FreeBSD_HEAD_i386 - Build #644 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #644 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/644/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/644/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/644/console

Change summaries:

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

Re: [CURRENT] r 285785: vt_core.c:(.text+0x42f): undefined reference to vt_logo_sprite_height'

[Andrey Fesenko]

On Wed, Jul 22, 2015 at 8:38 AM, O. Hartmann
 wrote:
> Recent sources (r285785) do not buildkernel due to the bug/error shown below:
>
> [...]
> linking kernel
> vt_core.o: In function `vtterm_cnprobe':
> /usr/src/sys/dev/vt/vt_core.c:(.text+0x42f): undefined reference to
> `vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x46b): undefined
> reference to
> `vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x4c5): undefined
> reference to
> `vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x51b): undefined
> reference to
> `vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x57d): undefined
> reference to `vt_logo_sprite_height'
> vt_core.o:/usr/src/sys/dev/vt/vt_core.c:(.text+0x2870): more undefined
> references to `vt_logo_sprite_height' follow vt_core.o: In function
> `vt_flush': /usr/src/sys/dev/vt/vt_core.c:(.text+0x4fb8): undefined reference
> to `vtterm_draw_cpu_logos' vt_core.o: In function
> `vt_scrollmode_kbdevent': /usr/src/sys/dev/vt/vt_core.c:(.text+0x5963):
> undefined reference to
> `vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x5a98): 
> undefined
> reference to `vt_logo_sprite_height' *** [kernel] Error code 1
>
>

This commit 285765 and 285766 (D2181)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201751
___
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"

[CURRENT] r 285785: vt_core.c:(.text+0x42f): undefined reference to vt_logo_sprite_height'

[O. Hartmann]

Recent sources (r285785) do not buildkernel due to the bug/error shown below:

[...]
linking kernel
vt_core.o: In function `vtterm_cnprobe':
/usr/src/sys/dev/vt/vt_core.c:(.text+0x42f): undefined reference to
`vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x46b): undefined
reference to
`vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x4c5): undefined
reference to
`vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x51b): undefined
reference to
`vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x57d): undefined
reference to `vt_logo_sprite_height'
vt_core.o:/usr/src/sys/dev/vt/vt_core.c:(.text+0x2870): more undefined
references to `vt_logo_sprite_height' follow vt_core.o: In function
`vt_flush': /usr/src/sys/dev/vt/vt_core.c:(.text+0x4fb8): undefined reference
to `vtterm_draw_cpu_logos' vt_core.o: In function
`vt_scrollmode_kbdevent': /usr/src/sys/dev/vt/vt_core.c:(.text+0x5963):
undefined reference to
`vt_logo_sprite_height' /usr/src/sys/dev/vt/vt_core.c:(.text+0x5a98): undefined
reference to `vt_logo_sprite_height' *** [kernel] Error code 1


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

FreeBSD_HEAD_i386 - Build #643 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #643 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/643/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/643/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/643/console

Change summaries:

No changes


The end of the build log:

