Re: Etnernal & infernal browser woes

[Martin Pieuchot]

On 28/04/17(Fri) 12:18, Jyri Hovila [iki.fi] wrote:
> [...] 
> Now, can anyone provide a relatively clear description of what it is
> that make the same browsers (Firefox, Seamonkey, Chrome) that work
> fine in Linux, Windows and OS X so ridiculously slow when they are
> being run on OpenBSD?

If you can answer this question you've already done 50% of the work.

Re: Etnernal & infernal browser woes

[Martin Pieuchot]

On 28/04/17(Fri) 14:03, Jyri Hovila [iki.fi] wrote:
> > If you can answer this question you've already done 50% of the work.
> 
> Exactly. Which is why I'm asking -- not expecting anyone to give a full
> answer. I want to know what people who have been working on this issue
> have already found out. I assume there is at least some basic
> understanding of why browsers are so incredibly sluggish on OpenBSD. Or
> is the clearest picture we have this far simply "because the browsers
> have been coded wrong"?

I know that our libpthread has some suboptimal code which I'm trying to
improved.  The futex(2) syscall I just committed is the first piece.

I also know that the Xorg/Input/Browser communication could be improved.

Re: Etnernal & infernal browser woes

[Martin Pieuchot]

On 28/04/17(Fri) 16:20, Anders Andersson wrote:
> [...] 
> From what I read, it seems as if the problems are mostly from when you
> try websites which are heavy on javascript. 

If javascript was the problem others OSes would suffer as well.

> Let me butt in as a grumpy
> not-so-old man and point out that there's nothing even remotely
> "secure by default" by even allowing javascript, considering its
> horrible track record.

So better run javascript on your phone or any other OS, right?

> Perhaps this is one of the reasons for the disinterest with browser 
> performance?

No.  The reason is always the same: somebody has to do the work.  It's
not easy, it takes time and we all have other things to do.

Re: RTL8153 stopped-communicating("crashed")-bug. I think because it was USB3 & OBSD doesn't support 5gbit/superspeed mode yet.

[Martin Pieuchot]

On 02/06/17(Fri) 12:38, Tinker wrote:
> Hi misc@,
> 
> My Xeon Asrock machine with an RTL8153 on an USB2 plug (to first network)
> and an RTL8153 on an USB3 plug (to second network), just had this USB
> failure on the second RTL8153:
> 
>  cdce1: usb error on tx: IOERROR
>  cdce1: watchdog timeout
>  cdce1: usb error on tx: TIMEOUT

Your bug report is missing a dmesg where this failure happens.

> I learned today that OpenBSD does not implement USB3 fully, specifically it
> doesn't implement the 5gbps SuperSpeed mode, but only 1gbps.

This is irrelevant to the error above.

> I picture that this could have been because that interface for a split
> second consumed the whole 1gbps frame and then attempting to push just a
> little bit more, and there was some data loss that ended up confusing the
> cdce driver so it (for practical purposes) crashed.

It could be anything.  If you're sure it's an xhci(4) problem, because
you tried the device on ehci(4) and it works, did you try enabling
XHCI_DEBUG?

> Too bad it doesn't recover and get online again by itself.

You can fix the watchdog functions, look at how other drivers do it.

> This is on a patched 6.0, someday I should try getting ureN devices on 6.1.

This won't fix bugs.

> Meanwhile I guess that this crash situation should be remedied simply by
> using the NIC:s' USB2 ports only instead.

So it's an xhci(4) problem?  Could you submit a bug report with a dmesg
of a kernel compiled with XHCI_DEBUG and exposing the problems above
motioned?

Re: re0 and re1 watchdog timeouts, and system freeze

[Martin Pieuchot]

On 07/06/17(Wed) 09:43, Björn Ketelaars wrote:
> On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
> > 
> > Reverting back to the previous kernel fixed the issue above. Question: can
> > someone give a hint on how to track this issue?
> 
> After a bit of experimenting I'm able to reproduce the problem. Summary is
> that queueing in pf and use of a current (after May 30), multi processor
> kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
> followed by a system freeze.
> 
> Issue is 'gone' when:
> 1.) using an older kernel (before May 30);
> 2.) removal of queueing statements from pf.conf. Included below the specific
> snippet;
> 3.) switch from MP kernel to SP kernel.
> 
> New observation is that while queueing, using a MP kernel, the download
> bandwidth is only a fraction of what is expected. Exchanging the MP kernel
> with a SP kernel restores the download bandwidth to expected level.
> 
> I'm guessing that this issue is related to recent work on PF?

It's certainly a problem in, or exposed by, re(4) with the recent MP work
in the network stack.

It would help if you could build a kernel with MP_LOCKDEBUG defined and
see if the resulting kernel enters ddb(4) instead of freezing.

Thanks,
Martin

> 
> 
> --- SNIP ---
> 
> # queueing
> #
> queue up on re0 bandwidth 15M max 15M
> queue up_def parent up bandwidth 1M qlimit 10 default
> queue up_dns parent up bandwidth 2M qlimit 20
> queue up_ssh parent up bandwidth 6M qlimit 50
> queue up_web parent up bandwidth 6M qlimit 50
> match on egress set queue up_def
> match out on egress proto {tcp, udp} to port 1:1024 set queue up_web
> match on egress proto tcp to port 22 set queue up_ssh
> match out on egress proto {tcp, udp} to port 53 set queue up_dns
> match on egress proto icmp set queue up_dns
> match out on egress proto tcp to port {119, 563} set queue up_def 
> 
> queue down on re1 bandwidth 150M max 150M
> queue down_def parent down bandwidth 10M qlimit 100 default
> queue down_dns parent down bandwidth 20M qlimit 200
> queue down_ssh parent down bandwidth 60M qlimit 500
> queue down_web parent down bandwidth 60M qlimit 500
> match on re1 set queue down_def
> match in on re1 proto {tcp, udp} to port 1:1024 set queue down_web
> match on re1 proto tcp to port 22 set queue down_ssh
> match in on re1 proto {tcp, udp} to port 53 set queue down_dns
> match on re1 proto icmp set queue down_dns
> match in on re1 proto tcp to port {119, 563} set queue down_def
> 
> --- SNIP ---
> 
> -- 
> Björn Ketelaars
> GPG key: 0x4F0E5F21
> 

Re: re0 and re1 watchdog timeouts, and system freeze

[Martin Pieuchot]

On 08/06/17(Thu) 20:38, Björn Ketelaars wrote:
> On Thu 08/06/2017 16:55, Martin Pieuchot wrote:
> > On 07/06/17(Wed) 09:43, Björn Ketelaars wrote:
> > > On Sat 03/06/2017 08:44, Björn Ketelaars wrote:
> > > > 
> > > > Reverting back to the previous kernel fixed the issue above. Question: 
> > > > can
> > > > someone give a hint on how to track this issue?
> > > 
> > > After a bit of experimenting I'm able to reproduce the problem. Summary is
> > > that queueing in pf and use of a current (after May 30), multi processor
> > > kernel (bsd.mp from snapshots) causes these specific watchdog timeouts
> > > followed by a system freeze.
> > > 
> > > Issue is 'gone' when:
> > > 1.) using an older kernel (before May 30);
> > > 2.) removal of queueing statements from pf.conf. Included below the 
> > > specific
> > > snippet;
> > > 3.) switch from MP kernel to SP kernel.
> > > 
> > > New observation is that while queueing, using a MP kernel, the download
> > > bandwidth is only a fraction of what is expected. Exchanging the MP kernel
> > > with a SP kernel restores the download bandwidth to expected level.
> > > 
> > > I'm guessing that this issue is related to recent work on PF?
> > 
> > It's certainly a problem in, or exposed by, re(4) with the recent MP work
> > in the network stack.
> > 
> > It would help if you could build a kernel with MP_LOCKDEBUG defined and
> > see if the resulting kernel enters ddb(4) instead of freezing.
> > 
> > Thanks,
> > Martin
> 
> Thanks for the hint! It helped in entering ddb. I collected a bit of output,
> which you can find below. If I read the trace correctly the crash is related
> to line 1750 of sys/dev/ic/re.c:
> 
>   d->rl_cmdstat |= htole32(RL_TDESC_CMD_EOF);

Could you test the diff below, always with a MP_LOCKDEBUG kernel and
tell us if you can reproduce the freeze or if the kernel enters ddb(4)?

Another question, how often do you see "watchdog timeout" messages?

Index: re.c
===
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.201
diff -u -p -r1.201 re.c
--- re.c24 Jan 2017 03:57:34 -  1.201
+++ re.c9 Jun 2017 10:04:43 -
@@ -2074,9 +2074,6 @@ re_watchdog(struct ifnet *ifp)
s = splnet();
printf("%s: watchdog timeout\n", sc->sc_dev.dv_xname);
 
-   re_txeof(sc);
-   re_rxeof(sc);
-
re_init(ifp);
 
splx(s);

Re: splassert: pool_put: want 0 have 4

[Martin Pieuchot]

On 14/06/17(Wed) 16:56, Marko Cupać wrote:
> On Tue, 13 Jun 2017 11:38:46 + (UTC)
> Stuart Henderson  wrote:
> 
> > Can you try "sysctl kern.splassert=2" to obtain a backtrace?
> > 
> > (This isn't on by default as there's a small risk of problems,
> > though I run this on almost all my routers/firewalls and never
> > had trouble from it).
> 
> Here's the backtrace:
> 
> Jun 14 16:52:05 nat2 /bsd: splassert: pool_put: want 0 have 4
> Jun 14 16:52:05 nat2 /bsd: Starting stack trace...
> Jun 14 16:52:05 nat2 /bsd: pool_put() at pool_put+0x6b
> Jun 14 16:52:05 nat2 /bsd: pipex_destroy_session() at 
> pipex_destroy_session+0xe4
> Jun 14 16:52:05 nat2 /bsd: pipex_timer() at pipex_timer+0x85
> Jun 14 16:52:05 nat2 /bsd: timeout_run() at timeout_run+0x48
> Jun 14 16:52:05 nat2 /bsd: softclock() at softclock+0x147
> Jun 14 16:52:05 nat2 /bsd: softintr_dispatch() at softintr_dispatch+0x8b
> Jun 14 16:52:05 nat2 /bsd: Xsoftclock() at Xsoftclock+0x1f

This has been fixed by yasuoka@ on Mai 28th.  Please try a new snapshot
and report back if you still encounter similar problems.

Cheers,
Martin

Re: inet6 packet filter question: link local address vs antispoof

[Martin Pieuchot]

On 11/06/17(Sun) 15:51, Harald Dunkel wrote:
> Hi folks,
> 
> pf.conf on my gateway (6.1) says
> 
> bash-4.4# pfctl -sr | egrep -i icmp\|block
> block return log all
> :
> :
> pass quick inet proto icmp all keep state (if-bound)
> pass quick inet6 proto ipv6-icmp all keep state (if-bound)
> 
> Problem is, a ping6 to the gateway's link local address is not
> answered. The pflog file reveals
> 
> 15:11:35.491878 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:1) (len 64, hlim 64)
> 15:11:36.520792 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:2) (len 64, hlim 64)
> 15:11:37.544670 rule 0/(match) [uid 0, pid 14639] block out on re1: [uid 
> 4294967295, pid 10] ::1 > fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply 
> (id:7445 seq:3) (len 64, hlim 64)
> 
> Please note the "::1". This address is not bound to re1. If I
> disable the firewall(!), or if I use
> 
>   pass quick inet6 proto ipv6-icmp all no state
> 
> then the icmp6 echo reply can pass:
> 
> bash-4.4# tcpdump -i re1 -env icmp6
> tcpdump: listening on re1, link-type EN10MB
> 15:13:36.328563 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:30) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:36.328689 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:30) (len 64, hlim 64)
> 15:13:37.352729 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:31) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:37.352845 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:31) (len 64, hlim 64)
> 15:13:38.376557 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:32) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:38.376672 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:32) (len 64, hlim 64)
> 15:13:39.400577 f4:6d:04:73:ab:4e 80:ee:73:95:c1:0d 86dd 118: 
> fe80::f66d:4ff:fe73:ab4e > fe80::82ee:73ff:fe95:c10d: icmp6: echo request 
> (id:74c1 seq:33) [flowlabel 0x47412] (len 64, hlim 255)
> 15:13:39.400693 80:ee:73:95:c1:0d f4:6d:04:73:ab:4e 86dd 118: ::1 > 
> fe80::f66d:4ff:fe73:ab4e: icmp6: echo reply (id:74c1 seq:33) (len 64, hlim 64)
> 
> But this doesn't help. The sender address of the echo reply is still
> bad. It is blocked by some antispoof rule on the receiver, afaict.

Looks like the source address selection for the reply is wrong.  Could
you please show me the routing table of this machine?

$ route -n show -inet6

Re: inet6 packet filter question: link local address vs antispoof

[Martin Pieuchot]

On 11/06/17(Sun) 16:23, Harald Dunkel wrote:
> PS #1: Outgoing traffic to a link-local address initiated by the
> gateway is not corrupted.
> 
> PS #2: It seems that OpenBSD 6.0 doesn't show this problem.

Could you use tcpdump on 6.0, do you spot any difference?

Re: splassert: pool_put: want 0 have 4

[Martin Pieuchot]

On 21/06/17(Wed) 17:42, Marko Cupać wrote:
> On Tue, 20 Jun 2017 12:22:46 +0200
> Martin Pieuchot  wrote:
> 
> > On 14/06/17(Wed) 16:56, Marko Cupać wrote:
> > > On Tue, 13 Jun 2017 11:38:46 + (UTC)
> > > Stuart Henderson  wrote:
> > >   
> > > > Can you try "sysctl kern.splassert=2" to obtain a backtrace?
> > > > 
> > > > (This isn't on by default as there's a small risk of problems,
> > > > though I run this on almost all my routers/firewalls and never
> > > > had trouble from it).  
> > > 
> > > Here's the backtrace:
> > > 
> > > Jun 14 16:52:05 nat2 /bsd: splassert: pool_put: want 0 have 4
> > > Jun 14 16:52:05 nat2 /bsd: Starting stack trace...
> > > Jun 14 16:52:05 nat2 /bsd: pool_put() at pool_put+0x6b
> > > Jun 14 16:52:05 nat2 /bsd: pipex_destroy_session() at
> > > pipex_destroy_session+0xe4 Jun 14 16:52:05 nat2 /bsd: pipex_timer()
> > > at pipex_timer+0x85 Jun 14 16:52:05 nat2 /bsd: timeout_run() at
> > > timeout_run+0x48 Jun 14 16:52:05 nat2 /bsd: softclock() at
> > > softclock+0x147 Jun 14 16:52:05 nat2 /bsd: softintr_dispatch() at
> > > softintr_dispatch+0x8b Jun 14 16:52:05 nat2 /bsd:
> > > Xsoftclock() at Xsoftclock+0x1f  
> > 
> > This has been fixed by yasuoka@ on Mai 28th.  Please try a new
> > snapshot and report back if you still encounter similar problems.
> 
> Thanx for info. Any chance to get this as (sys)patch? I'm tracking
> binary -stable for my production, I'd rather not experiment with
> snapshots as they tend to fix one thing while breaking another.

No it won't happen, this is not critical and the change is too
intrusive.

Re: isakmpd memory usage

[Martin Pieuchot]

On 17/06/17(Sat) 09:49, Nicolas Repentin wrote:
> No one ?
> 
> Le 13 juin 2017 09:11:02 GMT+02:00, Nicolas  a écrit :
> >Hi everyone
> >
> >I'm searching some help about isakmpd, which is eating a lot of memory,
> >until the machine crash. It's an OpenBSD 6.1 on Qemu KVM (ganeti).
> >After 3 days, the process is using 650MB of memory.
> >
> >When she's "freezed", she's unreachable on network, and on console
> >she's blinking on tty, like normal, but we can't write anything on it.
> >No .core are generated.
> >
> >I got a lot of errors like "INVALID_ID_INFORMATION" on
> >"NO_PROPOSAL_CHOSEN" on ipsec logs, but ipsec connections are working.
> >
> >Any idea how I can debug it?

You could start by increasing the log level.

Then rotate the log regularity, like everyday.

Every time you rotate the log, write down the amount of memory consumed
by the daemon.

Then hopefully you can find a pattern in the log that's proportional to
the amount of memory leaked between each rotation.  Many the number of
INVALID_ID_INFORMATION or something else.

That information could help us reducing the scope of the memory leak.

Re: touchpad input driver: test results

[Martin Pieuchot]

Thanks for your work Ulf.

By the way I brought a new laptop, X1 Carbon gen2 for you from Toronto.

It's a gift from deraadt@.  It has a soft-button synaptics and a USB
touchscreen.

Cheers,
Martin


On 20/08/17(Sun) 22:17, Ulf Brosziewski wrote:
> As people might want to know what they have worked for, it's probably
> time for a summary of the first test results and my conclusions.
> (But please don't get that wrong: more tests and reports are and will be
> welcome.)
> 
> Hardware:  Most tests were made with (PS/2) Synaptics touchpads, and it
> seems there are no problems with common models of "OpenBSD laptops".
> Few quirks and bugs have been reported for older and less common ones,
> and concern things that should be handled by the hardware driver.  Alps
> and Elantech models are rare, and it looks like most Mac users are on
> holiday.
> 
> Driver mechanisms:  No serious problem has come up.  It has been
> observed that there are (too) long delays between the start of a scroll
> gesture and the first scroll event.  I'm already testing an improved
> version of the handler.  There will still be a short delay, because
> it reduces the risk that you produce scroll events unintentionally.
> 
> Features:  Not surprisingly, some people are missing certain features.
> What has been mentioned is 1) "disable-while-typing", 2) edge areas
> (where initial contacts don't move the pointer or generate tap events),
> 3) multi-finger clicks, and 4) "coasting" (that is, scrolling continues
> for some time after the scrolling fingers have been lifted).  Up to now
> my impression is that 1) and/or 2) could be prominent, maybe 3).
> However, there are no decisions about additional features yet, each one
> would need some care.
> 
> 1) and 2) are different approaches to the same task: suppressing outputs
> of accidental contacts, usually palm or thumb contacts, so in this
> context one might also think of: 5) palm and thumb detection based on
> contact width, pressure, and other attributes, perhaps.  1) is based on
> a simple principle, but it needs coordination with another driver, and I
> am not sure whether it is a good solution, or despair.  What's a
> reasonable timeout here?  If it's too short, it only mitigates the
> problem, if it's too long, it can be a nuisance.  5) might work well for
> some users, with some touchpads, but it may be difficult to find useful
> generalizations.  I'm currently checking variants of 2), the basic
> mechanism is already present in the driver (it's required for software
> buttons and edge scroll areas).  But again, it's too early for
> conclusions, and surely we want to avoid a patchwork of half-general and
> half-successful solutions.
> 
> Default configuration:  The defaults, including the "hidden" ones, seem
> to be acceptable for many models.  I will increase the default scroll
> speed (moderately).  In some cases, the height of the button area on
> clickpads is problematic.  This is not as trivial as it may seem.
> Coordinate limits are not always correct, and resolution values can be
> unreliable - if they are present at all.  There is actually a good deal
> of guess work in the configuration.  Improving that will need more work
> on the hardware drivers.
> 
> As I have written, not all touchpad drivers cooperate with the input
> driver up to now.  I hope this will change soon.  It's not ready yet,
> but some work on imt/hidmt has already been done, with help of Remi.
> 
> Thanks again for the friendly, competent, and helpful feedback!
> 
> 
> On 07/31/2017 11:02 PM, Ulf Brosziewski wrote:
> > In the long run the synaptics driver, which handles touchpad inputs in
> > X, may be a dead end of the input framework, and it's time to prepare
> > an alternative.  The kernel contains an internal touchpad input driver
> > now, it's a part of wsmouse(4).  It provides standard features -
> > two-finger/edge scrolling, software buttons for clickpads, tapping -
> > and various kinds of plankton required for usability.
> > 
> > If you have a new snapshot (from July 27 or later) on a laptop with a
> > Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with
> > tests [...]
> 

Re: simple-mtpfs kernel panic

[Martin Pieuchot]

On 01/10/17(Sun) 20:35, Olivier Antoine wrote:
> Hi,
> 
> Looks like this bug: 
> 
> I can also reproduce this with:
> 
> $ while true ; do adb shell ls / ; adb kill-server ; done
> 
> The code which is triggered in /sys/dev/usb/ehci.c:
> 
> ehci_device_clear_toggle(struct usbd_pipe *pipe)
> {
> struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
> 
> #ifdef DIAGNOSTIC
> if ((epipe->sqh->qh.qh_qtd.qtd_status & htole32(EHCI_QTD_ACTIVE)) != 
> 0)
> panic("ehci_device_clear_toggle: queue active");
> #endif
> epipe->sqh->qh.qh_qtd.qtd_status &= htole32(~EHCI_QTD_TOGGLE_MASK);
> }
> 
> Don't know if it's hardware specific. But I can confirm that it hit me too.

Bug reports without dmesg are useless, see sendbug(1).

