ahci BSY retry

[Chris Cappuccio]

Peter J. Philipp recently ran into this on his Intel AHCI+Intel SSD
system (see misc from yesterday):

ahci2 at pci0 dev 31 function 2 Intel 8 Series AHCI rev 0x05: msi, AHCI 1.3
ahci2: device on port 1 didn't come ready, TFD: 0x80BSY
ahci2: stopping the port, softreset slot 31 was still active.
ahci2: unable to communicate with device on port 1

I've seen this on boot with Intel AHCI and Transcend SSD and others
have seen it with Intel AHCI+Intel SSD on soekris net6501.

Here's a simple fix based on Dragonfly's fix for the same problem.
(Try to restablish communication one more time.)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/f2dba7003b2add226b3999a41a99fd278cc5a26f

Dragonfly will only reset here on startup, whereas OpenBSD will
call this to reset ports after startup. This symptom occurred to
me during 24 hour heavy 100% read+write utilization on softraid
RAID1 configuration, with regular SATA disks. So if we are going 
to call ahci_port_portreset during operation, this seems prudent.

Index: ahci.c
===
RCS file: /cvs/src/sys/dev/ic/ahci.c,v
retrieving revision 1.13
diff -u -r1.13 ahci.c
--- ahci.c  14 Apr 2014 04:42:22 -  1.13
+++ ahci.c  23 Apr 2014 14:11:16 -
@@ -1363,7 +1363,7 @@
 ahci_port_portreset(struct ahci_port *ap, int pmp)
 {
u_int32_t   cmd, r;
-   int rc, s;
+   int rc, s, retries = 0;
 
s = splbio();
DPRINTF(AHCI_D_VERBOSE, %s: port reset\n, PORTNAME(ap));
@@ -1378,6 +1378,10 @@
ahci_pwrite(ap, AHCI_PREG_SCTL, 0);
delay(1);
r = AHCI_PREG_SCTL_IPM_DISABLED | AHCI_PREG_SCTL_DET_INIT;
+
+   ahci_pwrite(ap, AHCI_PREG_SCTL, r);
+retry:
+   delay(1);
if ((ap-ap_sc-sc_dev.dv_cfdata-cf_flags  0x01) != 0) {
DPRINTF(AHCI_D_VERBOSE, %s: forcing GEN1\n, PORTNAME(ap));
r |= AHCI_PREG_SCTL_SPD_GEN1;
@@ -1411,6 +1415,10 @@
/* even if the device doesn't wake up, check if there's
 * a port multiplier there
 */
+   if (retries == 0) {
+   retries = 1;
+   goto retry;
+   }
rc = EBUSY;
} else {
rc = 0;

Re: iked + isakmpd on the same machine

[Chris Cappuccio]

Mike Belopuhov [m...@belopuhov.com] wrote:
 
 more like it's not supported and is not supposed to work.
 it's like running nginx and apache at the same time

hey, nginx and httpd run concurrently quite fine on
different IP addresses, same box :)

Re: IPv6 by default

[Chris Cappuccio]

Kenneth Westerback [kwesterb...@gmail.com] wrote:
 
 Why is the burden on everyone to provide 'valid' objections? Should
 not the burden be on you to at least hint at a point to this change?
 Given the miniscule IPv6 usage out there, why should IPv6 come first?
 

I like how IPv6 support turns primary and secondary DNS caches from
a redundancy feature for clients to dual points of failure (for some
resolver implementations.) No response from either server for the first
AF you try? Just wait for a full time out before you try the second AF!

Re: new OpenSSL flaws

[Chris Cappuccio]

Miod Vallat [m...@online.fr] wrote:
  Now you have and example of how they are unwilling to work with you next
  time someone asks why not work with OpenSSL on fixing it.  Pretty direct
  proof.
 
 The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE.
 
 We believe in peer review; they don't give a sh*t about it (as shown
 less than a month ago by the way their #3317 bug was fixed, commiting a
 different fix from the proposed one and introducing a stupid *and
 obvious* bug in the process - which got fixed the next day after otto@
 mentioned it to the OpenSSL developers).
 
 If you can't trust people to apply one-liner fixes correctly, can you
 trust them for anything serious?

I think this Networkworld article says it all... (and since when
did interesting, critical analysis come from Networkworld!?)

http://www.networkworld.com/article/2360229/microsoft-subnet/critical-flaw-in-encryption-has-been-in-openssl-code-for-over-15-years.html

If you don't think that Robin Seggelmann is a paid stooge actively
trying to sabotage OpenSSL (an idea rooted in paranoia?) then you
may at least think he is careless, unable to use critical thought,
and certainly doesn't need commit access to any source code repository.
Am I late to the party? Or is it time to re-audit every single character
of his code?

In the mean time, let Dr. Stephen N. Strangelove continue his mad
plan to support VMS and Windows 3.1. Let him play games with LibreSSL
competitors by denying advance notice. Perhaps next time Otto won't
bother to inform them about their new stupid, obvious flaws in return?
It's low class for Dr. Strangelove and his team to behave like this,
after the many repetitive attempts from @openbsd.org to bring OpenSSL
into the new century.

OpenSSH became the de-facto standard because it was the only serious
free alternative for a long time. OpenSSL has always been free. So the
culture difference is precisely what will drive people for, or away
from OpenSSL. (People from the culture of supporting ancient software
and broken standards are going to choose OpenSSL every time!)

Re: that private mailing list

[Chris Cappuccio]

Theo de Raadt [dera...@cvs.openbsd.org] wrote:
 From: Solar Designer so...@openwall.com
 To: Theo de Raadt dera...@cvs.openbsd.org
 
 Hi Theo,
 
 I can't comment about OpenSSL folks, but my own impression certainly was
 that you didn't want your project to be provided advance notification -
 not only via distros list, but at all.  Now you're saying you actually
 wanted folks on your team to be notified, just not you personally.  Hmm?

Really?

Let's see it. I'm questioning your judgment after reading the next bit.

 As you had mentioned to me in the private discussion when stu@ wanted to
 get OpenBSD onto distros, you didn't want folks on your team to accept
 any kind of embargo.  I wish we had that discussion in public, as I had
 suggested at the time.  You objected to that.  (And I understand that
 with that discussion in public you might not have been willing to blame
 some others in it, which would possibly hamper my understanding of your
 position.  So your objection did make some sense.)  Now you appear to be
 misinforming folks on your own team (I hope not intentionally) that
 those evil people on distros list and OpenSSL maintainers deliberately
 didn't want to notify you.  You might be right about OpenSSL maintainers
 (although I think you are not) - I just don't know, and can't speak for
 them - but at least for me (as someone who was notified via distros
 list) it appeared that you actually didn't want your team to be notified
 in a manner that would impose any restrictions on when you can commit a
 fix.  So, believe it or not, it didn't even occur to me to put your
 project in a position where your folks would be asked to accept an
 embargo, which you didn't want.
 

This reads like some kind of strange combination of arbitrary logic
and reasoning to justify this in your own mind.

Firstly, an embargo is crap and you know it. That implies a formal
process with contracts and legal implications. (More plainly, did YOU sign?)

