Jenkins build is back to normal : Build-UFS-image #1973

[jenkins-admin]

See 

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

Re: Will 10.2 also ship with a very stale NTP?

[Tomoaki AOKI]

Xin, Ian:
 Confirmed MFC of ntp 4.2.8p3 and related kernel fix.
 Thanks for your work!

re@:
 Thanks for approving MFC at this timing, before creating releng/10.2.

John:
 Congraturations! We have latest stable version of ntp with 10.2. :-)


On Sun, 12 Jul 2015 12:48:49 -0600
Ian Lepore  wrote:

> On Mon, 2015-07-13 at 04:31 +1000, Peter Jeremy wrote:
> > On 2015-Jul-12 09:41:43 -0600, Ian Lepore  wrote:
> > >And let's all just hope that a week or two of testing is enough when
> > >jumping a major piece of software forward several years in its
> > >independent evolution.
> > 
> > Whilst I support John's desire for NTP to be updated, I also do not
> > think this is the appropriate time to do so.  That said, the final
> > decision is up to re@.
> > 
> > >The import of 4.2.8p2 several months ago resulted in complete failure of
> > >timekeeping on all my arm systems.  Just last week I tracked it down to
> > >a kernel bug (which I haven't committed the fix for yet).  While the bug
> > >has been in the kernel for years, it tooks a small change in ntpd
> > >behavior to trigger it.
> > >
> > >Granted it's an odd corner-case problem that won't affect most users
> > >because they just use the stock ntp.conf file (and it only affects
> > >systems that have a large time step due to no battery-backed clock).
> > >But it took me weeks to find enough time to track down the cause of the
> > >problem.
> > 
> > I'm not using the stock ntp.conf on my RPis and didn't notice any NTP
> > issues.  Are you able to provide more details of either the ntp.conf
> > options that trigger the bug or the kernel bug itself?  A quick search
> > failed to find anything.
> > 
> 
> I just committed the kernel fix as r285424; the commit message has some
> info on why the new ntpd made the problem visible.
> 
> I should have said "stock rc.conf and ntp.conf"... To get the problem to
> happen you've got to set rc.conf ntpd_sync_on_start=NO and allow ntpd to
> make a large step (-g without -q, or tinker panic 0).  I don't remember
> why I had sync on start disabled on most of my arm systems (probably a
> one-time experiment that I forgot to undo and it got copied around), but
> I suspect most people who don't have battery clocks will have it set to
> yes, and that's why nobody else saw this problem.
> 
> To me, the problem was mainly illustrative of how a tiny innocuous
> change (ntpd making a series of ntp_adjtime() calls in a different, but
> still correct, order than it used to) can expose a completely unexpected
> longstanding bug in our code.  Gotta wonder if any more of those are
> lurking. :/
> 
> -- Ian
> 
> 
> 
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 


-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: amd64 kernel dynamic linking allows extern references to statics

[Konstantin Belousov]

On Thu, Jul 16, 2015 at 09:18:15AM +1000, Jan Mikkelsen wrote:
> 
> > On 15 Jul 2015, at 11:27 pm, Konstantin Belousov  
> > wrote:
> > 
> > On Wed, Jul 15, 2015 at 06:17:20PM +1000, Jan Mikkelsen wrote:
> >> Hi,
> >> 
> >> (All on 10.2-BETA1.)
> >> 
> >> I noticed that the latest patch in the bug 
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 
> >>  works on amd64 
> >> but fails to load zfs.ko on i386 with a symbol not found error.
> >> 
> >> Looking at the patch, there is one file that has ???extern int 
> >> zio_use_uma??? to reference a variable that is declared elsewhere as 
> >> ???static int zio_use_uma???. To me this obviously should not work. 
> >> However it does work on amd64 but fails on i386.
> >> 
> >> Below is a small test case that reproduces the problem. The generated 
> >> kernel module loads on amd64 but fails on i386. On amd64 one compilation 
> >> unit is accessing a static in from another compilation unit by declaring 
> >> the variable ???extern???. 
> >> 
> >> I haven???t looked further to attempt to find the bug. However, it looks 
> >> like a Bad Thing??? to me.
> >> 
> > 
> > I am not sure that this is fixable.  Issue is that amd64 modules are
> > relinked object files, and they might have unresolved relocations against
> > local symbols.  Change like the following probably fix your test case,
> > but also quite possible would break legitimate local references.
> > 
> > diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c
> > index 021381d..6fa5276 100644
> > --- a/sys/kern/link_elf_obj.c
> > +++ b/sys/kern/link_elf_obj.c
> > @@ -1096,7 +1096,8 @@ link_elf_lookup_symbol(linker_file_t lf, const char 
> > *name, c_linker_sym_t *sym)
> > 
> > for (i = 0, symp = ef->ddbsymtab; i < ef->ddbsymcnt; i++, symp++) {
> > strp = ef->ddbstrtab + symp->st_name;
> > -   if (symp->st_shndx != SHN_UNDEF && strcmp(name, strp) == 0) {
> > +   if (symp->st_shndx != SHN_UNDEF && strcmp(name, strp) == 0 &&
> > +   ELF_ST_BIND(symp->st_info) != STB_LOCAL) {
> > *sym = (c_linker_sym_t) symp;
> > return 0;
> > }
> 
> I don???t know why there could be an unresolved relocation against a local 
> symbol. My (admittedly trivial) tests with nm and static functions/variables 
> have not led to a ???U??? record. Under what circumstances would this happen?

Assembler cannot know the final location for any non-local data, so
any variable, global or static, requires a relocation in the object file
for the final code to work properly.  Look at the most trivial example

static int a;
int
f(int x)
{
return (a + x);
}
int *g(void)
{
return (&a);
}
The g() function is needed for prevent too smart gcc optimizer from
noting that nothing could modify a and replace its uses with the literal
0.

The generated object file, after disassembly, is
 :
   0:   89 f8   mov%edi,%eax
   2:   03 05 00 00 00 00   add0x0(%rip),%eax# 8 
4: R_X86_64_PC32.bss-0x4
   8:   c3  retq   
The relocation is X86_64_PC32, which takes a symbol as displacement.
In this case, compiler decided to use the segment base for the symbol,
but it is allowed to use the local symbol directly.

Only linker during the final link (not the incremental -r link) can fill
the word which provides displacement for the rip-relative addressing to
fetch a value.

> 
> Separately to this is that this behaviour also defeats multiple definition 
> checking at link time. Modifying my test slightly to have one compilation 
> unit with ???static int testvar???, one compilation unit with ???int 
> testvar??? and one with ???extern int testvar??? gives nm output like this 
> from the .ko file:
> 
> 00d0 d testvar
> 00c0 d testvar
> 
> It is unclear which instance of testvar the ???extern??? declaration used for 
> resolution. Simple testing seems to show it was the one with the non-static 
> storage class. However, a piece of code depending on the previous resolution 
> to local names could break by the addition a file with a name clash. Also, 
> not no ???U??? record ??? the ???extern int testvar??? declaration has been 
> resolved at this point.
> 
> Making both definitions static gives this:
> 
>  U testvar
> 00c0 d testvar
> 00d0 d testvar
> 
> Which testvar will I get at load time? Who knows? Adding a file with a static 
> variable with a name clash in another compilation unit can change the 
> behaviour of a module.
> 
> The big question for me is: under which legitimate case is this feature 
> necessary? The downsides seem significant.
> 

Well, might be that adding a check for multiple definitions of the same
symbol into the link_elf_obj.c is reasonable, I do not have very strong
opinion against it. But also, I do

Re: Will 10.2 also ship with a very stale NTP?

[Mark Felder]

On Thu, Jul 16, 2015, at 07:57, Tomoaki AOKI wrote:
> Xin, Ian:
>  Confirmed MFC of ntp 4.2.8p3 and related kernel fix.
>  Thanks for your work!
> 
> re@:
>  Thanks for approving MFC at this timing, before creating releng/10.2.
> 
> John:
>  Congraturations! We have latest stable version of ntp with 10.2. :-)
> 
> 

Thank you guys for speaking up while we had the chance. Sometimes MFC
opportunities are missed for various reasons and it's great to have a
community that keeps an eye out for these situations so re@ can cut
fruitful releases which make your lives easier.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

No, thank *you*! [was: Re: Will 10.2 also ship with a very stale NTP?]

[Glen Barber]

On Thu, Jul 16, 2015 at 12:25:31PM -0500, Mark Felder wrote:
> On Thu, Jul 16, 2015, at 07:57, Tomoaki AOKI wrote:
> > Xin, Ian:
> >  Confirmed MFC of ntp 4.2.8p3 and related kernel fix.
> >  Thanks for your work!
> > 
> > re@:
> >  Thanks for approving MFC at this timing, before creating releng/10.2.
> > 
> > John:
> >  Congraturations! We have latest stable version of ntp with 10.2. :-)
> > 
> > 
> 
> Thank you guys for speaking up while we had the chance. Sometimes MFC
> opportunities are missed for various reasons and it's great to have a
> community that keeps an eye out for these situations so re@ can cut
> fruitful releases which make your lives easier.

Seconded.

It's great to have such an amazing community.

Glen



pgp1s1SMeAolc.pgp
Description: PGP signature

Regression in FreeBSD-STABLE 10.2-BETA1 r28551

[Michael L. Squires]

I've not worked with 10.x a lot, so please excuse novice mistakes.

I upgraded the OS on a quad Opteron Tyan S4881 (known to have SMP 
bugs, but I haven't seen any and I've been running this system for 
years).  I upgraded from an earlier version of FreeBSD-10.x to

FreeBSD 10.2-BETA1 r285551.

Problem:  during boot, when accessing the DVD drive attached to the 
EIDE bus there is an interrupt storm on interrupt 16.  After a few 
minutes of errors the boot continues successfully and the system 
appears to behave normally after that.  I do not use the DVD drive 
except for installs, which are infrequent.


The earlier kernel does not exhibit this behavior.

This is part of a verbose dmesg during a boot.  The complete dmesg is 
attached.


This does not appear to be a serious issue, and this is a home server 
system.


Mike Squires
mi...@siralan.org or michael.leslie.squi...@gmail.com
UN*X at home since 1986

FreeBSD 10.2-BETA1 #5 r285551: Tue Jul 14 23:13:18 EDT 2015
r...@superxeon.familysquires.net:/usr/obj/usr/src/sys/OPTERON8 amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: AMD Opteron(tm) Processor 850 (2405.51-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x20f51  Family=0xf  Model=0x25  Stepping=1
  
Features=0x78bfbff
  Features2=0x1
  AMD Features=0xe2500800
  AMD Features2=0x1

[stuff deleted]

ata0: stat0=0x20 err=0x20 lsb=0x20 msb=0x20
ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30
ata0: reset tp2 stat0=20 stat1=30 devices=0x0
ata1: reset tp1 mask=03 ostat0=50 ostat1=01
ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: stat1=0x00 err=0x01 lsb=0x00 msb=0x00
ata1: reset tp2 stat0=00 stat1=00 devices=0x1
(noperiph:ahc0:0:-1:): SCSI bus reset delivered. 0 SCBs aborted.
interrupt storm detected on "irq16:"; throttling interrupt source
(noperiph:ahc1:0:-1:): SCSI bus reset delivered. 0 SCBs aborted.Table 'FACP' at 0x7ff73307
Table 'SRAT' at 0x7ff75c74
Table 'HPET' at 0x7ff75dac
Table 'SSDT' at 0x7ff75de4
Table 'SSDT' at 0x7ff75e81
Table 'APIC' at 0x7ff75f1e
APIC: Found table at 0x7ff75f1e
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
SMP: Added CPU 3 (AP)
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.2-BETA1 #5 r285551: Tue Jul 14 23:13:18 EDT 2015
r...@superxeon.familysquires.net:/usr/obj/usr/src/sys/OPTERON8 amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Preloaded elf kernel "/boot/kernel/kernel" at 0x819f4000.
Preloaded elf obj module "/boot/modules/vboxdrv.ko" at 0x819f4cb0.
Calibrating TSC clock ... TSC clock: 2405511005 Hz
CPU: AMD Opteron(tm) Processor 850 (2405.51-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x20f51  Family=0xf  Model=0x25  Stepping=1
  
Features=0x78bfbff
  Features2=0x1
  AMD Features=0xe2500800
  AMD Features2=0x1
L1 2MB data TLB: 8 entries, fully associative
L1 2MB instruction TLB: 8 entries, fully associative
L1 4KB data TLB: 32 entries, fully associative
L1 4KB instruction TLB: 32 entries, fully associative
L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L2 2MB unified TLB: 0 entries, disabled/not present
L2 4KB data TLB: 512 entries, 4-way associative
L2 4KB instruction TLB: 512 entries, 4-way associative
L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
WARNING: This architecture revision has known SMP hardware bugs which may cause 
random instability
real memory  = 17179869184 (16384 MB)
Physical memory chunk(s):
0x0001 - 0x00096fff, 552960 bytes (135 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x01a2a000 - 0x7ff6, 2119458816 bytes (517446 pages)
0x0001 - 0x0003e5ea8fff, 12447289344 bytes (3038889 pages)
avail memory = 14476759040 (13806 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
INTR: Adding local APIC 1 as a target
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 3 as a target
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 4 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
APIC: CPU 0 has ACPI ID 0
APIC: CPU 1 has ACPI ID 1
APIC: CPU 2 has ACPI ID 2
APIC: CPU 3 has ACPI ID 3
x86bios:  IVT 0x00-0x0004ff at 0xf800
x86bios: SSEG 0x096000-0x096fff at 0xfe03cc1ac000
x86bios: EBDA 0x09a000-0x09 at 0xf809a000
x86bios:  ROM 0x0a-0x0fefff at 0xf80a
XEN: CP

Re: jail: /etc/rc: cannot create /dev/null: Operation not supported

[James Gritton]

On 2015-07-15 13:52, Per olof Ljungmark wrote:

FreeBSD 10.2-PRERELEASE #0 r284949

The jail can be started, but when /etc/rc is executed:

root@mar:/ # sh -x /etc/rc
+ stty status ^T
/etc/rc: cannot create /dev/null: Operation not supported
+ trap : 2
+ trap 'echo '\''Boot interrupted'\''; exit 1' 3
+ HOME=/
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin
+ export HOME PATH
+ [ '' = autoboot ]
+ autoboot=no
+ _boot=quietstart
+ /sbin/sysctl -n vfs.nfs.diskless_valid
/etc/rc: cannot create /dev/null: Operation not supported
...

I have done the procedure several times before but never saw this one
before and don't know how to get around it.

Ideas anyone? Any recent changes that can show up like the above?

Thanks!


If it's trying to create /dev/null, I assume that the jail's /dev isn't
mounted when /etc/rc is running.  Do you have mount.devfs set in the
jail.conf, or jail_foo_devfs_enable in rc.conf (depending on your
configuration)? For that matter, can you tell if the jail's /dev is
mounted?

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

Re: amd64 kernel dynamic linking allows extern references to statics

[Jan Mikkelsen]

> On 16 Jul 2015, at 23:01, Konstantin Belousov  wrote:
> 
> On Thu, Jul 16, 2015 at 09:18:15AM +1000, Jan Mikkelsen wrote:
>> 
>>> On 15 Jul 2015, at 11:27 pm, Konstantin Belousov  
>>> wrote:
>>> 
>>> On Wed, Jul 15, 2015 at 06:17:20PM +1000, Jan Mikkelsen wrote:
 Hi,
 
 (All on 10.2-BETA1.)
 
 I noticed that the latest patch in the bug 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 
  works on amd64 
 but fails to load zfs.ko on i386 with a symbol not found error.
 
 Looking at the patch, there is one file that has ???extern int 
 zio_use_uma??? to reference a variable that is declared elsewhere as 
 ???static int zio_use_uma???. To me this obviously should not work. 
 However it does work on amd64 but fails on i386.
 
 Below is a small test case that reproduces the problem. The generated 
 kernel module loads on amd64 but fails on i386. On amd64 one compilation 
 unit is accessing a static in from another compilation unit by declaring 
 the variable ???extern???. 
 
 I haven???t looked further to attempt to find the bug. However, it looks 
 like a Bad Thing??? to me.
 
>>> 
>>> I am not sure that this is fixable.  Issue is that amd64 modules are
>>> relinked object files, and they might have unresolved relocations against
>>> local symbols.  Change like the following probably fix your test case,
>>> but also quite possible would break legitimate local references.
>>> 
>>> diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c
>>> index 021381d..6fa5276 100644
>>> --- a/sys/kern/link_elf_obj.c
>>> +++ b/sys/kern/link_elf_obj.c
>>> @@ -1096,7 +1096,8 @@ link_elf_lookup_symbol(linker_file_t lf, const char 
>>> *name, c_linker_sym_t *sym)
>>> 
>>> for (i = 0, symp = ef->ddbsymtab; i < ef->ddbsymcnt; i++, symp++) {
>>> strp = ef->ddbstrtab + symp->st_name;
>>> -   if (symp->st_shndx != SHN_UNDEF && strcmp(name, strp) == 0) {
>>> +   if (symp->st_shndx != SHN_UNDEF && strcmp(name, strp) == 0 &&
>>> +   ELF_ST_BIND(symp->st_info) != STB_LOCAL) {
>>> *sym = (c_linker_sym_t) symp;
>>> return 0;
>>> }
>> 
>> I don???t know why there could be an unresolved relocation against a local 
>> symbol. My (admittedly trivial) tests with nm and static functions/variables 
>> have not led to a ???U??? record. Under what circumstances would this happen?
> 
> Assembler cannot know the final location for any non-local data, so
> any variable, global or static, requires a relocation in the object file
> for the final code to work properly.  Look at the most trivial example
> 
> static int a;
> int
> f(int x)
> {
>   return (a + x);
> }
> int *g(void)
> {
>   return (&a);
> }
> The g() function is needed for prevent too smart gcc optimizer from
> noting that nothing could modify a and replace its uses with the literal
> 0.
> 
> The generated object file, after disassembly, is
>  :
>   0:   89 f8   mov%edi,%eax
>   2:   03 05 00 00 00 00   add0x0(%rip),%eax# 8 
>4: R_X86_64_PC32.bss-0x4
>   8:   c3  retq   
> The relocation is X86_64_PC32, which takes a symbol as displacement.
> In this case, compiler decided to use the segment base for the symbol,
> but it is allowed to use the local symbol directly.
> 
> Only linker during the final link (not the incremental -r link) can fill
> the word which provides displacement for the rip-relative addressing to
> fetch a value.


OK, I see. My expectation (obviously wrong) was that local names would be 
resolved earlier and relocation would not involve a name.

>> Separately to this is that this behaviour also defeats multiple definition 
>> checking at link time. Modifying my test slightly to have one compilation 
>> unit with ???static int testvar???, one compilation unit with ???int 
>> testvar??? and one with ???extern int testvar??? gives nm output like this 
>> from the .ko file:
>> 
>> 00d0 d testvar
>> 00c0 d testvar
>> 
>> It is unclear which instance of testvar the ???extern??? declaration used 
>> for resolution. Simple testing seems to show it was the one with the 
>> non-static storage class. However, a piece of code depending on the previous 
>> resolution to local names could break by the addition a file with a name 
>> clash. Also, not no ???U??? record ??? the ???extern int testvar??? 
>> declaration has been resolved at this point.
>> 
>> Making both definitions static gives this:
>> 
>> U testvar
>> 00c0 d testvar
>> 00d0 d testvar
>> 
>> Which testvar will I get at load time? Who knows? Adding a file with a 
>> static variable with a name clash in another compilation unit can change the 
>> behaviour of a module.
>> 
>> The big question fo