Re: iMacPro and OpenBSD, kernel panicking

[Krystian Lewandowski]

> Wiadomość napisana przez Mike Larkin  w dniu 
> 24.01.2019, o godz. 00:15:
> 
> On Tue, Jan 22, 2019 at 11:31:08AM +0100, Krystian Lewandowski wrote:
>> 
>>> Wiadomość napisana przez Mike Larkin  w dniu 
>>> 22.01.2019, o godz. 04:35:
>>> 
>>> On Mon, Jan 21, 2019 at 07:29:40PM -0800, Mike Larkin wrote:
 On Tue, Jan 22, 2019 at 03:14:13AM +0100, Krystian Lewandowski wrote:
> Hello misc@,
> 
> I’m trying to boot OpenBSD (current) on iMac Pro (iMacPro1,1).
> It’s Apple’s Xeon-W based PC with ECC memory.
> 
> This machine is very picky when it comes to OS support. Obviously macOS 
> is well
> supported and I don’t have problems with it, MS Windows on an
> external USB drive is stable as well.
> I tried whole BSD family, multiple Linux based distros and Illumos. The 
> only
> Linux distribution I was able to boot and install was Clear Linux* - 
> ended up with kernel
> panicking randomly, and regarding BSDs - I was able to install and boot 
> FreeBSD
> but it randomly fails with a Machine Check Exceptions.
> 
> The other interesting thing is infamous T2 chip in which iMac Pro is 
> equipped -
> almost every crash ends up with BridgeOS crash report.
> 
> I would consider OpenBSD assertion failures and FreeBSD MCA errors
> "UNCORR PCC GCACHE L2 ERR error" as valid if it wasn’t for rock stable 
> macOS and
> MS Windows (and on both it’s pushed hard at times, for a few hours 
> straight, incl. VMs).
> And my understanding is that this iMac Pro is no exception - other iMacs 
> present
> similar behaviour (ending up with similar T2 chip Bridge OS crash 
> reports).
> 
> I tried to do my homework and installed OpenBSD on an external USB drive 
> via
> VMWare Fusion and built kernel with DEBUG flag.
> External USB drive is the only option because of T2 chip.
> 
> Tried to boot .SP kernel, tried to disable some devices - though probably
> doesn’t matter because I assume it’s crashing before autoconf is even 
> involved.
> I also, tried to update microcode at boot on FreeBSD - someone suggested 
> that
> via Twitter - didn’t help for at runtime MCA faults (CPU had most recent 
> microcode).
> 
> OpenBSD snapshot fails with:
> "fatal machine check in supervisor mode"
> "panic: trap type 18, code=0, pc=…"
> https://www.dropbox.com/s/birtxskxayjvxht/OpenBSD%20default%20kernel.jpeg?dl=0
> 
 
 This may be related to a set of recent changes I made. Can you try 
 6.4-RELEASE
 and see if that still panics?
 
 -ml
 
>>> 
>>> Sorry, didn't see the other captures. The most recent crash may still be 
>>> due to
>>> the recent changes though. The MCEs, well, that's another thing.
>>> 
>>> Can you send me the output of "machine memory" from the boot> prompt please?
>>> 
>>> -ml
>>> 
>> 
>> Sure,
>> please find machine memory output here: 
>> https://www.dropbox.com/s/sbgq7av9m0sre14/machine_memory.jpeg?dl=0
>> 
>> Krystian
>> 
> 
> Does shrinking the amount of memory get any further?
> 
> boot> mach mem =16G
> 
> ... something like that?
> 
> -ml
> 

I think, I could say yes, a bit (compared to my most recent attempts).  Now I 
can
see mpath0 and scsibus0 being logged before the crash.  Tried a few times on 
default
kernel and DEBUG kernel, very similar in all tries.

https://www.dropbox.com/s/z9xnheqhy274z8z/mem%2016G.jpeg?dl=0
https://www.dropbox.com/s/ozqlhsch0yz4ibr/16G%20default%20kernel.jpeg?dl=0
https://www.dropbox.com/s/hbzbf1aa2u0a9h4/16G%20debug%20kernel.jpeg?dl=0

And after that, macOS welcomed me with "x86 CPU CATERR detected report.

