Netbooting Sparc64

[Andrew Grillet]

Does anyone know what could cause this ...

SC Alert: Host System has Reset
\

Sun Fire T200, No Keyboard
Copyright (c) 1998, 2010, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.30.4.b, 16256 MB memory available, Serial #82196894.
Ethernet address 0:14:4f:e6:39:9e, Host ID: 84e6399e.



Bad magic number in disk label
Can't open disk label package
ERROR: boot-read fail
Boot device: net  File and args:
1000 Mbps full duplex  Link up
Requesting Internet Address for 0:14:4f:e6:39:9e
Requesting Internet Address for 0:14:4f:e6:39:9e
Requesting Internet Address for 0:14:4f:e6:39:9e
>> OpenBSD BOOT 1.22
1000 Mbps full duplex  Link up
Using BOOTPARAMS protocol: ip address: 192.168.2.100bootparamd: 'whoami'
call failed
Using BOOTP protocol: ip address: 192.168.2.100, hostname: elk, netmask:
255.255.255.0, gateway: 192.168.2.254
root addr=192.168.2.15 path=/install/
Trying bsd...
1000 Mbps full duplex  Link up
Using BOOTPARAMS protocol: ip address: 192.168.2.100bootparamd: 'whoami'
call failed
Using BOOTP protocol: ip address: 192.168.2.100, hostname: elk, netmask:
255.255.255.0, gateway: 192.168.2.254
root addr=192.168.2.15 path=/install/
1000 Mbps full duplex  Link up
Using BOOTPARAMS protocol: ip address: 192.168.2.100bootparamd: 'whoami'
call failed
Using BOOTP protocol: ip address: 192.168.2.100, hostname: elk, netmask:
255.255.255.0, gateway: 192.168.2.254
root addr=192.168.2.15 path=/install/
Booting /pci@780/pci@0/pci@1/network@0/bsd
8492368@0x100+2736@0x1819550+196552@0x1c0+3997752@0x1c2ffc8
symbols @ 0xfec42400 470285+165+565944+375574 start=0x100
[ using 1413000 bytes of bsd ELF symbol table ]
console is /virtual-devices@100/console@1
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.3 (GENERIC) #480: Sat Mar 24 22:11:46 MDT 2018
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC
real mem = 17045651456 (16256MB)
avail mem = 16729997312 (15954MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: Sun Fire T200
cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1000 MHz
"SUNW,UltraSPARC-T1" at mainbus0 not configured
[repeated for N cpus]
vbus0 at mainbus0
"flashprom" at vbus0 not configured
cbus0 at vbus0
vldc0 at cbus0
vldcp0 at vldc0 chan 0x0: ivec 0x0, 0x1 channel "hvctl"
"ldom-primary" at vldc0 chan 0x1 not configured
"fmactl" at vldc0 chan 0x3 not configured
vldc1 at cbus0
"ldmfma" at vldc1 chan 0x4 not configured
vldc2 at cbus0
vldcp1 at vldc2 chan 0x14: ivec 0x28, 0x29 channel "spds"
"system-management" at vldc2 chan 0xd not configured
vcons0 at vbus0: ivec 0x111, console
vrtc0 at vbus0
"fma" at vbus0 not configured
"sunvts" at vbus0 not configured
"sunmc" at vbus0 not configured
"explorer" at vbus0 not configured
"led" at vbus0 not configured
"flashupdate" at vbus0 not configured
"ncp" at vbus0 not configured
vpci0 at mainbus0: bus 2 to 7, dvma map 8000-
pci0 at vpci0
ppb0 at pci0 dev 0 function 0 "PLX PEX 8532" rev 0xbc
pci1 at ppb0 bus 3
ppb1 at pci1 dev 1 function 0 "PLX PEX 8532" rev 0xbc
pci2 at ppb1 bus 4
em0 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: ivec 0x795, address
00:14:4f:e6:39:9e
em1 at pci2 dev 0 function 1 "Intel 82571EB" rev 0x06: ivec 0x796, address
00:14:4f:e6:39:9f
ppb2 at pci1 dev 2 function 0 "PLX PEX 8532" rev 0xbc
pci3 at ppb2 bus 5
ppb3 at pci1 dev 8 function 0 "PLX PEX 8532" rev 0xbc: msi
pci4 at ppb3 bus 6
ppb4 at pci1 dev 9 function 0 "PLX PEX 8532" rev 0xbc
pci5 at ppb4 bus 7
mpi0 at pci5 dev 0 function 0 "Symbios Logic SAS1064E" rev 0x02: msi
mpi0: UNUSED, firmware 1.9.0.0
scsibus1 at mpi0: 63 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI4
0/direct fixed naa.5000cca0222458c0
vpci1 at mainbus0: bus 2 to 9, dvma map 8000-
pci6 at vpci1
ppb5 at pci6 dev 0 function 0 "PLX PEX 8532" rev 0xbc
pci7 at ppb5 bus 3
ppb6 at pci7 dev 1 function 0 "PLX PEX 8532" rev 0xbc
pci8 at ppb6 bus 4
ppb7 at pci8 dev 0 function 0 "Intel 41210 PCIE-PCIX" rev 0x09
pci9 at ppb7 bus 5
ebus0 at pci9 dev 2 function 0 "Acer Labs M1533 ISA" rev 0x00
com0 at ebus0 addr 3f8-3ff ivec 0x2: ns16550a, 16 byte fifo
ohci0 at pci9 dev 5 function 0 "Acer Labs M5237 USB" rev 0x03: ivec 0x7c1,
version 1.0, legacy support
ohci1 at pci9 dev 6 function 0 "Acer Labs M5237 USB" rev 0x03: ivec 0x7c3,
version 1.0, legacy support
pciide0 at pci9 dev 8 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc4: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using ivec 0x7c4 for native-PCI interrupt
atapiscsi0 at pciide0 channel 0 drive 0
scsibus2 at atapiscsi0: 2 targets
cd0 at scsibus2 targ 0 lun 0:  ATAPI 5/cdrom
removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Acer Labs OHCI root hub" rev
1.00/1.00 addr 1
usb1 at ohci1: USB 

Re: httpd.conf grammar

[Andrew Grillet]

I favour a fuller explanation, this one is fine by me.

On Sun, 21 Mar 2021 at 17:20, Laurence Tratt  wrote:
>
> I wanted to use httpd's fastcgi "socket" and "strip" options and based upon
> the man page's brief text:
>
>  [no] fastcgi [option]
>  Enable FastCGI instead of serving files.  Valid options are:
>
> tried "obvious" permutations such as:
>
>   fastcgi strip 1 socket "..."
>   fastcgi socket "..." strip 1
>   fastcgi socket "...", strip 1
>
> but with each was greeted by a terse "syntax error".
>
> After hunting around in the relevant parse.y file, it transpires that the
> grammar allows, roughly speaking, the following:
>
>   fastcgi
>   fastcgi option
>   fastcgi { option ((',' '\n'? | '\n') option)* }
>
> In other words, if you want to use more than one option you *have* to use
> the {...} notation, but there's more than one way for options inside curly
> brackets to be separated. In my case I can specify:
>
>   fastcgi {
> socket "..."
> strip 1
>   }
>
> or:
>
>   fastcgi {
> socket "...", strip 1
>   }
>
> or:
>
>   fastcgi {
> socket "...",
> strip 1
>   }
>
> This raised a couple of questions in my mind.
>
> First, stylistically, I'm not quite sure if having three slightly different
> ways of separating multiple options is useful or not. That said, I assume
> that some people might already be taking advantage of this flexibility, so
> perhaps worrying about it now is pointless.
>
> Second, is it worthwhile giving users a hint about what to do when multiple
> options need to be specified? For example, something like:
>
>  [no] fastcgi [option]
>  Enable FastCGI instead of serving files.  If more than option
>  is specified, they must be included inside { ... }, with each
>  option separated by a comma or newline.  Valid options are:
>
> I'm happy to raise a patch if other people think this is worth fixing,
> although I'm not entirely sure if we want to make people aware of the full
> extent of the grammar, or something a little less complete such as the
> suggestion above.
>
>
> Laurie
>

OBSD 6.8 on Sparc64 T2000 - problem ...

[Andrew Grillet]

I have a working T2000 partitioned to have a primary and seven guest
domains,
all running obsd6.7. It has been running live with 5 of the guests live for
several
months with OBSD 6.7. Each guest has two vdisks with the OS on one and app
specific data on the other.

I decided to try out 6.8 on one of the spare guests (that is what they are
there for).
do do this, I stop the guest (if running), unlink the app specific data
file, and replace it
with a link to miniroot68.img, and then do
> ldomctl start -c guest6
the result is what you expect if the baud rate or parity is set wrong -
garbled text.
It looks like it is trying to boot from the first vdisk - which has not
been prepared
(probably all zeros), and the boot eventually fails, so then it  presumably
goes on
to try netbooting.  I am unable to stop the broken boot process, and would
not
know how to reset the baud rate, if that is what is required.

Is this a 6.7/6.8 compatibility issue? a hardware problem? an uninitialised
variable?

What should I do?

Is there a way to set the cmos params of a guest from the primary? (eg to
stop auto-boot?)
eg "ldomctl set auto-boot? false"

I have seen similar issues (looks like wrong baud rate) a long time ago
with a T1000, and AFAICR, the problem went away after cleaning it - but the
T1000 ran hot when dirty, and the T2000 is not hot.

Andrew

Re: Use VGA text mode palette RGB values in rasops(9)

[Andrew Grillet]

As you get older, you gradually get cataracts  -which makes your lenses go
yellow. This has the effect of reducing the contrast you experience
with blue. Blue against back is very problematic, while blue is generally
not great anyway.

Eventually, you need an operation to replace your lenses replaced with
plastic ones, after which you can see ultraviolet.

I am at the stage where dark blue on black is nearly invisible. Probably
most males over 60 will experience this unless already colourblind.
If you are designing UIs you need to know this. And at least some of us
have been Unix users since the 1970's when X did not exist,
and are likely to use text mode a lot.





On Tue, 7 Jul 2020 at 18:37, Stuart Henderson  wrote:

> On 2020/07/07 15:16, Frederic Cambus wrote:
> > Hi tech@,
> >
> > The recent spike of interest around framebuffer consoles has prompted
> > me to revisit a proposal I sent back in early 2017 [1].
> >
> > Aesthetics considerations aside, kettenis@ raised the concern that
> colors
> > from the original rasops palette carefully matched what OpenFirmware
> > uses for the console on sparc64.
>
> ..and they're a good choice on sparc64 console with the pale background
> that the palette is normally used with.
>
> I agree that the blue we have now is a bit too dark against a black
> background.
>
>

Re: kstats for em(4)

[Andrew Grillet]

"unfortunately em(4) covers a lot of chips of different vintages, so if
anyone has a super old one they can try this diff on with kstat enabled
in their kernel config, that would be appreciated."

I have a T2000 - is that old enough?

Re: Include /var/www/tmp into base install

[Andrew Grillet]

For me, the "/var is full" problem can be adequately mitigated by mounting
a separate partition as /var/tmp.

More of an issue, although obviously not major - if there are a large
number of tmp directories, is making sure that they are all
routinely purged. Yes, I know this is down to careless admin practice, but
it happened to me earlier this year.

I can't give them all their own partitions.


On Tue, 7 Apr 2020 at 16:58, Theo de Raadt  wrote:

> Stefan Sperling  wrote:
>
> > On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote:
> > > > The idea was to have /var/www/tmp created by default, but with
> > > > www:www ownership.
> >
> > > Create the directory.  Now as a user, completely fill it.
> >
> > The proposal is to create tmp with www:www ownership, writable only for
> > that user, not like the old /var/tmp which was writable by anyone.
>
> That's not true; the diff created it mode 1777.
>
> A smaller secondary concern is if you can convince software using this
> space,
> from remote, to hog the space too much, and/or lose track of files in
> there.
> Which would also create the fallout problems of "/var is full".
>
> It's a matter of how other /var-using software misbehaves or fails in
> those circumstances.  These concerns have been ignored too long.
>
>

Re: tar confused error messages

[Andrew Grillet]

I would prefer that the name of the directory that cannot be created is
given in the error message. If you are going to
resolve the problem, "permission denied" is of no help at all.

"Creating directory 'path/to/problem' - permission denied" makes it trivial
to fix.


On Sun, 22 Mar 2020 at 12:22, Denis Fondras  wrote:

> On Sun, Mar 22, 2020 at 11:41:55AM +0100, Marc Espie wrote:
> > If tar can't create intermediate directories due to permission
> > issues, the resulting message is confusing:
> >
> > ./tar xf gcc.tar gcc-8.3.0/include/obstack.h
> > tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or
> directory
> >
> > (here I have gcc-8.3.0 owned by root and no permissions)
> >
> > The following patch changes this to:
> >
> > ./tar xf gcc.tar gcc-8.3.0/include/obstack.h
> > tar: Unable to create gcc-8.3.0/include: Permission denied
> > tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or
> directory
> >
>
> Why not use errno on line 106 of file_subs.c ?
> That would yield "Permission denied" on obstack.h and would avoid having 2
> error
> messages.
>
> > okay ? or a better way to do this ?
> >
> > Index: extern.h
> > ===
> > RCS file: /cvs/src/bin/pax/extern.h,v
> > retrieving revision 1.59
> > diff -u -p -r1.59 extern.h
> > --- extern.h  13 Sep 2018 12:33:43 -  1.59
> > +++ extern.h  22 Mar 2020 10:39:53 -
> > @@ -128,7 +128,7 @@ int cross_lnk(ARCHD *);
> >  int chk_same(ARCHD *);
> >  int node_creat(ARCHD *);
> >  int unlnk_exist(char *, int);
> > -int chk_path(char *, uid_t, gid_t);
> > +int chk_path(char *, uid_t, gid_t, int);
> >  void set_ftime(const char *, const struct timespec *,
> >  const struct timespec *, int);
> >  void fset_ftime(const char *, int, const struct timespec *,
> > Index: file_subs.c
> > ===
> > RCS file: /cvs/src/bin/pax/file_subs.c,v
> > retrieving revision 1.54
> > diff -u -p -r1.54 file_subs.c
> > --- file_subs.c   28 Jun 2019 13:34:59 -  1.54
> > +++ file_subs.c   22 Mar 2020 10:39:53 -
> > @@ -102,7 +102,7 @@ file_creat(ARCHD *arcn)
> >   file_mode)) >= 0)
> >   break;
> >   oerrno = errno;
> > - if (nodirs ||
> chk_path(arcn->name,arcn->sb.st_uid,arcn->sb.st_gid) < 0) {
> > + if (nodirs ||
> chk_path(arcn->name,arcn->sb.st_uid,arcn->sb.st_gid, 0) < 0) {
> >   syswarn(1, oerrno, "Unable to create %s",
> arcn->name);
> >   return(-1);
> >   }
> > @@ -316,7 +316,7 @@ mk_link(char *to, struct stat *to_sb, ch
> >   if (linkat(AT_FDCWD, to, AT_FDCWD, from, 0) == 0)
> >   break;
> >   oerrno = errno;
> > - if (!nodirs && chk_path(from, to_sb->st_uid,
> to_sb->st_gid) == 0)
> > + if (!nodirs && chk_path(from, to_sb->st_uid,
> to_sb->st_gid, ign) == 0)
> >   continue;
> >   if (!ign) {
> >   syswarn(1, oerrno, "Could not link to %s from %s",
> to,
> > @@ -458,7 +458,7 @@ badlink:
> >   if (++pass <= 1)
> >   continue;
> >
> > - if (nodirs || chk_path(nm,arcn->sb.st_uid,arcn->sb.st_gid)
> < 0) {
> > + if (nodirs || chk_path(nm,arcn->sb.st_uid,arcn->sb.st_gid,
> 0) < 0) {
> >   syswarn(1, oerrno, "Could not create: %s", nm);
> >   return(-1);
> >   }
> > @@ -590,7 +590,7 @@ unlnk_exist(char *name, int type)
> >   */
> >
> >  int
> > -chk_path(char *name, uid_t st_uid, gid_t st_gid)
> > +chk_path(char *name, uid_t st_uid, gid_t st_gid, int ign)
> >  {
> >   char *spt = name;
> >   char *next;
> > @@ -643,6 +643,8 @@ chk_path(char *name, uid_t st_uid, gid_t
> >* needed directory and continue on
> >*/
> >   if (mkdir(name, S_IRWXU | S_IRWXG | S_IRWXO) == -1) {
> > + if (!ign)
> > + syswarn(1, errno, "Unable to create %s",
> name);
> >   *spt = '/';
> >   retval = -1;
> >   break;
> >
>
>

Re: ldom.conf: Support devlias keyword for vdisk

[Andrew Grillet]

This looks really useful

On Wed, 5 Feb 2020 at 21:38, Klemens Nanni  wrote:

> On Wed, Feb 05, 2020 at 09:35:25PM +0100, Klemens Nanni wrote:
> > Straight forward diff to allow calling disks names:
> >
> >   $ cat ldom.conf
> >   domain guest {
> >   vcpu 4
> >   memory 8G
> >   vnet
> >   vdisk "/var/ldom/guest.img"
> >   vdisk "/var/ldom/miniroot.fs" devalias=miniroot
> >   }
> The same for network would be trivially to add:
>
> vnet devalias=netboot
>
> I have a few domains with two or more vnets, one of them is for
> diskless(8) so the following can be as handy;  it's little change for
> notable convenience:
>
> {ok} boot netboot
>
>

Re: ldom.conf: curly braces in vnet block

[Andrew Grillet]

I have used the mac-addr feature (for netboot reasons). I think this
probably caused me grief
but I assumed I was at fault and did not bother reporting it.

I prefer same line, no curly braces, and accurate documentation. And also
error messages
that are more explicit:
Vnet.conf:4 Syntax error - Unexpected  "{" found.


On Sun, 2 Feb 2020 at 11:20, Klemens Nanni  wrote:

> ldom.conf(5) says
>
> vnet [{keyword=value ...}]
> Assign a vnet(4) network interface to the guest domain.
> This
> keyword can be used multiple times.  The curly braces are
> optional and can contain the following keywords:
>
> But curly braces must not exist:
>
> $ cat -n vnet.conf
> 1  domain guest {
> 2   vcpu 1
> 3   memory 1G
> 4   vnet { mtu=1500 }
> 5  }
> $ ldomctl init-system -n vnet.conf
> vnet.conf:4 syntax error
> $ sed -i /vnet/s,[{}],,g vnet.conf
> $ ldomctl init-system -n vnet.conf ; echo $?
> 0
>
> Since it has been like this for years apparently, the question is which
> part should be fixed:  documentation or code?  I opt for the latter
> since that is what other parsers such as vm.conf(5) do, plus it reads
> much better structurally, imho.
>
> I came across this when implementing specific options for `vdisk', hence
> I copied the `vnet' block and ran into above thing.
>
> Given that noone complained so far about this:  Does anyone use
> `mac-addr' or `mtu'?  If so, do you prefer appending it without curly
> braces on the same line?  I'm curious.
>
>

Re: ldomctl: Add -c to start for automatic console connect

[Andrew Grillet]

Is there any possibility that the same -c option could be added to
> ldomctl panic -c 
It would be very useful.


On Thu, 16 Jan 2020 at 14:31, Klemens Nanni  wrote:

> On Thu, Jan 16, 2020 at 02:27:42PM +0100, Klemens Nanni wrote:
> > Just like vmctl(8), this implements the little convenience for ldomctl:
> >
> >   $ doas ./obj/ldomctl start -c guest4
> >   Connected to /dev/ttyV3 (speed 9600)
> >   ...
> >
> > To avoid duplicate code, I moved the now common exec routine into
> > console_exec() which is used by guest_console() and guest_start().
> Here's with updated usage:
>
> $ ./obj/ldomctl
> usage:  ldomctl delete|select configuration
> ldomctl download directory
> ldomctl dump|list|list-io
> ldomctl init-system [-n] file
> ldomctl create-vdisk -s size file
> ldomctl start [-c] domain
> ldomctl console|panic|status|stop [domain]
>
> OK?
>
>
> Index: ldomctl.8
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.8,v
> retrieving revision 1.24
> diff -u -p -r1.24 ldomctl.8
> --- ldomctl.8   9 Jan 2020 21:30:18 -   1.24
> +++ ldomctl.8   16 Jan 2020 13:02:43 -
> @@ -94,8 +94,12 @@ the default behaviour is to enter
>  .It Cm select Ar configuration
>  Select the next logical domain configuration to use
>  (after resetting the machine).
> -.It Cm start Ar domain
> +.It Cm start Oo Fl c Oc Ar domain
>  Start a guest domain.
> +.Bl -tag -width Fl
> +.It Fl c
> +Automatically connect to the guest console.
> +.El
>  .It Cm status Op Ar domain
>  Display status information for
>  .Ar domain ,
> Index: ldomctl.c
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 ldomctl.c
> --- ldomctl.c   4 Jan 2020 17:30:41 -   1.34
> +++ ldomctl.c   16 Jan 2020 14:24:24 -
> @@ -131,7 +131,10 @@ usage(void)
> "\t%1$s dump|list|list-io\n"
> "\t%1$s init-system [-n] file\n"
> "\t%1$s create-vdisk -s size file\n"
> -   "\t%1$s console|panic|start|status|stop [domain]\n",
> getprogname());
> +   "\t%1$s start [-c] domain\n"
> +   "\t%1$s console|panic|status|stop [domain]\n",
> +   getprogname());
> +
> exit(EXIT_FAILURE);
>  }
>
> @@ -399,23 +402,61 @@ download(int argc, char **argv)
>  }
>
>  void
> +console_exec(uint64_t gid)
> +{
> +   struct guest *guest;
> +   char console_str[8];
> +
> +   if (gid == 0)
> +   errx(1, "no console for primary domain");
> +
> +   TAILQ_FOREACH(guest, _list, link) {
> +   if (guest->gid != gid)
> +   continue;
> +   snprintf(console_str, sizeof(console_str),
> +   "ttyV%llu", guest->gid - 1);
> +
> +   closefrom(STDERR_FILENO + 1);
> +   execl(LDOMCTL_CU, LDOMCTL_CU, "-r", "-l", console_str,
> +   (char *)NULL);
> +   err(1, "failed to open console");
> +   }
> +}
> +
> +void
>  guest_start(int argc, char **argv)
>  {
> struct hvctl_msg msg;
> ssize_t nbytes;
> +   uint64_t gid;
> +   int ch, console = 0;
>
> -   if (argc != 2)
> +   while ((ch = getopt(argc, argv, "c")) != -1) {
> +   switch (ch) {
> +   case 'c':
> +   console = 1;
> +   break;
> +   default:
> +   usage();
> +   }
> +   }
> +   argc -= optind;
> +   argv += optind;
> +
> +   if (argc != 1)
> usage();
>
> hv_config();
>
> +   gid = find_guest(argv[0]);
> +
> /*
>  * Start guest domain.
>  */
> bzero(, sizeof(msg));
> msg.hdr.op = HVCTL_OP_GUEST_START;
> msg.hdr.seq = hvctl_seq++;
> -   msg.msg.guestop.guestid = find_guest(argv[1]);
> +   msg.msg.guestop.guestid = gid;
> nbytes = write(hvctl_fd, , sizeof(msg));
> if (nbytes != sizeof(msg))
> err(1, "write");
> @@ -424,6 +465,9 @@ guest_start(int argc, char **argv)
> nbytes = read(hvctl_fd, , sizeof(msg));
> if (nbytes != sizeof(msg))
> err(1, "read");
> +
> +   if (console)
> +   console_exec(gid);
>  }
>
>  void
> @@ -615,9 +659,7 @@ guest_status(int argc, char **argv)
>  void
>  guest_console(int argc, char **argv)
>  {
> -   struct guest *guest;
> uint64_t gid;
> -   char console_str[8];
>
> if (argc != 2)
> usage();
> @@ -625,20 +667,8 @@ guest_console(int argc, char **argv)
> hv_config();
>
> gid = find_guest(argv[1]);
> -   if (gid == 0)
> -   errx(1, "no console for primary domain");
>
> -   TAILQ_FOREACH(guest, _list, link) {
> -   

Re: ldom.conf.5: Mention default boot disk

[Andrew Grillet]

Yes - I like the alias idea.

The example you give exactly matches most of my setups.

Would it be possible to pass the actual filename to boot from via OBP?
(Perhaps if enabled/forced by a null or "*" as the filename).
This would make it possible to add/replace a disk to a  guest after the
config is running, without interrupting the primary or other guests.
(EG because guest is re-purposed).




On Tue, 7 Jan 2020 at 23:41, Klemens Nanni  wrote:

> On Sun, Dec 29, 2019 at 11:33:06PM +0100, Klemens Nanni wrote:
> > OBP defaults to booting from disk and network in that order.
> > With multiple disks attached, only the first disk is tried.
> >
> > OBP mostly if not always also defaults to automatic boot, meaning
> > domains start trying boot devices once the firmware is done rather than
> > dropping into the {0} ok prompt.
> >
> > This means (newly provisioned) guest domains may end up in network boot
> > loops without any possibility to force booting off any particular disk.
> >
> > I ran into this case with a bunch of domains like this one:
> >
> >   domain "guest01" {
> >   vdisk "/var/ldom/guest01.img"
> >   vdisk "/var/ldom/miniroot66.fs"
> >   vnet
> >   ...
> >   }
> >
> > Empty disk, miniroot for bootstrap/recovery and network.  But since the
> > first disk (empty/invalid) cannot be booted from, OBP tries booting off
> > net and seemingly does so forever: multiple solutions exist:
> Alternatively, I thought about extending ldom.conf(5) by an additional
> and optional parameter for `vdisk' such that disks can either be marked
> as boot device, e.g. `boot', or even perhaps even given a device alias
> right away, e.g. `miniroot'.
>
> Those aliases can be used right away in OBP, that is `boot miniroot'.
>
> All stuff for later on my list, but feedback is always welcome and small
> steps like this diff seem simpler.
>
> Documentation the default disk is a small step but adds much value in
> this context, so the diff below mentions the default with regard to
> eeprom(8)'s boot-device variable which the other diff mentions,
> because technically the first disk is only the default boot device
> until it gets set explicitly.
>
> Feedback? OK?
>
>
> Index: ldom.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldom.conf.5,v
> retrieving revision 1.9
> diff -u -p -r1.9 ldom.conf.5
> --- ldom.conf.5 3 Dec 2019 21:07:03 -   1.9
> +++ ldom.conf.5 7 Jan 2020 23:30:14 -
> @@ -64,6 +64,9 @@ can be a block device node or a disk ima
>  .Cm create-vdisk
>  command.
>  This keyword can be used multiple times.
> +Unless
> +.Cm variable Ar boot-device ...
> +is set, fhe first disk will be the default boot device.
>  .It Ic vnet Op Brq Ar keyword Ns = Ns Ar value ...
>  Assign a
>  .Xr vnet 4
>
>

Re: ldomctl: Do not start/stop/panic primary domain

[Andrew Grillet]

As a "Stupid Sysadmin", I want all the help I can get!

:-)

On Fri, 3 Jan 2020 at 19:56, Klemens Nanni  wrote:

> On Fri, Jan 03, 2020 at 08:28:54PM +0100, Mark Kettenis wrote:
> > Please no.  Stupid sysadmins should stay away from that command ;).
> Do you want to scare them away?
>
> Fine with me, your call.
>
>

Re: ldom.conf.5: Mention default boot disk

[Andrew Grillet]

The fact that netbooting cannot be interrupted has caused me to waste a lot
of time over the years.

Whether the config is screwed, there is a typo in a config or a cable has
fallen off somewhere,
it would be very nice to be able to kill the netboot and start again,
regardless of this particular reason.



On Sun, 29 Dec 2019 at 22:45, Klemens Nanni  wrote:

> OBP defaults to booting from disk and network in that order.
> With multiple disks attached, only the first disk is tried.
>
> OBP mostly if not always also defaults to automatic boot, meaning
> domains start trying boot devices once the firmware is done rather than
> dropping into the {0} ok prompt.
>
> This means (newly provisioned) guest domains may end up in network boot
> loops without any possibility to force booting off any particular disk.
>
> I ran into this case with a bunch of domains like this one:
>
> domain "guest01" {
> vdisk "/var/ldom/guest01.img"
> vdisk "/var/ldom/miniroot66.fs"
> vnet
> ...
> }
>
> Empty disk, miniroot for bootstrap/recovery and network.  But since the
> first disk (empty/invalid) cannot be booted from, OBP tries booting off
> net and seemingly does so forever: multiple solutions exist:
>
> - remove network so OBP exhausts boot devices and drops to prompt
>(not tested)
> - provide working network boot setup
> - make miniroot be the first disk so OBP boots into something usable
> - provision the actual guest disk prior to starting the domain
> - make OBP stay at boot prompt with `variable auto-boot?=false'
>
> Since our code handles no dynamic runtime changes, all of those
> approaches currently requires rewriting new LDOM configurations and
> resetting the physical machine to make it effective.
>
> Implementing the features will take much effort, but polishing
> documentation to make users more aware of such behaviour is easy, so I
> want to start with simply mentioning which disk is tried at boot.
>
> Hopefull users transport this into ordering their `vdisk' lines
> accordingly or disabling automatic boot.
>
> Feedback? OK?
>
>
> Index: ldom.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldom.conf.5,v
> retrieving revision 1.9
> diff -u -p -r1.9 ldom.conf.5
> --- ldom.conf.5 3 Dec 2019 21:07:03 -   1.9
> +++ ldom.conf.5 29 Dec 2019 22:11:12 -
> @@ -64,6 +64,7 @@ can be a block device node or a disk ima
>  .Cm create-vdisk
>  command.
>  This keyword can be used multiple times.
> +The first disk will be the default boot device.
>  .It Ic vnet Op Brq Ar keyword Ns = Ns Ar value ...
>  Assign a
>  .Xr vnet 4
>
>

Re: sysupgrade: Allow to use another directory for the sets

[Andrew Grillet]

I vote for this.


On Fri, 22 Nov 2019 at 16:12, Craig Skinner  wrote:

> On Tue, 19 Nov 2019 10:35:56 + Stuart Henderson wrote:
> > We are short on partitions, there is a hard limit (14+swap), disklabel
> auto
> > defaults already use 9, and there need to be some free for typical user
> use
> > (ports, dest for "make release", people often want a separate /var/www
> and/or
> > /var/log).
>
> Oh, I wasn't thinking of single disk desktops, but multi-drive servers
> (which have plenty partition letters available to slice disks with).
>
> Here's another idea Stuart:-
>
> The special directory /tmp/vi.recover/ is exempt from boot & daily purging.
>
> Could a similar /tmp/sysupgrade/ default directory suit most situations?
>
> /tmp/ is normally mounted separately from / /home/ /var/
> And probably not encrypted, nor over NFS.
>
> Cheers,
> --
> Craig Skinner | http://linkd.in/yGqkv7
>
>

Sparc64 - T1000 ldom config issue with OBSD 6.6

[Andrew Grillet]

I have been running my T1000 for almost a year on a config generated with
(I think) OBDS6.3.
I upgraded to 6.6 current on the day before it was released (2 October?).

I built a new config with minor changes (names of guest vdisks, and number
of CPUs allocated
to the primary - several had been unused previously).
On attempting to reboot with the new config, I get:

{0} ok boot

SC Alert: Host System has Reset

ERROR: /pci@780: Invalid hypervisor argument(s). function: b4

ERROR: /pci@780: Invalid hypervisor argument(s). function: b4

ERROR: /pci@780: Invalid hypervisor argument(s). function: b5


Sun Fire(TM) T1000, No Keyboard
Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.30.4.d, 2048 MB memory available, Serial #77558134.
Ethernet address 0:14:4f:9f:71:76, Host ID: 849f7176.

Boot device: net  File and args:
ERROR: boot-read fail

Evaluating:

Can't locate boot device
---
After this, my device tree is empty.
resetting to factory-default recovers the device tree, and the system will
boot.

I rebuilt the config reducing the amount of ram used by the last guest
(this has solved problems in the past). Downloaded it, and the problem
persists.

Does anyone know what the error means?
Are there non-obvious constraints on configs?

I think my pci is @7c0, not 780. I got the factory defaults by dumping the
factory default
config when I set the machine up before. The strings inside it seem to say
7c0.
Why would the newly compiled configs have a different root for the device
tree, and is there a way I can fix this?

SAS drives on Sparc64

[Andrew Grillet]

I have several SAS H/Ds that are reporting "device not configured" with
fdisk and disklabel.
dd if=/dev/zero of=/dev/sd1
The dmesg entry for one is ...
sd1 at scsibus1 targ 1 lun 0:  SCSI4
0/direct fixed naa.5000cca0222458c0

I assumed that the problem lies with the boot sector contents, and managed
to do
dd if=/dev/zero of=/dev/sd1
however, the problem has not gone away.
Would a SCSI format help? if so, is there an easy way to do it?

Google suggested using scsictl, but it is not installed. Is it part of a
pkg, or old info?

Re: ldomctl: improve usage

[Andrew Grillet]

I assumed "usage" is printed in response to a failure to give the correct
combination of command and argument
and that -h (or help) would give more detail.
I would like the usage (response to incorrect combination) to be the
"synopsis" while the grouped commands and
their valid arguments is supplied for -h.
Reason being failure to give the correct format is most likely a typo
anyway, while, if an infrequent user, you
might need to check (eg) that download takes a directory, while init-system
takes a file and dump takes nothing.
(I can never remember whether it is init-system or system-init, as I do it
about once a year).
For anything more complex, there is "man".
Would two columns be a solution for those who struggle with scroll back?



On Tue, 2 Jul 2019 at 21:23, Klemens Nanni  wrote:

> Thanks for the input;  I won't persue such verbose usages any longer.
>
> Another attempt was to continue grouping the commands by their arguments:
>
> $ ldomctl -h
> usage:  ldomctl command [argument ...]
> ldomctl delete|select configuration
> ldomctl download directory
> ldomctl dump
> ldomctl list
> ldomctl init-system file
> ldomctl panic|start|status|stop [domain]
>
> But this still seems long enough and even harder to read, so the
> following patch simply cuts it to the synopsis as per the manual:
>
> $ ldomctl -h
> usage: ldomctl command [argument ...]
>
> It contains less information than before, but is actually consistent
> and not incomplete any longer, which bothers me with the current usage.
>
> Feedback? Obections? OK?
>
> Index: ldomctl.c
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 ldomctl.c
> --- ldomctl.c   15 Sep 2018 13:20:16 -  1.21
> +++ ldomctl.c   1 Jul 2019 19:45:59 -
> @@ -157,10 +157,7 @@ main(int argc, char **argv)
>  void
>  usage(void)
>  {
> -   extern char *__progname;
> -
> -   fprintf(stderr, "usage: %s start|stop|panic domain\n", __progname);
> -   fprintf(stderr, "   %s status [domain]\n", __progname);
> +   fprintf(stderr, "usage: %s command [argument ...]\n",
> getprogname());
> exit(EXIT_FAILURE);
>  }
>
>
>

Re: ldomctl: improve usage

[Andrew Grillet]

As an ldomctl user, I would be happy for usage to be reasonably terse,
provided help gives a fuller description
- provided the usage mentions the help option.

If your screen does not have scroll back, the solution is a screen program
that does. It is not 1978 any more.

(Incidentally, do others have a very bad experience with the default
terminal when using Sparc[64]
consoles? Would the default of TERM=ansi help? Or is there a better
solution?)

On Sun, 30 Jun 2019 at 12:20, Klemens Nanni  wrote:

> On Sat, Jun 22, 2019 at 11:20:10AM -0600, Theo de Raadt wrote:
> > The problem is when I'm on screens that don't have scroll-back, those 9
> > lines have scrolled other information off the top, and then I've had to
> > repeat the operations, or if not possible, been more frustrated.
> Should we change those programs and refer to manual page or show a
> synopsis one-liner instead?
>
> I get the scroll-back argument, but I dare say it's a weak one given
> that this is something users can fix most of the time, e.g. by using
> tmux.
>
> I'd really like to have a valuable usage in ldomctl and haven't come up
> with a better and still consistent way of doing so.
>
> ssh-keygen is another good example of long usage that is most probably
> not going to change back to a simpler one;  I just stumbled over it due
> to wrong usage and was therefore reminded of this mail thread.
>
> What do other (ldomctl) users say?
>
>

Re: another go at bypass support for sparc64 iommu and BUS_DMA_64BIT

[Andrew Grillet]

I have the snapshot running on a guest domain on a T1000 - see attached.

I will test on the primary in a few days, and may be able to test on a
T5220 primary towards the end of next week.

Let me know if you want any specific test procedure run.

On Tue, 18 Jun 2019 at 02:37, Theo de Raadt  wrote:

> David Gwynne  wrote:
>
> > this is a reposting of the diff i sent out a while back. it lets sparc64
> > enable iommu bypass, and then uses that bypass support for BUS_DMA_64BIT
> > dmamaps.
>
> BTW, this is in snapshots and I'd urge everyone running sparc64 to give it
> a try.
>
>
console is /virtual-devices@100/console@1
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.5-current (GENERIC.MP) #207: Tue Jun 18 13:15:53 MDT 2019
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 1073741824 (1024MB)
avail mem = 1033175040 (985MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: Sun Fire(TM) T1000
cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1000 MHz
cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1000 MHz
vbus0 at mainbus0
"flashprom" at vbus0 not configured
cbus0 at vbus0
vdsk0 at cbus0 chan 0x2: ivec 0x4, 0x5
scsibus1 at vdsk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 10240MB, 512 bytes/sector, 20971520 sectors
vdsk1 at cbus0 chan 0x3: ivec 0x6, 0x7
scsibus2 at vdsk1: 2 targets
sd1 at scsibus2 targ 0 lun 0:  SCSI3 0/direct fixed
sd1: 2MB, 512 bytes/sector, 4096 sectors
vnet0 at cbus0 chan 0x4: ivec 0x8, 0x9, address 00:14:4f:fa:5a:dd
vnet1 at cbus0 chan 0x5: ivec 0xa, 0xb, address 00:14:4f:fb:22:90
vcons0 at vbus0: ivec 0x111, console
vrtc0 at vbus0
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
bootpath: /virtual-devices@100,0/channel-devices@200,0/disk@0,0
root on sd0a (8aa1a32792af6458.a) swap on sd0b dump on sd0b

Re: OpenBSD 6.5 released -- Apr 24 2019

[Andrew Grillet]

Install was very quick on my Sun V100. Congratulations to all involved.

Any news on if/when there will be packages for Sparc64?

On Wed, 24 Apr 2019 at 14:46, Theo de Raadt  wrote:

> OpenBSD 6.5 builds finished a week early, so the May 1 dated code can
> go out the door 1 week early.
>
> 
> - OpenBSD 6.5 RELEASED -
>
> May 1, 2019.
>
> We are pleased to announce the official release of OpenBSD 6.5.
> This is our 46th release.  We remain proud of OpenBSD's record of more
> than twenty years with only two remote holes in the default install.
>
> As in our previous releases, 6.5 provides significant improvements,
> including new features, in nearly all areas of the system:
>
>  - Improved hardware support, including:
> o clang(1) is now provided on mips64.
> o The default linker has been switched from the binutils bfd-based
>   linker to lld on amd64 and i386.
> o octeon: Now the system automatically detects the number of
>   available cores. However, manual setting of the numcores, or
>   coremask, boot parameter is still needed to enable secondary
>   cores.
> o octeon: It is now possible to use the root disk's DUID as the
>   value of the rootdev boot parameter.
> o New octgpio(4) driver for the OCTEON GPIO controller.
> o New pvclock(4) driver for KVM paravirtual clock.
> o New ixl(4) driver for Intel Ethernet 700 series controller
>   devices.
> o New abcrtc(4) driver for Abracon AB1805 real-time clock.
> o New imxsrc(4) driver for i.MX system reset controller.
> o New uxrcom(4) driver for Exar XR21V1410 USB serial adapters.
> o New mvgicp(4) driver for Marvell ARMADA 7K/8K GICP controller.
> o Support for QCA AR816x/AR817x in alc(4).
> o Support for isochronous transfers in xhci(4).
> o uaudio(4) has been replaced by a new driver which supports USB
>   audio class v2.0.
> o Improved support for nmea(4) devices, providing altitude and
>   ground speed values as sensors.
>
>  - IEEE 802.11 wireless stack improvements:
> o Reduced usage of RTS frames improves overall throughput and
>   latency.
> o Improved transmit rate selection in the iwm(4) driver.
> o Improved radio hardware calibration in the athn(4) driver.
> o The bwfm(4) driver now provides more accurate device configuration
>   information to userland.
> o Added new routing socket message RTM_80211INFO to provide details
>   of 802.11 interface state changes to dhclient(8) and route(8).
> o If an auto-join list is configured, wireless interfaces will no
>   longer connect to unknown open networks by default. This behaviour
>   must now be explicitly enabled by adding the empty network name to
>   the auto-join list, e.g. ifconfig iwm0 join "", or join "" in
>   hostname.if files.
> o The iwn(4) and iwm(4) drivers will now automatically try to
>   connect to a network if the radio kill switch is toggled to allow
>   radio transmissions while the interface is marked UP.
>
>  - Generic network stack improvements:
> o New bpe(4) Backbone Provider Edge pseudo-device.
> o New mpip(4) MPLS IP layer 2 pseudowire driver.
> o MPLS encapsulation interfaces support configuration of alternative
>   MPLS route domains.
> o The vlan(4) driver bypasses queue processing and outputs directly
>   to the parent interface.
> o New per SAD counters visible via ipsecctl(8).
> o The bpf(4) filter drop mechanism has been extended to allow
>   dropping without capturing packets, and use of the mechanism with
>   tcpdump(8) as a filtering mechanism early in the device receive
>   path.
> o ifconfig(8) gains txprio for controlling the encoding of priority
>   in tunnel headers, and support in drivers including vlan(4),
>   gre(4), gif(4), and etherip(4).
>
>  - Installer improvements:
> o rdsetroot(8) (a build-time tool) is now available for general use.
> o During upgrades, some components of old releases are deleted.
>
>  - Security improvements:
> o unveil(2) has been improved to understand and find covering unveil
>   matches above the working directory of the running process for
>   relative path accesses. As a result many programs now can use
>   unveil in broad ways such as unveil("/", "r").
> o unveil(2) no longer silently allows stat(2) and access(2) to work
>   on any unveiled path component.
> o Now using unveil(2) in ospfd(8), ospf6d(8), rebound(8),
>   getconf(1), kvm_mkdb(8), bdftopcf(1), Xserver(1), passwd(1),
>   spamlogd(8), spamd(8), sensorsd(8), snmpd(8), htpasswd(1),
>   ifstated(8). Some pledge(2) changes were required to accommodate
>   unveil.
> o ROP mitigations in clang(1) have been improved, resulting in a
>   significant decrease in the number of polymorphic 

Re: bypass support for iommu on sparc64

[Andrew Grillet]

So, substitute opening and closing the connection to the network?

Is the IOMMU not used for disk (and all SCSI) access also?



On Sat, 20 Oct 2018 at 20:32, Theo de Raadt  wrote:

> Andrew Grillet  wrote:
>
> > Ok, what I am proposing is that the IOMMU is set up when a file is opened
> > to provide the address space required for that file's IO.
>
> Wow, you keep saying file as if it means something.
>
> packets off the network are not associated with any specific "file"
> activity
>
> it isn't how the kernel works.
>
> You are ... way off target.
>

Re: bypass support for iommu on sparc64

[Andrew Grillet]

Ok, what I am proposing is that the IOMMU is set up when a file is opened
to provide the address space required for that file's IO.
This remains set up until the file is closed, avoiding frequent set-up and
tear-down for each IO transfer.

I assume that there is sufficient IOMMU address space to handle any
plausible number of files open, and that it is possible to keep
the knowledge of address spaces private to the Primary Ldom, and guests
would only be aware of the mbufs visible to them, and
this is acceptable. (If you cant trust the Primary, I rather suspect you
are stuffed anyway). Clearly, dependent of IOMMU architecture,
which I do not claim to understand, this could exhaust IO address space
before it exhausts physical memory, I don't know.
But I cannot see any other reason why this would not avoid frequent set-up
and tear-downs.

I get the impression that disk access is not great on my T machines. I
expect a 1GHz T1000 to totally piss on a 4GHz Intel
machine at web serving, and it doesn't. (Solaris annoys me too much to even
try it, but I assume its better than OpenBSD on
Spact64 at this time, or Larry Ellison would have to sell his yacht).





On Sat, 20 Oct 2018 at 20:04, Theo de Raadt  wrote:

> In this case, what do mbufs have to do with files?
>
> I am very confused.
>
> > I was assuming that the main objection to allocating mbufs for duration
> of
> > file open,
> > rather than allocating per transfer, this could result in a much higher
> > number of mbufs
> > being in use concurrently. I cannot see any other downside (which may be
> > due to my
> > not understanding a lot of stuff - I last wrote this level of stuff for
> > Unix in the 1980's).
> >
> > On Sat, 20 Oct 2018 at 14:41, Theo de Raadt  wrote:
> >
> > > Andrew Grillet  wrote:
> > >
> > > > These days we are not so short of memory - would it not be possible
> to
> > > > allocate an mbuf (or two for double-buffered) for each file
> > > > when opened, and free when closed?
> > >
> > > What does this have to do with files??
> > >
>

Re: bypass support for iommu on sparc64

[Andrew Grillet]

I was assuming that the main objection to allocating mbufs for duration of
file open,
rather than allocating per transfer, this could result in a much higher
number of mbufs
being in use concurrently. I cannot see any other downside (which may be
due to my
not understanding a lot of stuff - I last wrote this level of stuff for
Unix in the 1980's).

On Sat, 20 Oct 2018 at 14:41, Theo de Raadt  wrote:

> Andrew Grillet  wrote:
>
> > These days we are not so short of memory - would it not be possible to
> > allocate an mbuf (or two for double-buffered) for each file
> > when opened, and free when closed?
>
> What does this have to do with files??
>

Re: bypass support for iommu on sparc64

[Andrew Grillet]

These days we are not so short of memory - would it not be possible to
allocate an mbuf (or two for double-buffered) for each file
when opened, and free when closed?

I can see the management might be more complex, but the performance
benefits might be considerable.
Also, for VM disk access (ldom on T) does this mean the process happens
twice -once for disk-to-host
and again for host-to-guest? In which case, allocating mbufs for the entire
vdisk file to the host once
at (VM) boot time (ldomctl start guest), and deallocating when it is shut
down would save huge amounts
of work. Unless the host is not involved in guest file access at all (don't
know how you could safely do
that).

I can't see making all of memory visible to (even to kernel processes) in a
guest is acceptable. Too much to
go wrong.

Andrew

On Sat, 20 Oct 2018 at 01:59, David Gwynne  wrote:

>
>
> > On 19 Oct 2018, at 9:59 pm, Andrew Grillet  wrote:
> >
> > Is the setup and teardown per transfer or when file is opened and closed?
> > Or is it set up once per context switch of task?
> >
> > I am partly interested cos I would like to improve mt one day (as user of
> > tape
> > and Sparc64 Txxx) if I get the time.
> >
> > Andrew
>
> The overhead is per transfer. You might not get better performance out of
> a tx000 because of the PCIe bridges involved, but you may also be lucky and
> not have that bridge in the way.
>
> >
> >
> >
> > On Fri, 19 Oct 2018 at 10:22, Mark Kettenis 
> wrote:
> >
> >>> Date: Fri, 19 Oct 2018 10:22:30 +1000
> >>> From: David Gwynne 
> >>>
> >>> On Wed, May 10, 2017 at 10:09:59PM +1000, David Gwynne wrote:
> >>>> On Mon, May 08, 2017 at 11:03:58AM +1000, David Gwynne wrote:
> >>>>> on modern sparc64s (think fire or sparc enterprise Mx000 boxes),
> >>>>> setting up and tearing down the translation table entries (TTEs)
> >>>>> is very expensive. so expensive that the cost of doing it for disk
> >>>>> io has a noticable impact on compile times.
> >>>>>
> >>>>> now that there's a BUS_DMA_64BIT flag, we can use that to decide
> >>>>> to bypass the iommu for devices that set that flag, therefore
> >>>>> avoiding the cost of handling the TTEs.
> >>>>>
> >>>>> the following diff adds support for bypass mappings to the iommu
> >>>>> code on sparc64. it's based on a diff from kettenis@ back in 2009.
> >>>>> the main changes are around coping with the differences between
> >>>>> schizo/psycho and fire/oberon.
> >>>>>
> >>>>> the differences between the chips are now represented by a iommu_hw
> >>>>> struct. these differences include how to enable the iommu (now via
> >>>>> a function pointer), and masks for bypass addresses.
> >>>>>
> >>>>> ive tested this on oberon (on an m4000) and schizo (on a v880).
> >>>>> however, the bypass code isnt working on fire (v245s). to cope with
> >>>>> that for now, the iommu_hw struct lets drivers mask flag bits that
> >>>>> are handled when creating a dmamap. this means fire boards will
> >>>>> ignore BUS_DMA_64BIT until i can figure out whats wrong with them.
> >>>>
> >>>> i figured it out. it turns out Fire was working fine. however,
> >>>> enabling 64bit dva on the onboard devices didnt work because the
> >>>> serverworks/broadcom pcie to pcix bridge can only handle dma addresses
> >>>> in the low 40 bits. because the fire bypass window is higher than
> >>>> this, the bridge would choke and things stopped working.
> >>>>
> >>>> the updated diff attempts to handle this. basically when probing
> >>>> the bridge, the platform creates a custom dma tag for it. this tag
> >>>> intercets bus_dmamap_create and clears the BUS_DMA_64BIT flag before
> >>>> handing it up to the parent bridge, which is pyro in my situation.
> >>>> it looks like early sun4v boxes could make use of this too.
> >>>>
> >>>>> i have not tested this on psycho yet. if anyone has such a machine
> >>>>> and is willing to work with me to figure it out, please talk to me.
> >>>>
> >>>> i still dont have psycho reports.
> >>>
> >>> Would anyone object if I committed this? I've been running it for the
> >>> last release or two without issues, but with signif

Re: bypass support for iommu on sparc64

[Andrew Grillet]

Is the setup and teardown per transfer or when file is opened and closed?
Or is it set up once per context switch of task?

I am partly interested cos I would like to improve mt one day (as user of
tape
and Sparc64 Txxx) if I get the time.

Andrew



On Fri, 19 Oct 2018 at 10:22, Mark Kettenis  wrote:

> > Date: Fri, 19 Oct 2018 10:22:30 +1000
> > From: David Gwynne 
> >
> > On Wed, May 10, 2017 at 10:09:59PM +1000, David Gwynne wrote:
> > > On Mon, May 08, 2017 at 11:03:58AM +1000, David Gwynne wrote:
> > > > on modern sparc64s (think fire or sparc enterprise Mx000 boxes),
> > > > setting up and tearing down the translation table entries (TTEs)
> > > > is very expensive. so expensive that the cost of doing it for disk
> > > > io has a noticable impact on compile times.
> > > >
> > > > now that there's a BUS_DMA_64BIT flag, we can use that to decide
> > > > to bypass the iommu for devices that set that flag, therefore
> > > > avoiding the cost of handling the TTEs.
> > > >
> > > > the following diff adds support for bypass mappings to the iommu
> > > > code on sparc64. it's based on a diff from kettenis@ back in 2009.
> > > > the main changes are around coping with the differences between
> > > > schizo/psycho and fire/oberon.
> > > >
> > > > the differences between the chips are now represented by a iommu_hw
> > > > struct. these differences include how to enable the iommu (now via
> > > > a function pointer), and masks for bypass addresses.
> > > >
> > > > ive tested this on oberon (on an m4000) and schizo (on a v880).
> > > > however, the bypass code isnt working on fire (v245s). to cope with
> > > > that for now, the iommu_hw struct lets drivers mask flag bits that
> > > > are handled when creating a dmamap. this means fire boards will
> > > > ignore BUS_DMA_64BIT until i can figure out whats wrong with them.
> > >
> > > i figured it out. it turns out Fire was working fine. however,
> > > enabling 64bit dva on the onboard devices didnt work because the
> > > serverworks/broadcom pcie to pcix bridge can only handle dma addresses
> > > in the low 40 bits. because the fire bypass window is higher than
> > > this, the bridge would choke and things stopped working.
> > >
> > > the updated diff attempts to handle this. basically when probing
> > > the bridge, the platform creates a custom dma tag for it. this tag
> > > intercets bus_dmamap_create and clears the BUS_DMA_64BIT flag before
> > > handing it up to the parent bridge, which is pyro in my situation.
> > > it looks like early sun4v boxes could make use of this too.
> > >
> > > > i have not tested this on psycho yet. if anyone has such a machine
> > > > and is willing to work with me to figure it out, please talk to me.
> > >
> > > i still dont have psycho reports.
> >
> > Would anyone object if I committed this? I've been running it for the
> > last release or two without issues, but with significant improvements in
> > performance on the machines involved.
>
> At the price of giving all PCI devices unrestricted access to memory.
>
> So I'm not eager to this, especially since on sun4v hardware bypassing
> the iommu isn't possible as soon as multiple domains are enabled.  And
> we lose a useful diagnostic when developing drivers.  Are you sure the
> iommu overhead can't be reduced some other way?  At some point we
> probably want to add iommu support on amd64 and arm64, but if that
> comes with a similar overhead as on sparc64 that's going to be a bit
> of an issue.
>
> > > Index: dev/iommu.c
> > > ===
> > > RCS file: /cvs/src/sys/arch/sparc64/dev/iommu.c,v
> > > retrieving revision 1.74
> > > diff -u -p -r1.74 iommu.c
> > > --- dev/iommu.c 30 Apr 2017 16:45:45 -  1.74
> > > +++ dev/iommu.c 10 May 2017 12:00:09 -
> > > @@ -100,6 +100,25 @@ void iommu_iomap_clear_pages(struct iomm
> > >  void _iommu_dvmamap_sync(bus_dma_tag_t, bus_dma_tag_t, bus_dmamap_t,
> > >  bus_addr_t, bus_size_t, int);
> > >
> > > +void iommu_hw_enable(struct iommu_state *);
> > > +
> > > +const struct iommu_hw iommu_hw_default = {
> > > +   .ihw_enable = iommu_hw_enable,
> > > +
> > > +   .ihw_dvma_pa= IOTTE_PAMASK,
> > > +
> > > +   .ihw_bypass = 0x3fffUL << 50,
> > > +   .ihw_bypass_nc  = 0,
> > > +   .ihw_bypass_ro  = 0,
> > > +};
> > > +
> > > +void
> > > +iommu_hw_enable(struct iommu_state *is)
> > > +{
> > > +   IOMMUREG_WRITE(is, iommu_tsb, is->is_ptsb);
> > > +   IOMMUREG_WRITE(is, iommu_cr, IOMMUCR_EN | (is->is_tsbsize << 16));
> > > +}
> > > +
> > >  /*
> > >   * Initiate an STC entry flush.
> > >   */
> > > @@ -125,7 +144,8 @@ iommu_strbuf_flush(struct strbuf_ctl *sb
> > >   * - create a private DVMA map.
> > >   */
> > >  void
> > > -iommu_init(char *name, struct iommu_state *is, int tsbsize, u_int32_t
> iovabase)
> > > +iommu_init(char *name, const struct iommu_hw *ihw, struct iommu_state
> *is,
> > > +int tsbsize, u_int32_t iovabase)
> > >  {
> > > psize_t 

Vlan on T2000

[Andrew Grillet]

Hi,

I have been running OBSD6.0 and 6.1 on my T2000.

I now wish to upgrade to 6.2, and I managed to boot a guest domain from a
miniroot62.fs image
with no problems.

It is now asking:

Which network interface do you wish to configure? (or 'done') [vlan0]
Which interface:tag should vlan0 be on? [:none] vlan0:none
Invalid parent interface choice 'vlan0'.

There is only one interface available on the guest domain: vlan0, which is
bridged to
em3 on the host and nothing else. Em3 connects to a socket on a BT Business
Hub5.

I have tried various combinations of answers for the tag question, with and
without the vlan0
before the colon. All get labelled "invalid interface choice". There is
nothing that I can find
in the way of documentation to explain why I should even be asked this
question now, when I
have not ever been asked before, and I have used OBSD since 2.1, and
probably before that.


*What is the right answer?*

*Why is it the right answer?*

*Is this a bug or a feature?* If it is a new feature that you now need to
understand to perform
an install, then it needs to be explained in the install notes.

Ideally, the default should work without having to get new knowledge over
the internet,
cos you often have no internet access until after you manage to configure
your interfaces!

Andrew

Re: [PATCH] allow notAfter after 2038 with 32-bit time_t

[Andrew Grillet]

Hi,

I have built embedded systems that have run 20 years with no update - but I
doubt they are common.

More of an issue is archived data. I have read data 30 years old, and may
well do so again. While
I think the answer is "human readable date formats" The Americans have
scuppered that with M-D-Y.

I am sure there will still be 32 bit systems in 30 years time - there will
still be 8-bit systems too.

In summary:

1) 64 bit dates are needed ASAP, even on 8 bit machines.

2) What has Linux got to do with the price of fish?

Andrew

On 11 July 2017 at 11:23, Stuart Henderson  wrote:

> On 2017/07/11 01:55, Kyle J. McKay wrote:
> > 2) 32-bit systems are going to be around for many years still; 32-bit ARM
> > platforms are everywhere
> ..
> > 4) 32-bit time_t has potentially still got over 20 years of life left in
> it
>
> Yes. The gamble is whether 32-bit systems will still be around then.
> I don't see why they _wouldn't_ be. The sooner that OS adapt, the less
> likely there are to still be operational systems when 2038 comes around.
>
> > 3) 32-bit systems typically have 32-bit time_t values (I'm not aware of
> > anything in the standard preventing use of a 64-bit time_t on a 32-bit
> > system but that doesn't seem to be happening, at least not yet)
>
> This depends on the OS. Linux's general avoidance of ABI breaks is
> certainly a problem in this area. NetBSD has used 64-bit time_t on all
> architectures since 6.0 (2012) and OpenBSD since 5.5 (2014). I haven't
> looked recently but IIRC FreeBSD has 64-bit time_t on 32-bit ARM
> (and of course on 64-bit systems).
>
> Plenty of software still needs patching to fix operation on a 32-bit
> arch with 64-bit time_t - we have a lot of these in the ports tree
> (with mixed success feeding such changes upstream - "Linux doesn't
> need it"...).
>
>

Fwd: what does "internet stream tcp 0x0 *:0" mean?

[Andrew Grillet]

"The socket has no TCP PCB anymore. "

This would be a better error message. (Although I don't know what a PCB is,
and when I Google, it comes out as PolyChlorinated Biphenyl or Printed
Circuit Board,
so perhaps a bit more explanation is needed).




-- Forwarded message --
From: Alexander Bluhm 
Date: 4 May 2017 at 09:45
Subject: Re: what does "internet stream tcp 0x0 *:0" mean?
To: tech@openbsd.org


On Wed, May 03, 2017 at 02:22:23PM +0100, Stuart Henderson wrote:
> On 2017/05/03 10:33, Stuart Henderson wrote:
> > $ fstat | grep internet.stream.tcp | head -1500 |tail -5
> > _tomcat  java   88950 1585* internet stream tcp 0x0 *:0

The socket has no TCP PCB anymore.  This can happen either after
a TCP reset packet or a shutdown and a TCP time wait timeout.  The
attached Perl script triggers both cases.

I consider it as a bug that these connection don't appear in netstat.

bluhm

#!/usr/bin/perl
# create stream sockets without tcp pcb

use strict;
use warnings;
use IO::Socket::INET;
use Socket;

$> == 0
or die "Must run as root for netstat and fstat pointers";

my $ls = IO::Socket::INET->new(
Domain=> AF_INET,
LocalAddr => "127.0.0.1",
Proto => "tcp",
Listen=> 1,
) or die "Create listen socket failed: $!";
my $port = $ls->sockport();

# connect and reset

my $cs = IO::Socket::INET->new(
Domain=> AF_INET,
PeerAddr  => "127.0.0.1",
PeerPort  => $port,
Proto => "tcp",
) or die "Create connect socket failed: $!";

my $as = $ls->accept()
or die "Accept socket failed: $!";

$cs->setsockopt(SOL_SOCKET, SO_LINGER, pack('ii', 1, 0))
or die "Linger connect socket failed: $!";
$cs->close()
or die "Close connect socket failed: $!";

sleep 1;

print "\nReset:\n";
print map { "  $_" } `netstat -Aan -f inet -p tcp`;
print map { "  $_" } grep { /internet stream tcp/ } `fstat -p $$`;

# connect and shutdown

$cs = IO::Socket::INET->new(
Domain=> AF_INET,
PeerAddr  => "127.0.0.1",
PeerPort  => $port,
Proto => "tcp",
) or die "Create connect socket failed: $!";

$as = $ls->accept()
or die "Accept socket failed: $!";

$as->shutdown(SHUT_WR)
or die "Shutdown accept socket failed: $!";
$cs->close()
or die "Close connect socket failed: $!";

# TIME WAIT Timeout=2MSL + 1
sleep 61;

print "\nShutdown:\n";
print map { "  $_" } `netstat -Aan -f inet -p tcp`;
print map { "  $_" } grep { /internet stream tcp/ } `fstat -p $$`;

Re: Ldomctl interrupt boot

[Andrew Grillet]

Hi Stefan,

Thanks for your help.

It seems there was a hardware problem. I was running in SSH, and that did
not work (I knew it had previously in other situations).
In the end, I had to power down completely - including removing the cables
from the PSUs!

After the reboot, it behaved as you described.

On 23 April 2017 at 15:45, Stefan Sperling <s...@stsp.name> wrote:

> On Sun, Apr 23, 2017 at 02:14:51PM +0100, Andrew Grillet wrote:
> > Hi
> >
> > I have a T2000 running OpenBSD 6.0, with five guest domains.
> >
> > Primary and some guests are working. I am attempting to install the OS in
> > the remaining guests. In the process of installing the OS on vdisk0 of a
> > guest, I wish it to boot from vdisk1, but the guest is stuck in a
> situation
> > where it continually attempts to netboot.
> >
> > I am at the console using cu -l ttyVx.
> >
> > Is there a way to interrupt the continuous netbooting attempts? it does
> not
> > respond to anything I can find on the keyboard. Most commands are
> > intercepted by the primary domain.
>
> A break should interupt it and bring you to the ok> prompt.
> Type this to cu:
>
>   ~#
>
> If cu is running in SSH, you need to escape the tilde with
> another tilde:
>
>   ~~#
>

Ldomctl interrupt boot

[Andrew Grillet]

Hi

I have a T2000 running OpenBSD 6.0, with five guest domains.

Primary and some guests are working. I am attempting to install the OS in
the remaining guests. In the process of installing the OS on vdisk0 of a
guest, I wish it to boot from vdisk1, but the guest is stuck in a situation
where it continually attempts to netboot.

I am at the console using cu -l ttyVx.

Is there a way to interrupt the continuous netbooting attempts? it does not
respond to anything I can find on the keyboard. Most commands are
intercepted by the primary domain.

Ideally, I would like to be able to force auto-boot? to false from sc or
the primary using eeprom or ldomctl. Failing that, just forcing it back to
the ok prompt would be good. I really do not want to have to implement
netbooting.

This must be a general problem, so I assume there is a solution other than
netbooting, but if not, surely there needs to be one!

regards

Andrew

Sun T2000 internal communications

[Andrew Grillet]

Hi,

how _exactly_ does a guest domain connect to a virtual disk?

I am asking this because I installed 6.1 onto my system which had
been running 6.0. However, I took the opportunity to reformat and partition
the hard disks. I reinstalled the same virtual disks in the same logical
positions:
/home/xxx//vdisk0
etc, but on a different physical disk in some cases.
but the domains wont boot. There is a message
"WARNING: /virtual-devices@100/channel-devices@200/disk@0: Communication
error with Virtual Disk Server using Port 0. Retrying".
which repeats continually. I can not kill it with Ctrl-C, or any other
means I am aware of.

I have previously moved, and even replaced the virtual disks, but as far as
I know,
always on the same physical disk. (Not certain of this though, and I think
some of
the domains in the new setup are on the same disk as before).

I am not aware of any documentation explaining how the name supplied to the
ldom config file is used to access the actual physical disk - at what stage
is the file name and path converted to an inode? and in what domain? eg at
"compile time" or "run time"? Are there any rules about permissions on the
virtual disks?

In practice, these are things a system administrator needs to know, as most
systems will need disk space to grow eventually. There is also the issue of
backup and restore:  the obvious way is to connect a tape drive - which
means connect it to the primary domain - and save vdisks to tape. How can I
be sure the restored vdisks will work? (I assume this requires the guest
domain to be properly shut down before the backup stops, and not just
"ldomctl stop " It would be really nice if the tape backup script
could send the shutdown command using something like "ldomctl exec 
".

I have no way of knowing what is possible, since I am not aware of any
Sun/Oracle documentation  on any part of this stuff, and I doubt I have the
skills to do it either. But Oracle do claim to support Open Source - and
there is not much else than OpenBSD in the Open Source world supporting
Oracle.

regards

Andrew

rmt

[Andrew Grillet]

How do I actually use rmt?

I want to backup a guest domain on a T2000 using a tape drive on the
primary domain.
Both domains run OpenBSD 6.0.

The way I read the mt manual page, I should be able to do (from the guest,
as root)
> mt primary:/dev/rst0 status
and this should deliver the command to rmt on the primary, execute the
command
and return the results, identical to if I did
> mt -f /dev/rst0 status
on the primary.
Instead, it just hangs.
Are there some preconditions, somewhere? Like - do I need to start rmt on
the primary,
somehow, or hack around with inetd.conf? or is it all about hosts.allow?

Is there a magic FAQ for this stuff?

Or am I the only person that has used magtape since it was 556 bpi?

Help!

Thanks.

Re: dhcpd.conf(5): "domain name" -> "hostname" for next-server option

[Andrew Grillet]

Hi

"a name that can be looked up in the DNS"

Please can this phrase be used in the man page -it is a really good
explanation.



On 4 February 2017 at 15:34, Jeremie Courreges-Anglas 
wrote:

> Theo Buehler  writes:
>
> > On Wed, Jan 11, 2017 at 09:30:15PM +0100, Theo Buehler wrote:
> >> The TOK_NEXT_SERVER case in parse_statement() calls
> parse_ip_addr_or_hostname(),
> >> so I think the next-server option wants a host name, not a domain name:
> >
> > Any takers? I previously suggested 'host name', but the rest of the page
> > writes 'hostname', so let's go with that.
>
> "hostname" sounds less misleading indeed, I believe what is really meant
> here is "a name that can be looked up in the DNS".  Most occurrences of
> "domain name" in this manpage carry the same intent.  Do we want to
> convert those?
>
> FWIW, https://tools.ietf.org/html/rfc7719#section-2 acknowledges the
> fact that "host name" has multiple meanings: is it a FQDN, only the
> first label of an FQDN...?
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>
>

Re: ldomctl(8) usage

[Andrew Grillet]

Yes. A few lines, but really useful. The man page is for the full details.
However, if usage doesnt list
all options, you may assume the one you want does not exist, or belongs to
some other command,
rather than check with the man page.

The bikeshed is where school kids go for privacy with the opposite sex.
(Bikeshed music is like garage music,
but cheaper, and not so loud :-).

Prioritizing the small over the big is a problem too. Like the hospital
directors pending more time on whether to
compensate a patient for loss of his shirt than on spending £10M on a new
wing (my dad was the architect).

On 26 January 2017 at 13:49, Stefan Sperling <s...@stsp.name> wrote:

> On Thu, Jan 26, 2017 at 01:37:14PM +0000, Andrew Grillet wrote:
> > I am not sure what bikeshedding means in this case (it was all different
> > when I was at school ;-)
>
> http://producingoss.com/en/common-pitfalls.html#bikeshed
>
> > However, as an ldomctl user, I would be happier if the usage was
> consistent
> > with the man page:
> > it makes everything seem more trustworthy.
>
> Right, so you mean like this?
>
> SYNOPSIS
>  ldomctl command [argument ...]
>

Re: ldomctl(8) usage

[Andrew Grillet]

I am not sure what bikeshedding means in this case (it was all different
when I was at school ;-)

However, as an ldomctl user, I would be happier if the usage was consistent
with the man page:
it makes everything seem more trustworthy.

And once the machine is up and stable, you probably wont be using the
command very often, and might need to
quickly check if it is (eg) init-system or system-init.


On 26 January 2017 at 12:33, Stefan Sperling  wrote:

> I am not sure about the best way to fix this, but ldomctl's usage()
> is rather bogus. It only mentions some of the supported commands.
> The diff below adds the missing ones.
>
> However, I am tempted to just change all of it to something like this:
> fprintf(stderr, "usage: ldomctl command [arguments]\n");
> and let people refer to the man page instead.
>
> Is this worth bikeshedding about?
>
> Index: ldomctl.c
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 ldomctl.c
> --- ldomctl.c   9 Oct 2014 02:44:55 -   1.20
> +++ ldomctl.c   26 Jan 2017 11:16:30 -
> @@ -161,6 +161,11 @@ usage(void)
>
> fprintf(stderr, "usage: %s start|stop|panic domain\n", __progname);
> fprintf(stderr, "   %s status [domain]\n", __progname);
> +   fprintf(stderr, "   logical domain configuration:\n",
> __progname);
> +   fprintf(stderr, "   %s list|dump\n", __progname);
> +   fprintf(stderr, "   %s select|delete configuration\n",
> __progname);
> +   fprintf(stderr, "   %s download directory\n", __progname);
> +   fprintf(stderr, "   %s init-system file\n", __progname);
> exit(EXIT_FAILURE);
>  }
>
>
>