Re: Catastrophic machine freezes - X related

2020-03-08 Thread Justin Noor
You’re using tmux with or without X? We’re getting different errors. Thus
far my errors are definitely X related.

Coincidentally I was just working on this. My machine crashed, and my logs
are showing:

rwsleep_nsec: Xorg[98908]: fsleep: trying to sleep zero nanoseconds

I’m looking into it as we speak.

On Sun, Mar 8, 2020 at 4:09 PM Avon Robertson  wrote:

> On Sat, Feb 29, 2020 at 07:41:59AM -0800, Justin Noor wrote:
> > Awesome - thank you for your time and for the valuable information.
> >
> > That’s hilarious about the serial port. I’ll try plugging into a switch,
> > reproducing the crash, and SSHing into it. I still haven’t tried the
> > syslogd tip you mentioned either. It’s time for me to start learning more
> > about X. Will be in touch.
> >
> > Regards
> >
> > On Fri, Feb 28, 2020 at 6:57 AM Stuart Longland <
> stua...@longlandclan.id.au>
> > wrote:
> >
> > > On 28/2/20 11:32 pm, Justin Noor wrote:
> > > > Thanks for offering to help and sorry for the delay - I got dragged
> into
> > > a
> > > > work emergency. I finally managed to SCP my dmesg to a remote
> machine.
> > >
> > > Heh, no problems, these things happen.
> > >
> > > > As a refresher I have a 6.6 current machine that crashes when X is
> > > running,
> > > > and almost instantly when Firefox is running - it runs fine without
> X.
> > > The
> > > > machine becomes totally frozen - I have to perform a forced shutdown
> to
> > > > exit this state. The issue appears to be graphics related and is
> > > > inconsistent - sometimes it crashes immediately, other times it does
> not.
> > >
> > > Sometimes it might be the way a particular graphics toolkit "tickles"
> > > the video hardware too.  For instance FVWM uses libxcb for drawing
> > > graphics which means you're likely to be just working with 2D
> primitives.
> > >
> > > Then Firefox with its GTK+ back-end fires off a few RENDER extension
> > > requests to the X server and whoopsie!  Down she goes!
> > >
> > > > There are indeed some "unknown product" messages related to my PCI
> > > graphics
> > > > card in my dmesg, but I haven't been able to decipher them yet. Those
> > > > usually mean the device is not supported, but it is, and I'm sure I
> have
> > > > the correct driver (amdgpu0). Previously I had no issues for months,
> > > which
> > > > is why I suspected hardware failure. Admittedly I've been lucky with
> > > > graphics cards over the years, and don't know much about PCI.
> > >
> > > No issues for months running a previous version of OpenBSD or the same
> > > you're running now?
> > >
> > > One suggestion I made too was to maybe try setting up a serial console
> > > link… turns out the motherboard makers know how to tease:
> > >
> > > > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> > > > com0: probed fifo depth: 0 bytes
> > >
> > > That says there is a RS-232 port somewhere… so I had a look at the
> > > handbook:
> > >
> > >
> https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM4/ROG_STRIX_B450-I_GAMING/E14337_ROG_STRIX_B450-I_GAMING_UM_PRINT.pdf
> > >
> > > They didn't wire it up to a pin header, which is annoying.
> > >
> > > On the video front, I did see this:
> > > > initializing kernel modesetting (POLARIS11 0x1002:0x67EF
> 0x1002:0x0B04
> > > > 0xE5).
> > > > amdgpu_irq_add_domain: stub
> > > > amdgpu_device_resize_fb_bar: stub
> > > > amdgpu: [powerplay] Failed to retrieve minimum clocks.
> > > > amdgpu0: 1360x768, 32bpp
> > > > wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using
> wskbd0
> > > > wskbd1: connecting to wsdisplay0
> > > > wsdisplay0: screen 1-5 added (std, vt100 emulation)
> > >
> > > The "stub" messages make me wonder if we're hitting some
> > > not-yet-implemented features.  That "failed to retrieve minimum clocks"
> > > has been seen on Linux as well, and there it was related to PCI
> prefetch
> > > register programming.
> > >
> > > The machine you've got isn't much different to what I have at work
> > > actually: Rysen 7 1700 (so previous generation), and a RX550 video card
> > > (POLARIS12, maybe slightly newer?)… the machine is fitted with a RS-232
> > > serial port so I might try a little experiment with a USB stick and see
> > > if I can install OpenBSD 6.6 to USB storage and try to reproduce the
> crash.
> > > --
> > > Stuart Longland (aka Redhatter, VK4MSL)
> > >
> > > I haven't lost my mind...
> > >   ...it's backed up on a tape somewhere.
> > >
>
> Hello Justin and Stuart,
>
> It is possible that the errors that I have found in /var/log/messages*
> are unrelated to the above. Thoughts?
>
> I have noticed that the freezes on this machine occur more quickly if I
> am working within tmux(1), as I was; at the time that the last freeze
> occurred. That may have been sheer coincidence.
>
> $ grep ERROR /var/log/messag*
> /var/log/messages:Mar  8 16:20:10 gx470 /bsd: [drm] *ERROR* ring gfx
> timeout, signaled seq=385, emitted seq=387
> /var/log/messages:Mar  9 07:06:34 gx470 /bsd: [drm] *ERROR* Illegal
> register access in 

