Re: r322076 breaks vtnet connectivity

2017-08-10 Thread Jung-uk Kim 
On 08/10/2017 21:27, Ian FREISLICH wrote:
> I have a host on Digital Ocean (qemu) and the change in r322076 breaks
> my vtnet0 interface.  The interface still comes up but does not pass
> traffic any more.  It's not obvious to my why the changes from r322075
> to r322076 affect the vtnet interface.

Can you please try r322323 or later?  Basically, r322076 was incomplete
and r322323 corrected the stupid mistake.

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature

Re: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol

2017-08-10 Thread Mark Millard 
[clang 5 generates R_PPC_PLTREL24 in the .o files
for global symbols in places gcc 4.2.1 generates
R_PPC_ADDR16_HA / R_PPC_ADDR16_LO pairs.]

On 2017-Aug-10, at 7:22 PM, Mark Millard  wrote:

> [A top post about the failing R_PPC_PLTREL24 since
> the material does not flow well as a sequential
> read from prior material. I found that the .kld
> does not match the contributing .o for GLOBAL
> status for routines and the LOCAL in the .kld is
> rejected by ld in ppc_elf_check_relocs.]
> 
> There is something consistent between the two example
> failures. (The examples here are from a more recent
> head version for a buildkernel attempt.)
> 
> (I inserted some lines not matched by the shown grep.)
> 
> # readelf -a 
> /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha.kld
>  | grep aha_alloc
> 2b8c 3e12 R_PPC_PLTREL24   aha_alloc + 0
> 31a8 3e12 R_PPC_PLTREL24   aha_alloc + 0
> Symbol table (.symtab) contains 180 entries:
>   Num:Value  Size TypeBind   Vis  Ndx Name
>62: 96 FUNCLOCAL  DEFAULT1 aha_alloc
> 
> but in aha.o :
> 
>44: 96 FUNCGLOBAL DEFAULT2 aha_alloc
> 
> # readelf -a 
> /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/agp/agp.kld
>  | grep agp_find_caps
> 2e08 4912 R_PPC_PLTREL24   agp_find_caps + 0
> Symbol table (.symtab) contains 180 entries:
>   Num:Value  Size TypeBind   Vis  Ndx Name
>73:    172 FUNCLOCAL  DEFAULT1 agp_find_caps
> 
> but in agp.o :
> 
>58:    172 FUNCGLOBAL DEFAULT2 agp_find_caps
> 
> building the .kld's is turning GLOBAL into LOCAL -- and the LOCAL
> is being rejected by:
> 
> /usr/src/contrib/binutils/bfd/elf32-ppc.c
> 
> in its routine:
> 
> /* Look through the relocs for a section during the first phase, and
>   allocate space in the global offset table or procedure linkage
>   table.  */
> 
> static bfd_boolean
> ppc_elf_check_relocs (bfd *abfd,
>  struct bfd_link_info *info,
>  asection *sec,
>  const Elf_Internal_Rela *relocs)
> 
> via:
> 
> 
>  r_symndx = ELF32_R_SYM (rel->r_info);
>  if (r_symndx < symtab_hdr->sh_info)
>h = NULL;
>  else  
> 
> . . .
>  tls_type = 0;
>  r_type = ELF32_R_TYPE (rel->r_info);
> . . .  
>  switch (r_type)
>{
> . . .
>case R_PPC_PLT32:
>case R_PPC_PLTREL24:
>case R_PPC_PLTREL32:
>case R_PPC_PLT16_LO:
>case R_PPC_PLT16_HI:
>case R_PPC_PLT16_HA:
> #ifdef DEBUG
>  fprintf (stderr, "Reloc requires a PLT entry\n");
> #endif
>  /* This symbol requires a procedure linkage table entry.  We
> actually build the entry in finish_dynamic_symbol,
> because this might be a case of linking PIC code without
> linking in any dynamic objects, in which case we don't
> need to generate a procedure linkage table after all.  */
> 
>  if (h == NULL)
>{
>  /* It does not make sense to have a procedure linkage
> table entry for a local symbol.  */
>  (*_bfd_error_handler) (_("%B(%A+0x%lx): %s reloc against "
>   "local symbol"),
> abfd,
> sec,
> (long) rel->r_offset,
> ppc_elf_howto_table[r_type]->name);
>  bfd_set_error (bfd_error_bad_value);
>  return FALSE;
>}
>  else
> . . .

clang 5 and gcc 4.2.1 do not match for what
goes in aha*.o and agp*.o files for the
problem symbols in clang 5's output:

gcc 4.2.1 ( R_PPC_ADDR16_HA / R_PPC_ADDR16_LO ):

# readelf -at 
/usr/obj/powerpcvtsc_gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha*.o
 | grep aha_alloc
50: 0514   112 FUNCGLOBAL DEFAULT1 aha_alloc
0032 3206 R_PPC_ADDR16_HA  aha_alloc + 0
003e 3204 R_PPC_ADDR16_LO  aha_alloc + 0
052a 3206 R_PPC_ADDR16_HA  aha_alloc + 0
052e 3204 R_PPC_ADDR16_LO  aha_alloc + 0
50:  0 NOTYPE  GLOBAL DEFAULT  UND aha_alloc

# readelf -at 
/usr/obj/powerpcvtsc_gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/agp/agp*.o
 | grep caps
204a 3a06 R_PPC_ADDR16_HA 0434 agp_find_caps + 0
204e 3a04 R_PPC_ADDR16_LO 0434 agp_find_caps + 0
2312 3a06 R_PPC_ADDR16_HA 0434 agp_find_caps + 0
231a 3a04 R_PPC_ADDR16_LO 0434 agp_find_caps + 0
 3a01 R_PPC_ADDR320434 agp_find_caps + 0
58:

Re: r322076 breaks vtnet connectivity

2017-08-10 Thread Orion Tiller 
> Hi
>
> I have a host on Digital Ocean (qemu) and the change in r322076 breaks
> my vtnet0 interface.  The interface still comes up but does not pass
> traffic any more.  It's not obvious to my why the changes from r322075
> to r322076 affect the vtnet interface.
>
> Ian
>
Not sure if you have the same issue but I get the same thing happening
to my DO droplets after I upgrade them sometimes.  You can usually fix
it by putting the contents of the /etc/rc.digitalocean.d/droplet.conf
file into your /etc/rc.conf file.  Sometimes the file name is like this
with digits /etc/rc.digitalocean.d/39502227.conf just depends.

___
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: I have submitted bugzilla 221107 for a (e.g.) -r321706 system clang 5 vintage TARGET_ARCH=powerpc buildkernel failure for aha.kld: R_PPC_PLTREL24 reloc against local symbol

2017-08-10 Thread Mark Millard 
[A top post about the failing R_PPC_PLTREL24 since
the material does not flow well as a sequential
read from prior material. I found that the .kld
does not match the contributing .o for GLOBAL
status for routines and the LOCAL in the .kld is
rejected by ld in ppc_elf_check_relocs.]

There is something consistent between the two example
failures. (The examples here are from a more recent
head version for a buildkernel attempt.)

(I inserted some lines not matched by the shown grep.)

# readelf -a 
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/aha/aha.kld
 | grep aha_alloc
2b8c 3e12 R_PPC_PLTREL24   aha_alloc + 0
31a8 3e12 R_PPC_PLTREL24   aha_alloc + 0
Symbol table (.symtab) contains 180 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
62: 96 FUNCLOCAL  DEFAULT1 aha_alloc

but in aha.o :

44: 96 FUNCGLOBAL DEFAULT2 aha_alloc

# readelf -a 
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/agp/agp.kld
 | grep agp_find_caps
2e08 4912 R_PPC_PLTREL24   agp_find_caps + 0
Symbol table (.symtab) contains 180 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
73:    172 FUNCLOCAL  DEFAULT1 agp_find_caps

but in agp.o :

58:    172 FUNCGLOBAL DEFAULT2 agp_find_caps

building the .kld's is turning GLOBAL into LOCAL -- and the LOCAL
is being rejected by:

/usr/src/contrib/binutils/bfd/elf32-ppc.c

in its routine:

/* Look through the relocs for a section during the first phase, and
   allocate space in the global offset table or procedure linkage
   table.  */
  
static bfd_boolean
ppc_elf_check_relocs (bfd *abfd,
  struct bfd_link_info *info,
  asection *sec,
  const Elf_Internal_Rela *relocs)

via:


  r_symndx = ELF32_R_SYM (rel->r_info);
  if (r_symndx < symtab_hdr->sh_info)
h = NULL;
  else  

. . .
  tls_type = 0;
  r_type = ELF32_R_TYPE (rel->r_info);
. . .  
  switch (r_type)
{
. . .
case R_PPC_PLT32:
case R_PPC_PLTREL24:
case R_PPC_PLTREL32:
case R_PPC_PLT16_LO:
case R_PPC_PLT16_HI:
case R_PPC_PLT16_HA:
#ifdef DEBUG
  fprintf (stderr, "Reloc requires a PLT entry\n");
#endif
  /* This symbol requires a procedure linkage table entry.  We
 actually build the entry in finish_dynamic_symbol,
 because this might be a case of linking PIC code without
 linking in any dynamic objects, in which case we don't
 need to generate a procedure linkage table after all.  */
  
  if (h == NULL)
{
  /* It does not make sense to have a procedure linkage
 table entry for a local symbol.  */
  (*_bfd_error_handler) (_("%B(%A+0x%lx): %s reloc against "
   "local symbol"),
 abfd,
 sec,
 (long) rel->r_offset,
 ppc_elf_howto_table[r_type]->name);
  bfd_set_error (bfd_error_bad_value);
  return FALSE;
}
  else
. . .


===
Mark Millard
markmi at dsl-only.net

On 2017-Aug-6, at 2:44 PM, Mark Millard  wrote:

[-r322109 update failed for agp.kld instead. It may just be
a race for which happens first during the build.]

On 2017-Jul-30, at 3:03 PM, Mark Millard  wrote:

> [Just correcting the -r's to be -r321706.]
> 
> On 2017-Jul-30, at 1:34 PM, Mark Millard  wrote:
> 
> I experiment with system clang targeting powerpc
> (and powerpc64). Until recently I could buildkernel
> via system clang 4 (but it had problems if tried to
> boot such a kernel). After clang 5 it no longer
> completes the buildkernel. I'm submitting based on
> a -r321706 build attempt. The system binutils are
> in use.
> 
> The technical material from the submittal is. . .
> 
> First I list what the R_PPC_PLTREL24 is tied to
> then the error text then the build context.
> 
> objdump reports that the .text+0x2b94 involved
> is in aha_isa_probe and is a reference to aha_alloc:
> 
> (sorted objdump -x output:)
> 2b78 R_PPC_PLTREL24bus_alloc_resource
> 2b88 R_PPC_PLTREL24rman_get_start
> 2b94 R_PPC_PLTREL24aha_alloc
> 2b96 R_PPC_ADDR32  .debug_str+0x266c
> 2b9c R_PPC_PLTREL24aha_probe
> 2b9f R_PPC_ADDR32  .debug_str+0x1904
> 
> (objdump -d --prefix-addresses output:)
> 2aa4  mflrr0
> . . .
> 2b7c  cmplwi  r3,0
> 2b80  stw r3,188(r28)
> 2b84

r322076 breaks vtnet connectivity

2017-08-10 Thread Ian FREISLICH 

Hi

I have a host on Digital Ocean (qemu) and the change in r322076 breaks 
my vtnet0 interface.  The interface still comes up but does not pass 
traffic any more.  It's not obvious to my why the changes from r322075 
to r322076 affect the vtnet interface.


Ian

--
Ian Freislich


--


Cape Augusta Digital Properties, LLC a Cape Augusta Company

*Breach of confidentiality & accidental breach of confidentiality *

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

___
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: [322369] buildkernel failure: error: use of undeclared identifier 'mp_ncpus'

2017-08-10 Thread Ryan Libby 
On Thu, Aug 10, 2017 at 9:51 AM, O. Hartmann  wrote:
> r322369 fails to build a kernel due to:
>
>
> --- mptable.o ---
> /usr/src/sys/x86/x86/mptable.c:480:39: error: use of undeclared identifier 
> 'mp_ncpus'
> proc->apic_id < MAX_LAPIC_ID && mp_ncpus < MAXCPU) {
> ^
> /usr/src/sys/x86/x86/mptable.c:481:4: error: use of undeclared identifier 
> 'mp_ncpus'
> mp_ncpus++;
> ^
> /usr/src/sys/x86/x86/mptable.c:482:4: error: use of undeclared identifier 
> 'mp_maxid'
> mp_maxid = mp_ncpus - 1;
> ^
> /usr/src/sys/x86/x86/mptable.c:482:15: error: use of undeclared identifier 
> 'mp_ncpus'
> mp_maxid = mp_ncpus - 1;
>^
> 8 errors generated.
> *** [mptable.o] Error code 1
>

Yes, emaste identified this as related to r322347:
https://lists.freebsd.org/pipermail/svn-src-head/2017-August/103426.html
___
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"

[322369] buildkernel failure: error: use of undeclared identifier 'mp_ncpus'

2017-08-10 Thread O. Hartmann 
r322369 fails to build a kernel due to:


--- mptable.o ---
/usr/src/sys/x86/x86/mptable.c:480:39: error: use of undeclared identifier 
'mp_ncpus'
proc->apic_id < MAX_LAPIC_ID && mp_ncpus < MAXCPU) {
^
/usr/src/sys/x86/x86/mptable.c:481:4: error: use of undeclared identifier 
'mp_ncpus'
mp_ncpus++;
^
/usr/src/sys/x86/x86/mptable.c:482:4: error: use of undeclared identifier 
'mp_maxid'
mp_maxid = mp_ncpus - 1;
^
/usr/src/sys/x86/x86/mptable.c:482:15: error: use of undeclared identifier 
'mp_ncpus'
mp_maxid = mp_ncpus - 1;
   ^
8 errors generated.
*** [mptable.o] Error code 1

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpi9IaFxlwT3.pgp
Description: OpenPGP digital signature

Re: Would O_APPEND for /dev/null be possible?

2017-08-10 Thread Steffen Nurpmeso 
and i wrote:
  ...
 |The POSIX standard says that the error condition shall be set if
 |a read or write error occurs only, but this should not be the case
 |here, no?  So looking at [master]:lib/libc/stdio/fseek.c:_fseeko()
 |(note my machine is not strong enough to compile any compiler (but
 |pcc, tcc) or even operating systems, i cannot verify) there is
 |only one condition where the stream error indicator is set, after
 |the dumb: label.
 |
 |I would expect the error indicator for a failing __srefill() or
 |__sflush() (only: not following branches), but _here_ it is set
 |for a "long overflow" check failure.  This looks wrong to me, but
 |of course: without having any idea nor test possibilities.  Also
 |note this is 32-bit FreeBSD, can it be that /dev/null -2L,SEEK_END
 |sees enters 64-bit range?  That also feels wrong, for /dev/null
 |anyway, where it should not matter and simply succeed.  (The
 |tested OpenBSD was 32-bit, too.)

Also, the return of fseek(3) is "int", so testing LONG_MAX looks
a bit odd as such, from my point of view?

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
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: Would O_APPEND for /dev/null be possible?

2017-08-10 Thread Steffen Nurpmeso 
i wrote:
 |Bryan Drewery  wrote:
 ||On 8/7/2017 2:36 PM, Steffen Nurpmeso wrote:
 ||> I can open a file with "a+", which, for this software, means
 ||> "O_RDWR | O_APPEND | O_CREAT | n_O_NOFOLLOW" on Linux, Solaris and
 ||> OpenBSD, but FreeBSD complains, i think because O_APPEND.  (I
 | ...
 ||> openat(AT_FDCWD,"/dev/null",O_RDWR|O_APPEND|O_NOFOLLOW|O_CREAT,037625\
 ||> 2\
 ||> 0) = 3 (0x3)
 ||
 ||Seems to work fine.
 ..
 |locking, so i thought ...  Hmm, this is even more complicated than
 |i thought, wait, i have to debug that.  And: it turns out that
 |a fseek(3) on the descriptor opened not only fails but sets the
 |ferror(3) state of the FILE!  I would need to look into the
 |standard whether this behaviour is correct, but in any case we are
 |not prepared for that, and neither of Linux, Solaris nor OpenBSD
 |enter this condition.

The POSIX standard says that the error condition shall be set if
a read or write error occurs only, but this should not be the case
here, no?  So looking at [master]:lib/libc/stdio/fseek.c:_fseeko()
(note my machine is not strong enough to compile any compiler (but
pcc, tcc) or even operating systems, i cannot verify) there is
only one condition where the stream error indicator is set, after
the dumb: label.

I would expect the error indicator for a failing __srefill() or
__sflush() (only: not following branches), but _here_ it is set
for a "long overflow" check failure.  This looks wrong to me, but
of course: without having any idea nor test possibilities.  Also
note this is 32-bit FreeBSD, can it be that /dev/null -2L,SEEK_END
sees enters 64-bit range?  That also feels wrong, for /dev/null
anyway, where it should not matter and simply succeed.  (The
tested OpenBSD was 32-bit, too.)

Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
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: [autofs] problems with "dirty" UFS2 partitions

2017-08-10 Thread Edward Tomasz Napierała 
On 0808T0717, O. Hartmann wrote:
> Hello,
> 
> we're running a NanoBSD based appliance which resides on a small SoC and
> utilises a mSATA SSD for logging, database storage and mail folder. The
> operating system is recent CURRENT as it is still under development.
> 
> The problem ist, that from time to time, without knowing or seeing the reason,
> the automounted partitions become "dirty (UFS2 partitions, no ZFS dur to
> memory and performance limitations). Journaling is enbaled.
> 
> When the partitions on the SSD become "dirty", logging or accessing them isn't
> possible anymore and for some reason I do not see any log entries reporting
> this (maybe due to the fact all logs are going also to that disk since the 
> logs
> would pollute the serial console/console and the console is used for
> maintenance purposes/ssh terminal).
> 
> Is it possible to - automated! - check the filesystem on bootup? As on 
> ordinary
> FreeBSD systems with fstab-based filesystems, this happens due to the
> rc-init-infrastructure but autofs filesystems seem to be somehow standing 
> aside
> from this procedure.

There are several ways.  The easiest of them - since you probably know
the device name upfront - is what Warner suggested: add it to fstab(5)
with the "noauto" option, and then maybe use the -noauto autofs map
(see auto_master(5) man page to see what it does).

If you don't know the exact device name, you could add a call to fsck
to /etc/autofs/special_media, somewhere in print_map_entry() function.
It's the script that automountd(8) runs to figure out what devices are
available for mounting, and how to mount them.  You might need to
increase the vfs.autofs.timeout sysctl, though.

Yet another would be to run fsck from devd(8), on "GEOM" event,
as documented in devd.conf(5).

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