Krystian

Re: iMacPro and OpenBSD, kernel panicking

[Mike Larkin]

On Tue, Jan 22, 2019 at 11:31:08AM +0100, Krystian Lewandowski wrote:
> 
> > Wiadomość napisana przez Mike Larkin  w dniu 
> > 22.01.2019, o godz. 04:35:
> > 
> > On Mon, Jan 21, 2019 at 07:29:40PM -0800, Mike Larkin wrote:
> >> On Tue, Jan 22, 2019 at 03:14:13AM +0100, Krystian Lewandowski wrote:
> >>> Hello misc@,
> >>> 
> >>> I’m trying to boot OpenBSD (current) on iMac Pro (iMacPro1,1).
> >>> It’s Apple’s Xeon-W based PC with ECC memory.
> >>> 
> >>> This machine is very picky when it comes to OS support. Obviously macOS 
> >>> is well
> >>> supported and I don’t have problems with it, MS Windows on an
> >>> external USB drive is stable as well.
> >>> I tried whole BSD family, multiple Linux based distros and Illumos. The 
> >>> only
> >>> Linux distribution I was able to boot and install was Clear Linux* - 
> >>> ended up with kernel
> >>> panicking randomly, and regarding BSDs - I was able to install and boot 
> >>> FreeBSD
> >>> but it randomly fails with a Machine Check Exceptions.
> >>> 
> >>> The other interesting thing is infamous T2 chip in which iMac Pro is 
> >>> equipped -
> >>> almost every crash ends up with BridgeOS crash report.
> >>> 
> >>> I would consider OpenBSD assertion failures and FreeBSD MCA errors
> >>> "UNCORR PCC GCACHE L2 ERR error" as valid if it wasn’t for rock stable 
> >>> macOS and
> >>> MS Windows (and on both it’s pushed hard at times, for a few hours 
> >>> straight, incl. VMs).
> >>> And my understanding is that this iMac Pro is no exception - other iMacs 
> >>> present
> >>> similar behaviour (ending up with similar T2 chip Bridge OS crash 
> >>> reports).
> >>> 
> >>> I tried to do my homework and installed OpenBSD on an external USB drive 
> >>> via
> >>> VMWare Fusion and built kernel with DEBUG flag.
> >>> External USB drive is the only option because of T2 chip.
> >>> 
> >>> Tried to boot .SP kernel, tried to disable some devices - though probably
> >>> doesn’t matter because I assume it’s crashing before autoconf is even 
> >>> involved.
> >>> I also, tried to update microcode at boot on FreeBSD - someone suggested 
> >>> that
> >>> via Twitter - didn’t help for at runtime MCA faults (CPU had most recent 
> >>> microcode).
> >>> 
> >>> OpenBSD snapshot fails with:
> >>> "fatal machine check in supervisor mode"
> >>> "panic: trap type 18, code=0, pc=…"
> >>> https://www.dropbox.com/s/birtxskxayjvxht/OpenBSD%20default%20kernel.jpeg?dl=0
> >>> 
> >> 
> >> This may be related to a set of recent changes I made. Can you try 
> >> 6.4-RELEASE
> >> and see if that still panics?
> >> 
> >> -ml
> >> 
> > 
> > Sorry, didn't see the other captures. The most recent crash may still be 
> > due to
> > the recent changes though. The MCEs, well, that's another thing.
> > 
> > Can you send me the output of "machine memory" from the boot> prompt please?
> > 
> > -ml
> > 
> 
> Sure,
> please find machine memory output here: 
> https://www.dropbox.com/s/sbgq7av9m0sre14/machine_memory.jpeg?dl=0
> 
> Krystian
> 

Does shrinking the amount of memory get any further?

boot> mach mem =16G

... something like that?

-ml

Re: Squid slower compared to Linux how to boost it?

[Juan Francisco Cantero Hurtado]

On Tue, Jan 22, 2019 at 07:56:30PM -0500, Steven Shockley wrote:
> On 1/22/2019 11:51 AM, Juan Francisco Cantero Hurtado wrote:
> > On Tue, Jan 22, 2019 at 07:49:06AM +, slackwaree wrote:
> >> Hello,
> >>
> >> I'm migrating from an old Debian Wheezy 7.11 to OpenBSD 6.3.
> > 
> > If you're migrating to OpenBSD, then try with -current and update to 6.5
> > when we release it.
> 
> Was there a specific change that might make a difference?  Thanks.

