ie "AMD AMD64 17h Root Complex" -> "AMD 17h Root Complex"
Index: arch/amd64/pci/pchb.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pchb.c,v
retrieving revision 1.43
diff -u -p -r1.43 pchb.c
--- arch/amd64/pci/pchb.c 28 Apr 2018
On 02/01/20(Thu) 14:29, Scott Cheloha wrote:
> > On Jan 2, 2020, at 9:02 AM, Martin Pieuchot wrote:
> >
> > On 01/01/20(Wed) 22:13, Scott Cheloha wrote:
> >>> On Dec 31, 2019, at 9:35 AM, Martin Pieuchot wrote:
> >>>
> >>> I'd like to stop converting the given timespec to ticks and instead use
On Thu, Jan 02, 2020 at 04:05:45PM +0100, Denis Fondras wrote:
> This is mostly log messages sync.
ok remi@
>
> Index: database.c
> ===
> RCS file: /cvs/src/usr.sbin/ospf6d/database.c,v
> retrieving revision 1.18
> diff -u -p
On Thu, Jan 2, 2020 at 12:46 PM Oleg Pahl wrote:
>
> could you be so kind to revert this commit in FAQ 4?
>
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/www/faq/faq4.html.diff?r1=1.495=1.496
>
Instead of reverting the commit, this change in CSS fixes the problem:
- dt { margin-left: 40px; float:
On Fri, Jan 03, 2020 at 08:04:10PM +0100, Mark Kettenis wrote:
> No. If you messed this up in a previous commit, please fix it some
> other way.
The purpose of this diff is not to fix previously messed up spacing but
to omit information that I consider redundant by now since the `console'
> Date: Tue, 31 Dec 2019 09:12:56 +1000
> From: Jonathan Matthew
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Mon, Dec 30, 2019 at 03:36:54PM +0100, Klemens Nanni wrote:
> > On Mon, Dec 30, 2019 at 06:59:35PM +1000, Jonathan Matthew wrote:
> > > Here's the
On Fri, Jan 03, 2020 at 08:27:21PM +0100, Mark Kettenis wrote:
> I can't remember. Maybe someone with a t1k/t2k or t5120/t5140 can
> test this?
Hopefully; I don't have such machines anymore.
> It makes sense for the download command not to immediately select a
> configuration. So maybe just
> Date: Fri, 3 Jan 2020 20:18:46 +0100
> From: Klemens Nanni
>
> On Fri, Jan 03, 2020 at 08:04:10PM +0100, Mark Kettenis wrote:
> > No. If you messed this up in a previous commit, please fix it some
> > other way.
> The purpose of this diff is not to fix previously messed up spacing but
> to
BOOT_ARG from is a NetBSDism which did not make
its way to OpenBSD, where parsing kernel commandline options is done
inline.
It is no surprise then, that it is only used by the sparc64 boot blocks;
but boot blocks really only care about one option, -a, so there is no
need to check for more
> Date: Mon, 30 Dec 2019 18:59:35 +1000
> From: Jonathan Matthew
>
> On Sun, Dec 29, 2019 at 05:58:02AM +0100, Klemens Nanni wrote:
> > On Sun, Dec 29, 2019 at 01:59:38PM +1000, Jonathan Matthew wrote:
> > > I think we have the wrong size for the volume name, hence the difference
> > > between
> Date: Mon, 30 Dec 2019 21:07:59 +0100
> From: Klemens Nanni
>
> The example in the manual implies that the download command also selects
> it:
>
> # ldomctl init-system ldom.conf
> # cd ..
> # ldomctl delete openbsd
> # ldomctl download openbsd
> # ldomctl list
>
Although Open Firmware supports it, there is no way from OpenBSD to
reboot with a specified boot command line, so drop vestigial support for
it from boot().
Index: sparc64/machdep.c
===
RCS file:
On Thu, Jan 02, 2020 at 05:17:02PM +0100, Denis Fondras wrote:
> Sync with ospfd's hello.c
ok remi@
>
> Index: hello.c
> ===
> RCS file: /cvs/src/usr.sbin/ospf6d/hello.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 hello.c
>
> Date: Mon, 30 Dec 2019 01:13:56 +0100
> From: Klemens Nanni
>
> Now that `ldomctl console ...' is implemented there is actually no need
> to print the device any longer, it is an implementation detail that
> should be hidden just like it is the case with vmctl.
>
> That also makes it fit
> Date: Tue, 31 Dec 2019 03:26:13 +0100
> From: Klemens Nanni
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> This moves setup code from main() into its own function so instead of
> upfront it can be used only when and where needed.
>
> With the exception of
> Date: Mon, 30 Dec 2019 22:14:20 +0100
> From: Klemens Nanni
>
> `ldomctl start|stop primary" silently exits zero not doing anything,
> `ldomctl panic primary" makes primary panic (and pulls guests down with
> it).
>
> The manual explicitly documents those commands for "guest" domains,
> code
> Date: Wed, 1 Jan 2020 09:53:39 -0500
> From: Todd Mortimer
>
> My CPU has a CCP that isn't in the known list, so add it and tell ccp
> about it.
>
> Tested on Ryzen 3900x.
>
> ok?
ok kettenis@
> Will commit a pcidevs regen immediately after.
>
>
> diff --git a/sys/dev/pci/ccp_pci.c
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
> Date: Fri, 3 Jan 2020 20:42:11 +0100
> From: Klemens Nanni
>
> 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.
The command isn't actually as
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.
On Fri, Jan 03, 2020 at 09:17:58PM +0100, Mark Kettenis wrote:
> The command isn't actually as dangerous as you think. You can
> continue from the ddb prompt just fine...
That assumes one has access to the console. I hope everyone running
such setups has, but needing to resort to OOB access for
With the hv_config() now in, `ldomctl init-system -n ldom.conf' to only
parse configuration is trivial.
It is usable as unprivileged user, no devices are touched.
If errors occur, errors will be generated and ldomctl exits; if all is
valid, this prints "configuration OK" just like vmd(8) does.
On Fri, Jan 03, 2020 at 09:46:29PM +0100, Klemens Nanni wrote:
> +Only check the configuration file for validty.
"validity" fixed in my tree.
Diogo Galvao writes:
> On Thu, Jan 2, 2020 at 12:46 PM Oleg Pahl wrote:
> >
> > could you be so kind to revert this commit in FAQ 4?
> >
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/www/faq/faq4.html.diff?r1=1.495
> 2=1.496
> >
>
> Instead of reverting the commit, this change in CSS fixes the
On Fri, Jan 3, 2020 at 6:37 PM Anthony J. Bentley wrote:
>
> What browser are you using that misrenders the page like that?
Firefox 71.0. It must have something to do with monospace font
rendering on Windows. If you want to simulate the problem, try
adding the CSS below:
dt { height: 18.5px; }
On Fri, Jan 03, 2020 at 09:11:01PM +0100, Mark Kettenis wrote:
> The way I see it, "ldomctl console" is just there for compatibility
> with vmctl. We don't really need it for sparc64 as the random
> allocation of ttys that vmm(4) suffers from doesn't happen (and there
> are interesting user
On 2019/12/30 01:13, Klemens Nanni wrote:
> Now that `ldomctl console ...' is implemented there is actually no need
> to print the device any longer, it is an implementation detail that
> should be hidden just like it is the case with vmctl.
But vmctl does show the device ..?
$ vmctl start open
On Fri, Jan 03, 2020 at 08:58:16PM +, Stuart Henderson wrote:
> On 2019/12/30 01:13, Klemens Nanni wrote:
> > Now that `ldomctl console ...' is implemented there is actually no need
> > to print the device any longer, it is an implementation detail that
> > should be hidden just like it is the
Diogo Galvao writes:
> On Fri, Jan 3, 2020 at 6:37 PM Anthony J. Bentley wrote:
> >
> > What browser are you using that misrenders the page like that?
>
> Firefox 71.0. It must have something to do with monospace font
> rendering on Windows.
Thanks. These details were necessary to reproduce the
Consistently uppercase pci product defines.
does not address IBM oddities like
product IBM 0x0002 0x0002 MCA
minor changes to avoid duplicate defines or unclear names
(IIi -> 2I instead of III).
Index: arch/i386/pci/geodesc.c
Consistently uppercase usb product defines.
Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.85
diff -u -p -r1.85 if_urtwn.c
--- if_urtwn.c 16 Nov 2019 14:08:31 - 1.85
+++ if_urtwn.c
While playing with chromium u2f support[1] I managed to induce kernel
crashes in filt_uhidrdetach. It takes a few attempts of plugging/unplugging
the fido key while trying to authenticate at demo.yubico.com/playground.
Eventually the kernel panics with this stack trace (retyped from [2]):
32 matches
Mail list logo