A heads-up from OpenSSL to the key people is all it would have taken.
(Sorry, I guess that's only appropriate when those key people aren't aiming
at improving their shitty product.)

 Would you like me to suggest (to whoever reports an issue) that someone
 on your team (who?) be notified next time an OpenSSL issue is brought up
 on distros?  (It doesn't have to be one person on your team - it can be
 several.  This is to address Bob's comment on your lists.)  What about
 issues in other projects (not OpenSSL)?  Which other projects would you
 also like notifications about?
 
 It appears that you've made a (political) decision for your projects not
 to join distros (or possibly any such channels in general), but are now
 asking for people/projects to be notifying your folks anyway when
 appropriate (whatever that means), and this is difficult for everyone.
 
 How do you suggest we make things better (in whatever sense you like)
 going forward?
 

Seriously?

I think the situation here is PLAINLY OBVIOUS.

Here in the real world, key OpenBSD members should be trusted to
do the RIGHT THING in a typical situation like this.

This isn't the first time this has happened nor the last time it will.

Hopefully next time someone has common sense.

I think we can all agree, OpenSSH has been successful at mitigating
this same kind of problem with ALL of the other players.

Maybe you need some coffee?

Chris

Re: diff: Fix udp_usrreq.c to compile without IPSEC.

[Chris Cappuccio]

If you really want to be pedantic, it should be if defined(PIPEX) || 
defined(IPSEC)

YASUOKA Masahiko [yasu...@yasuoka.net] wrote:
 ok?
 
 Fix compile without IPSEC.
 
 Pointed out by Ivan Solonin.
 
 Index: sys/netinet/udp_usrreq.c
 ===
 RCS file: /disk/cvs/openbsd/src/sys/netinet/udp_usrreq.c,v
 retrieving revision 1.184
 diff -u -p -r1.184 udp_usrreq.c
 --- sys/netinet/udp_usrreq.c  23 Apr 2014 12:25:35 -  1.184
 +++ sys/netinet/udp_usrreq.c  23 Jun 2014 02:17:06 -
 @@ -186,9 +186,9 @@ udp_input(struct mbuf *m, ...)
   struct m_tag *mtag;
   struct tdb_ident *tdbi;
   struct tdb *tdb;
 +#endif /* IPSEC */
   int error;
   u_int32_t ipsecflowinfo = 0;
 -#endif /* IPSEC */
  
   va_start(ap, m);
   iphlen = va_arg(ap, int);

-- 
If you see fraud and don't shout fraud, you are a fraud -- Nassim Taleb

Re: IEEE80211_DEBUG

[Chris Cappuccio]

Nathanael Rensen [nathan...@list.polymorpheus.com] wrote:
 The IEEE80211_DEBUG kernel option needs a little help to compile.
 
 Index: ieee80211_pae_input.c
 ===
 RCS file: /cvs/src/sys/net80211/ieee80211_pae_input.c,v
 retrieving revision 1.19
 diff -u -p -r1.19 ieee80211_pae_input.c
 --- ieee80211_pae_input.c 22 Jul 2014 11:06:10 -  1.19
 +++ ieee80211_pae_input.c 23 Jul 2014 14:25:22 -
 @@ -978,7 +978,7 @@ ieee80211_recv_group_msg2(struct ieee802
  
   /* discard if we're not expecting this message */
   if (ni-ni_rsn_gstate != RSNA_REKEYNEGOTIATING) {
 - DPRINTF((%s: unexpected in state: %d\n, ni-ni_rsn_gstate));
 + DPRINTF((unexpected in state: %d\n, ni-ni_rsn_gstate));

probably want this:
+   DPRINTF((%s: unexpected in state: %d\n, ic-ic_if.if_xname,
+   ni-ni_rsn_gstate));

Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

[Chris Cappuccio]

ok chris@ 

David Gwynne [da...@gwynne.id.au] wrote:
 this lets you have networks on the native vlan on an interface
 at 1500, while setting a child vlan interfaces mtu to jumbos.
 
 ok?
 
 Index: if_vlan.c
 ===
 RCS file: /cvs/src/sys/net/if_vlan.c,v
 retrieving revision 1.108
 diff -u -p -r1.108 if_vlan.c
 --- if_vlan.c 12 Jul 2014 18:44:22 -  1.108
 +++ if_vlan.c 19 Aug 2014 23:52:15 -
 @@ -528,9 +528,9 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd
   case SIOCSIFMTU:
   if (ifv-ifv_p != NULL) {
   if (ifv-ifv_p-if_capabilities  IFCAP_VLAN_MTU)
 - p_mtu = ifv-ifv_p-if_mtu;
 + p_mtu = ifv-ifv_p-if_hardmtu;
   else
 - p_mtu = ifv-ifv_p-if_mtu - EVL_ENCAPLEN;
 + p_mtu = ifv-ifv_p-if_hardmtu - EVL_ENCAPLEN;
   
   if (ifr-ifr_mtu  p_mtu || ifr-ifr_mtu  ETHERMIN)
   error = EINVAL;

Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

[Chris Cappuccio]

David Gwynne [da...@gwynne.id.au] wrote:
 sthen@ says this is likely a bit optimistic. while most of our drivers 
 unconditionally configure their max mru, there's some stupid ones that still 
 interpret the configured mtu as a what the mru should be.
 

All the more reason to make this change, I'd say :)

Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/08/20 17:17, Chris Cappuccio wrote:
  David Gwynne [da...@gwynne.id.au] wrote:
   sthen@ says this is likely a bit optimistic. while most of our drivers 
   unconditionally configure their max mru, there's some stupid ones that 
   still interpret the configured mtu as a what the mru should be.
   
  
  All the more reason to make this change, I'd say :)
 
 it's not just that - there are some like et(4) with obvious trade-offs visible
 in the driver source code which are only wanted in the case where jumbos are
 actually in use. and who knows what various chips will do internally when the
 command to permit jumbos or raise the valid packet size is sent.
 

I don't think this is relevant. If a chip or driver is buggy in the jumbo MTU
non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU
case as well

 that said, there is a clear use case for being able to do 1500 MTU packets
 untagged while using jumbos on a vlan...

Yeah

Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/08/21 08:45, Chris Cappuccio wrote:
  Stuart Henderson [st...@openbsd.org] wrote:
   On 2014/08/20 17:17, Chris Cappuccio wrote:
David Gwynne [da...@gwynne.id.au] wrote:
 sthen@ says this is likely a bit optimistic. while most of our 
 drivers unconditionally configure their max mru, there's some stupid 
 ones that still interpret the configured mtu as a what the mru should 
 be.
 

All the more reason to make this change, I'd say :)
   
   it's not just that - there are some like et(4) with obvious trade-offs 
   visible
   in the driver source code which are only wanted in the case where jumbos 
   are
   actually in use. and who knows what various chips will do internally when 
   the
   command to permit jumbos or raise the valid packet size is sent.
   
  
  I don't think this is relevant. If a chip or driver is buggy in the jumbo 
  MTU
  non-vlan case, now it will be buggy in the (somewhat unique) vlan jumbo MTU
  case as well
 
 Oh I was thinking of the case where we changed those drivers to fix things
 so that the 1500 MTU untagged / high MTU tagged state worked which would
 involve downsides for non-jumbo. If you don't care if the new support
 actually works on some chips then that wouldn't apply..
 

Well in the case of if_et, the change the dlg proposes in if_vlan would not
make a difference to the if_et behavior at all. My first glance at et says
hardmtu == mtu 

Re: deprecate scsi_task usage in arc(4)

[Chris Cappuccio]

David Gwynne [da...@gwynne.id.au] wrote:
 can someone test this?
 

Running now.

arc0 at pci3 dev 14 function 0 Areca ARC-1210 rev 0x00: apic 8 int 19
arc0: 4 ports, 256MB SDRAM, firmware V1.43 2007-4-17
scsibus1 at arc0: 16 targets
sd0 at scsibus1 targ 0 lun 0: Areca, ARC-1210-VOL#00, R001 SCSI3 0/direct 
fixed eui.0004d927f800
sd0: 953674MB, 512 bytes/sector, 1953124864 sectors
...
# bioctl arc0
Volume  Status   Size Device  
 arc0 0 Online   99930368 sd0 RAID1 
  0 Online  1000204886016 0:0.0   noencl ST31000528AS CC38
  1 Online  1000204886016 0:1.0   noencl ST31000528AS CC38
# sysctl hw.sensors.arc0
hw.sensors.arc0.drive0=online (sd0), OK

Chris

Re: SSH Sourcing

[Chris Cappuccio]

Nagle, Edwin (James) [edwin.na...@austinenergy.com] wrote:
 Good morning,
 
 My problem is, I am separating users based on interface IP and radius, and 
 therefore need to force their outbound SSH sessions to bind to the IP address 
 of the interface they came in on (or at least a different IP) so I can create 
 firewall rules to restrict outbound access.  However, all outbound SSH 
 sessions are sourced through the default (bnx0) interface and therefore 
 hamper my ability to effectively firewall the outbound SSH requests since the 
 user could be in one of three firewall groups.  I may be just thinking too 
 hard about this but it seems to me there should be (and likely is) a simple 
 way to bind the outgoing connection from the source address.
 
 Any ideas, or should I just create three virtual machines and be done with it?
 
 Again, thanks in advance for any guidance!
 

If each user ID is correlated with a separate IP, you could run different sshd 
each which only allows certain users to log in, and then use pf to restrict 
each user in certain ways. 

Re: re(4) mtu 1500

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
 Does anyone have an idea of what's needed for working jumbos on the
 RL_FLAG_JUMBOV2 variants of re(4) where they're currently disabled?
 These seem to account for most of the chips seen in hardware
 designs from the last couple of years (including APU and some others).
 
 if ((sc-rl_flags  RL_FLAG_JUMBOV2) == 0)
 ifp-if_hardmtu = sc-rl_max_mtu;
 

I think the secrets are here :)

http://svnweb.freebsd.org/base/releng/10.1/sys/dev/re/if_re.c?revision=272461view=markup

Re: re(4) mtu 1500

[Chris Cappuccio]

I like MIMO/SISO better than 1x1 2x2 etc. Fix that shit :)

Stuart Henderson [st...@openbsd.org] wrote:
 On 2014/10/06 12:19, Chris Cappuccio wrote:
  Stuart Henderson [s...@spacehopper.org] wrote:
   Does anyone have an idea of what's needed for working jumbos on the
   RL_FLAG_JUMBOV2 variants of re(4) where they're currently disabled?
   These seem to account for most of the chips seen in hardware
   designs from the last couple of years (including APU and some others).
   
   if ((sc-rl_flags  RL_FLAG_JUMBOV2) == 0)
   ifp-if_hardmtu = sc-rl_max_mtu;
   
  
  I think the secrets are here :)
  
  http://svnweb.freebsd.org/base/releng/10.1/sys/dev/re/if_re.c?revision=272461view=markup
  
 
 Ah, more specifically
 
 http://svnweb.freebsd.org/base?view=revisionrevision=217499 /
 http://svnweb.freebsd.org/base/head/sys/dev/re/if_re.c?r1=217498r2=217499pathrev=217499
 
 OK that's probably more than I can figure out how to port without
 hardware then..

-- 
The bums will always lose

Re: improving OpenBSD's gmac.c...

[Chris Cappuccio]

Christian Weisgerber [na...@mips.inka.de] wrote:
 John-Mark Gurney:
 
  I also have an implementation of ghash that does a 4 bit lookup table
  version with the table split between cache lines in p4 at:
  https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.cREV=4
  
  This also has a version with does 4 blocks at a time getting a
  further speed up...
 
 FWIW, I did a quick  dirty merge of this into the OpenBSD tree and
 the speed of my test (net6501-50, tcpbench -u over esp aes-128-gmac)
 almost doubled.
 

That makes me horny.

Re: pppoe(4), add example for ipv6

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
 Any comments on the diff in this?
 
  +#ifdef INET6
  +   sc-sc_sppp.pp_if.if_xflags = ~IFXF_NOINET6;
  +#endif

Aside from what Stefan said, isn't this flag going to be removed
in favor of a flag that explicitly enables INET6 for interfaces?

Re: LibreSSL: GOST ciphers implementation

[Chris Cappuccio]

?? ?? [art.is...@yandex.ru] wrote:
 On Tue, Nov 04, 2014 at 08:42:03PM +, Miod Vallat wrote:
   Two weeks has passed. Is there anything that I can do to
   push GOST ciphers towards LibreSSL?
  
  Sorry about that. Joel and/or I need to review the diff again and push
  it. I'll try to find time for this next week-end (famous last words).
  
  Miod
 
 This is suspicious person for me (group of people?). There are lots of
 commits since about 2011 in many low-level and/or critical components
 from this person: linux kernel, android, gnupg, tcpdump, alsa, tor,
 openssl etc, etc..
 
 I'm almost certainly wrong, but not too much there competencies for one
 person?

So, you're saying, he's really dmi...@svr.gov.ru, the source of Russian
backdoors into technology worldwide!!!

I guess the open-source ecosystem has been thoroughly poisoned!

Putin is going to take us over. OpenBSD and Linux are ruined! Fuck, I'm
switching to Windows 8.

Re: rtentry leak

[Chris Cappuccio]

Martin Pieuchot [mpieuc...@nolizard.org] wrote:
 
 @@ -653,12 +653,12 @@ ifa_ifwithroute(int flags, struct sockad
   struct rtentry  *rt = rtalloc(gateway, 0, rtableid);
   if (rt == NULL)
   return (NULL);
 - rt-rt_refcnt--;
   /* The gateway must be local if the same address family. */
   if ((rt-rt_flags  RTF_GATEWAY) 
   rt_key(rt)-sa_family == dst-sa_family)
   return (NULL);

And
if ((rt-rt_flags  RTF_GATEWAY) 
rt_key(rt)-sa_family == dst-sa_family) {
+   rtfree(rt);
return (NULL);
}


   ifa = rt-rt_ifa;
 + rtfree(rt);
   if (ifa == NULL || ifa-ifa_ifp == NULL)
   return (NULL);

Re: need help setting an encrypted root FS on dual boot system

[Chris Cappuccio]

Matthieu Herrb [matth...@herrb.eu] wrote:
 Hi,
 
 I've a laptop with  Ubuntu 14.04/OpenBSD-current dual boot. 
 I'm trying to convert the OpenBSD FS to softraid(4) encryption with
 passphrase.
 
 I'm booting from an USB drive to access the disk to shuffle data on
 it. 
 
 After backing up my data, changing the OpenBSD disklabel in sd0 to
 have one RAID partition and one swap partition, running bioctl to
 setup an encrypted sd2 softraid and restoring my data, I'm stuck with 
 bootblocks. 
 
 What is the correct installboot incantation to setup bootblocks so
 that Ubuuntu's grub which chainloads the OpenBSD part of the disk
 loads a softraid-aware biosboot ?
 

Doesn't installboot load the first-stage at the beginning of the OpenBSD
partition according to disklabel? Grub is just replacing the MBR. I don't
understand how crypto would make grub-first-stage step any different.
(for that matter, I also don't understand how the first-stage can even
load the second-stage /boot from an encrypted partition!!)

Re: rtentry leak

[Chris Cappuccio]

Martin Pieuchot [mpieuc...@nolizard.org] wrote:
 
 Indeed!  And the ifa might also be freed so this chunk is completely
 wrong.  Here's a version of the diff without it, ok?
 

This looks ok to me

 
 Index: net/route.c
 ===
 RCS file: /home/ncvs/src/sys/net/route.c,v
 retrieving revision 1.189
 diff -u -p -r1.189 route.c
 --- net/route.c   4 Nov 2014 15:24:40 -   1.189
 +++ net/route.c   6 Nov 2014 10:24:02 -
 @@ -215,7 +215,7 @@ route_init(void)
  {
   struct domain*dom;
  
 - pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtent,
 + pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtentry,
   NULL);
   rn_init();  /* initialize all zeroes, all ones, mask table */
  
 @@ -1220,7 +1220,7 @@ rt_ifa_addloop(struct ifaddr *ifa)
   if (rt == NULL || !ISSET(rt-rt_flags, flags));
   rt_ifa_add(ifa, RTF_UP | flags, ifa-ifa_addr);
   if (rt)
 - rt-rt_refcnt--;
 + rtfree(rt);
  }
  
  /*
 @@ -1267,7 +1267,7 @@ rt_ifa_delloop(struct ifaddr *ifa)
   if (rt != NULL  ISSET(rt-rt_flags, flags))
   rt_ifa_del(ifa, flags, ifa-ifa_addr);
   if (rt)
 - rt-rt_refcnt--;
 + rtfree(rt);
  }
  
  /*

-- 
The bums will always lose

Re: Add Intel Centrino Wireless-N 130 support for iwn

[Chris Cappuccio]

Sylvestre Gallon [ccna@gmail.com] wrote:
 Hi tech@
 
 Here is a diff to allow the iwn driver to work with the intel Wifi Link
 130. It works for me(tm) without problems and solve this bug report : 
 
 Index: sys/dev/pci/if_iwn.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
 retrieving revision 1.121
 diff -u -p -u -p -r1.121 if_iwn.c
 --- sys/dev/pci/if_iwn.c  7 Aug 2013 01:06:35 -   1.121
 +++ sys/dev/pci/if_iwn.c  7 Aug 2013 09:25:43 -
 @@ -90,6 +90,8 @@ static const struct pci_matchid iwn_devi
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_1030_2 },
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_100_1 },
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_100_2 },
 + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_1 },
 + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_2 },
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_1 },
   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_2 },
  };

This part makes sense

 @@ -639,12 +641,8 @@ iwn5000_attach(struct iwn_softc *sc, pci
   break;
   case IWN_HW_REV_TYPE_6005:
   sc-limits = iwn6000_sensitivity_limits;
 - if (pid == PCI_PRODUCT_INTEL_WL_1030_1 ||
 - pid == PCI_PRODUCT_INTEL_WL_1030_2 ||
 - pid == PCI_PRODUCT_INTEL_WL_6030_1 ||
 - pid == PCI_PRODUCT_INTEL_WL_6030_2 ||
 - pid == PCI_PRODUCT_INTEL_WL_6235_1 ||
 - pid == PCI_PRODUCT_INTEL_WL_6235_2) {
 + if (pid != PCI_PRODUCT_INTEL_WL_6005_1 
 + pid != PCI_PRODUCT_INTEL_WL_6005_2) {
   sc-fwname = iwn-6030;
   sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
   } else

This does not. You are adjusting PCI_PRODUCT_INTEL_crap that has
nothing to do with WL_130 which is the only hardware you are testing
with, no?

Re: drm bits on 54.html

[Chris Cappuccio]

Alexey Suslikov [alexey.susli...@gmail.com] wrote:
 On Sat, Aug 10, 2013 at 11:58 AM, Brad Smith b...@comstyle.com wrote:
  - Original message -
  Hi tech@.
 
  54.html says:
 
   Now mostly in sync with Linux 3.8.13
 
  But there's no such thing as Linux X.X.X, there's a Linux kernel X.X.X.
 
  But there is. The later is redundant. Linux is a kernel.
 
 In geek world, maybe, but not in Real World (tm)
 
 http://en.wikipedia.org/wiki/Linux

You guys have it all wrong. It's GNU/Linux !!

Re: OpenBSD on a Nokia IP380

[Chris Cappuccio]

s_gamm...@charter.net [s_gamm...@charter.net] wrote:
 I finally got it to boot successfully.  Not sure what was up with
 the hard drive errors.  Maybe the file system wasn't clean?   After
 I put the drive in the laptop and let it boot Ok, it's been booting
 Ok in the IP380.  I'll see if I can get the network ports to work
 later today.

The errors you got are due to errors reported by the IDE controller back to the 
pciide driver. That's a layer (or two) lower than the filesystem itself. If 
moving the drive around fixed it, perhaps there was a poor connection 
somewhere? (Hell, I just bought an old stereo receiver and had to take it apart 
and reseat every board inside to clean up the sound coming out...)

Since the dc driver doesn't know how to read the MAC addresses from your 
system, your best bet to make those work is to use the 'lladdr' flag so that 
something other than 0 is used on the wire...

-- 
Semicolons; use them

virtio MSI

[Chris Cappuccio]

Here's a simple and obvious change that would be necessary to 
support virtio under bhyve. But it is only acceptable if other
virtio implementations either 1. don't claim to support MSI or
2. also work with MSI.

Index: virtio_pci.c
===
RCS file: /cvs/src/sys/dev/pci/virtio_pci.c,v
retrieving revision 1.6
diff -u -r1.6 virtio_pci.c
--- virtio_pci.c10 Mar 2013 21:58:02 -  1.6
+++ virtio_pci.c18 Sep 2013 14:10:49 -
@@ -211,7 +211,7 @@
goto fail_1;
}
 
-   if (pci_intr_map(pa, ih)) {
+   if (pci_intr_map_msi(pa, ih) != 0  pci_intr_map(pa, ih) != 0) {
printf(%s: couldn't map interrupt\n, vsc-sc_dev.dv_xname);
goto fail_2;
}

Re: virtio MSI

[Chris Cappuccio]

Stefan Fritsch [s...@sfritsch.de] wrote:
 Out of interest, does openbsd run on bhyve with this patch, or are there 
 other problems?
 

I believe Peter Grehan @ FreeBSD is working on the boot loader, and maybe
some driver stuff.

Unless the BIOS emulation is complete, and I don't think it is, it
requires a modified bootloader, and it requires that all emulated devices
implement MSI. But I asked Peter to comment further because I am not
sure of the status.

I think once OpenBSD/amd64 can boot under Bhyve, it makes sense to try 
and port Bhyve to OpenBSD/amd64. Or whatever. The CPU features that
it uses make for minimal system overhead, seems like it is quite a bit
ahead of any other full system virtualization on commodity crap.
Of course minimal overhead means absolutely no legacy support, including
anything prior to MSI interrupts.

Re: Improve routing functions

[Chris Cappuccio]

Lo?c BLOT [loic.b...@unix-experience.fr] wrote:
 Hello sven,
 it's not a routing table problem, it's only a modification on route
 priorities, it's not the same thing.

The two of you are solving totally different problems.

 Here is my example at work:
 
 I have BGP on the WAN, OSPF for my LAN (+ over GRE tunnels) and RIP to
 my CISCO catalyst 45XX.
 
 The problem is simple. I have two routers in this configuration. OSPF is
 prior on RIP. routes obtained by RIP are redistributed on OSPF (because
 my remote sites must know them). But OSPF is prior than RIP and then the
 two border routers want to pass by the other instead of using the RIP
 route.
 I have the same problem with BGP. default route is prior on OSPF than
 BGP. Then BGP must be prior on OSPF to don't loop default route between
 the two routers.

You don't need a new knob in the system to fix this.

You need to fix your configuration.

Re: RTL8111EVL interface on 5.4

[Chris Cappuccio]

Kenta Suzumoto [ken...@hush.com] wrote:
 I'm looking at a board with the Realtek RTL8111EVL NIC.
 I believe it's the same as the RTL8111E. Can anyone confirm/deny
 that this card works with 5.4? I couldn't find it listed in the re or rl 
 manpages.
 
 This is the device http://jetwaycomputer.com/JBC373F38.html

It is likely to work fine. All recent Realtek IDs are supported.

Some newer Realtek-based systems only work with MSI interrupts, you'll need a
-current snapshot to use one of those.

Re: wpi(4) fatal firmware error workaround

[Chris Cappuccio]

Mark Kettenis [mark.kette...@xs4all.nl] wrote:
 Now that wpi(4) does 802.11a, and I'm using my old laptop to test
 inteldrm(4) diffs, I got annoyed that from time to time wpi(4) craps
 out and I have to get out of my lazy chair to bring the interface back
 up.  So here's a diff that automatically reinitializes the hardware if
 this happens. 
 
 ok?
 

I love you.

Re: dhclient support for /32 assignments

[Chris Cappuccio]

Matthew Dempsky [matt...@dempsky.org] wrote:
  
  void
 -add_static_routes(int rdomain, struct option_data *static_routes)
 +add_static_routes(int rdomain, struct in_addr addr, struct in_addr addrmask,
 +struct option_data *static_routes)
  {
   struct in_addr   dest, netmask, gateway;
 - u_int8_t *addr;
 + u_int8_t *data;
...
 + ensure_direct_route(rdomain, addr, addrmask, gateway);

Did you try to compile this?

Re: dhclient support for /32 assignments

[Chris Cappuccio]

Chris Cappuccio [ch...@nmedia.net] wrote:
 Matthew Dempsky [matt...@dempsky.org] wrote:
   
   void
  -add_static_routes(int rdomain, struct option_data *static_routes)
  +add_static_routes(int rdomain, struct in_addr addr, struct in_addr 
  addrmask,
  +struct option_data *static_routes)
   {
  struct in_addr   dest, netmask, gateway;
  -   u_int8_t *addr;
  +   u_int8_t *data;
 ...
  +   ensure_direct_route(rdomain, addr, addrmask, gateway);
 
 Did you try to compile this?

Duh, never mind.

Re: re(4): tedu some unused code

[Chris Cappuccio]

Brad Smith [b...@comstyle.com] wrote:
 tedu some unused code. it has never been enabled and will not be; to
 deal with a hardware defect for rare boards. unmaintained, untested, etc.
 want to get rid of it.
 
 Comments? OK?
 

If RE_DIAG wasn't being compiled in, then it should be removed. The BUGS
section of re(4) needs to be updated to reflect the fact that the driver
does not detect this condition.

OPENBSD FUNDING SOLUTION -- COME AND PARTICIPATE

[Chris Cappuccio]

MJ [m...@sci.fi] wrote:
 
 On 18 Jan 2014, at 04.33, Theo de Raadt dera...@cvs.openbsd.org wrote:
  
  Why is there this effort to convince us to do less?
  
 
 I do not propagate such a train of thought; only said that if you want 
 corporate funding then be prepared to detail your costs and justify each and 
 every one of them as well as satisfying said corporation?s business interest. 
 Not trying to be condescending here at all, but that?s just Logic 101.
 

Logic 101? Do you own a business? Do you make monthly purchasing
decisions for one? Come on, what logic is this? What do you know about it?

Your constant rambling about costs being detailed and justified (and
how that is apparently not being done) is unnerving at best.

In any event, if you were paying attention, it was detailed and justified
about 10 different ways from Sunday in this thread. I suspect $1500 per
month is a drop in the bucket for some of the larger entities that make
extensive use of OpenBSD. No bureaucratic forms filled in triplicate, no
dick sucking, no constant justification, no whining, and no more replies
to this thread. There is a flare-up and we're going to unlock the medicated
pads from JP Morgan Chase!!!

My business makes extensive use of OpenBSD and I'm about to make
a $100 monthly pledge. I'm so sick of the asshole comments in this
thread, I'll take it out of my own pocket should my business be
unable to.

Mike, maybe you can stop your rambling, and just do the same. Because 
otherwise, I don't understand why you feel justified to be on this mailing
list. You were henning's roommate, so that means that you know all about
OpenBSD, programming, commputers, business, Logic 101, and how Theo is not a
businessman? And you have the real solution, right? You can tell everyone how
to make it work?

I'm going to tell you that I probably do know a very little bit about these
things, and even better...get this, MikeI HAVE A SOLUTION.

Please, donate with a subscription, tell everyone how to join you in
doing it, or, fuck yourself. 

I don't want Theo to have to worry about power.

Maybe 14 other business owners in my position can do the same?

Is anyone with me here?

There is this cool web site that automates the process:

http://www.openbsdfoundation.org/donations.html

Chris

USB install image for OpenBSD 5.5 - TESTING REQUIRED

[Chris Cappuccio]

Here are some potential USB installer images for OpenBSD/amd64 5.5

http://www.nmedia.net/chris/install55.fs
http://www.nmedia.net/chris/miniroot55.fs

The install55.fs contains full installation packages. The
miniroot55.fs is a ramdisk-kernel only (for network installation or
troubleshooting.)

Please test either on as many amd64 machines as you can with any USB
flash and any USB-CF adapters that you have.

Report failures and success of each image ASAP. Test as many flash
types (USB, CF-USB, old USB, new USB...) as you can.

SPECIFICALLY, IF you have a boot failure, I need to see the dmesg output
(and the fdisk and disklabel output from the machine if possible to boot
it another way). Any error messages displayed from the boot blocks or
BIOS are also essential.

Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

[Chris Cappuccio]

Chris Cappuccio [ch...@nmedia.net] wrote:
 The installation entails:
 
 dd if=miniroot55.fs of=/dev/rsd2c
 

Actually, for the install55.fs image, you want to specify a block size,
(or wait ages.)

dd if=install55.fs of=/dev/rsd2c bs=1m

It's something like 20x faster to specify a block size on some of mine.

The 512 byte default block size is so small, it must cause the USB key
to re-write the same physical block multiple times. These devices have
underlying blocks of 4K and larger.

Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

[Chris Cappuccio]

Loganaden Velvindron [logana...@gmail.com] wrote:
 
 That's OpenBSD -current right ? I'm going to test it in the afternoon,
 as the CDROM
 drive has issues on my OpenBSD development machine.
 

Yes. The correct .fs images for testing are now the i386 and amd64 snapshot
versions on the OpenBSD sites. 

Re: Boot network for remote unlock of fde

[Chris Cappuccio]

Giancarlo Razzolini [grazzol...@gmail.com] wrote:
 
 One byproduct of such design would be the possibility of redirecting the
 console to the ssh connection. I know this is deranging from the initial
 idea, but make perfect sense. Anyway, I noted your concerns on this.
 Now, anyone have any design idea for implementing this?
 

Personally I think this sort-of soft-IPMI is a pretty cool idea and I found
Matthieu's reply enlightening as well.

Apparently Linux has made some progress beyond pivot_root and there are
some interesting ideas there. (Note that we have a functioning tmpfs.)

http://www.spinics.net/lists/util-linux-ng/msg08794.html

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Evolving the kernel ramdisk to extract archive to a tmpfs might be the right
thing to do if the BSD tmpfs has the same advantages (doesn't run the
backing store back through the buffer cache etc.)

Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

[Chris Cappuccio]

sven falempin [sven.falem...@gmail.com] wrote:
 Some issue here, using install55.fs (today 18/3/2014 downloaded snaps)
 
 boot is ok (warn: entropy file missing)
 
 but /dev has no /dev/sd1 (is the usb key) and so i cannot look for the sets .
 
 I did MAKEDEV all so i can mount keys to get the dmesg.
 

The install script will create the devices on demand, as needed to mount
the source sets

 currently outputing dmesg on usb3 key, the machine has no plug for the
 com port, no idea how to get the boot infos (i am bad at soldering)
 
 I fdisk the key, but i cannot disklabel it ( out of inode )
 

This is because you ran MAKEDEV all, the ramdisk has only minimal inodes 
available

Re: OpenBSD Foundation 2014 Fundraising Campaign.

[Chris Cappuccio]

nobody [openbsd.as.a.desk...@gmail.com] wrote:
 Hi all,
 
 -
 1)
 If I search for openbsdfoundation on:
 
 - Facebook
 - Twitter
 - Youtube
 - Instagram
 - Flickr
 - Slideshare
 - etc..
 
 I get ZERO results regarding the topic.
 

I was thinking, maybe a superbowl commercial.

Re: iSCSI in recent Supermicro boards

[Chris Cappuccio]

This is some kind of BIOS boot-up support

The chips on this board are run-of-the-mill em

OpenBSD 4.9-current (GENERIC.MP) #32: Sat Apr 23 18:16:16 PDT 2011
ch...@celery.ykwc.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8580038656 (8182MB)
avail mem = 8337596416 (7951MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9f000 (68 entries)
bios0: vendor American Megatrends Inc. version 1.1 date 05/27/2010
bios0: Supermicro X8SIL
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI SSDT EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) BR1E(S4) 
PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) 
USB6(S4) GBE_(S4) BR20(S4) BR21(S4) BR22(S4) BR23(S4) BR24(S4) BR25(S4) 
BR26(S4) BR27(S4) EUSB(S4) USBE(S4) SLPB(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 X3430 @ 2.40GHz, 2400.33 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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2400.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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2400.00 MHz
cpu2: 
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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2400.00 MHz
cpu3: 
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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 7 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 7
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P3)
acpiprt3 at acpi0: bus 2 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpiprt5 at acpi0: bus 6 (BR1E)
acpiprt6 at acpi0: bus 3 (BR20)
acpiprt7 at acpi0: bus 4 (BR24)
acpiprt8 at acpi0: bus 5 (BR25)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 2400 MHz: speeds: 2401, 2400, 2267, 2133, 2000, 1867, 
1733, 1600, 1467, 1333, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core DMI rev 0x11
ppb0 at pci0 dev 3 function 0 Intel Core PCIE rev 0x11: apic 7 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 5 function 0 Intel Core PCIE rev 0x11: apic 7 int 16
pci2 at ppb1 bus 2
Intel Core Management rev 0x11 at pci0 dev 8 function 0 not configured
Intel Core Scratch rev 0x11 at pci0 dev 8 function 1 not configured
Intel Core Control rev 0x11 at pci0 dev 8 function 2 not configured
Intel Core Misc rev 0x11 at pci0 dev 8 function 3 not configured
Intel Core QPI Link rev 0x11 at pci0 dev 16 function 0 not configured
Intel Core QPI Routing rev 0x11 at pci0 dev 16 function 1 not configured
ppb2 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x05: apic 7 int 17
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 4 Intel 3400 PCIE rev 0x05: apic 7 int 17
pci4 at ppb3 bus 4
em0 at pci4 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 7 int 
16, address 00:25:90:0d:63:f0
ppb4 at pci0 dev 28 function 5 Intel 3400 PCIE rev 0x05: apic 7 int 16
pci5 at ppb4 bus 5
em1 at pci5 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: apic 7 int 
17, address 00:25:90:0d:63:f1
ehci0 at pci0 dev 29 function 0 Intel 3400 USB rev 0x05: apic 7 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb5 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xa5
pci6 at ppb5 bus 6
vga1 at pci6 dev 3 function 0 Matrox MGA G200eW rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 Intel 3400 LPC rev 0x05
ahci0 at pci0 dev 31 function 2 Intel 3400 AHCI rev 0x05: apic 7 int 19, AHCI 
1.3
ahci0: invalid ata_xfer state 06 in ahci_put_ccb, slot 31
ahci0: invalid ata_xfer state 06 in 

Re: umass trouble with USB flash drive

[Chris Cappuccio]

Matt Rowley [m...@arin.net] wrote:
 
 Hi, Zvezdan... not to be pedantic, but have you confirmed the flash
 drive working on another machine?  The only time I've seen errors
 like that, the drive itself was nearing its demise.

Nonsense. We all know how modern flash never fails!

-- 
There are only three sports: bullfighting, motor racing, and mountaineering; 
all the rest are merely games. - E. Hemingway

Re: SiS 1183 SATA controller support

[Chris Cappuccio]

Loganaden Velvindron [logana...@devio.us] wrote:
 
 The SiS 1183 is weird in the sense that it shows as an
 IDE device when in fact, it's a SATA controller. I don't
 see any reason why this is necessary.
 

The physical interface is unimportant. The software interface is the same, 
unless you force the chip into AHCI mode. And that's only if it even supports 
AHCI!

-- 
There are only three sports: bullfighting, motor racing, and mountaineering; 
all the rest are merely games. - E. Hemingway

Re: rc.d unbound daemon start order

[Chris Cappuccio]

Peter Bisroev [pe...@int19h.net] wrote:

 After looking in the 'starting early daemons:' section in /etc/rc I ccan see 
 that
 named and nsd are started before ntpd. If named is used as a recursive caching
 DNS server everything would work as expected. But with nsd that would not be 
 the
 case since it is an authoritative only server.

I suspect you want a feature like this. It would give you a pkg_early_scripts 
option to go in rc.conf.local along with your pkg_scripts.

--- /etc/rc Fri Dec  9 10:13:53 2011
+++ rc  Wed Jan  4 23:26:17 2012
@@ -232,6 +232,9 @@
 if [ X$1 = Xshutdown ]; then
dd if=/dev/arandom of=/var/db/host.random bs=65536 count=1 /dev/null 
21
chmod 600 /var/db/host.random /dev/null 21
+   if [ -n ${pkg_early_scripts} ]; then
+   pkg_scripts=${pkg_scripts} ${pkg_early_scripts}
+   fi
local _c=$?
if [ ${_c} -eq 0 -a -n ${pkg_scripts} ]; then
echo -n 'stopping package daemons:'
@@ -394,6 +397,15 @@
 dmesg /var/run/dmesg.boot
 
 make_keys
+
+# Run rc.d(8) early scripts from packages
+if [ -n ${pkg_early_scripts} ]; then
+   echo -n 'starting early package daemons:'
+   for _r in $pkg_early_scripts; do
+   [ -x /etc/rc.d/${_r} ]  start_daemon ${_r}
+   done
+   echo '.'
+fi
 
 echo -n 'starting early daemons:'
 start_daemon syslogd ldattach pflogd named nsd ntpd isakmpd iked sasyncd

Re: rc.d unbound daemon start order

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
 
 Alternatively I think it would work to add !/etc/rc.d/unbound start
 to a suitable hostname.if file, though that's a bit of a hack and this
 seems like a useful addition (some people like to use an alternative
 syslogd which is another good candidate for starting early).

After reading this, it occurs to me, syslogd should be moved above 
pkg_early_scripts initialization, so if you happen to be using the system 
syslogd, you won't miss any opening messages from unbound (e.g. your config 
file is broke)

Re: rc.d unbound daemon start order

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:

 Alternatively I think it would work to add !/etc/rc.d/unbound start
 to a suitable hostname.if file, though that's a bit of a hack and this
 seems like a useful additioto use an alternative
 syslogd which is another good candidate for starting early) .

This is slightly better for the unbound use case, keeps from adding another 
line of text at startup, and still works fine if you were going to usurp 
syslogd with an early script as well.

--- /etc/rc Fri Dec  9 10:13:53 2011
+++ rc  Thu Jan  5 01:00:21 2012
@@ -232,6 +232,9 @@
 if [ X$1 = Xshutdown ]; then
dd if=/dev/arandom of=/var/db/host.random bs=65536 count=1 /dev/null 
21
chmod 600 /var/db/host.random /dev/null 21
+   if [ -n ${pkg_early_scripts} ]; then
+   pkg_scripts=${pkg_scripts} ${pkg_early_scripts}
+   fi
local _c=$?
if [ ${_c} -eq 0 -a -n ${pkg_scripts} ]; then
echo -n 'stopping package daemons:'
@@ -396,7 +399,14 @@
 make_keys
 
 echo -n 'starting early daemons:'
-start_daemon syslogd ldattach pflogd named nsd ntpd isakmpd iked sasyncd
+start_daemon syslogd
+# Run rc.d(8) early scripts from packages
+if [ -n ${pkg_early_scripts} ]; then
+   for _r in $pkg_early_scripts; do
+   [ -x /etc/rc.d/${_r} ]  start_daemon ${_r}
+   done
+fi
+start_daemon ldattach pflogd named nsd ntpd isakmpd iked sasyncd
 start_daemon ldapd
 echo '.'

Re: rc.d unbound daemon start order

[Chris Cappuccio]

Peter Bisroev [pe...@int19h.net] wrote:

 Thank you for a quick response guys! Chris if you are talking about
 modifying /etc/rc does that mean that there could be a plan in the
 future to add that to the CVS? In the interim, should I test your
 patch or is Stuart's way of starting unbound should be used for now?

 Cheers,
 --peter

This might be suitable to commit. Stuart?

Index: etc/rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.397
diff -u -r1.397 rc
--- etc/rc  9 Dec 2011 14:52:26 -   1.397
+++ etc/rc  6 Jan 2012 19:10:29 -
@@ -232,6 +232,9 @@
 if [ X$1 = Xshutdown ]; then
dd if=/dev/arandom of=/var/db/host.random bs=65536 count=1 /dev/null 
21
chmod 600 /var/db/host.random /dev/null 21
+   if [ -n ${pkg_early_scripts} ]; then
+   pkg_scripts=${pkg_scripts} ${pkg_early_scripts}
+   fi
local _c=$?
if [ ${_c} -eq 0 -a -n ${pkg_scripts} ]; then
echo -n 'stopping package daemons:'
@@ -396,7 +399,14 @@
 make_keys
 
 echo -n 'starting early daemons:'
-start_daemon syslogd ldattach pflogd named nsd ntpd isakmpd iked sasyncd
+start_daemon syslogd
+# Run rc.d(8) early scripts from packages
+if [ -n ${pkg_early_scripts} ]; then
+   for _r in $pkg_early_scripts; do
+   [ -x /etc/rc.d/${_r} ]  start_daemon ${_r}
+   done
+fi
+start_daemon ldattach pflogd named nsd ntpd isakmpd iked sasyncd
 start_daemon ldapd
 echo '.'
 
Index: share/man/man8/rc.conf.8
===
RCS file: /cvs/src/share/man/man8/rc.conf.8,v
retrieving revision 1.19
diff -u -r1.19 rc.conf.8
--- share/man/man8/rc.conf.88 Jul 2011 17:43:58 -   1.19
+++ share/man/man8/rc.conf.86 Jan 2012 19:10:29 -
@@ -103,7 +103,9 @@
 .Pp
 The fourth section contains the
 .Va pkg_scripts
-variable, responsible for starting and stopping
+and
+.Va pkg_early_scripts
+variables, responsible for starting and stopping
 .Xr rc.d 8
 scripts installed by packages in the specified order.
 For example, the following line
@@ -120,6 +122,16 @@
 argument at boot time and in reverse order with the
 .Va stop
 argument at shutdown.
+Packages listed in the
+.Va pkg_early_scripts
+variable are started before any other system daemons, except syslogd. The
+.Va pkg_early_scripts
+variable is suitable for starting package daemons needed early, such
+as syslog or resolver packages which are replacing system daemons.
+Many packages can not be started early, as ldconfig has not initialized
+the shared library cache for package libraries prior to the
+.Va pkg_early_scripts
+entry point.
 .Sh SEE ALSO
 .Xr init 8 ,
 .Xr intro 8 ,
Index: share/man/man8/rc.d.8
===
RCS file: /cvs/src/share/man/man8/rc.d.8,v
retrieving revision 1.20
diff -u -r1.20 rc.d.8
--- share/man/man8/rc.d.8   9 Oct 2011 08:54:29 -   1.20
+++ share/man/man8/rc.d.8   6 Jan 2012 19:10:29 -
@@ -45,7 +45,9 @@
 .Xr packages 7
 may be started at boot time in the order specified by the
 .Va pkg_scripts
-variable from
+and
+.Va pkg_early_scripts
+variables from
 .Xr rc.conf 8 ;
 the order will be reversed during shutdown.
 Services comprising

Re: SiS 5513 rev 0x015597/5598 freeze diff

[Chris Cappuccio]

Jonathan Gray [j...@goblin.cx] wrote:
 
 I've committed this now.  Unknown SiS devices could still be attached
 with udma disabled if we were sure the 5597/5598 case is only
 used in machines with 5597_HB and and another else.

Ironically, according to Logan's experience as he tried to get this working, 
the 5597/5598 code worked fine in UDMA mode on his 968, but didn't work in MW 
DMA mode. I suggested that he try to move the 5597/5598 check to sis_hostbr. 
The chip also has a pure SATA pciide mode that apparently works and AHCI.

Re: rc.d unbound daemon start order

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
 iirc there were some objections to it.
 

I don't see any other way to accommodate ports that require early start in the 
rc.d system other than to PUT THEM FIRST. Otherwise, rc.d scripts for certain 
items need to be manually inserted into /etc/rc. How stupid is that ?

Re: rc.d unbound daemon start order

[Chris Cappuccio]

Antoine Jacoutot [ajacou...@bsdfrog.org] wrote:
  
  I don't see any other way to accommodate ports that require early start in 
  the rc.d system other than to PUT THEM FIRST. Otherwise, rc.d scripts for 
  certain items need to be manually inserted into /etc/rc. How stupid is that 
  ?
 
 First calm down.
 
 For now you can try cp /etc/rc.d/syslog-ng /etc/rc.d/syslogd.
 I'm not saying the current situation is perfect but what would be next after 
 pkg_early_scripts? pkg_late_scripts for stuffs that need to be started after 
 apm or cron or xdm ...?

Honestly, I'm not aware of any examples where this is necessary. Where it 
actually is necessary is for items that replace system daemons that need to 
start earlier than everything else.

Any example where you have to edit /etc/rc or have to replace /etc/rc.d scripts 
makes upgrades more complicated than need to be. Of course, replacing an 
/etc/rc.d script is preferrable to editing /etc/rc. Adding pkg_early_scripts 
which solves every problem and the only complaint is that it's 'another knob'. 
But as long as ports exist which need to start early, it's a useful knob that 
actually makes sense.

 I don't want to introduce a new knob^variable for each and every situation, 
 sorry can't please everyone.
 
 That said we may be able to come with something else in the future I don't 
 know.
 

Like what?

Re: rc.d unbound daemon start order

[Chris Cappuccio]

Mark Kettenis [mark.kette...@xs4all.nl] wrote:
 
 Perhaps not as stupid as you think.
 
 OpenBSD provides a complete base OS.  In principle you only need to
 install packages for add-on software.  And there should be no need for
 such add-on software to be started before the base system is up and
 running.  You only run into problems when you try to replace things
 from the base system with stuff from ports.  I'd argue that in that
 case you're no longer running OpenBSD, and therefore it is a good
 thing you need to go through some hoops in order to do this.
 
 In the particular case of unbound, there is some consensus that we
 should replace BIND in base with nsd and unbound.  But it seems nobody
 actually cares enough to do the work to make this happen.

If rc.d provides functionality, it should be usable in cases where you expect 
it to, or it should at least be documented why it is broken.

If an alternative server for syslogd, ldattach, pflogd, named, nsd, ntpd, 
isakmpd, iked, sasyncd, or ldapd isn't suitable then why is it even in ports ? 
Some people have specific needs that most people don't? Some of these tools are 
generally known to be lower quality, yet stay in ports for the same reason. 
They're useful, but not encouraged. We don't want to make rc.d good enough to 
help these people because it's another knob.

So, the perception here is that rc.d is aimed at the set it and forget it 
folks who aren't qualified to use ports? Do you use rc.d? I use rc.d. And, 
probably like you, I used it because it was convenient. And, I am satisfied 
with it. So while I understand the arguments against fully implementing rc.d, I 
can't agree that I don't want the pkg_early_scripts convenience there for 
myself.

Re: base httpd ProxyPreserveHost not working

[Chris Cappuccio]

Jacob L. Leifman [jac...@bitwise.net] wrote:
 
 Please let me know if/what additional diagnostic info is needed, or 
 hopefully patches to test.
 

Effort is going away from improving httpd in base (as you can see from the lack 
of commits in recent years) and instead preferring nginx. Nginx is in -current 
base and it has a fast and capable reverse proxy. On 4.9, install the package 
and carry your config over when you upgrade to 5.2 (or 5.1-current)

Re: acpihpet quality

[Chris Cappuccio]

Mark Kettenis [mark.kette...@xs4all.nl] wrote:
  Date: Wed, 15 Aug 2012 11:02:43 -0400
  From: Ted Unangst t...@tedunangst.com
  
  The acpihpet timer is, in my testing, lots better than the acpitimer.
  Faster to read and more precise.  They should not have the same quality
  value.  Double acpihpet.
 
 Since both acpitimer(4) and acpihpet(4) are based on an abstract
 specification that AFAIK doesn't say anything about the actual
 underlying hardware I'm totally unconvinced unless you can show this
 to be true on a wide variety of hardware.
 

HPET on some processors is emulated in software via BIOS. Ring -1 or whatever.  
I believe one of either the AMD Elan SC420 or the AMD Geode LX fits in this 
category.

Re: acpihpet quality

[Chris Cappuccio]

Ted Unangst [t...@tedunangst.com] wrote:
 On Thu, Sep 13, 2012 at 15:46, Chris Cappuccio wrote:
  Mark Kettenis [mark.kette...@xs4all.nl] wrote:
   Date: Wed, 15 Aug 2012 11:02:43 -0400
   From: Ted Unangst t...@tedunangst.com
  
   The acpihpet timer is, in my testing, lots better than the acpitimer.
   Faster to read and more precise.  They should not have the same quality
   value.  Double acpihpet.
 
  Since both acpitimer(4) and acpihpet(4) are based on an abstract
  specification that AFAIK doesn't say anything about the actual
  underlying hardware I'm totally unconvinced unless you can show this
  to be true on a wide variety of hardware.
 
  
  HPET on some processors is emulated in software via BIOS. Ring -1 or
  whatever.  I believe one of either the AMD Elan SC420 or the AMD Geode LX
  fits in this category.
 
 hpet or just regular acpi timer?

I'm not sure why I thought it was those two. 

Must be this that i'm thinking of from acpihpet.c but it's for a newer chip 
that provides an HPET (sometimes).

/*
 * Revisions 0x30 through 0x3a of the AMD SB700, with spread
 * spectrum enabled, have an SMM based HPET emulation that's
 * subtly broken.  The hardware is initialized upon first
 * access of the configuration register.  Initialization takes
 * some time during which the configuration register returns
 * 0x.
 */

Re: ln -s example

[Chris Cappuccio]

Amit Kulkarni [amitk...@gmail.com] wrote:
 shouldn't this order be flipped?
 

If you wanted a link in /var/www/www back to /home/www, then yes, it should be 
flipped.

 Index: ln.1
 ===
 RCS file: /cvs/src/bin/ln/ln.1,v
 retrieving revision 1.29
 diff -u -p -r1.29 ln.1
 --- ln.1  2 Mar 2011 07:47:21 -   1.29
 +++ ln.1  19 Sep 2012 23:27:04 -
 @@ -130,7 +130,7 @@ Create a symbolic link named
  and point it to
  .Pa /var/www :
  .Pp
 -.Dl # ln -s /var/www /home/www
 +.Dl # ln -s /home/www /var/www
  .Pp
  Hard link
  .Pa /usr/local/bin/fooprog

-- 
Keep them laughing half the time, scared of you the other half. And always keep 
them guessing. -- Clair George

tx dma segments for if_vr

[Chris Cappuccio]

Darren Tucker's vlan tagging for vr motivated me. Here is a diff that 
implements transmit DMA segments, instead of copying fragmented mbufs every 
time. This should be a win for userland traffic, and NFS. It also implements a 
FreeBSD feature to only ask for TX completion interrupts every 8 packets, 
instead of every packet, which is another win for weak CPUs. FreeBSD has been 
doing DMA tx segments and 1/8 completion interrupts for 4 years across the same 
chips. Annoyingly, on first glance, the rhine chip still seems to send the same 
number completion interrupts. But it's clear that bus_dmamap_load_mbuf no 
longer fails at the top of vr_encap on packets with 8 or less mbuf fragments, 
avoiding the whole new mbuf and m_copydata dance for the majority of situations 
now. The next win would be to copy reyk's method from if_myx to create a new 
DMA segment for padding packets  VR_MINFRAMELEN instead of create a whole new 
mbuf and copying. Micro-optimizations for micro-platforms.

This is heavily influenced by yongari@FreeBSD's work 4 years ago. (In fact, 
maybe too much so. As far as I can tell, allowing for DMA transfers of MCLBYTES 
* VR_MAXFRAGS is overkill since a packet over the size of MCLBYTES isn't even 
possible with this chip. Also returns from vr_encap are now ENOFBUFS but the 
error gets ignored upstream at this point.)