Yes, a full year of work.

Anyway, my point is that you're installing a version which will be EOL
in a few months and the security patches for ports goes only to the
-stable branch (6.4). I think that testing your setup with -current
before of migrate everything is easier for you, instead of install 6.3
now and then update to 6.4 and finally update to 6.5 (we don't support
updates of non-consecutive version, i.e. 6.3 -> 6.5).


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: openbsd : foundation : donation : annual : automatic : any method?

[Marcus MERIGHI]

mayur...@kathe.in (Mayuresh Kathe), 2019.01.23 (Wed) 13:12 (CET):
> not currently, but when i work with openbsd,
> i work at the text-console exclusively.
> i do use the web occasionally, via "lynx".
[...]
> i prefer to make annual donations to the
> openbsd foundation, typically 1st april.
> is there any method to automate that
> process?

If recurring transfers by a bank are an option:
http://www.openbsdfoundation.org/banktransfer.html
(Works with lynx :-)

Marcus

Re: Printing problem

[Stuart Henderson]

On 2019-01-23, Radek  wrote:
> Hello, 
>
> I can print from LibreOffice without any problems, but I canNOT print from 
> textproc/xpdf 
>
> If I print from textproc/xpdf (command: /usr/bin/lpr -P Kyocera_Mita_FS-6020) 
> I get error:
> lpr: connect: No such file or directory
> jobs queued, but cannot start daemon.

/usr/bin/lpr is lpr from the base OS. Since you are using CUPS you need
to use /usr/local/bin/lpr instead, you can either set this in xpdf (e.g.
/etc/xpdfrc), or you could adjust your PATH so that /usr/local/bin comes
before /usr/bin.
>

Re: chflags error message

[Paul de Weerd]

Hi Marcus,

[redirecting to misc@, this is not a bug and all is working as
intended]

By the time your recursive chflags gets to pkg_add, it will already
have the flag.  Note that these flags are per inode, and several files
under /usr/sbin have the same inode:

[weerd@despair] $ cd /usr/sbin; ls -li | grep 134232
134232 -r-xr-xr-x   7 root  bin 1473 Oct 27 03:48 fw_update
134232 -r-xr-xr-x   7 root  bin 1473 Oct 27 03:48 pkg_add
134232 -r-xr-xr-x   7 root  bin 1473 Oct 27 03:48 pkg_check
134232 -r-xr-xr-x   7 root  bin 1473 Oct 27 03:48 pkg_create
134232 -r-xr-xr-x   7 root  bin 1473 Oct 27 03:48 pkg_delete
134232 -r-xr-xr-x   7 root  bin 1473 Oct 27 03:48 pkg_info
134232 -r-xr-xr-x   7 root  bin 1473 Oct 27 03:48 pkg_sign

The recursive operation doesn't pay attention to this implementation
detail, so it first runs chflags against fw_update.  Then when it
finds pkg_add, it'll try to run chflags against it, but now it already
has the flag, so it gives you an error.

You will probably have seen multiple errors while running your
recursive chflags operation.  Same deal there.


Note that running chflags on files in your /usr/sbin directory will
be a problem come upgrade time.  You'll need to remove the flag before
you can upgrade.

Cheers,

Paul 'WEiRD' de Weerd

On Wed, Jan 23, 2019 at 12:46:43PM +, Marcus Pedersén wrote:
| Hi,
| 
| OpenBSD 6.4
| 
| I have a strange behavior on chflags.
| 
| If I run:
| 
| chflags schg /usr/sbin/pkg_add
| 
| This works fine and the schg flag is set.
| 
| 
| But if I run it recusively, as in:
| 
| chflags -R schg /usr/sbin/
| 
| I get the following error on pkg_add and a number of other files:
| 
| chflags: /usr/sbin/pkg_add: Operation is not permitted
| 
| 
| Still the schg flag is set.
| 
| 
| How come I get an error when running recurively but not when I run it on the 
same single file?
| 
| 
| I hope this will help you and if I have posted to the wrong address I 
apologize!!
| 
| Please, tell me where to post this if it is wrong!
| 
| 
| Best regards
| 
| Marcus Pedersén
| 
| ---
| När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
personuppgifter. För att läsa mer om hur detta går till, klicka här 