Anyway, here's a diff that should fix the problem.  However last I
couldn't narrow down possible regressions.  So make sure everything
works with it, including suspend/resume.

Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.200
diff -u -p -r1.200 ehci.c
--- ehci.c  15 May 2017 10:52:08 -  1.200
+++ ehci.c  3 Oct 2017 09:24:08 -
@@ -116,6 +116,7 @@ usbd_status ehci_open(struct usbd_pipe *
 intehci_setaddr(struct usbd_device *, int);
 void   ehci_poll(struct usbd_bus *);
 void   ehci_softintr(void *);
+intehci_start(struct ehci_softc *);
 intehci_intr1(struct ehci_softc *);
 void   ehci_check_intr(struct ehci_softc *, struct usbd_xfer *);
 void   ehci_check_qh_intr(struct ehci_softc *, struct usbd_xfer *);
@@ -188,12 +189,11 @@ int   ehci_alloc_sitd_chain(struct ehci_s
 void   ehci_abort_isoc_xfer(struct usbd_xfer *xfer,
usbd_status status);
 
-usbd_statusehci_device_setintr(struct ehci_softc *, struct ehci_soft_qh *,
-   int ival);
+struct ehci_soft_qh * ehci_intr_get_sqh(struct usbd_pipe *);
 
-void   ehci_add_qh(struct ehci_soft_qh *, struct ehci_soft_qh *);
-void   ehci_rem_qh(struct ehci_softc *, struct ehci_soft_qh *);
-void   ehci_set_qh_qtd(struct ehci_soft_qh *, struct ehci_soft_qtd *);
+void   ehci_add_qh(struct usbd_pipe *, struct ehci_soft_qh *,
+   struct ehci_soft_qtd *);
+void   ehci_rem_qh(struct ehci_softc *, struct usbd_pipe *);
 void   ehci_sync_hc(struct ehci_softc *);
 
 void   ehci_close_pipe(struct usbd_pipe *);
@@ -295,7 +295,7 @@ ehci_reverse_bits(u_int8_t c, int nbits)
 usbd_status
 ehci_init(struct ehci_softc *sc)
 {
-   u_int32_t sparams, cparams, hcr;
+   uint32_t sparams;
u_int i, j;
usbd_status err;
struct ehci_soft_qh *sqh;
@@ -316,20 +316,8 @@ ehci_init(struct ehci_softc *sc)
sparams = EREAD4(sc, EHCI_HCSPARAMS);
DPRINTF(("ehci_init: sparams=0x%x\n", sparams));
sc->sc_noport = EHCI_HCS_N_PORTS(sparams);
-   cparams = EREAD4(sc, EHCI_HCCPARAMS);
-   DPRINTF(("ehci_init: cparams=0x%x\n", cparams));
-
-   /* MUST clear segment register if 64 bit capable. */
-   if (EHCI_HCC_64BIT(cparams))
-   EWRITE4(sc, EHCI_CTRLDSSEGMENT, 0);
-
sc->sc_bus.usbrev = USBREV_2_0;
 
-   DPRINTF(("%s: resetting\n", sc->sc_bus.bdev.dv_xname));
-   err = ehci_reset(sc);
-   if (err)
-   return (err);
-
if (ehcixfer == NULL) {
ehcixfer = malloc(sizeof(struct pool), M_DEVBUF, M_NOWAIT);
if (ehcixfer == NULL) {
@@ -365,8 +353,6 @@ ehci_init(struct ehci_softc *sc)
for (i = 0; i < sc->sc_flsize; i++)
sc->sc_flist[i] = htole32(EHCI_LINK_TERMINATE);
 
-   EOWRITE4(sc, EHCI_PERIODICLISTBASE, DMAADDR(&sc->sc_fldma, 0));
-
sc->sc_softitds = mallocarray(sc->sc_flsize,
sizeof(struct ehci_soft_itd *), M_USB, M_NOWAIT | M_ZERO);
if (sc->sc_softitds == NULL) {
@@ -412,7 +398,6 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(&sqh->dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
}
@@ -443,18 +428,47 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(&sqh->dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
 
/* Point to async list */
sc->sc_async_head = sqh;
-   EOWRITE4(sc, EHCI_ASYNCLISTADDR, sq

Re: fuse version

[Martin Pieuchot]

On 25/10/17(Wed) 12:01, Stefan Sperling wrote:
> [...] 
> More help on fuse support would certainly be welcome, I think.
> It has not been actively maintained for some time.

Exactly.  There are many way to help.  It's not necessarily hard.   Helg
Bredow has been looking at some issues recently.  But it would be great
to see more regression tests, so make sure our libfuse matches what the
original 2.6 version does.  More documentation/man pages would also be
welcome.  Fuzzing the library would also help catch bugs.

Alternatively changing the API to match a newer version would also be
welcomed.

Re: no route to host (when there is a route )

[Martin Pieuchot]

On 01/05/18(Tue) 21:28, Ingo Schwarze wrote:
> [...] 
> So what you are doing seems fragile to me.  It may sometimes work
> due to order of configuration, timeouts, whatever, i'm not sure.

It can work if the ARP entry, what Ingo called the /32 is created
before you add your /23.

> But once part of it gets broken for whatever reason, i don't see
> how it could possibly automatically recover via the normal RTF_CLONING
> mechanism.

It can't because as you described the /23 will be a better match.  And the
reason will be the expiration of the ARP cache.

Re: protection fault trap with OpenBSD 6.3

[Martin Pieuchot]

On 28/05/18(Mon) 22:24, Marc Peters wrote:
> Hi List,
> 
> i am having issues with OpenBSD 6.3, latest patches as of today applied. We 
> are using gif-tunnels between our datacenters, transport encryption and 
> OpenBGPD to announce the prefixes between the datacenters. The boxes also 
> have isakmpd tunnels on a carp interface to AWS and GCP. The setup is working 
> fine with existing 6.1 boxes and there's no problem in pushing/receiving 
> several 100MBit/s (according to observium snmpd data, which gets constantly 
> collected). Switching the traffic to the 6.3 hosts, we get a freeze on one of 
> the boxes after about 45 minutes of transferring traffic (all IPv4 traffic in 
> our case for now):

This has been fixed in -current.

Re: iked[12345]: pfkey_reply: no reply from PF_KEY (-current)

[Martin Pieuchot]

On 10/09/18(Mon) 12:15, Mark Patruck wrote:
> I've tested with a current snapshot and two freshly installed systems
> and get the same error, but...
> 
> reverting mpi@s 'Add per-TDB counters and a new SADB extension (1)'
> changes make the issues disappear.
> 
> (1) https://marc.info/?l=openbsd-cvs&m=153546931106420&w=2

Does the smaller revert below also fix the issue?

Index: net/pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.191
diff -u -p -r1.191 pfkeyv2.c
--- net/pfkeyv2.c   31 Aug 2018 12:55:46 -  1.191
+++ net/pfkeyv2.c   10 Sep 2018 13:39:01 -
@@ -793,8 +793,7 @@ pfkeyv2_get(struct tdb *tdb, void **head
void *p;
 
/* Find how much space we need */
-   i = sizeof(struct sadb_sa) + sizeof(struct sadb_lifetime) +
-   sizeof(struct sadb_x_counter);
+   i = sizeof(struct sadb_sa) + sizeof(struct sadb_lifetime);
 
if (tdb->tdb_soft_allocations || tdb->tdb_soft_bytes ||
tdb->tdb_soft_timeout || tdb->tdb_soft_first_use)
@@ -955,9 +954,6 @@ pfkeyv2_get(struct tdb *tdb, void **head
export_tap(&p, tdb);
}
 #endif
-
-   headers[SADB_X_EXT_COUNTER] = p;
-   export_counter(&p, tdb);
 
rval = 0;
 

Re: inet6 autoconf will not remove invalid addresses on -current

[Martin Pieuchot]

Hello,

On 30/09/15(Wed) 18:19, Daniel Gillen wrote:
> [...]
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev vlan35 \
> authproto pap \
> authname "@vo.lu" \
> authkey ""
> dest 0.0.0.1
> inet6 autoconf
> !/sbin/route add 0.0.0.0/0 -ifp pppoe0 0.0.0.1
> !/sbin/route add ::/0 -ifp pppoe0 fe80::
> 
> As you can see, it get my IPv6 address trough autoconfiguration.
> 
> After my pppoe reconnected again, I saw the following in ifconfig:

What do you mean by "reconnected again" ?

> pppoe0: flags=208851
> mtu 1492
> priority: 0
> dev: vlan35 state: session
> sid: 0x44e PADI retries: 8 PADR retries: 0 time: 13:20:45
> sppp: phase network authproto pap authname "@vo.lu"
> groups: pppoe egress
> status: active
> inet6 fe80::XX:XX:XX:6c3a%pppoe0 ->  prefixlen 64 scopeid 0x8
> inet6 2001:XX:XX:6f3:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
> pltime 556434 vltime 2543634
> [...]
> inet6 2001:XX:XX:6f3:XX:XX:XX:87b2 ->  prefixlen 64 autoconf
> autoconfprivacy pltime 1835 vltime 520374
> inet 85.XX.XX.XX --> 80.XX.XX.XX netmask 0x
> inet6 2001:XX:XX:7c5:XX:XX:XX:6c3a ->  prefixlen 64 autoconf
> pltime 604755 vltime 2591955
> inet6 2001:XX:XX:7c5:XX:XX:XX:30c ->  prefixlen 64 autoconf
> autoconfprivacy pltime 37915 vltime 556755
> 
> I got the new 2001:XX:XX:7c5::/64 prefix after the reconnect and OpenBSD
> added it to my interface.
> 
> But it didn't remove the now invalid and no longer working
> 2001:XX:XX:6f3::/64 prefix addresses which caused quite some issues as
> my NAT was still using that address for part of the connections.
> 
> Shouldn't those be removed as soon as their prefix is no longer valid?
> Or at least all be deprecated?

If this happens again could you include the output of "# ndp -p",
"# route -n show -inet6" and "# ndp -r" in your report?

Thanks,
Martin

Re: inet6 autoconf will not remove invalid addresses on -current

[Martin Pieuchot]

On 01/10/15(Thu) 19:00, Daniel Gillen wrote:
> [...] 
> I managed to reproduce the issue and executed the commands you told me.
> 
> # ifconfig pppoe0
> IPv4 address is 80.XX.XX.227
> Autoconfigured IPv6 address is 2001:XX:XX:707:XX:XX:XX:6c3a
> 
> # ping6 -c 1 -S 2001:XX:XX:707:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
> Pinging google with that source address works
> 
> # ndp -p
> 2001:XX:XX:707::/64 if=pppoe0
> flags=LAD vltime=2592000, pltime=604800, expire=29d23h59m39s, ref=2
> advertised by
> fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)
> 
> # route -n show -inet6
> See long version below
> 
> # ndp -r
> fe80::46d3:caff:fe9c:ef00%pppoe0 if=pppoe0, flags=O, pref=medium,
> expire=29m59s
> 
> Now I simmulated a PPPoE dis-/re-connect (Thx again to Todd for the tip)
> # ifconfig pppoe0 down up
> 
> # ifconfig pppoe0
> New IPv4 address is 85.XX.XX.98
> But now I have 2 autoconfigured IPv6 addresses, the old
> 2001:XX:XX:707:XX:XX:XX:6c3a address and the new
> 2001:XX:XX:7c5:XX:XX:XX:6c3a address.
> 
> # ping6 -c 1 -S 2001:XX:XX:707:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
> # ping6 -c 1 -S 2001:XX:XX:7c5:XX:XX:XX:6c3a 2a00:1450:4001:806::1009
> Pinging google with the old 2001:XX:XX:707::/64 prefix address does not
> work anymore, but the new 2001:XX:XX:7c5::/64 prefix address works.
> 
> # ndp -p
> 2001:XX:XX:7c5::/64 if=pppoe0
> flags=LAD vltime=2592000, pltime=604800, expire=29d23h59m47s, ref=2
> advertised by
> fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)
> 2001:XX:XX:707::/64 if=pppoe0
> flags=LAD vltime=2592000, pltime=604800, expire=29d23h58m45s, ref=2
> advertised by
> fe80::46d3:caff:fe9c:ef00%pppoe0 (no neighbor state)
> 
> # route -n show -inet6
> Again, see below
> 
> # ndp -r
> fe80::46d3:caff:fe9c:ef00%pppoe0 if=pppoe0, flags=O, pref=medium,
> expire=29m28
> 
> I think the old 2001:XX:XX:707::/64 prefix should be removed as soon as
> the same router (fe80::46d3:caff:fe9c:ef00) advertises a new prefix.
> 
> Or am I getting something wrong here?

I can confirm that our kernel does not remove prefixes if a router stops
to advertise it.  Although it's unclear to me *when* we should remove
this prefix (and the associated autoconf address) except when it expires.

In your use case it seems clear to me that removing a previously
configured address makes sense.  Although this requires some non
trivial code refactoring, so I'd like to hear what others think
about this prior to start coding.

Any comment?

An alternate solution^Whack would be to give higher priority to the
last autoconfigured address, but I'm sure this would have downsides.

Re: inet6 autoconf will not remove invalid addresses on -current

[Martin Pieuchot]

On 02/10/15(Fri) 12:53, Stuart Henderson wrote:
> [...] 
> I think it would probably make sense to remove an autoconfigured
> prefix/address if an interface goes down (and one could argue for this
> being the right thing to do for IPv4/DHCP as well - I lost count of
> the number of times I have to manually remove addresses so I can
> continue to reach my home subnet after I've unplugged the laptop).

This makes sense and should work for LCP keepalive as well. But I
don't know how hard would it be to teach dhclient(8) to do that...

Re: /bsd: em0: watchdog timeout -- resetting

[Martin Pieuchot]

On 05/10/15(Mon) 10:35, Sonic wrote:
> On Sun, Oct 4, 2015 at 12:00 PM, Stuart Henderson  
> wrote:
> > I'm hoping it isn't this, but please try backing out the last commits to
> > if_em.c and if_em.h ("cd /sys/dev/pci; cvs up -D 2015/09/29 if_em*") to
> > see if it makes a difference.
> 
> Same issue here. Reverting now and will post if problem resurfaces.

Dmesg please.

Re: routing q

[Martin Pieuchot]

On 19/10/15(Mon) 13:37, Gregory Edigarov wrote:
> On 10/19/2015 01:24 PM, Stuart Henderson wrote:
> >On 2015-10-19, Gregory Edigarov  wrote:
> >>In order to conserve address space I am trying to confugure 'ip
> >>unnumbred' in cisco terminology, that is have an interface borrow the ip
> >>of a different interface, I am experimenting with vether0 and vlans the
> >>thing is to have one 'main' address on some 'real' interface and then
> >>just add routes pointing to the right interfaces.
> >>
> >># ifconfig vether0 192.168.100.1/24 up
> >># ifconfig vlan2 vlandev vether0 up
> >># ifconfig vlan3 vlandev vether0 up
> >># route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
> >>route: writing to routing socket: Network is unreachable
> >>add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable
> >>
> >>the same result I have if I am trying to configure this on a real
> >>interface connected  to my network:
> >>
> >># ifconfig vlan2 vlandev re0
> >># ifconfig vlan3 vlandev re0
> >># ifconfig re0 alias 192.168.100.1
> >># route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
> >>route: writing to routing socket: Network is unreachable
> >>add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable
> >>
> >># uname -a
> >>OpenBSD lbld12.duckdns.org 5.8 GENERIC.MP#1507 amd64
> >>
> >>I thoght OpenBSD supports such thing.
> >>
> >>am I missing something?
> >I don't *think* this is expected to work at the moment unless possibly
> >you specify a destination MAC address with -link.
> >
> >It does work with point-to-point interfaces, e.g. you can have
> >192.0.2.1/28 on em0 and 192.0.2.1/32 on pppoe0 and things will work
> >as expected, but in that case you don't have a problem of picking a
> >particular link-layer address, just "the pppoe0 interface" is enough
> >information for the system to know where to send the packet.
> >
> >The best I've done so far for address conservation on ethernet-like
> >interfaces is to use /31's (which works well).
> >
> Yes, I know /31 would work correctly, but I wanted further space
> conservation.

Does it?

> Is that a correct explanation that this does not work because  our routing
> table still wants a link layer address, errrmmm,  arp table is  included in
> routing table?

I believe it's simpler than that.  You cannot attach a route to an
interface without address, so I'm quite sure it will work if you add
an address to vlan2.

Re: crash with -current

[Martin Pieuchot]

On 01/11/15(Sun) 22:43, Sonic wrote:
> Upgraded -current earlier today, and system has crashed:

Do you have an idea how to reproduce this crash?  Which program are you
running that uses bpf?

> =
> Nov  1 22:23:55 stargate /bsd: uvm_fault(0x818f9920,
> 0xfff7818adf60, 0, 1) -> e
> Nov  1 22:23:55 stargate /bsd: fatal page fault in supervisor mode
> Nov  1 22:23:55 stargate /bsd: trap type 6 code 0 rip 81329e69
> cs 8 rflags 10286 cr2  fff7818adf60 cpl 7 rsp 8000221df76
> 0
> Nov  1 22:23:55 stargate /bsd: panic: trap type 6, code=0, pc=81329e69
> Nov  1 22:23:55 stargate /bsd: Starting stack trace...
> Nov  1 22:23:55 stargate /bsd: panic() at panic+0x10b
> Nov  1 22:23:55 stargate /bsd: trap() at trap+0x7b8
> Nov  1 22:23:55 stargate /bsd: --- trap (number 6) ---
> Nov  1 22:23:55 stargate /bsd: trap() at trap+0x709
> Nov  1 22:23:55 stargate /bsd: --- trap (number 4) ---
> Nov  1 22:23:55 stargate /bsd: trap() at trap+0x709
> Nov  1 22:23:55 stargate /bsd: --- trap (number 4) ---
> Nov  1 22:23:55 stargate /bsd: bpf_filter() at bpf_filter+0x19b
> Nov  1 22:23:55 stargate /bsd: _bpf_mtap() at _bpf_mtap+0xf4
> Nov  1 22:23:55 stargate /bsd: bpf_mtap_ether() at bpf_mtap_ether+0x39
> Nov  1 22:23:55 stargate /bsd: em_start() at em_start+0xd6
> Nov  1 22:23:55 stargate /bsd: nettxintr() at nettxintr+0x52
> Nov  1 22:23:55 stargate /bsd: softintr_dispatch() at softintr_dispatch+0x8b
> Nov  1 22:23:55 stargate /bsd: Xsoftnet() at Xsoftnet+0x1f
> Nov  1 22:23:55 stargate /bsd: --- interrupt ---
> Nov  1 22:23:55 stargate /bsd: end of kernel
> Nov  1 22:23:55 stargate /bsd: end trace frame: 0xff8132b494, count: 246
> Nov  1 22:23:55 stargate /bsd: 0x282:
> Nov  1 22:23:55 stargate /bsd: End of stack trace.
> =
> # dmesg
> OpenBSD 5.8-current (GENERIC.MP) #8: Sun Nov  1 13:10:37 EST 2015
> r...@stargate.grizzly.bear:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4277665792 (4079MB)
> avail mem = 4143894528 (3951MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9f000 (19 entries)
> bios0: vendor American Megatrends Inc. version "1.2b" date 07/19/13
> bios0: Supermicro X7SPA-HF
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
> acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4)
> USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4)
> P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.23 MHz
> 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 512KB 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 200MHz
> cpu0: mwait min=64, max=64, C-substates=0.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.01 MHz
> 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,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 512KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 3 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 1, remapped to apid 3
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 4 (P0P1)
> acpiprt2 at acpi0: bus 1 (P0P4)
> acpiprt3 at acpi0: bus 2 (P0P8)
> acpiprt4 at acpi0: bus 3 (P0P9)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpibtn0 at acpi0: SLPB
> acpibtn1 at acpi0: PWRB
> ipmi at mainbus0 not configured
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
> uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 16
> uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 21
> uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 19
> ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 18
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
> pci1 at ppb0 bus 1
> ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
> pci2 at ppb1 bus 2
> em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
> 00:25:90:92:d4:f8
> ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
> pci3 at ppb2 

Re: rtadvd not picking up dynamic ranges automatically anymore

[Martin Pieuchot]

On 09/11/15(Mon) 13:11, Giancarlo Razzolini wrote:
> Em 09-11-2015 12:45, Sly Midnight escreveu:
> > [...]
> > This was not a big deal as rtadvd would simply see the new prefix on my
> > internal interface and start sending out RA's with that prefix.  And
> > naturally my internal clients would automatically reconfigure themselves.
> >
> > Now I've noticed for a couple releases or more rtadvd does not notice a
> > change of the available prefixes assigned to the interface it both
> > monitors and advertises on.  I have not changed my config for it, as I
> > just run it without a configuration file invoking it's default behavior
> > (since I cannot know what my IPv6 prefix will be ahead of time).
> 
> I noticed this same behaviour. I devised two solutions, one is to use
> ifstated to monitor link changes and restart rtadvd accordingly and the
> other is to use ULA on the internal network.

As soon as you notice a regression please try to notify us.  I'm sorry
to say so, but we don't have the manpower to dig for a regression that
might have happen since "a couple of releases".

One of the reason we ask for a dmesg is that we can easily identify when
things broke.  We try the best we can not to break things, but sometimes
it is hard.  Sorry for that.

Now if you prefer to cook your own workaround, that's up to you ;)

Cheers,
Martin

Re: Fwd: USB mouse often not detected

[Martin Pieuchot]

On 10/11/15(Tue) 21:12, Notofsoundmind . wrote:
> -- Forwarded message --
> From: Notofsoundmind . 
> Date: Tue, Nov 10, 2015 at 5:47 PM
> Subject: Re: USB mouse often not detected
> To: Paco Willers 
> 
> 
> Hello everyone,
> I am having a similar problem with USB.  At times I can attach a
> device (mouse, keyboard, external HDD) and the machine will
> recognize it immediately.  Other times this is not the case, and I
> have to unplug and replug multiple times for it to work.  Also these
> devices will randomly disconnect, and I get the message
> "ehci_sync_hc: tsleep() = 35".  After much thought I assumed the
> problem may be related to the nVidia hardware on the motherboard
> so I ordered another motherboard without nVidia components..
> 
> My dmesg as follows:

We need a dmesg when it doesn't work to see what could go wrong.

Re: USB mouse often not detected

[Martin Pieuchot]

On 10/11/15(Tue) 23:51, Paco Willers wrote:
> Hi,
> 
> 
> I reinstalled OpenBSD 5.8 and updated to stable again, so I now have a
> clean install. The only thing I configured manually is: I added
> 'apmd_flags="-A"' in /etc/rc.conf.local to do CPU frequency scaling while
> I'm not sure my system supports it.
> 
> It seems a randomly occuring problem. My mouse: "vendor 0x USB OPTICAL
> MOUSE". It's wholesale cheap stuff. Other OSes don't show the problem, and
> that makes me believe the mouse is doing alright. I happen to have two of
> them, so to be certain I'll swap it and test this new configuration in a
> few days. I'll keep you informed. I wouldn't be surprised if this cheap
> piece of hardware would have some minor incompatibility that only a correct
> OS's (OpenBSD) driver would crash upon. :-) (That doesn't explain Maurice's
> identical problem using a Logitech mouse. Also, to my knowledge a crashed
> driver would raise an error message which I didn't see.)
> 
> Here are my dmesg outputs that might help. Of course if you want to see
> more files, I'd be happy to provide them. Also if you come up with some
> ideas I could test, let me know. (I won't be available for a few days
> however.)
> 
> My dmesg detecting the mouse:

Could you play with lsusb(1), from the usbutils package?  "lsusb -v"
will report the hub status for each hub port.  I'd suggest running
"lsusb -v" when your mouse plugged in but not recognized, then unplug
it an run it again.  Compare the outputs.  Also compare them to an
output when the mouse is recognized.

If you can send me these tree output (you can limit them to the
corresponding hub) it could help figuring out what's wrong.

Re: serious watchdog timeout issues with em driver

[Martin Pieuchot]

On 19/11/15(Thu) 17:54, Sonic wrote:
> Have serious problems for over 7 weeks now with em driver,
> specifically any rev of if_em.c >  1.305. Starting with rev 1.306,
> released on 2015/09/30 and continuing to -current, watchdog timeouts
> rue the day. Unfortunately rev 1.305 no longer builds with -current as
> it appears the patch in rev 1.309 would be necessary.

I just committed a revert to 1.305 keeping the API changes needed for
the driver to build.

This should bring your stability back, please let us know if that's not
the case.

I'm sorry for your troubles.

Re: No USB 3.0 on 5.8 -current Broadwell

[Martin Pieuchot]

On 20/11/15(Fri) 17:32, edward wandasiewicz wrote:
> If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
> USB 3.1 Type C port, nothing gets registered via dmesg, even if I add

This issue seems to be occurring only after a warm reboot as found by
jcs@.

Could you tell me if your USB 3 devices are detected after the 1st cold
boot?

>  UKC> disable xhci
> 
> I get no USB 2.0 support at all.

Because you don't seem to have any ehci hardware. 

Re: Bridge and blocknonip

[Martin Pieuchot]

On 22/11/15(Sun) 01:11, Momtchil Momtchev wrote:
> On 22/11/2015 00:34, Reyk Floeter wrote:
> >On Sat, Nov 21, 2015 at 04:22:51PM +0100, Momtchil Momtchev wrote:
> >> Hello,
> >>
> >> Sorry for what may appear to be a strange question, but shouldn't there
> >>be a check against IFBIF_BLOCKNONIP in bridge_output() in
> >>sys/net/if_bridge.c?
> >>
> >Why?  bridge_output() is used for packets that are sent from local
> >interfaces.  I think you should be aware if you're running any non-IP
> >service on your OpenBSD machine.
> >
> >I think your change would also break bridge_send_icmp_err() with
> >IFBIF_BLOCKNONIP, which is used by bridge_ipsec() and
> >bridge_fragment(). blocknonip and tunnels are not uncommon.
> >
> >btw., what OpenBSD version is this diff for?  This is not -current.
> 
> Thanks for the quick reply. That was my impression too, but it seems
> that bridge_output is also used sometimes for forwarding ARP requests by a
> code path that I haven't found yet - it is not a direct forwarding, it is
> like some kind of a proxy-ARP mechanism. I have a modified bridge and for me
> it makes sense (it is for a box that bridges IP6 traffic and routes IP4
> traffic - so I am blocking IP4 only with BLOCKNONIP), I just wondered why it
> was not there and if I was missing something. Who does call bridge_output?
> Isn't output always on the underlying interface, not directly on the bridge?

If you want some help you need to provide the information that allows
us to help you.  Which version are you running?  Can you describe the
problem you're facing *without* any modification on such version?

Re: Bridge and blocknonip

[Martin Pieuchot]

On 22/11/15(Sun) 16:56, Momtchil Momtchev wrote:
> On 22/11/2015 15:52, Martin Pieuchot wrote:
> >
> >btw., what OpenBSD version is this diff for?  This is not -current.
> >> Thanks for the quick reply. That was my impression too, but it seems
> >>that bridge_output is also used sometimes for forwarding ARP requests by a
> >>code path that I haven't found yet - it is not a direct forwarding, it is
> >>like some kind of a proxy-ARP mechanism. I have a modified bridge and for me
> >>it makes sense (it is for a box that bridges IP6 traffic and routes IP4
> >>traffic - so I am blocking IP4 only with BLOCKNONIP), I just wondered why it
> >>was not there and if I was missing something. Who does call bridge_output?
> >>Isn't output always on the underlying interface, not directly on the bridge?
> >If you want some help you need to provide the information that allows
> >us to help you.  Which version are you running?  Can you describe the
> >problem you're facing *without* any modification on such version?
> 
> I just upgraded to 5.8 (from 4.9) and I see the bridge has changed
> somewhat. I am using the bridge to pass IPv6 only traffic, NATting and
> routing IPv4. This is not possible without modifying the bridge.

When you say "the bridge changed somewhat" are you saying that you see
a regression?  Could you share your setup that, I guess work with 4.9,
and no longer work with 5.8.

>  Since
> upgrading to 5.8 I started getting IPv4 ARP requests passing through my
> _BLOCKNONIPV6_ bridge (which is a problem since there is an equipement that
> gets confused by them on that other side). I traced those requests down to
> bridge_output, so I added that check which solved my problem. Except now I
> don't get ARPs at all on this interface, but this is fine with me, I added a
> static entry for the only router I needed.

I don't understand what you mean with "_BLOCKNONIPV6_ bridge". ifconfig(8)
clearly say:

 blocknonip interface
  Mark interface so that no non-IPv4, IPv6, ARP, or Reverse ARP
  packets are accepted from it or forwarded to it from other
  bridge member interfaces


> My questions were, isn't the missing BLOCKNONIP check actually needed by
> everyone (not really according to Reyk Floeter) and why is bridge_output
> used at all? ARP traffic should originate in the output function of the
> underlying interface, not the bridge? But anyway, at this point it is mostly
> academic, I solved my problem, I was just trying to understand the code.

Re: Bridge and blocknonip

[Martin Pieuchot]

On 22/11/15(Sun) 18:30, Momtchil Momtchev wrote:
> On 22/11/2015 17:48, Martin Pieuchot wrote:
> >On 22/11/15(Sun) 16:56, Momtchil Momtchev wrote:
> >>On 22/11/2015 15:52, Martin Pieuchot wrote:
> >>>
> >>>When you say "the bridge changed somewhat" are you saying that you see
> >>>a regression?  Could you share your setup that, I guess work with 4.9,
> >>>and no longer work with 5.8.
> >>>
> >>>
> >I don't understand what you mean with "_BLOCKNONIPV6_ bridge". ifconfig(8)
> >clearly say:
> >
> >  blocknonip interface
> >   Mark interface so that no non-IPv4, IPv6, ARP, or Reverse ARP
> >   packets are accepted from it or forwarded to it from other
> >   bridge member interfaces
> 
> I have a modified bridge that adds a new bridge option - BLOCKNONIPV6 -
> to block IPv4 traffic but pass IPv6 traffic. There's no regression, my only
> problem was that in 4.9 bridge_output() was never used in my particular
> case. In 5.8 bridge_output() is used for some strange forwarding of ARP
> packets - every ARP request on the internal side coming from a bridge
> interface without an IP address (yes, only on interfaces without an IP
> address) spawns an ARP request on the external side. That request is coming
> from bridge_output(), not the usual bridge code path in bridgeintr().

The result of your analysis is either incorrect or there's a bug I
couldn't found by looking briefly at the code.  In both cases I can't
help you because you're not sharing the important pieces of informations.

When an ARP packet is received on a bridge member bridgeintr() is called.
So what you say about "strange forwarding of ARP packets" doesn't match
with what you say as "That request is coming from bridge_output()".

>   In a
> non-modified stock OpenBSD bridge this would be the correct behaviour, so
> there is no bug here.

What would be this correct behaviour?  I don't understand what you're
describing so I cannot say if I agree that there's no bug here.  But I'd
be glad if I could understand.

>   It is just somewhat weird that some ARP requests are
> forwarded through bridge_output(), not through the usual code path.

Why do you think it is weird?  What make you think that it isn't taking
the "usual code path".  What is the "usual code path" for you?

> My question is who uses bridge_output()? Except one obscure case for
> sending back ICMP errors,

Why do you think it is an obscure case?

>   normally all local traffic should originate in the
> output() function of the underlying interface? Or am I missing something?

What do you mean by "local traffic"?  I thought your were talking about
forwarding?

The picture is as follow:

RECEIVING SENDING
(userland)   (userland)
  
  ^ |
 INCOMING (interrupt handler) | | 
 || |
 v  v
  if_input -> pseudo_input -> | STACK | -> if_output -> if_enqueue -> if_start
 ^
||
`->  | BRIDGE | -'

> If you think that my feature presents any interest, I can tidy it up and
> submit it. It splits BLOCKNONIP into BLOCKNONIPV4 and BLOCKNONIPV6. I need
> it because in my particular case IPv4 should be NATed and IPv6 should be
> switched as you cannot split IPv6 into arbitrary subnets below /64, so you
> have to keep it whole. It is the only way to route and filter both IPv4 and
> IPv6 traffic with one particular French broadband service provider but there
> could maybe be other uses for it.

I think it might be interesting, at least to better understand your uses
case and the possible bug/limitation in bridge(4).  

Re: Bridge and blocknonip

[Martin Pieuchot]

On 23/11/15(Mon) 12:57, Momtchil Momtchev wrote:
> [...]
> So here is my setup:
> 
> NETWORK A is a wired network with private IPv4/24 addr a public IPv6/64
> addr
> NETWORK B is a wireless network with private IPv4/24 addr a public
> IPv6/64 addr
> The Broadband equipment provides a single IPv4/32 public addr and a
> public IPv6 /64 addr (French broadband provider Free/Proxad)
> So the OpenBSD box (PC Engines APU) has one public IPv4/32 addr and one
> public IPv6 addr on a /64 network.
> 
> 
> NETWORK A <-> (re0) (bridge0) (re2) <-> Broadband equipment
> NETWORK B <-/  (athn0)
> 
> TV Decoder <-> (re0 vlan 100) (bridge1) (re2 vlan 100) <->  IPTV Server
> 
> 
> The only way I can manage this setup is by bridging the IPv6 traffic and
> routing/NATing the IPv4 traffic.
> So what I did, I started from the BLOCKNONIP code and made a bridge that
> passes only IPv6 traffic.
> This setup is very common in France and was working perfectly with my
> patch on OpenBSD 4.x.
> 
> There is a bridge0 with
> re0
> athn0
> re2 (modified blocknonip)
> 
> And a bridge1 with
> re2.100
> re0.100
> 
> Since I upgraded to 5.8 I found that IPv4 ARP requests were slipping
> through my version of blocknonip. This is a problem because the broadband
> equipment picks them up. When I started looking at the code, I found that
> ARP requests from NETWORK B (only from NETWORK B, never NETWORK A, don't
> know why, maybe because B doesn't have an IP address assigned) were being
> resent to the external network via new code path that didn't exist in
> 4.8/4.9. 

It's hard to discuss without seeing your "version of blocknonip".  But
still what have you seen?  You're still giving your conclusion instead
of what you observed.

Did you use tcpdump(8) on the interfaces?  What kind of ARP request are
we talking about here?  echo, reply?  Sent from which host?  To which
destination?

>  Also, ARP requests on the bridge1 are being resent to the bridge0.
> Those packets are being sent by bridge_output().

That seems to be a known regression on 5.8 because re(4) supports
hardware VLAN.  The problem is that bridge_input() is called before
vlan_input() for every packet received on a physical interface.  Since
the hardware have already removed the VLAN header you see it in bridge0.

This should be fixed in -current as long as you configure your pseudo
interfaces in the order you need:

# ifconfig bridge0 add re0
# ifconfig vlan0 vlan 100 vlandev re0

This way vlan_input() will run before bridge_input() and the packets
with a VLAN ID 100 wont enter bridge0

> Those packets are being sent by bridge_output(). These are not forwarded
> packets.

Which packets?  Sorry but I don't understand what kind of packets you're
talking about so I cannot help.

>  In my setup, receiving an ARP request from athn0 will spawn another
> ARP request on re0. Receiving an ARP request on re2.100 will spawn another
> request on re0 (besides forwarding the request to re0.100). That one does
> not feel very right even without my patch. So my questions were :
> 
> First of all, is bridge_output() used to forward packets now? Or is it
> only for local traffic? If it is sometimes used to forward packets, then a
> check against BLOCKNONIP would be needed? Reyk Floeter confirmed that it was
> used only for local traffic.

It is only used to send local traffic, just like Reyk said.

> Second, why bridge_output()? In my understanding output is never done
> directly on the bridge, it is always on one of the underlying interfaces?

Please look at the code, we write Free Software for a reason:
  http://bxr.su/search?q=bridge_output&defs=&refs=&path=&project=OpenBSD

> This could have implications for pf too?

I don't understand your question.  What could have implication?

>  From what I saw bridge_output() is
> used directly only in one obscure case for sending back ICMP errors.

Why do you think it's an obscure case?

>  But it
> is also the output function of the interface? This is why I have a hard time
> finding the origin of those ARP requests. So this is my real question, who
> sends ARP requests directly on the bridge via bridge_output()?

One do not find who send packets by looking at the code but by looking
at the packets.  Since the beginning of this thread we don't know the
content of the packets, so we don't if they are forwarded or not, if
they are multicast or not if they are addressed to the OpenBSD machine
or not, if they are reply to other packets: we know nothing.

Plus we don't know the output of your ifconfig nor which code you're
running.  Come on, if you want some help, let others help you ;)

Cheers,
Martin

Re: kernel panic - panic: ehci_device_clear_toggle: queue active

[Martin Pieuchot]

On 30/11/15(Mon) 18:28, Björn Ketelaars wrote:
> Hello,
> 
> I repeatedly hit the kernel panic below. Easy to reproduce as it happens over
> and over again within 60 minutes after rebooting. Root cause is not known.
> 
> I'm running snapshot on an USB stick. I tried different USB ports with the 
> same
> result. Next step will be an attempt with a different USB stick.
> 
> I think this issue has been mentioned before:
> 
> https://marc.info/?t=14184059141&r=1&w=3
> http://openbsd-archive.7691.n7.nabble.com/panic-ehci-device-clear-toggle-queue-active-td231729.html
> http://article.gmane.org/gmane.os.openbsd.bugs/19812/
> 
> Any ideas on how to tackle this issue?

You can try the diff below and tell me if it helps.

Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.187
diff -u -p -r1.187 ehci.c
--- ehci.c  26 Jun 2015 11:17:34 -  1.187
+++ ehci.c  14 Oct 2015 14:24:19 -
@@ -188,12 +188,11 @@ int   ehci_alloc_sitd_chain(struct ehci_s
 void   ehci_abort_isoc_xfer(struct usbd_xfer *xfer,
usbd_status status);
 
-usbd_statusehci_device_setintr(struct ehci_softc *, struct ehci_soft_qh *,
-   int ival);
+struct ehci_soft_qh * ehci_intr_get_sqh(struct usbd_pipe *);
 
-void   ehci_add_qh(struct ehci_soft_qh *, struct ehci_soft_qh *);
-void   ehci_rem_qh(struct ehci_softc *, struct ehci_soft_qh *);
-void   ehci_set_qh_qtd(struct ehci_soft_qh *, struct ehci_soft_qtd *);
+void   ehci_add_qh(struct usbd_pipe *, struct ehci_soft_qh *,
+   struct ehci_soft_qtd *);
+void   ehci_rem_qh(struct ehci_softc *, struct usbd_pipe *);
 void   ehci_sync_hc(struct ehci_softc *);
 
 void   ehci_close_pipe(struct usbd_pipe *);
@@ -413,7 +412,6 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(&sqh->dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
}
@@ -444,7 +442,6 @@ ehci_init(struct ehci_softc *sc)
sqh->qh.qh_qtd.qtd_next = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_altnext = htole32(EHCI_LINK_TERMINATE);
sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
-   sqh->sqtd = NULL;
usb_syncmem(&sqh->dma, sqh->offs, sizeof(sqh->qh),
BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD);
 
@@ -729,6 +726,7 @@ ehci_check_qh_intr(struct ehci_softc *sc
return;
}
  done:
+   ehci_rem_qh(sc, xfer->pipe);
TAILQ_REMOVE(&sc->sc_intrhead, ex, inext);
timeout_del(&xfer->timeout_handle);
usb_rem_task(xfer->pipe->device, &xfer->abort_task);
@@ -861,7 +859,7 @@ ehci_idone(struct usbd_xfer *xfer)
 {
struct ehci_xfer *ex = (struct ehci_xfer *)xfer;
struct ehci_soft_qtd *sqtd;
-   u_int32_t status = 0, nstatus = 0;
+   uint32_t status = 0, nstatus = 0;
int actlen, cerr;
 
 #ifdef DIAGNOSTIC
@@ -1171,13 +1169,7 @@ ehci_freex(struct usbd_bus *bus, struct 
 void
 ehci_device_clear_toggle(struct usbd_pipe *pipe)
 {
-   struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
-
-#ifdef DIAGNOSTIC
-   if ((epipe->sqh->qh.qh_qtd.qtd_status & htole32(EHCI_QTD_ACTIVE)) != 0)
-   panic("ehci_device_clear_toggle: queue active");
-#endif
-   epipe->sqh->qh.qh_qtd.qtd_status &= htole32(~EHCI_QTD_TOGGLE_MASK);
+   pipe->endpoint->savedtoggle = 0;
 }
 
 #ifdef EHCI_DEBUG
@@ -1374,29 +1366,17 @@ ehci_open(struct usbd_pipe *pipe)
struct usbd_device *dev = pipe->device;
struct ehci_softc *sc = (struct ehci_softc *)dev->bus;
usb_endpoint_descriptor_t *ed = pipe->endpoint->edesc;
-   u_int8_t addr = dev->address;
u_int8_t xfertype = ed->bmAttributes & UE_XFERTYPE;
struct ehci_pipe *epipe = (struct ehci_pipe *)pipe;
struct ehci_soft_qh *sqh;
usbd_status err;
-   int s;
-   int ival, speed, naks;
-   int hshubaddr, hshubport;
 
-   DPRINTFN(1, ("ehci_open: pipe=%p, addr=%d, endpt=%d\n",
+   DPRINTFN(1, ("%s: pipe=%p, addr=%d, endpt=%d\n", __func__,
pipe, addr, ed->bEndpointAddress));
 
if (sc->sc_bus.dying)
return (USBD_IOERROR);
 
-   if (dev->myhsport) {
-   hshubaddr = dev->myhsport->parent->address;
-   hshubport = dev->myhsport->portno;
-   } else {
-   hshubaddr = 0;
-   hshubport = 0;
-   }
-
/* Root Hub */
if (pipe->device->depth == 0) {
switch (ed->bEndpointAddress) {
@@ -1412,55 +1392,11 @@ ehci_open(struct usbd_pipe *pipe)
retur

Re: Add Bay Trail EHCI controller to pcidevs

[Martin Pieuchot]

On 06/12/15(Sun) 20:44, Callum Davies wrote:
> Doesn't work, but at least it makes the dmesg look better.

What doesn't work?

> 
> Index: sys/dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1780
> diff -u -p -u -r1.1780 pcidevs
> --- sys/dev/pci/pcidevs 28 Nov 2015 14:11:33 -  1.1780
> +++ sys/dev/pci/pcidevs 6 Dec 2015 20:38:06 -
> @@ -3102,6 +3102,7 @@ product INTEL BAYTRAIL_LPA0x0f28  Bay Tr
>  product INTEL BAYTRAIL_IGD_1   0x0f31  Bay Trail Video
>  product INTEL BAYTRAIL_IGD_2   0x0f32  Bay Trail Video
>  product INTEL BAYTRAIL_IGD_3   0x0f33  Bay Trail Video
> +product INTEL BAYTRAIL_EHCI0x0f34  Bay Trail EHCI
>  product INTEL BAYTRAIL_XHCI0x0f35  Bay Trail xHCI
>  product INTEL BAYTRAIL_82370x0f40  Bay Trail I2C DMA
>  product INTEL BAYTRAIL_I2C_1   0x0f41  Bay Trail I2C

Re: 5.8: uvideo has support for Logitech QuickCam Pro 5000 but ugen0 attaches instead

[Martin Pieuchot]

On 03/01/16(Sun) 23:18, Matt Adams wrote:
> Hi,
> 
> I noted that uvideo has support for the Logitech QuickCam Pro 5000 - a piece
> of hardware that I have. However, ugen appears to attach to this device
> instead of allowing the special firmware (installed via "# fw_install
> uvideo") to configure /dev/video0 or /dev/video1, even though those two
> device files are present in the system.
> 
> For example:
> 
> -bash-4.3$ luvcview
> luvcview version 2.0
> Video driver: x11
> A window manager is available
> video /dev/video0
> ERROR opening V4L interface
> : Device not configured
> 
> Is there something that I am missing here or is my webcam not actually
> supported?

Could you paste the output of "lsusb -v" for your webcam?  lsusb(1) is
part of the usbutils package.

> 
> -bash-4.3$ ls -l /dev/video*
> lrwxr-xr-x  1 root  wheel 6 Dec 24 00:09 /dev/video -> video0
> crw-rw-rw-  1 root  wheel   44,   0 Dec 24 00:09 /dev/video0
> crw-rw-rw-  1 root  wheel   44,   1 Dec 24 00:09 /dev/video1
> 
> Thanks,
> 
> Matt
> 
> -- usbdevs -v below
> 
> Controller /dev/usb0:
> addr 1: high speed, self powered, config 1, EHCI root hub(0x),
> Intel(0x8086), rev 1.00
>  port 1 powered
>  port 2 powered
>  port 3 addr 2: high speed, self powered, config 1, product 0x2514(0x2514),
> Standard Microsystems(0x0424), rev 0.00
>   port 1 powered
>   port 2 powered
>  port 4 powered
> Controller /dev/usb1:
> addr 1: high speed, self powered, config 1, EHCI root hub(0x),
> Intel(0x8086), rev 1.00
>  port 1 powered
>  port 2 powered
>  port 3 powered
>  port 4 powered
>  port 5 addr 2: high speed, power 500 mA, config 1, QuickCam Pro
> 5000(0x08c5), Logitech(0x046d), rev 0.05, iSerialNumber 87C33093
>  port 6 powered
>  port 7 powered
>  port 8 powered
> Controller /dev/usb2:
> addr 1: full speed, self powered, config 1, UHCI root hub(0x),
> Intel(0x8086), rev 1.00
>  port 1 powered
>  port 2 addr 2: full speed, self powered, config 1, product 0x7000(0x7000),
> ATEN International(0x0557), rev 1.00
>   port 1 addr 3: low speed, power 100 mA, config 1, Type 6 Keyboard(0x0005),
> Fujitsu Component(0x0430), rev 1.02
>   port 2 powered
>   port 3 powered
>   port 4 powered
> Controller /dev/usb3:
> addr 1: full speed, self powered, config 1, UHCI root hub(0x),
> Intel(0x8086), rev 1.00
>  port 1 powered
>  port 2 powered
> Controller /dev/usb4:
> addr 1: full speed, self powered, config 1, UHCI root hub(0x),
> Intel(0x8086), rev 1.00
>  port 1 powered
>  port 2 powered
> Controller /dev/usb5:
> addr 1: full speed, self powered, config 1, UHCI root hub(0x),
> Intel(0x8086), rev 1.00
>  port 1 powered
>  port 2 powered
> Controller /dev/usb6:
> addr 1: full speed, self powered, config 1, UHCI root hub(0x),
> Intel(0x8086), rev 1.00
>  port 1 powered
>  port 2 addr 2: low speed, self powered, config 1, Back-UPS RS 1300 LCD
> FW:838.H5 .D USB FW:H5(0x0002), American Power Conversion(0x051d), rev 1.01,
> iSerialNumber JB0721002454
> Controller /dev/usb7:
> addr 1: full speed, self powered, config 1, UHCI root hub(0x),
> Intel(0x8086), rev 1.00
>  port 1 powered
>  port 2 powered
> 
> 
> -- dmesg below
> 
> OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 25739890688 (24547MB)
> avail mem = 24955904000 (23799MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xcf49c000 (85 entries)
> bios0: vendor Dell Inc. version "6.4.0" date 07/23/2013
> bios0: Dell Inc. PowerEdge T710
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST BERT
> EINJ SRAT TCPA SSDT
> acpi0: wakeup devices PCI0(S5) PCI1(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.46 MHz
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 132MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.00 MHz
> 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
>

Re: mbuf leak in carp with ipv6

[Martin Pieuchot]

On 05/01/16(Tue) 12:29, Håkon Lerring wrote:
> Hello misc.
> 
> I was investigating a problem with a firewall that goes AWOL every week. It
> happens only if i activate an ipv6 address on a carp interface. The carp log
> has this message:
> 
> Jan  5 12:10:06  /bsd: carp: packet size 48 too small
> 
> I think i have narrowed down the leak to the handling of too small
> ipv6-packets:
> 
> --- ip_carp.c.orig2016-01-05 12:18:03.0 +0100
> +++ ip_carp.c 2016-01-05 12:18:30.0 +0100
> @@ -562,6 +562,7 @@
>   if ((m = m_pullup(m, *offp + sizeof(*ch))) == NULL) {
>   carpstats.carps_badlen++;
>   CARP_LOG(LOG_INFO, sc, ("packet size %u too small", len));
> + m_freem(m);
>   return (IPPROTO_DONE);
>   }
>   ch = (struct carp_header *)(mtod(m, caddr_t) + *offp);
> 
> 
> I have not yet tested this patch since this is a production system. Why the
> other machine is sending incomplete packets is another question i'm currently
> investigating.

This is unlikely to be the leak you're chasing, m_pullup(9) frees the
mbuf for you in the error case.

> A meta-question: is this an appropriate channel for this or should i send such
> reports to bugs@?

bugs@ or tech@ if you have a diff.  In any case provide at least the
informations described in sendbug(1), because it's impossible to know
which version you're running for example, what's your setup, when does
this happens, etc.

Re: 5.8: uvideo has support for Logitech QuickCam Pro 5000 but ugen0 attaches instead

[Martin Pieuchot]

On 05/01/16(Tue) 13:19, Matt Adams wrote:
> On 05/01/16 05:10 AM, Martin Pieuchot wrote:
> >On 03/01/16(Sun) 23:18, Matt Adams wrote:
> >>Hi,
> >>
> >>I noted that uvideo has support for the Logitech QuickCam Pro 5000 - a piece
> >>of hardware that I have. However, ugen appears to attach to this device
> >>instead of allowing the special firmware (installed via "# fw_install
> >>uvideo") to configure /dev/video0 or /dev/video1, even though those two
> >>device files are present in the system.
> >>
> >>For example:
> >>
> >>-bash-4.3$ luvcview
> >>luvcview version 2.0
> >>Video driver: x11
> >>A window manager is available
> >>video /dev/video0
> >>ERROR opening V4L interface
> >>: Device not configured
> >>
> >>Is there something that I am missing here or is my webcam not actually
> >>supported?
> >Could you paste the output of "lsusb -v" for your webcam?  lsusb(1) is
> >part of the usbutils package.
> 
> lsusb -v as follows (webcam portion only):
> 
> Bus 001 Device 002: ID 046d:08c5 Logitech, Inc. QuickCam Pro 5000
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 1
>   bMaxPacketSize064
>   idVendor   0x046d Logitech, Inc.
>   idProduct  0x08c5 QuickCam Pro 5000

Thanks, does the diff below help?

Index: uvideo.c
===
RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
retrieving revision 1.183
diff -u -p -r1.183 uvideo.c
--- uvideo.c20 Dec 2015 10:08:05 -  1.183
+++ uvideo.c6 Jan 2016 09:14:05 -
@@ -382,6 +382,12 @@ struct uvideo_devs {
NULL,
UVIDEO_FLAG_VENDOR_CLASS
},
+   {   /* Incorrectly reports as bInterfaceClass=UICLASS_VENDOR */
+   { USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_QUICKCAMPRO5K_1 },
+   NULL,
+   NULL,
+   UVIDEO_FLAG_VENDOR_CLASS
+   },
 };
 #define uvideo_lookup(v, p) \
((struct uvideo_devs *)usb_lookup(uvideo_devs, v, p))

Re: 5.8: uvideo has support for Logitech QuickCam Pro 5000 but ugen0 attaches instead

[Martin Pieuchot]

On 06/01/16(Wed) 10:17, Martin Pieuchot wrote:
> On 05/01/16(Tue) 13:19, Matt Adams wrote:
> > On 05/01/16 05:10 AM, Martin Pieuchot wrote:
> > >On 03/01/16(Sun) 23:18, Matt Adams wrote:
> > >>Hi,
> > >>
> > >>I noted that uvideo has support for the Logitech QuickCam Pro 5000 - a 
> > >>piece
> > >>of hardware that I have. However, ugen appears to attach to this device
> > >>instead of allowing the special firmware (installed via "# fw_install
> > >>uvideo") to configure /dev/video0 or /dev/video1, even though those two
> > >>device files are present in the system.
> > >>
> > >>For example:
> > >>
> > >>-bash-4.3$ luvcview
> > >>luvcview version 2.0
> > >>Video driver: x11
> > >>A window manager is available
> > >>video /dev/video0
> > >>ERROR opening V4L interface
> > >>: Device not configured
> > >>
> > >>Is there something that I am missing here or is my webcam not actually
> > >>supported?
> > >Could you paste the output of "lsusb -v" for your webcam?  lsusb(1) is
> > >part of the usbutils package.
> > 
> > lsusb -v as follows (webcam portion only):
> > 
> > Bus 001 Device 002: ID 046d:08c5 Logitech, Inc. QuickCam Pro 5000
> > Device Descriptor:
> >   bLength18
> >   bDescriptorType 1
> >   bcdUSB   2.00
> >   bDeviceClass0 (Defined at Interface level)
> >   bDeviceSubClass 0
> >   bDeviceProtocol 1
> >   bMaxPacketSize064
> >   idVendor   0x046d Logitech, Inc.
> >   idProduct  0x08c5 QuickCam Pro 5000
> 
> Thanks, does the diff below help?

Could you test the diff?  Does it work?

> Index: uvideo.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
> retrieving revision 1.183
> diff -u -p -r1.183 uvideo.c
> --- uvideo.c  20 Dec 2015 10:08:05 -  1.183
> +++ uvideo.c  6 Jan 2016 09:14:05 -
> @@ -382,6 +382,12 @@ struct uvideo_devs {
>   NULL,
>   UVIDEO_FLAG_VENDOR_CLASS
>   },
> + {   /* Incorrectly reports as bInterfaceClass=UICLASS_VENDOR */
> + { USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_QUICKCAMPRO5K_1 },
> + NULL,
> + NULL,
> + UVIDEO_FLAG_VENDOR_CLASS
> + },
>  };
>  #define uvideo_lookup(v, p) \
>   ((struct uvideo_devs *)usb_lookup(uvideo_devs, v, p))

Re: permanent ARP being overwritten by ISP

[Martin Pieuchot]

On 16/01/16(Sat) 18:40, Doug Moss wrote:
> (my apologies for last message - unfamiliar with Yahoo and forcing plain text 
> email)
> 
> Why is a manually entered permanent arp entry being overwritten?

It should not, are you running -current?  If not could you try?

> 
> At my home, I have an ISP from which I have 5 static IPv4 addresses.
> I use these for my home network, a home email server, jabber server for 
> family/friends,
> website related to my academic work, etc, with different domains.
> 
> 
> The ISP service comes into my home via an ethernet cable which I connect to a 
> switch
> (Cisco gigabit)
> 
> Connected to the switch are:
> (A) router to my home network (behind which are desktops, a wireless access 
> point, kids laptops, etc)
>  a low-power, dual NIC OpenBSD amd64 running NAT and unbound (caching)
>  with IP address 70.20.25.26
> (B) the academic website
>  a low-power, OpenBSD 5.7 amd64
>  with IP address 70.20.25.30
> (plus other servers)
> 
> The ISP gateway/router is IP address 70.20.25.1
> 
> On the academic website, I noticed that the arp table
> showed 70.20.25.26 with the MAC of the ISP gateway
> 
> I thought - why should my private traffic from my personal webserver be routed
> through the ISP gateway - why not go directly to my home network on the same 
> switch?
> 
> So on my webserver, I did this:
> # sudo arp -s 70.20.25.26 00:25:90:0A:69:B6 permanent
> 
> Then I checked:
> # arp -an
> Host Ethernet Address   Netif Expire Flags
> 70.20.25.1   fa:c0:01:75:98:cdem0 19m59s 
> 70.20.25.26  00:25:90:0a:69:b6em0 permanent 
> 70.20.25.30  00:25:90:ea:52:9cem0 permanent  l
> 
> The next day, I found this is the logs:
> Jan 12 08:17:54 www /bsd: arp info overwritten for 70.20.25.26 by 
> 00:25:90:0a:69:b6 on em0
> Jan 12 08:17:54 www /bsd: arp info overwritten for 70.20.25.26 by 
> fa:c0:01:75:98:cd on em0
> Jan 12 08:37:54 www /bsd: arp info overwritten for 70.20.25.26 by 
> 00:25:90:0a:69:b6 on em0
> Jan 12 08:37:54 www /bsd: arp info overwritten for 70.20.25.26 by 
> fa:c0:01:75:98:cd on em0
> Jan 12 08:57:54 www /bsd: arp info overwritten for 70.20.25.26 by 
> 00:25:90:0a:69:b6 on em0
> Jan 12 08:57:54 www /bsd: arp info overwritten for 70.20.25.26 by 
> fa:c0:01:75:98:cd on em0
> (repeated a couple hundred times)
> 
> $ arp -an
> Host Ethernet Address   Netif Expire Flags
> 70.20.25.1   fa:c0:01:75:98:cdem0 19m54s 
> 70.20.25.26  fa:c0:01:75:98:cdem0 17m15s 
> 70.20.25.30  00:25:90:ea:52:9cem0 permanent  l
> 
> and
> $ traceroute 70.20.25.26
> traceroute to 70.20.25.26 (70.20.25.26), 64 hops max, 40 byte packets
> 1  lo0-100.BSTNMA-VFTTP-308.verizon-gni.net (70.20.25.1)  2.841 ms  0.594 ms  
> 3.724 ms
> 2  static-70-20-25-26.bstnma.fios.verizon.net (70.20.25.26)  3.544 ms  1.255 
> ms  3.593 ms
> 
> Am I understanding this correctly?
> Is the ISP gateway continuing to try to re-direct the arp table on my home 
> router
> to route traffic out to its gateway before coming back to my home network, 
> instead of
> directly from my router to the other server connected to ports on the same 
> switch?
> 
> 
> Have I done something wrong in my configuration?
> 
> Is this (a) expected (b) strange but innocent (c) nefarious, or (d) something 
> else?

Re: permanent ARP being overwritten by ISP

[Martin Pieuchot]

On 20/01/16(Wed) 00:11, Doug Moss wrote:
> [...]
> Second - per other reply. I upgraded from OpenBSD 5.7 amd64 to OpenBSD 5.8 
> amd64 yesterday

If you're referring to my reply, I was interested in the behavior in a
-current kernel, what will be 5.9 soon.  A lot of changes happened
since 5.8.

It would be nice if you could also post the output of "route -n show -inet"
with such kernel.

Re: 5.9-beta upgrade stalled at base59.tgz 98% fetched, 51072 KB on first try, retry succeeds

[Martin Pieuchot]

On 18/01/16(Mon) 18:39, Peter N. M. Hansteen wrote:
> For about the last week, I've been seeing this oddity with the amd64
> installer when doing snap to snap upgrades on my laptop.
> 
> My routine for quite a while has been to fetch snapshots off the local
> mirror whenever I notice there's a new one, recently about once a day,
> then installing by booting the new bsd.rd and pointing at the local
> directory for sets. This is a procedure that has just worked(TM) for years.
> 
> But as I mentioned earlier, for about the last week the installer has
> consistently stalled at base59.tgz 98%, 51072 KB fetched, and stayed
> that way for long enough that I'd Ctrl-C out to the bsd.rd shell and
> restart by typing 'upgrade' at the prompt. The upgrade then proceeds
> with no issues on the second attempt. That is, on the previous attempts
> over the last few days I've usually opted for the http (most local
> mirror) as the source for sets.
> 
> Then for today's snapshot, I downloaded only the bsd.rd, booted from
> that and did a http install, only to see base59.tgz stall again at the
> exact same spot. Ctrl-C and upgrade worked, just like the previous attempts.
> 
> Is anybody else seeing this or something similar?

I saw that a couple of times upgrading a macppc some months ago.

Re: VAX - are we dropping support in 5.9?

[Martin Pieuchot]

On 25/01/16(Mon) 15:24, Bryan C. Everly wrote:
> [...] 
> Please let me know and I'll do what I can do help.

The best advice I can give you is do something that you care about so
that you don't need anybody else to tell you what to do.  If you want
to maintain an architecture you need to run it first then understand
it somehow.

But if you don't know what to do you'll have to find out.

Now taking part of OpenBSD's development process might be a first step.
It is in any case required to contribute.  It's not too hard and well
documented:

  - follow -current
  - reports bugs and/or regressions on bugs@
  - read and tests diff on tech@, ports@ and/or www@

If you keep doing that you'll certainly learn something (I learn a lot
every days) and maybe one day you'll be sending a diff asking for
reviews.

Re: No keymap selection on macppc -current from Feb 8.

[Martin Pieuchot]

On 09/02/16(Tue) 23:28, Christoph R. Murauer wrote:
> Hello !
> 
> Sorry if the format of the message is not, as it should be.
> 
> I tried today the latest snapshot on a PowerMac G5. The installation worked 
> without problems but at the installer the first question about to choose the 
> keymap is missing.
> 
> It is possible to set the keymap after login using kbd de or  wsconsctl 
> keyboard.encoding=de but the setting is gone after a reboot.
> 
> Thanks for ideas.

You can simply do

# echo de > /etc/kbdtype

This is documented in kbd(8) feel free to check it ;)

Martin

Re: Current #189 Nov 1 panic ONLY at first boot.

[Martin Pieuchot]

Hello,

On 01/11/17(Wed) 13:38, Christoph R. Murauer wrote:
> I think I miss some informations for a bug report so, I post here.
> 
> I did a upgrade from a snapshot (which was a clean install 2 or 3 days
> ago) and also a clean install of this snapshot (booth with
> install62.fs instead of bsd.rd). The result was in booth cases a panic
> and I ended in ddb. But this happened only at the first boot - not on
> following boots.
> 
> I have at boot time no internet connection as the script tries to
> download the firmware. The bug happened also only with that snapshot
> and with none before (there I had also no internet connection).
> 
> ddb trace and ddb boot reboot messages (with ps) as pictures are here
> 
> http://www.nawi.is/images/trace.jpg
> http://www.nawi.is/images/boot.jpg

This has been fixed already, please updated from source or wait for the
next snapshot.

Re: Network stack 'lock' / single-thread

[Martin Pieuchot]

On 05/11/17(Sun) 09:39, Mihai Popescu wrote:
> [...] 
> This is rather a tech@ question but i'm not high enough for that list.
> I see some articles about the fact the network stack in OpenBSD is
> locked or single threaded. IT may be the same thing, i don't really
> know.
> 
> Can anyone share some light for this topic, at some beginner level?
> What is that 'lock' actually? Does it mean it can only be modified by
> a single thread at the time?
> Will multithread make things faster for the case where there is only
> one physical interface in a computer?

It means that if multiple CPUs want to process network packet (sending
and/or receiving) or access network data structure (interfaces, routes,
addresses, etc) at the same time they will be serialized by the NET_LOCK().

Serialized mean that the second CPU will start executing code in the
Network Stack as soon as the first one is "finished" with its current
task.  So there's currently no parallelism *inside* the Network Stack.

However some parts of the Network Stack, the IP layer for example, can
be executed in parallel of the rest of the kernel.  That's because it
doesn't run with the KERNEL_LOCK().

We're now working on using two threads to process packets.  Diffs are
floating around among developers and give some nice performance boost.

Other developers are working [0] on letting read data access, most of
ifconfig(8) for example, be able to be executed in parallel of packet
processing.

Stay tuned!

[0] https://marc.info/?l=openbsd-cvs&m=150981473127558&w=2

Re: Network stack 'lock' / single-thread

[Martin Pieuchot]

On 05/11/17(Sun) 09:32, Karsten Horsmann wrote:
> [...] 
> The nice FAQ told use that openbsd pf don't benefits much from smp.

That's wrong.

> So I assume that's an more single thread processing for pf.

It's multiple threads but they don't run in parallel.

> I also guess that it is the "keep it simple and then more secure" idea
> behind that rules openbsd as main goal.

Wrong guess.  It "just" has to be done.  Something we've been working on
for years now and it'll come soon.

Re: odd problem with etherip(4)

[Martin Pieuchot]

On 10/11/17(Fri) 20:22, Peter J. Philipp wrote:
> Hi,
> 
> I have an etherip(4) interface in down state, yet I still receive carp's
> through it.  I don't know how that's possible...
> 
> beta# ifconfig etherip0
> etherip0: flags=8902 mtu 1500
> lladdr fe:e1:ba:db:a8:15
> index 35 priority 0 llprio 3
> groups: etherip
> media: Ethernet autoselect
> status: active
> tunnel: inet 10.100.100.1 -> 10.100.100.4
> beta# tcpdump -v -n -i etherip0 -e 
> tcpdump: listening on etherip0, link-type EN10MB
> 20:13:49.199695 00:00:5e:00:01:01 01:00:5e:00:00:12 0800 70: carp 172.16.65.6 
> > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=0 demote=0 (DF) 
> [tos 0x10] (ttl 255, id 43499, len 56)
> 20:13:49.199707 00:00:5e:00:01:01 01:00:5e:00:00:12 0800 70: carp 172.16.65.6 
> > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=0 demote=0 (DF) 
> [tos 0x10] (ttl 255, id 43499, len 56)
> ^C
> 2 packets received by filter
> 0 packets dropped by kernel
> 
> The MAC addresses seem wrong they are usually fe:e1:ba:d... something.
> 
> My setup is 2 vmm's having etherip(4)'s to the main host, which is bridged
> to a vether(4) with an IP.  It looks a little like a tuning fork:
> 
> (carptest1 vmm)--\
> )-bridge(vether if)
> (carptest2 vmm)--/
> 
> The reason that I can't get a preempt or MASTER->BACKUP to take place is
> because somehow these CARP advertisings make it through even though the
> int is in down state.
> 
> It looks wrong to me.  Can someone concurr?

It looks like an incomplete bug report to me.  Creating frustration on
both the reporter side and the developer side.  Dmesg, full ifconfig
output and an mail to bugs@.

Re: renice and network forwarding

[Martin Pieuchot]

On 03/12/17(Sun) 21:13, Tom Smyth wrote:
> Hello all,
> 
> just wondering if anyone else has tried using renice to
> de-prioritise other processes in an effort to give more cpu
> time to packet forwarding in the kernel ?

The thread responsible for processing packets being forwarded is
'softnet'.  Like almost all others kernel threads is has a higher
priority than userland processes.  So renice is useless in that case.

This thread already uses as much CPU time as possible.  What is your
problem?  What do you want to achieve?

> While Im certain that there significant risks to system stability
> and other functionality of the system if one were to carpet bomb
> the process list pids with renice 20. Perhaps the current defaults
> are for general purpose systems ? Perhaps  other network
> Administrators have tweaked background processes where a system
> was a single purpose system such as a Router, Firewall or Bridge.

There's no such performance tweak.  However note that if you're
bridging interfaces you might suffer.  That's because nobody did
the work to take the bridge(4) out of the KERNEL_LOCK().  So it's
a totally different issue than the forwarding path.

> Also is the softnet process (as seen by  command top -SH)  only
> interrupt handling of packets ?

It's processing all incoming packets.

>  or does it cover processing (e.g. forwarding if enabled ) (either
> bridging or routing depending on network config)

All of them but some configurations work better because they don't
require to grab the KERNEL_LOCK().

> any advice  welcome ...

What do you want to achieve?  Better performances?  With which setup?

Cheers,
Martin

Re: help updating EHCI driver

[Martin Pieuchot]

On 05/12/17(Tue) 18:48, Paul B. Henson wrote:
> I'm trying to port some quirks for AMD USB chipsets from other operating
> systems to OpenBSD to hopefully resolve issues I am having with the pc
> engines APU3 EHCI ports, as they seem to work fine on those systems.

Which issue are you having?  What makes you think that the quirks below
will help?  What do you mean with 'work fine on those systems'?  If they
work fine, which issues are you having?

> I've got a pretty rough draft of one of them, which disables low-power
> mode during transfers, but would appreciate a little clarification on
> device I/O as I'm not generally a device driver developer.
> 
> Under Linux, the kernel uses absolute addresses when it's doing port I/O
> to a device, so that's what I am referencing in their implementation. In
> OpenBSD I see that a driver maps a handle to a region of memory and then
> uses offsets from the base of that region for port I/O. It looks like
> the EHCI driver code has already mapped that region and the handle is
> available for me to use, but I don't see where that mapping was made or
> how to figure out what the base was in order to turn the absolute
> addresses I have into appropriate offsets to use with the openbsd API?
> 
> Then, for some of the chipsets, in addition to poking at the USB device
> itself to twiddle the low-power mode, you also have to muck with the
> northbridge configuration. I think I gathered the device information,
> although I don't know that was the correct way to do so; but I need to
> map the I/O region for it to a handle so I can modify it. If a driver for
> one device needs to write to a different device is it supposed to call
> bus_space_map on its own to get a mapping, or can it somehow get access
> to the existing one already in place for that device?

It depends how the controller is connected to the host.  If you look at
the PCI glue driver, dev/pci/ehci_pci.c you'll see 

115:/* Map I/O registers */
116:if (pci_mapreg_map(pa, PCI_CBMEM, PCI_MAPREG_TYPE_MEM, 0,
117:   &sc->sc.iot, &sc->sc.ioh, NULL, &sc->sc.sc_size, 0)) 

Then in the EHCI driver, dev/usb/ehci.c, these are accessed via the
EREAD/EWRITE/EOREAD/EOWRITE macros.

But maybe you just want to use pci_conf_read()/pci_conf_write()?

> Finally, low power mode is supposed to be disabled whenever there are
> asynchronous transfers occurring, and then re-enabled once they
> complete. I'm not sure I've put the calls in the right place, and I know
> I haven't handled the case where transfers fail or are canceled  rather
> than complete.

Is low power mode enabled on OpenBSD?

> The other quirk involves never having an empty frame list; I have
> implemented the logic to detect when that is required, but haven't even
> come close to wrapping my head around actually implementing the quirk
> itself.

For which transfer type is this quirk required, isochronous only?

> In any case, here is my current laughable diff, advice and corrections
> most appreciated.

Thanks for sending a diff.  Don't hesitate to send them to tech@ next
time.

Comments inline.

> Index: pci/ehci_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/ehci_pci.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 ehci_pci.c
> --- pci/ehci_pci.c20 Jul 2016 09:48:06 -  1.30
> +++ pci/ehci_pci.c6 Dec 2017 02:46:24 -
> @@ -66,6 +66,8 @@ struct ehci_pci_softc {
>  };
>  
>  int ehci_sb700_match(struct pci_attach_args *pa);
> +int ehci_amd_pll_quirk_match(struct pci_attach_args *pa);
> +int ehci_amd_pll_quirk_match_nb(struct pci_attach_args *pa);
>  
>  #define EHCI_SBx00_WORKAROUND_REG0x50
>  #define EHCI_SBx00_WORKAROUND_ENABLE (1 << 3)
> @@ -111,6 +113,7 @@ ehci_pci_attach(struct device *parent, s
>   char *devname = sc->sc.sc_bus.bdev.dv_xname;
>   usbd_status r;
>   int s;
> + struct pci_attach_args amd_pa;
>  
>   /* Map I/O registers */
>   if (pci_mapreg_map(pa, PCI_CBMEM, PCI_MAPREG_TYPE_MEM, 0,
> @@ -131,6 +134,86 @@ ehci_pci_attach(struct device *parent, s
>  
>   /* Handle quirks */
>   switch (PCI_VENDOR(pa->pa_id)) {
> + case PCI_VENDOR_AMD:
> + /* AMD errata indicates 8111 chipset EHCI is broken */
> + if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_8111_EHCI) {
> + printf("%s: AMD 8111 EHCI broken, skipping", devname);
> + goto disestablish_ret;

If it is broken we should not match it.  That means ehci_pci_match()
should contain a check for this model an return 0 instead of 1.

This could be a diff on its own, but please make sure to give a
reference for where you found the piece of information.  A vendor
document is always the best, does it exist an errata for this chip?
At least the Linux commit hash such that it makes reviewer life easy ;)


> + if (pci_find_device(&amd_pa, ehci_amd_pll_quirk_match)) {
> + sc-

Re: cannot destroy loXX belonging to rdomain XX ?

[Martin Pieuchot]

On 14/02/18(Wed) 04:01, Jiri B wrote:
> How to "remove" loXX belong to rdomain XX ?
> 
> # ifconfig vether55 rdomain 55
> # ifconfig vether55   
>   
> 
> vether55: flags=8802 rdomain 55 mtu 1500
> lladdr fe:e1:ba:d6:a0:59
> index 23 priority 0 llprio 3
> groups: vether
> media: Ethernet autoselect
> status: active
> # ifconfig vether55 destroy
> # ifconfig lo55   
>   
> 
> lo55: flags=8049 rdomain 55 mtu 32768
> index 24 priority 0 llprio 3
> groups: lo
> inet6 ::1 prefixlen 128
> inet 127.0.0.1 netmask 0xff00
> inet6 fe80::1%lo55 prefixlen 64 scopeid 0x18
> # ifconfig lo55 destroy
> ifconfig: SIOCIFDESTROY: Operation not permitted
> 
> From lo(4):
> 
> ...
>  A loop interface can be created at runtime using the ifconfig loN create
>  command or by setting up a hostname.if(5) configuration file for
>  netstart(8).  The lo0 interface will always exist and cannot be destroyed
>  using ifconfig(8).
> ...
> 
> So it will exists forever till next reboot?

Yes, it's a current limitation of the rdomain <-> loopback
implementation.

Re: Still having super slow speeds with USB 3 flash.

[Martin Pieuchot]

On 27/03/18(Tue) 18:07, Kevin Chadwick wrote:
> It seems there may be a speed issue of some kind. A past thread
> mentions raw devices being fast but doesn't ntfs-3g use raw access.

raw USB speeds are faster but not fast on OpenBSD.

> ntfs-3g is the slowest then msdos gets around 2200 Kilobytes/s.

ntfs-3g uses fuse(4) which has its own performance issues.

> The same msdos stick gets 12000 Kilobytes/s on Win 10.

msdosfs has also known performance issues.

> FFS is faster. Strange to me that usb hdd have always been fast with
> any filesystem. I will try a ntfs-3g usb hdd on a recent snapshot.

The speed of USB devices my vary a *lot* as well.

So to resume the situation you have at least 3 different subsystems
where performance could be improved on top of pieces of hardware of
different quality.

Everything can be improved, it's a matter of dedication ;)  But make
sure you don't compare oranges to apples.

Re: X: WaitForSomething(): poll: Invalid argument

[Martin Pieuchot]

On 04/04/18(Wed) 12:02, Stephane HUC "PengouinBSD" wrote:
> Hi all.
> 
> How can identify what trouble X?
> I run OpenBSD 6.3 - amd64 on my laptop Dell Alienware 13.
> 
> Something fill both logs:
> - /var/log/Xorg.0.log
> - /var/log/xenodm.log
> 
> with this repeated message : "WaitForSomething(): poll: Invalid argument"
> 
> I use a custom xorg.conf, as:

Can you see the problem if you remove your custom xorg.conf?

Re: current/macppc on Mac Mini

[Martin Pieuchot]

On 26/12/12(Wed) 20:54, Miod Vallat wrote:
> > Just upgraded to a current again, with the same problem,
> > and the same solution:
> 
> [...]
> > wdc1 at kauaiata0 irq 39: DMA
> > atapiscsi0 at wdc1 channel 0 drive 0
> > scsibus0 at atapiscsi0: 2 targets
> > cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom 
> > removable
> > wd0 at wdc1 channel 0 drive 1: 
> > wd0: 16-sector PIO, LBA, 76319MB, 156301488 sectors
> [...]
> > bootpath: /pci@f400/ata-6@d/disk@1:/bsd
> 
> I think I understand what goes wrong. The code responsible for matching
> the boot device to the actual kernel device on macppc is quite crude,
> especially for non-SCSI disks.
> 
> Your bootpath specifies `disk@1' because the disk drive is the second
> device (slave) on the ATA channel, the cdrom drive being master.
> However, the kernel wants to match this information against a `wd1'
> device (as if there were two hard disks on the ATA channel).
> 
> The kernel code needs to be fixed to use device_register() to match the
> boot path against actual attachment information, instead of walking the
> device tree at the end of autoconf. If nobody beats me to do this, I'll
> try to cook a diff in a few days.

Were you thinking of something like that? It works for me (c) tm, with
my PowerBooks (disk@0/wd0), I haven't tried NFS boot yet.

Jan, does it improve something for you?

Index: autoconf.c
===
RCS file: /cvs/src/sys/arch/macppc/macppc/autoconf.c,v
retrieving revision 1.39
diff -u -p -r1.39 autoconf.c
--- autoconf.c  11 Nov 2010 17:58:21 -  1.39
+++ autoconf.c  22 May 2013 19:00:45 -
@@ -68,7 +68,7 @@
 
 void   dumpconf(void);
 static struct devmap *findtype(char **);
-void   makebootdev(char *cp);
+void   parseofwbp(char *);
 intgetpno(char **);
 
 /*
@@ -79,6 +79,9 @@ int   getpno(char **);
 intcold = 1;   /* if 1, still working on cold-start */
 char   bootdev[16];/* to hold boot dev name */
 struct device *bootdv = NULL;
+enum devclass bootdev_class = DV_DULL;
+intbootdev_type = 0;
+intbootdev_unit = 0;
 
 struct dumpmem dumpmem[VM_PHYSSEG_MAX];
 u_int ndumpmem;
@@ -165,9 +168,9 @@ findtype(char **s)
  *  '/ht@0,f200/pci@2/bcom5704@4/bsd'
  */
 void
-makebootdev(char *bp)
+parseofwbp(char *bp)
 {
-   int unit, ptype;
+   int ptype;
char   *dev, *cp;
struct devmap *dp;
 
@@ -184,6 +187,8 @@ makebootdev(char *bp)
} while((dp->type & T_IFACE) == 0);
 
if (dp->att && dp->type == T_IFACE) {
+   bootdev_class = DV_IFNET;
+   bootdev_type = dp->type;
strlcpy(bootdev, dp->dev, sizeof bootdev);
return;
}
@@ -193,24 +198,9 @@ makebootdev(char *bp)
ptype = dp->type;
dp = findtype(&cp);
if (dp->att && dp->type == T_DISK) {
-   unit = getpno(&cp);
-   if (ptype == T_SCSI) {
-   struct device *dv;
-   struct sd_softc *sd;
-
-   TAILQ_FOREACH(dv, &alldevs, dv_list) {
-   if (dv->dv_class != DV_DISK ||
-   strcmp(dv->dv_cfdata->cf_driver->cd_name, 
"sd"))
-   continue;
-   sd = (struct sd_softc *)dv;
-   if (sd->sc_link->target != unit)
-   continue;
-   snprintf(bootdev, sizeof bootdev,
-   "%s%c", dv->dv_xname, 'a');
-   return;
-   }
-   }
-   snprintf(bootdev, sizeof bootdev, "%s%d%c", dev, unit, 'a');
+   bootdev_class = DV_DISK;
+   bootdev_type = ptype;
+   bootdev_unit = getpno(&cp);
return;
}
printf("Warning: boot device unrecognized: %s\n", bp);
@@ -239,25 +229,44 @@ getpno(char **cp)
 void
 device_register(struct device *dev, void *aux)
 {
+   const char *drvrname = dev->dv_cfdata->cf_driver->cd_name;
+   const char *name = dev->dv_xname;
+
+   if (bootdv != NULL || dev->dv_class != bootdev_class)
+   return;
+
+   switch (bootdev_type) {
+   case T_SCSI:
+   if (strcmp(drvrname, "sd") == 0) {
+   struct sd_softc *sd = (struct sd_softc *)dev;
+
+   if (sd->sc_link->target == bootdev_unit)
+   bootdv = dev;
+   }
+   case T_IDE:
+   /*
+* Do not require the bootpath unit number to match
+* against the driver's one, a slave disk on the ATA
+* channel `disk@1' can attach as `wd0'.
+*/
+   if (strcmp(drvrname, "wd") == 0)
+   bootdv = dev;
+   break;
+   case T_IFACE:
+   

Re: current/macppc on Mac Mini

[Martin Pieuchot]

On 23/05/13(Thu) 17:00, Miod Vallat wrote:
> > Were you thinking of something like that? It works for me (c) tm, with
> > my PowerBooks (disk@0/wd0), I haven't tried NFS boot yet.
> 
> Not exactly, but your version is probably better than what I was
> thinking of. However, it will not allow for root on the second wd disk
> of a controller, or on any secondary pciide controller.
> 
> Borrowing the sparc64 logic is a larger work but less error-prone.

Indeed it is, but until someone does it, here's a slightly improved
version that adds a check for the drive number.

Jan does is still work for you?

Index: macppc//autoconf.c
===
RCS file: /cvs/src/sys/arch/macppc/macppc/autoconf.c,v
retrieving revision 1.39
diff -u -p -r1.39 autoconf.c
--- macppc//autoconf.c  11 Nov 2010 17:58:21 -  1.39
+++ macppc//autoconf.c  29 May 2013 23:17:42 -
@@ -62,13 +62,12 @@
 
 #include 
 #include 
-#include 
 #include 
-#include 
+#include 
 
 void   dumpconf(void);
 static struct devmap *findtype(char **);
-void   makebootdev(char *cp);
+void   parseofwbp(char *);
 intgetpno(char **);
 
 /*
@@ -79,6 +78,9 @@ int   getpno(char **);
 intcold = 1;   /* if 1, still working on cold-start */
 char   bootdev[16];/* to hold boot dev name */
 struct device *bootdv = NULL;
+enum devclass bootdev_class = DV_DULL;
+intbootdev_type = 0;
+intbootdev_unit = 0;
 
 struct dumpmem dumpmem[VM_PHYSSEG_MAX];
 u_int ndumpmem;
@@ -165,9 +167,9 @@ findtype(char **s)
  *  '/ht@0,f200/pci@2/bcom5704@4/bsd'
  */
 void
-makebootdev(char *bp)
+parseofwbp(char *bp)
 {
-   int unit, ptype;
+   int ptype;
char   *dev, *cp;
struct devmap *dp;
 
@@ -184,6 +186,8 @@ makebootdev(char *bp)
} while((dp->type & T_IFACE) == 0);
 
if (dp->att && dp->type == T_IFACE) {
+   bootdev_class = DV_IFNET;
+   bootdev_type = dp->type;
strlcpy(bootdev, dp->dev, sizeof bootdev);
return;
}
@@ -193,24 +197,9 @@ makebootdev(char *bp)
ptype = dp->type;
dp = findtype(&cp);
if (dp->att && dp->type == T_DISK) {
-   unit = getpno(&cp);
-   if (ptype == T_SCSI) {
-   struct device *dv;
-   struct sd_softc *sd;
-
-   TAILQ_FOREACH(dv, &alldevs, dv_list) {
-   if (dv->dv_class != DV_DISK ||
-   strcmp(dv->dv_cfdata->cf_driver->cd_name, 
"sd"))
-   continue;
-   sd = (struct sd_softc *)dv;
-   if (sd->sc_link->target != unit)
-   continue;
-   snprintf(bootdev, sizeof bootdev,
-   "%s%c", dv->dv_xname, 'a');
-   return;
-   }
-   }
-   snprintf(bootdev, sizeof bootdev, "%s%d%c", dev, unit, 'a');
+   bootdev_class = DV_DISK;
+   bootdev_type = ptype;
+   bootdev_unit = getpno(&cp);
return;
}
printf("Warning: boot device unrecognized: %s\n", bp);
@@ -239,25 +228,43 @@ getpno(char **cp)
 void
 device_register(struct device *dev, void *aux)
 {
+   const char *drvrname = dev->dv_cfdata->cf_driver->cd_name;
+   const char *name = dev->dv_xname;
+
+   if (bootdv != NULL || dev->dv_class != bootdev_class)
+   return;
+
+   switch (bootdev_type) {
+   case T_SCSI:
+   if (strcmp(drvrname, "sd") == 0) {
+   struct scsi_attach_args *sa = aux;
+
+   if (sa->sa_sc_link->target == bootdev_unit)
+   bootdv = dev;
+   }
+   case T_IDE:
+   if (strcmp(drvrname, "wd") == 0) {
+   struct ata_atapi_attach *aa = aux;
+
+   if (aa->aa_drv_data->drive == bootdev_unit)
+   bootdv = dev;
+   }
+   break;
+   case T_IFACE:
+   if (strcmp(name, bootdev) == 0)
+   bootdv = dev;
+   break;
+   default:
+   break;
+   }
 }
 
-/*
- * Now that we are fully operational, we can checksum the
- * disks, and using some heuristics, hopefully are able to
- * always determine the correct root disk.
- */
 void
 diskconf(void)
 {
-   dev_t temp;
-   int part = 0;
-
printf("bootpath: %s\n", bootpath);
-   makebootdev(bootpath);
 
-   /* Lookup boot device from boot if not set by configuration */
-   bootdv = parsedisk(bootdev, strlen(bootdev), 0, &temp);
-   setroot(bootdv, part, RB_USERREQ);
+   setroot(bootdv, 0, RB_USERREQ);
dumpconf();
 }
 
Index: macppc//machdep.c
=

Re: Xorg (or suspend/resume) regression 2013-JUN-27 amd64 snapshot

[Martin Pieuchot]

Patrick,

Thanks for the report, it clearly looks like an xserver regression, but
next time don't hesitate to mail bugs@ instead.

On 11/07/13(Thu) 03:56, patrick keshishian wrote:
> [...]
> So after some investigating, this "crash" after suspend/resume cycle
> is actually an "abort" due to an assertion on xf86CursorScreenKeyRec
> not being initialized. Provided are a backtrace and print of said
> object[1].

Yep, I can reproduce the crash here by simply doing a console-switch
with the "SWcursor" option defined in my xorg.conf.  So this is not
something related to suspend/resume.

> What I see happen is RADEONCursorInit() fails[2], so
> xf86_cursors_init() never gets called, which would call
> xf86InitCursor(), which initializes the xf86CursorScreenKeyRec.

That's a first bug.  Since the last Xserver update, the radeon driver
is using EXA instead of XAA as acceleration methods, and there's
probably a bug here when trying to allocate some memory for your
hardware cursor.

> When RADEONCursorInit() fails, it logs the following and moves on:
> 
> [  2009.859] (EE) RADEON(0): Hardware cursor initialization failed
> [  2009.859] (II) RADEON(0): Using software cursor
> 
> Now, on resume (after a suspend), radeon_crtc_mode_commit() is invoked
> (see bt), and it calls xf86_reload_cursors(), which eventually causes
> the assert() and abort().

That looks like a second bug to me, should xf86_reload_cursors() be
called when using software cursor?  I leave that to matthieu@ but
in the meantime the diff below should work around your problem.

Index: radeon_crtc.c
===
RCS file: /home/ncvs/xenocara/driver/xf86-video-ati/src/radeon_crtc.c,v
retrieving revision 1.7
diff -u -p -r1.7 radeon_crtc.c
--- radeon_crtc.c   8 Aug 2012 16:25:22 -   1.7
+++ radeon_crtc.c   16 Jul 2013 11:57:23 -
@@ -502,8 +502,13 @@ radeon_crtc_mode_set(xf86CrtcPtr crtc, D
 static void
 radeon_crtc_mode_commit(xf86CrtcPtr crtc)
 {
-if (crtc->scrn->pScreen != NULL)
-   xf86_reload_cursors(crtc->scrn->pScreen);
+ScrnInfoPtr pScrn = crtc->scrn;
+RADEONInfoPtr info = RADEONPTR(pScrn);
+
+if (!xf86ReturnOptValBool(info->Options, OPTION_SW_CURSOR, FALSE)) {
+if (pScrn->pScreen != NULL)
+xf86_reload_cursors(pScrn->pScreen);
+}
 }
 
 void

Re: usb device works on amd64 but not i386

[Martin Pieuchot]

On 17/07/13(Wed) 14:07, Ryan Freeman wrote:
> Hey tech@,
> 
> i came across a uhid device (joystick adapter) I have that only
> seems to work on my amd64 desktop, but not i386 laptop.
> 
> amd64:
> usb1 at ohci0: USB revision 1.0
> uhub1 at usb1 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb2 at ohci1: USB revision 1.0
> uhub2 at usb2 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb3 at ohci2: USB revision 1.0
> uhub3 at usb3 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb4 at ohci3: USB revision 1.0
> uhub4 at usb4 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb5 at ohci4: USB revision 1.0
> uhub5 at usb5 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> *snip*
> uhidev1 at uhub2 port 2 configuration 1 interface 0 "vendor 0x product 
> 0x0667" rev 1.00/2.88 addr 2
> uhidev1: iclass 3/0
> uhid0 at uhidev1: input=6, output=0, feature=0
> 
> i386:
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb3 at uhci2: USB revision 1.0
> uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb4 at uhci3: USB revision 1.0
> uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> *snip*
> uhidev1 at uhub1 port 2 configuration 1 interface 0 "vendor 0x product 
> 0x0667" rev 1.00/2.88 addr 2
> uhidev1: no report descriptor
> 
> I have confirmed with 'another os' that the device works on this
> i386 machine so its not bad ports or anything.
> 
> I noticed in sys/dev/usb/uhidev.c there are notes about a
> broken descriptor for a waccom tablet, and in sys/dev/usb/usb.h
> a note for i386 using unaligned access for unaligned little-endian
> word components in usb records.
> 
> I guess my only question would be, am I looking in the right
> areas for something such as this? 

Hard to tell without a full dmesg... and what's the output of
"usbdevs -dv" on the two machines?

You can also trie "lsusb -v" from the usbutils package to see what
descriptors you get on both machines.

M.

Re: current/macppc with the new radeondrm

[Martin Pieuchot]

On 18/08/13(Sun) 19:33, Jan Stary wrote:
> Just upgraded my MacMini to current/macppc.
> As the snapshot contains base sets from Aug 17
> but the X sets are from July 22, I recompiled
> everything from current source after the upgrade
> to make sure everything is over the recent ABI change.

But you forgot to update your xenocara sources ;) You're still trying
to use a UMS driver with a KMS kernel :

> [  8330.185] (II) LoadModule: "radeon"
> [  8330.186] (II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.so
> [  8330.187] (II) Module radeon: vendor="X.Org Foundation"
> [  8330.187]  compiled for 1.14.1, module version = 6.14.6

Make sure you have the last xf86-video-ati update, module version should
say 7.2.0.

Martin

Re: uaudio0: audio descriptors make no sense, with Schiit Bifrost USB DAC

[Martin Pieuchot]

On 07/09/13(Sat) 12:17, Martijn Rijkeboer wrote:
> Hi,
> 
> I have a Schiit Bifrost USB DAC that includes an uaudio device for audio
> playback. When I plug the device in I'm getting "uaudio0: audio
> descriptors make no sense, error=4". Any suggestions on how to make this
> work?
> 
> Here are the relevant lines from usbdevs -v (debugging enabled for uaudio):

Looks like the audio descriptor of your device doesn't match what
uaudio(4) expects.  A quirk might be needed.  Could you please
install the usbutils package and post the output of "lsusb -v" for
your device?

Martin

Re: Help troubleshooting ehci_idone hang.

[Martin Pieuchot]

Hi Bob,

On 07/09/13(Sat) 08:14, RD Thrush wrote:
> Since appx. November, 2012, I've had 2 amd64 systems hang while
> spewing "ehci_idone: ex=0x80.. is done!" messages to the
> serial console.  The hangs are intermittent.  The system is
> unresponsive to the keyboard and doesn't respond to network ping.  A
> hardware reset is necessary to regain control.
> 
> In order to help troubleshoot, I patched /usr/src/sys/dev/usb/ehci.c
> to panic when the forementioned message had occurred 9 times and then
> built a custom kernel with EHCI_DEBUG defined.  In the past day, the
> new panic has occurred on the same machine with both an mp and sp
> kernel and I have collected basic ddb information as well as crash
> dumps.
> 
> Will the ddb results from my patch [below] help troubleshoot the hang?
> If so, the largish console logs, usbdevs, pcidump and acpidump are
> located at .
> 
> NB: ehcidebug=0 in the sp session, while ehcidebug=3 or 2 in the mp session.
> Setting ehcidebug=3 seemed to hang but I was able to interrupt ddb, set
> ehcidebug=2 and continue the ddb session.
> 
> I appreciate any help diagnosing this problem.

Thanks for this detailed bug report.

You're saying that you have 2 amd64 systems with the same problem but
I see only the dmesg for one machine, does the other has the same ehci
controller?

The problem you are seeing is related to the way ehci transfers are
aborted.  The abortion process is subtly broken.

For the archives what happens in your case is that the timeout for
one of the transfers fires and enqueue an abort task (ehci_timeout
in your log).  This abort task get scheduled tries to deactivate
the qTDs, asks for an Interrupt on Async Advance Doorbell and goes
to sleep (ehci_sync_hc in your log).
Then the interrupt happens (ehci_intr1: door bell), wakeups the
task and goes into the softinterrupt path to process the finished
transfers.  Here the driver discovers that the transfer that timed
out is finished (whoa!) and tries to handles it.  But since this 
transfer has been marked as TIMEOUT (ehci_idone: aborted in your
log), it does nothing and bails.  

Apparently the abort task never get rescheduled and your transfer
is never removed from the list, certainly because the hardware 
keeps interrupting your systems, so you're livelock ;)

But all of that happens because a timeout fires for one of your
transfers, apparently some ATI controllers needs one more quirk,
as your problem looks like a dropped interrupt.  Does the diff
below helps? 

Index: pci/ehci_pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/ehci_pci.c,v
retrieving revision 1.26
diff -u -p -r1.26 ehci_pci.c
--- pci/ehci_pci.c  15 Apr 2013 09:23:01 -  1.26
+++ pci/ehci_pci.c  10 Sep 2013 08:19:28 -
@@ -204,10 +204,16 @@ ehci_pci_attach(struct device *parent, s
else
snprintf(sc->sc.sc_vendor, sizeof(sc->sc.sc_vendor),
"vendor 0x%04x", PCI_VENDOR(pa->pa_id));
-   
+
/* Enable workaround for dropped interrupts as required */
-   if (sc->sc.sc_id_vendor == PCI_VENDOR_VIATECH)
+   switch (sc->sc.sc_id_vendor) {
+   case PCI_VENDOR_ATI:
+   case PCI_VENDOR_VIATECH:
sc->sc.sc_flags |= EHCIF_DROPPED_INTR_WORKAROUND;
+   break;
+   default:
+   break;
+   }
 
ehci_pci_takecontroller(sc, 0);
r = ehci_init(&sc->sc);
Index: usb/ehci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.134
diff -u -p -r1.134 ehci.c
--- usb/ehci.c  12 Jun 2013 11:42:01 -  1.134
+++ usb/ehci.c  10 Sep 2013 08:19:28 -
@@ -2943,11 +2943,11 @@ ehci_timeout_task(void *addr)
 }
 
 /*
- * Some EHCI chips from VIA seem to trigger interrupts before writing back the
- * qTD status, or miss signalling occasionally under heavy load.  If the host
- * machine is too fast, we we can miss transaction completion - when we scan
- * the active list the transaction still seems to be active.  This generally
- * exhibits itself as a umass stall that never recovers.
+ * Some EHCI chips from VIA / ATI seem to trigger interrupts before writing
+ * back the qTD status, or miss signalling occasionally under heavy load.
+ * If the host machine is too fast, we can miss transaction completion - when
+ * we scan the active list the transaction still seems to be active. This
+ * generally exhibits itself as a umass stall that never recovers.
  *
  * We work around this behaviour by setting up this callback after any softintr
  * that completes with transactions still pending, giving us another chance to

Re: uaudio0: audio descriptors make no sense, with Schiit Bifrost USB DAC

[Martin Pieuchot]

On 10/09/13(Tue) 08:17, Remco wrote:
> Martijn Rijkeboer wrote:
> 
> >>> I have a Schiit Bifrost USB DAC that includes an uaudio device for audio
> >>> playback. When I plug the device in I'm getting "uaudio0: audio
> >>> descriptors make no sense, error=4". Any suggestions on how to make this
> >>> work?
> >>>
> >>> Here are the relevant lines from usbdevs -v (debugging enabled for
> >>> uaudio):
> >>
> >> Looks like the audio descriptor of your device doesn't match what
> >> uaudio(4) expects.  A quirk might be needed.  Could you please
> >> install the usbutils package and post the output of "lsusb -v" for
> >> your device?
> > 
> > Below are the relevant lines of "lsusb -v". Before I ran lsusb I've
> > re-installed the system with current (i386).
> > 
> > Bus 000 Device 002: ID 0d8c:0319 C-Media Electronics, Inc.
> ...
> > Interface Descriptor:
> >   bLength 9
> >   bDescriptorType 4
> >   bInterfaceNumber0
> >   bAlternateSetting   0
> >   bNumEndpoints   1
> >   bInterfaceClass 1 Audio
> >   bInterfaceSubClass  1 Control Device
> >   bInterfaceProtocol 32
> >   iInterface  2 Schiit USB Audio Device
> >   AudioControl Interface Descriptor:
> > bLength 9
> > bDescriptorType36
> > bDescriptorSubtype  1 (HEADER)
> > --> bcdADC   2.00 <--
> 
> If I'm interpreting this correctly your device is an USB Audio 2.0 device.
> AFAICT there's currently no support for such a device in OpenBSD.

But it shouldn't be too hard to port the FreeBSD changes in our tree, if
anybody is motivated ;)

M.

Re: Help troubleshooting ehci_idone hang.

[Martin Pieuchot]

On 10/09/13(Tue) 07:15, RD Thrush wrote:
> On 09/10/13 04:42, Martin Pieuchot wrote:
> > [...]
> >
> > Thanks for this detailed bug report.
> > 
> > You're saying that you have 2 amd64 systems with the same problem but
> > I see only the dmesg for one machine, does the other has the same ehci
> > controller?
> 
> Apparently one is ATI and the other Intel.  
> <http://arp.thrush.com/openbsd/ehci_idone/v1/> has two console captures, 
> "v1.1" and "v1.2", for the other machine after an ehci_idone hang (I hadn't 
> made the panic patch yet).  I was able to generate a ddb interrupt to stop 
> the spew and gather some additional ddb info.  The forementioned directory 
> also has acpidump, pcidump, biosdecode, and dmidecode previously collected 
> from the same kernel.
> 
> If you want/need further info about the 'v1' machine, let me know and I'll 
> boot OpenBSD and get the info.

It would be nice if you could reproduce the manipulation you did with
the other machine and set ehcidebug to 5 before switching your kvm.

> > The problem you are seeing is related to the way ehci transfers are
> > aborted.  The abortion process is subtly broken.
> > 
> > For the archives what happens in your case is that the timeout for
> > one of the transfers fires and enqueue an abort task (ehci_timeout
> > in your log).  This abort task get scheduled tries to deactivate
> > the qTDs, asks for an Interrupt on Async Advance Doorbell and goes
> > to sleep (ehci_sync_hc in your log).
> > Then the interrupt happens (ehci_intr1: door bell), wakeups the
> > task and goes into the softinterrupt path to process the finished
> > transfers.  Here the driver discovers that the transfer that timed
> > out is finished (whoa!) and tries to handles it.  But since this 
> > transfer has been marked as TIMEOUT (ehci_idone: aborted in your
> > log), it does nothing and bails.  
> > 
> > Apparently the abort task never get rescheduled and your transfer
> > is never removed from the list, certainly because the hardware 
> > keeps interrupting your systems, so you're livelock ;)
> > 
> > But all of that happens because a timeout fires for one of your
> > transfers, apparently some ATI controllers needs one more quirk,
> > as your problem looks like a dropped interrupt.  Does the diff
> > below helps?
> 
> Thank you very much for the detailed analysis and patch.  I'll build a 
> -current kernel and try it.
> 
> Would there be a complementary patch for the (above) Intel ehci controller?

I'm not even sure this will avoid your problem, a proper fix would be to
stop trying to deactivate the transfer descriptors, as it obviously
doesn't work, and just remove them from the list.  Does anybody want to
take the time to do that? :)

Otherwise you can just buy a non crappy kvm ;)

M.

Re: Help troubleshooting ehci_idone hang.

[Martin Pieuchot]

On 11/09/13(Wed) 11:03, RD Thrush wrote:
> On 09/10/13 07:56, Martin Pieuchot wrote:
> > On 10/09/13(Tue) 07:15, RD Thrush wrote:
> >> On 09/10/13 04:42, Martin Pieuchot wrote:
> >>> [...]
> >>>
> >>> Thanks for this detailed bug report.
> >>>
> >>> You're saying that you have 2 amd64 systems with the same problem but
> >>> I see only the dmesg for one machine, does the other has the same ehci
> >>> controller?
> >>
> >> Apparently one is ATI and the other Intel.  
> >> <http://arp.thrush.com/openbsd/ehci_idone/v1/> has two console captures, 
> >> "v1.1" and "v1.2", for the other machine after an ehci_idone hang (I 
> >> hadn't made the panic patch yet).  I was able to generate a ddb interrupt 
> >> to stop the spew and gather some additional ddb info.  The forementioned 
> >> directory also has acpidump, pcidump, biosdecode, and dmidecode previously 
> >> collected from the same kernel.
> >>
> >> If you want/need further info about the 'v1' machine, let me know and I'll 
> >> boot OpenBSD and get the info.
> > 
> > It would be nice if you could reproduce the manipulation you did with
> > the other machine and set ehcidebug to 5 before switching your kvm.
> 
> With ehcidebug=5 on the v1 machine, switching the kvm resulted in a continual
> ddb loop,  I wasn't able to generate a ddb interrupt via the serial console;
> however, the pc keyboard was able to drop into ddb where I collected some
> additional info.
> 
> 'boot sync' resulted in the panic I'd patched (earlier in thread) to stop the
> initial hang.  I had to do a hard reset to regain control.
> 
> <http://arp.thrush.com/openbsd/ehci_idone/v1/v1-2> has the capture of the 
> serial
> console for that session.

Could you try the diff below on the v1 machine and tell me if it helps?

> WRT to the other machine, x4, I installed the patch and have not yet had a
> problem.  However, with ehcidebug=5, the following 2 line message is issued
> about once per second:
> ehci_intrlist_timeout
> ehci_check_intr: ex=0x80238c00

That's expected, thanks for confirming the problem cannot be reproduced
with this diff with an ATI controller.

Index: usbdi.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.58
diff -u -p -r1.58 usbdi.c
--- usbdi.c 6 Sep 2013 08:29:58 -   1.58
+++ usbdi.c 12 Sep 2013 08:47:09 -
@@ -810,6 +810,8 @@ usb_transfer_complete(struct usbd_xfer *
if (!repeat) {
/* XXX should we stop the queue on all errors? */
if ((xfer->status == USBD_CANCELLED ||
+xfer->status == USBD_IOERROR ||
+xfer->status == USBD_STALLED ||
 xfer->status == USBD_TIMEOUT) &&
pipe->iface != NULL)/* not control pipe */
pipe->running = 0;

Re: Help troubleshooting ehci_idone hang.

[Martin Pieuchot]

On 12/09/13(Thu) 08:16, RD Thrush wrote:
> On 09/12/13 05:15, Martin Pieuchot wrote:
> > [...]
> > 
> > Could you try the diff below on the v1 machine and tell me if it helps?
> 
> Thanks, I don't think it helped...

By looking at your new log, I believe it did ;)

> After booting the new kernel, upon first use of the kvm switch, the serial
> console began filling with diagnostics which (to my untrained eye) looked
> similar to the pre-patch session. v1-2.  Since I was unable to remotely ssh, I
> interrupted ddb and set ehcidebug=1 but was unable to remotely ssh.  
> ehcidebug=0
> allowed remote ssh and normal operations resumed.
> 
> <http://arp.thrush.com/openbsd/ehci_idone/v1/v1-3> has the associated serial
> console.
> 
> Let me know if I can provide further info.

Could you reproduce once again this manipulation with the diff below
applied on top of the previous one?

> >> WRT to the other machine, x4, I installed the patch and have not yet had a
> >> problem.  However, with ehcidebug=5, the following 2 line message is issued
> >> about once per second:
> >> ehci_intrlist_timeout
> >> ehci_check_intr: ex=0x80238c00
> > 
> > That's expected, thanks for confirming the problem cannot be reproduced
> > with this diff with an ATI controller.
> 
> Since the problem has been intermittent since Nov 2012, I'm not sure enough
> time/kvm usage has occurred for certainty about that fix.

Since this diff is a backport of what has been done in FreeBSD and I
already had a similar report from another developer with the same
controller, I'm quite confident.

> I will run a custom MP kernel with your pci/ehci_pci.c patch on the x4 machine
> whenever I install a new snapshot and let you know if I notice the ehci_idone 
> issue.

Please let me know.

Index: uhidev.c
===
RCS file: /home/ncvs/src/sys/dev/usb/uhidev.c,v
retrieving revision 1.44
diff -u -p -r1.44 uhidev.c
--- uhidev.c7 May 2013 08:44:38 -   1.44
+++ uhidev.c12 Sep 2013 14:25:52 -
@@ -393,7 +393,7 @@ uhidev_intr(struct usbd_xfer *xfer, void
}
 #endif
 
-   if (status == USBD_CANCELLED)
+   if (status == USBD_CANCELLED || status == USBD_IOERROR)
return;
 
if (status != USBD_NORMAL_COMPLETION) {

Re: pms0: not in sync yet, discard input (state 3)

[Martin Pieuchot]

On 17/09/13(Tue) 14:59, frantisek holop wrote:
> hmm, on Tue, Sep 17, 2013 at 02:56:30PM +0200, Stefan Sperling said that
> > On Tue, Sep 17, 2013 at 02:36:25PM +0200, frantisek holop wrote:
> > > as it seems like this is a legit regression,
> > > could this backed out please?
> > 
> > Which commit exactly needs to be backed out?
> 
> my guess would be the ones done after aug 19..
> that one was working.

Could you try to commenting out all the protocol definitions in
the pms_protocols[] table but the Elantech v2 one and tell me if
it works?

If that's working could you reiterate the manipulation by enabling
one by one the protocols defined before this one and find out which
addition breaks your mouse?

Thanks,
Martin

Re: general question about usb stack and ups

[Martin Pieuchot]

On 19/09/13(Thu) 12:20, Gregory Edigarov wrote:
> Hello, everybody.
> 
> A few days ago I've bought a new ups, as a replacement for  my old one, which 
> got it's last way to junkyard.
> The old one had RS232 порт, and the new one is an USB ups.
> Trying different ways to connect it to OpenBSD, but everything I've tried 
> fails.
> The UPS reports itself as:
> 
> uhidev2 at uhub3 port 2 configuration 1 interface 0 "ATCL FOR UPS ATCL FOR 
> UPS" rev 2.00/0.00 addr 4
> uhidev2: iclass 3/0
> uhid2 at uhidev2: input=8, output=8, feature=0
> 
> I've connected it to Windows via USB, and installed software which came with 
> it, snooped the protocol, and I am dead sure it is an old and frayed 
> Megatec/Q1, which should work with blazer_usb driver from nut. But it isn't. 
> Seems I've tried nearly every option and allowed option combinations with no 
> result.
> I cannot get you the usbdevs && usbhidctl right now, because I left it 
> connected to windows, and it is at home.
> 
> So, my question is: could it the differences in usb stack  between various 
> OSes, that are giving the trouble? Will try connect it to linux and NetBSD 
> later, but I am willing to solve the puzzle with OpenBSD.

nut depends on the libusb to talk to the ups, and to be fully
functional with the libusb your device must be attached to
ugen(4).  That's why usb_quirks.c contains various UPS.

Could you try adding a quirk for your device and see if it works? If you
don't know how to do it, please post the output of "usbdevs -dv" so
that somebody can make a diff with the right values.

Martin

Re: KVM card in HP MicroServer

[Martin Pieuchot]

Hello Joe,

On 02/11/13(Sat) 13:58, Joe Gidi wrote:
> 
> I have an HP MicroServer N36L with HP's remote management card installed.
> The card provides KVM-over-IP by presenting a video device and an emulated
> USB keyboard and mouse to the system. The KVM is accessed via a Java (ugh)
> applet in the card's web GUI.
> 
> When I open the KVM session, the video display works fine, and the
> emulated keyboard works at the boot prompt. However, it doesn't work on
> the console once the system has booted. I don't see an error anywhere, but
> typing into the KVM session simply has no effect at all.
> 
> Opening the KVM session after the system is booted causes this to appear
> in the dmesg; apparently it's disconnecting and reconnecting the emulated
> keyboard and mouse:
> 
> Nov  2 13:39:11 microserver /bsd: wskbd0: disconnecting from wsdisplay0
> Nov  2 13:39:11 microserver /bsd: wskbd0 detached
> Nov  2 13:39:11 microserver /bsd: ukbd0 detached
> Nov  2 13:39:11 microserver /bsd: uhidev0 detached
> Nov  2 13:39:11 microserver /bsd: wsmouse0 detached
> Nov  2 13:39:11 microserver /bsd: ums0 detached
> Nov  2 13:39:11 microserver /bsd: uhidev1 detached
> Nov  2 13:39:11 microserver /bsd: wsmouse1 detached
> Nov  2 13:39:11 microserver /bsd: ums1 detached
> Nov  2 13:39:11 microserver /bsd: uhidev2 detached
> Nov  2 13:39:19 microserver /bsd: uhidev0 at uhub1
> Nov  2 13:39:19 microserver /bsd:  port 2 configuration 1 interface 0
> "Avocent USB Composite Device-0" rev 2.00/0.00 addr 2
> Nov  2 13:39:19 microserver /bsd: uhidev0: iclass 3/1
> Nov  2 13:39:19 microserver /bsd: ukbd0 at uhidev0: 8 variable keys, 6 key
> codes
> Nov  2 13:39:19 microserver /bsd: wskbd0 at ukbd0 mux 1
> Nov  2 13:39:19 microserver /bsd: wskbd0: connecting to wsdisplay0
> Nov  2 13:39:19 microserver /bsd: uhidev1 at uhub1
> Nov  2 13:39:19 microserver /bsd:  port 2 configuration 1 interface 1
> "Avocent USB Composite Device-0" rev 2.00/0.00 addr 2
> Nov  2 13:39:19 microserver /bsd: uhidev1: iclass 3/1
> Nov  2 13:39:19 microserver /bsd: ums0 at uhidev1: 3 buttons, Z dir
> Nov  2 13:39:19 microserver /bsd: wsmouse0 at ums0 mux 0
> Nov  2 13:39:19 microserver /bsd: uhidev2 at uhub1
> Nov  2 13:39:19 microserver /bsd:  port 2 configuration 1 interface 2
> "Avocent USB Composite Device-0" rev 2.00/0.00 addr 2
> Nov  2 13:39:19 microserver /bsd: uhidev2: iclass 3/1
> Nov  2 13:39:19 microserver /bsd: ums1 at uhidev2: 3 buttons, Z dir
> Nov  2 13:39:19 microserver /bsd: wsmouse1 at ums1 mux 0
> 
> The system is currently running 5.3/amd64; I plan to upgrade to 5.4 in the
> next week or so. Full dmesg is included below. Any ideas on how I can
> start troubleshooting this? Thanks for any suggestions.

Some changes have been made in this area, post 5.3 to fix a ukbd(4) attach
problem and post 5.4 to fix issues with USB KVM.  So the first thing you
can try is a -current snapshot.  Tell me if it helps ;)

If your problem is still present, could you compile a kernel defining
EHCI_DEBUG and USB_DEBUG, then set ehci_debug = 3 and usbdebug = 6
and send me the corresponding dmesg?

Regards,
Martin

Re: icmp6_reflect misbehaviour ?

[Martin Pieuchot]

On 28/11/18(Wed) 17:48, Stuart Henderson wrote:
> On 2018-11-27, Arnaud BRAND  wrote:
> > Good evening everyone,
> >
> > I am stuck with a IPv6 traceroute problem in an OSPFv3 environment.
> >
> > Long story short  :
> > - IPv6 routes are propagated using OSPFv3
> > - so they are installed with link-local gateways in the fib
> > - ICMPv6 "time exceeded" packets are generated with link-local source 
> > address
> > - these packets are not to be routed so they do not get past the next 
> > hop
> > - the endpoint never receives the "time exceeded packets"
> >
> > This of course is only true if the router generating the icmp packet is 
> > not the endpoint, but only a hop in the path.
> >
> > I checked the code (or at least tried to).
> > It seems like it's in function icmp6_reflect in file icmp6.c at lines 
> > 1144/1147.
> >
> > This code (if I understood it correctly) :
> > - fetches the route to the destination
> > - gets the interface source address for this route
> > - uses it as the source for the generated IP packet
> >
> > As my routes are installed with link-local addresses by OSPFv3, I get a 
> > generated packet with a link local source-address.
> > The problem is when the destination is not on the local subnet : the 
> > generated packet is unroutable and never makes it to its destination
> >
> > Would it be better to try to find another address on the interface that 
> > is not link local if the destination address isn't on the interface 
> > subnets ?

That could be a solution.  But if you do that, why don't you attach the
routes to a routable address in the first place?

Why is ospfd(8) not doing that?

Re: sh /etc/netstart interface counter intuitive behaviour with multiple inet aliases 6.4 and 6.3

[Martin Pieuchot]

On 06/12/18(Thu) 22:49, Tom Smyth wrote:
> Hello,
> 
> Im running a router with multiple ips on an interface using the
> inet alias
> 
> issue:
> when commenting out configured  aliases on hostname.if
> after running sh /etc/netstart vio4
> 
> if you run ifconfig vio4 after the restart of the interface
> the old aliases that were commented still appear in ifconfig output ahead
> of the first ip address configured in the /etc/hostname.vio4 file.
> 
> ifconfig  before commenting  out   10.134.91.253  in hostname.vio4
> is listed below
> vio4: flags=8843 mtu 1500
> lladdr 16:2c:a4:f2:b4:e3
> index 5 priority 0 llprio 3
> media: Ethernet autoselect
> status: active
> inet 10.94.0.1 netmask 0x broadcast 10.94.255.255
> inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67
> inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71
> inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75
> inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87
> inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91
> inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95
> inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163
> inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167
> inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171
> inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175
> inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195
> inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199
> inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203
> inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207
> inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211
> inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215
> inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219
> inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223
> inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227
> inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231
> inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235
> inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239
> inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243
> inet 10.134.91.245 netmask 0xfffc broadcast 10.134.91.247
> inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251
> inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255
> 
> 
> after commenting out the last 2 inet aliases , and running sh /etc/netstart 
> vio4
> 
> the ifconfig output is as follows  (i have highlighted with ***  the addresses
> which I think should have been removed
> 
> vio4: flags=8843 mtu 1500
> lladdr 16:2c:a4:f2:b4:e3
> index 5 priority 0 llprio 3
> media: Ethernet autoselect
> status: active
> ** inet 10.134.91.249 netmask 0xfffc broadcast 10.134.91.251
> ** inet 10.134.91.253 netmask 0xfffc broadcast 10.134.91.255
> inet 10.94.0.1 netmask 0x broadcast 10.94.255.255
> inet 10.134.91.65 netmask 0xfffc broadcast 10.134.91.67
> inet 10.134.91.69 netmask 0xfffc broadcast 10.134.91.71
> inet 10.134.91.73 netmask 0xfffc broadcast 10.134.91.75
> inet 10.134.91.85 netmask 0xfffc broadcast 10.134.91.87
> inet 10.134.91.89 netmask 0xfffc broadcast 10.134.91.91
> inet 10.134.91.93 netmask 0xfffc broadcast 10.134.91.95
> inet 10.134.91.161 netmask 0xfffc broadcast 10.134.91.163
> inet 10.134.91.165 netmask 0xfffc broadcast 10.134.91.167
> inet 10.134.91.169 netmask 0xfffc broadcast 10.134.91.171
> inet 10.134.91.173 netmask 0xfffc broadcast 10.134.91.175
> inet 10.134.91.193 netmask 0xfffc broadcast 10.134.91.195
> inet 10.134.91.197 netmask 0xfffc broadcast 10.134.91.199
> inet 10.134.91.201 netmask 0xfffc broadcast 10.134.91.203
> inet 10.134.91.205 netmask 0xfffc broadcast 10.134.91.207
> inet 10.134.91.209 netmask 0xfffc broadcast 10.134.91.211
> inet 10.134.91.213 netmask 0xfffc broadcast 10.134.91.215
> inet 10.134.91.217 netmask 0xfffc broadcast 10.134.91.219
> inet 10.134.91.221 netmask 0xfffc broadcast 10.134.91.223
> inet 10.134.91.225 netmask 0xfffc broadcast 10.134.91.227
> inet 10.134.91.229 netmask 0xfffc broadcast 10.134.91.231
> inet 10.134.91.233 netmask 0xfffc broadcast 10.134.91.235
> inet 10.134.91.237 netmask 0xfffc broadcast 10.134.91.239
> inet 10.134.91.241 netmask 0xfffc broadcast 10.134.91.243
> inet 10.134.91.245 net

Re: Routing 10-40 Mpps on OpenBSD

[Martin Pieuchot]

On 11/09/16(Sun) 18:04, K K wrote:
> [...]
> > There is a lot of ongoing work in this area, OpenBSD doesn't claim to
> > be the performance leader today.
> 
> What is the take of OpenBSD developers on this?
> Are they any plans?
> 
> Many options seems available, but I have no idea how they could be
> integrated in OpenBSD. I now clearly nothing of proper software
> development.
> 
> - DPDK (now BSD licensed)
> - NETMAP/FW

The plan is to keep being a general purpose operating system with a
kernel abstracting the hardware. 

With that in mind, we're doing our best to modernize the network stack
in order to improve the performance on today's hardware.

There's a lot to do, and what's missing is people working with us.  For
example I send diff daily to improve the network stack and make it
faster.  If you can test them, you're helping *a lot*.  Sadly, very few
people test, fewer comment, and even fewer write diffs.

So as you said, many options are available.  But who's going to do the
work?

PS: Here's the last diff I sent that needs testing:
https://marc.info/?l=openbsd-tech&m=147368131715529&w=2

Re: 6.0-stable panic

[Martin Pieuchot]

On 21/09/16(Wed) 10:44, mxb wrote:
> Panic is very similar to

So far no developer have a clue how to reproduce this panic.  It's a
long standing bug that is now being exposed.  Without knowing what
triggers it we are stuck.

> 
> https://www.mail-archive.com/tech@openbsd.org/msg32608.html
> 
> 
> Panic happened during restart of relayd.
> 
> System is up to date with errata up to 004. Runs relayd, ospfd, bgpd.
> no Tor, no transparent stuff.
> 
> OpenBSD 6.0-stable (GENERIC.MP) #0: Sun Sep  4 11:02:11 CEST 2016
> root@lb1.:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17051353088 (16261MB)
> avail mem = 16530104320 (15764MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed8a0 (122 entries)
> bios0: vendor American Megatrends Inc. version "1.0b" date 01/06/2015
> bios0: Supermicro X10DRT-PT
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI BDAT HPET MSCT PMCT SLIT
> SRAT WDDT SSDT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ
> acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP01(S4) RP02(S4) RP03(S4)
> RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) BR1A(S4) BR1B(S4) BR2A(S4)
> BR2B(S4) BR2C(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz, 3500.44 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,PO
> PCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,F
> SGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz, 3500.01 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,PO
> PCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,F
> SGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 8 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz, 3500.01 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,PO
> PCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,F
> SGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 4, package 0
> cpu3 at mainbus0: apid 10 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz, 3500.01 MHz
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,PO
> PCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,F
> SGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 5, package 0
> cpu4 at mainbus0: apid 16 (application processor)
> cpu4: Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz, 3495.35 MHz
> cpu4:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,PO
> PCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,F
> SGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,SENSOR,ARAT
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu4: smt 0, core 0, package 1
> cpu5 at mainbus0: apid 18 (application processor)
> cpu5: Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz, 3500.01 MHz
> cpu5:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,PO
> PCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,F
> SGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,SENSOR,ARAT
> cpu5: 256KB 64b/line 8-way L2 cache
> cpu5: smt 0, core 1, package 1
> cpu6 

Re: permanent ARP being overwritten by ISP

[Martin Pieuchot]

On 25/10/16(Tue) 03:27, Doug Moss wrote:
> On Wednesday, January 20, 2016 1:37 PM, Martin Pieuchot  
> wrote:
> >If you're referring to my reply, I was interested in the behavior in a
> >-current kernel, what will be 5.9 soon.  A lot of changes happened
> >since 5.8.
> >
> >It would be nice if you could also post the output of "route -n show -inet"
> 
> >with such kernel.
> 
> I have brought up this issue before, but I think I have narrowed down the 
> possible causes/scenario,
> and I have my machine up to date with the current release.
> 
> I think my question is:
> on my openbsd 6.0 amd64 machine, where I already have an accurate ARP entry 
> that has been manually
> set as permanent, when the sshd daemon receives a connection, why does that 
> machine broadcast
> an ARP 'who-has' for the IP address of the SSH client machine?

Good question.  Could you rebuild arp(8) with the diff attached and show
me the output of "arp -an" after triggering the 'who-has'?  I'd like to
know if some code path set the expiration timer of your permanent entry.

Index: arp.c
===
RCS file: /cvs/src/usr.sbin/arp/arp.c,v
retrieving revision 1.76
diff -u -p -r1.76 arp.c
--- arp.c   27 Aug 2016 04:15:52 -  1.76
+++ arp.c   4 Nov 2016 10:03:34 -
@@ -556,7 +556,7 @@ print_entry(struct sockaddr_dl *sdl, str
 
if (rtm->rtm_flags & (RTF_PERMANENT_ARP|RTF_LOCAL))
printf(" %-10.10s", "permanent");
-   else if (rtm->rtm_rmx.rmx_expire == 0)
+   if (rtm->rtm_rmx.rmx_expire == 0)
printf(" %-10.10s", "static");
else if (rtm->rtm_rmx.rmx_expire > now.tv_sec)
printf(" %-10.10s",

Re: Kernel panic on 6.0-stable

[Martin Pieuchot]

On 20/11/16(Sun) 13:58, Frank Groeneveld wrote:
> A few week back there was an outage at my ISP. Afterwards, I kept
> getting crashed on igmpproxy after changing channels on the tv a few
> times:

This has been fixed in -current.

Re: Kernel panic on 6.0-stable

[Martin Pieuchot]

On 20/11/16(Sun) 18:34, Frank Groeneveld wrote:
> On Sun, Nov 20, 2016 at 03:21:32PM +0100, Martin Pieuchot wrote:
> > On 20/11/16(Sun) 13:58, Frank Groeneveld wrote:
> > > A few week back there was an outage at my ISP. Afterwards, I kept
> > > getting crashed on igmpproxy after changing channels on the tv a few
> > > times:
> > 
> > This has been fixed in -current.
> 
> Thanks for the pointer. Does it fix both the igmpproxy crash and the
> kernel crash? Or just the igmpproxy crash?

Kernel crash.

Re: IPv6 Setup not working on Hetzner server

[Martin Pieuchot]

On 05/12/16(Mon) 14:05, Marc Peters wrote:
> Am 12/02/16 um 13:39 schrieb Leo Unglaub:
> > I just found out that since i changed my mygate up to your suggestion
> > that i now have to ping6 fe80::1%em0 first and then i am able to
> > connecto to other hosts via IPv6. But not before i pinged the
> > fe80::1%em0. WTF?
> 
> i have the same setup at hetzner and as someone suggested, i am using in
> my root crontab:
> 
> @reboot sleep 10 && ping6 -c 10 fe80::1\%em0 > /dev/null
> 
> works for me, at least.

Could you reports the problem on bugs@?  It would be nice to fix the
issue rather than documenting workarounds :)

Re: One of the CARP interfaces stopped sending ARP replies on OpenBSD 6.0

[Martin Pieuchot]

On 06/12/16(Tue) 13:48, Rafał Błaszczyk wrote:
> At first I would like to say hello and greet everyone as this is my first
> post here.
> 
> I am having strange issues with one of the CARP interfaces.
> 
> I have two OpenBSD boxes (fw1, fw2) running as HA firewalls with CARP
> interfaces in each VLAN.
> 
> Both boxes are running on two Linux KVM (Proxmox 4.2) hosts.
> 
> One of CARP interfaces stopped responding on ARP requests on CARP IP - it's
> carp1
> 
> running on physical dev vio1 which is also running pfsync on top.
> 
> It's weird because the rest of carp interfaces behave correctly.
> 
> # ifconfig carp1
> carp1: flags=8843 mtu 1500
> lladdr 00:00:5e:00:01:37
> index 18 priority 15 llprio 3
> carp: MASTER carpdev vio1 vhid 55 advbase 1 advskew 0
> groups: carp
> status: master
> inet 10.24.5.1 netmask 0xff00 broadcast 10.24.5.255
> 
> I've checked arp table on two boxes and there is no entry for carp1.

That's the problem.  We'll have to figure out where does it come from.

Could you share your routing table?  Doing "# netstat -rnf inet"

How does your /etc/hostname.carp1 look like?

Do you see an error when running "# sh /etc/netstart carp1" ?

If you grep for 'arp' in /var/log/messages do you get anything?

Re: Bizarre arp entry corruption

[Martin Pieuchot]

On 11/12/16(Sun) 00:50, Joe Holden wrote:
> On 10/12/2016 08:43, Mihai Popescu wrote:
> > > > seeing some bizarre behaviour on one box, on one specific interface:
> > 
> > Hello,
> > 
> > This looks like some stupid TV game, where contesters are given some
> > clues from time to time and they have to guess what is the real shit.
> > 
> > Do post your FULL dmesg and configurations for network if you really
> > want someone to even think at your issue. Isn't that obvious?
> > 
> > Bye!
> > 
> 
> Appreciate the useless response (but still better than nothing!), the
> affected box has since been reverted to older snapshot and thus no more
> debugging can be done - someone else will have to do it.

I'd appreciate to see the output of 'netstat -rnf inet' when it is
relevant.  Without that information it's hard to understand.

But there's a bug somewhere, it has to be fixed.

> Not that dmesg is even relevant since it is a userland bug not a kernel
> problem but anyway:

It's a kernel problem.

Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)

[Martin Pieuchot]

On 25/01/17(Wed) 10:36, Stefan Sperling wrote:
> On Tue, Jan 24, 2017 at 03:10:34PM -0500, mabi wrote:
> > Hi Stefan
> > Thanks for your input. It looks like the g2k16 modifications to the athn 
> > code from awolk@ did not make it into the 6.0 release. So there is still 
> > hope for 6.1 ;-)
> 
> There was a rabbit hole this diff by Adam fell into. I don't know what
> the current status of this is. Adam might know more.

The diff should go in, it doesn't make things worse.

Re: splassert: yield message on 5 Feb snapshot (amd64)

[Martin Pieuchot]

On 09/02/17(Thu) 17:55, Stefan Wollny wrote:
> Am 02/08/17 um 17:57 schrieb Hrvoje Popovski:
> > On 8.2.2017. 17:51, Scott Vanderbilt wrote:
> >> Updated a machine to latest (5 Feb.) snapshot of amd64. I'm now seeing
> >> the following message after booting that I've not recalled seeing before:
> >>
> >>splassert: yield: want 0 have 1
> > 
> > 
> > add sysctl kern.splassert=2 ...
> > 
> 
> Here you go:
> 
> OpenBSD 6.0-current (GENERIC.MP) #163: Sun Feb  5 13:55:12 MST 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

This should be fixed now.  Please update from source or wait for the next
snapshot.  If the problem still persist, report back.

Thanks.

Re: kernel panic in OpenBSD 6.0-stable

[Martin Pieuchot]

On 27/02/17(Mon) 19:36, Infoomatic wrote:
> Hi,
> 
> I have "managed" go get a kernel panic in OpenBSD 6.0 -stable (from 
> GENERIC.MP). Unfortunately I cannot provide you with lots of information, but 
> here is what I have:
> 
> The panic occured twice on an IBM X3550 server (CPU: Intel(R) Xeon(R) CPU 
> E5-2603 0 @ 1.80GHz, with 4GB RAM and Intel I350 Gigabit Network chips 
> onboard) and once in a VM which was
> hosted inside Linux KVM with the e1000 as network interface.
> The IBM server was configured to act as bridged and routed firewall, so we 
> had a hostname.bridge0 (with blocknonip) with em0 and em1 interfaces and 
> vether0 (having the main external ip-address of the firewall and some alias 
> addresses that are routed through into the internal network) and vether1 
> (having the primary internal ip-adress) - some hosts on the network are not 
> of my responsibility so they stayed with an external ip address (and thus we 
> need bridging).
> We carefully planned the migration from Linux/iptables to OpenBSD/PF (which 
> is really a joy to use, kudos to you devs for making me happy and enjoying 
> the time spent with PF and the rest of the system), but after we switched, 
> the hardware got a panic at night (and so did I). I could not even type via 
> USB-keyboard in ddb. And since it was already in production I did not have 
> time to fiddle around and get it working, a restart was needed. See picture 
> [1]
> 
> The second crash occured when I did a "ifconfig vether0 alias EX.TE.RN.IP 
> netmask 255.255.255.240", this time I have switched on ddb.panic=0, but the 
> server did not restart and was hung - no USB keyboard again. See pic [2]
> 
> The third crash was in a VM, where I was playing around. Here, I did not have 
> a bridge configuration, but a "ifconfig em1 alias XX.XX.XX.XX netmask 
> 255.255.255.0" resulted in picture [3], this time again without being able to 
> type in the VM. We had to switch back to the old Linux based firewall, but in 
> the VM I have not managed to reproduce this.
> 
> I would appreciate any tipps, comments or info in this matter, I am willing 
> to help if more information is needed or if I can do anything to support a 
> dev to fix this problem.

At least two bugs leading to this panic have been fixed post 6.0.  I'd
suggest you to upgrade to -current where it should work as expected.  If
not, please send a new bug report to bugs@.

Thanks,
Martin

Re: Bizarre arp entry corruption

[Martin Pieuchot]

On 07/03/17(Tue) 19:38, Joe Holden wrote:
> On 12/12/2016 16:55, Joe Holden wrote:
> > On 12/12/2016 10:27, Martin Pieuchot wrote:
> > > On 11/12/16(Sun) 00:50, Joe Holden wrote:
> > > > On 10/12/2016 08:43, Mihai Popescu wrote:
> > > > > > > seeing some bizarre behaviour on one box, on one specific 
> > > > > > > interface:
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > This looks like some stupid TV game, where contesters are given some
> > > > > clues from time to time and they have to guess what is the real shit.
> > > > > 
> > > > > Do post your FULL dmesg and configurations for network if you really
> > > > > want someone to even think at your issue. Isn't that obvious?
> > > > > 
> > > > > Bye!
> > > > > 
> > > > 
> > > > Appreciate the useless response (but still better than nothing!), the
> > > > affected box has since been reverted to older snapshot and thus no more
> > > > debugging can be done - someone else will have to do it.
> > > 
> > > I'd appreciate to see the output of 'netstat -rnf inet' when it is
> > > relevant.  Without that information it's hard to understand.
> > > 
> > > But there's a bug somewhere, it has to be fixed.
> > > 
> > > > Not that dmesg is even relevant since it is a userland bug not a kernel
> > > > problem but anyway:
> > > 
> > > It's a kernel problem.
> > > 
> > I'll see if I can recreate it but I'm not holding my breath - it only
> > breaks once BGP loaded the table which leads me to thing it is actually
> > bgpd that is updating the llinfo with bogus info and even though I have
> > a feed in my lab it doesn't do the same thing.
> > 
> Ok so, inadvertantly recreated this (pretty much exactly the same) issue on
> a lab/test setup:
> 
> For the purposes of debug, ignore the fact that the interfaces are tap
> interfaces, they're still emulated ethernet...
> 
> Wall of text incoming, various info...
> 
> box#1:
> 
> tap1: flags=8843 mtu 1500
> lladdr fe:e1:ba:d1:be:f3
> index 7 priority 0 llprio 3
> groups: tap
> status: active
> inet 172.20.230.72 netmask 0xfffe
> 
> box#2:
> 
> tap1: flags=8843 mtu 1500
> lladdr fe:e1:ba:d1:cf:92
> index 7 priority 0 llprio 3
> groups: tap
> status: active
> inet 172.20.230.73 netmask 0xfffe
> 
> All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows
> the following:
> 
> Host Ethernet AddressNetif Expire Flags
> 172.20.230.7200:00:00:00:20:12   ? 12m30s
> 
> # route -n get 172.20.230.72
>route to: 172.20.230.72
> destination: 172.20.230.72
>mask: 255.255.255.255
>   interface: tap1
>  if address: 172.20.230.73
>priority: 3 ()
>   flags: 
>  use   mtuexpire
>   20 0   702
> 
> flags destination  gateway  lpref   med aspath origin
> IS*>  172.20.230.72/31 172.20.230.64  200 0 i
> 
> .64 is the loopback on one of its connected boxes that doesn't have broken
> entries
> 
> tcpdump looks ok, afterwards:
> 
> 19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73
> 19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
> 19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73
> 19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
> 
> but the correct entry is never installed, after I delete the broken arp
> entry it never readds a new one.
> 
> This only happens with redist connected as far as I can tell, but bgpd
> probably shouldn't be able to mangle arp entries and prevent the correct one
> being added.

Here's the fix.

Index: net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.232
diff -u -p -r1.232 rtsock.c
--- net/rtsock.c7 Mar 2017 09:23:27 -   1.232
+++ net/rtsock.c8 Mar 2017 16:06:22 -
@@ -895,10 +895,22 @@ rtm_output(struct rt_msghdr *rtm, struct
}
}
 change:
-   if (info->rti_info[RTAX_GATEWAY] != NULL && (error =
-   rt_setgate(rt, info->rti_info[RTAX_GATEWAY],
-   tableid)))
-  

Re: Van Jacobson network channels

[Martin Pieuchot]

On 03/04/17(Mon) 10:41, Hrvoje Popovski wrote:
> Hi all,
> 
> i'm reading some networking stuff and I saw Van Jacobson presentation
> about net channels concept.
> For me, as user that doesn't know net internals, this presentation seems
> quite reasonable.
> 
> Beside that it's about linux network stack, what net gurus think about
> VJ net channels ?
> 
> http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf

It's an interesting idea.  But you have to understand the context in
which it has been presented.  I doubt that replacing "mbuf queue" (see
mq_init(9)) by net channels will buy us anything for now.  We're still
in the phase of eliminating the 'softint' context and moving everything
to tasks, close to where the packets will be consumed, as explained in
the presentation.

Once that's done we might see if a lock-free FIFO helps to pass packets
between contexts.

Re: Suspending USB devices from userland

[Martin Pieuchot]

On 06/11/14(Thu) 14:38, lm wrote:
> Hello there,
> 
> I'm trying to reduce power consumption on my OpenBSD laptop,
> and I can't find the way to suspend some USB devices I never
> use (like the webcam and the DVD drive). 
> 
> Does anybody know a way to do this from userland? If not,
> is it possible to do it with some coding?

There's currently no support for reducing power consumption of USB
devices on OpenBSD.  But if you want to do some coding, I'll suggest
you to start looking at a way to suspend USB ports when there is no
device attached, then you'll to find a way to check if a device is
idle in order to adapt this mechanism to unused devices.

This will require some change to uhub(4) and the various *hci(4).  You
can read chapter 4.3.1 of EHCI specification as a starting point :)

Re: USB ports not working on a mid-2012 MacBookAir5,1

[Martin Pieuchot]

Hello Sevan,

On 10/11/14(Mon) 15:45, Sevan / Venture37 wrote:
> Now that xhci is enabled in -current I gave the snapshots a try again
> on my 11" mid-2012 MacBook Air. The system has USB3 ports but it seems
> that these are not detected & so it is left without any working ports.
> 
> snippets from dmesg
> http://imgur.com/9b1xZA9
> http://imgur.com/OKzAfGe
> 
> dmesg
> http://imgur.com/fugXWyT
> http://imgur.com/934GJhS
> http://imgur.com/M4P3xkO

Could you please post the dmesg inline in text next time?  Having to
search thru 6 pictures in a browser is not something I'm fan of :)

xhci(4) is not yet enabled in the RAMDISK* kernels, because I'd prefer
to squash some more bugs with people really tracking -current 8)

Either you've to install -current or come back in a few weeks, it'll 
be there.

Martin

Re: recent and64 shapshots: USB device timeouts, xhci: NULL xfer pointer

[Martin Pieuchot]

Hello Peter,

On 15/11/14(Sat) 15:29, Peter N. M. Hansteen wrote:
> and I just noticed that the supplied dmesg did not in fact capture the NULL 
> xfer pointer messages,
> but here's one that does, from a few minutes later running the same snapshot.
> 
> The failure pattern isn't entirely consistent - the urtwn device will 
> maintain link for some minutes,
> then timeout, sometimes with the NULL xfer pointer message, but not always. 
> Also, about 50% of the time
> it's possible to get the link back just by rerunning netstart for urtwn0, at 
> other times detaching, 
> reattaching and re-running netstart urtwn0 is needed in order to get back on 
> line. Also, when the device
> does work, its throughput is significantly worse than earlier (guesstimate 
> 10% of previous throughput
> although pinging the gateway yields wildly fluctuating round trip times).

Various people reported a similar problem with an xHCI 1.0 controller
and urtwn(4).  I am unable to reproduce the problem with the various
controllers I have at my disposition here.  I'll try to get access to
more hardware in order to track that down, unless somebody else find
the issue before me.

Re: USB worked on 5.5, not on 5.6 on MacbookAir5,1

[Martin Pieuchot]

On 18/11/14(Tue) 09:02, Scott Bonds wrote:
> A few people suggest I try current. I tried it and the ports show up
> again, this time as XHCI. They are unreliable, as others have noted:
> http://marc.info/?l=openbsd-misc&m=141614729913281&w=2

-current is moving fast and this remark is already outdated since a
commit improving the situation went in just after that :)

I don't know what you mean by "unreliable" nor which snapshot you tried,
that sad for me, 'cause I cannot learn from your experience :/

> I use this laptop as my main workstation, so I'm going to retreat back
> to 5.5-stable for now, but I'll see if I can get a kernel built with the
> XHCI debugging on so I can help gather info on the XHCI issues.

Well you still have an ehci(4) controller on your machine, how does it work
on -current?

Be it on -current or 5.6, could you post the output of "usbdevs -dv" or
even better "lsusb -v" (from the usbutils package) with your devices
attached but not recognized?

> Excerpts from Scott Bonds's message of 2014-11-15 01:35:32 -0800:
> > [...]
> > An old copy of the 5.5 dmesg is available here:
> > 
> > http://marc.info/?l=openbsd-tech&m=138867402307945&w=2

There's no difference USB-wise with the dmesg you posted for 5.6.  From
what I can see your urtwn(4) was attached to uhub3 which is connected to
an ehci(4).  Do you connect it in a blue port? 

Do you also have a "usbdevs -dv" output, or better "lsusb -v"
one for this release?

Re: uvideo(4) problems in recent snaps?

[Martin Pieuchot]

On 18/11/14(Tue) 12:46, percy piper wrote:
> Has anyone noticed problems with uvideo(4) in recent snapshots?
> 
> The issue I'm seeing is reproducible with video(1) - just run it and
> wait. After some seconds or minutes no new frames arrive and video(1)
> is waiting on poll(2). Larger frame sizes seem to decrease the time
> needed to achieve this state. No errors are logged at all.
> 
> Our in-house video monitoring has used a variety of uvideo(4) devices
> for some years and this behaviour was not apparent up to 5.6 or in snaps
> dated 2nd September (i386 & amd64).
> 
> Now, we see this behaviour on all tested i386 and amd64 systems running
> recent snaps, regardless of whether our code is using mmap(2) or
> read(2) and/or select(2) or poll(2) and with any uvideo(4) device.
> 
> We don't have any xhci(4) hardware, and everything works fine again
> if we roll back to 5.6 release.
> 
> Two dmesg below, the first from the last snap we tried that is known
> to work (a machine in production) and the second from my laptop
> running Sunday's i386 snap which exhibits this behaviour.
> 
> Can anyone else confirm this?

I can confirm.  I see this on amd64 with a "Nov 2" snapshot.  If
somebody can bisect this period and find which change introduced
a regression, it would be nice.

Martin

Re: USB worked on 5.5, not on 5.6 on MacbookAir5,1

[Martin Pieuchot]

On 19/11/14(Wed) 11:39, Scott Bonds wrote:
> > I don't know what you mean by "unreliable" nor which snapshot you
> > tried, that sad for me, 'cause I cannot learn from your experience :/
> 
> Sorry about that Martin, I'll try to be more helpful by providing more
> details. The snapshot I tried and found to be unreliable was amd64
> bsd.mp 2014-11-14.
>
> By unreliable I mean this: I plugged in my axe network adapter, which is
> 100% rock solid under 5.5. Under -current@20141114 after a few minutes
> of use, the axe0 stops working. I try to ping a known good host and it
> drops all the packets. Running 'ifconfig axe0 down' then 'ifconfig axe0 up
> && dhclient axe0' restores functionality for a few minutes, then it goes
> down again. Same behavior with a urtwn. When booting off of a USB2
> thumbdrive everything works for 5 minutes or so, but at some point the
> light on the drive stops flashing and any command I type in never
> returns. I can keep typing (so the internal EHCI controller seems ok)
> but nothing happens besides what I type showing up on the screen. I can
> reproduce this misbehavior on both the 20141114 and the 20141118 snaps.

Thanks for the information.  

> > Well you still have an ehci(4) controller on your machine, how does it
> > work on -current?
> 
> I believe my MacbookAir5,1 has a number of *internal* EHCI ports for
> stuff like the keyboard to connect to, plus 2 *external* XHCI ports for
> me to plug peripherals into.
> 
> The internal EHCI ports seem to work fine on -current. The external
> ports show up as XHCI ports on -current and exhibit the problems I
> described above.
> 
> To hazard a guess on why my ports worked in 5.5 and earlier as EHCI
> ports, do not work at all in 5.6, and show up as XHCI ports in -current:
> the BIOS is capable of falling back to EHCI if the OS doesn't ask for
> XHCI ports. 5.5 and earlier only asked for EHCI ports, so that's what
> the BIOS provided. 5.6 asks for XHCI ports, the BIOS provides them
> instead of emulating EHCI ports, but 5.6 doesn't actually support XHCI
> ports yet, so they are unusable in 5.6. -current adds support of XHCI
> ports, and asks the BIOS for XHCI ports, so things are working again, at
> least at a basic level.
> 
> If my guess is somewhat right, a fix or workaround for 5.6 might be to
> somehow return to the old behavior of pretending the OS knows nothing of
> XHCI and ask the BIOS to provide EHCI ports at boot.

I don't know how it works in Apple machines but other people reported
such weird thing with machine having an xhci(4)/ehci(4) controller.
Telling the BIOS to "deactivate" USB 3 support made their ports work
again with ehci(4), do you have a way to do that on your MacbookAir5,1?

> > Be it on -current or 5.6, could you post the output of "usbdevs -dv"
> > or even better "lsusb -v" (from the usbutils package) with your
> > devices attached but not recognized?
> 
> Yes. Here are the usbdev, usbdev -dv, lsusb, and lsusb -v outputs for
> this machine with a urtwn plugged into the external USB port on the left
> side, for both 5.5-stable-i386 and -current@20141118-amd64. Note: for
> current I booted off of a USB thumbdrive, so you'll see that too on
> those outputs.

Thanks for this info.

Re: Mac Mini

[Martin Pieuchot]

On 20/11/14(Thu) 15:49, Austin Gilbert wrote:
> On Nov 20, 2014, at 2:33 PM, Chris Cappuccio  wrote:
> 
> > Austin Gilbert [austin.gilb...@gmail.com] wrote:
> >>> On Nov 20, 2014, at 1:27 PM, Otto Moerbeek  wrote:
> >>> 
>  On Thu, Nov 20, 2014 at 12:37:58PM -0600, Austin Gilbert wrote:
>  
>  I have an amd64 based Mac Mini which I would like to run OpenBSD on.
>  
>  With OpenBSD 5.6, the USB keyboard works at the ?boot>? prompt, but not
> >> after booting BSD.rd. The Mac Mini has USB 3 ports, I thought perhaps the
> >> newly minted USB 3 support in current could help, but the nightly snapshot
> >> behaved the same as the last release version.
>  
>  Is there anything I can do at the ?boot>? prompt to try 
>  disabling/enabling
> >> different device drivers for the USB ports so the keyboard will work under
> >> BSD.rd?
>  
>  The other option I thought of would be setting the terminal to a serial
> >> port? which I can?t do as I don?t have any serial ports on the box. Only
> >> Thunderbolt 2, USB 3, Ethernet.
> >> 
> > 
> > You might want to try a -current snapshot. They have a USB 3 driver!
> 
> I saw the news about the USB 3 driver in current and was very excited about 
> that. The first thing I did was grab a snapshot. Sadly, the snapshot BSD.rd 
> behaves the same as the stable 5.6 release (as of the 16th).

bsd.rd do not include xhci(4) for the moment, because there's a known
issue with the driver & some chips.

Re: Trackpad after suspend/resume on MacBookAir4,1

[Martin Pieuchot]

Hello Maximilian,

On 23/11/14(Sun) 11:08, Maximilian Pichler wrote:
> Hi,
> 
> After resuming from suspend (either by closing and reopening the lid
> or via zzz) the trackpad behaves erratically -- the pointer jumps
> around wildly when using it. The issue is reproducible.

This is a known issue with USB pointer devices.  What's happening is
that your device is detached upon suspend an re-attached at resume.

However there's no way to tell the Xserver to re-open/re-calibrate
your device when it is re-attached.  The best you can do for the moment
is restart X after resuming, it should recalibrate your touchpad
properly.

Martin

Re: Trackpad after suspend/resume on MacBookAir4,1

[Martin Pieuchot]

On 24/11/14(Mon) 09:04, Peter Hessler wrote:
> Can you switch from the graphical console (ctrl-alt-f5) to a text
> console (ctrl-alt-f1), and back?  That may help with input device
> related problems.

That won't work in this case.  His pointer isn't behind the mux and
needs to be calibrated.

Re: Trackpad after suspend/resume on MacBookAir4,1

[Martin Pieuchot]

On 24/11/14(Mon) 08:11, Maximilian Pichler wrote:
> Thanks for the explanations!
> 
> On Mon, Nov 24, 2014 at 4:19 AM, Martin Pieuchot  
> wrote:
> > On 24/11/14(Mon) 09:04, Peter Hessler wrote:
> >> Can you switch from the graphical console (ctrl-alt-f5) to a text
> >> console (ctrl-alt-f1), and back?  That may help with input device
> >> related problems.
> >
> > That won't work in this case.  His pointer isn't behind the mux and
> > needs to be calibrated.
> 
> It's even slightly worse: after resuming, the keyboard still works in
> X, but switching to a text console (either via ctrl-alt-f1 or by
> quitting X) results in the keyboard being unusable, i.e. typing
> anything results in garbled characters. I therefore cannot even try
> your previous suggestions of restarting X.

This is a bug.

> Here is yet another experiment: after booting into text console mode,
> suspend and resume. The keyboard still works. However, now attempting
> to start X results in a black screen. Killing X and starting it a
> second time works (and mouse and keyboard are fine within X). The
> difference between the logs are:

The black screen is another issue related to the graphic driver.

Regarding your mouse, it is normal that suspending the machine in
console does not have the same effect as in X.  Because only X 
calibrates it.  For that it needs to open a specific device node
in /dev which is closed when you suspend the machine.  The problem
is that we have currently no way to tell X to re-open such node in
order to re-calibrate your pointer.

Re: USB hub stopped working

[Martin Pieuchot]

Hello Patrick,

On 24/11/14(Mon) 23:48, patrick keshishian wrote:
> Hi,
> 
> I have this USB hub, which is connected to my desktop
> PC; it makes the USB ports accessible w/o need to crawl
> under the desk. I'll seldom need to transfer files (to/fro)
> with a USB stick, which I plug into one of the hub ports.
> 
> I don't quite recall when it was last used. But with 2014-NOV-21
> snapshot it doesn't seem to work.
> 
> OpenBSD 5.6-current (GENERIC) #563: Fri Nov 21 10:09:03 MST 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Could you try a more recent snapshot?  This should already be fixed.
Let me know if that's not the case.

Martin

Re: -current hangs during boot from xhci controller on MacbookAir6,1

[Martin Pieuchot]

On 01/12/14(Mon) 15:41, Scott Bonds wrote:
> While investigating the slow hard drive on my MacbookAir6,1, I decided
> to take a working installation of -current (20141201 snapshot) on a USB
> drive and try booting it on the MBA6,1. I discovered that booting off of
> a usb drive (with a full install, i.e. bsd.mp NOT bsd.rd) hangs once the
> boot reaches this line:
> 
> uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
> 
> This behavior manifests while using a 'normal' boot--I did not use the
> OSX bless utility to get the builtin USB controller into ehci mode
> instead of xhci mode. When I *do* do that (use bless to set the usb
> controller into ehci mode) the boot progresses to:
> 
> scsibus4 at softraid0: 256 targets
> 
> then pauses there for 5 minutes, then proceeds to boot just fine. When
> booting this way, I observe the same pauses/slowness when operating on
> the builtin hard drive as mentioned in the thread I started on that
> topic:
> 
> http://marc.info/?l=openbsd-misc&m=141747241629431&w=2
> 
> Anyway, I mention the xhci boot hang behaviour because I know xhci
> development is active, and I thought this result may be
> interesting/useful for that.

Such long hang generally means that timeouts are occurring.  If you
can compile a kernel with XHCI_DEBUG and UHUB_DEBUG defined and send
me a dmesg, it will be much appreciated.

Martin

Re: OpenBSD and disk slowliness

[Martin Pieuchot]

Dear Mikolaj,

On 09/01/15(Fri) 00:30, Mikolaj Kucharski wrote:
> Hi,
> 
> This problem looks very similar as:
> 
>   https://marc.info/?l=openbsd-misc&m=140288534929223&w=2
> 
> On my i386 KVM after each upgrade I run this:
> 
> #!/bin/sh
> 
> for kernel in /bsd /bsd.mp
> do
> config -fe $kernel << EOF
> find mpbios
> disable mpbios
> find mpbios
> find acpimadt
> disable acpimadt
> find acpimadt
> quit
> EOF
> done
> 
> 
> Please CC me in any replies, I'm not receiving mails from `misc`

Your email makes me really sad.

It makes me really sad because I want to believe that you sent it in
order to help somebody.  However you're doing the contrary and you are
doing it publicly.  That means other people will later find your email
and, believing that you are trying to help, do what you recommend.

Please do not recommend to *disable* anything in a kernel.

Disabling something that you don't understand might be good enough for
you.  But it does not help me, or I believe anyone else, to fix the 
damn problem people are having.

Instead of giving such advices, I'd suggest you to read sendbug(1) and
fill a bug report as complete as possible such that competent people
might have a chance to help you fix your problem.  If you do that you
might be able to run a GENERIC kernel without disabling anything.  You
might also prevent other people to send other bug reports for the same
problem.

Think about it, the system you're running is good because *a lot* of
other people did not deactivate anything but instead sent good or not
so good bug reports.

Sadly you've just answered to yet another bug report without information,
giving a bad advice and nobody can improve OpenBSD.

I hope I didn't sound to harsh and I hope to see a nice bug report from
you in bugs@ soon.

Best regards,
Martin

Re: usb_transfer_complete: actlen > len

[Martin Pieuchot]

Hello Ingo,

On 11/01/15(Sun) 09:54, Ingo Feinerer wrote:
> With the latest snapshot I have /var/log/messages filled up with
> 
> uaudio_chan_rintr: count < n
> usb_transfer_complete: actlen > len 2824 > 0
> usb_transfer_complete: actlen > len 3 > 0
> usb_transfer_complete: actlen > len 2816 > 0
> 
> when playing audio. The problem is that I have disk activity because
> /var/log/messages fills up extremely fast (e.g. it was 80 MB after
> watching a video via mplayer for a few minutes).

Thanks for the bug report, don't hesitate to send it to bugs@ next time.
Not all the developers read misc@.

I am the one to blame for this regression.  I wanted to make sure every
USB transfer was checked for buffer overrun but isoc transfers are
special.  Could you tell me if the diff below fixes it?


Index: usbdi.c
===
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.77
diff -u -p -r1.77 usbdi.c
--- usbdi.c 9 Jan 2015 12:15:48 -   1.77
+++ usbdi.c 11 Jan 2015 11:12:34 -
@@ -732,7 +732,7 @@ usb_transfer_complete(struct usbd_xfer *
pipe->running = 0;
 
 #ifdef DIAGNOSTIC
-   if (xfer->actlen > xfer->length) {
+   if (xfer->actlen > xfer->length && xfer->length != 0) {
printf("%s: actlen > len %u > %u\n", __func__, xfer->actlen,
xfer->length);
xfer->actlen = xfer->length;

Re: CUPS USB Madness

[Martin Pieuchot]

On 26/01/15(Mon) 11:02, Stephan Schindel wrote:
> Hey,
> 
> First off: I'm new to OpenBSD :). I'm running 5.6-STABLE with stable 5.6
> ports tree. I've updated my CUPS installation which had some USB patches in
> it. However, I cannot see my printer via webinterface/Administration/Add
> Printer. The only options I can choose from are "Other Network Printer".

I believe you forgot some of the steps described in:

/usr/local/share/doc/pkg-readmes/cups-*

M.

Re: kbc: cmd word write error

[Martin Pieuchot]

On 24/01/15(Sat) 23:47, Jan Stary wrote:
> On Jan 24 23:46:27, h...@stare.cz wrote:
> > Just reinstalled a MacBook2,1 with current/amd64 (dmesg below).
> > Everything is working fine, except I can't do UKC at boot,
> > because the keyboard does not work inside UKC.
> > 
> > In the boot loader I can type my softraid password,
> > and enter 'boot -c'. But once inside UKC, it says
> > 
> > kbc: cmd word write error
> > 
> > and the keyboard stops working. I can see the cursor
> > running frantically across the last line I think.
> > http://stare.cz/dmesg/macbook2%2c1-kbc.jpg

This error simply means that the kernel did not find a pckbd(4) keyboard
on your machine.  It is normal since your console keyboard is connected 
through USB.  But since the USB subsystem has not been discovered yet,
you cannot use your keyboard.

> > What can I do to help debug this?

I don't know if it is possible to call the firmware for input on amd64,
that's what macppc is doing at this stage.

Another crazy idea would be to have a limited USB support for handling
inputs.  But it's not a trivial task.

Re: IPv6 gateway fe80::1 needs a ping to work

[Martin Pieuchot]

Hello Thomas

On 29/01/15(Thu) 02:50, Thomas Bohl wrote:
> Hello List,
> 
> my vServer hosting provider states the IPv6 default gateway as fe80::1.
> To get IPv6 traffic flowing it's necessary to ping fe80::1 fist.
> 
> For now I help myself with the following line in crontab
> @reboot sleep 10 && ping6 -c 10 fe80::1\%vio0 > /dev/null
> [...]
> # ping6 -vc 4 heise.de
> PING6(56=40+8+8 bytes) 2a03:4000:6:f0::47:e --> 2a02:2e0:3fe:1001:302::
> 32 bytes from 2a03:4000:6::1: Neighbor Advertisement

Could you tcpdump ICMP6 packets on vio0 at this moment?  I wonder if a
wrong target address can be used to craft NS messages for your gateway. 

Martin

Re: routing help

[Martin Pieuchot]

Hello Edgar,

On 01/02/15(Sun) 10:01, Edgar Pettijohn wrote:
> I am trying to add a second ip to my openbsd5.6 vultr.com server.  I thought
> it would be as simple as:
> 
> /etc/hostname.vio1
> 104.238.145.48 255.255.254.0
> !route add 104.238.145/23 104.238.144.1
> 
> They claim to be assigning me ip 104.238.145.48 netmask 255.255.254.0 with a
> gateway of 104.238.144.1.
> However, I am unable to ping 104.238.145.48.  Any help is appreciated.  I've
> read the following manuals hostname.if(5), route(8), and ifconfig(8) and
> tried several different approaches. I'm still learning so be gentle :).
> 
> vio0: flags=28843 mtu 1500
> lladdr 56:00:00:03:ef:10
> priority: 0
> groups: egress
> media: Ethernet autoselect
> status: active
> inet 108.61.222.55 netmask 0xff00 broadcast 108.61.222.255
> vio1: flags=28843 mtu 1500
> lladdr 52:54:00:86:36:94
> priority: 0
> media: Ethernet autoselect
> status: active
> inet 104.238.145.48 netmask 0xfe00 broadcast 104.238.145.255
> 
> # route show
> Routing tables
> 
> Internet:
> Destination  GatewayFlags   Refs  Use Mtu  Prio
> Iface
> default 108.61.222.1 UGS  3 214 - 8
> vio0
> 104.238.144/23 link#2UC   1  0   -
> 4  vio1
> 104.238.144/23 104.238.144.1  UGS  0  0 - 8
> vio1
> 104.238.144.1  link#2UHLc 1 0-
> 4  vio1
> vpn.pettijohn-web. 52:54:00:86:36:94  UHLl0 0 -  1
> lo0
> 108.61.222/24  link#1   UC   2 0   -
> 4 vio0
> 108.61.222.1   74:8e:f8:48:67:80  UHLc   10 -4
> vio0
> pettijohn-web.com  56:00:00:03:ef:10  UHLl   00 - 1
> lo0
> 108.61.222.170.vul 52:54:00:cb:e8:f1  UHLc   00 - 4
> vio0
> loopback   localhost  UGRS   00 32768 8
> lo0
> localhost  localhost  UH 10 32768 4
> lo0
> BASE-ADDRESS.MCAST localhost  URS00 32768 8
> lo0
> 
> # dmesg (is full of the following)
> arp: attempt to add entry for 104.238.144.1 on vio1 by 74:8e:f8:48:67:80 on
> vio0

It seems that your two gateways (108.61.222.1 and 104.238.144.1) correspond
to the same Ethernet address.

You're seeing this message because you configured your addresses on two
different interfaces.  Configuring both of them on vio0 should solve
your problem.

Re: IBM/Lenovo Thinkpad trackpoint support in pms(4)?

[Martin Pieuchot]

On 31/01/15(Sat) 12:27, Peter Piwowarski wrote:
> Hello,
> 
> pms(4) currently seems to have no particular support for the trackpoint
> devices on Thinkpads.

"Recent" Thinkpads have support for the trackpoint via the Synaptics
protocol supported by pms(4).

>   These support some extensions to the PS/2 protocol, to
> do things like configure the device's sensitivity. What can be done to add
> support for this to OpenBSD? IBM provides (or provided) some fairly detailed
> docs[1], and there is a driver in linux[2][3]. I'd be interested in
> attacking this myself, but I have no experience with kernel hacking and
> don't really know how to begin. I can provide dmesg for systems with
> trackpoint and touchpad and for systems without a touchpad, if anyone is
> interested.

First step for kernel hacking would be to follow -current and be able to
build your own kernel 8)

Posting your dmesg would help us understand which hardware you're
talking about.

Then you might want to add another protocol for your trackpoint to pms(4),
have look at pms_protocols[] :)

Martin