Started by an SCM change
Building remotely on kyua6.nyi.freebsd.org (jailer) in workspace 
/jenkins/workspace/FreeBSD_HEAD_i386
Updating svn://svnmir.freebsd.org/base/head at revision 
'2015-07-22T05:15:03.083 +'
U sys/conf/files
U sys/ddb/db_examine.c
U sys/ddb/db_print.c
U sys/ddb/db_main.c
U sys/kern/subr_smp.c
U sys/amd64/amd64/machdep.c
U sys/amd64/amd64/db_trace.c
U sys/i386/i386/machdep.c
U sys/i386/i386/db_trace.c
U sys/netinet/udp_usrreq.c
U sys/netinet/tcp_output.c
U sys/cddl/dev/fbt/fbt.c
U sys/netipsec/ipsec.h
U sys/netipsec/ipsec_input.c
U sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
U sys/dev/ixl/if_ixl.c
U sys/dev/vt/vt_core.c
AUsys/dev/vt/vt_cpulogos.c
U sys/dev/vt/vt.h
AUsys/dev/vt/logo/logo_beastie.c
U sys/dev/nvd/nvd.c
U sys/dev/gpio/gpiobus.c
U usr.bin/patch/patch.1
U usr.bin/patch/patch.c
U usr.bin/patch/backupfile.c
U usr.bin/netstat/main.c
At revision 285785
hudson.util.IOException2: revision check failed on 
svn://svnmir.freebsd.org/base/head
at 
hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:196)
at 
hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:123)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1282)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: org.tmatesoft.svn.core.SVNException: svn: E160006: No such revision 
285785
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.svn.SVNReader.handleFailureStatus(SVNReader.java:269)
at 
org.tmatesoft.svn.core.internal.io.svn.SVNReader.parse(SVNReader.java:248)
at 
org.tmatesoft.svn.core.internal.io.svn.SVNConnection.read(SVNConnection.java:276)
at 
org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.read(SVNRepositoryImpl.java:1291)
at 
org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLocationsImpl(SVNRepositoryImpl.java:293)
at 
org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1091)
at 
org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1519)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:212)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
at 
org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
at 
org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
at 
hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:184)
... 12 more
[PostBuildScript] - Execution post build scripts.
[FreeBSD_HEAD_i386] $ /bin/sh -xe /tmp/hudson2344095484425782383.sh
+ export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin'
+ export 'jname=FreeBSD_HEAD_i386'
+ echo 'clean up jail FreeBSD_HEAD_i386'
clean up jail FreeBSD_HEAD_i386
+ sudo jail -r FreeBSD_HEAD_i386
jail: "FreeBSD_HEAD_i386" not found
+ true
+ sudo ifconfig igb0 inet6 2610:1c1:1:607c::106:1 -alias
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
+ true
+ sudo umount FreeBSD_HEAD_i386/usr/src
umount: FreeBSD_

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[David Wolfskill]