| E-mailing SLU will result in SLU processing your personal data. For more 
information on how this is done, click here 


-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

openbsd : foundation : donation : annual : automatic : any method?

[Mayuresh Kathe]

not currently, but when i work with openbsd,
i work at the text-console exclusively.
i do use the web occasionally, via "lynx".
i hate the 'pui' and hence graphical web
browsers.
i prefer to make annual donations to the
openbsd foundation, typically 1st april.
is there any method to automate that
process?
i do not have any liking towards having
to boot off a ubuntu live system and using
it's 'pui' web browser even once a year
to make a donation, though i have to do it
for the moment.

carm : benefits to a budding programmer?

[Mayuresh Kathe]

i stumbled upon the book "c: a reference manual, 5ed" by harbisson and 
steele.

may i know what benefits it might impart to a budding c programmer?

Re: Printing problem

[Radek]

Hello, 

I can print from LibreOffice without any problems, but I canNOT print from 
textproc/xpdf 

If I print from textproc/xpdf (command: /usr/bin/lpr -P Kyocera_Mita_FS-6020) I 
get error:
lpr: connect: No such file or directory
jobs queued, but cannot start daemon.

It worked for me in FreeBSD, but maybe I have missed something in my new 
desktop.

This is a network printer. 
$ lpstat -d -p
system default destination: Kyocera_Mita_FS-6020
printer Kyocera_Mita_FS-6020 is idle.  enabled since Wed Jan 23 08:55:43 2019

$ cat /etc/printcap 
Kyocera_Mita_FS-6020|:rm=desk.pk:rp=Kyocera_Mita_FS-6020:

$ cat .cups/lpoptions 
Default Kyocera_Mita_FS-6020

$ rcctl check cupsd
cupsd(ok)

OpenBSD 6.4 (GENERIC.MP) #0: Thu Jan 10 13:55:24 CET 2019
r...@desk.pk:/usr/src/sys/arch/amd64/compile/GENERIC.MP


Thanks for help. 


On Fri, 21 Feb 2014 07:47:28 -0800
Jeremy Evans  wrote:

> On Fri, Feb 21, 2014 at 3:54 AM, Jan Stary  wrote:
> 
> > On Feb 19 13:20:07, chrisbenn...@bennettconstruction.us wrote:
> > > I don't print from my laptop often, but all was fine until recently.
> > > I did not have any problems previously.
> > > I haven't made any changes either.
> > > I am using commands of
> > > lpr -Plp estimate_details_for_customer
> > > or
> > > lpr -Paps1 estimate_details_for_customer
> >
> > On Feb 19 12:32:36, jeremyeva...@gmail.com wrote:
> > > Known issue with that snapshot.  Already fixed in -current.
> >
> > Indeed. Out of curiosity, what was it? I couldn't find anything under
> > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/lpr/
> > that would break and fix this.
> >
> 
> Remote printing with lpd was broken from January 20 to February 7.
> 
> usr.sbin/lpr/lpd/printjob.c (broken by r1.50, fixed by r1.52)
> 
> Thanks,
> Jeremy
> 


-- 
radek

[patch] cwm group-delete

[Nam Nguyen]

This patch for cwm adds group-delete to delete all windows in a group. I
usually end up with many disposable windows in a group, so this makes it
easier to manage them.

