Stabilize Inteldrm on Braswell
I was encountering the same crashes as some other Braswell-Users.
(Black Screen after youtube and pmap_flush_cache in panic message in
/var/log/messages)
For *me* those crashes went away as i added two Fixes which Matt Dillon
used in Dragonfly BSD.
The Patch below was applied to an cvs-checkout from 2017-11-15.
Index: i915_gem_gtt.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem_gtt.c,v
retrieving revision 1.15
diff -u -p -r1.15 i915_gem_gtt.c
--- i915_gem_gtt.c 1 Jul 2017 16:14:10 - 1.15
+++ i915_gem_gtt.c 16 Nov 2017 15:51:02 -
@@ -778,7 +778,10 @@ static void gen8_ppgtt_clear_pte_range(s
num_entries--;
}
- kunmap_px(ppgtt, pt);
+ kunmap_px(ppgtt, pt_vaddr); /* XXX dillon, out of order
+ * patch from linux
+ * 44a71024 12-Apr-2016
+ */
pte = 0;
if (++pde == I915_PDES) {
@@ -1317,6 +1320,8 @@ static int gen8_alloc_va_range_3lvl(stru
gen8_for_each_pde(pt, pd, pd_start, pd_len, temp, pde) {
/* Same reasoning as pd */
WARN_ON(!pt);
+if (pt == NULL) /* XXX dillon hack */
+continue; /* XXX dillon hack */
WARN_ON(!pd_len);
WARN_ON(!gen8_pte_count(pd_start, pd_len));
Re: Current #197 Nov 5 umb0 ucom0 umodem0 detached.
Christoph, The first thing I see when looking at your report, is that your USB devices were plugged in via USB3 (XHCI). Please recompile your kernel with XHCI_DEBUG, and share the debug output here (and with mpi@) when you have it, when the error happened next time. Ok? Tinker > Hello ! > > Today I experienced, that umb0 ucom0 umodem0 detached at the same > time. I can't reproduce it but saw it 1 time with snapshot #194 but > before not. [..] > xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev > 3.00/1.00 addr 1 [..] > umb0 at uhub0 port 10 configuration 1 interface 0 "Sierra Wireless > Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 4 > umodem0 at uhub0 port 10 configuration 1 interface 2 "Sierra Wireless > ucom0 at umodem0
Re: pppd and DNS
On Thu, Nov 16, 2017 at 08:36:18PM +, Roderick wrote: > But still I want to get the DNS from the ppp peer. Then you need to ask your ISP for static nameserver IPs, or use a umb(4) device, or implement this missing feature in sppp(8) such that it decodes the relavant IPCP options passed by the PPP session peer and makes the information available somehow. See /usr/src/sys/net/if_spppsubr.c for relevant source code. With my umsm(4) device, running 'tcpdump -n -i ppp0 -v' while connecting, I see: 23:15:59.704894 IPCP: Configure-Nak, Unknown IPCP code 0x81 0308 001c 8106 0a0b 0c0d 8306 0a0b 0c0e 8206 0a0b 0c0d 8406 0a0b 0c0e This seems to be one of several DNS related IPCP codes which our sppp(4) driver ignores. According to Table 7.10 here: https://technet.microsoft.com/en-us/library/cc957981.aspx "Primary DNS server address | 129 or 0x81"
Re: pppd and DNS
On Thu, Nov 16, 2017 at 08:09:27PM +, Roderick wrote: > > > On Thu, 16 Nov 2017, Stefan Sperling wrote: > > > For WAN devices supported by umsm(4), the situation is a bit better. > > The umsm(4) driver shows DNS resolver IPs in ifconfig output so scripts > > can grab them from there. > > Thanks. How do I get the DNS with ifconfig? This is what I get: Sorry, I got confused. I meant umb(4) devices, not umsm(4) devices.
Re: How to share a secret between a process and its children ?
> On 16 nov. 2017 =C3=A0 22:15 +0100, Theo de Raadt , > wrote: > > > On Linux, I'm really not sure that a channel returned by socketpair > > > would ensure confidentiality > > > > Huh? Why not? > > > /proc/pid/fd I'm speaking more generally that a socketpair is safe amongst it's uid, except for root. There is such thing on OpenBSD. And it doesn't matter. If you have another uid that can read it, you're screwed. Inventing crazy shit is pointless. Someone just attaches to the process earlier. So much pointless overdesign to compensate for bad decisions before privsep became well known.
Re: How to share a secret between a process and its children ?
On 16 nov. 2017 à 22:15 +0100, Theo de Raadt , wrote: > > On Linux, I'm really not sure that a channel returned by socketpair > > would ensure confidentiality > > Huh? Why not? > /proc/[pid]/fd
Re: How to share a secret between a process and its children ?
> On Linux, I'm really not sure that a channel returned by socketpair > would ensure confidentiality Huh? Why not?
How to share a secret between a process and its children ?
Hello, I need to share a short secret (say, 32 bytes long) between a process - the father - and its children. The father process generates a random secret at launch. Then it launches multiple children, and children also have children. Both fork and execve are used. The whole tree uses the same Unix user (say, 'daemon') I need each child to be able to access the common secret. But other processes that are not descendants of the father process must not be able to access the secret, even if they also run under 'daemon’. Because there are some execve involved, I can’t just rely on fork to share memory. On Linux, I’m really not sure that a channel returned by socketpair would ensure confidentiality, so I would use a kernel keyring to store and share the secret (http://man7.org/linux/man-pages/man7/keyrings.7.html, session keyrings more exactly). What is the recommended way to share a secret between the father and the descendants on OpenBSD ? Can I assume that the socket pairs returned by socketpair provide confidentiality and integrity ? Thanks !
Re: Huawei E372 UMTS Stick
On Mon, 30 Oct 2017, I asked: Does anyone know if the above device ist supported by OpenBSD? It works. It could be mentioned in man 4 umsm. As said, it seems to be Quadband and someone may be interessted on it. Rodrigo.
Re: pppd and DNS
On Thu, 16 Nov 2017, Stefan Sperling wrote: You could try running unbound(8) and make resolv.conf point to 127.0.0.1. That should give you working DNS in any case. That works and was very simple. In oposition to BIND, it was ready to be consulted. But still I want to get the DNS from the ppp peer. Rodrigo.
Re: pppd and DNS
On Thu, 16 Nov 2017, Stefan Sperling wrote: For WAN devices supported by umsm(4), the situation is a bit better. The umsm(4) driver shows DNS resolver IPs in ifconfig output so scripts can grab them from there. Thanks. How do I get the DNS with ifconfig? This is what I get: - root@nc10% ifconfig ppp0 ppp0: flags=8051 mtu 1500 index 6 priority 0 llprio 3 groups: ppp egress inet 37.80.16.9 --> 10.0.0.1 netmask 0xff00 - And even to get a remote address above was some kind of gambling: --- :10.0.0.1 ipcp-accept-local ipcp-accept-remote noipdefault --- Regards Rodrigo.
CVS diff for FAQ Ports SpecialTopics
Hi, all.
Is normal this tabulation into TT text?
If not, i suggest this diff:
Index: faq/ports/specialtopics.html
===
RCS file: /cvs/www/faq/ports/specialtopics.html,v
retrieving revision 1.71
diff -u -p -r1.71 specialtopics.html
--- faq/ports/specialtopics.html12 Oct 2017 16:44:00 - 1.71
+++ faq/ports/specialtopics.html16 Nov 2017 17:54:00 -
@@ -325,7 +325,7 @@ Make sure you read the section about tro
This script is normally run during the configure stage of ports building.
To invoke the configure script, one only has to set
-CONFIGURE_STYLE= gnu
+CONFIGURE_STYLE=gnu
which will automatically invoke ${WRKSRC}/configure.
--
~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<
Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net
Re: Abort Trap question
On 11/16/17 08:40, Ax0n wrote: > For what it's worth, bricking my main workstation in this way a few times > over the past 20 years yes the only reason I thought about it. It also got > me into a (good) habit of examining the paths and contents of archive files > every single time before I extract them. > > On Nov 16, 2017 06:14, "Daniel Boyd" wrote: > >> Haha crap. I think this is what happened. I haven’t bothered >> downloading src.tar.gz in awhile bc of syspatch, but since this is a >> PowerPC machine, i wanted to be ready for the first errata. This is what I >> get for doing things from memory instead of reading the FAQ. >> >> Right. Let’s pretend that this didn’t happen, shall we? >> >> Sent from my iPhone good news: that means your recovery is probably pretty easy -- just boot from bsd.rd (which should be unharmed) and do a re-install. Nick. >> >> > On Nov 15, 2017, at 8:54 PM, Ax0n wrote: >> > >> > A quick thought... are you extracting src.tar.gz into /usr (like you to >> > with ports.tar.gz)? On a few occasions, I've done this (instead of making >> > sure I'm in /usr/src first as I should) and had system binaries get >> > clobbered. When I've accidentally done this in the past, I do get a bunch >> > of abort trap errors and a predictably un-bootable system. Example: This >> > block of stuff from src.tar.gz, if extracted whilst in /usr, would >> > overwrite /usr/bin/cat with a directory full of the source code for >> cat(1) >> > and so on and so forth. >> > >> > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin >> > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/CVS >> > -rw-rw-r-- 1 axon axon 5 Oct 9 22:38 bin/CVS/Root >> > -rw-rw-r-- 1 axon axon 8 Oct 9 22:38 bin/CVS/Repository >> > -rw-rw-r-- 1 axon axon 439 Oct 9 22:41 bin/CVS/Entries >> > -rw-rw-r-- 1 axon axon18 Oct 9 22:41 bin/CVS/Tag >> > -rw-rw-r-- 1 axon axon 241 Apr 25 2016 bin/Makefile >> > -rw-rw-r-- 1 axon axon 145 Jul 11 2014 bin/Makefile.inc >> > drwxrwxr-x 2 axon axon 0 Oct 9 22:38 bin/cat >> > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/cat/CVS >> > -rw-rw-r-- 1 axon axon 5 Oct 9 22:38 bin/cat/CVS/Root >> > -rw-rw-r-- 1 axon axon12 Oct 9 22:38 >> > bin/cat/CVS/Repository >> > -rw-rw-r-- 1 axon axon 172 Oct 9 22:41 >> bin/cat/CVS/Entries >> > -rw-rw-r-- 1 axon axon18 Oct 9 22:41 bin/cat/CVS/Tag >> > -rw-rw-r-- 1 axon axon93 Feb 18 2017 bin/cat/Makefile >> > -rw-rw-r-- 1 axon axon 4848 Jul 9 2016 bin/cat/cat.1 >> > -rw-rw-r-- 1 axon axon 5567 Oct 19 2016 bin/cat/cat.c >> > >> > >> > >> > On Wed, Nov 15, 2017 at 5:24 PM, patrick keshishian >> > wrote: >> > >> >>> On 11/15/17, Philip Guenther wrote: >> >>> On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington >> >>> wrote: >> >>> >> > On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote: >> > I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to >> > be working fine until I go to untar src.tar.gz at which point it >> >> throws >> > some abort trap errors and crashes. If I reboot, I get a bunch of >> > abort traps during the boot process followed by several: >> > >> > init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ... >> > >> > What do you guys think this is...? Hard drive failure...? >> >> Out of curiosity, does the same thing happen if you extract the tar >> with >> the pax(1) program? That'll at least let you know if it's tar causing >> the problem or not. >> >> >>> >> >>> tar _is_ pax: >> >>> : corwin; ls -li /bin/tar /bin/pax >> >>> 52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 /bin/pax >> >>> 52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 /bin/tar >> >>> : corwin; >> >>> >> >>> Fundamentally, unless a userspace process is poking at devices or >> >> similar, >> >>> it should be unable to panic the kernel. An abort trap in the kernel >> is >> >>> either a kernel bug or a hardware bug. IIRC there's some pmap bug on >> >>> macppc that no one has managed to track down which causes crashes on >> some >> >>> machines, but not others. I've never hit it on the Macbook I use for >> >>> builds, but the ports build boxes, whatever model they are, seem to hit >> >> it >> >>> periodically... >> >> >> >> I read it as the tar process is the one aborting. which, if true, >> >> sounds like user-land and kernel are out-of-sync. >> >> >> >> Unfortunately, specific info is missing from the problem report. >> >> >> >> --patrick >> >> >> >> >> >> >
Re: Abort Trap question
> > On Nov 16, 2017 at 6:14 AM,wrote: > > > Haha crap. I think this is what happened. I haven’t bothered downloading > src.tar.gz in awhile bc of syspatch, but since this is a PowerPC machine, i > wanted to be ready for the first errata. This is what I get for doing things > from memory instead of reading the FAQ. > > > > > > The last I looked it had been removed from the FAQ. I didn't want to glob my > system so I had to look through CVS to find the version with pre packing your > src tree. > > > > > Right. Let’s pretend that this didn’t happen, shall we > > > Sent from my iPhone > On Nov 15, 2017, at 8:54 PM, Ax0n wrote: > > A > quick thought... are you extracting src.tar.gz into /usr (like you to > > with ports.tar.gz)? On a few occasions, I've done this (instead of making > > sure I'm in /usr/src first as I should) and had system binaries get > > clobbered. When I've accidentally done this in the past, I do get a bunch > > of abort trap errors and a predictably un-bootable system. Example: This > > block of stuff from src.tar.gz, if extracted whilst in /usr, would > > overwrite /usr/bin/cat with a directory full of the source code for cat(1) > > and so on and so forth. > > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin > > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/CVS > -rw-rw-r-- 1 axon axon 5 Oct > 9 22:38 bin/CVS/Root > -rw-rw-r-- 1 axon axon 8 Oct 9 22:38 > bin/CVS/Repository > -rw-rw-r-- 1 axon axon 439 Oct 9 22:41 bin/CVS/Entries > > -rw-rw-r-- 1 axon axon 18 Oct 9 22:41 bin/CVS/Tag > -rw-rw-r-- 1 axon > axon 241 Apr 25 2016 bin/Makefile > -rw-rw-r-- 1 axon axon 145 Jul 11 2014 > bin/Makefile.inc > drwxrwxr-x 2 axon axon 0 Oct 9 22:38 bin/cat > > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/cat/CVS > -rw-rw-r-- 1 axon axon 5 > Oct 9 22:38 bin/cat/CVS/Root > -rw-rw-r-- 1 axon axon 12 Oct 9 22:38 > > bin/cat/CVS/Repository > -rw-rw-r-- 1 axon axon 172 Oct 9 22:41 > bin/cat/CVS/Entries > -rw-rw-r-- 1 axon axon 18 Oct 9 22:41 bin/cat/CVS/Tag > > -rw-rw-r-- 1 axon axon 93 Feb 18 2017 bin/cat/Makefile > -rw-rw-r-- 1 > axon axon 4848 Jul 9 2016 bin/cat/cat.1 > -rw-rw-r-- 1 axon axon 5567 Oct > 19 2016 bin/cat/cat.c > > > > On Wed, Nov 15, 2017 at 5:24 PM, > patrick keshishian > wrote: > >>> On 11/15/17, Philip Guenther wrote: > >>> On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington >>> wrote: >>> > > On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote: > > I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to > > be working fine until I go to untar src.tar.gz at which point it >> throws > > some abort trap errors and crashes. If I reboot, I get a bunch of > > abort traps during the boot process followed by several: > > > init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ... > > > What do you guys think this is...? Hard drive failure...? > Out of curiosity, does the same thing happen if you extract the > tar with the pax(1) program? That'll at least let you know if it's tar > causing the problem or not. >>> >>> tar _is_ pax: >>> : > corwin; ls -li /bin/tar /bin/pax >>> 52015 -r-xr-xr-x 3 root bin 433472 Nov > 1 11:15 /bin/pax >>> 52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 > /bin/tar >>> : corwin; >>> >>> Fundamentally, unless a userspace > process is poking at devices or >> similar, >>> it should be unable to > panic the kernel. An abort trap in the kernel is >>> either a kernel bug or > a hardware bug. IIRC there's some pmap bug on >>> macppc that no one has > managed to track down which causes crashes on some >>> machines, but not > others. I've never hit it on the Macbook I use for >>> builds, but the > ports build boxes, whatever model they are, seem to hit >> it >>> > periodically... >> >> I read it as the tar process is the one aborting. > which, if true, >> sounds like user-land and kernel are out-of-sync. >> > >> Unfortunately, specific info is missing from the problem report. >> >> > --patrick >> >> >
Re: pppd and DNS
On Thu, Nov 16, 2017 at 01:13:55PM +, Roderick wrote: > > Dear Sirs! > > How it is supposed that I get the DNS servers from a PPP connection? > > Should I guess the servers and put them manually in resolv.conf? > > Something like dhclient ppp0 does not work. > > I think this is an old thema: > > http://openbsd-archive.7691.n7.nabble.com/pppd-usepeerdns-td261633.html > > https://marc.info/?l=openbsd-tech&m=111946828027916&w=2 > > Is there a solution that I do not know? > > Otherwise I wonder that others do not miss such a feature: > UMTS providers do not give much information and one must > lietraly quess it with help google. > > Rodrigo. Indeed, it seems pppd doesn't support getting DNS resolvers in client mode. I've run into the same issue years ago. Nowadays I always use a VPN across such links and just get DNS from the other end of my tunnel. You could try running unbound(8) and make resolv.conf point to 127.0.0.1. That should give you working DNS in any case. For WAN devices supported by umsm(4), the situation is a bit better. The umsm(4) driver shows DNS resolver IPs in ifconfig output so scripts can grab them from there.
Re: Abort Trap question
For what it's worth, bricking my main workstation in this way a few times over the past 20 years yes the only reason I thought about it. It also got me into a (good) habit of examining the paths and contents of archive files every single time before I extract them. On Nov 16, 2017 06:14, "Daniel Boyd" wrote: > Haha crap. I think this is what happened. I haven’t bothered > downloading src.tar.gz in awhile bc of syspatch, but since this is a > PowerPC machine, i wanted to be ready for the first errata. This is what I > get for doing things from memory instead of reading the FAQ. > > Right. Let’s pretend that this didn’t happen, shall we? > > Sent from my iPhone > > > On Nov 15, 2017, at 8:54 PM, Ax0n wrote: > > > > A quick thought... are you extracting src.tar.gz into /usr (like you to > > with ports.tar.gz)? On a few occasions, I've done this (instead of making > > sure I'm in /usr/src first as I should) and had system binaries get > > clobbered. When I've accidentally done this in the past, I do get a bunch > > of abort trap errors and a predictably un-bootable system. Example: This > > block of stuff from src.tar.gz, if extracted whilst in /usr, would > > overwrite /usr/bin/cat with a directory full of the source code for > cat(1) > > and so on and so forth. > > > > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin > > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/CVS > > -rw-rw-r-- 1 axon axon 5 Oct 9 22:38 bin/CVS/Root > > -rw-rw-r-- 1 axon axon 8 Oct 9 22:38 bin/CVS/Repository > > -rw-rw-r-- 1 axon axon 439 Oct 9 22:41 bin/CVS/Entries > > -rw-rw-r-- 1 axon axon18 Oct 9 22:41 bin/CVS/Tag > > -rw-rw-r-- 1 axon axon 241 Apr 25 2016 bin/Makefile > > -rw-rw-r-- 1 axon axon 145 Jul 11 2014 bin/Makefile.inc > > drwxrwxr-x 2 axon axon 0 Oct 9 22:38 bin/cat > > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/cat/CVS > > -rw-rw-r-- 1 axon axon 5 Oct 9 22:38 bin/cat/CVS/Root > > -rw-rw-r-- 1 axon axon12 Oct 9 22:38 > > bin/cat/CVS/Repository > > -rw-rw-r-- 1 axon axon 172 Oct 9 22:41 > bin/cat/CVS/Entries > > -rw-rw-r-- 1 axon axon18 Oct 9 22:41 bin/cat/CVS/Tag > > -rw-rw-r-- 1 axon axon93 Feb 18 2017 bin/cat/Makefile > > -rw-rw-r-- 1 axon axon 4848 Jul 9 2016 bin/cat/cat.1 > > -rw-rw-r-- 1 axon axon 5567 Oct 19 2016 bin/cat/cat.c > > > > > > > > On Wed, Nov 15, 2017 at 5:24 PM, patrick keshishian > > wrote: > > > >>> On 11/15/17, Philip Guenther wrote: > >>> On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington > >>> wrote: > >>> > > On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote: > > I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to > > be working fine until I go to untar src.tar.gz at which point it > >> throws > > some abort trap errors and crashes. If I reboot, I get a bunch of > > abort traps during the boot process followed by several: > > > > init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ... > > > > What do you guys think this is...? Hard drive failure...? > > Out of curiosity, does the same thing happen if you extract the tar > with > the pax(1) program? That'll at least let you know if it's tar causing > the problem or not. > > >>> > >>> tar _is_ pax: > >>> : corwin; ls -li /bin/tar /bin/pax > >>> 52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 /bin/pax > >>> 52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 /bin/tar > >>> : corwin; > >>> > >>> Fundamentally, unless a userspace process is poking at devices or > >> similar, > >>> it should be unable to panic the kernel. An abort trap in the kernel > is > >>> either a kernel bug or a hardware bug. IIRC there's some pmap bug on > >>> macppc that no one has managed to track down which causes crashes on > some > >>> machines, but not others. I've never hit it on the Macbook I use for > >>> builds, but the ports build boxes, whatever model they are, seem to hit > >> it > >>> periodically... > >> > >> I read it as the tar process is the one aborting. which, if true, > >> sounds like user-land and kernel are out-of-sync. > >> > >> Unfortunately, specific info is missing from the problem report. > >> > >> --patrick > >> > >> > >
tar bombs (was: RE: Abort Trap question)
Hi, "Daniel Boyd" wrote: > Haha crap. I think this is what happened. I haven't bothered downloading > src.tar.gz in awhile bc of syspatch, but since this is a PowerPC machine, i > wanted to be ready for the first errata. This is what I get for doing things > from memory instead of reading the FAQ. Mistakes happen, don't worry =) Though I consider it good practice to at least do a 'pax -v | head' before extracting anything. And in dubious cases, I create a '.x/' dir first and do the extraction in there. HTH, --schaafuit.
HDD fail signal
On various SATA/SAS backplanes, notably the Icy Box/Raidsonic IB555SK, there is a 'HDD fail signal IN' connector and a note that this can be provided by the controller, to make the failure LED flash. I can't find any controller that supports this, and presume it's directly supported by the controller (or does it need OS support?). Can anyone offer advice? I'm thinking about buying another backplane with the same signal, because it's nice to do things correctly, but there's no point if nothing supports it... (unless something is manually hacked together)
pppd and DNS
Dear Sirs! How it is supposed that I get the DNS servers from a PPP connection? Should I guess the servers and put them manually in resolv.conf? Something like dhclient ppp0 does not work. I think this is an old thema: http://openbsd-archive.7691.n7.nabble.com/pppd-usepeerdns-td261633.html https://marc.info/?l=openbsd-tech&m=111946828027916&w=2 Is there a solution that I do not know? Otherwise I wonder that others do not miss such a feature: UMTS providers do not give much information and one must lietraly quess it with help google. Rodrigo.
Re: Abort Trap question
Haha crap. I think this is what happened. I haven’t bothered downloading src.tar.gz in awhile bc of syspatch, but since this is a PowerPC machine, i wanted to be ready for the first errata. This is what I get for doing things from memory instead of reading the FAQ. Right. Let’s pretend that this didn’t happen, shall we? Sent from my iPhone > On Nov 15, 2017, at 8:54 PM, Ax0n wrote: > > A quick thought... are you extracting src.tar.gz into /usr (like you to > with ports.tar.gz)? On a few occasions, I've done this (instead of making > sure I'm in /usr/src first as I should) and had system binaries get > clobbered. When I've accidentally done this in the past, I do get a bunch > of abort trap errors and a predictably un-bootable system. Example: This > block of stuff from src.tar.gz, if extracted whilst in /usr, would > overwrite /usr/bin/cat with a directory full of the source code for cat(1) > and so on and so forth. > > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/CVS > -rw-rw-r-- 1 axon axon 5 Oct 9 22:38 bin/CVS/Root > -rw-rw-r-- 1 axon axon 8 Oct 9 22:38 bin/CVS/Repository > -rw-rw-r-- 1 axon axon 439 Oct 9 22:41 bin/CVS/Entries > -rw-rw-r-- 1 axon axon18 Oct 9 22:41 bin/CVS/Tag > -rw-rw-r-- 1 axon axon 241 Apr 25 2016 bin/Makefile > -rw-rw-r-- 1 axon axon 145 Jul 11 2014 bin/Makefile.inc > drwxrwxr-x 2 axon axon 0 Oct 9 22:38 bin/cat > drwxrwxr-x 2 axon axon 0 Oct 9 22:41 bin/cat/CVS > -rw-rw-r-- 1 axon axon 5 Oct 9 22:38 bin/cat/CVS/Root > -rw-rw-r-- 1 axon axon12 Oct 9 22:38 > bin/cat/CVS/Repository > -rw-rw-r-- 1 axon axon 172 Oct 9 22:41 bin/cat/CVS/Entries > -rw-rw-r-- 1 axon axon18 Oct 9 22:41 bin/cat/CVS/Tag > -rw-rw-r-- 1 axon axon93 Feb 18 2017 bin/cat/Makefile > -rw-rw-r-- 1 axon axon 4848 Jul 9 2016 bin/cat/cat.1 > -rw-rw-r-- 1 axon axon 5567 Oct 19 2016 bin/cat/cat.c > > > > On Wed, Nov 15, 2017 at 5:24 PM, patrick keshishian > wrote: > >>> On 11/15/17, Philip Guenther wrote: >>> On Wed, Nov 15, 2017 at 11:08 AM, Mike Coddington >>> wrote: >>> > On Wed, Nov 15, 2017 at 10:01:09AM -0600, Daniel Boyd wrote: > I've installed OpenBSD/macppc twice on my G4 Cube now and it seems to > be working fine until I go to untar src.tar.gz at which point it >> throws > some abort trap errors and crashes. If I reboot, I get a bunch of > abort traps during the boot process followed by several: > > init: can't exec getty '/usr/libexec/getty' for pot /dev/ttyC3: ... > > What do you guys think this is...? Hard drive failure...? Out of curiosity, does the same thing happen if you extract the tar with the pax(1) program? That'll at least let you know if it's tar causing the problem or not. >>> >>> tar _is_ pax: >>> : corwin; ls -li /bin/tar /bin/pax >>> 52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 /bin/pax >>> 52015 -r-xr-xr-x 3 root bin 433472 Nov 1 11:15 /bin/tar >>> : corwin; >>> >>> Fundamentally, unless a userspace process is poking at devices or >> similar, >>> it should be unable to panic the kernel. An abort trap in the kernel is >>> either a kernel bug or a hardware bug. IIRC there's some pmap bug on >>> macppc that no one has managed to track down which causes crashes on some >>> machines, but not others. I've never hit it on the Macbook I use for >>> builds, but the ports build boxes, whatever model they are, seem to hit >> it >>> periodically... >> >> I read it as the tar process is the one aborting. which, if true, >> sounds like user-land and kernel are out-of-sync. >> >> Unfortunately, specific info is missing from the problem report. >> >> --patrick >> >>
Re: xfce4 and gtk+3 applications
On Wed, Nov 15, 2017 at 02:16:49AM +0100, Zeljko Jovanovic wrote: > > On 13.11.2017. 00:47, Dutch Ingraham wrote: > I encountered this long ago, but it is actually not an OpenBSD or gtk+3 issue. > The problem is lack of gtk+3 themes in Xfce 4.12. Until Xfce 4.14 is released, > you can try adding some theme from an another source. For example, > https://www.gnome-look.org/p/1191436/ looks promising. Indeed, I added a few of the available themes and the difference between gtk+2 and gtk+3 themes was the issue. Thanks!
Re: error trying to load C/XS Perl module
On 2017-11-15, Alceu Rodrigues de Freitas Junior wrote: > Em 15/11/2017 15:06, Stuart Henderson escreveu: >> On 2017-11-15, Stuart Henderson wrote: >>> >>> If I make a port using the normal ports framework and try it on -current, >>> I get this, which is a bit further but not all the way : >>> >>> 1..23 >>> ok 1 - use PerlIO::eol; >>> ok 2 >>> ok 3 >>> ok 4 >>> ok 5 >>> ok 6 - open for read >>> Failed 17/23 subtests >>> >>> Test Summary Report >>> --- >>> t/1-basic.t (Wstat: 134 Tests: 6 Failed: 0) >>>Non-zero wait status: 134 >>>Parse errors: Bad plan. You planned 23 tests but ran 6. >>> Files=1, Tests=6, 0 wallclock secs ( 0.01 usr 0.04 sys + 0.03 cusr 0.03 >>> csys = 0.11 CPU) >>> Result: FAIL >>> >>> >>> >> >> Ha. I didn't notice before I wrote a local port, but there's already >> a port in the tree. So actually you should just be able to use >> "pkg_add p5-PerlIO-eol". >> >> In general: use the OS packages, don't try and mix with cpan. >> In most cases it's easier to write a port than deal with the mess >> that you'll end up in by using two different/conflicting package >> systems (i.e. OpenBSD's usual one and CPAN). >> > > Thanks Stuart! > > Actually, using CPAN is the main objective here because I'm testing > OpenBSD 6.1 as a CPAN Smoker > (https://github.com/glasswalk3r/cpan-openbsd-smoker). > > So, basically it really didn't occurred to me to search for a ports, but > I see that it is updated to the latest version of this module. > > I'm not acquainted with creating ports, but I guess I should start from > https://www.openbsd.org/faq/ports/ and then checkout > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/devel/p5-PerlIO-eol/Makefile?rev=1.17&content-type=text/plain. > > So far, I wasn't able to figure out anything outstanding with the > building process that is common to Perl modules, but I didn't find > anything regarding executing tests as well. To me, the Makefile over > there has a bit of magic to make it work, so I would appreciate any > inputs on that. > > The individual port Makefile includes bsd.port.mk (from /usr/ports/infrastructure/mk), and that pulls in additional parts via the MODULES mechanism (especially relevant here are cpan.port.mk and perl.port.mk). If you want to see the actual command line used to run tests for this port, "make fake; make -n _internal-test". You'll need a checkout of the whole ports tree rather than just the one directory.
