Re: Xorg hangs on recent snapshots

On Wed, 5 Feb 2020 22:31:52 -0700 Aaron Bieber wrote: > On Wed, 05 Feb 2020 at 20:29:31 +0100, William Orr wrote: > > > > Hey, > > > > On recent a snap (04/02/2020), the unpriv'ed process of Xorg seems to hang, > > becoming totally unresponsive. Running `ktrace` on the process fails to log > >

Re: sysupgrade ignores the sets selected from install (6.5 -> 6.6)

Frédéric Dhieux wrote: > Hi OpenBSD team, > > I would like to report a problem I have, we have in production many OpenBSD > where we remove X*, game* and comp* at the install. > > Everything is fine except sysupgrade adds every sets again when I try to > upgrade my OpenBSD version. Is it

Re: sysupgrade ignores the sets selected from install (6.5 -> 6.6)

On Thu, Feb 06, 2020 at 07:55:40PM -0500, Bryan Steele wrote: > On Thu, Feb 06, 2020 at 03:37:14PM +, Frédéric Dhieux wrote: > > Hi OpenBSD team, > > > > I would like to report a problem I have, we have in production many OpenBSD > > where we remove X*, game* and comp* at the install. > > >

Re: sysupgrade ignores the sets selected from install (6.5 -> 6.6)

On Thu, Feb 06, 2020 at 03:37:14PM +, Frédéric Dhieux wrote: > Hi OpenBSD team, > > I would like to report a problem I have, we have in production many OpenBSD > where we remove X*, game* and comp* at the install. > > Everything is fine except sysupgrade adds every sets again when I try to

sysupgrade ignores the sets selected from install (6.5 -> 6.6)

Hi OpenBSD team, I would like to report a problem I have, we have in production many OpenBSD where we remove X*, game* and comp* at the install. Everything is fine except sysupgrade adds every sets again when I try to upgrade my OpenBSD version. Is it possible for sysupgrade to preserve the

Re: OpenIKED missing EAP-MSCHAPv2 for client setup

On 2020/02/06 18:03, Master One wrote: > To whom it may concern, > > Please excuse me sending such a questionable bug or feature request > this way, I'm not subscribed to any OpenBSD mailing list and I'm not an > OpenBSD user yet but currently evaluating the move from GNU/Linux to > OpenBSD. > >

Re: xhci: KASSERT panic on USB run0 network load

On Thu, Feb 06, 2020 at 04:46:08PM +0100, Adam Wolk wrote: > On Tue, Feb 04, 2020 at 03:19:17PM +1100, Kenneth R Westerback wrote: > > On Sun, Feb 02, 2020 at 10:19:44PM -0500, Kenneth R Westerback wrote: > > > On Mon, Feb 03, 2020 at 12:30:18AM +0100, Adam Wolk wrote: > > > > On Sun, Feb 02, 2020

Sun V240 will not boot with generic ati video

Hello, I tried to post this at sp...@openbsd.org, but it bounced, or rather didn't go through at all so I apologize in advance. I was hoping to get decent video (any video at all actually) on my V240 since my XVR-600 was not displaying anything at all despite everything appearing to work. I

Re: umb device no longer detected

leeb wrote: > OK, just rebuilt my kernel: > > x230$ grep MC7700 umsm.c > {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7700}, 0}, > x230$ diff if_umb.c if_umb.c.~1.31.~ > > 276,277c276 > < /* return

Re: umb device no longer detected

Gerhard Roth wrote: > thank you very much for your generous offer. But I don't think this is > needed. I think the umsm(4) vs. umb(4) attach problem can be attacked > without having this specific device as it happens with other Sierra > Wireless devices, too. Yes, it looks like the testing

OpenIKED missing EAP-MSCHAPv2 for client setup

To whom it may concern, Please excuse me sending such a questionable bug or feature request this way, I'm not subscribed to any OpenBSD mailing list and I'm not an OpenBSD user yet but currently evaluating the move from GNU/Linux to OpenBSD. I have looked into the possibility to use the tools

Re: xhci: KASSERT panic on USB run0 network load

On Tue, Feb 04, 2020 at 03:19:17PM +1100, Kenneth R Westerback wrote: > On Sun, Feb 02, 2020 at 10:19:44PM -0500, Kenneth R Westerback wrote: > > On Mon, Feb 03, 2020 at 12:30:18AM +0100, Adam Wolk wrote: > > > On Sun, Feb 02, 2020 at 04:06:38PM -0500, Kenneth Westerback wrote: > > > > A kernel

Re: umb device no longer detected

OK, just rebuilt my kernel: x230$ grep MC7700 umsm.c {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7700}, 0}, x230$ diff if_umb.c if_umb.c.~1.31.~ 276,277c276 < /* return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; */ <

Re: umb device no longer detected

Hi Lee, thank you very much for your generous offer. But I don't think this is needed. I think the umsm(4) vs. umb(4) attach problem can be attacked without having this specific device as it happens with other Sierra Wireless devices, too. Theo had a M7700 that would not attach a umb(4) but as I

Re: dig: internal_send when network is dead

I don't know if it is expected behavior. It does not surprise me though. Since you are asking, what did *you* expect? On 6 February 2020 00:41:40 CET, jungle Boogie wrote: >Hi All, > >Not sure if this is the expected behavior: > >$ ping 1.1.1.1 >PING 1.1.1.1 (1.1.1.1): 56 data bytes >ping: