Kernel build broken without "options KTRACE"

[John Nielsen]

Getting a set but not used warning for “td” in sys/kern/kern_condvar.c when 
doing a buildkernel for a config file without “options KTRACE”. I failed to 
copy the full error message/line numbers but I will reproduce this evening if 
needed.

JN

Re: How do I update the kernel of FreeBSD-CURRENT

[John Nielsen]

On Nov 29, 2023, at 12:21 PM, Manoel Games  wrote:
> 
> I am a new FreeBSD user, and I am using FreeBSD-CURRENT. How do I update the 
> FreeBSD-CURRENT kernel, and is it done through pkg? I installed 
> FreeBSD-CURRENT without src.

As a new user you should probably run a supported release version, such as 
14.0.  Releases have binary updates available via freebsd-update. (Upgrading 
the base OS via pkg is still experimental.) Current has no such feature, so you 
need to download/update the source and recompile.

See the Handbook chapter on upgrading FreeBSD:
https://docs.freebsd.org/en/books/handbook/cutting-edge/

JN

Re: twe(4) removed

[John Nielsen]

> On Jun 24, 2023, at 4:16 AM, Marcin Cieslak  wrote:
> 
> I just noticed that I had to remove "device twe"
> from my kernel configuration when rebuilding my -CURRENT today.
> 
> Is there any problem with this driver that makes it difficult
> to keep around?
> 
> Believe or not, I still rent a machine using it in JBOD mode
> (running 13 right now but I could switch it to -CURRENT for testing if 
> needed).

The deprecation notice and partial justification are here:
https://cgit.freebsd.org/src/commit/?id=4b22ce07306243d6641c93efcf315a787dd0876c