Index: if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.115
diff -u -r1.115 if_vr.c
--- if_vr.c 18 Sep 2012 14:49:44 -  1.115
+++ if_vr.c 4 Oct 2012 17:12:08 -
@@ -113,7 +113,7 @@
NULL, vr, DV_IFNET
 };
 
-int vr_encap(struct vr_softc *, struct vr_chain *, struct mbuf *);
+int vr_encap(struct vr_softc *, struct vr_chain **, struct mbuf *);
 void vr_rxeof(struct vr_softc *);
 void vr_rxeoc(struct vr_softc *);
 void vr_txeof(struct vr_softc *);
@@ -720,13 +720,17 @@
 
cd = sc-vr_cdata;
ld = sc-vr_ldata;
+
+   cd-vr_tx_pkts = 0;
+   cd-vr_tx_cnt = 0;
+
for (i = 0; i  VR_TX_LIST_CNT; i++) {
cd-vr_tx_chain[i].vr_ptr = ld-vr_tx_list[i];
cd-vr_tx_chain[i].vr_paddr =
sc-sc_listmap-dm_segs[0].ds_addr +
offsetof(struct vr_list_data, vr_tx_list[i]);
 
-   if (bus_dmamap_create(sc-sc_dmat, MCLBYTES, 1,
+   if (bus_dmamap_create(sc-sc_dmat, MCLBYTES * VR_MAXFRAGS, 
VR_MAXFRAGS,
MCLBYTES, 0, BUS_DMA_NOWAIT, cd-vr_tx_chain[i].vr_map))
return (ENOBUFS);
 
@@ -984,11 +988,13 @@
 * frames that have been transmitted.
 */
cur_tx = sc-vr_cdata.vr_tx_cons;
-   while(cur_tx-vr_mbuf != NULL) {
-   u_int32_t   txstat;
+   while (cur_tx != sc-vr_cdata.vr_tx_prod) {
+   
+   u_int32_t   txstat, txctl;
int i;
 
txstat = letoh32(cur_tx-vr_ptr-vr_status);
+   txctl = letoh32(cur_tx-vr_ptr-vr_ctl);
 
if ((txstat  VR_TXSTAT_ABRT) ||
(txstat  VR_TXSTAT_UDF)) {
@@ -1002,7 +1008,7 @@
sc-vr_flags |= VR_F_RESTART;
break;
}
-   VR_TXOWN(cur_tx) = htole32(VR_TXSTAT_OWN);
+   cur_tx-vr_ptr-vr_status = htole32(VR_TXSTAT_OWN);
CSR_WRITE_4(sc, VR_TXADDR, cur_tx-vr_paddr);
break;
}
@@ -1010,6 +1016,11 @@
if (txstat  VR_TXSTAT_OWN)
break;
 
+   sc-vr_cdata.vr_tx_cnt--;
+   /* Only the first descriptor in the chain is valid. */
+   if ((txctl  VR_TXCTL_FIRSTFRAG) == 0)
+   goto next;
+
if (txstat  VR_TXSTAT_ERRSUM) {
ifp-if_oerrors++;
if (txstat  VR_TXSTAT_DEFER)
@@ -1028,11 +1039,12 @@
cur_tx-vr_mbuf = NULL;
ifp-if_flags = ~IFF_OACTIVE;
 
+next:
cur_tx = cur_tx-vr_nextdesc;
}
 
sc-vr_cdata.vr_tx_cons = cur_tx;
-   if (cur_tx-vr_mbuf == NULL)
+   if (sc-vr_cdata.vr_tx_cnt == 0)
ifp-if_timer = 0;
 }
 
@@ -1164,19 +1176,22 @@
  * pointers to the fragment pointers.
  */
 int
-vr_encap(struct vr_softc *sc, struct vr_chain *c, struct mbuf *m_head)
+vr_encap(struct vr_softc *sc, struct vr_chain **cp, struct mbuf *m_head)
 {
+   struct vr_chain *c = *cp;
struct vr_desc  *f = NULL;
struct mbuf *m_new = NULL;
-   u_int32_t   vr_flags = 0, vr_status = 0;
+   u_int32_t   vr_ctl = 0, vr_status = 0;
+   bus_dmamap_ttxmap;
+   int i;
 
if (sc-vr_quirks  VR_Q_CSUM) {
if 

if_vr tx dma segs with zero pad

[Chris Cappuccio]

same as last diff, plus zero pad small frames with an extra, zeroed dma segment 
instead of a copy (a la myx)

Index: if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.115
diff -u -r1.115 if_vr.c
--- if_vr.c 18 Sep 2012 14:49:44 -  1.115
+++ if_vr.c 5 Oct 2012 17:48:42 -
@@ -113,13 +113,16 @@
NULL, vr, DV_IFNET
 };
 
-int vr_encap(struct vr_softc *, struct vr_chain *, struct mbuf *);
+int vr_encap(struct vr_softc *, struct vr_chain **, struct mbuf *);
 void vr_rxeof(struct vr_softc *);
 void vr_rxeoc(struct vr_softc *);
 void vr_txeof(struct vr_softc *);
 void vr_tick(void *);
 void vr_rxtick(void *);
 int vr_intr(void *);
+int vr_dmamem_alloc(struct vr_softc *, struct vr_dmamem *,
+bus_size_t, u_int);
+void vr_dmamem_free(struct vr_softc *, struct vr_dmamem *);
 void vr_start(struct ifnet *);
 int vr_ioctl(struct ifnet *, u_long, caddr_t);
 void vr_chipinit(struct vr_softc *);
@@ -481,6 +484,46 @@
return(0);
 }
 
+int
+vr_dmamem_alloc(struct vr_softc *sc, struct vr_dmamem *vrm,
+bus_size_t size, u_int align)
+{
+   vrm-vrm_size = size;
+
+   if (bus_dmamap_create(sc-sc_dmat, vrm-vrm_size, 1,
+   vrm-vrm_size, 0, BUS_DMA_WAITOK | BUS_DMA_ALLOCNOW,
+   vrm-vrm_map) != 0)
+   return (1);
+   if (bus_dmamem_alloc(sc-sc_dmat, vrm-vrm_size,
+   align, 0, vrm-vrm_seg, 1, vrm-vrm_nsegs,
+   BUS_DMA_WAITOK | BUS_DMA_ZERO) != 0)
+   goto destroy;
+   if (bus_dmamem_map(sc-sc_dmat, vrm-vrm_seg, vrm-vrm_nsegs,
+   vrm-vrm_size, vrm-vrm_kva, BUS_DMA_WAITOK) != 0)
+   goto free;
+   if (bus_dmamap_load(sc-sc_dmat, vrm-vrm_map, vrm-vrm_kva,
+   vrm-vrm_size, NULL, BUS_DMA_WAITOK) != 0)
+   goto unmap;
+
+   return (0);
+ unmap:
+   bus_dmamem_unmap(sc-sc_dmat, vrm-vrm_kva, vrm-vrm_size);
+ free:
+   bus_dmamem_free(sc-sc_dmat, vrm-vrm_seg, 1);
+ destroy:
+   bus_dmamap_destroy(sc-sc_dmat, vrm-vrm_map);
+   return (1);
+}
+
+void
+vr_dmamem_free(struct vr_softc *sc, struct vr_dmamem *vrm)
+{
+   bus_dmamap_unload(sc-sc_dmat, vrm-vrm_map);
+   bus_dmamem_unmap(sc-sc_dmat, vrm-vrm_kva, vrm-vrm_size);
+   bus_dmamem_free(sc-sc_dmat, vrm-vrm_seg, 1);
+   bus_dmamap_destroy(sc-sc_dmat, vrm-vrm_map);
+}
+
 /*
  * Attach the interface. Allocate softc structures, do ifmedia
  * setup and ethernet/BPF attach.
@@ -497,8 +540,6 @@
const char  *intrstr = NULL;
struct ifnet*ifp = sc-arpcom.ac_if;
bus_size_t  size;
-   int rseg;
-   caddr_t kva;
 
/*
 * Handle power management nonsense.
@@ -555,7 +596,7 @@
/* Allocate interrupt */
if (pci_intr_map(pa, ih)) {
printf(: can't map interrupt\n);
-   goto fail_1;
+   goto fail;
}
intrstr = pci_intr_string(pc, ih);
sc-sc_ih = pci_intr_establish(pc, ih, IPL_NET, vr_intr, sc,
@@ -565,7 +606,7 @@
if (intrstr != NULL)
printf( at %s, intrstr);
printf(\n);
-   goto fail_1;
+   goto fail;
}
printf(: %s, intrstr);
 
@@ -593,29 +634,20 @@
printf(, address %s\n, ether_sprintf(sc-arpcom.ac_enaddr));
 
sc-sc_dmat = pa-pa_dmat;
-   if (bus_dmamem_alloc(sc-sc_dmat, sizeof(struct vr_list_data),
-   PAGE_SIZE, 0, sc-sc_listseg, 1, rseg,
-   BUS_DMA_NOWAIT | BUS_DMA_ZERO)) {
-   printf(: can't alloc list\n);
-   goto fail_2;
-   }
-   if (bus_dmamem_map(sc-sc_dmat, sc-sc_listseg, rseg,
-   sizeof(struct vr_list_data), kva, BUS_DMA_NOWAIT)) {
-   printf(: can't map dma buffers (%d bytes)\n,
-   sizeof(struct vr_list_data));
-   goto fail_3;
-   }
-   if (bus_dmamap_create(sc-sc_dmat, sizeof(struct vr_list_data), 1,
-   sizeof(struct vr_list_data), 0, BUS_DMA_NOWAIT, sc-sc_listmap)) {
-   printf(: can't create dma map\n);
-   goto fail_4;
-   }
-   if (bus_dmamap_load(sc-sc_dmat, sc-sc_listmap, kva,
-   sizeof(struct vr_list_data), NULL, BUS_DMA_NOWAIT)) {
-   printf(: can't load dma map\n);
-   goto fail_5;
+   if (vr_dmamem_alloc(sc, sc-sc_zeromap, 64, PAGE_SIZE) != 0) {
+   printf(: failed to allocate zero pad memory\n);
+   return;
+   }
+   bzero(sc-sc_zeromap.vrm_kva, 64);
+   bus_dmamap_sync(sc-sc_dmat, sc-sc_zeromap.vrm_map, 0,
+   sc-sc_zeromap.vrm_map-dm_mapsize, BUS_DMASYNC_PREREAD);
+   if (vr_dmamem_alloc(sc, sc-sc_listmap, sizeof(struct vr_list_data),
+   PAGE_SIZE) != 0) {
+   printf(: failed to allocate dma map\n);
+   goto free_zero;
}
-   sc-vr_ldata = (struct 

one more

[Chris Cappuccio]

proper ring size check when runt segment is added

Index: if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.115
diff -u -r1.115 if_vr.c
--- if_vr.c 18 Sep 2012 14:49:44 -  1.115
+++ if_vr.c 5 Oct 2012 18:22:36 -
@@ -113,13 +113,16 @@
NULL, vr, DV_IFNET
 };
 
-int vr_encap(struct vr_softc *, struct vr_chain *, struct mbuf *);
+int vr_encap(struct vr_softc *, struct vr_chain **, struct mbuf *);
 void vr_rxeof(struct vr_softc *);
 void vr_rxeoc(struct vr_softc *);
 void vr_txeof(struct vr_softc *);
 void vr_tick(void *);
 void vr_rxtick(void *);
 int vr_intr(void *);
+int vr_dmamem_alloc(struct vr_softc *, struct vr_dmamem *,
+bus_size_t, u_int);
+void vr_dmamem_free(struct vr_softc *, struct vr_dmamem *);
 void vr_start(struct ifnet *);
 int vr_ioctl(struct ifnet *, u_long, caddr_t);
 void vr_chipinit(struct vr_softc *);
@@ -481,6 +484,46 @@
return(0);
 }
 
+int
+vr_dmamem_alloc(struct vr_softc *sc, struct vr_dmamem *vrm,
+bus_size_t size, u_int align)
+{
+   vrm-vrm_size = size;
+
+   if (bus_dmamap_create(sc-sc_dmat, vrm-vrm_size, 1,
+   vrm-vrm_size, 0, BUS_DMA_WAITOK | BUS_DMA_ALLOCNOW,
+   vrm-vrm_map) != 0)
+   return (1);
+   if (bus_dmamem_alloc(sc-sc_dmat, vrm-vrm_size,
+   align, 0, vrm-vrm_seg, 1, vrm-vrm_nsegs,
+   BUS_DMA_WAITOK | BUS_DMA_ZERO) != 0)
+   goto destroy;
+   if (bus_dmamem_map(sc-sc_dmat, vrm-vrm_seg, vrm-vrm_nsegs,
+   vrm-vrm_size, vrm-vrm_kva, BUS_DMA_WAITOK) != 0)
+   goto free;
+   if (bus_dmamap_load(sc-sc_dmat, vrm-vrm_map, vrm-vrm_kva,
+   vrm-vrm_size, NULL, BUS_DMA_WAITOK) != 0)
+   goto unmap;
+
+   return (0);
+ unmap:
+   bus_dmamem_unmap(sc-sc_dmat, vrm-vrm_kva, vrm-vrm_size);
+ free:
+   bus_dmamem_free(sc-sc_dmat, vrm-vrm_seg, 1);
+ destroy:
+   bus_dmamap_destroy(sc-sc_dmat, vrm-vrm_map);
+   return (1);
+}
+
+void
+vr_dmamem_free(struct vr_softc *sc, struct vr_dmamem *vrm)
+{
+   bus_dmamap_unload(sc-sc_dmat, vrm-vrm_map);
+   bus_dmamem_unmap(sc-sc_dmat, vrm-vrm_kva, vrm-vrm_size);
+   bus_dmamem_free(sc-sc_dmat, vrm-vrm_seg, 1);
+   bus_dmamap_destroy(sc-sc_dmat, vrm-vrm_map);
+}
+
 /*
  * Attach the interface. Allocate softc structures, do ifmedia
  * setup and ethernet/BPF attach.
@@ -497,8 +540,6 @@
const char  *intrstr = NULL;
struct ifnet*ifp = sc-arpcom.ac_if;
bus_size_t  size;
-   int rseg;
-   caddr_t kva;
 
/*
 * Handle power management nonsense.
@@ -555,7 +596,7 @@
/* Allocate interrupt */
if (pci_intr_map(pa, ih)) {
printf(: can't map interrupt\n);
-   goto fail_1;
+   goto fail;
}
intrstr = pci_intr_string(pc, ih);
sc-sc_ih = pci_intr_establish(pc, ih, IPL_NET, vr_intr, sc,
@@ -565,7 +606,7 @@
if (intrstr != NULL)
printf( at %s, intrstr);
printf(\n);
-   goto fail_1;
+   goto fail;
}
printf(: %s, intrstr);
 
@@ -593,29 +634,20 @@
printf(, address %s\n, ether_sprintf(sc-arpcom.ac_enaddr));
 
sc-sc_dmat = pa-pa_dmat;
-   if (bus_dmamem_alloc(sc-sc_dmat, sizeof(struct vr_list_data),
-   PAGE_SIZE, 0, sc-sc_listseg, 1, rseg,
-   BUS_DMA_NOWAIT | BUS_DMA_ZERO)) {
-   printf(: can't alloc list\n);
-   goto fail_2;
-   }
-   if (bus_dmamem_map(sc-sc_dmat, sc-sc_listseg, rseg,
-   sizeof(struct vr_list_data), kva, BUS_DMA_NOWAIT)) {
-   printf(: can't map dma buffers (%d bytes)\n,
-   sizeof(struct vr_list_data));
-   goto fail_3;
-   }
-   if (bus_dmamap_create(sc-sc_dmat, sizeof(struct vr_list_data), 1,
-   sizeof(struct vr_list_data), 0, BUS_DMA_NOWAIT, sc-sc_listmap)) {
-   printf(: can't create dma map\n);
-   goto fail_4;
-   }
-   if (bus_dmamap_load(sc-sc_dmat, sc-sc_listmap, kva,
-   sizeof(struct vr_list_data), NULL, BUS_DMA_NOWAIT)) {
-   printf(: can't load dma map\n);
-   goto fail_5;
+   if (vr_dmamem_alloc(sc, sc-sc_zeromap, 64, PAGE_SIZE) != 0) {
+   printf(: failed to allocate zero pad memory\n);
+   return;
+   }
+   bzero(sc-sc_zeromap.vrm_kva, 64);
+   bus_dmamap_sync(sc-sc_dmat, sc-sc_zeromap.vrm_map, 0,
+   sc-sc_zeromap.vrm_map-dm_mapsize, BUS_DMASYNC_PREREAD);
+   if (vr_dmamem_alloc(sc, sc-sc_listmap, sizeof(struct vr_list_data),
+   PAGE_SIZE) != 0) {
+   printf(: failed to allocate dma map\n);
+   goto free_zero;
}
-   sc-vr_ldata = (struct vr_list_data *)kva;
+
+   sc-vr_ldata = (struct vr_list_data 

if_vr diff again, now with less bugs

[Chris Cappuccio]

i exercised the vr_encap error path by setting the TX ring size to 4, and 
discovered an unnecessary bus_dmamap_unload, also figured out that pointing the 
ring member to an mbuf before vr_encap is committed is a bad idea. also brad 
pointed out that there is no need to setup VR_MAXFRAGS * MCLBYTES dma transfer 
size for each list member. 

please test.

the end result of this diff should be lower CPU utliizaton for userland traffic 
on newer vr chips (Rhine II-2 and above, the ones that don't NEEDALIGN as you 
can easily see in the driver's quirk table) because we can get rid of buffer 
data copying by using scatter gather, and do less intensive work to pack 
segments into descriptors. 

Index: if_vr.c
===
RCS file: /cvs/src/sys/dev/pci/if_vr.c,v
retrieving revision 1.115
diff -u -r1.115 if_vr.c
--- if_vr.c 18 Sep 2012 14:49:44 -  1.115
+++ if_vr.c 6 Oct 2012 15:30:55 -
@@ -113,13 +113,16 @@
NULL, vr, DV_IFNET
 };
 
-int vr_encap(struct vr_softc *, struct vr_chain *, struct mbuf *);
+int vr_encap(struct vr_softc *, struct vr_chain **, struct mbuf *);
 void vr_rxeof(struct vr_softc *);
 void vr_rxeoc(struct vr_softc *);
 void vr_txeof(struct vr_softc *);
 void vr_tick(void *);
 void vr_rxtick(void *);
 int vr_intr(void *);
+int vr_dmamem_alloc(struct vr_softc *, struct vr_dmamem *,
+bus_size_t, u_int);
+void vr_dmamem_free(struct vr_softc *, struct vr_dmamem *);
 void vr_start(struct ifnet *);
 int vr_ioctl(struct ifnet *, u_long, caddr_t);
 void vr_chipinit(struct vr_softc *);
@@ -481,6 +484,46 @@
return(0);
 }
 
+int
+vr_dmamem_alloc(struct vr_softc *sc, struct vr_dmamem *vrm,
+bus_size_t size, u_int align)
+{
+   vrm-vrm_size = size;
+
+   if (bus_dmamap_create(sc-sc_dmat, vrm-vrm_size, 1,
+   vrm-vrm_size, 0, BUS_DMA_WAITOK | BUS_DMA_ALLOCNOW,
+   vrm-vrm_map) != 0)
+   return (1);
+   if (bus_dmamem_alloc(sc-sc_dmat, vrm-vrm_size,
+   align, 0, vrm-vrm_seg, 1, vrm-vrm_nsegs,
+   BUS_DMA_WAITOK | BUS_DMA_ZERO) != 0)
+   goto destroy;
+   if (bus_dmamem_map(sc-sc_dmat, vrm-vrm_seg, vrm-vrm_nsegs,
+   vrm-vrm_size, vrm-vrm_kva, BUS_DMA_WAITOK) != 0)
+   goto free;
+   if (bus_dmamap_load(sc-sc_dmat, vrm-vrm_map, vrm-vrm_kva,
+   vrm-vrm_size, NULL, BUS_DMA_WAITOK) != 0)
+   goto unmap;
+
+   return (0);
+ unmap:
+   bus_dmamem_unmap(sc-sc_dmat, vrm-vrm_kva, vrm-vrm_size);
+ free:
+   bus_dmamem_free(sc-sc_dmat, vrm-vrm_seg, 1);
+ destroy:
+   bus_dmamap_destroy(sc-sc_dmat, vrm-vrm_map);
+   return (1);
+}
+
+void
+vr_dmamem_free(struct vr_softc *sc, struct vr_dmamem *vrm)
+{
+   bus_dmamap_unload(sc-sc_dmat, vrm-vrm_map);
+   bus_dmamem_unmap(sc-sc_dmat, vrm-vrm_kva, vrm-vrm_size);
+   bus_dmamem_free(sc-sc_dmat, vrm-vrm_seg, 1);
+   bus_dmamap_destroy(sc-sc_dmat, vrm-vrm_map);
+}
+
 /*
  * Attach the interface. Allocate softc structures, do ifmedia
  * setup and ethernet/BPF attach.
@@ -497,8 +540,6 @@
const char  *intrstr = NULL;
struct ifnet*ifp = sc-arpcom.ac_if;
bus_size_t  size;
-   int rseg;
-   caddr_t kva;
 
/*
 * Handle power management nonsense.
@@ -555,7 +596,7 @@
/* Allocate interrupt */
if (pci_intr_map(pa, ih)) {
printf(: can't map interrupt\n);
-   goto fail_1;
+   goto fail;
}
intrstr = pci_intr_string(pc, ih);
sc-sc_ih = pci_intr_establish(pc, ih, IPL_NET, vr_intr, sc,
@@ -565,7 +606,7 @@
if (intrstr != NULL)
printf( at %s, intrstr);
printf(\n);
-   goto fail_1;
+   goto fail;
}
printf(: %s, intrstr);
 
@@ -593,29 +634,20 @@
printf(, address %s\n, ether_sprintf(sc-arpcom.ac_enaddr));
 
sc-sc_dmat = pa-pa_dmat;
-   if (bus_dmamem_alloc(sc-sc_dmat, sizeof(struct vr_list_data),
-   PAGE_SIZE, 0, sc-sc_listseg, 1, rseg,
-   BUS_DMA_NOWAIT | BUS_DMA_ZERO)) {
-   printf(: can't alloc list\n);
-   goto fail_2;
-   }
-   if (bus_dmamem_map(sc-sc_dmat, sc-sc_listseg, rseg,
-   sizeof(struct vr_list_data), kva, BUS_DMA_NOWAIT)) {
-   printf(: can't map dma buffers (%d bytes)\n,
-   sizeof(struct vr_list_data));
-   goto fail_3;
-   }
-   if (bus_dmamap_create(sc-sc_dmat, sizeof(struct vr_list_data), 1,
-   sizeof(struct vr_list_data), 0, BUS_DMA_NOWAIT, sc-sc_listmap)) {
-   printf(: can't create dma map\n);
-   goto fail_4;
-   }
-   if (bus_dmamap_load(sc-sc_dmat, sc-sc_listmap, kva,
-   sizeof(struct vr_list_data), NULL, BUS_DMA_NOWAIT)) {
-   printf(: can't load dma map\n);
-   goto 

Re: upstream vendors and why they can be really harmful

[Chris Cappuccio]

Tomas Bodzar [tomas.bod...@gmail.com] wrote:
 
 Here you can read what Linux devs think about Dfly for example
 https://plus.google.com/101384639386588513837/posts/Dkb8iixE4eP

Yes, let's all work on Linux!!!

Let's all move to Texas.

And, what's with this water? Like in the toilets? What about Brawndo?

Re: CVS changeset that fixed multiple NIC issue in 5.2-CURRENT?

[Chris Cappuccio]

Robbert Kouprie [robb...@exx.nl] wrote:
 
 The advice is appreciated, but why is it better?
 
 What I need is stability. I now have 5.2-STABLE with the PCI bus number
 resource tracking and secondary PCI root segment detection patches
 retrieved from CVS. These patches were applied to CVS not long after
 tagging 5.2-STABLE. The resulting kernel boots perfectly and now detects
 all my hardware. In this case I really don't expect any complications.
 

Sounds like you'll be fine. As always, the cvs mailing list has the details, 
www/plus.html has the summary. On the networking front, there are various 
ethernet driver, bgpd, ospfd, pf and IPsec improvements in current. Also has 
bug fixes for pthread apps and better disk performance if you do lots of big 
writes. If you are just running this thing as a basic firewall, no big deal.

Re: adduser: better locked password

[Chris Cappuccio]

Tobias Ulmer [tobi...@tmux.org] wrote:
 Adding a user with a locked password is a deliberate action.
 Set the password to * to stop security(8) from
 complaining about the new user.
 

I think it'd make more sense if security(8) didn't flag :*: as unusual. Since 
when is it unusual?

Re: [miniroot/install.sub] skip x* sets if do not expect to run X.

[Chris Cappuccio]

Devin Ceartas [de...@nacredata.com] wrote:
 There are cases where you want to compile some port not directly related to X 
 but the dependency is missing if you didn't load the X sets. I don't remember 
 the particular, but I know this has happened to me. 
 

Several ports depend on libraries that are only included with xbase, like 
freetype. The decision to work this way was made long ago for simplicity.

Re: vr(4) TX interrupt reduction

[Chris Cappuccio]

Micha?? Markowski [markows...@gmail.com] wrote:
 2013/1/14 Darren Tucker dtuc...@zip.com.au:
  Testing on any VIA Rhine chips would be appreciated (especially ones
  that are not 6105M like my ALIX).
 
 Hi, nothing conclusive on VIA VT6107 (dmesg: vr0 at pci0 dev 10
 function 0 VIA RhineII-2 rev 0x8d: irq 15, address
 00:16:35:06:af:eb).
 
 current kernel: 9835.56 int/s, 84.0 Mbps (100 s avg)
 with your patch: 9857.85 int/s, 84.0 Mbps
 
 No problems observed, though.
 

This will only affect TX direction interrupts. Can you try and generate a stream
of UDP traffic at full rate with a program like iperf to test just TX?

Re: vr(4) TX interrupt reduction

[Chris Cappuccio]

Micha?? Markowski [markows...@gmail.com] wrote:
 2013/1/14 Chris Cappuccio ch...@nmedia.net:
  This will only affect TX direction interrupts. Can you try and generate a 
  stream
  of UDP traffic at full rate with a program like iperf to test just TX?
 
 Those numbers are from `iperf -c a -t 100 -i 10` on vr machine.
 Iperf man page says: user must establish both a server (to discard
 traffic) and a client (to generate traffic) so yes, it's TX.
 

Well your numbers clearly show almost no difference. But TCP might not
be the best way to test due to the regular ack reply.

 When I try UDP test with -b higher than 87m:
 

Clearly, the current ports iperf is buggy. Stuart has the ticket on
tcpbench, in, uhh, udpbench mode.

Re: vr(4) TX interrupt reduction

[Chris Cappuccio]

Darren Tucker [dtuc...@zip.com.au] wrote:
 On Fri, Jan 18, 2013 at 09:00:25AM +1100, Darren Tucker wrote:
  Thanks to Mark Patruck for noticing that the previous patch didn't
  actually help, due to a bug I introduced in a last minute obviously
  correct clean up.
 
 The turd polishing continues unabated.  This adds the interrupt disable
 bit to descriptors where there's more than one mbuf in a packet.
 

Just in case anyone else cares about low-end performance, look closely. This 
is a managed TX interrupt moderation. As Darren shows, it produces significant
benefit for the CPUs often paired with these low-end chips. Any other tulip-like
chip, or other fast E chip that has a per-packet interrupt disable bit
should be looked at.

Re: man pages: wireless frequency nit 2GHz vs 2.4GHz

[Chris Cappuccio]

Amit Kulkarni [amitk...@gmail.com] wrote:
 I was reading the manpages of athn/iwn for purchasing a suitable wireless 
 card and found repeated occurences of 2GHz, when in fact it should be 2.4GHz. 
 That is the standard frequency when purchasing a wireless a/b/g/n card. The 
 code is filled with 2GHz references but just changed to man pages in section 
 4.
 

The atheros chip, and probably several others, are capable of operating in a 
much wider range than just 2400-2500 MHz.

-- 
That's what. -- She

Re: Fixing a phrase in /stable.html

[Chris Cappuccio]

Marc Espie [es...@nerim.net] wrote:
 
 This seems like a disturbing trend to me.
 are we going to turn www into a dumbed-down international english slang ? ...


Yeah, we need some more translations of www. What should we call the
mix of hillbilly, valley girl, inner-city slang, and various grunts?

Re: controler = controller

[Chris Cappuccio]

Nick Permyakov [stick...@mail.ru] wrote:
 Hi,
 
 The phrase in question is Always be aware of what was available
 when a controler or interface was manufactured in section 14.8,
 subsection FFS vs. FFS2 on http://www.openbsd.org/faq/faq14.html.
 

That whole area is sort of a poor summary of the actual issues, confusing to
new users because it provides no useful information and annoying to others
who actually know what the limitations are.

Re: goodbye to some isa devices

[Chris Cappuccio]

Creamy [cre...@nocrater.com] wrote:
 
 Miod, you seem like an all-right bloke, and I don't want to create
 bad feelings, but you're insulting me on a public mailing list,
 because I dare to bring up something you object to.
 
 Other people have been rude to me in private mail, because my views
 differ from theirs.  This represents a small minority of the OpenBSD
 development community, I know, but if I was really just here to troll,
 why would I have posted so many patches and fixes in the two weeks
 that I have been subscribed?
 

Too Creamy?

 Why does it seem like everybody is obsessed with me on this mailing list
 at times?  Ever since I joined, I have seen a flood of hits from OpenBSD
 based browsers in the logs for the nocrater.com site, even though it's
 off-line at the moment and re-directing everybody to the mobile site,
 which is making us look really unprofessional, I know, but I've been
 spending so much time contributing to this list that I haven't had time
 to fix it.  I've also had private mails quizzing me as to who I am,
 (who cares, if I'm writing good code?), and general written abuse, mostly
 off-list.
 

It's a hard bunch. And people disagree with you. Don't take it so personally.

We love you, man.

pflow and NAT

[Chris Cappuccio]

I upgraded a 4.9 box to 5.3 recently and found pflow is behaving
in new ways.

Pflow used to report the source IP before NAT was performed. Today, it 
reports the translated source IP rather than the untranslated one. I was
using it to keep a record of NAT translations, which isn't possible now.

Anyone know if this was a desired, or an accidental change ?

Re: ipsec / PF received-on

[Chris Cappuccio]

Stuart Henderson [s...@spacehopper.org] wrote:
 On a router running PF and isakmpd, I have a rule like this:
 
 match out on pppoe0 inet all received-on vlan5 nat-to $someip
 
 I was surprised to find this being applied to packets received on vlan5
 and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets
 (as in, generated on the router itself, not actually themselves received on
 vlan5) end up getting natted.
 
 What does anyone else think...expected or not?

From your description, i'd think ipsec should not be processing these packets,
PF should get them first.

Failure to boot i386/amd64 GENERIC+rd kernel on 4.8

[Chris Cappuccio]

Adding a 7480-block ramdisk to i386 GENERIC/GENERIC.MP and amd64 
GENERIC/GENERIC.MP used to work in 4.5, 4.6 and 4.7 but it has broke in 4.8 
for i386 GENERIC.MP and amd64 GENERIC (haven't yet tested amd64 GENERIC.MP)

At this point i'm wondering if some part of the system fails to take into 
account the extended size of the kernel with the ramdisk added (not a problem 
for bsd.rd since it's so small), and I've just gotten lucky doing this in the 
past (exceeding limiations of the ramdisk implementation?)  I'm hoping someone 
could peek at this for a minute and point me in the right direction.


1. Begin: 

I tried adding a ramdisk to amd64 GENERIC but it fails to boot early on.  When 
I've seen the kernel stop booting early on, I always assumed that either the 
kernel or the ramdisk needs to shrink.  This is nothing new.  A ramdisk of this 
size (7480 512-byte blocks) works with 4.7 GENERIC, a larger one fails to boot 
early on, and with the kernel growth in 4.8, this size ramdisk does not work in 
4.8 either, it fails early on.

http://www.nmedia.net/GENERICRD

Unfortunately I can't reproduce the exact panic messages until tomorrow.  My 
amd64 desktop has a usb keyboard and doesn't work at boot prompt (only works 
after the kernel initializes).  Most BIOS provide some ps/2 emulation that 
works at boot but not this one.


2. Next attempt:

So then I tried to trim some fat and get the kernel+ramdisk to shrink. I 
deleted some devices that were totally irrelevant for my application and bring 
the total amd64 kernel+rd to almost 10MB.

http://www.nmedia.net/TESTRD

This kernelgives me a panic: uvm_pglistalloc returned too many during isadma 
attach (with OPENBSD_4_8 tagged sources).

bus_dmamem_alloc_range+0x192
isadmaattach+0x54
config_attach+0x150
isascan+0x14c
config_scan+0xb3
config_attach+0x150

What's odd about the traceback is that isadmaattach in 
/usr/src/sys/dev/isa/isadma.c doesn't call bus_dmamem_alloc_range, like the 
trace shows.  It calls bus_dmamap_create

if ((bus_dmamap_create(sc-sc_dmat, sz, 1, sz, sz,
BUS_DMA_24BIT|BUS_DMA_NOWAIT|BUS_DMA_ALLOCNOW,
isadma_dmam[i])) != 0)

which then calls malloc, not bus_dmamem_alloc_range!

/* Allocate and initialize DMA map.

mapsize = sizeof(struct bus_dmamap) +
(sizeof(bus_dma_segment_t) * (nsegments - 1));
if ((mapstore = malloc(mapsize, M_DEVBUF,
(flags  BUS_DMA_NOWAIT) ?
(M_NOWAIT|M_ZERO) : (M_WAITOK|M_ZERO))) == NULL)
return (ENOMEM);

So I wonder if my trace is bogus.  Obviously bsd.rd works, where kernel and 
ramdisk are much smaller.


3. Test attempt

I wanted to make sure that my device removal wasn't bringing out some 
previously unidentified issue.  So I booted a kernel with the same devices 
removed from GENERIC, but without any ramdisk, just normal config bsd swap 
generic.  It boots properly as expected.

http://www.nmedia.net/TEST


4. Back to step 1, but on i386 

So as I compile this information, I created two more kernels that are 
essentially like the amd64 GENERICRD above, but on i386 instead.

http://www.nmedia.net/I386RD
http://www.nmedia.net/I386RD.MP

Both kernels+rd end up around 12MB

Non-MP boots fine... yet the MP version panics before the Copyright displays!!  
 It triggers this panic in sys/arch/i386/i386/pmap.c:

/* sanity check: kernel PTPs should already have been pre-allocated */
if (va = VM_MIN_KERNEL_ADDRESS 
!pmap_valid_entry(pmap-pm_pdir[pdei(va)]))
panic(pmap_enter: missing kernel PTP!);

Because the panic is so early, the traceback shows (null) function names. 

Hmmm

Chris

Re: Failure to boot i386/amd64 GENERIC+rd kernel on 4.8

[Chris Cappuccio]

Stuart Henderson [...@spacehopper.org] wrote:
 the README in flashboot has some information about this..
 

Sweet, I think my failures are all making a lot of sense now.  Thank you.

Re: bgpd config to announce one netblock only to one upstream

[Chris Cappuccio]

Claudio Jeker [cje...@diehard.n-r-g.com] wrote:
 
 Are you sure that problem still exists in 4.8 or -current? Because the way
 networks are handled changed completely. There is no longer a special
 static/connected global rule. Now explicit rules have a higher precedence
 then the dynamic network inet ... ones.
 

That sounds good.  I missed that stuff, I didn't think it was much different 
from 4.7 to current when I submitted the PR.  I'll retest.

Thanks,

Chris

Re: rthreads vs pthreads performance test

[Chris Cappuccio]

You don't need to recompile mysql or other tools.  Just move the librthreads 
shared object library (librthreads.so.x.y) in place of libpthreads.so.x.y.  
It's designed to work this way.

Jung [moor...@gmail.com] wrote:
 oops.
 sorry. i did not re-compile mysql and other tool. (pthreads vs
 rthreads result are same)
 so, previous e-mail's performance test is fail.
 i'll update test tools and i'll send that results again.
 
 thanks.

Re: pfi_kif leaks for PBR rules

[Chris Cappuccio]

Alexandr Nedvedicky [alexandr.nedvedi...@oracle.com] wrote:
 
 is missing at pfr_destroy_kentry(). We created patch against OpenBSD CURRENT.
 We have no OpenBSD boxes around, where we could verify our fix.
 

You are aware that OpenBSD supports both host and guest roles of
Sparc system virtualization ? Quite easy to install, I might add,
it's very simple to setup. As a host of virtual guests, it also
supports a bit of modern Sparc hardware, out-of-the-box.

Chris

Re: Better de(4) fix

[Chris Cappuccio]

Why do we still prefer de over dc for 211140 ?

Reyk Floeter [r...@openbsd.org] wrote:
 On Thu, Jun 25, 2015 at 09:21:11PM +0200, Mark Kettenis wrote:
  There really is no excuse for using dma_alloc(9) if you have the
  bus_dmatag_t available.
  
  This re-uses tulip_busdma_allocmem(), which simplifies the code for
  allocating the dmamap and such.
  
  Unfortunately I can't test this myself right now.
  
 
 Fixes the panic on Hyper-V, see dmesg below.
 
 Unrelated to that, no interrupts on the nic with the ioapic enabled
 (no traffic and autoneg timeouts).  
 
 Reyk
 
 OpenBSD 5.8-beta (GENERIC.MP) #7: Thu Jun 25 22:03:02 CEST 2015
 root@openbsd.hyperv:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8573091840 (8175MB)
 avail mem = 8309399552 (7924MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf8ec0 (216 entries)
 bios0: vendor American Megatrends Inc. version 090006 date 05/23/2012
 bios0: Microsoft Corporation Virtual Machine
 acpi0 at bios0: rev 0
 acpi0: sleep states S0 S5
 acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
 acpi0: wakeup devices
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, 1645.76 MHz
 cpu0: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,RTM
 cpu0: 256KB 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 106MHz
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, 1745.46 MHz
 cpu1: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,RTM
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 0, package 1
 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
 ioapic0: misconfigured as apic 2, remapped to apid 0
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpicpu0 at acpi0
 acpicpu1 at acpi0
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 Intel 82443BX rev 0x03
 pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x01
 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 
 wired to compatibility, channel 1 wired to compatibility
 wd0 at pciide0 channel 0 drive 0: Virtual HD
 wd0: 128-sector PIO, LBA48, 10240MB, 20971520 sectors
 wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
 atapiscsi0 at pciide0 channel 1 drive 0
 scsibus1 at atapiscsi0: 2 targets
 cd0 at scsibus1 targ 0 lun 0: Msft, Virtual CD/ROM, 1.0 ATAPI 5/cdrom 
 removable
 cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
 piixpm0 at pci0 dev 7 function 3 Intel 82371AB Power rev 0x02: SMBus 
 disabled
 vga1 at pci0 dev 8 function 0 Microsoft VGA rev 0x00
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 de0 at pci0 dev 10 function 0 DEC 21140 rev 0x20, 21140A pass 2.0: apic 0 
 int 11, address 00:15:5d:01:9b:03
 isa0 at pcib0
 isadma0 at isa0
 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
 fd1 at fdc0 drive 1: density unknown
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
 com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
 pckbc0 at isa0 port 0x60/5 irq 1 irq 12
 pckbd0 at pckbc0 (kbd slot)
 wskbd0 at pckbd0: console keyboard, using wsdisplay0
 pms0 at pckbc0 (aux slot)
 wsmouse0 at pms0 mux 0
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 vscsi0 at root
 scsibus2 at vscsi0: 256 targets
 softraid0 at root
 scsibus3 at softraid0: 256 targets
 root on wd0a (02632bce06e92172.a) swap on wd0b dump on wd0b
 
 

-- 
The bums will always lose

Re: whois(1): fix lookup of XX.network

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
 When I added code to use whois.nic.XX for new TLDs I forgot to think
 about one case, where the TLD is a substring of one of the traditional
 TLDs who have to use the old whois-servers.net method. Specifically,
 trying to lookup a .network name will incorrectly try to use
 network.whois-servers.net - strncasecmp was the wrong decision,
 so this diff switches to strcasecmp instead to fix. They're all
 null-terminated strings.
 

Makes perfect sense
ok chris@

Re: softdep by default on AMD64

[Chris Cappuccio]

?? ?? [art.is...@yandex.ru] wrote:
 On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote:
  generally reliable HAHAHAHAHA
 
 Why irony? It's more or less true for ALL modern computing system.

Think of it as a selling point. OpenBSD ffs softdep: On the cutting
edge of reliability!

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

[Chris Cappuccio]

Maxime Villard [m...@m00nbsd.net] wrote:
 
 Now, I believe that this effort is too much for my spare time. If you
 want to say thanks to me for reporting this vulnerability, dear Sam,
 it's never too late.
 

I put here a thanks among others:

Thank you for your effort to help improve the OpenBSD operating system,
to the benefit of its users, developers, and the many others who are
using the code in their own systems. Your work is appreciated, each
commit fixing a bug that you found is perhaps the spiritual thank-you
of which you have detected the subtle presence :)

Chris

Re: Kill arp_ifinit()?

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
 On 07/07/15(Tue) 18:02, Martin Pieuchot wrote:
  Maybe not yet but at least I'd like to do the ARP request a bit later.
  
  We create a RTF_LOCAL route entry for every configured address.  So
  use this information to emit a who-has for the configured address.
  
  This also has the advantage of *not* sending an ARP request if 
  something wrong happens between the SIOCSIFADDR ioctl and the
  RTF_LOCAL route creation.
 
 Anybody?
 

Looks ok to me!!

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Brian Conway [bcon...@rcesoftware.com] wrote:
> I meant positioning the whole case bottom-up (i.e. but the hot surface
> at the top).

Oh I see!

I just got a beta unit. I was late to the party. I used some of this
ZM-STG1 thermal grease (comes with a paint applicator type brush) and
the integrated memtest goes between 46 and 47 C. With intel ethernet,
four cores and usb3, this is a pretty nice unit!

I wonder if these are four discrete cores or if AMD is playing games
(like the bulldozer lawsuit as of late.)

Chris

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Brian Conway [bcon...@rcesoftware.com] wrote:
> 
> Taking into account Mr. Cappuccio's advice on using thermal paste
> between the CPU and heat spreader, and also positioning it bottom-up,
> this one stabilized at 51 C at idle. I haven't had a chance to do much
> benchmarking for higher temps yet, other than a run of `openssl speed`
> to warm it up.

If you put the heat speader upside down, the sticky pad would be against
the cpu heatsink contact area?? There's only one way to put that device in.

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Mathias Schmocker [s...@smat.ch] wrote:
> 
> First tests with a bootable OpenBSD amd64 5.8-current USB stick and
> installation on the 16GB mSata internal storage.
> After reboot, BIOS could find mSata to boot on, but defaulted to the memtest
> boot payload
> 

This is a setting you can change, although the default boot order would put 
memtest last.

I've had no problems with apu2 detecting msata so far..

> Unable to abort memtest by pressing (esc) on the serial console, or (c) for
> configure.
> 

You have to escape to the prompt before memtest starts.

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Noth [nothingn...@citycable.ch] wrote:
> Hi again,
> 
>   I think I've found a bug: if I have a console session open using minicom
> or cu when rebooting, the machine hangs. This doesn't happen with either
> CentOS Linux 7 or FreeBSD 10.2 / 11. I can reproduce the problem. Anyone
> else have this issue ?
> 

The boot loader output is emulated video output until it switches to com0.
Once it reads 'stty com0 115200; set tty com0' from /etc/boot.conf, it 
switches from video output to serial output.

During the switch, some contents comes out of the boot loader that is at
the wrong baud rate (or something similar). This causes some high characters
to come out, which your terminal emulator might interpret as a terminal command
and it could even send a short reply back. If it does, this reply stops the
auto-boot process and you sit at boot> indefinitely.

The solution is to not leave a terminal emulator connected during the boot
(or fix the boot loader to not output high characters)

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Noth [nothingn...@citycable.ch] wrote:
> No it freezes after the "rebooting..." message appears. It isn't before the
> firmware restarts. Hopefully the next firmware release will some kind of fix
> for this.
> 

The non-ACPI kernel does this (bsd.rd). bsd should not do this

Re: restricting DNS to port 53

[Chris Cappuccio]

gwes [g...@oat.com] wrote:
> Will unbound and nsd be restricted to port 53 only?
> 

No

Re: PC Engines APU2 coming soon - how is OpenBSD's support so far?

[Chris Cappuccio]

Noth,
I got my APU (first rev) to go from 56-58 temps down to 49-50 by using heatsink 
paste instead of the thermal pad...

Noth [nothingn...@citycable.ch] wrote:
> Thanks Stuart, that works for me!
> 
> # sysctl hw
> hw.machine=amd64
> hw.model=AMD GX-412TC SOC
> hw.ncpu=4
> hw.byteorder=1234
> hw.pagesize=4096
> hw.disknames=sd0:47e18331a1a8156e
> hw.diskcount=1
> hw.sensors.km0.temp0=59.38 degC
> hw.cpuspeed=998
> hw.setperf=100
> hw.vendor=PC Engines
> hw.product=apu2
> hw.version=1.0
> hw.serialno=123456789
> hw.physmem=4261081088
> hw.usermem=4261056512
> hw.ncpufound=4
> hw.allowpowerdown=1
> hw.perfpolicy=manual
> 
> On 04/11/15 18:47, Stuart Henderson wrote:
> >this will probably get you a cpu temperature sensor.
> >
> >Index: km.c
> >===
> >RCS file: /cvs/src/sys/dev/pci/km.c,v
> >retrieving revision 1.10
> >diff -u -p -r1.10 km.c
> >--- km.c 14 Mar 2015 03:38:48 -  1.10
> >+++ km.c 4 Nov 2015 17:44:25 -
> >@@ -72,7 +72,8 @@ static const struct pci_matchid km_devic
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_14_MISC },
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_15_0x_MISC },
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_15_1x_MISC },
> >-{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_MISC }
> >+{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_MISC },
> >+{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_16_3X_MISC }
> >  };
> >

Re: Purge route entries when an address is removed

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
> Currently we leave RTF_STATIC route entries in the table when the
> address they are attached to is removed from a system.
> 
> That's why ifas need to be refcounted and that's why we have *a lot*
> of checks in the stack to not use cached routes attached to such ifa.
> 
> I'd like to simplify all of this by simply purging all the routes
> attached to an ifa being removed.  This behavior is coherent with
> the fact that routes *need* an ifa to be inserted in the table.
> 
> This makes the kernel simpler as it no longer try to find a new ifa
> when a route with a stale address is being used.
> 

I'm pretty sure this feature has been broken for a while. Once upon
a time in OpenBSD, this used to work:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
ping 8.8.8.8
reply!

For some years, this has been required:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8  
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
**route delete default**
**route add default 192.168.1.1**
ping 8.8.8.8
reply!

It appears, what you're proposing is:

ifconfig em0 192.168.1.2/24
route add default 192.168.1.1
ping 8.8.8.8
reply!
ifconfig em0 delete 192.168.1.2
ifconfig em1 192.168.1.2/24
**route add default 192.168.1.1**
ping 8.8.8.8
reply!

As a user (only), I really like the original behavior, it seems to be
consistent with the behavior of some other systems, at least in the case
of the default router. If there was some way to do this without stupid
complexity, it might be worth considering.

In any event, what you propose seems much better than the current state
of affairs, where you end up with broken routes in the table that need
nothing more than to be removed.

Chris

Re: mpsafe re(4)

[Chris Cappuccio]

Dimitris Papastamos [s...@2f30.org] wrote:
> On Sat, Dec 05, 2015 at 06:11:51PM +0100, Jonathan Matthew wrote:
> > The main interesting bit here is the txeof and start loops, which previously
> > operated based on the prod/cons indices and the contents of the tx queue,
> > but now just uses the indices as that's the only way to get a consistent 
> > view
> > of the tx queue state.
> > 
> > At the moment I don't think the tx ring is big enough to use IFQ_DEQUEUE
> > instead of ifq_deq_begin/commit, but maybe I'm wrong about that.
> > 
> > can someone try this on an APU1?
> 
> I've tested this on my router and it seems to work okay.  I've also used
> tcpbench with various combinations.
> 
> re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G
> (0x4c00), msi, address 80:ee:73:9f:1d:3e
> re1 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G
> (0x4c00), msi, address 80:ee:73:9f:1d:3d

Testing fine for me on APU1 so far.

Re: [PATCH] let the mbufs use more then 4gb of memory

[Chris Cappuccio]

Mark Kettenis [mark.kette...@xs4all.nl] wrote:
> 
> We really don't want to implement bounce-buffers.  Adding IOMMU
> support is probably a better approach as it also brings some security
> benefits.  Not all amd64 hardware supports an IOMMU.  And hardware
> that does support it doesn't always have it enabled.  But for modern
> hardware an iommu is pretty much standard, except for the absolute
> low-end.  But those low-end machines tend to have only 2GB of memory
> anyway.

Is the sparc64 iommu code port usable for this purpose?

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/Attic/sg_dma.c

Re: remove net80211 turbo mode

[Chris Cappuccio]

Stuart Henderson [st...@openbsd.org] wrote:
> 
> +1, I wondered if we should do this when reading the 11n diffs.
> 
> If people need more speed it's likely that they will get better
> performance with 20MHz channels on a newer radio/MAC than 40MHz
> on a 10-year-old one.
> 
> Free the spectrum!

i've never seen any significant improvement from the old 40mhz mode,
just much higher noise sensitivity

Re: New scheduler for OpenBSD

[Chris Cappuccio]

Alexandre Ratchov [a...@caoua.org] wrote:
> On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > 
> > Please test, and let me know if the performance of something else
> > degrades.
> > 
> 
> With your diff firefox consumes twice less cpu (watched the same
> video with and without the diff).  This suggests firefox spins
> somewhere and your diff makes it spin less.
> 
> When audio device is using small blocks it stutters more with your
> diff though; according to device counters the stuttering is caused
> by sndiod not getting the cpu fast enough.

there is no 'nice' functionality at the moment

Re: APU1 ethernet LEDs

[Chris Cappuccio]

Did you bring this up to Pascal Dornier ? I think he would rather fix
the eeprom...

This is specific to the hardware layout, the eeprom is the right place,
not the driver!

On the other hand, I think the CSR_WRITE_1 is perfectly clear

Stuart Henderson [s...@spacehopper.org] wrote:
> The re(4) variant on the PC Engines APU1, RTL8111E, has a flexible LED
> configuration. The nic's default config seems to be intended for
> controlling 3 LEDs (or one single-colour and a bi-colour LED with
> different colours to indicate link speed) however the ethernet ports
> on the APU1 only have two LEDs (one green one amber).
> 
> Defaults can be changed in eeprom but (intentionally or not) this
> hasn't been done on the APU1 so in normal situations with a 1GB link,
> you only ever see one lit LED, and even that is normally off, only
> blinking for activity. I don't know of any APU users who like
> the default setup.
> 
> Section 6.2.6 of the RTL8111E-VB-GR / -VB-CG / -VC-CG datasheet
> tells us how to reprogramme it. Do we want to change it?
> 
> Without diff:
> 
> green: normally off, blink on for activity.
> amber: on solid for 100MB link, off for 1GB link.
> 
> With diff:
> 
> green: normally on if link at any speed. blink off for activity.
> amber: on solid for 1GB link, otherwise off.
> 
> Some other settings are possible but I think this gives the best
> combination of information under "normal" conditions given only
> 2 LEDs.
> 
> Looking at unique "RTL8168E/8111E (0x2c00)" entries from dmesglog
> back to Feb 2013, there are 7 APUs (=21 NICs), and 20 non-APUs.
> Do we care if we change led state for those others too? We could
> check the MAC vendor for 00:0d:b9, but I think this is unnecessary
> complexity (and who knows, maybe it's an improvement for some of
> those too).
> 
> Any comments/OKs? (I am not 100% happy with the clarity of the new
> CSR_WRITE_1 line, but my earlier iterations were worse ;)
> 

Re: New scheduler for OpenBSD

[Chris Cappuccio]

Michal Mazurek [akf...@jasminek.net] wrote:
> On 16:28:33, 14.03.16, Martin Pieuchot wrote:
> > > The number of calls to yield() dropped to 4,576.
> > 
> > This is really similar to what I observed with Firefox and Chrome.
> > 
> > > This is where I get stuck, I don't know how to replace the call to
> > > sched_yield(), or whether it is a good idea to do so. Any advice?
> > 
> > I'd assume the problem is not in the _spinlock() implementation itself
> > but rather on the code calling this lock.  Do you know which code is
> > triggering this?
> > 
> > See r1.13 of lib/librthread/rthread_libc.c, this is an example where a
> > the use of a spinlock created similar symptoms.
> 
> I don't know how to fix it, but in the meanwhile here is a workaround so
> I can continue working on the scheduler. In yield():
> 
> + tmp = p->p_rrticks;
> + sched_deadline(p);
> + p->p_rrticks = tmp;
> 
> So penalise a process calling yield() by giving it the worst deadline,
> i.e. make it go to the end of the run queue.
> 
> Other than this, no changes.
> 
> Chrome still isn't smooth.
> 

On a frankenstein 5.9 kernel with bob beck's latest NOWAIT vfs_biomem buffer 
alloc and this, I'm getting very smooth action on chrome, with video, even on
an old x201. I don't remember the last time it could re-open 20 tabs without
constantly pausing most of itself, or the last time youtube videos would
play on this laptop in chrome, without random and frequenty stuttering.

Re: New scheduler for OpenBSD

[Chris Cappuccio]

Bob Beck [b...@openbsd.org] wrote:
> this is cool .. but
> 
> I would be interested in someone comparing server workloads, as
> opposed to interactive GUI response, using this.
> 
> I wouldn't be surprised that inspiriation from BFS would produce
> better interactive response, my bigger concern
> would be does this adversely impact how we deal with non-interactive 
> workloads.

I've been testing it on my heavily loaded Zabbix server, which regularly
get dozens of variables from over 5,000 devices. I get mixed results, the
load avg is higher, and the idle cpu time is generally higher, I regularly
see 1 second (top 's 1') CPU idle of 50-70% where I regularly saw 20-50% 
with the old scheduler. This is in top with all cpus collasped into 1 (top
'1'). I suspect if I averaged it over time, the difference could be less   
dramatic.

I'm using Postgres, there is no heavily threaded stuff, so I have
no idea why the idle CPU seems to be higher. The load avg is a bit higher,
it seems to stay up around 48 longer with the new scheduler, and also
shoots up and down more quickly. None of this is particularly well measured,
just a weird observation. With the old scheduler the load avg would fluctuate
from 32-42, and seemed to stay at a particular value for a longer period
of time (whatever that means.)

Zabbix is a horrible pig, and my polling confiuguration is not fine-tuned 
to top it off. The box is a "Xeon E2-1230 v3 @ 3.30GHz" with 16GB RAM and
two Samsung 845DC SSDs in softraid raid1. We use Postgres as a time-series
database, I'm looking at alternatives using collectd and graphite and
whatever, I really want to get away from Zabbix + Postgres.

Since this scheduler has a hack to help spinning threaded apps, that
explains why there is less CPU usage during video playback, but I don't
know how to explain my Zabbix results. It takes at least 2 minutes after
boot before the Zabbix box stabilizes to the levels I'm describing
here. 

If I set top to .1 second (top 's .1') then the new scheduler seems to
drive all CPUs to 0% idle for shorter periods of time, but more
frequently.

These are really rough observations. This box spawns lots of dirty
perl processes and also lots of fping processes for monitoring. I've
not spent the time to optimize this area at all. I was curious if this
scheduler or other OS level optmizations might take away some of the
costs here. With this rather stupid polling architecture, perhaps
copy-on-write is still the biggest win...

Chris

Re: dc patch

[Chris Cappuccio]

Edgar Pettijohn [ed...@pettijohn-web.com] wrote:
> nevermind just found the elusive "q"
> 

There's always the universal ^D

LTE umsm

[Chris Cappuccio]

Here is a patch to support some newer LTE umsm devices

Yes, the 313U actually has an SD card slot. And yes, it actually
changes vendor ID to Airprime after the umsm_truinstall_changemode
takes place.

Matching ifaceno == 9 for newer USB_PRODUCT_SIERRA_TRUINSTALL devices
is necessary. They don't show up as 0. (It's possible that Huawei will
will need the same treatment in umsm_attach if they use newer umsm chips)

ok?

Aircard 313U:

umsm0 at uhub5 port 3 configuration 1 interface 9 "Sierra Wireless, 
Incorporated USB MMC Storage" rev 2.00/0.00 addr 5
umsm0: truinstall mode. need to reattach
umsm0 detached
umsm0 at uhub5 port 3 configuration 1 interface 0 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom1 at umsm0
umsm1 at uhub5 port 3 configuration 1 interface 1 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom2 at umsm1
umsm2 at uhub5 port 3 configuration 1 interface 2 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom3 at umsm2
umsm3 at uhub5 port 3 configuration 1 interface 3 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom4 at umsm3
umsm4 at uhub5 port 3 configuration 1 interface 4 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom5 at umsm4
umass1 at uhub5 port 3 configuration 1 interface 9 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd5 at scsibus3 targ 1 lun 0:  SCSI2 0/direct removable 
serial.0f3d68aa615000291196
umsm5 at uhub5 port 3 configuration 1 interface 7 "Sierra Wireless, 
Incorporated AirCard 313U" rev 2.00/0.06 addr 5
ucom6 at umsm5

Aircard 770S:

umsm0 at uhub5 port 3 configuration 1 interface 9 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
umsm0: truinstall mode. need to reattach
umsm0 detached
umsm0 at uhub5 port 3 configuration 1 interface 3 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom1 at umsm0
umsm1 at uhub5 port 3 configuration 1 interface 8 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom2 at umsm1
umsm2 at uhub5 port 3 configuration 1 interface 0 "NETGEAR, Inc. AirCard 770S" 
rev 2.00/0.06 addr 5
ucom3 at umsm2

Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.104
diff -u -p -u -r1.104 umsm.c
--- umsm.c  29 Sep 2015 08:34:28 -  1.104
+++ umsm.c  20 May 2016 02:05:54 -
@@ -115,6 +115,7 @@ struct umsm_type {
 
 static const struct umsm_type umsm_devs[] = {
{{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_PC5220 }, 0},
+   {{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_AIRCARD_313U }, 0},
 
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_A2502 }, 0},
{{ USB_VENDOR_ANYDATA,  USB_PRODUCT_ANYDATA_ADU_500A }, 0},
@@ -247,6 +248,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_USB305}, 0},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_TRUINSTALL }, DEV_TRUINSTALL},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC8355}, 0},
+   {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
 
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS_2 }, DEV_UMASS3},
@@ -359,7 +361,7 @@ umsm_attach(struct device *parent, struc
printf("%s: umass only mode. need to reattach\n",
sc->sc_dev.dv_xname);
} else if ((sc->sc_flag & DEV_TRUINSTALL) &&
-   uaa->ifaceno == 0) {
+   (uaa->ifaceno == 0 || uaa->ifaceno == 9)) {
umsm_truinstall_changemode(uaa->device);
printf("%s: truinstall mode. need to reattach\n",
sc->sc_dev.dv_xname);

Re: LTE umsm

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
> On 20/05/16(Fri) 09:47, Chris Cappuccio wrote:
> > So to just remove the ifaceno check, here's the diff.
> > 
> > This matches u3g behaviour for SIERRA TRUINSTALL devices. There is
> > still a bit of hardcoded stuff that needs to be reviewed in umsm
> > for other devices. I think yuo@ was trying to match some of these
> > style checks when he added support for these devices (but it
> > does not appear to be necessary to isolate based on ifaceno for
> > u3g)
> 
> Did you try this with the corresponding device?
> 

I tested the 313U and 770S. 

Re: LTE umsm

[Chris Cappuccio]

Martin Pieuchot [m...@openbsd.org] wrote:
> On 19/05/16(Thu) 19:27, Chris Cappuccio wrote:
> > Here is a patch to support some newer LTE umsm devices
> > 
> > Yes, the 313U actually has an SD card slot. And yes, it actually
> > changes vendor ID to Airprime after the umsm_truinstall_changemode
> > takes place.
> > 
> > Matching ifaceno == 9 for newer USB_PRODUCT_SIERRA_TRUINSTALL devices
> > is necessary. They don't show up as 0. (It's possible that Huawei will
> > will need the same treatment in umsm_attach if they use newer umsm chips)
> 
> No.  Hardcoding interface number is not the way to go.  Interfaces
> descriptors have a class, subclass and protocol that should be looked
> at. 
> 
> In 3 months a new device will show up with different interfaces layout and
> we will have to hardcode something else?
> 

I agree in principle, however in practice, the goal is to run
umsm_truinstall_changemode to get the device to present itself in a useful
manner.

Before umsm_truinstall_changemode, the class is UICLASS_MASS, subclass
UISUBCLASS_SCSI, and protocol UIPROTO_MASS_BBB. That's a USB disk.

FreeBSD's u3g driver is similar. We could match FreeBSD behavior by simply
removing the ifnaceno check. Then we are just matching on
USB_PRODUCT_SIERRA_TRUINSTALL and UICLASS_MASS.

Chris