The main function added is group_delete(struct screen_ctx *sc, int idx).

Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.362
diff -u -p -r1.362 calmwm.h
--- calmwm.h8 Nov 2018 15:49:42 -   1.362
+++ calmwm.h23 Jan 2019 08:09:36 -
@@ -451,6 +451,7 @@ int  group_holds_only_sticky(struct gr
 voidgroup_init(struct screen_ctx *, int);
 voidgroup_movetogroup(struct client_ctx *, int);
 voidgroup_only(struct screen_ctx *, int);
+voidgroup_delete(struct screen_ctx *, int);
 int group_restore(struct client_ctx *);
 voidgroup_show(struct group_ctx *);
 voidgroup_toggle_membership(struct client_ctx *);
@@ -508,6 +509,7 @@ void 
kbfunc_client_toggle_group(void 
 voidkbfunc_client_movetogroup(void *, struct cargs *);
 voidkbfunc_group_toggle(void *, struct cargs *);
 voidkbfunc_group_only(void *, struct cargs *);
+voidkbfunc_group_delete(void *, struct cargs *);
 voidkbfunc_group_cycle(void *, struct cargs *);
 voidkbfunc_group_alltoggle(void *, struct cargs *);
 voidkbfunc_menu_client(void *, struct cargs *);
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.242
diff -u -p -r1.242 conf.c
--- conf.c  13 Nov 2018 17:37:13 -  1.242
+++ conf.c  23 Jan 2019 08:09:36 -
@@ -143,6 +143,15 @@ static const struct {
{ FUNC_SC(group-only-7, group_only, 7) },
{ FUNC_SC(group-only-8, group_only, 8) },
{ FUNC_SC(group-only-9, group_only, 9) },
+   { FUNC_SC(group-delete-1, group_delete, 1) },
+   { FUNC_SC(group-delete-2, group_delete, 2) },
+   { FUNC_SC(group-delete-3, group_delete, 3) },
+   { FUNC_SC(group-delete-4, group_delete, 4) },
+   { FUNC_SC(group-delete-5, group_delete, 5) },
+   { FUNC_SC(group-delete-6, group_delete, 6) },
+   { FUNC_SC(group-delete-7, group_delete, 7) },
+   { FUNC_SC(group-delete-8, group_delete, 8) },
+   { FUNC_SC(group-delete-9, group_delete, 9) },
 
{ FUNC_SC(pointer-move-up, ptrmove, (CWM_UP)) },
{ FUNC_SC(pointer-move-down, ptrmove, (CWM_DOWN)) },
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.70
diff -u -p -r1.70 cwmrc.5
--- cwmrc.5 29 Dec 2017 20:03:46 -  1.70
+++ cwmrc.5 23 Jan 2019 08:09:37 -
@@ -288,6 +288,8 @@ menu.
 Toggle visibility of group n, where n is 1-9.
 .It group-only-[n]
 Show only group n, where n is 1-9, hiding other groups.
+.It group-delete-[n]
+Delete windows in group n, where n is 1-9.
 .It group-toggle-all
 Toggle visibility of all groups.
 .It window-group
Index: group.c
===
RCS file: /cvs/xenocara/app/cwm/group.c,v
retrieving revision 1.128
diff -u -p -r1.128 group.c
--- group.c 23 Jan 2018 13:48:49 -  1.128
+++ group.c 23 Jan 2019 08:09:37 -
@@ -250,6 +250,24 @@ group_only(struct screen_ctx *sc, int id
 }
 
 void
+group_delete(struct screen_ctx *sc, int idx)
+{
+   struct group_ctx*gc;
+   struct client_ctx   *cc;
+
+   if (idx < 0 || idx >= Conf.ngroups)
+   return;
+
+   TAILQ_FOREACH(gc, >groupq, entry) {
+   if (gc->num == idx) {
+   TAILQ_FOREACH(cc, >clientq, group_entry) {
+   XKillClient(X_Dpy, cc->win);
+   }
+   }
+   }
+}
+
+void
 group_cycle(struct screen_ctx *sc, int flags)
 {
struct group_ctx*newgc, *oldgc, *showgroup = NULL;
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.159
diff -u -p -r1.159 kbfunc.c
--- kbfunc.c29 Dec 2017 20:03:46 -  1.159
+++ kbfunc.c23 Jan 2019 08:09:37 -
@@ -440,6 +440,12 @@ kbfunc_group_only(void *ctx, struct carg
 }
 
 void
+kbfunc_group_delete(void *ctx, struct cargs *cargs)
+{
+   group_delete(ctx, cargs->flag);
+}
+
+void
 kbfunc_group_cycle(void *ctx, struct cargs *cargs)
 {
group_cycle(ctx, cargs->flag);