Re: arm64: add a new MID

2016-11-24 Thread Theo de Raadt
OK with me.

The selection of those numbers used to follow various other "standards",
but that is not important these days.

> this adds an MID entry for arm64.  That's the next reasonable one in the
> list.
> 
> ok?
> 
> Patrick
> 
> diff --git a/sys/sys/exec.h b/sys/sys/exec.h
> index cd0a8c4..8bcfc04 100644
> --- a/sys/sys/exec.h
> +++ b/sys/sys/exec.h
> @@ -287,6 +287,7 @@ struct exec {
>  #define  MID_HPPA154 /* hppa */
>  #define  MID_AMD64   157 /* AMD64 */
>  #define  MID_MIPS64  158 /* big-endian MIPS64 */
> +#define  MID_ARM64   159 /* ARM64 */
>  #define  MID_HP200   200 /* hp200 (68010) BSD binary */
>  #define  MID_HP300   300 /* hp300 (68020+68881) BSD binary */
>  #define  MID_HPUX0x20C   /* hp200/300 HP-UX binary */
> 



arm64: add a new MID

2016-11-24 Thread Patrick Wildt
Hi,

this adds an MID entry for arm64.  That's the next reasonable one in the
list.

ok?

Patrick

diff --git a/sys/sys/exec.h b/sys/sys/exec.h
index cd0a8c4..8bcfc04 100644
--- a/sys/sys/exec.h
+++ b/sys/sys/exec.h
@@ -287,6 +287,7 @@ struct exec {
 #defineMID_HPPA154 /* hppa */
 #defineMID_AMD64   157 /* AMD64 */
 #defineMID_MIPS64  158 /* big-endian MIPS64 */
+#defineMID_ARM64   159 /* ARM64 */
 #defineMID_HP200   200 /* hp200 (68010) BSD binary */
 #defineMID_HP300   300 /* hp300 (68020+68881) BSD binary */
 #defineMID_HPUX0x20C   /* hp200/300 HP-UX binary */



GPT->softraid0: Failed to install bootblocks

2016-11-24 Thread Leo Unglaub

Hey,
i am trying to install OpenBSD on a Raid1 created by softraid0. My 
drives are sd0 and sd1. The created raid1 is sd3. The install works fine 
until OpenBSD tryes to write the bootblocks. But it fails with the error 
message: "Failed to install bootblocks".


If its not possible to do this setup with GTP enabled the installer 
should exit with a better error message. I tryed this in the 6.0 release 
and in the latest snapshot. Both have the same issue.


I tryed an amd64 image. I added you a dmesg output from when i installed 
it without the raid on the device.


I also added your some "screenshots" :)

  * http://i.imgur.com/2aEQDky.jpg
  * http://i.imgur.com/hkYLOlK.jpg
  * http://i.imgur.com/HypY4qd.jpg


Thanks and greetings
Leo
OpenBSD 6.0 (RAMDISK_CD) #2100: Tue Jul 26 13:05:59 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 8382631936 (7994MB)
avail mem = 8126865408 (7750MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (69 entries)
bios0: vendor LENOVO version "G2ET95WW (2.55 )" date 07/09/2013
bios0: LENOVO 232495G
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! 
UEFI UEFI MSDM SSDT SSDT SSDT UEFI DBG2 BGRT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.79 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 4 (EXP3)
acpicpu at acpi0 not configured
acpipwrres at acpi0 not configured
acpitz at acpi0 not configured
"PNP0C0D" at acpi0 not configured
"PNP0C0E" at acpi0 not configured
"LEN0071" at acpi0 not configured
"LEN0020" at acpi0 not configured
"SMO1200" at acpi0 not configured
"PNP0C0A" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"LEN0078" at acpi0 not configured
"LEN0068" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT3392" at acpi0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
"Intel HD Graphics 4000" rev 0x09 at pci0 dev 2 function 0 not configured
xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address 
3c:97:0e:cd:bb:35
ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
"Intel 7 Series HD Audio" rev 0x04 at pci0 dev 27 function 0 not configured
ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: msi
pci1 at ppb0 bus 2
sdhc0 at pci1 dev 0 function 0 "Ricoh 5U822 SD/MMC" rev 0x07: apic 2 int 16
sdhc0: SDHC 3.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma
ppb1 at pci0 dev 28 function 1 "Intel 7 Series PCIE" rev 0xc4: msi
pci2 at ppb1 bus 3
iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
MIMO 2T2R, MoW, address 8c:70:5a:59:e8:48
ppb2 at pci0 dev 28 function 2 "Intel 7 Series PCIE" rev 0xc4: msi
pci3 at ppb2 bus 4
ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 23
usb2 at ehci1: USB revision 2.0
uhub2 at usb2 "Intel EHCI root hub" rev 2.00/1.00 addr 1
"Intel QM77 LPC" rev 0x04 at pci0 dev 31 function 0 not configured
ahci0 at pci0 dev 31 function 2 "Intel 7 Series AHCI" rev 0x04: msi, AHCI 1.3
ahci0: port 0: 6.0Gb/s
ahci0: port 2: 3.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct fixed 
naa.50025388a03f679d
sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
sd1 at scsibus0 targ 2 lun 0:  SCSI3 0/direct fixed 
naa.00232d00
sd1: 122104MB, 512 bytes/sector, 250069680 sectors, thin
"Intel 7 Series SMBus" rev 0x04 at pci0 dev 31 function 3 not configured
isa0 at mainbus0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
efifb0 at mainbus0: 1366x768, 32bpp
wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
umass0 at uhub0 port 2 configuration 1 interface 0 

Re: LLVM: use OpenBSD target code for AArch64

2016-11-24 Thread Patrick Wildt
On Fri, Nov 25, 2016 at 12:44:44AM +0100, Joerg Sonnenberger wrote:
> On Fri, Nov 25, 2016 at 12:37:10AM +0100, Patrick Wildt wrote:
> > This diff makes LLVM do all the OpenBSD stuff for AArch64.
> > 
> > ok?
> 
> If you plan to submit this upstream, you should also update the test
> cases accordingly.
> 
> Joerg
> 

As far as I know we did not import the tests, so there's no way I can
update those in our tree.

Patrick



Re: LLVM: use OpenBSD target code for AArch64

2016-11-24 Thread Joerg Sonnenberger
On Fri, Nov 25, 2016 at 12:37:10AM +0100, Patrick Wildt wrote:
> This diff makes LLVM do all the OpenBSD stuff for AArch64.
> 
> ok?

If you plan to submit this upstream, you should also update the test
cases accordingly.

Joerg



arm64: add ELF machine id for AArch64

2016-11-24 Thread Patrick Wildt
Hi,

ARM IHI 0056B, the ELF spec for the ARM 64-bit Architecture, specifies
the following for the ELF e_machine attribute:

An object file conforming to this specification must have the value
EM_AARCH64 (183, 0xB7).

ok?

Patrick

diff --git a/sys/sys/exec_elf.h b/sys/sys/exec_elf.h
index 5b24563..2e17788 100644
--- a/sys/sys/exec_elf.h
+++ b/sys/sys/exec_elf.h
@@ -194,6 +194,7 @@ typedef struct {
 #define EM_IA_64   50  /* Intel IA-64 Processor */
 #define EM_AMD64   62  /* AMD64 architecture */
 #define EM_VAX 75  /* DEC VAX */
+#define EM_AARCH64 183 /* ARM 64-bit architecture (AArch64) */
 
 /* Non-standard */
 #define EM_ALPHA_EXP   0x9026  /* DEC ALPHA */



LLVM: use OpenBSD target code for AArch64

2016-11-24 Thread Patrick Wildt
Hi,

a clang binary using the AArch64 backend currently does not use
proper OpenBSD defines and specifics.  This is because we don't
tell clang to use OpenBSD target info if it encounters an AArch64
target.

This diff makes LLVM do all the OpenBSD stuff for AArch64.

ok?

Patrick

diff --git a/gnu/llvm/tools/clang/lib/Basic/Targets.cpp 
b/gnu/llvm/tools/clang/lib/Basic/Targets.cpp
index 1b88184..d65c88a 100644
--- a/gnu/llvm/tools/clang/lib/Basic/Targets.cpp
+++ b/gnu/llvm/tools/clang/lib/Basic/Targets.cpp
@@ -7551,6 +7551,8 @@ static TargetInfo *AllocateTarget(const llvm::Triple 
) {
   return new LinuxTargetInfo(Triple);
 case llvm::Triple::NetBSD:
   return new NetBSDTargetInfo(Triple);
+case llvm::Triple::OpenBSD:
+  return new OpenBSDTargetInfo(Triple);
 default:
   return new AArch64leTargetInfo(Triple);
 }



Re: vio(4): fixup crash on up/down

2016-11-24 Thread Mike Belopuhov
On Wed, Nov 23, 2016 at 21:10 +0100, Stefan Fritsch wrote:
> On Wed, 23 Nov 2016, Rafael Zalamena wrote:
> 
> > > Maybe something like this is enough already (untested):
> > 
> > I tried your diff without Mike's if_vio diff and it doesn't panic anymore,
> > however it doesn't work.
> > 
> > vioX can send packets to host, host receives them and reply, but vioX
> > doesn't see any packets back. I don't even need to touch the interface
> > up/down status to see this happening. Also when the interface comes
> > up after being shutdown it sends a bunch of packets to host.
> 
> Sorry, device_status is a bitmask, not a plain value.
> 
> Try the patch below. The first hunk is to fix the 'sends a bunch of 
> packets'. If it causes any problems, leave it out.
> 
> diff --git usr.sbin/vmd/virtio.c usr.sbin/vmd/virtio.c
> index 93def73..6436e6a 100644
> --- usr.sbin/vmd/virtio.c
> +++ usr.sbin/vmd/virtio.c
> @@ -703,6 +703,13 @@ virtio_net_io(int dir, uint16_t reg, uint32_t *data, 
> uint8_t *intr,
>   break;
>   case VIRTIO_CONFIG_DEVICE_STATUS:
>   dev->cfg.device_status = *data;
> + if (*data == 0) {
> + dev->vq[0].last_avail = 0;
> + dev->vq[0].notified_avail = 0;
> + dev->vq[1].last_avail = 0;
> + dev->vq[1].notified_avail = 0;
> + /* XXX do proper reset */
> + }
>   break;
>   default:
>   break;
> @@ -796,6 +803,9 @@ vionet_enq_rx(struct vionet_dev *dev, char *pkt, ssize_t 
> sz, int *spc)
>  
>   ret = 0;
>  
> + if (!(dev->cfg.device_status & VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK))
> + return ret;
> +
>   vr_sz = vring_size(VIONET_QUEUE_SIZE);
>   q_gpa = dev->vq[0].qa;
>   q_gpa = q_gpa * VIRTIO_PAGE_SIZE;
> 

This diff works fine, huge thanks for stepping in!



Re: [PATCH] List Sierra Wireless EM7455 as supported umb(4) device

2016-11-24 Thread Bryan Vyhmeister
On Thu, Nov 24, 2016 at 06:56:42PM +, Jason McIntyre wrote:
> ah. i have a habit of committing diffs from developers because i keep
> losing track of who has commit. this time i'm giving oks to people
> without commit...
> 
> fixed, thanks for the mail, and sorry about the (perpetual) confusion.

No problem at all. I understand and I definitely see how it gets
confusing.

Bryan



Re: List Ericsson N5321gw as supported umb(4) device

2016-11-24 Thread Ingo Feinerer
On Thu, Nov 24, 2016 at 07:01:52PM +0100, Otto Moerbeek wrote:
> On Wed, Nov 23, 2016 at 08:56:53PM +0100, Ingo Feinerer wrote:
> > the "Lenovo N5321gw" is working for me with umb(4)
> > (https://marc.info/?l=openbsd-misc=147992993614369=2). So mention it
> > as a supported device in umb.4?
> > 
> > (Lenovo seems to call it Ericsson N5321gw on its support sites, so I'll
> > use this wording.)
> > 
> > OK?
> 
> This is a different card than Lenovo H5321gw, right?  I have that one,
> but there are some problems with which make it work non-optimal.
> These problems are being ironed out as we speak.

I do not know. The Lenovo support site is quite confusing for me:
http://support.lenovo.com/downloads/ds039685

Lenovo lists a single firmware for H5321gw/C5621gw/N5321gw but on the other
side different names are explicitly used:

$ usbdevs -v
port 4 addr 2: high speed, self powered, config 1, N5321 gw(0x193e), 
Lenovo(0x0bdb), rev 0.00

Best regards,
Ingo



Re: [PATCH] List Sierra Wireless EM7455 as supported umb(4) device

2016-11-24 Thread Jason McIntyre
On Thu, Nov 24, 2016 at 10:36:42AM -0800, Bryan Vyhmeister wrote:
> On Wed, Nov 23, 2016 at 04:20:25PM -0800, Bryan Vyhmeister wrote:
> > I forgot about adding the newly supported Sierra Wireless EM7455 to the
> > umb(4) man page.
> > 
> > Bryan
> > 
> > 
> > Index: share/man/man4/umb.4
> > ===
> > RCS file: /cvs/src/share/man/man4/umb.4,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 umb.4
> > --- share/man/man4/umb.423 Nov 2016 20:23:54 -  1.5
> > +++ share/man/man4/umb.424 Nov 2016 00:17:39 -
> > @@ -46,6 +46,7 @@ The following devices should work:
> >  .Bl -tag -width Ds -offset indent -compact
> >  .It Ericsson N5321gw
> >  .It Medion Mobile S4222 (MediaTek OEM)
> > +.It Sierra Wireless EM7455
> >  .It Sierra Wireless EM8805
> >  .It Sierra Wireless MC8305
> >  .El
> > 
> 
> I have an ok from jmc. Could someone commit this? Thank you.
> 
> Bryan
> 

ah. i have a habit of committing diffs from developers because i keep
losing track of who has commit. this time i'm giving oks to people
without commit...

fixed, thanks for the mail, and sorry about the (perpetual) confusion.

jmc



Re: [PATCH] List Sierra Wireless EM7455 as supported umb(4) device

2016-11-24 Thread Bryan Vyhmeister
On Wed, Nov 23, 2016 at 04:20:25PM -0800, Bryan Vyhmeister wrote:
> I forgot about adding the newly supported Sierra Wireless EM7455 to the
> umb(4) man page.
> 
> Bryan
> 
> 
> Index: share/man/man4/umb.4
> ===
> RCS file: /cvs/src/share/man/man4/umb.4,v
> retrieving revision 1.5
> diff -u -p -r1.5 umb.4
> --- share/man/man4/umb.4  23 Nov 2016 20:23:54 -  1.5
> +++ share/man/man4/umb.4  24 Nov 2016 00:17:39 -
> @@ -46,6 +46,7 @@ The following devices should work:
>  .Bl -tag -width Ds -offset indent -compact
>  .It Ericsson N5321gw
>  .It Medion Mobile S4222 (MediaTek OEM)
> +.It Sierra Wireless EM7455
>  .It Sierra Wireless EM8805
>  .It Sierra Wireless MC8305
>  .El
> 

I have an ok from jmc. Could someone commit this? Thank you.

Bryan



Re: List Ericsson N5321gw as supported umb(4) device

2016-11-24 Thread Otto Moerbeek
On Wed, Nov 23, 2016 at 08:56:53PM +0100, Ingo Feinerer wrote:

> Hi,
> 
> the "Lenovo N5321gw" is working for me with umb(4)
> (https://marc.info/?l=openbsd-misc=147992993614369=2). So mention it
> as a supported device in umb.4?
> 
> (Lenovo seems to call it Ericsson N5321gw on its support sites, so I'll
> use this wording.)
> 
> OK?

This is a different card than Lenovo H5321gw, right?  I have that one,
but there are some problems with which make it work non-optimal.
These problems are being ironed out as we speak.

-Otto

> 
> Best regards,
> Ingo
> 
> Index: umb.4
> ===
> RCS file: /cvs/src/share/man/man4/umb.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 umb.4
> --- umb.4 22 Aug 2016 06:45:12 -  1.4
> +++ umb.4 23 Nov 2016 19:27:23 -
> @@ -44,6 +44,7 @@ PIN again even if the system was reboote
>  The following devices should work:
>  .Pp
>  .Bl -tag -width Ds -offset indent -compact
> +.It Ericsson N5321gw
>  .It Medion Mobile S4222 (MediaTek OEM)
>  .It Sierra Wireless EM8805
>  .It Sierra Wireless MC8305



Re: Possible typos in find(1) man page

2016-11-24 Thread Senthil Kumar M
Hi Otto,

Thank you for the clarifications. Indeed reading the man page more 
carefully I understood the difference between option and expression, and 
using -prune.

Sorry for the noise.

Senthil

On Thu, 24 Nov 2016, Otto Moerbeek wrote:

> On Thu, Nov 24, 2016 at 04:42:37PM +0100, Senthil Kumar M wrote:
> 
> > Hello Tech,
> > 
> > In the find(1) man page, for the option `-f': 
> > 
> >  -f path
> >  Specifies a file hierarchy for find to traverse.  File
> >  hierarchies may be specified without the -f option if they are
> >  given immediately after any other options.
> > 
> > shouldn't this be `before' instead of `after'?
> 
> No, look at the synopsis. An option is not the same as an expression.
> 
> > 
> > Also, in the third listed example in EXAMPLES:
> > 
> >Print out a list of all core files on local file systems:
> > 
> >$ find / \! -fstype local -prune -o -name '*.core'
> > 
> > shouldn't this be instead:
> > $ find / -fstype local -prune -o -name '*.core'
> 
> No, look at the definition of -prune. You want to prevent find to go
> into a non-local fs. You version makes the prune active on any local
> filesystem.  Try it.
> 
>   -Otto
> 
> > 
> > The following diff incorporates these two changes.
> > 
> > Senthil
> > 
> > Index: find.1
> > ===
> > RCS file: /cvs/src/usr.bin/find/find.1,v
> > retrieving revision 1.91
> > diff -u -p -r1.91 find.1
> > --- find.1  11 Sep 2015 18:58:16 -  1.91
> > +++ find.1  24 Nov 2016 12:17:16 -
> > @@ -86,7 +86,7 @@ Specifies a file hierarchy for
> >  to traverse.
> >  File hierarchies may be specified without the
> >  .Fl f
> > -option if they are given immediately after any other options.
> > +option if they are given immediately before any other options.
> >  .It Fl H
> >  Causes the file information and file type (see
> >  .Xr stat 2 )
> > @@ -546,7 +546,7 @@ and owned by
> >  .Pp
> >  Print out a list of all core files on local file systems:
> >  .Pp
> > -.Dl "$ find / \e! -fstype local -prune -o -name '*.core'"
> > +.Dl "$ find / -fstype local -prune -o -name '*.core'"
> >  .Pp
> >  Find all files in
> >  .Pa /usr/src
> 



Re: Possible typos in find(1) man page

2016-11-24 Thread Otto Moerbeek
On Thu, Nov 24, 2016 at 04:42:37PM +0100, Senthil Kumar M wrote:

> Hello Tech,
> 
> In the find(1) man page, for the option `-f': 
> 
>  -f path
>  Specifies a file hierarchy for find to traverse.  File
>  hierarchies may be specified without the -f option if they are
>  given immediately after any other options.
> 
> shouldn't this be `before' instead of `after'?

No, look at the synopsis. An option is not the same as an expression.

> 
> Also, in the third listed example in EXAMPLES:
> 
>Print out a list of all core files on local file systems:
> 
>$ find / \! -fstype local -prune -o -name '*.core'
> 
> shouldn't this be instead:
> $ find / -fstype local -prune -o -name '*.core'

No, look at the definition of -prune. You want to prevent find to go
into a non-local fs. You version makes the prune active on any local
filesystem.  Try it.

-Otto

> 
> The following diff incorporates these two changes.
> 
> Senthil
> 
> Index: find.1
> ===
> RCS file: /cvs/src/usr.bin/find/find.1,v
> retrieving revision 1.91
> diff -u -p -r1.91 find.1
> --- find.111 Sep 2015 18:58:16 -  1.91
> +++ find.124 Nov 2016 12:17:16 -
> @@ -86,7 +86,7 @@ Specifies a file hierarchy for
>  to traverse.
>  File hierarchies may be specified without the
>  .Fl f
> -option if they are given immediately after any other options.
> +option if they are given immediately before any other options.
>  .It Fl H
>  Causes the file information and file type (see
>  .Xr stat 2 )
> @@ -546,7 +546,7 @@ and owned by
>  .Pp
>  Print out a list of all core files on local file systems:
>  .Pp
> -.Dl "$ find / \e! -fstype local -prune -o -name '*.core'"
> +.Dl "$ find / -fstype local -prune -o -name '*.core'"
>  .Pp
>  Find all files in
>  .Pa /usr/src



Re: LLVM: add Makefile support for AArch64

2016-11-24 Thread Pascal Stumpf
On Thu, 24 Nov 2016 16:16:19 +0100, Patrick Wildt wrote:
> Hi,
> 
> this diff allows us to build clang with AArch64 support.  It's based on
> the ARM lib Makefiles modified to compile the AArch64 code.
> 
> ok?

Looks good to me, and the aarch64/arm64 naming thing can always be
bikeshed later.  ok.

> Patrick
> 
> diff --git a/gnu/usr.bin/clang/Makefile.arch b/gnu/usr.bin/clang/Makefile.arch
> index b372b68..3883c5e 100644
> --- a/gnu/usr.bin/clang/Makefile.arch
> +++ b/gnu/usr.bin/clang/Makefile.arch
> @@ -6,13 +6,15 @@ LLVM_ARCH=  X86
>  LLVM_ARCH=   PowerPC
>  .elif ${MACHINE_ARCH} == "sparc64"
>  LLVM_ARCH=   Sparc
> +.elif ${MACHINE_ARCH} == "aarch64"
> +LLVM_ARCH=   AArch64
>  .elif ${MACHINE_ARCH} == "arm"
>  LLVM_ARCH=   ARM
>  .elif ${MACHINE_ARCH} == "mips64" || ${MACHINE_ARCH} == "mips64el"
>  LLVM_ARCH=   Mips
>  .endif
>  
> -.if !(${LLVM_ARCH} == "X86")
> +.if !(${LLVM_ARCH} == "X86" || ${LLVM_ARCH} == "AArch64")
>  BACKEND_UTILS=
>  .endif
>  
> diff --git a/gnu/usr.bin/clang/include/llvm/AArch64/Makefile 
> b/gnu/usr.bin/clang/include/llvm/AArch64/Makefile
> new file mode 100644
> index 000..ae5fc03
> --- /dev/null
> +++ b/gnu/usr.bin/clang/include/llvm/AArch64/Makefile
> @@ -0,0 +1,92 @@
> +# $OpenBSD: Makefile,v 1.1 2016/09/17 16:43:51 kettenis Exp $
> +
> +.include 
> +
> +LLVM_SRCS=   ${.CURDIR}/../../../../../llvm
> +
> +HDRS=AArch64GenAsmMatcher.inc AArch64GenAsmWriter.inc \
> + AArch64GenAsmWriter1.inc \
> + AArch64GenCallingConv.inc AArch64GenDAGISel.inc \
> + AArch64GenDisassemblerTables.inc AArch64GenFastISel.inc \
> + AArch64GenInstrInfo.inc AArch64GenRegisterInfo.inc \
> + AArch64GenSubtargetInfo.inc \
> + AArch64GenMCCodeEmitter.inc AArch64GenMCPseudoLowering.inc \
> + AArch64GenDisassemblerTables.inc
> +
> +all: ${HDRS}
> +
> +install:
> + # Nothing here so far ...
> +
> +depend:
> + # Nothing here so far ...
> +
> +clean cleandir:
> + rm -f ${HDRS}
> +
> +AArch64GenRegisterInfo.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-register-info \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenDisassemblerTables.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-disassembler \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenInstrInfo.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-instr-info \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenAsmWriter.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-asm-writer \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenAsmWriter1.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-asm-writer \
> + -asmwriternum=1 -I${LLVM_SRCS}/include \
> + -I${LLVM_SRCS}/lib/Target/AArch64 -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenAsmMatcher.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-asm-matcher \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenDAGISel.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-dag-isel \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenFastISel.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-fast-isel \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenCallingConv.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-callingconv \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenSubtargetInfo.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-subtarget \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenMCCodeEmitter.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-emitter \
> + -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
> + -o ${.TARGET} ${.ALLSRC}
> +
> +AArch64GenMCPseudoLowering.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
> + 

Possible typos in find(1) man page

2016-11-24 Thread Senthil Kumar M
Hello Tech,

In the find(1) man page, for the option `-f': 

 -f path
 Specifies a file hierarchy for find to traverse.  File
 hierarchies may be specified without the -f option if they are
 given immediately after any other options.

shouldn't this be `before' instead of `after'?

Also, in the third listed example in EXAMPLES:

   Print out a list of all core files on local file systems:

   $ find / \! -fstype local -prune -o -name '*.core'

shouldn't this be instead:
$ find / -fstype local -prune -o -name '*.core'

The following diff incorporates these two changes.

Senthil

Index: find.1
===
RCS file: /cvs/src/usr.bin/find/find.1,v
retrieving revision 1.91
diff -u -p -r1.91 find.1
--- find.1  11 Sep 2015 18:58:16 -  1.91
+++ find.1  24 Nov 2016 12:17:16 -
@@ -86,7 +86,7 @@ Specifies a file hierarchy for
 to traverse.
 File hierarchies may be specified without the
 .Fl f
-option if they are given immediately after any other options.
+option if they are given immediately before any other options.
 .It Fl H
 Causes the file information and file type (see
 .Xr stat 2 )
@@ -546,7 +546,7 @@ and owned by
 .Pp
 Print out a list of all core files on local file systems:
 .Pp
-.Dl "$ find / \e! -fstype local -prune -o -name '*.core'"
+.Dl "$ find / -fstype local -prune -o -name '*.core'"
 .Pp
 Find all files in
 .Pa /usr/src



LLVM: add Makefile support for AArch64

2016-11-24 Thread Patrick Wildt
Hi,

this diff allows us to build clang with AArch64 support.  It's based on
the ARM lib Makefiles modified to compile the AArch64 code.

ok?

Patrick

diff --git a/gnu/usr.bin/clang/Makefile.arch b/gnu/usr.bin/clang/Makefile.arch
index b372b68..3883c5e 100644
--- a/gnu/usr.bin/clang/Makefile.arch
+++ b/gnu/usr.bin/clang/Makefile.arch
@@ -6,13 +6,15 @@ LLVM_ARCH=X86
 LLVM_ARCH= PowerPC
 .elif ${MACHINE_ARCH} == "sparc64"
 LLVM_ARCH= Sparc
+.elif ${MACHINE_ARCH} == "aarch64"
+LLVM_ARCH= AArch64
 .elif ${MACHINE_ARCH} == "arm"
 LLVM_ARCH= ARM
 .elif ${MACHINE_ARCH} == "mips64" || ${MACHINE_ARCH} == "mips64el"
 LLVM_ARCH= Mips
 .endif
 
-.if !(${LLVM_ARCH} == "X86")
+.if !(${LLVM_ARCH} == "X86" || ${LLVM_ARCH} == "AArch64")
 BACKEND_UTILS=
 .endif
 
diff --git a/gnu/usr.bin/clang/include/llvm/AArch64/Makefile 
b/gnu/usr.bin/clang/include/llvm/AArch64/Makefile
new file mode 100644
index 000..ae5fc03
--- /dev/null
+++ b/gnu/usr.bin/clang/include/llvm/AArch64/Makefile
@@ -0,0 +1,92 @@
+# $OpenBSD: Makefile,v 1.1 2016/09/17 16:43:51 kettenis Exp $
+
+.include 
+
+LLVM_SRCS= ${.CURDIR}/../../../../../llvm
+
+HDRS=  AArch64GenAsmMatcher.inc AArch64GenAsmWriter.inc \
+   AArch64GenAsmWriter1.inc \
+   AArch64GenCallingConv.inc AArch64GenDAGISel.inc \
+   AArch64GenDisassemblerTables.inc AArch64GenFastISel.inc \
+   AArch64GenInstrInfo.inc AArch64GenRegisterInfo.inc \
+   AArch64GenSubtargetInfo.inc \
+   AArch64GenMCCodeEmitter.inc AArch64GenMCPseudoLowering.inc \
+   AArch64GenDisassemblerTables.inc
+
+all: ${HDRS}
+
+install:
+   # Nothing here so far ...
+
+depend:
+   # Nothing here so far ...
+
+clean cleandir:
+   rm -f ${HDRS}
+
+AArch64GenRegisterInfo.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-register-info \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenDisassemblerTables.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-disassembler \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenInstrInfo.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-instr-info \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenAsmWriter.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-asm-writer \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenAsmWriter1.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-asm-writer \
+   -asmwriternum=1 -I${LLVM_SRCS}/include \
+   -I${LLVM_SRCS}/lib/Target/AArch64 -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenAsmMatcher.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-asm-matcher \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenDAGISel.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-dag-isel \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenFastISel.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-fast-isel \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenCallingConv.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-callingconv \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenSubtargetInfo.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-subtarget \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenMCCodeEmitter.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-emitter \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenMCPseudoLowering.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen -gen-pseudo-lowering \
+   -I${LLVM_SRCS}/include -I${LLVM_SRCS}/lib/Target/AArch64 \
+   -o ${.TARGET} ${.ALLSRC}
+
+AArch64GenDisassemblerTables.inc: ${LLVM_SRCS}/lib/Target/AArch64/AArch64.td
+   ${.OBJDIR}/../../../llvm-tblgen/llvm-tblgen 

Re: vio(4): fixup crash on up/down

2016-11-24 Thread Rafael Zalamena
On Wed, Nov 23, 2016 at 09:10:44PM +0100, Stefan Fritsch wrote:
> On Wed, 23 Nov 2016, Rafael Zalamena wrote:
> 
> > > Maybe something like this is enough already (untested):
> > 
> > I tried your diff without Mike's if_vio diff and it doesn't panic anymore,
> > however it doesn't work.
> > 
> > vioX can send packets to host, host receives them and reply, but vioX
> > doesn't see any packets back. I don't even need to touch the interface
> > up/down status to see this happening. Also when the interface comes
> > up after being shutdown it sends a bunch of packets to host.
> 
> Sorry, device_status is a bitmask, not a plain value.
> 
> Try the patch below. The first hunk is to fix the 'sends a bunch of 
> packets'. If it causes any problems, leave it out.

This diff fixes the panic and makes the interface work again after a 'down'.

Thank you and Mike for fixing this. I'm going to play with this
more today and I can give feedbacks later if anything bad happens.

> 
> diff --git usr.sbin/vmd/virtio.c usr.sbin/vmd/virtio.c
> index 93def73..6436e6a 100644
> --- usr.sbin/vmd/virtio.c
> +++ usr.sbin/vmd/virtio.c
> @@ -703,6 +703,13 @@ virtio_net_io(int dir, uint16_t reg, uint32_t *data, 
> uint8_t *intr,
>   break;
>   case VIRTIO_CONFIG_DEVICE_STATUS:
>   dev->cfg.device_status = *data;
> + if (*data == 0) {
> + dev->vq[0].last_avail = 0;
> + dev->vq[0].notified_avail = 0;
> + dev->vq[1].last_avail = 0;
> + dev->vq[1].notified_avail = 0;
> + /* XXX do proper reset */
> + }
>   break;
>   default:
>   break;
> @@ -796,6 +803,9 @@ vionet_enq_rx(struct vionet_dev *dev, char *pkt, ssize_t 
> sz, int *spc)
>  
>   ret = 0;
>  
> + if (!(dev->cfg.device_status & VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK))
> + return ret;
> +
>   vr_sz = vring_size(VIONET_QUEUE_SIZE);
>   q_gpa = dev->vq[0].qa;
>   q_gpa = q_gpa * VIRTIO_PAGE_SIZE;