Re: [drm] *ERROR* [CRTC:41:pipe ] flip_done timed out

2020-03-08 Thread Jon Whalen
Hi Jonathan,

Thank you very much for the quick response.

I applied the changes (manually), and they fix all of the hangs
mentioned as well as the two original errors; however, a new error
that I haven't seen before now shows in dmesg:

[drm] *ERROR* CPU pipe B FIFO underrun

This is only after ~45 min uptime so I'll continue to monitor it,
although it doesn't seem to have hurt anything thus far. No errors
appear in xconsole, for what it's worth, whereas the original errors
would appear fairly often.

Jon

On Sun, Mar 8, 2020 at 9:56 AM Jonathan Gray  wrote:
>
> On Sat, Mar 07, 2020 at 08:50:44PM -0400, Jon Whalen wrote:
> > Hi there,
> >
> > I also receive these errors as well as hangs on an old Dell Inspiron
> > 1525 with OpenBSD, several releases of Ubuntu Linux, and NetBSD 9.0.
> > My unqualified assumption is that it's an Intel i915 driver issue and
> > not an actual OpenBSD issue. I don't know anything about computer
> > programming, but given the errors, I wonder if it could be narrowed
> > down to the drm_irq.c, drm_vblank.c, and/or intel_fifo_underrun.c
> > files in the Intel driver? There are differences between the current
> > Linux and OpenBSD source trees, but I lack the skills, expertise, and
> > brain power to begin troubleshooting this. The main differences appear
> > to have something to do with spinlocks and mutexes, but again, this is
> > beyond my abilities.
> >
> > OpenBSD became affected after 6.6 development began (6.5 is not
> > affected). Probably irrelevant, but not all Linux distributions are
> > affected; Kubuntu and Alpine are not, and neither is the latest Ubuntu
> > 20.04 development release.
> >
> > NetBSD 9.0 repeated the following errors upon boot and is what led me
> > to my assumption above:
> > [4.6926206] warning:
> > /usr/src/sys/external/bsd/drm2/dist/drm/drm_irq.c:1510 vblank wait
> > timed out on crtc 0
> > [4.7526574] kern error:
> > [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:363)intel_cpu_fifo_underrun_irq_handler]
> > *ERROR* CPU pipe A FIFO underrun
> >
> > Booting OpenBSD with inteldrm enabled, there is a delay of
> > approximately 30 seconds when inteldrm is "probed" after root is
> > mounted, which is also when the [drm] errors begin to appear. The boot
> > process continues normally after the hang.
> >
> > If xenodm is configured to start it takes about 60 seconds for it to
> > load and become usable.
> >
> > After entering credentials into xenodm, cwm takes approximately 30
> > seconds to become usable and xconsole starts repeating the same [drm]
> > errors. Things seem to work fine after this, though the errors
> > continue to litter /var/log/messages.
> >
> > Resuming from a suspend, the system hangs for ~30s.
> >
> > None of this occurs if inteldrm is disabled.
> >
> > On Linux, adding the following line to the grub conf eliminated the
> > errors and hangs:
> >
> > GRUB_CMDLINE_LINUX_DEFAULT="video=SVIDEO-1:d"
> >
> > Is it possible to pass similar Linux grub parameters to boot on
> > OpenBSD via boot.conf? If there is a way, could this be the "easiest"
> > solution?
> >
> > Sendbug text below, with -current as of March 7, 2020.
> >
> > This message refers to:
> > https://marc.info/?t=15807519011=1=2
>
> https://bugs.freedesktop.org/show_bug.cgi?id=93782
>
> This appears to have been fixed in linux 5.1 in commit
> 32db0b6501d97b09e92e70caefc74fa35aa9a8d6 which was marked as being for
> stable but did not appear in the stable branches likely due it it not
> applying cleanly (ed20151a7699bb2c77eba3610199789a126940c4 did land in
> the 4.19 branch so we already have that).
>
> Here is a backport of 32db0b6501d97b09e92e70caefc74fa35aa9a8d6 to our
> 4.19 tree.
>
> drm/i915: Don't try to use the hardware frame counter with i965gm TV output
>
> Index: sys/dev/pci/drm/i915/i915_irq.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_irq.c,v
> retrieving revision 1.33
> diff -u -p -r1.33 i915_irq.c
> --- sys/dev/pci/drm/i915/i915_irq.c 14 Apr 2019 10:14:51 -  1.33
> +++ sys/dev/pci/drm/i915/i915_irq.c 8 Mar 2020 12:46:04 -
> @@ -822,11 +822,26 @@ static void i915_enable_asle_pipestat(st
>  static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
>  {
> struct drm_i915_private *dev_priv = to_i915(dev);
> +   struct drm_vblank_crtc *vblank = >vblank[pipe];
> +   const struct drm_display_mode *mode = >hwmode;
> i915_reg_t high_frame, low_frame;
> u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
> -   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
> unsigned long irqflags;
>
> +   /*
> +* On i965gm TV output the frame counter only works up to
> +* the point when we enable the TV encoder. After that the
> +* frame counter ceases to work and reads zero. We need a
> +* vblank wait before enabling the TV encoder and so we
> + 

Re: Catastrophic

2020-03-08 Thread Avon Robertson
On Sat, Feb 29, 2020 at 07:41:59AM -0800, Justin Noor wrote:
> Awesome - thank you for your time and for the valuable information.
> 
> That’s hilarious about the serial port. I’ll try plugging into a switch,
> reproducing the crash, and SSHing into it. I still haven’t tried the
> syslogd tip you mentioned either. It’s time for me to start learning more
> about X. Will be in touch.
> 
> Regards
> 
> On Fri, Feb 28, 2020 at 6:57 AM Stuart Longland 
> wrote:
> 
> > On 28/2/20 11:32 pm, Justin Noor wrote:
> > > Thanks for offering to help and sorry for the delay - I got dragged into
> > a
> > > work emergency. I finally managed to SCP my dmesg to a remote machine.
> >
> > Heh, no problems, these things happen.
> >
> > > As a refresher I have a 6.6 current machine that crashes when X is
> > running,
> > > and almost instantly when Firefox is running - it runs fine without X.
> > The
> > > machine becomes totally frozen - I have to perform a forced shutdown to
> > > exit this state. The issue appears to be graphics related and is
> > > inconsistent - sometimes it crashes immediately, other times it does not.
> >
> > Sometimes it might be the way a particular graphics toolkit "tickles"
> > the video hardware too.  For instance FVWM uses libxcb for drawing
> > graphics which means you're likely to be just working with 2D primitives.
> >
> > Then Firefox with its GTK+ back-end fires off a few RENDER extension
> > requests to the X server and whoopsie!  Down she goes!
> >
> > > There are indeed some "unknown product" messages related to my PCI
> > graphics
> > > card in my dmesg, but I haven't been able to decipher them yet. Those
> > > usually mean the device is not supported, but it is, and I'm sure I have
> > > the correct driver (amdgpu0). Previously I had no issues for months,
> > which
> > > is why I suspected hardware failure. Admittedly I've been lucky with
> > > graphics cards over the years, and don't know much about PCI.
> >
> > No issues for months running a previous version of OpenBSD or the same
> > you're running now?
> >
> > One suggestion I made too was to maybe try setting up a serial console
> > link… turns out the motherboard makers know how to tease:
> >
> > > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> > > com0: probed fifo depth: 0 bytes
> >
> > That says there is a RS-232 port somewhere… so I had a look at the
> > handbook:
> >
> > https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM4/ROG_STRIX_B450-I_GAMING/E14337_ROG_STRIX_B450-I_GAMING_UM_PRINT.pdf
> >
> > They didn't wire it up to a pin header, which is annoying.
> >
> > On the video front, I did see this:
> > > initializing kernel modesetting (POLARIS11 0x1002:0x67EF 0x1002:0x0B04
> > > 0xE5).
> > > amdgpu_irq_add_domain: stub
> > > amdgpu_device_resize_fb_bar: stub
> > > amdgpu: [powerplay] Failed to retrieve minimum clocks.
> > > amdgpu0: 1360x768, 32bpp
> > > wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0
> > > wskbd1: connecting to wsdisplay0
> > > wsdisplay0: screen 1-5 added (std, vt100 emulation)
> >
> > The "stub" messages make me wonder if we're hitting some
> > not-yet-implemented features.  That "failed to retrieve minimum clocks"
> > has been seen on Linux as well, and there it was related to PCI prefetch
> > register programming.
> >
> > The machine you've got isn't much different to what I have at work
> > actually: Rysen 7 1700 (so previous generation), and a RX550 video card
> > (POLARIS12, maybe slightly newer?)… the machine is fitted with a RS-232
> > serial port so I might try a little experiment with a USB stick and see
> > if I can install OpenBSD 6.6 to USB storage and try to reproduce the crash.
> > --
> > Stuart Longland (aka Redhatter, VK4MSL)
> >
> > I haven't lost my mind...
> >   ...it's backed up on a tape somewhere.
> >

Hello Justin and Stuart,

It is possible that the errors that I have found in /var/log/messages*
are unrelated to the above. Thoughts?

I have noticed that the freezes on this machine occur more quickly if I
am working within tmux(1), as I was; at the time that the last freeze
occurred. That may have been sheer coincidence.

$ grep ERROR /var/log/messag*
/var/log/messages:Mar  8 16:20:10 gx470 /bsd: [drm] *ERROR* ring gfx timeout, 
signaled seq=385, emitted seq=387
/var/log/messages:Mar  9 07:06:34 gx470 /bsd: [drm] *ERROR* Illegal register 
access in command stream
/var/log/messages:Mar  9 07:06:44 gx470 /bsd: [drm] *ERROR* ring gfx timeout, 
signaled seq=794, emitted seq=796

My machine's last freeze occurred at the time of the last error in
/var/log/messages. I am able to remotely login to this machine and
access files when it is frozen, using kermit(1) and a USB to Serial
adapter. The machine's /var/run/dmesg.boot can be found in my first
email to this thread.

Regards Avon

-- 
aer



Re: Hardening browser

2020-03-08 Thread Tomasz Rola
On Sat, Mar 07, 2020 at 11:55:59AM -0700, Luke A. Call wrote:
> On 03-07 19:19, whistlez...@riseup.net wrote:
[...]
> > As I know many sites without js doesn't work. Anyway I don't understand
> > how switching off js defend you from 0day browser bug.
> > Maybe you mean that because many 0day concern javascript ?
> 
> Yes, as well as the general category of speculative execution CPU
> attacks, rowhammer-type attacks, evercookies that use javascript, 
> and/or whatever else I don't know about that is enabled by javascript.
> It just seems to be required for many attacks that one reads about, over
> time, and given that trend, probably some future ones, all from
> downloading unknown code to run locally.  For those fewer times when I do
> enable it, I'm glad for OBSD's various protections, to further lower
> risk.


I think switching js off is one (very important) thing. But, there is
more of it. Which is why I try to not load page-provided fonts and css
at all. In css (or in certain browser-specific variation), one can
embed js code, and same with svg file. I wonder if switching js off in
browser would then result in not executing embedded js as well?

Another fun read: Krebbs describes how browser extension has been sold
by original author and then used by new owner to detect if user works
on Wordpress or Joomla. If so, the "Page Ruler" injected small js
snippet into edited webpage.

   
https://krebsonsecurity.com/2020/03/the-case-for-limiting-your-browser-extensions/

I guess extensions work even with js switched off...

Etc etc

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **



Re: Hardening browser

2020-03-08 Thread Tomasz Rola
On Thu, Mar 05, 2020 at 12:25:56PM +0100, zeurk...@volny.cz wrote:
> Me's been following this discussion w/ some interest.
> 
> Personally, meuses lynx(1) (w/o the ports patches, as they interfere w/
> text field editing among other things), in image_links mode w/ feh(1).
> Works like a charm :)

I use lynx a lot, very nice tool. It also helped me to restart my
browsing of gopher sites. There was plenty of them 20+ years ago, now
it is just a handful of servers. But still, better than nothing.

[...]
> Occasionally, when really pressed, meruns 'tails', a specialized Lunix
> distro, from a DVD on a spare craptop; at least that way, mecan get rid
> of the bloated, buggy shit by simply turning off the machine.

I do not know tails, only read about it.

Using separate computers for different roles might be a way of the
future. A very convoluted way. But one cannot count too much on
security offered by modern popular cpus and there is always a chance
to be struck by something unexpected: I have just read that bmp file
from game server might make buffer overflow on client side. So, one
machine for gaming, one for reading, one for shopping and one for
work. And one for listing the music.

I will never propose this kind of solution to normal people. :-)

[...]
>  --zeurkous.
> 
> -- 
> Friggin' Machines!

Oh no, it is not the machines. It is their masters.

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **



Extending rtwn(4) to RTL8723BE

2020-03-08 Thread Hannu Vuolasaho
Hi!

I am in the begin of extending rtwn(4) to RTL8723BE. How hard it would
be if there is only one letter changed in chip name if AE is already
supported. :)

My progress so far has been detecting the chip, reading the rom table
and loading the firmware. Any use of the interface causes log message
of RF not powered, which is understandable and I will dig into it
after the rom part works.

I have few questions

Does the rtwn firmware package ship already RTL8723BE firmware? I have
rtwn-rtl8723befw_36 directory in /etc/firmware. Just asking to make
sure I load right firmware as there are no easily findable changelogs
for firmware packages.

As there was some preliminary work done to RTL8723BE, has someone
gathered info already? Or is the boot linux compile more debugging to
driver and figure out what is happening the only slow way?

Best regards,
Hannu Vuolasaho



Re: [drm] *ERROR* [CRTC:41:pipe ] flip_done timed out

2020-03-08 Thread Jonathan Gray
On Sat, Mar 07, 2020 at 08:50:44PM -0400, Jon Whalen wrote:
> Hi there,
> 
> I also receive these errors as well as hangs on an old Dell Inspiron
> 1525 with OpenBSD, several releases of Ubuntu Linux, and NetBSD 9.0.
> My unqualified assumption is that it's an Intel i915 driver issue and
> not an actual OpenBSD issue. I don't know anything about computer
> programming, but given the errors, I wonder if it could be narrowed
> down to the drm_irq.c, drm_vblank.c, and/or intel_fifo_underrun.c
> files in the Intel driver? There are differences between the current
> Linux and OpenBSD source trees, but I lack the skills, expertise, and
> brain power to begin troubleshooting this. The main differences appear
> to have something to do with spinlocks and mutexes, but again, this is
> beyond my abilities.
> 
> OpenBSD became affected after 6.6 development began (6.5 is not
> affected). Probably irrelevant, but not all Linux distributions are
> affected; Kubuntu and Alpine are not, and neither is the latest Ubuntu
> 20.04 development release.
> 
> NetBSD 9.0 repeated the following errors upon boot and is what led me
> to my assumption above:
> [4.6926206] warning:
> /usr/src/sys/external/bsd/drm2/dist/drm/drm_irq.c:1510 vblank wait
> timed out on crtc 0
> [4.7526574] kern error:
> [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:363)intel_cpu_fifo_underrun_irq_handler]
> *ERROR* CPU pipe A FIFO underrun
> 
> Booting OpenBSD with inteldrm enabled, there is a delay of
> approximately 30 seconds when inteldrm is "probed" after root is
> mounted, which is also when the [drm] errors begin to appear. The boot
> process continues normally after the hang.
> 
> If xenodm is configured to start it takes about 60 seconds for it to
> load and become usable.
> 
> After entering credentials into xenodm, cwm takes approximately 30
> seconds to become usable and xconsole starts repeating the same [drm]
> errors. Things seem to work fine after this, though the errors
> continue to litter /var/log/messages.
> 
> Resuming from a suspend, the system hangs for ~30s.
> 
> None of this occurs if inteldrm is disabled.
> 
> On Linux, adding the following line to the grub conf eliminated the
> errors and hangs:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="video=SVIDEO-1:d"
> 
> Is it possible to pass similar Linux grub parameters to boot on
> OpenBSD via boot.conf? If there is a way, could this be the "easiest"
> solution?
> 
> Sendbug text below, with -current as of March 7, 2020.
> 
> This message refers to:
> https://marc.info/?t=15807519011=1=2

https://bugs.freedesktop.org/show_bug.cgi?id=93782

This appears to have been fixed in linux 5.1 in commit
32db0b6501d97b09e92e70caefc74fa35aa9a8d6 which was marked as being for
stable but did not appear in the stable branches likely due it it not
applying cleanly (ed20151a7699bb2c77eba3610199789a126940c4 did land in
the 4.19 branch so we already have that).

Here is a backport of 32db0b6501d97b09e92e70caefc74fa35aa9a8d6 to our
4.19 tree.

drm/i915: Don't try to use the hardware frame counter with i965gm TV output

Index: sys/dev/pci/drm/i915/i915_irq.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_irq.c,v
retrieving revision 1.33
diff -u -p -r1.33 i915_irq.c
--- sys/dev/pci/drm/i915/i915_irq.c 14 Apr 2019 10:14:51 -  1.33
+++ sys/dev/pci/drm/i915/i915_irq.c 8 Mar 2020 12:46:04 -
@@ -822,11 +822,26 @@ static void i915_enable_asle_pipestat(st
 static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   const struct drm_display_mode *mode = >hwmode;
i915_reg_t high_frame, low_frame;
u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
-   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
unsigned long irqflags;
 
+   /*
+* On i965gm TV output the frame counter only works up to
+* the point when we enable the TV encoder. After that the
+* frame counter ceases to work and reads zero. We need a
+* vblank wait before enabling the TV encoder and so we
+* have to enable vblank interrupts while the frame counter
+* is still in a working state. However the core vblank code
+* does not like us returning non-zero frame counter values
+* when we've told it that we don't have a working frame
+* counter. Thus we must stop non-zero values leaking out.
+*/
+   if (!vblank->max_vblank_count)
+   return 0;
+
htotal = mode->crtc_htotal;
hsync_start = mode->crtc_hsync_start;
vbl_start = mode->crtc_vblank_start;
@@ -4803,16 +4818,10 @@ void intel_irq_init(struct drm_i915_priv
if (INTEL_GEN(dev_priv) >= 8)
rps->pm_intrmsk_mbz |= GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
 
-   if 

Re: Compiling Zeek 3.0.2 returns an error at final stage (partially solved)

2020-03-08 Thread Carlos Lopez
Ok, all works well when I configure Zeek as a standalone node: packets are 
captured, there are several logs regarding conn, dns ... Problem appears when 
Zeek is configured as a cluster using one host as a manager and another host as 
a worker  ...

Strange, because PF is disabled in both hosts, one host can connect to the 
other (ping, ssh and so on). Maybe it is a bug with Zeek ...

-- 
Regards,
C. L. Martinez

On 08/03/2020, 10:42, "owner-m...@openbsd.org on behalf of Carlos Lopez" 
 wrote:

Hi Monah,

Yes, zeekctl deploy works without problem. If I launch several requests 
using curl or doing several dns requests, I can see all of them with tcpdump 
but not in zeek … Of course, sniffing the same interface …

--
Regards,
C. L. Martinez

From: Monah Baki 
Date: Sunday, 8 March 2020 at 00:25
To: Carlos Lopez 
Cc: "misc@openbsd.org" 
Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage

From the server if you curl a website, in zeek log current folder do you 
see a http.log file, and after changing the interface did you zeekctl deploy.

Thanks
Monah



On Sat, Mar 7, 2020 at 5:42 PM Carlos Lopez 
mailto:clo...@outlook.com>> wrote:
Thanks Monah … But this is not the problem … interface configuration is 
correct …

--
Regards,
C. L. Martinez

From: Monah Baki mailto:monahb...@gmail.com>>
Date: Saturday, 7 March 2020 at 23:30
To: Carlos Lopez mailto:clo...@outlook.com>>
Cc: "misc@openbsd.org" 
mailto:misc@openbsd.org>>
Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage

Hi Carlos,

Check your node.cfg, the interface section

[zeek]
type=standalone
host=localhost
interface=eth0   << might want to change it

On Sat, Mar 7, 2020 at 5:01 PM Carlos Lopez 
mailto:clo...@outlook.com>> wrote:
Many thanks for your answer Stuart ... Finally, I have compiled Zeek 
3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture any 
packet ... and tcpdump works without problems and I can see all traffic ...

--
Regards,
C. L. Martinez

On 07/03/2020, 22:08, 
"owner-m...@openbsd.org on behalf of Stuart 
Henderson" mailto:owner-m...@openbsd.org> on behalf of 
s...@spacehopper.org> wrote:

On 2020-03-07, Carlos Lopez 
mailto:clo...@outlook.com>> wrote:
> Hi all,
>
>  I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully 
patched but compilation returns me the following error:
>
> [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o
> [ 97%] Linking CXX executable zeek
> ld: error: unable to find library -llibbinpac.so.VERSION
> c++: error: linker command failed with exit code 1 (use -v to see 
invocation)
> *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 
'src/zeek')
> *** Error 1 in build (CMakeFiles/Makefile2:1661 
'src/CMakeFiles/zeek.dir/all')
> *** Error 1 in build (Makefile:152 'all')
> *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all')
>
>  But libbinpac.so exists compiled under the source dirs.:
>
> root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so"
> ./build/aux/binpac/lib/libbinpac.so
> root@obsd66:~/builds/src/zeek-3.0.2
>
>  Any tip to solve this issue?
>

You're probably better off using the port. There is a fair chance that
if you update *just* the net/bro directory (the port dir wasn't renamed
but the package was) to -current that it will build, and if not, you'll
be closer to getting it working.

Or the easy option, update to -current, pkg_add zeek.





Re: [drm] *ERROR* [CRTC:41:pipe ] flip_done timed out

2020-03-08 Thread Jon Whalen
Hi there,

I also receive these errors as well as hangs on an old Dell Inspiron
1525 with OpenBSD, several releases of Ubuntu Linux, and NetBSD 9.0.
My unqualified assumption is that it's an Intel i915 driver issue and
not an actual OpenBSD issue. I don't know anything about computer
programming, but given the errors, I wonder if it could be narrowed
down to the drm_irq.c, drm_vblank.c, and/or intel_fifo_underrun.c
files in the Intel driver? There are differences between the current
Linux and OpenBSD source trees, but I lack the skills, expertise, and
brain power to begin troubleshooting this. The main differences appear
to have something to do with spinlocks and mutexes, but again, this is
beyond my abilities.

OpenBSD became affected after 6.6 development began (6.5 is not
affected). Probably irrelevant, but not all Linux distributions are
affected; Kubuntu and Alpine are not, and neither is the latest Ubuntu
20.04 development release.

NetBSD 9.0 repeated the following errors upon boot and is what led me
to my assumption above:
[4.6926206] warning:
/usr/src/sys/external/bsd/drm2/dist/drm/drm_irq.c:1510 vblank wait
timed out on crtc 0
[4.7526574] kern error:
[drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:363)intel_cpu_fifo_underrun_irq_handler]
*ERROR* CPU pipe A FIFO underrun

Booting OpenBSD with inteldrm enabled, there is a delay of
approximately 30 seconds when inteldrm is "probed" after root is
mounted, which is also when the [drm] errors begin to appear. The boot
process continues normally after the hang.

If xenodm is configured to start it takes about 60 seconds for it to
load and become usable.

After entering credentials into xenodm, cwm takes approximately 30
seconds to become usable and xconsole starts repeating the same [drm]
errors. Things seem to work fine after this, though the errors
continue to litter /var/log/messages.

Resuming from a suspend, the system hangs for ~30s.

None of this occurs if inteldrm is disabled.

On Linux, adding the following line to the grub conf eliminated the
errors and hangs:

GRUB_CMDLINE_LINUX_DEFAULT="video=SVIDEO-1:d"

Is it possible to pass similar Linux grub parameters to boot on
OpenBSD via boot.conf? If there is a way, could this be the "easiest"
solution?

Sendbug text below, with -current as of March 7, 2020.

This message refers to:
https://marc.info/?t=15807519011=1=2

System  : OpenBSD 6.6
Details : OpenBSD 6.6-current (GENERIC.MP) #36: Fri Mar  6
16:56:31 MST 2020
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

dmesg:
OpenBSD 6.6-current (GENERIC.MP) #36: Fri Mar  6 16:56:31 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4268150784 (4070MB)
avail mem = 4126191616 (3935MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf7190 (45 entries)
bios0: vendor Dell Inc. version "A17" date 10/27/2009
bios0: Dell Inc. Inspiron 1525
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG SLIC OSFR BOOT SSDT
acpi0: wakeup devices PCI0(S5) PCIE(S4) USB1(S0) USB2(S0) USB3(S0)
USB4(S0) USB5(S0) EHC2(S0) EHCI(S0) AZAL(S3) RP01(S5) RP02(S3)
RP03(S3) RP04(S3) RP05(S3) RP06(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz, 1995.31 MHz, 06-0f-0d
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 2MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz, 1995.02 MHz, 06-0f-0d
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 2MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpimcfg0: addr 0x0, bus 0-0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PCIE)
acpiprt2 at acpi0: bus 9 (RP01)
acpiprt3 at acpi0: bus 11 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus 12 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), 

Re: Compiling Zeek 3.0.2 returns an error at final stage

2020-03-08 Thread Carlos Lopez
Hi Monah,

Yes, zeekctl deploy works without problem. If I launch several requests using 
curl or doing several dns requests, I can see all of them with tcpdump but not 
in zeek … Of course, sniffing the same interface …

--
Regards,
C. L. Martinez

From: Monah Baki 
Date: Sunday, 8 March 2020 at 00:25
To: Carlos Lopez 
Cc: "misc@openbsd.org" 
Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage

>From the server if you curl a website, in zeek log current folder do you see a 
>http.log file, and after changing the interface did you zeekctl deploy.

Thanks
Monah



On Sat, Mar 7, 2020 at 5:42 PM Carlos Lopez 
mailto:clo...@outlook.com>> wrote:
Thanks Monah … But this is not the problem … interface configuration is correct 
…

--
Regards,
C. L. Martinez

From: Monah Baki mailto:monahb...@gmail.com>>
Date: Saturday, 7 March 2020 at 23:30
To: Carlos Lopez mailto:clo...@outlook.com>>
Cc: "misc@openbsd.org" 
mailto:misc@openbsd.org>>
Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage

Hi Carlos,

Check your node.cfg, the interface section

[zeek]
type=standalone
host=localhost
interface=eth0   << might want to change it

On Sat, Mar 7, 2020 at 5:01 PM Carlos Lopez 
mailto:clo...@outlook.com>> wrote:
Many thanks for your answer Stuart ... Finally, I have compiled Zeek 
3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture any 
packet ... and tcpdump works without problems and I can see all traffic ...

--
Regards,
C. L. Martinez

On 07/03/2020, 22:08, "owner-m...@openbsd.org on 
behalf of Stuart Henderson" 
mailto:owner-m...@openbsd.org> on behalf of 
s...@spacehopper.org> wrote:

On 2020-03-07, Carlos Lopez mailto:clo...@outlook.com>> 
wrote:
> Hi all,
>
>  I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched 
but compilation returns me the following error:
>
> [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o
> [ 97%] Linking CXX executable zeek
> ld: error: unable to find library -llibbinpac.so.VERSION
> c++: error: linker command failed with exit code 1 (use -v to see 
invocation)
> *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek')
> *** Error 1 in build (CMakeFiles/Makefile2:1661 
'src/CMakeFiles/zeek.dir/all')
> *** Error 1 in build (Makefile:152 'all')
> *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all')
>
>  But libbinpac.so exists compiled under the source dirs.:
>
> root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so"
> ./build/aux/binpac/lib/libbinpac.so
> root@obsd66:~/builds/src/zeek-3.0.2
>
>  Any tip to solve this issue?
>

You're probably better off using the port. There is a fair chance that
if you update *just* the net/bro directory (the port dir wasn't renamed
but the package was) to -current that it will build, and if not, you'll
be closer to getting it working.

Or the easy option, update to -current, pkg_add zeek.