JN

Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 7, 2018, at 6:07 AM, Maurizio Vairani <maurizio1...@gmail.com> wrote:
> 
> 2018-02-06 23:02 GMT+01:00 John Nielsen <li...@jnielsen.net>:
> > On Feb 6, 2018, at 11:50 AM, Ian Lepore <i...@freebsd.org> wrote:
> >
> > On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> >>
> >> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> >> since this commit in 2011:
> >> https://svnweb.freebsd.org/base?view=revision=218757
> >>
> >> So I'm going to add this patch to the port unconditionally once it
> >> works.
> >>
> >> Unfortunately, I can't compile the port with either my patch below or
> >> your original replacement version of isboot_ifup(). :( Did you make
> >> other changes? Here's the error I'm getting:
> >>
> >> --- isboot.o ---
> >> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> >> error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
> >>   ~~^
> >> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> >> thread'
> >> struct thread;
> >>^
> >> 1 error generated.
> >>
> >
> > Try adding #include  if it's not already in the list.  It
> > may be that that file got included via pollution from some other header
> > file in the past and maybe now that has changed.
> >
> > If you're already including sys/proc.h then I'm clueless.
> 
> Thanks Ian, that appears to work.
> 
> Maurizio, can you apply the attached patch to a clean ports tree and see if 
> isboot-kmod will build and function properly for you? This is all the changes 
> from this thread and the previous one. If you let me know it works I'll get 
> the port updated.
> 
> 
> Hi John, I need some help.
> 
> I am running:
>  # uname -a
> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52 
> UTC 2018 
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> 
> after upgrading the ports tree with:
> # portsnap fetch update
> 
> I have copied the directory /usr/ports/net/isboot-kmod/ in  
> /root/src/isboot-kmod and /root/src/isboot-kmod.orig
> # ls -l /root/src
> total 6
> drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod
> drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod.orig
> -rw-rw-rw-  1 root  wheel  5630 Feb  7 11:38 isboot_patch.txt
> 
> Trying to apply the patch I obtain the error:
> # cd /root/src
> # patch -sC < isboot_patch.txt
> 2 out of 2 hunks failed while patching isboot-kmod/Makefile
> 5 out of 5 hunks failed while patching isboot-kmod/files/patch-isboot.c 
> 
> What I am missing ?
> Thanks again for your work.

Not sure but I ran in to similar issues testing here as well. Here's the "svn 
diff" patch which does work for me. Note that this one should be applied from 
within the isboot-kmod directory.

Index: Makefile
===
--- Makefile(revision 461112)
+++ Makefile(working copy)
@@ -2,7 +2,7 @@
 
 PORTNAME=  isboot-kmod
 PORTVERSION=   0.2.13
-PORTREVISION=  1
+PORTREVISION=  2
 CATEGORIES=net
 MASTER_SITES=  http://www.peach.ne.jp/archives/isboot/
 DISTNAME=  isboot-${PORTVERSION}
@@ -12,9 +12,7 @@
 
 LICENSE=   BSD2CLAUSE
 
-BROKEN_aarch64=fails to compile: 
/usr/src/sys/sys/bus.h:724:10: fatal error: 'device_if.h' file not found
 BROKEN_armv6=  fails to compile: implicit declaration of function 
'cp15_pmccntr_get' is invalid in C99
-BROKEN_armv7=  fails to compile: /usr/src/sys/sys/bus.h:724:10: fatal 
error: 'device_if.h' file not found
 BROKEN_powerpc64=  fails to compile: pcpu.h: size of array '__assert_0' is 
negative
 
 USES=  kmod uidfix
Index: files/patch-Makefile
===
--- files/patch-Makefile(nonexistent)
+++ files/patch-Makefile(working copy)
@@ -0,0 +1,10 @@
+--- Makefile.orig  2015-09-23 22:33:04.0 -0600
 Makefile   2018-01-29 10:20:10.453188000 -0700
+@@ -6,6 +6,7 @@
+ SRCS= isboot.c ibft.c iscsi.c
+ SRCS+=isboot.h ibft.h iscsi_compat.h
+ SRCS+=opt_cam.h
++SRCS+=device_if.h bus_if.h
+ #CFLAGS+= -DVIMAGE
+ #CFLAGS+= -DIBFT_VERBOSE
+ #CFLAGS+= -DDEBUG

Property changes on: files/patch-Makefile
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at 

Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 6, 2018, at 11:50 AM, Ian Lepore <i...@freebsd.org> wrote:
> 
> On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
>> 
>> Apparently sending a NULL socket pointer to ifioctl hasn't worked
>> since this commit in 2011:
>> https://svnweb.freebsd.org/base?view=revision=218757
>> 
>> So I'm going to add this patch to the port unconditionally once it
>> works.
>> 
>> Unfortunately, I can't compile the port with either my patch below or
>> your original replacement version of isboot_ifup(). :( Did you make
>> other changes? Here's the error I'm getting:
>> 
>> --- isboot.o ---
>> isboot.c:425:53: error: incomplete definition of type 'struct thread'
>> error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
>>   ~~^
>> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
>> thread'
>> struct thread;
>>^
>> 1 error generated.
>> 
> 
> Try adding #include  if it's not already in the list.  It
> may be that that file got included via pollution from some other header
> file in the past and maybe now that has changed.
> 
> If you're already including sys/proc.h then I'm clueless.

Thanks Ian, that appears to work.

Maurizio, can you apply the attached patch to a clean ports tree and see if 
isboot-kmod will build and function properly for you? This is all the changes 
from this thread and the previous one. If you let me know it works I'll get the 
port updated.

diff -uPr isboot-kmod.orig/Makefile isboot-kmod/Makefile
--- isboot-kmod.orig/Makefile   2018-01-11 07:18:01.0 -0700
+++ isboot-kmod/Makefile2018-02-06 14:56:23.654737000 -0700
@@ -2,7 +2,7 @@
 
 PORTNAME=  isboot-kmod
 PORTVERSION=   0.2.13
-PORTREVISION=  1
+PORTREVISION=  2
 CATEGORIES=net
 MASTER_SITES=  http://www.peach.ne.jp/archives/isboot/
 DISTNAME=  isboot-${PORTVERSION}
@@ -12,9 +12,7 @@
 
 LICENSE=   BSD2CLAUSE
 
-BROKEN_aarch64=fails to compile: 
/usr/src/sys/sys/bus.h:724:10: fatal error: 'device_if.h' file not found
 BROKEN_armv6=  fails to compile: implicit declaration of function 
'cp15_pmccntr_get' is invalid in C99
-BROKEN_armv7=  fails to compile: /usr/src/sys/sys/bus.h:724:10: fatal 
error: 'device_if.h' file not found
 BROKEN_powerpc64=  fails to compile: pcpu.h: size of array '__assert_0' is 
negative
 
 USES=  kmod uidfix
diff -uPr isboot-kmod.orig/files/patch-Makefile isboot-kmod/files/patch-Makefile
--- isboot-kmod.orig/files/patch-Makefile   1969-12-31 17:00:00.0 
-0700
+++ isboot-kmod/files/patch-Makefile2018-01-29 10:24:27.372206000 -0700
@@ -0,0 +1,10 @@
+--- Makefile.orig  2015-09-23 22:33:04.0 -0600
 Makefile   2018-01-29 10:20:10.453188000 -0700
+@@ -6,6 +6,7 @@
+ SRCS= isboot.c ibft.c iscsi.c
+ SRCS+=isboot.h ibft.h iscsi_compat.h
+ SRCS+=opt_cam.h
++SRCS+=device_if.h bus_if.h
+ #CFLAGS+= -DVIMAGE
+ #CFLAGS+= -DIBFT_VERBOSE
+ #CFLAGS+= -DDEBUG
diff -uPr isboot-kmod.orig/files/patch-isboot.c isboot-kmod/files/patch-isboot.c
--- isboot-kmod.orig/files/patch-isboot.c   2016-05-06 08:34:57.0 
-0600
+++ isboot-kmod/files/patch-isboot.c2018-02-06 14:24:47.447244000 -0700
@@ -1,6 +1,14 @@
 isboot.c.orig  2015-11-05 16:50:51 UTC
-+++ isboot.c
-@@ -347,9 +347,9 @@ isboot_set_v4gw(struct sockaddr_in *gate
+--- isboot.c.orig  2015-11-05 09:50:51.0 -0700
 isboot.c   2018-02-06 14:23:24.479249000 -0700
+@@ -38,6 +38,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -347,9 +348,9 @@
netmask.sin_addr.s_addr = htonl(0);
  
/* delete gateway if exists */
@@ -12,7 +20,7 @@
if (error) {
if (error != ESRCH) {
printf("rtrequest RTM_DELETE error %d\n",
-@@ -359,9 +359,9 @@ isboot_set_v4gw(struct sockaddr_in *gate
+@@ -359,9 +360,9 @@
}
  
/* set new default gateway */
@@ -24,7 +32,7 @@
if (error) {
printf("rtrequest RTM_ADD error %d\n", error);
return (error);
-@@ -391,9 +391,9 @@ isboot_set_v6gw(struct sockaddr_in6 *gat
+@@ -391,9 +392,9 @@
memset(_addr, 0, 16);
  
/* delete gateway if exists */
@@ -36,7 +44,7 @@
if (error) {
if (error != ESRCH) {
printf("rtrequest RTM_DELETE error %d\n",
-@@ -403,9 +403,9 @@ isboot_set_v6gw(struct sockaddr_in6 *gat
+@@ -403,9 +404,9 @@
}
  
/* set new default gateway */
@@ -48,3 +56,42 @@
if (error) {
printf("rtrequest RTM_ADD error %d\n", error);
return (error);
+@@ -417,28 +418,36 @@
+ isboot_ifup(struct ifnet *ifp)
+ {
+   struct ifreq ifr;
++  struct s

Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 6, 2018, at 10:54 AM, John Nielsen <li...@jnielsen.net> wrote:
> 
>> 
>> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani <maurizio1...@gmail.com> wrote:
>> 
>> 2018-01-29 18:38 GMT+01:00 John Nielsen <li...@jnielsen.net>:
>> [ resending from correct email address ]
>> 
>>> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani <maurizio1...@gmail.com> 
>>> wrote:
>>> 
>>> I am running
>>> # uname
>>> -a
>>> 
>>> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
>>> UTC 2018 
>>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>>> amd64
>>> 
>>> After compiling the kernel module as discussed in this thread :
>>> https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html
>>> 
>>> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
>>> boot driver version 0.2.13, starts I receive a panic:
>>> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
>>> 
>>> Any idea?
>> 
>> Bummer! 
>> 
>> Aoyama-san-
>> 
>> Are you still maintaining isboot? Can you help debug this issue on FreeBSD 
>> 12-CURRENT?
>> 
>> Once we get it working I will update the port with whatever is needed and 
>> send you the patches in case you'd like to cut a new release.
>> 
>> Thank you!
>> 
>> I have solved the issue changing the function isboot_ifup() in the source 
>> file isboot.c.
> 
> Here is a patch with some changes to minimize the diff. Except for the 
> printed error messages does that look functionally equivalent?
> 
> Now the question is why is this change needed and for what values of 
> __FreeBSD_version is it appropriate?

Apparently sending a NULL socket pointer to ifioctl hasn't worked since this 
commit in 2011:
https://svnweb.freebsd.org/base?view=revision=218757

So I'm going to add this patch to the port unconditionally once it works.

Unfortunately, I can't compile the port with either my patch below or your 
original replacement version of isboot_ifup(). :( Did you make other changes? 
Here's the error I'm getting:

--- isboot.o ---
isboot.c:425:53: error: incomplete definition of type 'struct thread'
error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
  ~~^
/usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct thread'
struct thread;
   ^
1 error generated.


> # diff -u isboot.c.patched1 isboot.c
> --- isboot.c.patched1 2018-02-06 10:35:20.808692000 -0700
> +++ isboot.c  2018-02-06 10:50:05.347663000 -0700
> @@ -417,28 +417,36 @@
> isboot_ifup(struct ifnet *ifp)
> {
>   struct ifreq ifr;
> + struct socket *so;
>   struct thread *td;
>   int error;
> 
>   memset(, 0, sizeof(ifr));
>   td = curthread;
> 
> + error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
> + if (error) {
> + printf("%s: socreate, error=%d\n", __func__, error);
> + return (error);
> + }
> +
>   /* boot NIC */
>   strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
> 
>   /* set IFF_UP */
> - error = ifioctl(NULL, SIOCGIFFLAGS, (caddr_t), td);
> + error = ifioctl(so, SIOCGIFFLAGS, (caddr_t), td);
>   if (error) {
>   printf("ifioctl SIOCGIFFLAGS\n");
>   return (error);
>   }
>   ifr.ifr_flags |= IFF_UP;
> - error = ifioctl(NULL, SIOCSIFFLAGS, (caddr_t), td);
> + error = ifioctl(so, SIOCSIFFLAGS, (caddr_t), td);
>   if (error) {
>   printf("ifioctl SIOCSIFFLAGS\n");
>   return (error);
>   }
> 
> + soclose(so);
>   return (0);
> }
> 
> 
>> static int
>> isboot_ifup(struct ifnet *ifp)
>> {
>>struct socket *so;
>>struct ifreq ifr;
>>struct thread *td;
>>int error;
>> 
>>td = curthread;
>>error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
>>if (error) {
>>printf("%s: socreate, error=%d\n", __func__, error);
>>return (error);
>>}
>> 
>>/* boot NIC */
>>memset(, 0, sizeof(ifr));
>>strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
>> 
>>/* set IFF_UP */
>>error = ifioctl(so, SIOCGIFFLAGS, (caddr_t), td);
>>if (error) {
>>printf("%s: ifioctl SIOCGIFFLAGS, error=%d\n", __func__, error);
>>return (error);
>>}
>> 
>>ifr.ifr_flags |= IFF_UP;
>>error = ifioctl(so, SIOCSIFFLAGS, (caddr_t), td);
>>if (error) {
>>printf("%s, ifioctl SIOCSIFFLAGS, error=%d\n", __func__, error);
>>return (error);
>>}
>>soclose(so);
>>return (0);
>> }
>> 
>> I have added a socket in the ifioctl() call as in the 
>> /usr/src/sys/nfs/bootp_subr.c source.
>> Please let me know if you prefer a patch.
>> --
>> Regards,
>> Maurizio

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

Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani <maurizio1...@gmail.com> wrote:
> 
> 2018-01-29 18:38 GMT+01:00 John Nielsen <li...@jnielsen.net>:
> [ resending from correct email address ]
> 
>> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani <maurizio1...@gmail.com> wrote:
>> 
>> I am running
>> # uname
>> -a
>> 
>> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
>> UTC 2018 
>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>> 
>> After compiling the kernel module as discussed in this thread :
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html
>> 
>> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
>> boot driver version 0.2.13, starts I receive a panic:
>> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
>> 
>> Any idea?
> 
> Bummer! 
> 
> Aoyama-san-
> 
> Are you still maintaining isboot? Can you help debug this issue on FreeBSD 
> 12-CURRENT?
> 
> Once we get it working I will update the port with whatever is needed and 
> send you the patches in case you'd like to cut a new release.
> 
> Thank you!
> 
> I have solved the issue changing the function isboot_ifup() in the source 
> file isboot.c.

Here is a patch with some changes to minimize the diff. Except for the printed 
error messages does that look functionally equivalent?

Now the question is why is this change needed and for what values of 
__FreeBSD_version is it appropriate?

# diff -u isboot.c.patched1 isboot.c
--- isboot.c.patched1   2018-02-06 10:35:20.808692000 -0700
+++ isboot.c2018-02-06 10:50:05.347663000 -0700
@@ -417,28 +417,36 @@
 isboot_ifup(struct ifnet *ifp)
 {
struct ifreq ifr;
+   struct socket *so;
struct thread *td;
int error;
 
memset(, 0, sizeof(ifr));
td = curthread;
 
+   error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
+   if (error) {
+   printf("%s: socreate, error=%d\n", __func__, error);
+   return (error);
+   }
+
/* boot NIC */
strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
 
/* set IFF_UP */
-   error = ifioctl(NULL, SIOCGIFFLAGS, (caddr_t), td);
+   error = ifioctl(so, SIOCGIFFLAGS, (caddr_t), td);
if (error) {
printf("ifioctl SIOCGIFFLAGS\n");
return (error);
}
ifr.ifr_flags |= IFF_UP;
-   error = ifioctl(NULL, SIOCSIFFLAGS, (caddr_t), td);
+   error = ifioctl(so, SIOCSIFFLAGS, (caddr_t), td);
if (error) {
printf("ifioctl SIOCSIFFLAGS\n");
return (error);
}
 
+   soclose(so);
return (0);
 }


> static int
> isboot_ifup(struct ifnet *ifp)
> {
> struct socket *so;
> struct ifreq ifr;
> struct thread *td;
> int error;
> 
> td = curthread;
> error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
> if (error) {
> printf("%s: socreate, error=%d\n", __func__, error);
> return (error);
> }
> 
> /* boot NIC */
> memset(, 0, sizeof(ifr));
> strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
> 
> /* set IFF_UP */
> error = ifioctl(so, SIOCGIFFLAGS, (caddr_t), td);
> if (error) {
> printf("%s: ifioctl SIOCGIFFLAGS, error=%d\n", __func__, error);
> return (error);
> }
> 
> ifr.ifr_flags |= IFF_UP;
> error = ifioctl(so, SIOCSIFFLAGS, (caddr_t), td);
> if (error) {
> printf("%s, ifioctl SIOCSIFFLAGS, error=%d\n", __func__, error);
> return (error);
> }
> soclose(so);
> return (0);
> }
> 
> I have added a socket in the ifioctl() call as in the 
> /usr/src/sys/nfs/bootp_subr.c source.
> Please let me know if you prefer a patch.
> --
> Regards,
> Maurizio
> 

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

Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

> On Feb 4, 2018, at 2:50 AM, Maurizio Vairani <maurizio1...@gmail.com> wrote:
> 
> 2018-01-29 18:38 GMT+01:00 John Nielsen <li...@jnielsen.net>:
> [ resending from correct email address ]
> 
>> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani <maurizio1...@gmail.com> wrote:
>> 
>> I am running
>> # uname
>> -a
>> 
>> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
>> UTC 2018 
>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>> 
>> After compiling the kernel module as discussed in this thread :
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html
>> 
>> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
>> boot driver version 0.2.13, starts I receive a panic:
>> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
>> 
>> Any idea?
> 
> Bummer! 
> 
> Aoyama-san-
> 
> Are you still maintaining isboot? Can you help debug this issue on FreeBSD 
> 12-CURRENT?
> 
> Once we get it working I will update the port with whatever is needed and 
> send you the patches in case you'd like to cut a new release.
> 
> Thank you!
> 
> I have solved the issue changing the function isboot_ifup() in the source 
> file isboot.c.

Nice work, thank you! I'll put the below together with the necessary changes to 
iscsi.c and update the port. If you could re-install from the port at that 
point as a further test/sanity check that would be great.

> static int
> isboot_ifup(struct ifnet *ifp)
> {
> struct socket *so;
> struct ifreq ifr;
> struct thread *td;
> int error;
> 
> td = curthread;
> error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
> if (error) {
> printf("%s: socreate, error=%d\n", __func__, error);
> return (error);
> }
> 
> /* boot NIC */
> memset(, 0, sizeof(ifr));
> strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));
> 
> /* set IFF_UP */
> error = ifioctl(so, SIOCGIFFLAGS, (caddr_t), td);
> if (error) {
> printf("%s: ifioctl SIOCGIFFLAGS, error=%d\n", __func__, error);
> return (error);
> }
> 
> ifr.ifr_flags |= IFF_UP;
> error = ifioctl(so, SIOCSIFFLAGS, (caddr_t), td);
> if (error) {
> printf("%s, ifioctl SIOCSIFFLAGS, error=%d\n", __func__, error);
> return (error);
> }
> soclose(so);
> return (0);
> }
> 
> I have added a socket in the ifioctl() call as in the 
> /usr/src/sys/nfs/bootp_subr.c source.
> Please let me know if you prefer a patch.
> --
> Regards,
> Maurizio

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

Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[John Nielsen]

[ resending from correct email address ]

> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani  wrote:
> 
> I am running
> # uname
> -a
> 
> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
> UTC 2018 
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
> 
> After compiling the kernel module as discussed in this thread :
> https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html
> 
> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
> boot driver version 0.2.13, starts I receive a panic:
> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
> 
> Any idea?

Bummer! 

Aoyama-san-

Are you still maintaining isboot? Can you help debug this issue on FreeBSD 
12-CURRENT?

Once we get it working I will update the port with whatever is needed and send 
you the patches in case you'd like to cut a new release.

Thank you!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Error compiling isboot-kmod

[John Nielsen]

> On Jan 27, 2018, at 9:20 AM, Ian Lepore <i...@freebsd.org> wrote:
> 
> On Fri, 2018-01-26 at 23:20 -0700, John Nielsen wrote:
>>> 
>>> On Jan 26, 2018, at 9:42 PM, John Nielsen <li...@jnielsen.net> wrote:
>>> 
>>>> 
>>>> [...]
>>> --- iscsi.o ---
>>> iscsi.c:1146:3: error: incompatible pointer types passing 'void (struct 
>>> mbuf *, void *, void *)' to parameter of type 'm_ext_free_t *' (aka 'void 
>>> (*)(struct mbuf *)') [-Werror,-Wincompatible-pointer-types]
>>>MEXTADD(md, (caddr_t)ds_dd, (ISCSI_ALIGN(pp->ds_len)
>>>^~~~
>>> /usr/src/sys/sys/mbuf.h:887:42: note: expanded from macro 'MEXTADD'
>>>m_extadd((m), (char *)(buf), (size), (free), (arg1), (arg2),\
>>> ^~
>>> /usr/src/sys/sys/mbuf.h:634:59: note: passing argument to parameter here
>>> void m_extadd(struct mbuf *, char *, u_int, m_ext_free_t,
>> Looks like iscsi.c needs to be fixed up following r324446
>> (https://svnweb.freebsd.org/changeset/base/324446). Starting to be
>> out of my depth unless there's a mechanical way to make the changes?
> 
> I'm not set up to test-compile this against -current right now, so I'm
> not sure if this is all that remains or just another breadcrumb on the
> trail, but... try the attached patch.
> 
> -- Ian
> --- iscsi.c.orig  2018-01-27 08:43:26.937858000 -0700
> +++ iscsi.c   2018-01-27 09:15:39.631501000 -0700
> @@ -1071,17 +1071,23 @@
> }
> 
> 
> -#if __FreeBSD_version >= 110
> +#if __FreeBSD_version >= 1200051
> +static void
> +isboot_free_mbufext(struct mbuf *m)
> +{
> + void *p = m->m_ext.ext_arg1;
> +#elif __FreeBSD_version >= 110
> static void
> isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
> #elif __FreeBSD_version >= 150 && __FreeBSD_version < 110
> static int
> isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
> +{
> #else
> static void
> isboot_free_mbufext(void *p, void *optarg)
> -#endif
> {
> +#endif

Thanks Ian. I think I ran in to a copy/paste issue on my end with the above but 
I can compile with this similar patch. Is it functionally equivalent to yours?

--- iscsi.c.orig2015-11-05 09:50:51.0 -0700
+++ iscsi.c 2018-01-29 10:20:00.586277000 -0700
@@ -1070,9 +1070,11 @@
return (n);
 }
 
-
-#if __FreeBSD_version >= 110
+#if __FreeBSD_version >= 1200051
 static void
+isboot_free_mbufext(struct mbuf *m)
+#elif __FreeBSD_version >= 110
+static void
 isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
 #elif __FreeBSD_version >= 150 && __FreeBSD_version < 110
 static int
@@ -1082,7 +1084,9 @@
 isboot_free_mbufext(void *p, void *optarg)
 #endif
 {
-
+#if __FreeBSD_version >= 1200051
+   void *p = m->m_ext.ext_arg1;
+#endif
ISBOOT_TRACE("isboot_free_mbufext\n");
if (p == NULL)
 #if __FreeBSD_version >= 150 && __FreeBSD_version < 110

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

Re: Error compiling isboot-kmod

[John Nielsen]

> On Jan 26, 2018, at 9:42 PM, John Nielsen <li...@jnielsen.net> wrote:
> 
>> On Jan 26, 2018, at 10:35 AM, Ian Lepore <i...@freebsd.org> wrote:
>> 
>> On Fri, 2018-01-26 at 10:00 -0700, John Nielsen wrote:
>>>> 
>>>> On Jan 26, 2018, at 3:37 AM, Maurizio Vairani <maurizio1018@gmail.c
>>>> om> wrote:
>>>> 
>>>> 2018-01-24 17:19 GMT+01:00 Warner Losh <i...@bsdimp.com>:
>>>> 
>>>> 
>>>> On Wed, Jan 24, 2018 at 3:12 AM, Maurizio Vairani <maurizio1018@gma
>>>> il.com> wrote:
>>>> On this CURRENT snapshot
>>>> # uname -a
>>>> FreeBSD freebsd12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r327788: Wed
>>>> Jan 10
>>>> 22:55:40 UTC 2018
>>>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENER
>>>> IC
>>>> amd64
>>>> 
>>>> I can't compile the kernel module isboot-kmod:
>>>> 
>>>> /usr/src/sys/sys/bus.h:726:10: fatal error: 'device_if.h' file not
>>>> found
>>>> #include "device_if.h"
>>>> ^
>>>> 
>>>> I think this was fixed in a newer -current.
>>>> 
>>>> Warner 
>>>> Thanks Warner, but I have the same error in :
>>>> # uname -a
>>>> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25
>>>> 04:48:52 UTC 2018 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src
>>>> /amd64.amd64/sys/GENERIC  amd64
>>> Whatever change broke it happened around the beginning of July 2017.
>>> I started getting (and ignoring, sadly, due to lack of time and
>>> certainty that anyone cared) messages with this error from pkg-
>>> fallout@ on July 11. I'm looking through the revision history but
>>> nothing stands out to me yet. Maybe someone with better svn-foo will
>>> find it faster. :)
>>> 
>>>> In file included from /usr/src/sys/dev/mmc/bridge.h:59:
>>>> /usr/src/sys/sys/bus.h:726:10: fatal error: 'device_if.h' file not
>>>> found
>>>> #include "device_if.h"
>>>> ^
>> 
>> I've never looked into how kernel modules compile when built as a port,
>> but when built as part of the system kernel build, the SRCS= in the
>> module makefile needs to name all of the dynamically generated header
>> files such as device_if.h (basically anything ending in _if.h used by
>> the module needs to be in SRCS=).
>> 
>> So adding device_if.h to SRCS may be all that's needed.  Or maybe
>> that's incremental and you'll find that several others are needed as
>> well.
> 
> Thanks! Patching the Makefile with:
> SRCS+=  device_if.h bus_if.h
> 
> solves the above issue but now there's something else. Anyone have an idea 
> off the top of their head?
> 
> root@freebsd12:/usr/ports/net/isboot-kmod # make
> ===>  Configuring for isboot-kmod-0.2.13_1
> ===>  Building for isboot-kmod-0.2.13_1
> --- machine ---
> --- x86 ---
> --- objwarn ---
> Warning: Object directory not changed from original 
> /usr/ports/net/isboot-kmod/work/isboot-0.2.13/src
> --- x86 ---
> x86 -> /usr/src/sys/x86/include
> --- machine ---
> machine -> /usr/src/sys/amd64/include
> --- opt_cam.h ---
> --- device_if.h ---
> --- bus_if.h ---
> --- opt_cam.h ---
> :> opt_cam.h
> --- device_if.h ---
> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h
> --- bus_if.h ---
> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
> --- isboot.o ---
> --- ibft.o ---
> --- iscsi.o ---
> --- isboot.o ---
> cc  -O2 -pipe -DNO_MALLOC_EXTRAS -fno-strict-aliasing -DNO_MALLOC_EXTRAS  
> -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I/usr/src/sys -fno-common  
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   -MD  
> -MF.depend.isboot.o -MTisboot.o -mcmodel=kernel -mno-red-zone -mno-mmx 
> -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
> -fstack-protector -Wall -Wredundant-decls -Wnested-externs 
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
> -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
> -Wno-error-tautological-compare -Wno-error-empty-body 
> -Wno-error-parentheses-equality -Wno-error-unused-function 
> -Wno-error-pointer-sign -Wno-error-shift-negative-value 
> -Wno-error-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 -c 
> isboot.c -o isboot.o

Re: Error compiling isboot-kmod

[John Nielsen]

> On Jan 26, 2018, at 10:35 AM, Ian Lepore <i...@freebsd.org> wrote:
> 
> On Fri, 2018-01-26 at 10:00 -0700, John Nielsen wrote:
>>> 
>>> On Jan 26, 2018, at 3:37 AM, Maurizio Vairani <maurizio1018@gmail.c
>>> om> wrote:
>>> 
>>> 2018-01-24 17:19 GMT+01:00 Warner Losh <i...@bsdimp.com>:
>>> 
>>> 
>>> On Wed, Jan 24, 2018 at 3:12 AM, Maurizio Vairani <maurizio1018@gma
>>> il.com> wrote:
>>> On this CURRENT snapshot
>>> # uname -a
>>> FreeBSD freebsd12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r327788: Wed
>>> Jan 10
>>> 22:55:40 UTC 2018
>>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENER
>>> IC
>>> amd64
>>> 
>>> I can't compile the kernel module isboot-kmod:
>>> 
>>> /usr/src/sys/sys/bus.h:726:10: fatal error: 'device_if.h' file not
>>> found
>>> #include "device_if.h"
>>>  ^
>>> 
>>> I think this was fixed in a newer -current.
>>> 
>>> Warner 
>>> Thanks Warner, but I have the same error in :
>>> # uname -a
>>> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25
>>> 04:48:52 UTC 2018 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src
>>> /amd64.amd64/sys/GENERIC  amd64
>> Whatever change broke it happened around the beginning of July 2017.
>> I started getting (and ignoring, sadly, due to lack of time and
>> certainty that anyone cared) messages with this error from pkg-
>> fallout@ on July 11. I'm looking through the revision history but
>> nothing stands out to me yet. Maybe someone with better svn-foo will
>> find it faster. :)
>> 
>>> In file included from /usr/src/sys/dev/mmc/bridge.h:59:
>>> /usr/src/sys/sys/bus.h:726:10: fatal error: 'device_if.h' file not
>>> found
>>> #include "device_if.h"
>>>  ^
> 
> I've never looked into how kernel modules compile when built as a port,
> but when built as part of the system kernel build, the SRCS= in the
> module makefile needs to name all of the dynamically generated header
> files such as device_if.h (basically anything ending in _if.h used by
> the module needs to be in SRCS=).
> 
> So adding device_if.h to SRCS may be all that's needed.  Or maybe
> that's incremental and you'll find that several others are needed as
> well.

Thanks! Patching the Makefile with:
SRCS+=  device_if.h bus_if.h

solves the above issue but now there's something else. Anyone have an idea off 
the top of their head?

root@freebsd12:/usr/ports/net/isboot-kmod # make
===>  Configuring for isboot-kmod-0.2.13_1
===>  Building for isboot-kmod-0.2.13_1
--- machine ---
--- x86 ---
--- objwarn ---
Warning: Object directory not changed from original 
/usr/ports/net/isboot-kmod/work/isboot-0.2.13/src
--- x86 ---
x86 -> /usr/src/sys/x86/include
--- machine ---
machine -> /usr/src/sys/amd64/include
--- opt_cam.h ---
--- device_if.h ---
--- bus_if.h ---
--- opt_cam.h ---
:> opt_cam.h
--- device_if.h ---
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h
--- bus_if.h ---
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
--- isboot.o ---
--- ibft.o ---
--- iscsi.o ---
--- isboot.o ---
cc  -O2 -pipe -DNO_MALLOC_EXTRAS -fno-strict-aliasing -DNO_MALLOC_EXTRAS  
-Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I/usr/src/sys -fno-common  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   -MD  -MF.depend.isboot.o 
-MTisboot.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare 
-Wno-error-empty-body -Wno-error-parentheses-equality 
-Wno-error-unused-function -Wno-error-pointer-sign 
-Wno-error-shift-negative-value -Wno-error-address-of-packed-member  -mno-aes 
-mno-avx  -std=iso9899:1999 -c isboot.c -o isboot.o
--- iscsi.o ---
cc  -O2 -pipe -DNO_MALLOC_EXTRAS -fno-strict-aliasing -DNO_MALLOC_EXTRAS  
-Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I/usr/src/sys -fno-common  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   -MD  -MF.depend.iscsi.o 
-MTiscsi.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign

Re: Error compiling isboot-kmod

[John Nielsen]

> On Jan 26, 2018, at 3:37 AM, Maurizio Vairani  wrote:
> 
> 2018-01-24 17:19 GMT+01:00 Warner Losh :
> 
> 
> On Wed, Jan 24, 2018 at 3:12 AM, Maurizio Vairani  
> wrote:
> On this CURRENT snapshot
> # uname -a
> FreeBSD freebsd12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r327788: Wed Jan 10
> 22:55:40 UTC 2018
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
> 
> I can't compile the kernel module isboot-kmod:
> # cd /usr/ports/net/isboot-kmod && make
> ===>  License BSD2CLAUSE accepted by the
> user
> 
> ===>   isboot-kmod-0.2.13_1 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by isboot-kmod-0.2.13_1 for building
> ===>  Extracting for isboot-kmod-0.2.13_1
> => SHA256 Checksum OK for isboot-0.2.13.tar.gz.
> ===>  Patching for isboot-kmod-0.2.13_1
> ===>  Applying FreeBSD patches for isboot-kmod-0.2.13_1
> ===>  Configuring for isboot-kmod-0.2.13_1
> ===>  Building for isboot-kmod-0.2.13_1
> --- machine ---
> --- x86 ---
> --- machine ---
> machine -> /usr/src/sys/amd64/include
> --- x86 ---
> x86 -> /usr/src/sys/x86/include
> --- objwarn ---
> --- opt_cam.h ---
> --- objwarn ---
> Warning: Object directory not changed from original
> /usr/ports/net/isboot-kmod/work/isboot-0.2.13/src
> --- opt_cam.h ---
> :> opt_cam.h
> --- isboot.o ---
> --- ibft.o ---
> --- isboot.o ---
> cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
> d.isboot.o -MTisboot.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
> -fstack-protector -Wall -Wredundant-dec$
> s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs $
> fdiagnostics-show-option -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-s$
> gn -Wno-error-shift-negative-value -Wno-error-address-of-packed-member
> -mno-aes -mno-avx  -std=iso9899:1999 -c isboot.c -o isboot.o
> --- ibft.o ---
> cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
> d.ibft.o -MTibft.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
> -fstack-protector -Wall -Wredundant-decls -$
> nested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdi$
> gnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare
> -Wno-error-empty-body -Wno-error-parentheses-equality
> -Wno-error-unused-function -Wno-error-pointer-sign $
> Wno-error-shift-negative-value -Wno-error-address-of-packed-member
> -mno-aes -mno-avx  -std=iso9899:1999 -c ibft.c -o ibft.o
> --- iscsi.o ---
> cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
> d.iscsi.o -MTiscsi.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
> -fstack-protector -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -f$
> iagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare
> -Wno-error-empty-body -Wno-error-parentheses-equality
> -Wno-error-unused-function -Wno-error-pointer-sig$
>  -Wno-error-shift-negative-value -Wno-error-address-of-packed-member
> -mno-aes -mno-avx  -std=iso9899:1999 -c iscsi.c -o iscsi.o
> In file included from iscsi.c:62:
> In file included from /usr/src/sys/cam/cam_ccb.h:1035:
> In file included from /usr/src/sys/cam/mmc/mmc_bus.h:5:
> In file included from /usr/src/sys/dev/mmc/bridge.h:59:
> /usr/src/sys/sys/bus.h:726:10: fatal error: 'device_if.h' file not found
> #include "device_if.h"
>  ^
> 
> I think this was fixed in a newer -current.
> 
> Warner 
> Thanks Warner, but I have the same error in :
> # uname -a
> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52 
> UTC 2018 
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

Whatever change broke it happened around the beginning of July 2017. I started 
getting (and ignoring, sadly, due to lack of time and certainty that anyone 
cared) messages with this error from pkg-fallout@ on July 11. I'm looking 
through the revision history but 

Re: bhyve with lagg failover doesn't work on wifi

[John Nielsen]

Generally speaking, you can't bridge the station side of a wireless link. The 
access point will only accept frames with the station's MAC address. So what 
you are seeing is expected, unfortunately.

Your best bet is probably to do NAT. Take lagg0 out of the bridge and use it as 
your "public" interface. Assign a local IP to the bridge. Run a DHCP server on 
your host (or in another VM on the bridge if you like) or just use static 
internal IPs on your VMs. Enable IP forwarding (gateway_enable=yes in rc.conf). 
Configure your firewall to NAT your private range out lagg0.

You can do other things with tunneling, etc. but you'll need a remote endpoint 
for the tunnel. (If your access point runs FreeBSD you can use either vxlan or 
gif+EtherIP and just use the wireless link to carry the tunnel traffic, but I 
suspect that you want to roam between arbitrary access points.)

> On Jul 28, 2016, at 10:56 PM, Randy Westlund  wrote:
> 
> I'm using bhyve on 11.0-BETA2, bridging tap0 to lagg0, a failover
> between wifi and ethernet.  The bhyve VM's networking only works I'm
> using ethernet.
> 
>> # Lagg config.
>> ifconfig_em0="up"
>> create_args_wlan0="wlanaddr 3c:97:0e:46:70:ca"
>> wlans_iwn0="wlan0"
>> ifconfig_wlan0="WPA"
>> cloned_interfaces="lagg0 bridge0 tap0"
>> ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"
>> # tap0 and bridge0 are for bhyve.
>> ifconfig_bridge0="addm lagg0 addm tap0"
> 
> With the ethernet cable connected, the VM's networking works.  But when
> I remove the ethernet cable and lagg0 fails over to wifi, the VM can no
> longer use the network.
> 
> I can use tcpdump to see the DHCP packets going along this path:
>vtnet0 -> tap0 -> bridge0 -> lagg0 -> wlan0
> 
> The DHCP requests appear on wlan0.  But the router never sees them.
> 
> Here's the ifconfig output when wlan0 is active:
> 
>> em0: flags=8943 metric 0 mtu 
>> 1500
>>
>> options=4219b
>>ether 3c:97:0e:46:70:ca
>>nd6 options=29
>>media: Ethernet autoselect
>>status: no carrier
>> lo0: flags=8049 metric 0 mtu 16384
>>options=63
>>inet6 ::1 prefixlen 128
>>inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>>inet 127.0.0.1 netmask 0xff00
>>nd6 options=21
>>groups: lo
>> wlan0: flags=8943 metric 0 
>> mtu 1500
>>ether 3c:97:0e:46:70:ca
>>nd6 options=29
>>media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
>>status: associated
>>ssid neural_network channel 1 (2412 MHz 11g ht/40+) bssid 
>> c4:04:15:90:f5:fd
>>regdomain FCC country US authmode WPA2/802.11i privacy ON
>>deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 bmiss 10
>>scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8
>>-amsdutx amsdurx shortgi -stbc wme roaming MANUAL
>>groups: wlan
>> lagg0: flags=8943 metric 0 
>> mtu 1500
>>ether 3c:97:0e:46:70:ca
>>inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255
>>nd6 options=29
>>media: Ethernet autoselect
>>status: active
>>groups: lagg
>>laggproto failover lagghash l2,l3,l4
>>laggport: em0 flags=1
>>laggport: wlan0 flags=4
>> bridge0: flags=8843 metric 0 mtu 1500
>>ether 02:4a:6b:6e:fc:00
>>nd6 options=9
>>groups: bridge
>>id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>>root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>member: tap0 flags=143
>>ifmaxaddr 0 port 6 priority 128 path cost 200
>>member: lagg0 flags=143
>>ifmaxaddr 0 port 4 priority 128 path cost 55
>> tap0: flags=8943 metric 0 
>> mtu 1500
>>options=8
>>ether 00:bd:ea:f0:f6:00
>>nd6 options=29
>>media: Ethernet autoselect
>>status: active
>>groups: tap
>>Opened by PID 1322
> 

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

Re: Add isboot iSCSI boot driver to FreeBSD

[John Nielsen]

On Sep 23, 2015, at 2:12 AM, Yonas Yanfa  wrote:

> isboot is a iSCSI boot driver written by Daisuke Aoyama that allows you to 
> boot your root partition using iSCSI.
[,,,]
> This was first announced way back in June, 2010:
> 
> https://lists.freebsd.org/pipermail/freebsd-scsi/2010-June/004425.html
> 
> I've tested the current version (v0.2.10) and it works with FreeBSD 10.2 
> booting a ZFS on root installation:
> 
> http://www.peach.ne.jp/archives/isboot/isboot-0.2.10.tar.gz
> 
> I've used iSCSI boot with Ubuntu Server for a while and it's been very 
> useful. I'm looking forward to FreeBSD having the same capability built-in.

+1. I have used this module in the past and it is extremely useful. Thanks for 
the pointer, I wasn’t aware it had been updated for FreeBSD 10.x so recently. 
I’ve also wondered why this is not part of FreeBSD by default.

Aoyama-san, do you have any objection to this code being included in FreeBSD? 
If not, can you formally assign it a BSD or other friendly license? Thank you 
again for the work!

Trasz (or anyone), is there other work to support iSCSI booting and/or IBFT on 
FreeBSD? Anything else isboot might conflict with? Any problems with 
integrating the code or with the code itself?

In the mean time, I’m going to work on adding an isboot port to the tree to 
further ease installation and increase exposure.

JN

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

Re: Add isboot iSCSI boot driver to FreeBSD

[John Nielsen]

On Sep 23, 2015, at 9:16 AM, John Nielsen <li...@jnielsen.net> wrote:

> On Sep 23, 2015, at 2:12 AM, Yonas Yanfa <yo...@fizk.net> wrote:
> 
>> isboot is a iSCSI boot driver written by Daisuke Aoyama that allows you to 
>> boot your root partition using iSCSI.
> [,,,]
>> This was first announced way back in June, 2010:
>> 
>> https://lists.freebsd.org/pipermail/freebsd-scsi/2010-June/004425.html
>> 
>> I've tested the current version (v0.2.10) and it works with FreeBSD 10.2 
>> booting a ZFS on root installation:
>> 
>> http://www.peach.ne.jp/archives/isboot/isboot-0.2.10.tar.gz
>> 
>> I've used iSCSI boot with Ubuntu Server for a while and it's been very 
>> useful. I'm looking forward to FreeBSD having the same capability built-in.
> 
> +1. I have used this module in the past and it is extremely useful. Thanks 
> for the pointer, I wasn’t aware it had been updated for FreeBSD 10.x so 
> recently. I’ve also wondered why this is not part of FreeBSD by default.
> 
> Aoyama-san, do you have any objection to this code being included in FreeBSD? 
> If not, can you formally assign it a BSD or other friendly license? Thank you 
> again for the work!
> 
> Trasz (or anyone), is there other work to support iSCSI booting and/or IBFT 
> on FreeBSD? Anything else isboot might conflict with? Any problems with 
> integrating the code or with the code itself?
> 
> In the mean time, I’m going to work on adding an isboot port to the tree to 
> further ease installation and increase exposure.

Proposed port here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203294

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

Re: Add isboot iSCSI boot driver to FreeBSD

[John Nielsen]

On Sep 23, 2015, at 2:19 PM, Kurt Jaeger  wrote:

>> Proposed port here:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203294
> 
> Builds on 10.2a+i, fails on current-amd64 and 9.3-amd64.
> 
> Is this supposed to work on 9.3 or 11 ?

The README says 9.0-9.3 and 10.0-10.2. I’ve only tested it on 10.2. What is 
failing on the 9.3 build?

Can you try 0.2.8 (instead of 0.2.10) and see if it works any better on 9.3? 
(Change the version in the Makefile, mv distinfo distinfo.prev; make fetch; 
make makesum).

JN

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

Re: Add isboot iSCSI boot driver to FreeBSD

[John Nielsen]

On Sep 23, 2015, at 3:25 PM, Edward Tomasz Napierała <tr...@freebsd.org> wrote:

> On 0923T0916, John Nielsen wrote:
>> On Sep 23, 2015, at 2:12 AM, Yonas Yanfa <yo...@fizk.net> wrote:
>> 
>>> isboot is a iSCSI boot driver written by Daisuke Aoyama that allows you to 
>>> boot your root partition using iSCSI.
>> [,,,]
>>> This was first announced way back in June, 2010:
>>> 
>>> https://lists.freebsd.org/pipermail/freebsd-scsi/2010-June/004425.html
>>> 
>>> I've tested the current version (v0.2.10) and it works with FreeBSD 10.2 
>>> booting a ZFS on root installation:
>>> 
>>> http://www.peach.ne.jp/archives/isboot/isboot-0.2.10.tar.gz
>>> 
>>> I've used iSCSI boot with Ubuntu Server for a while and it's been very 
>>> useful. I'm looking forward to FreeBSD having the same capability built-in.
>> 
>> +1. I have used this module in the past and it is extremely useful. Thanks 
>> for the pointer, I wasn’t aware it had been updated for FreeBSD 10.x so 
>> recently. I’ve also wondered why this is not part of FreeBSD by default.
>> 
>> Aoyama-san, do you have any objection to this code being included in 
>> FreeBSD? If not, can you formally assign it a BSD or other friendly license? 
>> Thank you again for the work!
>> 
>> Trasz (or anyone), is there other work to support iSCSI booting and/or IBFT 
>> on FreeBSD? Anything else isboot might conflict with? Any problems with 
>> integrating the code or with the code itself?
> 
> The basic problem with isboot is that it only works with the old iSCSI
> initiator, which is now marked obsolete.  AFAIK there is no ready solution
> that works with the new one - however, it should be possible to use upcoming
> reroot support to achieve this: boot with a temporary rootfs, mounted from
> a ramdisk preloaded by loader(8), setup an iSCSI session, and then replace
> the temporary rootfs with the real one, mounted over iSCSI.

Ah, thank you for clarifying. I forgot that 10.x still supports the old 
initiator.

The reroot approach sounds interesting but less straightforward. The beauty of 
isboot is that the kernel—loaded from a normal root disk that happens to be 
iSCSI-connected—knows how to re-establish its network and iSCSI connections 
just from the information in the iSCSI Boot Firmware Table, i.e. native iSCSI 
booting. I’d love to see the same approach continued with the new initiator. I 
suspect that a new implementation could re-use all of the IBFT code and most of 
the networking code, but I don’t know how hard the remaining pieces would be. I 
may have a chance to look in to it but a kernel programmer I am not, sadly.

I think a “native” iSCSI reroot approach could be feasible at some point; for 
me that would mean that the loader could load the kernel and a standard-ish (or 
easily auto-generated) mfsroot from the iSCSI volume seamlessly, then something 
in the mfsroot parses the IBFT and sets up the network and iSCSI connections 
before switching root.

JN

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

Re: Add isboot iSCSI boot driver to FreeBSD

[John Nielsen]

On Sep 23, 2015, at 1:51 PM, John Nielsen <li...@jnielsen.net> wrote:

> On Sep 23, 2015, at 9:16 AM, John Nielsen <li...@jnielsen.net> wrote:
> 
>> On Sep 23, 2015, at 2:12 AM, Yonas Yanfa <yo...@fizk.net> wrote:
>> 
>>> isboot is a iSCSI boot driver written by Daisuke Aoyama that allows you to 
>>> boot your root partition using iSCSI.
>> [,,,]
>>> This was first announced way back in June, 2010:
>>> 
>>> https://lists.freebsd.org/pipermail/freebsd-scsi/2010-June/004425.html
>>> 
>>> I've tested the current version (v0.2.10) and it works with FreeBSD 10.2 
>>> booting a ZFS on root installation:
>>> 
>>> http://www.peach.ne.jp/archives/isboot/isboot-0.2.10.tar.gz
>>> 
>>> I've used iSCSI boot with Ubuntu Server for a while and it's been very 
>>> useful. I'm looking forward to FreeBSD having the same capability built-in.
>> 
>> +1. I have used this module in the past and it is extremely useful. Thanks 
>> for the pointer, I wasn’t aware it had been updated for FreeBSD 10.x so 
>> recently. I’ve also wondered why this is not part of FreeBSD by default.
>> 
>> Aoyama-san, do you have any objection to this code being included in 
>> FreeBSD? If not, can you formally assign it a BSD or other friendly license? 
>> Thank you again for the work!
>> 
>> Trasz (or anyone), is there other work to support iSCSI booting and/or IBFT 
>> on FreeBSD? Anything else isboot might conflict with? Any problems with 
>> integrating the code or with the code itself?
>> 
>> In the mean time, I’m going to work on adding an isboot port to the tree to 
>> further ease installation and increase exposure.
> 
> Proposed port here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203294

Thanks Allan and Mehmet for noticing the existing BSD license which I somehow 
overlooked in the source files.

I have updated the PR above based on some feedback. Further testing welcome.

JN

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

Re: Devops question: unattended installs of FreeBSD?

[John Nielsen]

On Jan 12, 2015, at 12:24 PM, Craig Rodrigues rodr...@freebsd.org wrote:

 I had a devops person who is familiar with setting up hundreds of
 Linux nodes in cloud environment ask me what is the best way
 to do unattended installs in a cloud environment.
 Linux has kickstart installs, which are quite useful and popular.
 
 What is the equivalent in FreeBSD?
 
 In the sysinstall days, the sysinstall.cfg config file could be created
 which drove large parts of the installer.  Now that sysinstall is gone,
 what is the alternative?  Searching the web, I found two answers:
 
 (1)  Write your own script
 (2)  Use pc-sysinstall from the PC-BSD project
 http://wiki.pcbsd.org/index.php/Creating_an_Automated_Installation_with_pc-sysinstall/10.0/en

bsdinstall(8) does support scripted installations, see the man page. Writing 
your own script is also viable, or a combination of the two. I don't have 
experience with scripting bsdinstall as I tend to script my own.

Vultr.com has a script that does a full installation when you first bring up a 
FreeBSD VM. At $work, I maintain a script which creates FreeBSD template disk 
images which are then cloned for new VMs. There are also now make targets in 
the base system to build VM-suitable disk images (but I don't recall what they 
are off the top of my head).

 I am trying to work with a devops team who is very experienced
 with setting up Linux environments in the cloud.  Based on the available
 docs,
 it is not clear to non-FreeBSD experts how to accomplish similar things
 with FreeBSD.

I'd be happy to provide more specific suggestions if needed. It really depends 
on how fully automated you want things to be and how much customization you 
want to include, as well as what you have available in the install environment. 
If you're installing on live VMs then you first have to get them booted. A 
custom ISO or MFS image is probably the simplest for that, though PXE is also 
an option. (Actually, serving an mfsBSD image via PXE is pretty 
straightforward.)

Then:

Set up the network if it will be needed for the install and is not already done.
Set up the disk(s), partition(s), filesystem(s), etc
Mount
Install distribution sets. Here's what I use for that:
#!/bin/sh
#...
DISTS=base kernel lib32 doc games
for dist in ${DISTS}; do
  fetch -o - ${BASEURL}/${dist}.txz | tar -xJ --exclude kernel/\*.symbols -C 
${MOUNTPOINT} -f -
done
#...

Run freebsd-update
Populate /etc/fstab
Set a root password
Make sure you can log in to the new system (if SSH is needed then either create 
a non-root user or enable root login in sshd_config (not ideal))
Populate /etc/rc.conf
Run tzsetup or similar
Install 3rd-party packages
Configure bootcode

 By the way, I would be very interested in hearing from people who have
 experience
 in installing, configuring, and upgrading hundreds or even thousands of
 FreeBSD
 nodes in devops and cloud environments.  For people who are not FreeBSD
 experts,
 but who are Linux devops experts, is it easy to do, or is there a lot of
 custom scripts which need to be written?

A few tools translate over more or less directly, such as Ansible and 
SaltStack. Having a uniform and automated installation procedure (like it 
sounds like you're going for) and front-loading a lot of your customization in 
to that is a good starting point. Building your own packages to 
distribute/update configuration files or run scripts where needed is also 
helpful. Install that package as part of the initial system setup then have it 
update itself (or push out a cron job, or do mass updates when needed via Salt, 
etc).

Just some ideas. I don't think it's any harder/easier than running lots of 
Linux servers, just different in some ways. If you want custom functionality 
then you'll probably need some custom scripts. :)

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

Re: HEADS UP: Merging projects/bhyve_svm to HEAD

[John Nielsen]

On Oct 26, 2014, at 4:40 PM, Zaphod Beeblebrox zbee...@gmail.com wrote:

 On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu neeln...@gmail.com wrote:
 
 On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox zbee...@gmail.com
 wrote:
 I tried to integrate this patch into 10.1_RC3 and I failed.  Is there a
 timeframe to MFC this to 10.1 or 10-STABLE?
 
 It will be MFCed to 10-STABLE but I don't have a specific time frame in
 mind.
 
 I'll guess that it'll be towards the end of November but can be
 accelerated if someone has a need for this in 10-STABLE sooner.
 
 I would be using such a patch as soon as it was available.  On a friend's
 advice, I upgraded a ZFS server here at home with an AMD 9590 and 32Gig of
 RAM.  I'd dearly like to use it to track down the netgraph bug (see my
 other recent posts), but it doesn't currently qualify.

Ping? I'm also waiting with bated breath for this to be MFCed. :) Thanks for 
the great work!

JN

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

Re: UEFI display frozen on Retina MacBook Pro

[John Nielsen]

On Sep 8, 2014, at 7:21 AM, Anders Bolt Evensen andersb...@icloud.com wrote:

 On 05.09.14 19:37, John Nielsen wrote:
 On Sep 5, 2014, at 11:30 AM, Glen Barber g...@freebsd.org wrote:
 
 On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote:
 I have a MacBook Pro Retina, Mid 2012 (MacBookPro10,1) on which I'd like 
 to be able to boot FreeBSD from an external USB drive. For testing I've 
 been using the mini-memstick images from the -CURRENT snapshots, most 
 recently the one from 20140903.
 
 I am able to select EFI Boot on the USB device from the Mac's boot menu, 
 and it does _something_, but the screen never changes--the image of the 
 boot menu is displayed indefinitely. I think it is actually booting since 
 there is drive activity and the caps lock key indicator starts working a 
 few seconds in, but the screen just stays the same. Thinking the 
 resolution of the Retina display may have been an issue, I tried booting 
 with it disabled (lid closed) and an external monitor and keyboard. The 
 result was the same--Mac boot menu frozen on the external display.
 
 Is there anything I should try to troubleshoot or debug this issue? 
 Anything else I should include in a PR? I can test patches if needed 
 (probably after building an image including the patch from a VM).
 
 To be clear, which boot menu do you see?  If you see the FreeBSD loader
 menu, escape to the loader prompt and try:
 
set kern.vty=vt
set hw.vga.textmode=1
boot
 
 I am a bit unclear under which conditions 'hw.vga.textmode=1' is
 required, though.
 No, I don't ever see the FreeBSD loader. I see the menu you get on a Mac 
 when you hold down the option (alt) key while booting--big disk icons 
 representing the bootable disks/partitions in the system. In my case it was 
 the Macintosh HD volume (Mac OS Mavericks), my Windows partition, and the 
 USB stick with the FreeBSD memstick image on it, which the Mac just called 
 EFI Boot (and the icon was that of a USB disk). There is also a little 
 section at the bottom that allows wifi network booting (if you've done all 
 the black magic (not PXE) to get that to happen). It shows a circular 
 activity animation while it scans for wireless networks. That animation 
 stops when I select the USB EFI icon and press enter (and that is the only 
 visual indication I get that I made a selection).
 
 To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI 
 shell like rEFIt on either your hard drive or a HFS formatted memory stick:
 1) Download the rEFIt installer from here: 
 http://downloads.sourceforge.net/project/refit/rEFIt/0.14/rEFIt-0.14.dmg?r=http%3A%2F%2Frefit.sourceforge.net%2Fts=1410181876use_mirror=optimate
 2) Open the downloaded file
 3) Run the following command from the terminal: sudo installer -pkg 
 /Volumes/rEFIt/rEFIt.mpkg -tgt /Volumes/memstick (in this example, I'm using 
 an HFS formatted memory stick).
 4) Run the command sudo /Volumes/memstick/efi/enable.sh
 5) When you reboot your Mac, when you hold down the alt key, choose rEFIt on 
 the startup menu. Then, choose the BOOTx64.efi from … option
 If everything now goes as it should, you should see the FreeBSD loader. When 
 the Press enter to boot or any other key to go to loader in X seconds (or 
 whatever it says), press a random key. Then try to type the commands 
 suggested by [Glen Barber].

Thanks all, made _some_ progress.

I installed rEFInd on my internal hard drive and now I can get to (and see!) 
the FreeBSD EFI loader. Unfortunately that's about as far as it gets. Once I 
tell the loader to boot it displays the EFI framebuffer information and then 
nothing else. This happens with 'kern.vty=vt' set and with or without 
'hw.vga.textmode=1'.

Screenshot here: https://blog.jnielsen.net/images/efiloader.jpg

What should the next troubleshooting steps be?

JN

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

UEFI display frozen on Retina MacBook Pro

[John Nielsen]

I have a MacBook Pro Retina, Mid 2012 (MacBookPro10,1) on which I'd like to 
be able to boot FreeBSD from an external USB drive. For testing I've been using 
the mini-memstick images from the -CURRENT snapshots, most recently the one 
from 20140903.

I am able to select EFI Boot on the USB device from the Mac's boot menu, and 
it does _something_, but the screen never changes--the image of the boot menu 
is displayed indefinitely. I think it is actually booting since there is drive 
activity and the caps lock key indicator starts working a few seconds in, but 
the screen just stays the same. Thinking the resolution of the Retina display 
may have been an issue, I tried booting with it disabled (lid closed) and an 
external monitor and keyboard. The result was the same--Mac boot menu frozen on 
the external display.

Is there anything I should try to troubleshoot or debug this issue? Anything 
else I should include in a PR? I can test patches if needed (probably after 
building an image including the patch from a VM).

Thanks,

JN

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

Re: UEFI display frozen on Retina MacBook Pro

[John Nielsen]

On Sep 5, 2014, at 11:30 AM, Glen Barber g...@freebsd.org wrote:

 On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote:
 I have a MacBook Pro Retina, Mid 2012 (MacBookPro10,1) on which I'd like 
 to be able to boot FreeBSD from an external USB drive. For testing I've been 
 using the mini-memstick images from the -CURRENT snapshots, most recently 
 the one from 20140903.
 
 I am able to select EFI Boot on the USB device from the Mac's boot menu, 
 and it does _something_, but the screen never changes--the image of the boot 
 menu is displayed indefinitely. I think it is actually booting since there 
 is drive activity and the caps lock key indicator starts working a few 
 seconds in, but the screen just stays the same. Thinking the resolution of 
 the Retina display may have been an issue, I tried booting with it disabled 
 (lid closed) and an external monitor and keyboard. The result was the 
 same--Mac boot menu frozen on the external display.
 
 Is there anything I should try to troubleshoot or debug this issue? Anything 
 else I should include in a PR? I can test patches if needed (probably after 
 building an image including the patch from a VM).
 
 
 To be clear, which boot menu do you see?  If you see the FreeBSD loader
 menu, escape to the loader prompt and try:
 
set kern.vty=vt
set hw.vga.textmode=1
boot
 
 I am a bit unclear under which conditions 'hw.vga.textmode=1' is
 required, though.

No, I don't ever see the FreeBSD loader. I see the menu you get on a Mac when 
you hold down the option (alt) key while booting--big disk icons representing 
the bootable disks/partitions in the system. In my case it was the Macintosh 
HD volume (Mac OS Mavericks), my Windows partition, and the USB stick with the 
FreeBSD memstick image on it, which the Mac just called EFI Boot (and the 
icon was that of a USB disk). There is also a little section at the bottom that 
allows wifi network booting (if you've done all the black magic (not PXE) to 
get that to happen). It shows a circular activity animation while it scans for 
wireless networks. That animation stops when I select the USB EFI icon and 
press enter (and that is the only visual indication I get that I made a 
selection).

JN

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

Re: Booting a SuperMicro Superserver

[John Nielsen]

On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com wrote:

 A continuing issue (with 9.1 previously and now 10) is that FreeBSD 
 occasionally (or always) seems to boot from the 2nd installed drive
 rather than the first. I'd be happy to debug this, but I have no idea if it's 
 bootcode or a BIOS issue. Supermicro pleads innocent, but their bios
 guys are hard to work with and fairly arrogant if you don't specifically 
 isolate something.
 
 The scenario occurs when ada0 is upgraded and has an incompatible kernel with 
 other code on drive ada1.  (note that ada1 is a backup of the pre-upgrade 
 ada0, so it's fstab points to ada0 for mount points). The system will boot 
 and then modules will fail to load. It loads the kernel from
  ada1 and then mounts partitions from ada0; old kernel and newer modules.
 
 The problem is resolved by popping the 2nd drive. So there is nothing wrong 
 with ada0 to cause it to bounce to ada1.
 
 My question: What would cause the system to boot from ada1 instead of ada0? 
 Bios or Bootcode?

BIOS, most likely. If the disk controller in question is onboard you should be 
able to specify which disk(s) and what order they will be booted from. If not, 
you'll need to just say disk controller in the BIOS boot order then go to the 
controllers BIOS to say which disk(s) to boot from and in what order. I have 
recent experience with a SuperMicro box and an LSI controller; the latter 
allows you to specify a (b)oot drive and an (a)lternate. Yes, b comes before a. 
:)

JN

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

Re: Booting a SuperMicro Superserver

[John Nielsen]

On Aug 12, 2014, at 12:09 PM, Barney Cordoba barney_cord...@yahoo.com wrote:

 On Tuesday, August 12, 2014 1:16 PM, John Nielsen li...@jnielsen.net wrote:
 
 On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com 
 wrote:
 
 A continuing issue (with 9.1 previously and now 10) is that FreeBSD 
 occasionally (or always) seems to boot from the 2nd installed drive rather 
 than the first. I'd be happy to debug this, but I have no idea if it's 
 bootcode or a BIOS issue. Supermicro pleads innocent, but their bios guys 
 are hard to work with and fairly arrogant if you don't specifically isolate 
 something.
 
 The scenario occurs when ada0 is upgraded and has an incompatible kernel 
 with other code on drive ada1.  (note that ada1 is a backup of the 
 pre-upgrade ada0, so it's fstab points to ada0 for mount points). The 
 system will boot and then modules will fail to load. It loads the kernel 
 from ada1 and then mounts partitions from ada0; old kernel and newer 
 modules.
 
 The problem is resolved by popping the 2nd drive. So there is nothing wrong 
 with ada0 to cause it to bounce to ada1.
 
 My question: What would cause the system to boot from ada1 instead of ada0? 
 Bios or Bootcode?
 
 BIOS, most likely. If the disk controller in question is onboard you should 
 be able to specify which disk(s) and what order they will be booted from. If 
 not, you'll need to just say disk controller in the BIOS boot order then 
 go to the controllers BIOS to say which disk(s) to boot from and in what 
 order. I have recent experience with a SuperMicro box and an LSI controller; 
 the latter allows you to specify a (b)oot drive and an (a)lternate. Yes, b 
 comes before a. :)
 
 The bios only gives you one choice for HDD. You can't select one of the 4 
 drives to boot from. You can specify USB or CD or HDD, but Not HDD2 or HDD3.

There may be a separate option controlling hard drive boot order, and/or 
there may be a completely separate BIOS program for your drive controller with 
its own hotkey.

JN

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

Re: [HEADSUP] pkg 1.3.0 alpha1: Breath of fresh air from Kirov

[John Nielsen]

Looks great! Thanks as always for the work. I do have one question (below).

On Mar 17, 2014, at 11:21 AM, Baptiste Daroussin b...@freebsd.org wrote:

 - Remove support for PACKAGESITE

There are two cases where I still define PACKAGESITE in the environment, 
specifically when building new jails or VM images. Can you suggest alternatives?

1. Installing/bootstrapping the latest pkg from a specific source. Often I 
build in an environment that is firewalled from the Internet at large but I 
have a local repo. (And it's nice to know exactly what version with which 
options I'm installing.)

2. Installing a package that includes a repo file for my local custom repo. 
This is a chicken-and-egg problem for which PACKAGESITE was a nice solution 
since there's no risk of a stale repo file being left behind--either the 
package is installed (with the correct/current repo file) or it isn't.

JN

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

Re: iSCSI boot ... root?

[John Nielsen]

On Sep 16, 2013, at 4:35 AM, Edward Tomasz Napierała tr...@freebsd.org wrote:

 Wiadomość napisana przez Zaphod Beeblebrox zbee...@gmail.com w dniu 16 wrz 
 2013, o godz. 07:35:
 Is it now possible to boot from iSCSI?  I'm not talking about an iSCSI
 controller, but with
 
 pxe - dhcp - tftp (loads loader) - (something) - boot (mounts root from
 iSCSI)
 
 Not yet.  The iSCSI initiator requires iscsid(8) in order to work, and you 
 can't
 run it before mounting root.
 
 I think the proper way to do this would be by doing something similar to 
 Linux'
 initrd; i.e. booting from mdroot loaded by loader(8), run iscsid(8) from 
 there,
 setup iSCSI session, then mount the real root and pivot to it.  I'm not sure 
 if it's
 possible right now.

I'm not sure to what extent trasz's work overlaps with this, but I was able to 
boot a FreeBSD 9.1 image via iSCSI using aoyama's isboot module. I used gPXE 
and UNDI since my BIOS and NIC don't have any iSCSI support, just vanilla PXE. 
I haven't heard anything about isboot lately but the links below are still 
active. Let me know if you'd like additional details.

JN

On Aug 23, 2012, at 6:25 PM, Daisuke Aoyama aoy...@peach.ne.jp wrote:
 Subject: Updated isboot 0.2.6 and FreeBSD 9.1-RC1
 Cc: freebsd-s...@freebsd.org, freebsd-sta...@freebsd.org
 
 I have updated isboot and created 9.1-RC based image.
 Please try it:
 
 http://www.peach.ne.jp/archives/isboot/isboot-0.2.6.tar.gz
 http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-9.1-RC1-amd64-memstick-isboot-0.2.6.img


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

Re: using ConnectX card as Ethernet (mlxen)

[John Nielsen]

On Jul 9, 2013, at 9:58 AM, John Baldwin j...@freebsd.org wrote:

 On Monday, September 24, 2012 12:37:30 pm John Nielsen wrote:
 I have a machine running FreeBSD 10.0-CURRENT #0 r240887 amd64 with two 
 ConnectX (InfiniBand) cards. Relevant bits of dmesg and pciconf -lv below. 
 The 
 cards are connected directly to a 10GB Ethernet switch so I need to run them 
 in eth mode rather than ib. Unfortunately they come up in ib mode and I 
 don't know how to change it.
 
 The same hardware works fine under CentOS 6.3, though I need to manually set 
 the cards to 'eth' there as well (which I do using a 'connectx_port_config 
 script from Mellanox that twiddles the mlx4_port1 entries under /sys (sysfs). 
 Under FreeBSD I see these sysctls but I can't set them to 'eth' either via 
 /boot/loader.conf or by sysctl after boot, with or without mlxen and/or 
 mlx4ib 
 loaded:
 sys.device.mlx4_core0.mlx4_port1: ib
 sys.device.mlx4_core1.mlx4_port1: ib
 
 So this was just fixed (finally) in HEAD in r253048.  You can how use the
 sysctls to change this.

I saw the commit. Thanks! I'll give it a try at some point (whenever my 
schedule and hardware availability align).

JN

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

Re: request for your comments on release documentation

[John Nielsen]

On Jun 12, 2013, at 11:49 AM, Hiroki Sato h...@freebsd.org wrote:

 I would like your comments on release notes for each release.
 Although I have been working on editing them for years, the workflow
 is still not optimal and sometimes delay of the preparation became an
 obstacle for release process.  I would like to improve it, but before
 that I would like to know what are desired of the contents which
 people think.
 
 Release Notes is just listing the changes between the two releases.
 It includes user-visible change (bugfix and/or UI change), new
 functionality, and performance improvement.  Minor changes such as
 one in kernel internal structure are omitted.  I always try to keep
 these series of relnotes items are correct and reasonably
 comprehensive, but this lengthy list may be boring and
 technically-correct descriptions can be cryptic for average users.
 
 So, my questions are:
 
 1. What do you think about current granularity of the relnotes items?
Too detailed, good, or too rough?  Currently, judgment of what is
included or not is based on user-visible, new functionality, or
performance improvement.  Applicable changes are included as
relnotes items even if the changes are small,

I think the current granularity is good.

 2. Do you want technical details?  For example, just disk access
performance was improved by 50% or Feature A has been added.
This changes the old behavior because ..., and as a result, it
improves disk access performance by 50%.

I want technical details. You could compromise here by trying to always have 
the non-technical end result in the first sentence or so, and then go on with a 
more technical explanation.

I would echo Mark Felder and say that if in doubt, more detail is better.

 3. Is there missing information which should be in the relnotes?
Probably there are some missing items for each release, but this
question is one at some abstraction level.  Link to commit log and
diff, detailed description of major incompatible changes, and so
on.

I've not ever noticed any. Thanks!

I'm on the SVN mailing lists so I tend to know about or be able to find changes 
I care about independent of the release notes. However if there is a 
mostly-automated way to link to specific commits in the release notes that 
could be valuable.

 Although the other release documentations---Errata, Installation
 Notes, ReadMe, and Hardware Notes---also need some improvements,
 please focus on Release Notes only.  And you might think quality of
 English writing are not good, please leave that alone for now.

I've never noticed any language problems in the release notes, and I tend to be 
a stickler. :)

JN

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

using ConnectX card as Ethernet (mlxen)

[John Nielsen]

I have a machine running FreeBSD 10.0-CURRENT #0 r240887 amd64 with two 
ConnectX (InfiniBand) cards. Relevant bits of dmesg and pciconf -lv below. The 
cards are connected directly to a 10GB Ethernet switch so I need to run them in 
eth mode rather than ib. Unfortunately they come up in ib mode and I 
don't know how to change it.

The same hardware works fine under CentOS 6.3, though I need to manually set 
the cards to 'eth' there as well (which I do using a 'connectx_port_config 
script from Mellanox that twiddles the mlx4_port1 entries under /sys (sysfs). 
Under FreeBSD I see these sysctls but I can't set them to 'eth' either via 
/boot/loader.conf or by sysctl after boot, with or without mlxen and/or mlx4ib 
loaded:
sys.device.mlx4_core0.mlx4_port1: ib
sys.device.mlx4_core1.mlx4_port1: ib

Assuming mlxen is actually supported, how do I configure the card so it will 
attach?


mlx4_core0: mlx4_core mem 0xdfa0-0xdfaf,0xdd80-0xddff irq 32 
at device 0.0 on pci4
mlx4_core: Mellanox ConnectX core driver v1.0-ofed1.5.2 (August 4, 2010)
mlx4_core: Initializing mlx4_core
mlx4_en: Mellanox ConnectX HCA Ethernet driver v1.5.2 (July 2010)
mlx4_en mlx4_core0: UDP RSS is not supported on this device.
mlx4_core1: mlx4_core mem 0xdf90-0xdf9f,0xdd00-0xdd7f irq 42 
at device 0.0 on pci7
mlx4_core: Initializing mlx4_core

mlx4_core0@pci0:4:0:0:  class=0x0c0600 card=0x002215b3 chip=0x673c15b3 rev=0xb0 
hdr=0x00
vendor = 'Mellanox Technologies'
device = 'MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE]'
class  = serial bus
mlx4_core1@pci0:7:0:0:  class=0x028000 card=0x001715b3 chip=0x100315b3 rev=0x00 
hdr=0x00
vendor = 'Mellanox Technologies'
device = 'MT27500 Family [ConnectX-3]'
class  = network

Thanks,

JN

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

Re: Script to set/unset automatic status in PKGNG database

[John Nielsen]

On Aug 30, 2012, at 11:56 PM, Matthew Seaman matt...@freebsd.org wrote:

 On 30/08/2012 22:44, John Nielsen wrote:
 After dialog(1) exits the script has a list of packages to mark as
 automatic. Is there a non-SQL way to efficiently get the inverse?
 I.e. the set { all_packages - new_automatic_package_list } ?
 
 Use pkg query - it is really quite powerful.  This shows all
 non-autoremove packages as name-version:
 
 pkg query -e '%a == 0' '%n-%v'
 
 and this shows the port origin for all autoremove packages:
 
 pkg query -e '%a == 1' '%o'

Thanks. I know about pkg query (and in fact my script uses something very much 
like that to get the initial list of automatic packages). What I was trying to 
do was get a list of packages installed but not in another list. The other list 
represents _future_ automatic packages but not necessarily what is in the 
database now.

In any case, I worked around it but first unsetting all packages and then 
setting the user-selected list back to automatic.

JN

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

Re: pkg (aka pkgng) 1.0 released

[John Nielsen]

Thanks to everyone involved.

I've been lightly testing pkg for a little while, but I still mainly use ports. 
This announcement prompted me to switch from portupgrade to portupgrade-devel 
(20120827 version) to see how it works with PKGNG. I encountered a couple 
issues:

Portupgrade doesn't remove the pkgdb.db.lock reliably.
Portupgrade doesn't handle stale lock files (just waits indefinitely for a 
nonexistent process to finish). A big problem when combined with the above.
Running portupgrade pkg failed. It stalled trying to unregister the package 
installation after the old pkg was removed. I didn't dig too deeply but it 
seems like a dependency chicken-and-egg problem.

I was able to reinstall using /usr/sbin/pkg, and I also tested make  make 
deinstall  make reinstall of ports-mgmt/pkg successfully, so it may just be 
a portupgrade issue.

JN

On Aug 30, 2012, at 8:19 AM, Baptiste Daroussin b...@freebsd.org wrote:

 After 2 years of development (first commit Tue Sep 7 2010), more than 2000
 commits, 43 different contibutors.  The pkgng team is proud to release 
 pkg-1.0!
 
 [...]
 
 Tools supporting natively pkgng
  - ports-mgmt/portupgrade-devel (soon the main portupgrade will support)
 [...]

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

Re: pkg (aka pkgng) 1.0 released

[John Nielsen]

On Aug 30, 2012, at 9:43 AM, John Nielsen li...@jnielsen.net wrote:

 Thanks to everyone involved.
 
 I've been lightly testing pkg for a little while, but I still mainly use 
 ports. This announcement prompted me to switch from portupgrade to 
 portupgrade-devel (20120827 version) to see how it works with PKGNG. I 
 encountered a couple issues:
 
 Portupgrade doesn't remove the pkgdb.db.lock reliably.
 Portupgrade doesn't handle stale lock files (just waits indefinitely for a 
 nonexistent process to finish). A big problem when combined with the above.
 Running portupgrade pkg failed. It stalled trying to unregister the package 
 installation after the old pkg was removed. I didn't dig too deeply but it 
 seems like a dependency chicken-and-egg problem.

I tried this again so I could provide some more details. This is what shows in 
the terminal when it stalls:
---  Backing up the old version
---  Uninstalling the old version
USING PKGNG
---  Deinstalling 'pkg-1.0'
---  Preserving /usr/local/lib/libpkg.so.0 as 
/usr/local/lib/compat/pkg/libpkg.so.0
The following packages will be deinstalled:

pkg-1.0

The deinstallation will free 7 MB
Deleting pkg-1.0... done
[Updating the pkgdb format:bdb_btree in /var/db/pkg ... 

Running ps in another terminal shows pkg query %n-%v. Since the actual pkg is 
now gone, I suspect this is really /usr/sbin/pkg. I further suspect that it's 
waiting for y/n input (whether to install the binary pkg) on its nonexistent 
stdin somewhere. I killed it (pkg) and portupgrade seemed to finish normally.

 I was able to reinstall using /usr/sbin/pkg, and I also tested make  make 
 deinstall  make reinstall of ports-mgmt/pkg successfully, so it may just 
 be a portupgrade issue.
 
 JN
 
 On Aug 30, 2012, at 8:19 AM, Baptiste Daroussin b...@freebsd.org wrote:
 
 After 2 years of development (first commit Tue Sep 7 2010), more than 2000
 commits, 43 different contibutors.  The pkgng team is proud to release 
 pkg-1.0!
 
 [...]
 
 Tools supporting natively pkgng
 - ports-mgmt/portupgrade-devel (soon the main portupgrade will support)
 [...]
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 

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

Re: pkg (aka pkgng) 1.0 released

[John Nielsen]

On Aug 30, 2012, at 10:06 AM, Olivier Smedts oliv...@gid0.org wrote:

 2012/8/30 John Nielsen li...@jnielsen.net:
 Running ps in another terminal shows pkg query %n-%v. Since the actual pkg 
 is now gone, I suspect this is really /usr/sbin/pkg. I further suspect that 
 it's waiting for y/n input (whether to install the binary pkg) on its 
 nonexistent stdin somewhere. I killed it (pkg) and portupgrade seemed to 
 finish normally.
 
 This is the first example where renaming pkg to pkg-bootstrap would
 have been useful.

I think this is a bug in portupgrade, but removing /usr/sbin/pkg does have the 
side effect of allowing portupgrade to continue (with an empty pkgdb briefly):

Deleting pkg-1.0... done
[Updating the pkgdb format:bdb_btree in /var/db/pkg ... pkg: not found
- 0 packages found (-163 +0)  nothing to do]
---  Installing the new version via the port
...
===   Registering installation for pkg-1.0
Installing pkg-1.0... done
===  Cleaning for pkg-1.0
[Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 163 packages found 
(-0 +163) 
100...
 done]


JN

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

Script to set/unset automatic status in PKGNG database

[John Nielsen]

I today noticed the pkg autoremove command for the first time, which does 
much the same thing as pkg_cutleaves but relies on the automatic flag in the 
pkgng database rather than user input to determine which leaf ports can be 
removed. Unfortunately, the pkg2ng utility has no way of knowing which 
old-style packages it converts were installed automatically as dependencies, so 
they are all marked as non-automatic (i.e. user-requested). In my case, this 
was not true for the majority of installed ports. Since I really like this 
functionality, I decided to update my local package database to match my 
preferences.

Having succeeded, I decided a tool to make doing so easy could well benefit 
others (as well as my future self). (Plus I wanted an excuse to play with 
dialog(1) and pkg query a bit.) So here's the result. I'm not too attached to 
the name. It shouldn't eat your package database or steal your lunch money, but 
I'm not responsible if it does. Other than that, feedback is welcome.


JN
#!/bin/sh

# Copyright (c) 2012 John Nielsen j...@jnielsen.net

# This script presents a checklist of all PKGNG packages registered on
# the system, showing for each whether or not it is marked as automatic
# (i.e. not explicitly requested by the user). Any changes are recorded
# in the PKGNG database. I wrote it to make pkg autoremove useful
# following a pkg2ng migration, but other uses are conceivable.

# The PKGNG database file to use
DB=/var/db/pkg/local.sqlite

# Terminal geometry
sz=`stty size`
rows=`echo ${sz} | cut -d ' ' -f 1`
cols=`echo ${sz} | cut -d ' ' -f 2`
drows=$(( ${rows} - 3 ))
dcols=$(( ${cols} - 6 ))

# Dialog results are stored here
tmpfile=`mktemp -t set_pkg_auto`

# We always want the same style checklist
export DIALOGOPTS=--extra-button --extra-label \Select All\ --cancel-label 
\Deselect All\ --help-button --help-label Exit --separator ,

# Exit with an error message
die() {
rm -f ${tmpfile}
echo ${1}
exit 1
}

# Don't leave tmpfile behind even if we are killed/interrupted
trap die \Interrupt received.\ 2 15

# Run dialog to present the checklist and save the results in tmpfile
run_dialog() {
dialog --checklist Select packages to consider for auto-removal 
${drows} ${dcols} ${drows} $* 2${tmpfile}
return $?
}

# Show the current status from the package database in the checklist
select_current() {
run_dialog `pkg query '%n %o %a' | sed -e 's/1$/on/g' -e 's/0$/off/g'`
return $?
}

# Select all packages in the checklist
select_all() {
run_dialog `pkg query '%n %o' | sed -e 's/$/ on/g'`
return $?
}

# De-select all packages in the checklist
select_none() {
run_dialog `pkg query '%n %o' | sed -e 's/$/ off/g'`
return $?
}

# Update the package database to match selections in the specified file
do_update() {
autopkgs=`sed -e s/^,//g -e s/\/'/g ${1}`
sqlite3 ${DB} update packages set automatic=1 where name in 
(${autopkgs}); \
|| die SQlite error.
sqlite3 ${DB} update packages set automatic=0 where name not in 
(${autopkgs}); \
|| die SQlite error.
}

# Run select_current for the first checklist
pkgset=current

# Show the checklist until OK or Exit is selected
while : ; do
select_${pkgset}
case $? in
0) # OK, continue with updates
break;
;;
3) # Extra (Select all), show the checklist again
pkgset=all
;;
1) # Cancel (Deselect all), show the checklist again
pkgset=none
;;
*) # 4-Help (Exit) or ESC or error, exit.
die No changes made.
;;
esac
done

# If we got this far then tmpfile has a list of 'automatic' packages
do_update ${tmpfile}

# Clean up
rm -f ${tmpfile}
echo Updated successfully.


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

Re: Script to set/unset automatic status in PKGNG database

[John Nielsen]

On Aug 30, 2012, at 3:29 PM, Julien Laffaye jlaff...@freebsd.org wrote:

 On 8/30/2012 11:19 PM, John Nielsen wrote:
 I today noticed the pkg autoremove command for the first time, which does 
 much the same thing as pkg_cutleaves but relies on the automatic flag in 
 the pkgng database rather than user input to determine which leaf ports 
 can be removed. Unfortunately, the pkg2ng utility has no way of knowing 
 which old-style packages it converts were installed automatically as 
 dependencies, so they are all marked as non-automatic (i.e. user-requested). 
 In my case, this was not true for the majority of installed ports. Since I 
 really like this functionality, I decided to update my local package 
 database to match my preferences.
 
 Having succeeded, I decided a tool to make doing so easy could well benefit 
 others (as well as my future self). (Plus I wanted an excuse to play with 
 dialog(1) and pkg query a bit.) So here's the result. I'm not too attached 
 to the name. It shouldn't eat your package database or steal your lunch 
 money, but I'm not responsible if it does. Other than that, feedback is 
 welcome.
 
 You want to use `pkg set -A` :)
 We make zero promises concerning the SQL schema in pkgng so it can change at 
 every time and break your script.

Thanks. I looked for something like that but not hard enough obviously. I'll 
change it.

After dialog(1) exits the script has a list of packages to mark as automatic. 
Is there a non-SQL way to efficiently get the inverse? I.e. the set { 
all_packages - new_automatic_package_list } ?

JN

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

Re: Script to set/unset automatic status in PKGNG database

[John Nielsen]

On Aug 30, 2012, at 3:28 PM, Baptiste Daroussin b...@freebsd.org wrote:

 On Thu, Aug 30, 2012 at 03:19:59PM -0600, John Nielsen wrote:
 I today noticed the pkg autoremove command for the first time, which does 
 much the same thing as pkg_cutleaves but relies on the automatic flag in 
 the pkgng database rather than user input to determine which leaf ports 
 can be removed. Unfortunately, the pkg2ng utility has no way of knowing 
 which old-style packages it converts were installed automatically as 
 dependencies, so they are all marked as non-automatic (i.e. user-requested). 
 In my case, this was not true for the majority of installed ports. Since I 
 really like this functionality, I decided to update my local package 
 database to match my preferences.
 
 Having succeeded, I decided a tool to make doing so easy could well benefit 
 others (as well as my future self). (Plus I wanted an excuse to play with 
 dialog(1) and pkg query a bit.) So here's the result. I'm not too attached 
 to the name. It shouldn't eat your package database or steal your lunch 
 money, but I'm not responsible if it does. Other than that, feedback is 
 welcome.
 
 Would you mind adding create a patch against the git tree of pkgng so that we
 can include your script into the scripts subdirectory, so that we provide your
 script along with the next pkg 1.0.1 as a contributed script?

No problem. Attached is the output of git diff origin after dropping my 
script in to my local tree. Let me know if you need something else.

Changes between this and the version I originally posted:
Added 2-clause license and disclaimer
Replaced SQL with 'pkg set' commands. Since I didn't come up with a 
fast way to list the packages not in the 'automatic' list, I first set all 
packages to 0 (not automatic), then set the ones in the list to 1. This is 
likely slower than the SQL variant was, but it's not bad and not something 
likely to be run frequently.

JN


set_pkg_auto.sh.diff
Description: Binary data


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

Re: Script to set/unset automatic status in PKGNG database

[John Nielsen]

On Aug 30, 2012, at 4:40 PM, Baptiste Daroussin b...@freebsd.org wrote:

 Thanks you should be enough, can you provide a git format-patch patch so that
 you get your name in the logs :D

Here you go.



0001-Add-script-to-interactively-set-un-set-automatic-sta.patch
Description: Binary data


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

Re: jemalloc: Conf string ends with key

[John Nielsen]

On Apr 17, 2012, at 8:58 AM, O. Hartmann wrote:

 On 04/17/12 14:51, Ivan Klymenko wrote:
 В Tue, 17 Apr 2012 10:42:13 +0200
 O. Hartmann ohart...@mail.zedat.fu-berlin.de пишет:
 
 Having just built world on 10.0-CURRENT FreeBSD 10.0-CURRENT #0
 r234370: Tue Apr 17 10:17:46 CEST 2012, gives me now a flooding of
 
 jemalloc: Conf string ends with key
 
 on console, screens, xterms with almost everything I touch. If those
 messages, which I believe are surely necessary, could be focused on
 the console and not bothering xterms, editors etc., would be nice and
 polite and would make the work even with a development branch more
 convenient ... ;-)
 
 What's up? How to avoid this message flooding?
 
 remove /etc/malloc.conf
 
 simple and efficient ;-)

I encountered this today as well. I set /etc/malloc.conf a long time ago and 
haven't thought about it much since. The new options format is documented in 
jemalloc(3), but I for one would have appreciated a heads-up of some sort. 
Should this be an entry in UPDATING?

JN

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

Re: Python won't build?

[John Nielsen]

Quoting John Nielsen li...@jnielsen.net:


On Mar 31, 2012, at 10:21 PM, John Nielsen wrote:

I updated a machine yesterday from 9-STABLE to 10-CURRENT  
(r233631). Everything went smoothly with the update itself, but I  
ran in to an issue with Python when rebuilding all of my installed  
ports. Python won't build; it complains about the definition of  
LONG_BIT. I had python27 installed but python26 does the same  
thing. I ran make delete-old and make delete-old-libs, no  
improvement. I even built a clean chroot environment via make  
installworld DESTDIR=..., (plus devfs and ports tree). Same problem.


So.. is this the result of something in the FreeBSD source? Can  
anyone else reproduce this? What should I try next?


So, no chorus of me toos. How about a works for me? I'm still  
not sure if this is something peculiar to this machine or not and I  
haven't fired up a clean virtual machine on different hardware to  
verify (though I'm not far from that...).


Some of my own follow up:

I tried rebuilding world with sources from today, 3/9 and 2/28 and  
got the same result, so if it's a regression on the FreeBSD end it's  
been there a while (and seemingly not related to the i386/amd64/x86  
header cleanup, which led me to pick those revisions). I also tried  
setting tweaking newvers.sh to say 9.9-CURRENT and rebuilt world  
with no improvement, so if it's autotools or something else versus  
two-digit FreeBSD version problem it's something subtle.


I'm still mystified but I'm no longer having an issue. I rebuilt world  
from today's sources and lo and behold, Python builds again. If anyone  
knows what might have changed I'd still love to know, but otherwise I  
guess I'll move on.


JN

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

Re: Python won't build?

[John Nielsen]

On Mar 31, 2012, at 10:21 PM, John Nielsen wrote:

 I updated a machine yesterday from 9-STABLE to 10-CURRENT (r233631). 
 Everything went smoothly with the update itself, but I ran in to an issue 
 with Python when rebuilding all of my installed ports. Python won't build; it 
 complains about the definition of LONG_BIT. I had python27 installed but 
 python26 does the same thing. I ran make delete-old and make 
 delete-old-libs, no improvement. I even built a clean chroot environment via 
 make installworld DESTDIR=..., (plus devfs and ports tree). Same problem.
 
 So.. is this the result of something in the FreeBSD source? Can anyone else 
 reproduce this? What should I try next?

So, no chorus of me toos. How about a works for me? I'm still not sure if 
this is something peculiar to this machine or not and I haven't fired up a 
clean virtual machine on different hardware to verify (though I'm not far from 
that...).

Some of my own follow up:

I tried rebuilding world with sources from today, 3/9 and 2/28 and got the same 
result, so if it's a regression on the FreeBSD end it's been there a while (and 
seemingly not related to the i386/amd64/x86 header cleanup, which led me to 
pick those revisions). I also tried setting tweaking newvers.sh to say 
9.9-CURRENT and rebuilt world with no improvement, so if it's autotools or 
something else versus two-digit FreeBSD version problem it's something subtle.

Looking in to the Python code, this block is what throws the error:

/* from python27/work/Python-2.7.2/Include/pyport.h */
#ifndef LONG_BIT
#define LONG_BIT (8 * SIZEOF_LONG)
#endif

#if LONG_BIT != 8 * SIZEOF_LONG
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent
 * 32-bit platforms using gcc.  We try to catch that here at compile-time
 * rather than waiting for integer multiplication to trigger bogus
 * overflows.
 */
#error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?).
#endif

It turns out the problem is not the one mentioned in the comment (bogus 
definition of LONG_BIT), but rather that SIZEOF_LONG is never defined. 
Comparing with another amd64 system running 9-STABLE, it looks like that ought 
to be defined during the configure step and end up in 
work/Python-2.7.2/portbld.shared/pyconfig.h. That is not happening on the 
maching running -CURRENT--pyconfig.h doesn't get created in the portbld.shared 
directory. It does exist in portbld.static (and on the well-behaving -STABLE 
machine the two are identical), so I copied it over. That lets the first stage 
of the build mostly finish but it fails linking the 'python' binary:

cc -c -fno-strict-aliasing -O2 -pipe -march=athlon64  -fno-strict-aliasing 
-DNDEBUG -O2 -pipe -march=athlon64  -fno-strict-aliasing  -I. -IInclude 
-I./../Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ./../Modules/python.c
cc -pthread -Wl,--export-dynamic -o python  Modules/python.o  -L. -lpython2.7 
-lutil   -lm  
./libpython2.7.so: undefined reference to `_PyImport_Inittab'
*** [python] Error code 1

Stop in /opt/scratch/opt/ports/lang/python27/work/Python-2.7.2/portbld.shared.
*** [pre-build] Error code 1


So there is something going on besides just the header file not being created. 
Does anyone have any ideas what it could be? I'm willing to believe this is a 
Python problem but I'd still like to know what changed on my end to uncover it 
before pursuing help from the Python folks.

 cc -c -fno-strict-aliasing -O2 -pipe -march=athlon64  -fno-strict-aliasing 
 -DNDEBUG -O2 -pipe -march=athlon64  -fno-strict-aliasing  -I. -IInclude 
 -I./../Include -fPIC -DPy_BUILD_CORE -o Parser/acceler.o ./../Parser/acceler.c
 ...
 In file included from ./../Include/Python.h:58,
 from ./../Include/pgenheaders.h:10,
 from ./../Parser/acceler.c:13:
 ./../Include/pyport.h:849:2: error: #error LONG_BIT definition appears wrong 
 for platform (bad gcc/glibc config?).
 ...
 Stop in /opt/scratch/opt/ports/lang/python27/work/Python-2.7.2/portbld.shared.
 *** [pre-build] Error code 1

Thanks,

JN

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

Python won't build?

[John Nielsen]

I updated a machine yesterday from 9-STABLE to 10-CURRENT (r233631). Everything 
went smoothly with the update itself, but I ran in to an issue with Python when 
rebuilding all of my installed ports. Python won't build; it complains about 
the definition of LONG_BIT. I had python27 installed but python26 does the same 
thing. I ran make delete-old and make delete-old-libs, no improvement. I 
even built a clean chroot environment via make installworld DESTDIR=..., (plus 
devfs and ports tree). Same problem.

So.. is this the result of something in the FreeBSD source? Can anyone else 
reproduce this? What should I try next?


cc -c -fno-strict-aliasing -O2 -pipe -march=athlon64  -fno-strict-aliasing 
-DNDEBUG -O2 -pipe -march=athlon64  -fno-strict-aliasing  -I. -IInclude 
-I./../Include -fPIC -DPy_BUILD_CORE -o Parser/acceler.o ./../Parser/acceler.c
In file included from ./../Include/Python.h:8,
 from ./../Include/pgenheaders.h:10,
 from ./../Parser/acceler.c:13:
./pyconfig.h:1:1: warning: null character(s) ignored
./pyconfig.h:1:35803: warning: no newline at end of file
In file included from ./../Include/pyport.h:4,
 from ./../Include/Python.h:58,
 from ./../Include/pgenheaders.h:10,
 from ./../Parser/acceler.c:13:
./pyconfig.h:1:1: warning: null character(s) ignored
./pyconfig.h:1:35803: warning: no newline at end of file
In file included from ./../Include/Python.h:58,
 from ./../Include/pgenheaders.h:10,
 from ./../Parser/acceler.c:13:
./../Include/pyport.h:849:2: error: #error LONG_BIT definition appears wrong 
for platform (bad gcc/glibc config?).
In file included from ./../Include/pymath.h:4,
 from ./../Include/Python.h:77,
 from ./../Include/pgenheaders.h:10,
 from ./../Parser/acceler.c:13:
./pyconfig.h:1:1: warning: null character(s) ignored
./pyconfig.h:1:35803: warning: no newline at end of file
*** [Parser/acceler.o] Error code 1

Stop in /opt/scratch/opt/ports/lang/python27/work/Python-2.7.2/portbld.shared.
*** [pre-build] Error code 1

Stop in /opt/ports/lang/python27.
*** [build] Error code 1

Stop in /opt/ports/lang/python27.

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

Re: loader crash / BTX halted on 9.0-RC2 DVD with AMD pseudo-RAID

[John Nielsen]

On Nov 22, 2011, at 10:26 AM, John Baldwin j...@freebsd.org wrote:

 On Monday, November 21, 2011 1:45:36 pm John Nielsen wrote:
 This weekend I downloaded the Freebsd 9.0 RC2 amd64 ISO image and burned it 
 to a DVD. I have a computer that currently runs Windows 7 but I plan to 
 install FreeBSD on it in the near future so I booted it up from the DVD to 
 check the hardware/driver status. Much to my dismay, the boot loader crashed 
 right away (register dump followed by BTX halted) and the computer 
 immediately rebooted. I took a video with my phone so I could capture the 
 crash message, screenshot here:
 
 http://picpaste.com/pics/BTXcrash.1321899682.jpg
 
 I then tried tweaking a few BIOS settings and found that turning off the 
 built-in pseudo-RAID allowed the DVD to boot normally. I changed the SATA 
 type 
 from RAID to AHCI. Fortunately I plan to use the controller in AHCI mode 
 for the FreeBSD installation so this won't end up being a problem for me, but 
 I still thought it was worth reporting.
 
 Hmmm, so this is odd.  It died with an Invalid TSS exception on the iret 
 instruction at the end of the return-from-real-mode trampoline in BTX.  
 Looking at the dump I noticed that PSL_NT is set in %eflags, so for some 
 reason the iret was trying to do a nested task return.  We shouldn't let
 that flag leak out of any real mode code.  Try this patch perhaps:

Thanks for looking!

I put gptboot on a USB stick and tried it with and without the patch. Identical 
behavior in both cases to booting from the DVD (only faster)--BTX dump and an 
instant reboot. I didn't do a screen capture yet but will be happy to tomorrow 
if it will help.

JN

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

loader crash / BTX halted on 9.0-RC2 DVD with AMD pseudo-RAID

[John Nielsen]

This weekend I downloaded the Freebsd 9.0 RC2 amd64 ISO image and burned it to 
a DVD. I have a computer that currently runs Windows 7 but I plan to install 
FreeBSD on it in the near future so I booted it up from the DVD to check the 
hardware/driver status. Much to my dismay, the boot loader crashed right away 
(register dump followed by BTX halted) and the computer immediately rebooted. 
I took a video with my phone so I could capture the crash message, screenshot 
here:

http://picpaste.com/pics/BTXcrash.1321899682.jpg

I then tried tweaking a few BIOS settings and found that turning off the 
built-in pseudo-RAID allowed the DVD to boot normally. I changed the SATA type 
from RAID to AHCI. Fortunately I plan to use the controller in AHCI mode 
for the FreeBSD installation so this won't end up being a problem for me, but I 
still thought it was worth reporting.

The system in question has a Foxconn A7GM-S motherboard with AMD 780G (NB) and 
AMD SB700 chipsets. I have a two-disk mirror for the Windows installation which 
is why I had RAID mode enabled in the first place.

In case jhb^H^H^Hsomeone is interested, below is the output from dmesg and 
pciconf -lv once I booted up in AHCI mode. Let me know if any additional 
information or tests would be helpful. Thanks!

JN


=== dmesg ===
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-RC2 #0: Sat Nov 12 18:35:25 UTC 2011
r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2767.66-MHz K8-class CPU)
  Origin = AuthenticAMD  Id = 0x60fb2  Family = f  Model = 6b  Stepping = 2
  
Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
  Features2=0x2001SSE3,CX16
  AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!
  AMD Features2=0x11fLAHF,CMP,SVM,ExtAPIC,CR8,Prefetch
real memory  = 8589934592 (8192 MB)
avail memory = 7711911936 (7354 MB)
Event timer LAPIC quality 400
ACPI APIC Table: 050410 APIC1120
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 
0x/0x1 (20110527/tbfadt-586)
ioapic0 Version 2.1 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: 050410 RSDT1120 on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of fee0, 1000 (3) failed
acpi0: reservation of ffb8, 8 (3) failed
acpi0: reservation of fec1, 20 (3) failed
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, bfe0 (3) failed
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0xc000-0xc0ff mem 
0xc000-0xcfff,0xfe9f-0xfe9f,0xfe80-0xfe8f irq 18 at 
device 5.0 on pci1
hdac0: ATI RS780 High Definition Audio Controller mem 0xfe9e8000-0xfe9ebfff 
irq 19 at device 5.1 on pci1
pcib2: ACPI PCI-PCI bridge irq 18 at device 2.0 on pci0
pci2: ACPI PCI bus on pcib2
vgapci1: VGA-compatible display port 0xd000-0xd0ff mem 
0xd000-0xdfff,0xfeaf-0xfeaf irq 18 at device 0.0 on pci2
hdac1: ATI RV770 High Definition Audio Controller mem 0xfeaec000-0xfeae 
irq 19 at device 0.1 on pci2
pcib3: ACPI PCI-PCI bridge irq 17 at device 9.0 on pci0
pci3: ACPI PCI bus on pcib3
re0: RealTek 8168/8111 B/C/CP/D/DP/E PCIe Gigabit Ethernet port 0xe800-0xe8ff 
mem 0xfebff000-0xfebf irq 17 at device 0.0 on pci3
re0: Using 1 MSI message
re0: Chip rev. 0x3800
re0: MAC rev. 0x0040
miibus0: MII bus on re0
rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, 
auto-flow
re0: Ethernet address: 00:1f:e2:55:1d:bc
ahci0: ATI IXP700 AHCI SATA controller port 
0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 
0xfe7ff800-0xfe7ffbff irq 22 at device 17.0 on pci0
ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported
ahcich0: AHCI channel at channel 0 on ahci0
ahcich1: AHCI channel at channel 1 on ahci0
ahcich2: AHCI channel at channel 2 on ahci0
ahcich3: AHCI channel at channel 3 on ahci0
ohci0: OHCI (generic) USB controller mem 0xfe7fe000-0xfe7fefff irq 16 at 
device 18.0 on pci0
usbus0: OHCI (generic) USB controller on ohci0
ohci1: 

Re: build flags for a 386DX (5.1)

[John Nielsen]

On Saturday 14 June 2003 10:32, Doug White wrote:
 On Fri, 13 Jun 2003, John Nielsen wrote:
  As I indicated, my only hangup is that I'm not familiar enough with the
  new GCC 3 build procedures to know where to put the -march and/or -mcpu
  flags for a buildworld on a separate (newer) machine.

 CPUTYPE=yatta in make.conf.  See /etc/defaults/make.conf :)

Thank you (and thanks DES!), that's what I needed.  I actually looked for 
/etc/defaults/make.conf, but it doesn't exist on any of my 5.1 systems that 
were installed from scratch.  Now that I look around, though, I see that 
there is an extensive make.conf(5) manpage, as well as 
share/examples/etc/make.conf.  Live and learn, I guess.

Thanks again,

JN

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: build flags for a 386DX (5.1)

[John Nielsen]

On Friday 13 June 2003 15:02, Kris Kennaway wrote:
 On Fri, Jun 13, 2003 at 12:44:06PM -0700, Doug White wrote:
  On Thu, 12 Jun 2003, John Nielsen wrote:
   [escalated from -questions]
  
   Hi folks-
  
   I am setting up FreeBSD 5.1-RELEASE on a 386DX.
 
  That works? 386 is not a supported CPU on 5.X.  It is missing atomic
  operations that is necesary for proper operation of threading.

 It is if you compile your own kernel, it's just not supported by
 default.

Yup, it's working fine.  I replaced the kernel on the boot floppy with one I 
had built for the occasion (with 'cpu I386_CPU' and 'options 
GPL_MATH_EMULATE').

As I indicated, my only hangup is that I'm not familiar enough with the new 
GCC 3 build procedures to know where to put the -march and/or -mcpu flags 
for a buildworld on a separate (newer) machine.

JN

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

build flags for a 386DX (5.1)

[John Nielsen]

[escalated from -questions]

Hi folks-

I am setting up FreeBSD 5.1-RELEASE on a 386DX.  I'm mostly doing it as a 
learning exercise (or perhaps because I'm a masochist), but the machine may 
be used as a firewall at some point.  I have the OS installed with a custom 
kernel, and things are actually going quite well.

There are (of course) some problems though.  Most of the userland utilities 
work great, but some just dump core.  The one I miss in particular is groff 
(for manpages, etc).  I suspect that the problems are a result of CPU 
instructions that the poor 386 doesn't understand.

I do have a separate build machine (soon to be running 5.1 as well), so I'd 
like to recompile everything (kernel, world, and 
ports-to-be-made-into-packages) for the 386 with the appropriate flags to 
gcc and friends.  Hopefully that will take care of the issues I'm seeing.

So my question is, what flags should I use and where should I put them?  I'd 
like to be able to switch easily between builds for the 386 and normal 
builds (for everything else).  Can I just put an override in /etc/make.conf 
or do I have to futz with /usr/share/mk/bsd.cpu.mk?  (In the case of the 
latter, detailed hints would be appreciated.. I don't grok Make all that 
well yet.)

Thanks,

JN

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

dhclient script in rc.d doesn't use ${dhcp_program} (conf/53007)

[John Nielsen]

Hi folks-

I'm happily using 5.1 and it's terrific.  Keep up the great work.

I just submitted a PR for a bug I noticed in the dhclient script.  Namely, 
it ignores the setting of dhcp_program from rc.conf.  A one-line fix did 
the trick for me, although there may be ramifications I'm not aware of.

The PR is conf/53007.

JN

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: USB support for new HP printers?

[John Nielsen]

On Monday 02 December 2002 05:13, Bernd Walter wrote:
 On Sun, Aug 25, 2002 at 11:36:15PM -0600, John Nielsen wrote:
  Are there plans to add USB support for HP's newer printers to FreeBSD?
  Specificially, the OfficeJets and the LaserJet 1200?  They use a
  new/different/broken USB interface so they're just recognized as ugen
  devices at the moment..

 Can you tell details about the difference?

Not really.  Pretty much everything I know I learned from corresponding with 
David Paschal on the hpoj-devel mailing list (see hpoj.sourceforge.net).  
If Geocrawler ever comes back up today you can browse the list.  See the 
thread FreeBSD howto? starting August 26 2002.  Here is a quote from Mr. 
Paschal in one of those e-mails:

Hi, John.  The LaserJet 1200 advertises several alternate settings for the
printer-class interface: 7/1/3 (for IEEE 1284.4 packets, the new and
different USB interface you mentioned), 7/1/2 (bidirectional raw print
data), and 7/1/1 (unidirectional raw print data).  If you can somehow
convince the ulpt driver to bind to 7/1/2 or 7/1/1 rather than just blindly
binding to the first alternate setting it finds, then that should be all you
need.

The above quote is in reference to getting printing (and only printing) to 
work on an LJ 1200.  For full functionality, you'd need to do a bit more.  
I think the hpoj project was leaning towards a cross-platform userland 
solution (hack?) rather than doing kernel mods on several different 
platforms.

JN

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

USB support for new HP printers?

[John Nielsen]

Are there plans to add USB support for HP's newer printers to FreeBSD?  
Specificially, the OfficeJets and the LaserJet 1200?  They use a 
new/different/broken USB interface so they're just recognized as ugen 
devices at the moment..

JN

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message