On Tue, Jul 21, 2015 at 03:21:16PM -0500, Eric van Gyzen wrote:
> ...
> >> So it looks like net swi, leaking some udp6 lock.
> > Curiouser and curiouser...  While I'm not taking any special pains to
> > avoid building IPv6, I'm not actively actually doing anything with it
> > (IPv6), either (for both the failing machine and my laptop).
> >
> > Once I'm back home, I should be able to poke around in ddb after
> > re-creating the panic, if that would be a useful thing for me to do (and
> > given some hints as to what to poke).
> >
> > Naturally, I'm also happy to change bits of sources, rebuild, and
> > smoke-test.
> >
> > A quick check from the SVN update output only shows r285710, r285711, and
> > r285740 in the range from (r285685,r285741] -- as the kernel running
> > r285685 had no known issues -- that touched sys/netinet6/*.
> 
> It's a multicast destination.  Maybe something is using mDNS?
> 
> Randall, does the test on line 406 of udp6_usrreq.c need to be inverted?
> 
> Eric
> 

  We have a winner!

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1789  
r285741M/285741:1100077: Tue Jul 21 14:50:59 PDT 2015 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

freebeast(11.0-C)[3] cd /usr/src
freebeast(11.0-C)[4] svn diff sys/netinet
netinet/  netinet6/ 
freebeast(11.0-C)[4] svn diff sys/netinet*
Index: sys/netinet6/udp6_usrreq.c
===
--- sys/netinet6/udp6_usrreq.c  (revision 285741)
+++ sys/netinet6/udp6_usrreq.c  (working copy)
@@ -403,7 +403,7 @@
INP_RLOCK(last);
INP_INFO_RUNLOCK(pcbinfo);
UDP_PROBE(receive, NULL, last, ip6, last, uh);
-   if (udp6_append(last, m, off, &fromsa)) 
+   if (! udp6_append(last, m, off, &fromsa)) 
INP_RUNLOCK(last);
inp_lost:
return (IPPROTO_DONE);
freebeast(11.0-C)[5] 

Thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpJj1IlX26b0.pgp
Description: PGP signature

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[Eric van Gyzen]

On 07/21/2015 15:21, Eric van Gyzen wrote:
> On 07/21/2015 15:05, David Wolfskill wrote:
>> On Tue, Jul 21, 2015 at 10:28:32PM +0300, Konstantin Belousov wrote:
>>> ...
>>> Indeed, thank you.
>>> ithread_loop() at ithread_loop+0xa6/frame 0xfe083b9c0a70
>>> fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
>>> --- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
>>> suspending ithread with the following locks held:
>>> shared rw udpinp (udpinp) r = 3 (0xf80010c7d7b0) locked @ 
>>> /usr/src/sys/netinet6/in6_pcb.c:1174
>>> panic: witness_warn
>>> cpuid = 3
>>>
>>> So it looks like net swi, leaking some udp6 lock.
>> Curiouser and curiouser...  While I'm not taking any special pains to
>> avoid building IPv6, I'm not actively actually doing anything with it
>> (IPv6), either (for both the failing machine and my laptop).
>>
>> Once I'm back home, I should be able to poke around in ddb after
>> re-creating the panic, if that would be a useful thing for me to do (and
>> given some hints as to what to poke).
>>
>> Naturally, I'm also happy to change bits of sources, rebuild, and
>> smoke-test.
>>
>> A quick check from the SVN update output only shows r285710, r285711, and
>> r285740 in the range from (r285685,r285741] -- as the kernel running
>> r285685 had no known issues -- that touched sys/netinet6/*.
> It's a multicast destination.  Maybe something is using mDNS?

Blurf.  "I wonder if" it's a multicast destination.  (I need more chocolate.)

> Randall, does the test on line 406 of udp6_usrreq.c need to be inverted?
>
> Eric
>




signature.asc
Description: OpenPGP digital signature

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[Eric van Gyzen]

On 07/21/2015 15:05, David Wolfskill wrote:
> On Tue, Jul 21, 2015 at 10:28:32PM +0300, Konstantin Belousov wrote:
>> ...
>> Indeed, thank you.
>> ithread_loop() at ithread_loop+0xa6/frame 0xfe083b9c0a70
>> fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
>> --- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
>> suspending ithread with the following locks held:
>> shared rw udpinp (udpinp) r = 3 (0xf80010c7d7b0) locked @ 
>> /usr/src/sys/netinet6/in6_pcb.c:1174
>> panic: witness_warn
>> cpuid = 3
>>
>> So it looks like net swi, leaking some udp6 lock.
> Curiouser and curiouser...  While I'm not taking any special pains to
> avoid building IPv6, I'm not actively actually doing anything with it
> (IPv6), either (for both the failing machine and my laptop).
>
> Once I'm back home, I should be able to poke around in ddb after
> re-creating the panic, if that would be a useful thing for me to do (and
> given some hints as to what to poke).
>
> Naturally, I'm also happy to change bits of sources, rebuild, and
> smoke-test.
>
> A quick check from the SVN update output only shows r285710, r285711, and
> r285740 in the range from (r285685,r285741] -- as the kernel running
> r285685 had no known issues -- that touched sys/netinet6/*.

It's a multicast destination.  Maybe something is using mDNS?

Randall, does the test on line 406 of udp6_usrreq.c need to be inverted?

Eric



signature.asc
Description: OpenPGP digital signature

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[David Wolfskill]

On Tue, Jul 21, 2015 at 10:28:32PM +0300, Konstantin Belousov wrote:
> ...
> Indeed, thank you.
> ithread_loop() at ithread_loop+0xa6/frame 0xfe083b9c0a70
> fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
> --- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
> suspending ithread with the following locks held:
> shared rw udpinp (udpinp) r = 3 (0xf80010c7d7b0) locked @ 
> /usr/src/sys/netinet6/in6_pcb.c:1174
> panic: witness_warn
> cpuid = 3
> 
> So it looks like net swi, leaking some udp6 lock.

Curiouser and curiouser...  While I'm not taking any special pains to
avoid building IPv6, I'm not actively actually doing anything with it
(IPv6), either (for both the failing machine and my laptop).

Once I'm back home, I should be able to poke around in ddb after
re-creating the panic, if that would be a useful thing for me to do (and
given some hints as to what to poke).

Naturally, I'm also happy to change bits of sources, rebuild, and
smoke-test.

A quick check from the SVN update output only shows r285710, r285711, and
r285740 in the range from (r285685,r285741] -- as the kernel running
r285685 had no known issues -- that touched sys/netinet6/*.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpQ_E2uiyznk.pgp
Description: PGP signature

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[Konstantin Belousov]

On Tue, Jul 21, 2015 at 07:17:43PM +, Mark Johnston wrote:
> On Tue, Jul 21, 2015 at 09:19:27AM -0700, David Wolfskill wrote:
> > On Tue, Jul 21, 2015 at 04:39:07PM +0300, Konstantin Belousov wrote:
> > > On Tue, Jul 21, 2015 at 05:57:34AM -0700, David Wolfskill wrote:
> > > > My laptop had no problems, but the build machine has a panic that
> > > > appears quite reproducible (4 "successes" out of 4 tries); here's a bit
> > > > from the core.txt file:
> > > 
> > > There must be kernel messages before the panic string.  They are crusial
> > > to understand what is going on.
> > > ...
> > 
> > Sorry I wasn't able to capture those before I needed to do Other Things.
> > 
> > The machine had a (PCI-attached) serial console that was working
> > for FreeBSD (thanks mostly to sbruno's help), but Somthing seems
> > to Have Happened, and that's not presently working (even in stable/10,
> > where I first got it working).
> > 
> > I will try to get it working again, but I doubt I will have time to
> > focus on that until about 9 hours from now.
> 
> It's possible to extract log messages leading up to the panic from the
> vmcore. From the kgdb prompt, running
> 
> (kgdb) printf "%s", msgbufp->msg_ptr
> 
> should bring them up.
> 
> And, I just noticed that you posted the core.txt, which contains this
> info near the end:
> http://www.catwhisker.org/~david/FreeBSD/head/core.txt.1

Indeed, thank you.
ithread_loop() at ithread_loop+0xa6/frame 0xfe083b9c0a70
fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
--- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
suspending ithread with the following locks held:
shared rw udpinp (udpinp) r = 3 (0xf80010c7d7b0) locked @ 
/usr/src/sys/netinet6/in6_pcb.c:1174
panic: witness_warn
cpuid = 3

So it looks like net swi, leaking some udp6 lock.
___
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: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[Mark Johnston]

On Tue, Jul 21, 2015 at 09:19:27AM -0700, David Wolfskill wrote:
> On Tue, Jul 21, 2015 at 04:39:07PM +0300, Konstantin Belousov wrote:
> > On Tue, Jul 21, 2015 at 05:57:34AM -0700, David Wolfskill wrote:
> > > My laptop had no problems, but the build machine has a panic that
> > > appears quite reproducible (4 "successes" out of 4 tries); here's a bit
> > > from the core.txt file:
> > 
> > There must be kernel messages before the panic string.  They are crusial
> > to understand what is going on.
> > ...
> 
> Sorry I wasn't able to capture those before I needed to do Other Things.
> 
> The machine had a (PCI-attached) serial console that was working
> for FreeBSD (thanks mostly to sbruno's help), but Somthing seems
> to Have Happened, and that's not presently working (even in stable/10,
> where I first got it working).
> 
> I will try to get it working again, but I doubt I will have time to
> focus on that until about 9 hours from now.

It's possible to extract log messages leading up to the panic from the
vmcore. From the kgdb prompt, running

(kgdb) printf "%s", msgbufp->msg_ptr

should bring them up.

And, I just noticed that you posted the core.txt, which contains this
info near the end:
http://www.catwhisker.org/~david/FreeBSD/head/core.txt.1
___
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: Kernel Application Binary Interface (kABI) support in FreeBSD

[Adrian Chadd]

Yes, I think the FreeBSD developers have been doing this since before
Redhat was a thing.



-a


On 20 July 2015 at 23:02, Venkat Duvvuru
 wrote:
> Yes, my question was about kernel module compatibililty with FreeBSD's
> major releases of a particular version.
> For example, will FreeBSD makes sure that the driver built on 10.0 version
> of Freebsd seamlessly load on all other 10.x versions of FreeBSD?
> Does it make sure that the symbols and their parameters are not blindly
> changed without considering the binary compatibility with other FreeBSD
> version binaries?
>
> RHEL kABI whitelist makes sure that once the symbol is added into the
> whitelist, it will never be changed during the major releases of that
> kernel.
>
>
> Thanks,
> Venkat.
>
> On Fri, Jul 17, 2015 at 8:29 PM, Allan Jude  wrote:
>
>> On 2015-07-17 10:47, Julian Elischer wrote:
>> > On 7/17/15 9:02 PM, Venkat Duvvuru wrote:
>> >> Hi,
>> >>
>> >> Is there kABI (Kabi-whitelist) equivalent feature in FreeBSD?
>> > well, yes and no.
>> >
>> > Firstly, FreeBSD maintains a backwards compatible kABI (with the
>> > exception of programs that hunt around in kernel memory).
>> > We also use symbol versioning on the libc. so depending on what you want
>> > to do. the answer may be useful to you or not.
>> > Basically any binary should continue to run on a newer kernel, even if
>> > the syscalls change, because we should still support the old abi.
>> >
>> > tell us more about what you need and we can be more specific.
>> >
>> > I have run Freebsd 1.1 binaries on a Freebsd 8  system, in fact I have
>> > done a system build in a freebsd 1.1 chroot on an 8 system.
>> > I haven't tried it on 9 or 10 but I'd expect it to work..
>> >
>> >
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> Venkat.
>> >> ___
>> >> 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"
>>
>> I think the question related to drivers (kernel modules).
>>
>> In which case, they should be compatible across major versions (module
>> from 10.0 works in 10.2, but not 9.3 or 11.0)
>>
>> --
>> Allan Jude
>>
>>
> ___
> 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: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[David Wolfskill]

On Tue, Jul 21, 2015 at 04:39:07PM +0300, Konstantin Belousov wrote:
> On Tue, Jul 21, 2015 at 05:57:34AM -0700, David Wolfskill wrote:
> > My laptop had no problems, but the build machine has a panic that
> > appears quite reproducible (4 "successes" out of 4 tries); here's a bit
> > from the core.txt file:
> 
> There must be kernel messages before the panic string.  They are crusial
> to understand what is going on.
> ...

Sorry I wasn't able to capture those before I needed to do Other Things.

The machine had a (PCI-attached) serial console that was working
for FreeBSD (thanks mostly to sbruno's help), but Somthing seems
to Have Happened, and that's not presently working (even in stable/10,
where I first got it working).

I will try to get it working again, but I doubt I will have time to
focus on that until about 9 hours from now.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpXNNyz_zCPR.pgp
Description: PGP signature

Re: Kernel Application Binary Interface (kABI) support in FreeBSD

[Julian Elischer]

On 7/21/15 2:02 PM, Venkat Duvvuru wrote:

Yes, my question was about kernel module compatibililty with FreeBSD's
major releases of a particular version.
For example, will FreeBSD makes sure that the driver built on 10.0 version
of Freebsd seamlessly load on all other 10.x versions of FreeBSD?
Does it make sure that the symbols and their parameters are not blindly
changed without considering the binary compatibility with other FreeBSD
version binaries?
Our aim is that a module compiled on X.0 should be loadable on X.Y for 
all values of Y.
This is true for most of the subsystems that people expect to touch 
with modules.
i.e. the network stack, driver framework, IO paths, system call 
interfaces, scheduler exported calls.
and the structures  they use. Note, a module compiled on X.Y is not 
guaranteed (or expected) to run

on systems with smaller values of Y.



RHEL kABI whitelist makes sure that once the symbol is added into the
whitelist, it will never be changed during the major releases of that
kernel.


Thanks,
Venkat.

On Fri, Jul 17, 2015 at 8:29 PM, Allan Jude  wrote:


On 2015-07-17 10:47, Julian Elischer wrote:

On 7/17/15 9:02 PM, Venkat Duvvuru wrote:

Hi,

Is there kABI (Kabi-whitelist) equivalent feature in FreeBSD?

well, yes and no.

Firstly, FreeBSD maintains a backwards compatible kABI (with the
exception of programs that hunt around in kernel memory).
We also use symbol versioning on the libc. so depending on what you want
to do. the answer may be useful to you or not.
Basically any binary should continue to run on a newer kernel, even if
the syscalls change, because we should still support the old abi.

tell us more about what you need and we can be more specific.

I have run Freebsd 1.1 binaries on a Freebsd 8  system, in fact I have
done a system build in a freebsd 1.1 chroot on an 8 system.
I haven't tried it on 9 or 10 but I'd expect it to work..





Thanks,

Venkat.
___
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"

I think the question related to drivers (kernel modules).

In which case, they should be compatible across major versions (module
from 10.0 works in 10.2, but not 9.3 or 11.0)

--
Allan Jude



___
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: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[Konstantin Belousov]

On Tue, Jul 21, 2015 at 05:57:34AM -0700, David Wolfskill wrote:
> My laptop had no problems, but the build machine has a panic that
> appears quite reproducible (4 "successes" out of 4 tries); here's a bit
> from the core.txt file:

There must be kernel messages before the panic string.  They are crusial
to understand what is going on.

> 
> freebeast.catwhisker.org dumped core - see /var/crash/vmcore.1
> 
> Tue Jul 21 05:36:11 PDT 2015
> 
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1787  
> r285741M/285741:1100077: Tue Jul 21 04:48:37 PDT 2015 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> panic: witness_warn
___
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"

panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[David Wolfskill]

My laptop had no problems, but the build machine has a panic that
appears quite reproducible (4 "successes" out of 4 tries); here's a bit
from the core.txt file:

freebeast.catwhisker.org dumped core - see /var/crash/vmcore.1

Tue Jul 21 05:36:11 PDT 2015

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1787  
r285741M/285741:1100077: Tue Jul 21 04:48:37 PDT 2015 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

panic: witness_warn

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: witness_warn
cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe083b9c0860
vpanic() at vpanic+0x189/frame 0xfe083b9c08e0
kassert_panic() at kassert_panic+0x132/frame 0xfe083b9c0950
witness_warn() at witness_warn+0x498/frame 0xfe083b9c0a20
ithread_loop() at ithread_loop+0x165/frame 0xfe083b9c0a70
fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
--- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
...
(kgdb) #0  doadump (textdump=0) at pcpu.h:221
#1  0x80377dfe in db_dump (dummy=, dummy2=false, 
dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
#2  0x80377971 in db_command (cmd_table=0x0)
at /usr/src/sys/ddb/db_command.c:440
#3  0x80377604 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:493
#4  0x8037a19b in db_trap (type=, code=0)
at /usr/src/sys/ddb/db_main.c:251
#5  0x80a56624 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#6  0x80e61bd1 in trap (frame=0xfe083b9c0790)
at /usr/src/sys/amd64/amd64/trap.c:540
#7  0x80e41e02 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:235
#8  0x80a55cfe in kdb_enter (why=0x8136f098 "panic", 
msg=0x80a5bee0 
"UH\211AWAVATSH\203PI\211A\211H\213\004%\201H\211E\201<%x\201")
 at cpufunc.h:63
#9  0x80a19739 in vpanic (fmt=, 
ap=) at /usr/src/sys/kern/kern_shutdown.c:737
#10 0x80a19582 in kassert_panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:634
#11 0x80a74908 in witness_warn (flags=2, lock=, 
fmt=0x81367827 "suspending ithread")
at /usr/src/sys/kern/subr_witness.c:1757
#12 0x809e2985 in ithread_loop (arg=0xf8000770c820)
at /usr/src/sys/kern/kern_intr.c:1345
#13 0x809df874 in fork_exit (
callout=0x809e2820 , arg=0xf8000770c820, 
frame=0xfe083b9c0ac0) at /usr/src/sys/kern/kern_fork.c:1006
#14 0x80e4233e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:610
#15 0x in ?? ()
Current language:  auto; currently minimal
(kgdb) 


On boot, it dropped into the debugger; it was on the most recent
instantiation that I manually issued a "dump" command from that
environment, then rebooted under the previous kernel:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1786  
r285715M/285715:1100077: Mon Jul 20 04:22:26 PDT 2015 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

(And yes, it runs an unmodified GENERIC kernel.)

The machine has been deployed only for a couple of months or so,
but has been building stable/10 and head daily during that time.
Until a couple of weeks ago, it was doing this for both i386 and
amd64; since then, I dropped i386 from my home infrastructure, so
it's been only amd64.

In the stable/10 environment, it also make use of a 3-spindle zraid for
running poudriere (to build the ports for my "production" machines), and
it's been doing that quite well, also.

Only other thing that I think of that's noteworthy is that its boot
drive is an SSD (where I have not yet enabled TRIM, as it's a Crucial
M500, and I need to be sure we don't try to use the queued TRIM commands
on it, as there are reports that queued TRIM commands on the M500 will
corrupt data).

OK; please see  for the
dump(-related) files.  (It's on a residential ADSL, so it's going to be
slow.  Sorry; I have a limited amount of bandwidth.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp4y7XWYoZPA.pgp
Description: PGP signature

Re: Kernel Application Binary Interface (kABI) support in FreeBSD

[Venkat Duvvuru]

Yes, my question was about kernel module compatibililty with FreeBSD's
major releases of a particular version.
For example, will FreeBSD makes sure that the driver built on 10.0 version
of Freebsd seamlessly load on all other 10.x versions of FreeBSD?
Does it make sure that the symbols and their parameters are not blindly
changed without considering the binary compatibility with other FreeBSD
version binaries?

RHEL kABI whitelist makes sure that once the symbol is added into the
whitelist, it will never be changed during the major releases of that
kernel.


Thanks,
Venkat.

On Fri, Jul 17, 2015 at 8:29 PM, Allan Jude  wrote:

> On 2015-07-17 10:47, Julian Elischer wrote:
> > On 7/17/15 9:02 PM, Venkat Duvvuru wrote:
> >> Hi,
> >>
> >> Is there kABI (Kabi-whitelist) equivalent feature in FreeBSD?
> > well, yes and no.
> >
> > Firstly, FreeBSD maintains a backwards compatible kABI (with the
> > exception of programs that hunt around in kernel memory).
> > We also use symbol versioning on the libc. so depending on what you want
> > to do. the answer may be useful to you or not.
> > Basically any binary should continue to run on a newer kernel, even if
> > the syscalls change, because we should still support the old abi.
> >
> > tell us more about what you need and we can be more specific.
> >
> > I have run Freebsd 1.1 binaries on a Freebsd 8  system, in fact I have
> > done a system build in a freebsd 1.1 chroot on an 8 system.
> > I haven't tried it on 9 or 10 but I'd expect it to work..
> >
> >
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Venkat.
> >> ___
> >> 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"
>
> I think the question related to drivers (kernel modules).
>
> In which case, they should be compatible across major versions (module
> from 10.0 works in 10.2, but not 9.3 or 11.0)
>
> --
> Allan Jude
>
>
___
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: Laptops that will not boot

[Juan Ramón Molina Menor]

Does anyone else have a machine that won't boot from GPT without the
active flag set?

bsdinstall now has a blacklist for these models, and can apply the fix
as part of the installation (ufs or zfs).

If you are also suffering from this, please post your machine's details
to get it added to the blacklist:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194359


--
Allan Jude


Hi Allan. It seems that this problem affects some recent ThinkPads, but 
I’m not seeing it with a S440: the latest CURRENT memstick boots fine 
both in 'UEFI Only' and 'Legacy' modes.


So, don’t blacklist it, please! ;-)

Best regards,
Juan
___
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_HEAD_i386 - Build #637 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #637 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/637/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/637/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/637/console

Change summaries:

No changes
___
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_HEAD_i386 - Build #636 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #636 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/636/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/636/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/636/console

Change summaries:

No changes


The end of the build log:

Started by an SCM change
Building remotely on kyua6.nyi.freebsd.org (jailer) in workspace 
/jenkins/workspace/FreeBSD_HEAD_i386
FATAL: java.io.EOFException
hudson.remoting.RequestAbortedException: java.io.EOFException
at hudson.remoting.Request.abort(Request.java:296)
at hudson.remoting.Channel.terminate(Channel.java:815)
at 
org.jenkinsci.remoting.nio.NioChannelHub$3.run(NioChannelHub.java:613)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
at 
jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to kyua6.nyi.freebsd.org(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1361)
at hudson.remoting.Request.call(Request.java:171)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:980)
at hudson.FilePath.act(FilePath.java:969)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1282)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:381)
Caused by: java.io.EOFException
at 
org.jenkinsci.remoting.nio.NioChannelHub$3.run(NioChannelHub.java:613)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
at 
jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[PostBuildScript] - Execution post build scripts.
ERROR: Build step failed with exception
java.lang.NullPointerException: no workspace from node 
hudson.slaves.DumbSlave[kyua6.nyi.freebsd.org] which is computer 
hudson.slaves.SlaveComputer@6d54ca2c and has channel null
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:76)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
at 
org.jenkinsci.plugins.postbuildscript.PostBuildScript.processBuildSteps(PostBuildScript.java:204)
at 
org.jenkinsci.plugins.postbuildscript.PostBuildScript.processScripts(PostBuildScript.java:143)
at 
org.jenkinsci.plugins.postbuildscript.PostBuildScript._perform(PostBuildScript.java:105)
at 
org.jenkinsci.plugins.postbuildscript.PostBuildScript.perform(PostBuildScript.java:85)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:726)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671)
at hudson.model.Run.execute(Run.java:1766)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.mode