Re: kernel/6309: CPU Core i5 is not fully recognized

[Jonathan Gray]

On Sun, Apr 25, 2010 at 08:13:27PM +0200, Daniele Pilenga wrote:
 On Thu, Feb 4, 2010 at 11:25 PM,  gn...@cvs.openbsd.org wrote:
  Thank you very much for your problem report.
  It has the internal identification `kernel/6309'.
  The individual assigned to look at your
  report is: bugs.
 
 Category:   kernel
 Responsible:bugs
 Synopsis:   CPU Core i5 is not fully recognized
 Arrival-Date:   Thu Feb 04 21:20:01 GMT 2010
 
 
 As a partial integration: I run the cpuid.c that once passed on the
 misc mailing list, here the result:

This is irrelevant, the speedstep code is disabled
on these newer Intel CPUs as the code needs to be rewritten
to not use MSRs Intel have removed.

Re: kernel/6427: Intel em(4) Intel PRO/1000 QP (82576) fails: Unable to initialize

[Jonathan Gray]

The following reply was made to PR kernel/6427; it has been noted by GNATS.

From: Jonathan Gray j...@goblin.cx
To: Sebastian Benoit benoit-li...@fb12.de
Cc: gn...@cvs.openbsd.org, b...@cvs.openbsd.org
Subject: Re: kernel/6427: Intel em(4) Intel PRO/1000 QP (82576) fails:
 Unable to initialize
Date: Mon, 12 Jul 2010 01:40:05 +1000

 On Sun, Jul 11, 2010 at 03:36:42PM +0200, Sebastian Benoit wrote:
  Hi, 
  
  i found the problem:
  
  if_em_hw.c patch 1.46, specifically the function
  em_set_pciex_completion_timeout() breaks my em card:
 
 Can you try this diff from SAITOH Masanobu?
 
 Index: if_em_hw.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
 retrieving revision 1.46
 diff -u -r1.46 if_em_hw.c
 --- if_em_hw.c 2 Mar 2010 22:09:57 -   1.46
 +++ if_em_hw.c 4 Apr 2010 13:41:09 -
 @@ -527,6 +527,7 @@
hw-asf_firmware_present = TRUE;
break;
case em_80003es2lan:
 +  case em_82575:
hw-swfw_sync_present = TRUE;
/* FALLTHROUGH */
case em_82571:
 @@ -3780,7 +3781,7 @@
uint16_t swfw;
DEBUGFUNC(em_read_phy_reg);
  
 -  if ((hw-mac_type == em_80003es2lan) 
 +  if (((hw-mac_type == em_80003es2lan) || (hw-mac_type == em_82575)) 
(E1000_READ_REG(hw, STATUS)  E1000_STATUS_FUNC_1)) {
swfw = E1000_SWFW_PHY1_SM;
} else {
 @@ -3937,7 +3938,7 @@
uint16_t swfw;
DEBUGFUNC(em_write_phy_reg);
  
 -  if ((hw-mac_type == em_80003es2lan) 
 +  if (((hw-mac_type == em_80003es2lan) || (hw-mac_type == em_82575)) 
(E1000_READ_REG(hw, STATUS)  E1000_STATUS_FUNC_1)) {
swfw = E1000_SWFW_PHY1_SM;
} else {
 @@ -4150,7 +4151,8 @@
DEBUGOUT(Resetting Phy...\n);
  
if (hw-mac_type  em_82543  hw-mac_type != em_icp_) {
 -  if ((hw-mac_type == em_80003es2lan) 
 +  if (((hw-mac_type == em_80003es2lan) ||
 +  (hw-mac_type == em_82575)) 
(E1000_READ_REG(hw, STATUS)  E1000_STATUS_FUNC_1)) {
swfw = E1000_SWFW_PHY1_SM;
} else {

Re: kernel/6427: Intel em(4) Intel PRO/1000 QP (82576) fails: Unable to initialize

[Jonathan Gray]

On Tue, Jul 13, 2010 at 02:59:36PM -0500, Adam Kujawski wrote:
 Hello,
 
 I applied the patch from SAITOH Masanobu to 4.7-RELEASE successfully,
 and that resolved the problem with the hardware initialization
 failing. However, while the interfaces on the Intel PRO/1000 QP
 (82576) work fine for untagged traffic, I'm unable to pass packets
 over 1472 bytes (payload) over a VLAN trunked interface (i.e. 'ping -s
 1472 target' fails). This is on an amd64 multi-proc kernel.
 
 Has anybody else tested this patch with tagged VLAN interfaces? It
 seems a similar problem was reported in openbsd-misc back in May
 (subject: vlan + em driver).

Do packets properly fragment when larger than mtu size without vlans
involved or do you only see it with tagged vlans?

Re: kernel/6433: Intel EF Server Adapter Dual Port aka Intel PRO/1000 FP (82576/fiber) always has hardware initialization failure.

[Jonathan Gray]

The following reply was made to PR kernel/6433; it has been noted by GNATS.

From: Jonathan Gray j...@goblin.cx
To: =?iso-8859-1?Q?Fr=E9d=E9ric?= URBAN frederic.ur...@ircad.u-strasbg.fr
Cc: gn...@openbsd.org
Subject: Re: kernel/6433: Intel EF Server Adapter Dual Port aka Intel PRO/1000 
FP (82576/fiber) always has hardware initialization failure.
Date: Mon, 19 Jul 2010 19:54:59 +1000

 Try this, and send a dmesg of the updated machine.
 
 Index: if_em_hw.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
 retrieving revision 1.55
 diff -u -p -r1.55 if_em_hw.c
 --- if_em_hw.c 13 Jul 2010 21:55:52 -  1.55
 +++ if_em_hw.c 19 Jul 2010 09:52:30 -
 @@ -4959,6 +4959,7 @@ em_detect_gig_phy(struct em_hw *hw)
hw-mac_type == em_82574 ||
hw-mac_type == em_82573 ||
hw-mac_type == em_82574 ||
 +  hw-mac_type == em_82575 ||
hw-mac_type == em_80003es2lan)) {
hw-phy_type = em_phy_undefined;
return E1000_SUCCESS;

Re: kernel/6433: Intel EF Server Adapter Dual Port aka Intel PRO/1000 FP (82576/fiber) always has hardware initialization failure.

[Jonathan Gray]

On Mon, Jul 19, 2010 at 07:15:02AM -0600, Fridiric URBAN wrote:
 The following reply was made to PR kernel/6433; it has been noted by GNATS.
 
 From: =?ISO-8859-1?Q?Fr=E9d=E9ric_URBAN?= frederic.ur...@ircad.u-strasbg.fr
 To: Cc: gn...@openbsd.org
 Subject: Re: kernel/6433: Intel EF Server Adapter Dual Port aka Intel 
 PRO/1000 FP (82576/fiber) always has hardware initialization failure.
 Date: Mon, 19 Jul 2010 15:02:23 +0200
 
  Hello,
  
  I just tried to apply it on -current, still unable to initialize. 
  Compared to the dmesg provided with the bug, i had to change the rest of 
  the hardware. It was server, it's a old desktop computer.

try this

Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.55
diff -u -p -r1.55 if_em_hw.c
--- if_em_hw.c  13 Jul 2010 21:55:52 -  1.55
+++ if_em_hw.c  27 Jul 2010 10:13:46 -
@@ -590,13 +590,44 @@ em_set_mac_type(struct em_hw *hw)
 void
 em_set_media_type(struct em_hw *hw)
 {
-   uint32_t status;
+   uint32_t status, ctrl_ext = 0;
DEBUGFUNC(em_set_media_type);
 
if (hw-mac_type != em_82543) {
/* tbi_compatibility is only valid on 82543 */
hw-tbi_compatibility_en = FALSE;
}
+
+   /*
+* The 82575 uses bits 22:23 for link mode. The mode can be changed
+* based on the EEPROM. We cannot rely upon device ID. There
+* is no distinguishable difference between fiber and internal
+* SerDes mode on the 82575. There can be an external PHY attached
+* on the SGMII interface.
+*/
+   if (hw-mac_type == em_82575) {
+   hw-media_type = em_media_type_copper;
+
+   ctrl_ext = E1000_READ_REG(hw, CTRL_EXT);
+   switch (ctrl_ext  E1000_CTRL_EXT_LINK_MODE_MASK) {
+   case E1000_CTRL_EXT_LINK_MODE_SGMII:
+   ctrl_ext |= E1000_CTRL_I2C_ENA;
+   break;
+   case E1000_CTRL_EXT_LINK_MODE_1000BASE_KX:
+   case E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES:
+   hw-media_type = em_media_type_internal_serdes;
+   ctrl_ext |= E1000_CTRL_I2C_ENA;
+   break;
+   default:
+   ctrl_ext = ~E1000_CTRL_I2C_ENA;
+   break;
+   }
+
+   E1000_WRITE_REG(hw, CTRL_EXT, ctrl_ext);
+
+   return;
+   }
+
switch (hw-device_id) {
case E1000_DEV_ID_82545GM_SERDES:
case E1000_DEV_ID_82546GB_SERDES:
@@ -4959,6 +4990,7 @@ em_detect_gig_phy(struct em_hw *hw)
hw-mac_type == em_82574 ||
hw-mac_type == em_82573 ||
hw-mac_type == em_82574 ||
+   hw-mac_type == em_82575 ||
hw-mac_type == em_80003es2lan)) {
hw-phy_type = em_phy_undefined;
return E1000_SUCCESS;
Index: if_em_hw.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v
retrieving revision 1.44
diff -u -p -r1.44 if_em_hw.h
--- if_em_hw.h  2 Jul 2010 21:41:59 -   1.44
+++ if_em_hw.h  27 Jul 2010 10:13:47 -
@@ -1566,6 +1566,7 @@ struct em_hw {
 #define E1000_CTRL_VME  0x4000  /* IEEE VLAN mode enable */
 #define E1000_CTRL_PHY_RST  0x8000  /* PHY Reset */
 #define E1000_CTRL_SW2FW_INT 0x0200  /* Initiate an interrupt to 
manageability engine */
+#define E1000_CTRL_I2C_ENA  0x0200  /* I2C enable */
 
 /* Device Status */
 #define E1000_STATUS_FD 0x0001  /* Full duplex.0=half,1=full */
@@ -1679,10 +1680,11 @@ struct em_hw {
 #define E1000_CTRL_EXT_SPD_BYPS  0x8000 /* Speed Select Bypass */
 #define E1000_CTRL_EXT_RO_DIS0x0002 /* Relaxed Ordering disable */
 #define E1000_CTRL_EXT_LINK_MODE_MASK 0x00C0
+#define E1000_CTRL_EXT_LINK_MODE_1000BASE_KX 0x0040
 #define E1000_CTRL_EXT_LINK_MODE_GMII 0x
 #define E1000_CTRL_EXT_LINK_MODE_TBI  0x00C0
 #define E1000_CTRL_EXT_LINK_MODE_KMRN 0x
-#define E1000_CTRL_EXT_LINK_MODE_SERDES  0x00C0
+#define E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES  0x00C0
 #define E1000_CTRL_EXT_LINK_MODE_SGMII   0x0080
 #define E1000_CTRL_EXT_WR_WMARK_MASK  0x0300
 #define E1000_CTRL_EXT_WR_WMARK_256   0x

Re: 4.8-current fails with uvm_fault in em(4)

[Jonathan Gray]

On Tue, Aug 03, 2010 at 11:12:01PM +0100, Stuart Henderson wrote:
 Do you know what the last working kernel was?
 
 I have an archive of old kernels if you want to track it down without
 the cvs up -D / compile dance, mail me offlist.

broken:
OpenBSD 4.7-current (GENERIC) #104: Thu Jul  8 16:47:03 MDT 2010

works:
OpenBSD 4.7-current (GENERIC) #98: Wed Jul  7 18:25:12 MDT 2010

I don't see how it could be an em problem as there are no commits
in this window and all the commits either side of it are chip
specific to other chips.

Re: user/6509: relayctl show sessions make relayd crash

[Jonathan Gray]

The problem is we have multiple handlers and get
IMSG_STATISTICS when in the secondary handler.

Try the following diff from reyk:

Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.124
diff -u -p -r1.124 relay.c
--- relay.c 16 Nov 2010 15:31:01 -  1.124
+++ relay.c 18 Nov 2010 16:12:29 -
@@ -567,10 +567,12 @@ relay_statistics(int fd, short events, v
if (resetday)
cur-last_day = 0;
 
-   crs.id = rlay-rl_conf.id;
-   crs.proc = proc_id;
-   imsg_compose_event(iev_pfe, IMSG_STATISTICS, 0, 0, -1,
-   crs, sizeof(crs));
+   if (!env-sc_statstop) {
+   crs.id = rlay-rl_conf.id;
+   crs.proc = proc_id;
+   imsg_compose_event(iev_pfe, IMSG_STATISTICS, 0, 0, -1,
+   crs, sizeof(crs));
+   }
 
for (con = SPLAY_ROOT(rlay-rl_sessions);
con != NULL; con = next_con) {
@@ -2556,6 +2558,7 @@ relay_dispatch_pfe(int fd, short event, 
evtimer_add(con-se_ev, tv);
break;
case IMSG_CTL_SESSION:
+   env-sc_statstop = 1;
TAILQ_FOREACH(rlay, env-sc_relays, rl_entry)
SPLAY_FOREACH(con, session_tree,
rlay-rl_sessions)
@@ -2564,6 +2567,7 @@ relay_dispatch_pfe(int fd, short event, 
0, 0, -1, con, sizeof(*con));
imsg_compose_event(iev, IMSG_CTL_END,
0, 0, -1, NULL, 0);
+   env-sc_statstop = 0;
break;
case IMSG_CTL_LOG_VERBOSE:
memcpy(verbose, imsg.data, sizeof(verbose));
Index: relayd.h
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.h,v
retrieving revision 1.138
diff -u -p -r1.138 relayd.h
--- relayd.h26 Oct 2010 15:04:37 -  1.138
+++ relayd.h18 Nov 2010 16:12:29 -
@@ -663,6 +663,7 @@ struct relayd {
 
struct event sc_statev;
struct timeval   sc_statinterval;
+   int  sc_statstop;
 
int  sc_snmp;
struct event sc_snmpto;

Re: user/6509: relayctl show sessions make relayd crash

[Jonathan Gray]

The following reply was made to PR user/6509; it has been noted by GNATS.

From: Jonathan Gray j...@goblin.cx
To: janj+open...@wemf.org
Cc: gn...@openbsd.org
Subject: Re: user/6509: relayctl show sessions make relayd crash
Date: Fri, 19 Nov 2010 04:28:45 +1100

 The problem is we have multiple handlers and get
 IMSG_STATISTICS when in the secondary handler.
 
 Try the following diff from reyk:
 
 Index: relay.c
 ===
 RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
 retrieving revision 1.124
 diff -u -p -r1.124 relay.c
 --- relay.c16 Nov 2010 15:31:01 -  1.124
 +++ relay.c18 Nov 2010 16:12:29 -
 @@ -567,10 +567,12 @@ relay_statistics(int fd, short events, v
if (resetday)
cur-last_day = 0;
  
 -  crs.id = rlay-rl_conf.id;
 -  crs.proc = proc_id;
 -  imsg_compose_event(iev_pfe, IMSG_STATISTICS, 0, 0, -1,
 -  crs, sizeof(crs));
 +  if (!env-sc_statstop) {
 +  crs.id = rlay-rl_conf.id;
 +  crs.proc = proc_id;
 +  imsg_compose_event(iev_pfe, IMSG_STATISTICS, 0, 0, -1,
 +  crs, sizeof(crs));
 +  }
  
for (con = SPLAY_ROOT(rlay-rl_sessions);
con != NULL; con = next_con) {
 @@ -2556,6 +2558,7 @@ relay_dispatch_pfe(int fd, short event, 
evtimer_add(con-se_ev, tv);
break;
case IMSG_CTL_SESSION:
 +  env-sc_statstop = 1;
TAILQ_FOREACH(rlay, env-sc_relays, rl_entry)
SPLAY_FOREACH(con, session_tree,
rlay-rl_sessions)
 @@ -2564,6 +2567,7 @@ relay_dispatch_pfe(int fd, short event, 
0, 0, -1, con, sizeof(*con));
imsg_compose_event(iev, IMSG_CTL_END,
0, 0, -1, NULL, 0);
 +  env-sc_statstop = 0;
break;
case IMSG_CTL_LOG_VERBOSE:
memcpy(verbose, imsg.data, sizeof(verbose));
 Index: relayd.h
 ===
 RCS file: /cvs/src/usr.sbin/relayd/relayd.h,v
 retrieving revision 1.138
 diff -u -p -r1.138 relayd.h
 --- relayd.h   26 Oct 2010 15:04:37 -  1.138
 +++ relayd.h   18 Nov 2010 16:12:29 -
 @@ -663,6 +663,7 @@ struct relayd {
  
struct event sc_statev;
struct timeval   sc_statinterval;
 +  int  sc_statstop;
  
int  sc_snmp;
struct event sc_snmpto;

Re: system/6516: relayctl reload : command failed

[Jonathan Gray]

On Thu, Nov 25, 2010 at 08:41:52PM +0200, Alexey Suslikov wrote:
 Xavier Beaudouin wrote:
 
   Description:
 
  using relayctl reload, fails miserably with command failed.
 
  kill relayd parent and starting it again work correctly.
 
 Code in usr.sbin/relayd/control.c says:
 
   case IMSG_CTL_RELOAD:
   if (env-sc_prefork_relay  0) {
   imsg_compose_event(c-iev, IMSG_CTL_FAIL,
   0, 0, -1, NULL, 0);
   break;
   }
 
 Is it correct that with L7 relays sc_prefork_relay is always  0 and reload
 is only supported for !L7 configurations?

Right, reload only works with redirects not relays currently.

Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url

[Jonathan Gray]

Try this diff against -current.  You'll have to apply
the patch from sys/dev/mii and run 'make' afterwards
to regenerate the headers.

Index: miidevs
===
RCS file: /cvs/src/sys/dev/mii/miidevs,v
retrieving revision 1.116
diff -u -p -r1.116 miidevs
--- miidevs 21 Jan 2011 09:46:13 -  1.116
+++ miidevs 19 Dec 2011 12:52:37 -
@@ -159,6 +159,7 @@ model xxBROADCOM2 BCM5709C  0x003c  BCM570
 model xxBROADCOM2 BCM5761  0x003d  BCM5761 10/100/1000baseT PHY
 model xxBROADCOM2 BCM5709S 0x003f  BCM5709S 1000/2500baseSX PHY
 model xxBROADCOM3 BCM57780 0x0019  BCM57780 10/100/1000baseT PHY
+model xxBROADCOM3 BCM57785 0x0024  BCM57785 10/100/1000baseT PHY
 model BROADCOM BCM5400 0x0004  BCM5400 1000baseT PHY
 model BROADCOM BCM5401 0x0005  BCM5401 1000baseT PHY
 model BROADCOM BCM5411 0x0007  BCM5411 1000baseT PHY
Index: brgphy.c
===
RCS file: /cvs/src/sys/dev/mii/brgphy.c,v
retrieving revision 1.93
diff -u -p -r1.93 brgphy.c
--- brgphy.c24 May 2010 21:23:23 -  1.93
+++ brgphy.c19 Dec 2011 12:52:37 -
@@ -176,6 +176,8 @@ static const struct mii_phydesc brgphys[
  MII_STR_xxBROADCOM2_BCM5709CAX },
{ MII_OUI_xxBROADCOM3,  MII_MODEL_xxBROADCOM3_BCM57780,
  MII_STR_xxBROADCOM3_BCM57780 },
+   { MII_OUI_xxBROADCOM3,  MII_MODEL_xxBROADCOM3_BCM57785,
+ MII_STR_xxBROADCOM3_BCM57785 },
{ MII_OUI_BROADCOM2,MII_MODEL_BROADCOM2_BCM5906,
  MII_STR_BROADCOM2_BCM5906 },

Re: Intel PRO/1000 PF em() network card not working with MSI on Dell R610

[Jonathan Gray]

On Tue, Feb 14, 2012 at 10:52:49AM +0100, David Imhoff wrote:
 Synopsis:Intel PRO/1000 PF em() network card not working with MSI
 on Dell R610
 Category:Kernel/i386
 Environment:
   System  : OpenBSD 5.1
   Details : OpenBSD 5.1 (GENERIC.MP) #5: Mon Feb 13 12:12:18 CET
 2012

 r...@obsd50.fox.local:/usr/src/sys/arch/i386/compile/GENERIC.MP
 
   Architecture: OpenBSD.i386
   Machine : i386
 Description:
   My Intel PRO/1000 PF network card in a Dell PowerEdge R610 server,
 stopped
   functioning after upgrading to OpenBSD 5.0. The card does not
 transmit any
   data. When trying to send a packet the following error appears in the
   kernel logging:
em0: watchdog timeout -- resetting
 
   I found that disabling MSI in the em* driver, by always setting
   'sc-osdep.em_pa.pa_flags = ~PCI_FLAGS_MSI_ENABLED;' in em_attach(),
   made the card function again. Of course this is not a structural fix.
 
   The problem does not seem card or driver related. Since the same model
   and subtype card, in a Dell PowerEdge 1950, does function properly
 with
   MSI enabled. I also tried the same setup with multiple revisions of
 the
   R610, with the same result.

This appears to be a silicon level flaw:

From Intel 82571EB/82572EI Ethernet Controller Specification Update:

63. Byte Enables 2 and 3 Are Not Set on MSI Writes Problem: MSI
(format code definition Message Signal Interrupts) writes on the 82571EB
will not have the upper two Byte Enables (BE) set.

Implication: The PCI specification requires Byte Enables 2 and 3 to be
set even though that data will always be zero. Because the
82571/82572 does not set these Byte Enables, MSI writes fail to
generate interrupts on systems with chipsets that have been designed
to require these Bytes Enables to be set. This errata only applies
when MSI is supported and enabled by the system and OS.

Workaround: None, As long as MSI is being used, Byte Enables 2 and 3
will not be set.

Status:  No Fix.

--

So it seems to be safe we should not try to enable MSI on 82571/82572
at all.

Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.261
diff -u -p -r1.261 if_em.c
--- if_em.c 5 Oct 2011 02:52:09 -   1.261
+++ if_em.c 14 Feb 2012 10:27:03 -
@@ -329,8 +329,11 @@ em_attach(struct device *parent, struct 
/* Determine hardware revision */
em_identify_hardware(sc);
 
-   /* Only use MSI on the newer PCIe parts */
-   if (sc-hw.mac_type  em_82571)
+   /*
+* Only use MSI on the newer PCIe parts, with the exception
+* of 82571/82572 due to Byte Enables 2 and 3 Are Not Set errata
+*/
+   if (sc-hw.mac_type = em_82572)
sc-osdep.em_pa.pa_flags = ~PCI_FLAGS_MSI_ENABLED;
 
/* Parameters (to be read from user) */

Re: Intel 82579LM auto negotiation fails at boot

[Jonathan Gray]

On Sun, Mar 25, 2012 at 10:21:58PM +0900, Yoshihisa Matsushita wrote:
 Synopsis:Intel 82579LM auto negotiation fails at boot
 Category:amd64 kernel system
 Environment:
   System  : OpenBSD 5.1
   Details : OpenBSD 5.1-current (GENERIC.MP) #227: Thu Mar 22 
 11:10:40 MDT 2012

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
   em(4) describes 82579LM is one of supported chips, but
   auto-negotiation fails at boot, always links at 100Mbps on
   Thinkpad X220 (4286CTO).
 
   Despite of sudo ifconfig em0 media showing 1000BaseT
   capability, manually select 'media 1000baseT mediaopt
   full-duplex' also 'media 1000baseT' with ifconfig bring no
   links at all.
 
 How-To-Repeat:
   Rebooting system.
 Fix:
   Following patch fix my problems, auto-negotiation at boot and
   ifconfig media works as expected. I haven't checked any other
   em_pch2lan machines since I don't have any. Tests needed.

This points to a general problem with reset on 82579/pch2.

It seems we are writing the wrong registers to disable the management
interference with the chip in non managed mode.

I think we need something along the lines of the following,
untested as I don't have any machines with pch2.

Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.68
diff -u -p -r1.68 if_em_hw.c
--- if_em_hw.c  29 Nov 2011 04:10:59 -  1.68
+++ if_em_hw.c  26 Mar 2012 02:33:16 -
@@ -158,7 +158,9 @@ static void em_release_eeprom(struct em_
 static voidem_standby_eeprom(struct em_hw *);
 static int32_t em_set_vco_speed(struct em_hw *);
 static int32_t em_polarity_reversal_workaround(struct em_hw *);
+#if 0
 static void em_pch2lan_disable_hw_config(struct em_hw *, boolean_t);
+#endif
 static int32_t em_set_phy_mode(struct em_hw *);
 static int32_t em_host_if_read_cookie(struct em_hw *, uint8_t *);
 static uint8_t em_calculate_mng_checksum(char *, uint32_t);
@@ -171,6 +173,7 @@ int32_t em_link_stall_workaround_hv(str
 int32_tem_k1_gig_workaround_hv(struct em_hw *, boolean_t);
 int32_tem_k1_workaround_lv(struct em_hw *);
 int32_tem_configure_k1_ich8lan(struct em_hw *, boolean_t);
+void   em_gate_hw_phy_config_ich8lan(struct em_hw *, boolean_t);
 int32_tem_access_phy_wakeup_reg_bm(struct em_hw *, uint32_t,
uint16_t *, boolean_t);
 int32_tem_access_phy_debug_regs_hv(struct em_hw *, uint32_t,
@@ -836,12 +839,18 @@ em_reset_hw(struct em_hw *hw)
 
if ((hw-mac_type == em_pch2lan) 
!(E1000_READ_REG(hw, FWSM)  
E1000_FWSM_FW_VALID)) {
-   em_pch2lan_disable_hw_config(hw, TRUE);
+   em_gate_hw_phy_config_ich8lan(hw, TRUE);
}
}
em_get_software_flag(hw);
E1000_WRITE_REG(hw, CTRL, (ctrl | E1000_CTRL_RST));
msec_delay(5);
+
+   if (hw-mac_type == em_pch2lan  !hw-phy_reset_disable 
+   !(E1000_READ_REG(hw, FWSM)  E1000_FWSM_FW_VALID)) {
+   msec_delay(10);
+   em_gate_hw_phy_config_ich8lan(hw, FALSE);
+   }
break;
default:
E1000_WRITE_REG(hw, CTRL, (ctrl | E1000_CTRL_RST));
@@ -1156,7 +1165,7 @@ em_init_hw(struct em_hw *hw)
}
 
if (hw-mac_type == em_pch2lan)
-   em_pch2lan_disable_hw_config(hw, TRUE);
+   em_gate_hw_phy_config_ich8lan(hw, TRUE);
 
/*
 * Reset the PHY before any acccess to it.  Doing so,
@@ -1169,7 +1178,7 @@ em_init_hw(struct em_hw *hw)
 
if (hw-mac_type == em_pch2lan 
(fwsm  E1000_FWSM_FW_VALID) == 0)
-   em_pch2lan_disable_hw_config(hw, FALSE);
+   em_gate_hw_phy_config_ich8lan(hw, FALSE);
 
/* Set MDIO slow mode before any other MDIO access */
ret_val = em_set_mdio_slow_mode_hv(hw);
@@ -8532,6 +8541,7 @@ em_polarity_reversal_workaround(struct e
return E1000_SUCCESS;
 }
 
+#if 0
 /*
  *  Set whether the PHY self-configures itself in hardware
  */
@@ -8549,6 +8559,7 @@ static void em_pch2lan_disable_hw_config
 
E1000_WRITE_REG(hw, CTRL_EXT, ctrl_ext);
 }
+#endif
 
 /**
  *
@@ -10141,3 +10152,32 @@ em_configure_k1_ich8lan(struct em_hw *hw
 out:
return ret_val;
 }
+
+/**
+ *  e1000_gate_hw_phy_config_ich8lan - disable PHY config via hardware
+ *  @hw:   pointer to the HW structure
+ *  @gate: boolean set 

Re: Unknown vendor with WinTV PVR-150 l.p.

[Jonathan Gray]

On Tue, Mar 27, 2012 at 11:35:33PM +0200, e...@gmx.net wrote:
 Hello
 
 I have put a Hauppauge WinTV PVR-150 low profile PCI card into my computer. 
 bktr(4) should work with WinTV cards, but it seem not to recognize the card. 
 Maybe its just the ID which is unknown to the driver.
 
 Is it possible to add this card to the supported devices, or is there another 
 solution to use this card with OpenBSD?
 
 I get this from dmesg:
 unknown vendor 0x product 0x0016 (class multimedia subclass video, rev 
 0x01) at pci2 dev 5 function 0 not configured

This is not based on a brooktree device but rather
Conexant cx23416/cx23415 and would need a different driver to
be written or ported.

more 82579LM/pch2 workarounds

[Jonathan Gray]

On Wed, Aug 15, 2012 at 02:13:18PM +0400, Yuriy Nikonov wrote:
 Synopsis:
 Incorrect working netcard on chip Intel 82579LM with network media/link
 Category:
 bugs tech
 Environment:
   System  : OpenBSD 5.1
   Details : OpenBSD 5.1 (SERVER) #5: Mon Aug 13 16:50:36 MSK 2012

 r...@server.lan.home:/usr/src/sys/arch/amd64/compile/SERVER
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
 Netcard em0 on chip Intel 82579LM can't link up in media mode 1000baseT, in 
 autoselect mode 
 linking on 100baseTX full-duplex. In 1000baseT mode can to switch manually, 
 but link on switch
 lights off. Netcard officially 1Gbit and under FreeBSD 9.0 it works correctly 
 in 1000baseT mode.

Can you try the following diff?  These pch chips are very
much a game of find the next workaround.

Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.69
diff -u -p -r1.69 if_em_hw.c
--- if_em_hw.c  17 May 2012 10:45:17 -  1.69
+++ if_em_hw.c  20 Aug 2012 14:35:29 -
@@ -168,6 +168,7 @@ static int32_t  em_configure_kmrn_for_100
 static int32_t em_set_pciex_completion_timeout(struct em_hw *hw);
 static int32_t em_set_mdio_slow_mode_hv(struct em_hw *);
 int32_tem_hv_phy_workarounds_ich8lan(struct em_hw *);
+int32_tem_lv_phy_workarounds_ich8lan(struct em_hw *);
 int32_tem_link_stall_workaround_hv(struct em_hw *);
 int32_tem_k1_gig_workaround_hv(struct em_hw *, boolean_t);
 int32_tem_k1_workaround_lv(struct em_hw *);
@@ -183,6 +184,7 @@ voidem_power_up_serdes_link_82575(stru
 int32_tem_get_pcs_speed_and_duplex_82575(struct em_hw *, 
uint16_t *,
 uint16_t *);
 int32_tem_set_eee_i350(struct em_hw *); 
+int32_tem_set_eee_pchlan(struct em_hw *);
 
 /* IGP cable length table */
 static const uint16_t 
@@ -569,6 +571,7 @@ em_set_mac_type(struct em_hw *hw)
case E1000_DEV_ID_PCH2_LV_LM:
case E1000_DEV_ID_PCH2_LV_V:
hw-mac_type = em_pch2lan;
+   hw-eee_enable = 1;
break;
case E1000_DEV_ID_EP80579_LAN_1:
hw-mac_type = em_icp_;
@@ -870,7 +873,7 @@ em_reset_hw(struct em_hw *hw)
return ret_val;
}
else if (hw-mac_type == em_pch2lan) {
-   ret_val = em_set_mdio_slow_mode_hv(hw);
+   ret_val = em_lv_phy_workarounds_ich8lan(hw);
if (ret_val)
return ret_val;
}
@@ -3681,6 +3684,13 @@ em_check_for_link(struct em_hw *hw)
 */
em_check_downshift(hw);
 
+   /* Enable/Disable EEE after link up */
+   if (hw-mac_type == em_pch2lan) {
+   ret_val = em_set_eee_pchlan(hw);
+   if (ret_val)
+   return ret_val;
+   }
+
/*
 * If we are on 82544 or 82543 silicon and
 * speed/duplex are forced to 10H or 10F, then we
@@ -10189,6 +10199,51 @@ out:
return ret_val;
 }
 
+/**
+ *  em_lv_phy_workarounds_ich8lan - A series of Phy workarounds to be
+ *  done after every PHY reset.
+ **/
+int32_t
+em_lv_phy_workarounds_ich8lan(struct em_hw *hw)
+{
+   int32_t ret_val = E1000_SUCCESS;
+   uint16_t swfw;
+
+   DEBUGFUNC(e1000_lv_phy_workarounds_ich8lan);
+
+   if (hw-mac_type != em_pch2lan)
+   goto out;
+
+   /* Set MDIO slow mode before any other MDIO access */
+   ret_val = em_set_mdio_slow_mode_hv(hw);
+
+   swfw = E1000_SWFW_PHY0_SM;
+   ret_val = em_swfw_sync_acquire(hw, swfw);
+   if (ret_val)
+   goto out;
+   ret_val = em_write_phy_reg(hw, I82579_EMI_ADDR,
+  I82579_MSE_THRESHOLD);
+   if (ret_val)
+   goto release;
+   /* set MSE higher to enable link to stay up when noise is high */
+   ret_val = em_write_phy_reg(hw, I82579_EMI_DATA,
+  0x0034);
+   if (ret_val)
+   goto release;
+   ret_val = em_write_phy_reg(hw, I82579_EMI_ADDR,
+  I82579_MSE_LINK_DOWN);
+   if (ret_val)
+   goto release;
+   /* drop link after 5 times MSE threshold was reached */
+   ret_val = em_write_phy_reg(hw, I82579_EMI_DATA,
+  0x0005);
+release:
+   em_swfw_sync_release(hw, swfw);
+
+out:
+   return ret_val;
+}
+
 int32_t
 em_set_eee_i350(struct em_hw *hw) 
 {
@@ -10217,3 +10272,36 @@ em_set_eee_i350(struct em_hw *hw) 
 out:

Re: more 82579LM/pch2 workarounds

[Jonathan Gray]

On Tue, Nov 27, 2012 at 10:39:21AM +0400, Yuriy Nikonov wrote:
 
 Good day,
 
 saw on a site new release of OpenBSD 5.2. Wanted to take an interest about 
 the 
 problem described above - whether there were any changes in the em driver? 
 Tried to load a kernel from FreeBSD 9.0 - 82579LM seems works correctly, on 
 gigabit. There can be a driver analysis from FreeBSD something can help?

There is now a fix for this in -current, so it should work
as expected in future snapshots and 5.3.

Re: DVI output not detected with kms

[Jonathan Gray]

On Fri, Mar 29, 2013 at 12:33:32PM +1100, Jonathan Gray wrote:
 On Thu, Mar 28, 2013 at 09:38:20AM +0100, Ralf Horstmann wrote:
  Hi,
  
  with current snapshot (i386) the DVI output of the docking station of
  my Fujitsu Lifebook T4215 is not detected anymore. Under Linux (Debian
  kernel 3.2) it's detected as DVI1. With older OpenBSD versions it was
  detected as TMDS-1.
  
  VGA on the docking station works fine as well as directly attached to the
  laptop. In contrast to VGA, there is no DVI output at the laptop, only at 
  the
  docking station.
  
  Cheers,
  Ralf
 
 It sounds like your docking station has a SDVO output, which
 apparently requires bitbanging for gmbus which we don't
 yet do.

Looking over the sdvo code it seems part of the i2c code
is wrong, try this:

Index: intel_sdvo.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_sdvo.c,v
retrieving revision 1.2
diff -u -p -r1.2 intel_sdvo.c
--- intel_sdvo.c19 Mar 2013 03:58:10 -  1.2
+++ intel_sdvo.c29 Mar 2013 02:21:05 -
@@ -393,12 +393,23 @@ bool
 intel_sdvo_read_byte(struct intel_sdvo *intel_sdvo, u8 addr, u8 *ch)
 {
uint8_t cmd = 0;
+   int ret;
 
iic_acquire_bus(intel_sdvo-i2c, 0);
-   iic_exec(intel_sdvo-i2c, I2C_OP_READ_WITH_STOP, addr, cmd, 1, ch, 1, 
0);
+   ret = iic_exec(intel_sdvo-i2c, I2C_OP_WRITE_WITH_STOP,
+   intel_sdvo-slave_addr, cmd, 1, addr, 1, 0); 
+   if (ret) {
+   iic_release_bus(intel_sdvo-i2c, 0);
+   return (false);
+   }
+   ret = iic_exec(intel_sdvo-i2c, I2C_OP_READ_WITH_STOP,
+   intel_sdvo-slave_addr, cmd, 1, ch, 1, 0);
iic_release_bus(intel_sdvo-i2c, 0);
 
-   return true;
+   if (ret)
+   return (false);
+   else
+   return (true);
 }
 
 #define SDVO_CMD_NAME_ENTRY(cmd) {cmd, #cmd}

Re: X server crash with intel kms

[Jonathan Gray]

On Fri, Mar 29, 2013 at 07:20:26PM +0100, Ralf Horstmann wrote:
 Hi,
 
 with latest snapshot kernel, the X server crashes pretty reliably for me when
 opening new thumbnail tabs in Firefox (version 18.0.1p0). Sometimes it crashes
 on first new tab, sometimes I need to open a few of them. Xorg log says:
 
 [   337.411] (EE) intel(0): Failed to submit batch buffer, expect rendering 
 corruption or even a frozen display: Unknown error: -11.
 [   337.415] (EE) intel(0): Failed to submit batch buffer, expect rendering 
 corruption or even a frozen display: Unknown error: -11.
 [   337.426] Segmentation fault at address 0x8d4239fc
 [   337.426]
 Fatal server error:
 [   337.426] Caught signal 11 (Segmentation fault). Server aborting
 
 The changeset adding i915_gem_execbuffer_reserve_object seems to trigger the
 bug. After backing out that changeset, the problem is gone.

Thanks for tracking this down, I've backed out the parts that
were calling i915_gem_execbuffer_reserve_object but kept
the (now uncalled) functions there.  Can you cvs up and
check that everything is fine still?

Re: Driver for Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter

[Jonathan Gray]

Try the following diff, you'll have to run make in
sys/dev/usb after applying.

Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.598
diff -u -p -r1.598 usbdevs
--- usbdevs 7 Mar 2013 23:39:14 -   1.598
+++ usbdevs 23 Apr 2013 09:34:55 -
@@ -4045,6 +4045,7 @@ product UNKNOWN3 ZD1211B  0x1233 ZD1211B
 
 /* Unknown vendor 4 */
 product UNKNOWN4 DM96010x8101 DM9601
+product UNKNOWN4 DM9601_2  0x9700 DM9601
 
 /* Unknown vendor 5 */
 product UNKNOWN5 NF_RIC0x0001  NF RIC
Index: if_udav.c
===
RCS file: /cvs/src/sys/dev/usb/if_udav.c,v
retrieving revision 1.61
diff -u -p -r1.61 if_udav.c
--- if_udav.c   28 Mar 2013 03:58:03 -  1.61
+++ if_udav.c   23 Apr 2013 09:35:15 -
@@ -165,6 +165,7 @@ static const struct udav_type {
{{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ZT6688 }, 0 },
{{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ADM8515 }, 0 },
{{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601 }, 0 },
+   {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601_2 }, 0 },
{{ USB_VENDOR_UNKNOWN6, USB_PRODUCT_UNKNOWN6_DM9601 }, 0 }
 };
 #define udav_lookup(v, p) ((struct udav_type *)usb_lookup(udav_devs, v, p))

Re: Driver for Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter

[Jonathan Gray]

You need to figure out what chip it has.
FreeBSD don't seem to have a man page for 'ue' or a driver in
their sys/dev/usb/net/ dir so I have no idea what it is
attaching as.

On Mon, Apr 29, 2013 at 02:04:32PM +0700, Stefanus Hermawan wrote:
 Hi Jonathan,
 
 I have test my device in FreeBSD 10-CURRENT, and run fine on 'ue' 
 pseudo-device.
 
 Any ideas?
 
 
 Sent from my iPhone
 
 On Apr 23, 2013, at 4:40 PM, Jonathan Gray j...@jsg.id.au wrote:
 
  Try the following diff, you'll have to run make in
  sys/dev/usb after applying.
  
  Index: usbdevs
  ===
  RCS file: /cvs/src/sys/dev/usb/usbdevs,v
  retrieving revision 1.598
  diff -u -p -r1.598 usbdevs
  --- usbdevs7 Mar 2013 23:39:14 -1.598
  +++ usbdevs23 Apr 2013 09:34:55 -
  @@ -4045,6 +4045,7 @@ product UNKNOWN3 ZD1211B0x1233 ZD1211B
  
  /* Unknown vendor 4 */
  product UNKNOWN4 DM96010x8101 DM9601
  +product UNKNOWN4 DM9601_20x9700 DM9601
  
  /* Unknown vendor 5 */
  product UNKNOWN5 NF_RIC0x0001NF RIC
  Index: if_udav.c
  ===
  RCS file: /cvs/src/sys/dev/usb/if_udav.c,v
  retrieving revision 1.61
  diff -u -p -r1.61 if_udav.c
  --- if_udav.c28 Mar 2013 03:58:03 -1.61
  +++ if_udav.c23 Apr 2013 09:35:15 -
  @@ -165,6 +165,7 @@ static const struct udav_type {
 {{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ZT6688 }, 0 },
 {{ USB_VENDOR_SHANTOU, USB_PRODUCT_SHANTOU_ADM8515 }, 0 },
 {{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601 }, 0 },
  +{{ USB_VENDOR_UNKNOWN4, USB_PRODUCT_UNKNOWN4_DM9601_2 }, 0 },
 {{ USB_VENDOR_UNKNOWN6, USB_PRODUCT_UNKNOWN6_DM9601 }, 0 }
  };
  #define udav_lookup(v, p) ((struct udav_type *)usb_lookup(udav_devs, v, p))

Re: Use after free in ami(4)

[Jonathan Gray]

On Sat, May 04, 2013 at 07:04:59PM -0400, Kenneth R Westerback wrote:
 On Sat, May 04, 2013 at 08:25:18PM +0300, Arto Jonsson wrote:
  Spotted by LLVM static analyser.
  
  In /usr/src/sys/dev/ic/ami.c line 499 ami_freemem(sc, am) is called. In
  the next block ami_alloc_ccbs(...) is called. If the result != 0 control
  jumps to free_mbox in line 614. This falls through to call
  ami_freemem(sc, am) again.
  
 
 Is LLMV happy with this diff?
 
  Ken
 
 Index: ami.c
 ===
 RCS file: /cvs/src/sys/dev/ic/ami.c,v
 retrieving revision 1.223
 diff -u -p -r1.223 ami.c
 --- ami.c 9 Jan 2012 18:50:44 -   1.223
 +++ ami.c 4 May 2013 23:02:16 -
 @@ -497,6 +497,7 @@ ami_attach(struct ami_softc *sc)
   }
  
   ami_freemem(sc, am);
 + am = NULL;
  
   if (ami_alloc_ccbs(sc, AMI_MAXCMDS + 1) != 0) {
   /* error already printed */
 @@ -614,7 +615,8 @@ ami_attach(struct ami_softc *sc)
  free_mbox:
   ami_freemem(sc, sc-sc_mbox_am);
  free_idata:
 - ami_freemem(sc, am);
 + if (am)
 + ami_freemem(sc, am);
  
   return (1);
  }

here is the diff I had for ami, the mfi one included here as a bonus

Index: ami.c
===
RCS file: /cvs/src/sys/dev/ic/ami.c,v
retrieving revision 1.223
diff -u -p -r1.223 ami.c
--- ami.c   9 Jan 2012 18:50:44 -   1.223
+++ ami.c   5 May 2013 01:06:08 -
@@ -496,12 +496,12 @@ ami_attach(struct ami_softc *sc)
sc-sc_link.openings = sc-sc_maxcmds;
}
 
-   ami_freemem(sc, am);
-
if (ami_alloc_ccbs(sc, AMI_MAXCMDS + 1) != 0) {
/* error already printed */
goto free_mbox;
}
+
+   ami_freemem(sc, am);
 
/* hack for hp netraid version encoding */
if ('A' = sc-sc_fwver[2]  sc-sc_fwver[2] = 'Z' 
Index: mfi.c
===
RCS file: /cvs/src/sys/dev/ic/mfi.c,v
retrieving revision 1.144
diff -u -p -r1.144 mfi.c
--- mfi.c   3 May 2013 02:46:28 -   1.144
+++ mfi.c   3 May 2013 07:20:03 -
@@ -1470,8 +1470,10 @@ mfi_bio_getitall(struct mfi_softc *sc)
if (cfg == NULL)
goto done;
if (mfi_mgmt(sc, MR_DCMD_CONF_GET, MFI_DATA_IN, sizeof *cfg, cfg,
-   NULL))
+   NULL)) {
+   free(cfg, M_DEVBUF);
goto done;
+   }
 
size = cfg-mfc_size;
free(cfg, M_DEVBUF);

Re: Kernel panic on current amd64 running under Ubuntu KVM (patch included)

[Jonathan Gray]

That is quite a large hammer.  It would be preferable to
find out which msr it objects to and guard it with a specific cpuid
check, and/or fix the hypervisor.

On Mon, May 20, 2013 at 10:34:43AM +0300, Roman Kravchuk wrote:
 patch_amd64errata.diff
 
 Index: amd64/amd64/amd64errata.c
 ===
 RCS file: /cvs/src/sys/arch/amd64/amd64/amd64errata.c,v
 retrieving revision 1.3
 diff -u -p -u -p -r1.3 amd64errata.c
 --- amd64/amd64/amd64errata.c27 Mar 2012 05:59:46 -1.3
 +++ amd64/amd64/amd64errata.c19 May 2013 23:48:11 -
 @@ -293,6 +293,9 @@ amd64_errata(struct cpu_info *ci)
  int found = 0;
  int corrected = 0;
 
 +if (ci-ci_feature_eflags  CPUIDECX_RAZ)
 +return;
 +
  CPUID(0x8001, code, dummy, dummy, dummy);
 
  for (i = 0; ; i += 2) {
 Index: amd64/amd64/identcpu.c
 ===
 RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
 retrieving revision 1.47
 diff -u -p -u -p -r1.47 identcpu.c
 --- amd64/amd64/identcpu.c6 May 2013 04:32:12 -1.47
 +++ amd64/amd64/identcpu.c19 May 2013 23:48:11 -
 @@ -129,6 +129,7 @@ const struct {
  { CPUIDECX_AVX,AVX },
  { CPUIDECX_F16C,F16C },
  { CPUIDECX_RDRAND,RDRAND },
 +{ CPUIDECX_RAZ,RAZ }
  }, cpu_ecpuid_ecxfeatures[] = {
  { CPUIDECX_LAHF,LAHF },
  { CPUIDECX_CMPLEG,CMPLEG },
 Index: amd64/include/specialreg.h
 ===
 RCS file: /cvs/src/sys/arch/amd64/include/specialreg.h,v
 retrieving revision 1.25
 diff -u -p -u -p -r1.25 specialreg.h
 --- amd64/include/specialreg.h6 May 2013 04:32:12 -1.25
 +++ amd64/include/specialreg.h19 May 2013 23:48:11 -
 @@ -158,6 +158,7 @@
  #defineCPUIDECX_AVX0x1000/* Advanced Vector Extensions */
  #defineCPUIDECX_F16C0x2000/* 16bit fp conversion  */
  #defineCPUIDECX_RDRAND0x4000/* RDRAND instruction  */
 +#defineCPUIDECX_RAZ0x8000/* RAZ. Indicates guest state. */
 
  /*
   * Structured Extended Feature Flags Parameters (CPUID function 0x7,
 leaf 0)

Re: Kernel panic on current amd64 running under Ubuntu KVM (patch included)

[Jonathan Gray]

On Mon, May 20, 2013 at 01:50:39PM +, Alexey E. Suslikov wrote:
 Jonathan Gray jsg at jsg.id.au writes:
 
  That is quite a large hammer.  It would be preferable to
  find out which msr it objects to and guard it with a specific cpuid
  check, and/or fix the hypervisor.
 
 From NetBSD PR/47677 (http://gnats.netbsd.org/47677)
 
 I think x86_errata should be avoided if NetBSD running
 on virtual machine because accesses to MSR may be restricted
 
 While above statement is an assumption, it is highly possible
 for hypervisor to restrict operations on model-specific regs.
 
 For me it's kinda grounded approach, because erratas applied
 on host level may conflict with what guests want, increasing
 a possibility of screwing up things.
 
 So what is the point for guest to run erratas if hypervisor
 may already done that upwards?

Filling the kernel full of if not really running on hardware
do something else paths is asking for trouble.  If a hypervisor
claims to be a specific model of a processor it should not be
surprised when it gets msrs that processor can handle.

Re: Intel GM45 hangs

[Jonathan Gray]

On Mon, Jul 15, 2013 at 01:13:39PM +0300, ja...@cieti.lv wrote:
 Synopsis:Intel GM45 hangs
 Category:amd64
 Environment:
   System  : OpenBSD 5.4
   Details : OpenBSD 5.4-beta (GENERIC.MP) #28: Sat Jul 13
 12:41:36 MDT 2013

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
   error: [drm:pid2:i915_hangcheck_hung] *ERROR* Hangcheck timer
 elapsed... GPU hung
 error: [drm:pid3:init_ring_common] *ERROR* failed to set render ring
 head to zero ctl  head 23605c14 tail  start 0200
 error: [drm:pid3:init_ring_common] *ERROR* render ring
 initialization failed ctl 0001f001 head 23605c14 tail  start
 0200
 error: [drm:pid2:i915_hangcheck_hung] *ERROR* Hangcheck timer
 elapsed... GPU hung
 error: [drm:pid3:i915_reset] *ERROR* GPU hanging too fast, declaring
 wedged!
 error: [drm:pid3:i915_reset] *ERROR* Failed to reset chip.
 
 How-To-Repeat:
   The GPU hangs while watching youtube.com videos using
 chromium-27.0.1453.110p0-proprietary. On my computer it is easily
 repeatable, I just have to play some videos for a while and then it
 randomly happens. I have seen it happen while surfing in Firefox
 once too. I am not very sure, but it seems to me, that it started to
 happen after X update to 1.14.1. Is there any way you would
 recommend to debug this?
 Fix:
   I have no idea.

Can you try run a kernel with the following diff?  It disables
powersaving and framebuffer compression and would help
narrow things down.

Index: i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.35
diff -u -p -r1.35 i915_drv.c
--- i915_drv.c  5 Jul 2013 07:20:27 -   1.35
+++ i915_drv.c  15 Jul 2013 12:59:53 -
@@ -69,7 +69,7 @@ extern struct mutex mchdev_lock;
 int i915_panel_ignore_lid = 1;
 
 /* Enable powersavings, fbc, downclocking, etc. (default: true) */
-unsigned int i915_powersave = 1;
+unsigned int i915_powersave = 0;
 
 /* Use semaphores for inter-ring sync (default: -1 (use per-chip defaults)) */
 int i915_semaphores = -1;
@@ -78,7 +78,7 @@ int i915_semaphores = -1;
  * Enable frame buffer compression for power savings
  * (default: -1 (use per-chip default))
  */
-int i915_enable_fbc = -1;
+int i915_enable_fbc = 0;
 
 /*
  * Enable power-saving render C-state 6.

Re: Intel GM45 hangs

[Jonathan Gray]

On Mon, Jul 15, 2013 at 06:07:09PM +0300, ja...@cieti.lv wrote:
 On 15.07.2013 16:07, Jonathan Gray wrote:
 Can you try run a kernel with the following diff?  It disables
 powersaving and framebuffer compression and would help
 narrow things down.
 
 Index: i915_drv.c
 ===
 RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
 retrieving revision 1.35
 diff -u -p -r1.35 i915_drv.c
 --- i915_drv.c   5 Jul 2013 07:20:27 -   1.35
 +++ i915_drv.c   15 Jul 2013 12:59:53 -
 @@ -69,7 +69,7 @@ extern struct mutex mchdev_lock;
  int i915_panel_ignore_lid = 1;
 
  /* Enable powersavings, fbc, downclocking, etc. (default: true) */
 -unsigned int i915_powersave = 1;
 +unsigned int i915_powersave = 0;
 
  /* Use semaphores for inter-ring sync (default: -1 (use per-chip
 defaults)) */
  int i915_semaphores = -1;
 @@ -78,7 +78,7 @@ int i915_semaphores = -1;
   * Enable frame buffer compression for power savings
   * (default: -1 (use per-chip default))
   */
 -int i915_enable_fbc = -1;
 +int i915_enable_fbc = 0;
 
  /*
   * Enable power-saving render C-state 6.
 
 Thank you for your diff, but unfortunately it does not solve the
 problem. Is there anything else I can try?
 
 Is there a way on OpenBSD to get i915_error_state mentioned in
 Xorg.0.log?
 
 [  3845.493] (EE) intel(0): When reporting this, please include
 i915_error_state from debugfs and the full dmesg.

Here is a diff that is a bit of a guess.   We don't have a way
to produce something similiar to the i915_error_state files
at the moment.


https://bugs.freedesktop.org/show_bug.cgi?id=55984#c143

commit 262b6d363fcff16359c93bd58c297f961f6e6273
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Tue Jan 15 16:17:54 2013 +

drm/i915: Invalidate the relocation presumed_offsets along the slow path

In the slow path, we are forced to copy the relocations prior to
acquiring the struct mutex in order to handle pagefaults. We forgo
copying the new offsets back into the relocation entries in order to
prevent a recursive locking bug should we trigger a pagefault whilst
holding the mutex for the reservations of the execbuffer. Therefore, we
need to reset the presumed_offsets just in case the objects are rebound
back into their old locations after relocating for this exexbuffer - if
that were to happen we would assume the relocations were valid and leave
the actual pointers to the kernels dangling, instant hang.

Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Sun Nov 21 22:07:12 2010 +

drm/i915: Handle pagefaults in execbuffer user relocations

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@fwll.ch
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Index: i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.35
diff -u -p -r1.35 i915_drv.c
--- i915_drv.c  5 Jul 2013 07:20:27 -   1.35
+++ i915_drv.c  15 Jul 2013 15:45:04 -
@@ -1726,6 +1726,12 @@ i915_gem_get_relocs_from_user(struct drm
return (EINVAL);
*relocs = drm_alloc(reloc_count * sizeof(**relocs));
for (i = 0; i  buffer_count; i++) {
+   struct drm_i915_gem_relocation_entry *user_relocs;
+   u64 invalid_offset = (u64)-1;
+   int j;
+
+   user_relocs = (void *)(uintptr_t)exec_list[i].relocs_ptr;
+
if ((ret = copyin((void *)(uintptr_t)exec_list[i].relocs_ptr,
(*relocs)[reloc_index], exec_list[i].relocation_count *
sizeof(**relocs))) != 0) {
@@ -1733,6 +1739,26 @@ i915_gem_get_relocs_from_user(struct drm
*relocs = NULL;
return (ret);
}
+
+   /* As we do not update the known relocation offsets after
+* relocating (due to the complexities in lock handling),
+* we need to mark them as invalid now so that we force the
+* relocation processing next time. Just in case the target
+* object is evicted and then rebound into its old
+* presumed_offset before the next execbuffer - if that
+* happened we would make the mistake of assuming that the
+* relocations were valid.
+*/
+   for (j = 0; j  exec_list[i].relocation_count; j++) {
+   if (DRM_COPY_TO_USER(user_relocs[j].presumed_offset,
+invalid_offset,
+sizeof(invalid_offset))) {
+   drm_free(*relocs

Re: Intel GM45 hangs

[Jonathan Gray]

On Mon, Jul 15, 2013 at 09:32:36PM +0300, ja...@cieti.lv wrote:
 Is it possible that it is related to these problems?
 
 https://code.google.com/p/chromium/issues/detail?id=252389
 https://code.google.com/p/chromium/issues/detail?id=252446

unlikely as we don't provide libva and youtube with chromium
works fine on gen7/ivy bridge here.

Re: Intel GM45 hangs

[Jonathan Gray]

On Mon, Jul 15, 2013 at 08:41:47PM +0300, ja...@cieti.lv wrote:
 
 I just applied this diff and quickly got another hang. I would like
 to mention (maybe it helps to diagnose this) that I get visual
 glitches in Youtube player area and sometimes in a whole tab where
 youtube.com is open. After GPU hangs chrome.core is in my home
 directory. Everything else I use including mplayer -vo gl,xv,x11
 works without problems. It looks like only Youtube player has this
 nasty effect on the GPU. Is it possible to trace it somehow to see
 what causes this?

There are a few things that may be relevant in terms of fixes
in newer versions of xf86-video-intel.

ftp://ftp.x.org/pub/individual/driver/xf86-video-intel-2.21.11.tar.gz

(after this they assume relaxed fencing is present and broke the
build by requiring yet another gcc extension we don't have)

as described in the xenocara README, install:

- automake 1.12 (devel/automake/1.12)
- autoconf 2.69 (devel/autoconf/2.69)
- metaauto 0.9 (or later) (devel/metaauto)
- libtool 2.4.2 (or later) (devel/libtool)

extract the above tarball and add
http://jsg.id.au/openbsd/Makefile.bsd-wrapper

make -f Makefile.bsd-wrapper obj
env XENOCARA_RERUN_AUTOCONF=Yes make -f Makefile.bsd-wrapper build

and restart your X server.

Re: Intel GM45 hangs

[Jonathan Gray]

On Tue, Jul 16, 2013 at 08:57:37AM +0300, ja...@cieti.lv wrote:
 On 16.07.2013 07:27, Jonathan Gray wrote:
 There are a few things that may be relevant in terms of fixes
 in newer versions of xf86-video-intel.
 
 ftp://ftp.x.org/pub/individual/driver/xf86-video-intel-2.21.11.tar.gz
 
 (after this they assume relaxed fencing is present and broke the
 build by requiring yet another gcc extension we don't have)
 
 as described in the xenocara README, install:
 
 - automake 1.12 (devel/automake/1.12)
 - autoconf 2.69 (devel/autoconf/2.69)
 - metaauto 0.9 (or later) (devel/metaauto)
 - libtool 2.4.2 (or later) (devel/libtool)
 
 extract the above tarball and add
 http://jsg.id.au/openbsd/Makefile.bsd-wrapper
 
 make -f Makefile.bsd-wrapper obj
 env XENOCARA_RERUN_AUTOCONF=Yes make -f Makefile.bsd-wrapper build
 
 and restart your X server.
 
 Thank you for good and detailed instructions. I compiled new driver
 successfully and verified in Xorg.0.log that it installed correctly:
 
 [  1352.617] (II) LoadModule: intel
 [  1352.617] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so
 [  1352.619] (II) Module intel: vendor=X.Org Foundation
 [  1352.619]compiled for 1.14.1, module version = 2.21.11
 [  1352.619]Module class: X.Org Video Driver
 [  1352.619]ABI class: X.Org Video Driver, version 14.1
 
 But sorry to say -- it did not help. Same problem persists.

Can you try move the relevant mesa driver to a different
directory so we can see if it is the x driver or the mesa driver
that is triggering it?

In other words move /usr/X11R6/lib/modules/dri/i965_dri.so to
a different directory outside of the ld.so search path.  Your
x log should show the software renderer 'swrast' being loaded.

Re: Intel GM45 hangs

[Jonathan Gray]

On Sun, Jul 21, 2013 at 12:34:57PM +0300, ja...@cieti.lv wrote:
 Looks like Mesa-9.1.4 does not fix this. It turns out that chromium
 just used software rendering because WebGL does not work at all.
 Running openarena hangs GPU instantly on loading with an error:
 
 intel_do_flush_locked failed: Input/output error
 
 How can I test if, for example, this diff: 
 http://freshbsd.org/commit/openbsd/304417ea27d0874895cc4e65c30324b7bd14ac22
 
 caused this problem?

There are commits stacked on top of that so the easiest way
would be to checkout src from just before that commit and build
a kernel.  Keeping in mind you'll need a version of libdrm from
a similiar timeframe out of the xenocara tree.

Re: Intel GM45 hangs

[Jonathan Gray]

On Mon, Jul 22, 2013 at 10:08:27AM +0300, ja...@cieti.lv wrote:
 Well trying to go backwards is always a bit of a risk.
 To be sure things are as intended you're best off starting
 with a 5.3 install and updating src/xenocara to a point
 before the commit with an eye on current.html
 
 I took an empty harddrive, installed 5.3 on it, then
 
 # cd /usr
 # cvs -d anon...@anoncvs.eu.openbsd.org:/cvs checkout -D 2013-06-05
 -P src ports xenocara
 
 Tried to compile, but got an error:
 
 In file included from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_locl.h:52,
  from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_cmp.c:34:
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/libasn1.h:45:18:
 error: asn1.h: No such file or directory
 In file included from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_locl.h:52,
  from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_get.c:34:
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/libasn1.h:45:18:
 error: asn1.h: No such file or directory
 In file included from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_locl.h:52,
  from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_put.c:34:
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/libasn1.h:45:18:
 error: asn1.h: No such file or directory
 In file included from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_locl.h:52,
  from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_free.c:34:
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/libasn1.h:45:18:
 error: asn1.h: No such file or directory
 In file included from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_locl.h:52,
  from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_length.c:34:
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/libasn1.h:45:18:
 error: asn1.h: No such file or directory
 In file included from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_locl.h:52,
  from
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_copy.c:34:
 /usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/libasn1.h:45:18:
 error: asn1.h: No such file or directory
 mkdep: compile failed.
 *** Error 1 in lib/libkrb5 (bsd.dep.mk:22 '.depend':
 @files=/usr/src/lib/libkrb5/../../kerberosV/src/lib/asn1/der_cmp.c
 /usr/src/lib/libk...)
 *** Error 1 in lib (bsd.subdir.mk:48 'depend')
 *** Error 1 in /usr/src (Makefile:82 'build')
 
 How do I get it to compile?

Can you show the file that is including asn1.h?  None of the mentioned
files ever included it directly according to cvsweb.

Re: Intel GM45 hangs

[Jonathan Gray]

On Mon, Jul 22, 2013 at 12:04:44PM +0300, ja...@cieti.lv wrote:
 There is something wrong with your cvs checkout, it should look
 be 1.9 not 1.7 and look like:
 http://www.openbsd.org/cgi-bin/cvsweb/src/kerberosV/src/lib/asn1/Attic/libasn1.h?rev=1
  \
 .1.1.2;content-type=text%2Fplain
 
 What would be the correct command to get a source from 2013-06-05?

It seems 1.9 is only on the vendor branch, so your checkout is likely fine.
Did you forget to run make obj before make build?  Something odd seems
to be occuring.

Re: shuttle DS47 - RTL8168 no link / lladdr

[Jonathan Gray]

On Fri, Oct 11, 2013 at 12:23:50AM +0200, m...@m021.nl wrote:
 Synopsis:Realtek 8168 ethernet not working
 Category:bugs
 Environment:
   System  : OpenBSD 5.3
   Details : OpenBSD 5.3 (GENERIC.MP) #62: Tue Mar 12 18:21:20 MDT 2013

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
   OpenBSD does recognize the NIC as Realtek 8168 but the NIC will have
   no valid mac-address and even if set, the NIC won't work.
 How-To-Repeat:
   Install OpenBSD on hardware with the RTL8186 chipset
 Fix:
   Realtek has new drivers available on there website
   (http://www.realtek.com.tw) -- Perhaps someone with the
   knowlage of how to compile and embed them into OpenBSD kernel
   can create a fix for this problem.

re(4) does not know about RTL8168G/RTL8111G, here is a diff
against -current that might work

Index: re.c
===
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.144
diff -u -p -r1.144 re.c
--- re.c5 Oct 2013 22:59:57 -   1.144
+++ re.c9 Oct 2013 01:21:41 -
@@ -223,6 +223,8 @@ static const struct re_revision {
{ RL_HWREV_8101,RTL8101 },
{ RL_HWREV_8101E,   RTL8101E },
{ RL_HWREV_8102E,   RTL8102E },
+   { RL_HWREV_8106E,   RTL8106E },
+   { RL_HWREV_8106E_SPIN1, RTL8106E },
{ RL_HWREV_8401E,   RTL8401E },
{ RL_HWREV_8402,RTL8402 },
{ RL_HWREV_8411,RTL8411 },
@@ -238,6 +240,10 @@ static const struct re_revision {
{ RL_HWREV_8168C_SPIN2, RTL8168C/8111C },
{ RL_HWREV_8168CP,  RTL8168CP/8111CP },
{ RL_HWREV_8168F,   RTL8168F/8111F },
+   { RL_HWREV_8168G,   RTL8168G/8111G },
+   { RL_HWREV_8168G_SPIN1, RTL8168G/8111G },
+   { RL_HWREV_8168G_SPIN2, RTL8168G/8111G },
+   { RL_HWREV_8168G_SPIN4, RTL8168G/8111G },
{ RL_HWREV_8105E,   RTL8105E },
{ RL_HWREV_8105E_SPIN1, RTL8105E },
{ RL_HWREV_8168D,   RTL8168D/8111D },
@@ -846,6 +852,8 @@ re_attach(struct rl_softc *sc, const cha
case RL_HWREV_8402:
case RL_HWREV_8105E:
case RL_HWREV_8105E_SPIN1:
+   case RL_HWREV_8106E:
+   case RL_HWREV_8106E_SPIN1:
sc-rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
RL_FLAG_PHYWAKE_PM | RL_FLAG_PAR | RL_FLAG_DESCV2 |
RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD |
@@ -892,6 +900,15 @@ re_attach(struct rl_softc *sc, const cha
RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_NOJUMBO;
break;
+   case RL_HWREV_8168G:
+   case RL_HWREV_8168G_SPIN1:
+   case RL_HWREV_8168G_SPIN2:
+   case RL_HWREV_8168G_SPIN4:
+   sc-rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
+   RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
+   RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_NOJUMBO |
+   RL_FLAG_EARLYOFF;
+   break;
case RL_HWREV_8169_8110SB:
case RL_HWREV_8169_8110SBL:
case RL_HWREV_8169_8110SCd:
@@ -1974,6 +1991,7 @@ re_init(struct ifnet *ifp)
 {
struct rl_softc *sc = ifp-if_softc;
u_int16_t   cfg;
+   uint32_trxcfg;
int s;
union {
u_int32_t align_dummy;
@@ -2058,7 +2076,10 @@ re_init(struct ifnet *ifp)
 
CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16);
 
-   CSR_WRITE_4(sc, RL_RXCFG, RL_RXCFG_CONFIG);
+   rxcfg = RL_RXCFG_CONFIG;
+   if (sc-rl_flags  RL_FLAG_EARLYOFF)
+   rxcfg |= RL_RXCFG_EARLYOFF;
+   CSR_WRITE_4(sc, RL_RXCFG, rxcfg);
 
/* Program promiscuous mode and multicast filters. */
re_iff(sc);
Index: rtl81x9reg.h
===
RCS file: /cvs/src/sys/dev/ic/rtl81x9reg.h,v
retrieving revision 1.76
diff -u -p -r1.76 rtl81x9reg.h
--- rtl81x9reg.h17 Mar 2013 20:47:23 -  1.76
+++ rtl81x9reg.h3 Aug 2013 13:54:57 -
@@ -186,8 +186,14 @@
 #define RL_HWREV_8105E 0x4080
 #define RL_HWREV_8105E_SPIN1   0x40C0
 #define RL_HWREV_8402  0x4400
+#define RL_HWREV_8106E 0x4480
+#define RL_HWREV_8106E_SPIN1   0x4490
 #define RL_HWREV_8168F 0x4800
 #define RL_HWREV_8411  0x4880
+#define RL_HWREV_8168G 0x4c00
+#define RL_HWREV_8168G_SPIN1   0x4c10
+#define RL_HWREV_8168G_SPIN2   0x5090
+#define RL_HWREV_8168G_SPIN4   0x5c80  
 #define RL_HWREV_8139  0x6000
 #define RL_HWREV_8139A 0x7000
 #define RL_HWREV_8139AG0x7080
@@ -277,6 +283,7 @@
 #define RL_RXCFG_RX_RUNT   0x0010
 

Re: Intel Chipset Error? OpenBSD 5.4

[Jonathan Gray]

On Sat, Nov 02, 2013 at 10:20:54PM +0100, Lakosimi wrote:
 
 error: [drm:pid21332:i915_get_vblank_timestamp] *ERROR* Invalid crtc 1
 error: [drm:pid1035:i915_get_vblank_timestamp] *ERROR* Invalid crtc 1
 error: [drm:pid3:i915_get_vblank_timestamp] *ERROR* Invalid crtc 1
 error: [drm:pid3:i915_get_vblank_timestamp] *ERROR* Invalid crtc 1
 error: [drm:pid18152:i915_get_vblank_timestamp] *ERROR* Invalid crtc 1
 error: [drm:pid18152:i915_get_vblank_timestamp] *ERROR* Invalid crtc 1

I'm not entirely sure what is going wrong with these old 845 parts.
You could try disable vblank timestamping with the following diff
(against -current, might work on 5.4 though)

Index: i915_irq.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_irq.c,v
retrieving revision 1.9
diff -u -p -r1.9 i915_irq.c
--- i915_irq.c  30 Oct 2013 02:11:32 -  1.9
+++ i915_irq.c  4 Nov 2013 03:23:12 -
@@ -2707,7 +2707,7 @@ void intel_irq_init(struct drm_device *d
dev-driver-get_vblank_counter = gm45_get_vblank_counter;
}
 
-   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   if (drm_core_check_feature(dev, DRIVER_MODESET)  !IS_GEN2(dev))
dev-driver-get_vblank_timestamp = i915_get_vblank_timestamp;
else
dev-driver-get_vblank_timestamp = NULL;

Re: patches to add support for I/O DATA ETX-US2 usb ethernet adapter and fix wrong products name.

[Jonathan Gray]

Thanks, committed.

On Sun, Nov 17, 2013 at 10:33:36PM +0900, ishit wrote:
 My ETX-US2 is 0x092a.
 
 $ usbdevs -v
 Controller /dev/usb0:
 addr 1: high speed, self powered, config 1, EHCI root hub(0x),
 NEC(0x1033), rev 1.00
  port 1 powered
  port 2 powered
  port 3 powered
  port 4 addr 2: high speed, power 224 mA, config 1, I-O DATA
 ETX-US2(0x092a), I-O DATA DEVICE,INC.(0x04bb), rev 1.01, iSerialNumber
 685AA5
  port 5 powered
 snip
 
 I fogot usbdevs.patch file.
 I am sorry.
 
 http://www.tunagu.gr.jp/~isihara/usbdevs.patchhttp://www.tunagu.gr.jp/%7Eisihara/if_aue.c.patch
 
 
 2013/11/17 Jonathan Gray j...@jsg.id.au
 
  What is the product number of this device?
  NetBSD usbdevs has 0x092a, Linux has 0x093a and it isn't
  included in your patches.
 
  On Sun, Nov 17, 2013 at 07:21:03AM +0900, is...@oak.dti.ne.jp wrote:
   Synopsis:patches to add support for I/O DATA ETX-US2 usb ethernet
  adapter and fix wrong products name.
   Category:kernel documentation
   Environment:
 System  : OpenBSD 5.4
 Details : OpenBSD 5.4 (GENERIC) #0: Mon Nov  4 03:27:59 JST
  2013
  r...@ishitgw2.home
  :/usr/src/sys/arch/landisk/compile/GENERIC
  
 Architecture: OpenBSD.landisk
 Machine : landisk
   Description:
 5.4 does not support I/O DATA ETX-US2 ethernet adapter.
 and I found a wrong I/O DATA products name.
  
 cf.
  http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=43040
   How-To-Repeat:
  
   Fix:
 apply patches, please.
 http://www.tunagu.gr.jp/~isihara/aue.4.patch
 http://www.tunagu.gr.jp/~isihara/if_aue.c.patch
  
  
   dmesg:
   OpenBSD 5.4 (GENERIC) #0: Mon Nov  4 03:27:59 JST 2013
   r...@ishitgw2.home:/usr/src/sys/arch/landisk/compile/GENERIC
   SH4 SH7751R
   real mem = 67108864 (64MB)
   avail mem = 61845504 (58MB)
   mainbus0 at root
   cpu0 at mainbus0: HITACHI SH4 266.666 MHz PCLOCK 33.333 MHz
   cpu0: 16KB/32B 2-way associative I-cache, 32KB/32B 2-way associative
  D-cache
   shb0 at mainbus0
   scif0 at shb0
   scif0: console
   rsclock0 at shb0: RS5C313 real time clock
   shpcic0 at mainbus0: HITACHI SH7751R
   pci0 at shpcic0
   re0 at pci0 dev 0 function 0 Realtek 8139 rev 0x20: RTL8139C+
  (0x7480), irq 5, address 00:a0:b0:65:00:c6
   rlphy0 at re0 phy 0: RTL internal PHY
   ohci0 at pci0 dev 2 function 0 NEC USB rev 0x43: irq 7, version 1.0
   ohci1 at pci0 dev 2 function 1 NEC USB rev 0x43: irq 8, version 1.0
   ehci0 at pci0 dev 2 function 2 NEC USB rev 0x04: irq 5
   usb0 at ehci0: USB revision 2.0
   uhub0 at usb0 NEC EHCI root hub rev 2.00/1.00 addr 1
   usb1 at ohci0: USB revision 1.0
   uhub1 at usb1 NEC OHCI root hub rev 1.00/1.00 addr 1
   usb2 at ohci1: USB revision 1.0
   uhub2 at usb2 NEC OHCI root hub rev 1.00/1.00 addr 1
   obio0 at mainbus0
   wdc0 at obio0 port 0x1400-0x140f irq 10
   wd0 at wdc0 channel 0 drive 0: FLASH CARD
   wd0: 1-sector PIO, LBA, 3831MB, 7847280 sectors
   wd0(wdc0:0:0): using BIOS timings
   power0 at obio0 irq 11
   umsm0 at uhub1 port 1 configuration 1 interface 0 HUAWEI Technologies
  HUAWEI Mobile Modem rev 1.10/0.00 addr 2
   ucom0 at umsm0
   umsm1 at uhub1 port 1 configuration 1 interface 1 HUAWEI Technologies
  HUAWEI Mobile Modem rev 1.10/0.00 addr 2
   ucom1 at umsm1
   umass0 at uhub1 port 1 configuration 1 interface 2 HUAWEI Technologies
  HUAWEI Mobile Modem rev 1.10/0.00 addr 2
   umass0: using SCSI over Bulk-Only
   scsibus0 at umass0: 2 targets, initiator 0
   cd0 at scsibus0 targ 1 lun 0: HUAWEI, Mass Storage, 2.31 SCSI2 5/cdrom
  removable
   vscsi0 at root
   scsibus1 at vscsi0: 256 targets
   softraid0 at root
   scsibus2 at softraid0: 256 targets
   root on wd0a swap on wd0b dump on wd0b
  
   usbdevs:
   Controller /dev/usb0:
   addr 1: high speed, self powered, config 1, EHCI root hub(0x),
  NEC(0x1033), rev 1.00
port 1 powered
port 2 powered
port 3 powered
port 4 powered
port 5 powered
   Controller /dev/usb1:
   addr 1: full speed, self powered, config 1, OHCI root hub(0x),
  NEC(0x1033), rev 1.00
port 1 addr 2: full speed, power 500 mA, config 1, HUAWEI Mobile
  Modem(0x1003), HUAWEI Technologies(0x12d1), rev 0.00
port 2 powered
port 3 powered
   Controller /dev/usb2:
   addr 1: full speed, self powered, config 1, OHCI root hub(0x),
  NEC(0x1033), rev 1.00
port 1 powered
port 2 powered
 
 
 -- 
 ISIHARA Takanori

Re: Issues on Acer Aspire E1 572G

[Jonathan Gray]

On Sun, Dec 22, 2013 at 04:13:54PM +0100, mark rowland wrote:
 I'm having some issues running OpenBSD on my notebook Acer Aspire E1 572G.
 
 1) During the installation of 5.4 weird things happened with the keyboard:
 typing with the keyboard was slow, sometimes typed characters were repeated,
 the kernel gave several times the error message pckbcintr: no dev for slot 
 1.
 In [1] you can find the output of dmesg from the 5.4 install media.
 I had the same issue during the installation of the latest snapshot.
 After installation the keyboard works fine though. In [2], [3], [4]
 you can find the
 output of dmesg, pcidump and acpidump (base64 encoded .zip) from the
 latest snapshot.
 
 2) As you can read from dmesg, both wired (BCM57786) and wireless lan
 (Atheros 956x) don't get recognized.
 
 Broadcom BCM57786 rev 0x01 at pci1 dev 0 function 0 not configured

That is perhaps manageable with a minor diff to bge?

 
 vendor Atheros, unknown product 0x0036 (class network subclass
 miscellaneous, rev 0x01) at pci2 dev 0 function 0 not configured
 
 3) The discrete gpu (Radeon HD 8670A) isn't recognized. The integrated
 gpu seems to be working, but the
 kernel gives the error messages below.
 
 ATI Radeon HD 8670A rev 0x00 at pci3 dev 0 function 0 not configured

We don't have a new enough version of drm to support modesetting on the
'oland' southern islands parts yet.  

 
 error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register
 before writing to 10
 error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting
 for DP idle patterns
 error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register
 before writing to 64040

this might help your problems with edp on haswell, diff against -current:

diff --git sys/dev/pci/drm/i915/intel_ddi.c sys/dev/pci/drm/i915/intel_ddi.c
index d60adf2..6e367a4 100644
--- sys/dev/pci/drm/i915/intel_ddi.c
+++ sys/dev/pci/drm/i915/intel_ddi.c
@@ -685,7 +685,7 @@ static void intel_ddi_mode_set(struct drm_encoder *encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
 
-   intel_dp-DP = intel_dig_port-port_reversal |
+   intel_dp-DP = intel_dig_port-saved_port_bits |
   DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
switch (intel_dp-lane_count) {
case 1:
@@ -1309,7 +1309,8 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder)
 * enabling the port.
 */
I915_WRITE(DDI_BUF_CTL(port),
-  intel_dig_port-port_reversal | DDI_BUF_CTL_ENABLE);
+  intel_dig_port-saved_port_bits |
+  DDI_BUF_CTL_ENABLE);
} else if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
@@ -1492,16 +1493,6 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
return;
}
 
-   if (port != PORT_A) {
-   hdmi_connector = malloc(sizeof(struct intel_connector),
-   M_DRM, M_WAITOK | M_ZERO);
-   if (!hdmi_connector) {
-   free(dp_connector, M_DRM);
-   free(intel_dig_port, M_DRM);
-   return;
-   }
-   }
-
intel_encoder = intel_dig_port-base;
encoder = intel_encoder-base;
 
@@ -1516,12 +1507,9 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_encoder-get_hw_state = intel_ddi_get_hw_state;
 
intel_dig_port-port = port;
-   intel_dig_port-port_reversal = I915_READ(DDI_BUF_CTL(port)) 
-   DDI_BUF_PORT_REVERSAL;
-   if (hdmi_connector)
-   intel_dig_port-hdmi.sdvox_reg = DDI_BUF_CTL(port);
-   else
-   intel_dig_port-hdmi.sdvox_reg = 0;
+   intel_dig_port-saved_port_bits = I915_READ(DDI_BUF_CTL(port)) 
+ (DDI_BUF_PORT_REVERSAL |
+  DDI_A_4_LANES);
intel_dig_port-dp.output_reg = DDI_BUF_CTL(port);
 
intel_encoder-type = INTEL_OUTPUT_UNKNOWN;
@@ -1529,7 +1517,17 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_encoder-cloneable = false;
intel_encoder-hot_plug = intel_ddi_hot_plug;
 
-   if (hdmi_connector)
-   intel_hdmi_init_connector(intel_dig_port, hdmi_connector);
intel_dp_init_connector(intel_dig_port, dp_connector);
+
+   if (intel_encoder-type != INTEL_OUTPUT_EDP) {
+   hdmi_connector = malloc(sizeof(struct intel_connector),
+   M_DRM, M_WAITOK | M_ZERO);
+
+   if (!hdmi_connector) {
+   return;
+   }
+
+   intel_dig_port-hdmi.hdmi_reg = DDI_BUF_CTL(port);
+   intel_hdmi_init_connector(intel_dig_port, hdmi_connector);
+   }
 }

Re: Issues on Acer Aspire E1 572G

[Jonathan Gray]

On Sun, Dec 29, 2013 at 10:24:27PM +0100, mark rowland wrote:
 I did a fresh install of the latest snapshot, audio is still buggy.

try this:

Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.208
diff -u -p -r1.208 azalia.c
--- azalia.c6 Dec 2013 21:03:03 -   1.208
+++ azalia.c30 Dec 2013 02:27:09 -
@@ -463,6 +463,7 @@ azalia_configure_pci(azalia_t *az)
case PCI_PRODUCT_INTEL_6SERIES_HDA:
case PCI_PRODUCT_INTEL_7SERIES_HDA:
case PCI_PRODUCT_INTEL_8SERIES_HDA:
+   case PCI_PRODUCT_INTEL_8SERIES_LP_HDA:
reg = azalia_pci_read(az-pc, az-tag,
INTEL_PCIE_NOSNOOP_REG);
reg = INTEL_PCIE_NOSNOOP_MASK;

Re: Issues on Acer Aspire E1 572G

[Jonathan Gray]

On Thu, Jan 02, 2014 at 09:01:21AM +0100, Alexandre Ratchov wrote:
 On Sun, Dec 29, 2013 at 10:24:27PM +0100, mark rowland wrote:
  I did a fresh install of the latest snapshot, audio is still buggy.
  I'm attaching a dmesg of the default kernel, a dmesg of a kernel I
  built after adding
  the option AZALIA_DEBUG, the output of mixerctl and the output of audioctl.
  
  After more testing, I could replicate the following steps:
  
  1) I boot OpenBSD on my machine and login
  2) I try to play some .ogg file with ogg123 or some .wav file with
  aucat -i, but I hear a grinding sound and in audioctl play.samples
  remains 0.
  3) I try to play again the file and I hear nothing. Also ogg123/aucat
  seems stuck, thus I kill the process.
  4) I stop sndiod and it is not very responsive:
  
  # /etc/rc.d/sndiod stop
  sndiod(failed)
  # /etc/rc.d/sndiod stop
  sndiod(ok)
  # ps aux | grep sndiod
  _sndio   19767  0.0  0.0   680   984 ??  SEs   8:27PM0:00.05 (sndiod)
  #
  
  After some time (10-15 secs) it finally exits, then I restart it:
  
  # /etc/rc.d/sndiod start
  sndiod(ok)
  #
  
  5) I try to play again the file. If the machine is idle, I hear a
  noise that is different from the grinding sound I heard in step 2.
  If concurrently I'm doing some work (building the kernel or running ls
  -R /) I hear the audio (a bit distorted) of the .ogg/.wav file and
  audioctl
  shows that play.samples is increasing.
  
  With sndiod not running (disabled in /etc/rc.conf.local), I could
  replicate the following steps:
  
  1) I boot OpenBSD on my machine and login.
  2) I try to play some .wav file with aucat -i, I hear a grinding sound
  and play.sample remains 0. After some time the sound stops, aucat
  seems stuck, I kill it.
  3) I try to play again the file. If the machine is idle I hear noise,
  if I am doing some work I hear the audio (a bit distorted) of the .wav
  file and play.samples increases.
  
 
 Thank you for the very detailed report. The problem is probably
 caused by disabled PCIe snooping. Does this diff help?

Yes, and it was already fixed in rev 1.209

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/azalia.c.diff?r2=1.209r1=1.208f=u

The HDMI/DisplayPort audio devices won't work at the moment
and are omitted on purpose.

 
 Index: azalia.c
 ===
 RCS file: /cvs/src/sys/dev/pci/azalia.c,v
 retrieving revision 1.208
 diff -u -p -r1.208 azalia.c
 --- azalia.c  6 Dec 2013 21:03:03 -   1.208
 +++ azalia.c  2 Jan 2014 07:59:13 -
 @@ -463,6 +463,9 @@ azalia_configure_pci(azalia_t *az)
   case PCI_PRODUCT_INTEL_6SERIES_HDA:
   case PCI_PRODUCT_INTEL_7SERIES_HDA:
   case PCI_PRODUCT_INTEL_8SERIES_HDA:
 + case PCI_PRODUCT_INTEL_CORE4G_HDA_1:
 + case PCI_PRODUCT_INTEL_CORE4G_HDA_2:
 + case PCI_PRODUCT_INTEL_CORE4G_HDA_3:
   reg = azalia_pci_read(az-pc, az-tag,
   INTEL_PCIE_NOSNOOP_REG);
   reg = INTEL_PCIE_NOSNOOP_MASK;

Re: Regression: X11 doesn't detect HDMI output since latest snapshot

[Jonathan Gray]

On Mon, Feb 10, 2014 at 01:06:43PM +0100, Norman Golisz wrote:
 I just upgraded to the latest snapshot from Feb, 7. and I'm experiencing
 a regression, where X11 doesn't detect the HDMI output when available.
 
 I've a dual-head configuration, where one VGA and one DVI monitor is
 connected to a docking station of my Thinkpad T400. The VGA works, but
 HDMI stays dark.
 
 Just before I upgraded from a snapshot from Feb, 2. to this snapshot,
 everything worked fine.
 
 Below you'll find the output of xrandr, /var/log/Xorg.0.log, pcidump, dmesg.
 
 Please let me know if I can provide more information or test patches,
 etc.!

Which thinkpad dock is this?

I suspect it may be using an SDVO output in which case the following
diff that combines some fixes we don't yet have from linux 3.8.13.17
might be interesting to try:

aee389b0e2e0d99c1ac779804fc46c2921b405d6
drm/i915/sdvo: Use intel_sdvo-ddc instead of intel_sdvo-i2c for DDC.

and
795de6db7c0397315b083c6dbf57cecd2c6ad098
drm/i915: prefer VBT modes for SVDO-LVDS over EDID

The change that introduced the problem for you is almost certaintly the
update to xf86-video-intel 2.99.909.

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

discusses a similiar problem involving a T400 and mentions trying
a xorg.conf with:

  Section Device
Option ReprobeOutputs true
  EndSection

diff --git sys/dev/pci/drm/i915/intel_sdvo.c sys/dev/pci/drm/i915/intel_sdvo.c
index d92daa8..18a75cb 100644
--- sys/dev/pci/drm/i915/intel_sdvo.c
+++ sys/dev/pci/drm/i915/intel_sdvo.c
@@ -1771,11 +1771,14 @@ static void intel_sdvo_get_lvds_modes(struct 
drm_connector *connector)
 * Assume that the preferred modes are
 * arranged in priority order.
 */
-   intel_ddc_get_modes(connector, intel_sdvo-i2c);
-   if (list_empty(connector-probed_modes) == false)
-   goto end;
+   intel_ddc_get_modes(connector, intel_sdvo-ddc);
 
-   /* Fetch modes from VBT */
+   /*
+* Fetch modes from VBT. For SDVO prefer the VBT mode since some
+* SDVO-LVDS transcoders can't cope with the EDID mode. Since
+* drm_mode_probed_add adds the mode at the head of the list we add it
+* last.
+*/
if (dev_priv-sdvo_lvds_vbt_mode != NULL) {
newmode = drm_mode_duplicate(connector-dev,
 dev_priv-sdvo_lvds_vbt_mode);
@@ -1787,7 +1790,6 @@ static void intel_sdvo_get_lvds_modes(struct 
drm_connector *connector)
}
}
 
-end:
list_for_each_entry(newmode, connector-probed_modes, head) {
if (newmode-type  DRM_MODE_TYPE_PREFERRED) {
intel_sdvo-sdvo_lvds_fixed_mode =

Re: Regression: X11 doesn't detect HDMI output since latest snapshot

[Jonathan Gray]

On Mon, Feb 10, 2014 at 05:48:50PM +0100, Norman Golisz wrote:
 
 [1] xrandr --output LVDS1 --off
 xrandr --output HDMI2 --right-of VGA1 --auto --output VGA1 --primary 
 --auto
 

 
 So, it seems the modes for VGA1 and HDMI2 are swapped with each call of
 xrandr.

Does the behaviour change here if you have a single xrandr command
along the lines of:

xrandr --output LVDS1 --off --output VGA1 --auto --output HDMI2 --right-of VGA1

It might be interesting to try starting the machine with the laptop
screen closed as well.

Re: Intel HD Graphics 4000, only one monitor detected

[Jonathan Gray]

On Tue, May 20, 2014 at 10:05:07AM +0200, mar...@familjenbergkvist.net wrote:
 Synopsis:Intel HD Graphics 4000, only one monitor detected
 Category:
 Environment:
   System  : OpenBSD 5.5
   Details : OpenBSD 5.5-current (GENERIC.MP) #136: Mon May 19 
 09:40:42 MDT 2014

 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
   I have two identical monitors connected to my Intel HD Graphics 4000
   on DisplayPort and HDMI respectively. Usually there was no problem
   detecting them both and split my desktop across both monitors. But
   somewhere between
   OpenBSD 5.5-beta (GENERIC.MP) #284: Mon Feb  3 07:57:32 MST 2014
   and
   OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb  7 11:45:09 MST 2014
   something happened. The monitor on HDMI is mirroring the DisplayPort
   and it is not detected properly by xrand.
 
   After doing xrandr --auto the monitor on HDMI turns black and is not
   detected at all by xrand.

That is around the timeframe of the xf86-video-intel update to
2.99.909 from 2.20.19.  Currently we have 2.99.910.

I don't see any likely commits in the kernel around that timeframe.

2.99.911 has since been released
http://lists.freedesktop.org/archives/xorg/2014-March/056491.html

When I get a chance I'll test it here and send you a patch to see
if that changes anything.

Re: Intel HD Graphics 4000, only one monitor detected

[Jonathan Gray]

On Tue, May 20, 2014 at 08:56:27PM +1000, Jonathan Gray wrote:
 On Tue, May 20, 2014 at 10:05:07AM +0200, mar...@familjenbergkvist.net wrote:
  Synopsis:  Intel HD Graphics 4000, only one monitor detected
  Category:  
  Environment:
  System  : OpenBSD 5.5
  Details : OpenBSD 5.5-current (GENERIC.MP) #136: Mon May 19 
  09:40:42 MDT 2014
   
  t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
  
  Architecture: OpenBSD.amd64
  Machine : amd64
  Description:
  I have two identical monitors connected to my Intel HD Graphics 4000
  on DisplayPort and HDMI respectively. Usually there was no problem
  detecting them both and split my desktop across both monitors. But
  somewhere between
  OpenBSD 5.5-beta (GENERIC.MP) #284: Mon Feb  3 07:57:32 MST 2014
  and
  OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb  7 11:45:09 MST 2014
  something happened. The monitor on HDMI is mirroring the DisplayPort
  and it is not detected properly by xrand.
  
  After doing xrandr --auto the monitor on HDMI turns black and is not
  detected at all by xrand.
 
 That is around the timeframe of the xf86-video-intel update to
 2.99.909 from 2.20.19.  Currently we have 2.99.910.
 
 I don't see any likely commits in the kernel around that timeframe.
 
 2.99.911 has since been released
 http://lists.freedesktop.org/archives/xorg/2014-March/056491.html
 
 When I get a chance I'll test it here and send you a patch to see
 if that changes anything.

Patch can be found here, a bit large to inline:
http://jsg.id.au/openbsd/xf86-video-intel-2.99.911.diff

To apply:
cd /usr/xenocara/driver/xf86-video-intel/
patch -p1  /path/to/xf86-video-intel-2.99.911.diff

Then rebuild xenocara and restart Xorg.

You should see an entry in /var/log/Xorg.0.log to the effect of

[ 17346.336] (II) LoadModule: intel
[ 17346.336] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so
[ 17346.355] (II) Module intel: vendor=X.Org Foundation
[ 17346.355]compiled for 1.15.1, module version = 2.99.911
[ 17346.355]Module class: X.Org Video Driver
[ 17346.355]ABI class: X.Org Video Driver, version 15.0

if everything worked.

Only lightly tested on gen5/ironlake so far.

Re: inteldrm doesn't allow 5.7 Gbps modes on DisplayPort

[Jonathan Gray]

On Mon, Jun 16, 2014 at 02:41:15AM -0600, Steven Wilson wrote:
 Synopsis:inteldrm doesn't allow 5.7 Gbps modes on DisplayPort
 Category:kernel
 Environment:
   System  : OpenBSD 5.5
   Details : OpenBSD 5.5-current (GENERIC) #1: Mon Jun 16 07:29:22 MDT 
 2014

 r...@steven-laptop.home.lan:/usr/src/sys/arch/amd64/compile/GENERIC
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
   On my Lenovo IdeaPad Yoga 2 Pro laptop, inteldrm turns off the
   panel when it loads. This appears to be caused by the mode
   filtering code in the driver rejecting the modes and then
   continuing as though no display is attached to the internal
   eDP port. This in turn appears to be caused by the mode
   filtering code treating 5.4 Gbps DP links as though they were
   2.7 Gbps links, and thus too slow to support the panel's modes.
 How-To-Repeat:
   Install OpenBSD 5.5 or a recent snapshot on a Lenovo IdeaPad
   Yoga 2 Pro and boot it. Wait until the inteldrm driver kicks
   in and the panel turns off. Reboot and disable inteldrm*
   in UKC. Observe that the panel stays active with inteldrm
   disabled.
 Fix:
   The most basic workaround is to disable inteldrm* in UKC, but
   this makes X pretty unusable. An external display should work,
   but I don't have the right cable in the right place to test
   that just now.
 
   The following patch makes the mode filtering code take 5.4 Gbps
   links into account. With it applied, the panel is usable. I am
   a little concerned about the error messages that appear (see
   the second dmesg), but I don't see any obvious malfunction
   associated with them.

Thanks for the report and the analysis.  I'd prefer to use
the linux commits around this if at all possible.

Can you try the patch below that is a combination of two commits:

commit d4eead50eb206b875f54f66cc0f6ec7d54122c28
Author: Imre Deak imre.d...@intel.com
Date:   Tue Jul 9 17:05:26 2013 +0300

drm/i915: fix lane bandwidth capping for DP 1.2 sinks

DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
the driver will treat as an invalid value and use 1.62Gbps instead. Fix
this by capping to 2.7Gbps for sinks reporting a 5.4Gbps max bw.

Also add a warning for reserved values.

v2:
- allow only bw values explicitly listed in the DP standard (Daniel,
  Chris)

Signed-off-by: Imre Deak imre.d...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

commit 9fa5f6522e6eecb5ab20192a264a29ba4f2f4e85
Author: Paulo Zanoni paulo.r.zan...@intel.com
Date:   Thu Nov 29 11:31:29 2012 -0200

drm/i915: kill intel_dp_link_clock()
   
Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but
supports DP_LINK_BW_5_4 and is also used by the other drivers.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch


If that doesn't work we could then look into:

commit 9bbfd20abe5025adbb0ac75160bd2e41158a9e83
Author: Paulo Zanoni paulo.r.zan...@intel.com
Date:   Tue Apr 29 11:00:22 2014 -0300

drm/i915: don't try DP_LINK_BW_5_4 on HSW ULX

Because the docs say ULX doesn't support it on HSW.

Reviewed-by: Dave Airlie airl...@redhat.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com


commit 06ea66b6bb445043dc25a9626254d5c130093199
Author: Todd Previte tprev...@gmail.com
Date:   Mon Jan 20 10:19:39 2014 -0700

drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices

For HSW+ platforms, enable the 5.4Ghz (HBR2) link rate for devices that 
support it. The
sink device must report that is supports Displayport 1.2 and the HBR2 bit 
rate in the
DPCD in order to use HBR2.

Signed-off-by: Todd Previte tprev...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

The errors you see currently appear on all haswell machines.

Index: intel_dp.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_dp.c,v
retrieving revision 1.18
diff -u -p -r1.18 intel_dp.c
--- intel_dp.c  30 Mar 2014 01:10:36 -  1.18
+++ intel_dp.c  17 Jun 2014 04:49:17 -
@@ -139,22 +139,18 @@ intel_dp_max_link_bw(struct intel_dp *in
case DP_LINK_BW_1_62:
case DP_LINK_BW_2_7:
break;
+   case DP_LINK_BW_5_4: /* 1.2 capable displays may advertise higher bw */
+   max_link_bw = DP_LINK_BW_2_7;
+   break;
default:
+   WARN(1, invalid max DP link bw val %x, using 1.62Gbps\n,
+max_link_bw);
max_link_bw = DP_LINK_BW_1_62;
break;
}
return max_link_bw;
 }
 
-static int
-intel_dp_link_clock(uint8_t link_bw)
-{
-   if (link_bw == DP_LINK_BW_2_7)
-  

Re: inteldrm doesn't allow 5.7 Gbps modes on DisplayPort

[Jonathan Gray]

On Tue, Jun 17, 2014 at 12:26:57AM -0600, Steven Wilson wrote:
  Thanks for the report and the analysis.  I'd prefer to use
  the linux commits around this if at all possible.
 
 I tried for that, but got lost in some of the bigger changes on the
 Linux side and ended up thinking that the relevant one couldn't be
 applied without pulling in other stuff.
 
  Can you try the patch below that is a combination of two commits:
 
 It works. Thanks.

Great, committed.  Thanks again for tracking the problem down.

Re: Compiling the kernel fails without com ports enabled on amd64 openbsd 5.5

[Jonathan Gray]

On Sat, Aug 09, 2014 at 03:37:03PM +0200, �yvind Vågen JÊgtnes wrote:
 The FAQ says not to report build errors, however this is not a development
 snapshot but the openbsd 5.5 release source with erratas applied.
 
 If this is fixed in a development snapshot then I am sorry for the
 disturbance.
 
 
 In:
 /usr/src/sys/arch/amd64/amd64/machdep.c: line 1862
 
 The following code block generates the build error (warnings not allowed)
 The variable cdp is set no matter what the config options are.
 
 cdp is only referenced if you build with com ports or BOOTINFO_DEBUG
 
 Without com ports enabled in the kernel config or BOOTINFO_DEBUG the build
 will fail with a warning.

Snapshots and releases all use GENERIC/RAMDISK kernels so this isn't
a problem there, as they all have com.

I guess we either go with a change like the below or just
move all of the BOOTARG_CONSDEV case under NCOM  0.

Index: amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.189
diff -u -p -r1.189 machdep.c
--- amd64/amd64/machdep.c   21 Jul 2014 17:25:47 -  1.189
+++ amd64/amd64/machdep.c   9 Aug 2014 14:04:10 -
@@ -1853,8 +1853,10 @@ getbootinfo(char *bootinfo, int bootinfo
case BOOTARG_CONSDEV:
if (q-ba_size = sizeof(bios_consdev_t) +
offsetof(struct _boot_args32, ba_arg)) {
+#if NCOM  0 || defined(BOOTINFO_DEBUG)
bios_consdev_t *cdp =
(bios_consdev_t*)q-ba_arg;
+#endif
 #if NCOM  0
static const int ports[] =
{ 0x3f8, 0x2f8, 0x3e8, 0x2e8 };
Index: i386/i386/bios.c
===
RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
retrieving revision 1.104
diff -u -p -r1.104 bios.c
--- i386/i386/bios.c29 Mar 2014 18:09:29 -  1.104
+++ i386/i386/bios.c9 Aug 2014 13:54:58 -
@@ -549,8 +549,10 @@ bios_getopt()
case BOOTARG_CONSDEV:
if (q-ba_size = sizeof(bios_consdev_t) +
offsetof(bootarg_t, ba_arg)) {
+#if NCOM  0 || defined(BIOS_DEBUG)
bios_consdev_t *cdp =
(bios_consdev_t*)q-ba_arg;
+#endif
 #if NCOM  0
static const int ports[] =
{ 0x3f8, 0x2f8, 0x3e8, 0x2e8 };

Re: couldn't find agp

[Jonathan Gray]

On Fri, Sep 05, 2014 at 12:06:54PM +0300, KÄ?rlis MiÄ·elsons wrote:
 Hello!
 
 After installing OpenBSD 5.5 or latest snapshot on this Dell system
 it crashes while booting OpenBSD with following message:
 
 cpu0: Enhanced SpeedStep 2926 MHz: speeds: 2933, 2128, 1596 MHz
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 Intel 82Q33 Host rev 0x02
 vga1 at pci0 dev 2 function 0 Intel 82Q33 Video rev 0x02
 intagp at vga1 not configured
 inteldrm0 at vga1
 drm0 at inteldrm0: couldn't find agp
 uvm_fault(0x81dcbd80, 0x20, 0, 1) - e
 kernel: page fault trap, code=0
 Stopped at  drm_fb_helper_restore_fbdev_mode+0x14:  movl
 0x20(%rdi),%edx

It looks like Q33 is missing from the i810 agp code,
you'll need a kernel with the following diff:

Index: sys/dev/pci/agp_i810.c
===
RCS file: /cvs/src/sys/dev/pci/agp_i810.c,v
retrieving revision 1.87
diff -u -p -r1.87 agp_i810.c
--- sys/dev/pci/agp_i810.c  12 Jul 2014 18:48:51 -  1.87
+++ sys/dev/pci/agp_i810.c  5 Sep 2014 11:42:55 -
@@ -174,6 +174,8 @@ agp_i810_get_chiptype(struct pci_attach_
case PCI_PRODUCT_INTEL_82G33_IGD_2:
case PCI_PRODUCT_INTEL_82Q35_IGD_1:
case PCI_PRODUCT_INTEL_82Q35_IGD_2:
+   case PCI_PRODUCT_INTEL_82Q33_IGD_1:
+   case PCI_PRODUCT_INTEL_82Q33_IGD_2:
return (CHIP_G33);
break;
case PCI_PRODUCT_INTEL_82GM45_IGD_1:

Re: man doesn't display malloc.conf(5)

[Jonathan Gray]

malloc(3) and malloc.conf(5) are the same page

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/stdlib/Makefile.inc?rev=HEADcontent-type=text/plain

MLINKS+=malloc.3 free.3 malloc.3 realloc.3 malloc.3 calloc.3
MLINKS+=malloc.3 reallocarray.3 malloc.3 cfree.3 malloc.3 malloc.conf.5

On Tue, Sep 30, 2014 at 01:37:44PM +1000, Brett Mahar wrote:
 Hi bug busters,
 
 I tried to look up the malloc.conf man page and it does not display on my 
 amd64-current system (from Sept 10 snapshot  also upgrading today). The file 
 is there:
 
 $ man -k malloc
 calloc(3) - memory allocation and deallocation
 cfree(3) - memory allocation and deallocation
 free(3) - memory allocation and deallocation
 malloc(3) - memory allocation and deallocation
 realloc(3) - memory allocation and deallocation
 reallocarray(3) - memory allocation and deallocation
 TIFFmemory(3) - _TIFFrealloc,  _TIFFfree,  _TIFFmemset,  _TIFFmemcpy,  
 _TIFFmemcmp,  memory management-related functions for use with TIFF files
 XtAsprintf, XtCalloc, XtFree, XtMalloc, XtNew, XtNewString, XtRealloc(3) - 
 memory management functions
 malloc.conf(5) - memory allocation and deallocation
 free(9) - kernel memory allocator
 malloc(9) - kernel memory allocator
 mallocarray(9) - kernel memory allocator
 uvm_km_kmemalloc(9) - virtual memory system external interface
 
 $ ls /usr/share/man/man5/malloc.conf.5
 /usr/share/man/man5/malloc.conf.5
  
 but when I type `man malloc.conf` at the terminal I get malloc(3). If I type 
 `man 5 malloc.conf` I still get malloc(3). The same thing is happening via 
 the web interface on openbsd.org.
 
 My man.conf is the default and I don't think I've changed any other settings 
 that could affect this.
 
 Cheers,
 Brett.
 
 
 OpenBSD 5.6-current (GENERIC.MP) #372: Wed Sep 10 18:03:54 MDT 2014
 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 3854872576 (3676MB)
 avail mem = 3743522816 (3570MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdce37000 (61 entries)
 bios0: vendor LENOVO version H1ET84WW(1.22) date 11/26/2013
 bios0: LENOVO 20208
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SLIC SSDT HPET APIC MCFG FPDT ASF! SSDT SSDT UEFI 
 UEFI MSDM UEFI DBG2
 acpi0: wakeup devices P0P1(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S4) 
 PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
 PXSX(S4) RP05(S4) [...]
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpihpet0 at acpi0: 14318179 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.46 MHz
 cpu0: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
 cpu0: apic clock running at 99MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.10 MHz
 cpu1: 
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 1, core 0, package 0
 cpu2 at mainbus0: apid 2 (application processor)
 cpu2: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.10 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu2: 256KB 64b/line 8-way L2 cache
 cpu2: smt 0, core 1, package 0
 cpu3 at mainbus0: apid 3 (application processor)
 cpu3: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.10 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu3: 256KB 64b/line 8-way L2 cache
 cpu3: smt 1, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
 acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus -1 (P0P1)
 acpiprt2 at acpi0: bus 1 (RP01)
 acpiprt3 at acpi0: bus 2 (RP02)
 acpiprt4 at acpi0: bus -1 (RP03)
 acpiprt5 at acpi0: bus 3 (RP04)
 

Re: Suspend/Resume broken, doesn't re-attach video.

[Jonathan Gray]

On Thu, Dec 04, 2014 at 08:47:34PM -0600, Sean Cody wrote:
 Synopsis:Suspend/Resume broken, doesn't re-attached video.   
 Category:amd64
 Environment:
   System  : OpenBSD 5.6
   Details : OpenBSD 5.6-current (GENERIC.MP) #648: Thu Dec  4 
 14:23:47 MST 2014

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
   Architecture: OpenBSD.amd64
   Machine : amd64
 Description:
 
   Suspend/Resume doesn't quite work out on this laptop (Acer Aspire One 
 D27-1375).  Hibernate _does_ work (ZZZ and power button to resume).  When 
 using lid or 'zzz' to suspend you can see all the devices detach and it shuts 
 down but when you attempt to start it back up (lid open OR keyboard mash) the 
 screen doesn't activate.  It is partially resuming as I can make the system 
 beep with bad keys and was able to use the reboot command and ZZZ (which 
 worked but the resume didn't attach the display).  Using the function keys to 
 swap interfaces or kill the backlight doesn't seem to do much (though screen 
 does dim so it does something).
 
   Tried i386 and amd64 kernels with a November current snapshot and a 
 snapshot from today with the same behavior.  
 
   Consistently repeatable, just need to 'zzz' and it will sleep, wake up 
 and the screen doesn't engage/attach/activate.
 
 How-To-Repeat:
 
   zzz or close lid on device.  Attempt to wake up with keyboard or 
 lid-open.
 Fix:
   how to correct or work around the problem, if known (multiple lines)

We should probably repost all known powervr devices given there
is otherwise no kernel support.

For now try this:

Index: sys/dev/pci/vga_pci.c
===
RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
retrieving revision 1.81
diff -u -p -r1.81 vga_pci.c
--- sys/dev/pci/vga_pci.c   28 Jul 2014 15:00:27 -  1.81
+++ sys/dev/pci/vga_pci.c   5 Dec 2014 02:55:20 -
@@ -167,6 +167,11 @@ static const struct vga_device_descripti
0x, 0x },
{   0x, 0x, 0x, 0x }, 1
},
+   {   /* All machines with Intel D2000/N2000 (until more evidence) */
+   {   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_D2000_IGD,
+   0x, 0x },
+   {   0x, 0x, 0x, 0x }, 1
+   },
 };
 #endif
 

Re: system hangs after drm:i915_hangcheck_hung error

[Jonathan Gray]

On Mon, Mar 09, 2015 at 08:06:57AM -0400, dan mclaughlin wrote:
 Synopsis:system hangs after drm:i915_hangcheck_hung error
 Category:video driver
 Environment:
   System  : OpenBSD 5.7
   Details : OpenBSD 5.7 (GENERIC) #738: Sun Mar  8 10:59:31 MDT 2015

 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
 
   Architecture: OpenBSD.i386
   Machine : i386
 Description:
 system hangs after moderate use. it mostly seems to occur when a
   program starts (ie qiv feh mplayer). scrolling thru photos hasn't
   triggered it yet, but quitting and restarting a viewer may.
   it doesn't take much to trigger it, i can reproduce fairly quickly.
   just now got around to reporting, but it's been happening for at
   least a couple months now. usually the system freezes before anything
   gets recorded, but by sheer luck i just got this:
 
 Mar  9 07:07:26 node02 /bsd: error: [drm:pid3557:i915_hangcheck_hung] *ERROR* 
 Hangcheck timer elapsed... GPU hung
 Mar  9 07:07:28 node02 /bsd: error: [drm:pid3557:i915_hangcheck_hung] *ERROR* 
 Hangcheck timer elapsed... GPU hung
 Mar  9 07:07:28 node02 /bsd: error: [drm:pid21570:i915_reset] *ERROR* GPU 
 hanging too fast, declaring wedged!
 Mar  9 07:07:28 node02 /bsd: error: [drm:pid21570:i915_reset] *ERROR* Failed 
 to reset chip.
 
 i am pretty certain this is the same issue as reported here:
 
   https://bugs.freedesktop.org/show_bug.cgi?id=54226

That looks unrelated and only for gen6 hardware.

At least part of the problem here is that the gen2 reset itself
is known to cause problems and was at one point removed.

Here is an equivalent of

commit e252d07aff961f8553822cda621490d9aeef8a06
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Tue Oct 8 12:25:41 2013 +0200

drm/i915: rip out gen2 reset code

At least on my i830M here it reliably results in hard system hangs
nowadays. This is much worse than falling back to software rendering,
so I think we should simply rip this out.

After all we don't have any gpu reset for gen3 either, and there are a
lot more of those still around.

Cc: Chris Wilson ch...@chris-wilson.co.uk
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Index: sys/dev/pci/drm/i915/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.75
diff -u -p -r1.75 i915_drv.c
--- sys/dev/pci/drm/i915/i915_drv.c 12 Feb 2015 04:56:03 -  1.75
+++ sys/dev/pci/drm/i915/i915_drv.c 9 Mar 2015 15:08:05 -
@@ -1364,36 +1364,6 @@ inteldrm_timeout(void *arg)
task_add(dev_priv-mm.retire_taskq, dev_priv-mm.retire_task);
 }
 
-static int i8xx_do_reset(struct drm_device *dev)
-{
-   struct drm_i915_private *dev_priv = dev-dev_private;
-
-   if (IS_I85X(dev))
-   return -ENODEV;
-
-   I915_WRITE(D_STATE, I915_READ(D_STATE) | DSTATE_GFX_RESET_I830);
-   POSTING_READ(D_STATE);
-
-   if (IS_I830(dev) || IS_845G(dev)) {
-   I915_WRITE(DEBUG_RESET_I830,
-  DEBUG_RESET_DISPLAY |
-  DEBUG_RESET_RENDER |
-  DEBUG_RESET_FULL);
-   POSTING_READ(DEBUG_RESET_I830);
-   drm_msleep(1, 8res1);
-
-   I915_WRITE(DEBUG_RESET_I830, 0);
-   POSTING_READ(DEBUG_RESET_I830);
-   }
-
-   drm_msleep(1, 8res2);
-
-   I915_WRITE(D_STATE, I915_READ(D_STATE)  ~DSTATE_GFX_RESET_I830);
-   POSTING_READ(D_STATE);
-
-   return 0;
-}
-
 static int i965_reset_complete(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1540,9 +1510,6 @@ int intel_gpu_reset(struct drm_device *d
break;
case 4:
ret = i965_do_reset(dev);
-   break;
-   case 2:
-   ret = i8xx_do_reset(dev);
break;
}
 

Re: radeon drm regression (was Re: D-Link DGE-528T / re(4) regression)

[Jonathan Gray]

On Wed, Apr 08, 2015 at 07:14:57PM +0200, Daniel Jakots wrote:
 On Wed, 8 Apr 2015 20:03:00 +1000, j...@insec.sh wrote:
 
  but could you try it with the following patch applied?
 
 Sure, I updated my cvs src tree, patched it and made a new kernel.
 
 I booted on the new kernel then, but when usually the screen blink and
 then says:
 radeondrm0: 1680x1050
 wsdisplay0 at radeondrm0 mux 1: blah blah blah
 
 the screen simply goes off as if it doesn't receive any input anymore.

Is that with rev 1.4 of sys/dev/pci/drm/drm_linux.c ?

Re: Asus X102BA does not resume from suspend

[Jonathan Gray]

On Thu, Jun 18, 2015 at 02:51:53AM +0200, Tilo Stritzky wrote:
 On 17/06/15 21:02  Jonathan Gray wrote:
  On Wed, Jun 17, 2015 at 12:46:33PM +0200, Tilo Stritzky wrote:
   Synopsis:Asus X102BA does not resume from suspend
   Category:PR category (one line)
   Environment:
 System  : OpenBSD 5.7
 Details : OpenBSD 5.7-current (GENERIC.MP) #945: Mon Jun 15 
   01:02:25 MDT 2015
  
   dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
   
 Architecture: OpenBSD.i386
 Machine : i386
   Description:
 On triggering suspend (zzz, magic Fn-key or lidclose) machine
 shows all signs of suspending (console shows USB devices
 disconnecting, backlight goes off, fan stops,
 USB ports are unpowered, power blinkenlight indicates
 ``suspended'' mode)
 On wakeup fan spins up and USB devices are powered,
 blinkenlight goes back to steady (``on'').
 Screen stays dark (backlight off), 
 machine seems completely locked up.
   
 This an older regression, suspend works fine with 5.4 release.
  
  The radeondrm code does not support kabini radeons.  Were you running
  the same system with the same processor with 5.4?
  
 Below is a dmesg from 5.4 release with a full suspend/resume cycle,
 triggered from within X.
 The aml parse error would happen once in a while but not often.

We stopped reposting ati/amd video when radeon kms went in.
You could try this to enable it for your device.

Index: sys/dev/pci/vga_pci.c
===
RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
retrieving revision 1.84
diff -u -p -r1.84 vga_pci.c
--- sys/dev/pci/vga_pci.c   29 Mar 2015 18:45:22 -  1.84
+++ sys/dev/pci/vga_pci.c   18 Jun 2015 02:45:17 -
@@ -185,6 +185,11 @@ static const struct vga_device_descripti
0x, 0x },
{   0x, 0xfff0, 0x, 0x }, 1
},
+   {
+   {   PCI_VENDOR_ATI, 0x9839,
+   0x, 0x },
+   {   0x, 0xfff0, 0x, 0x }, 1
+   },
 };
 #endif
 

Re: Asus X102BA does not resume from suspend

[Jonathan Gray]

On Wed, Jun 17, 2015 at 12:46:33PM +0200, Tilo Stritzky wrote:
 Synopsis:Asus X102BA does not resume from suspend
 Category:PR category (one line)
 Environment:
   System  : OpenBSD 5.7
   Details : OpenBSD 5.7-current (GENERIC.MP) #945: Mon Jun 15 
 01:02:25 MDT 2015

 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
 
   Architecture: OpenBSD.i386
   Machine : i386
 Description:
   On triggering suspend (zzz, magic Fn-key or lidclose) machine
   shows all signs of suspending (console shows USB devices
   disconnecting, backlight goes off, fan stops,
   USB ports are unpowered, power blinkenlight indicates
   ``suspended'' mode)
   On wakeup fan spins up and USB devices are powered,
   blinkenlight goes back to steady (``on'').
   Screen stays dark (backlight off), 
   machine seems completely locked up.
 
   This an older regression, suspend works fine with 5.4 release.

The radeondrm code does not support kabini radeons.  Were you running
the same system with the same processor with 5.4?

Re: no working network on latest nuc

[Jonathan Gray]

On Sat, Aug 22, 2015 at 07:21:28PM -0400, Ted Unangst wrote:
 The latest intel nuc (braswell model) has wired and wireless network, but
 neither appear supported.
 
 The ethernet shows up as:
 re0 at pci3 dev 0 function 0 Realtek 8168 rev 0x15: unknown ASIC (0x5400),
  msi, address ff:ff:ff:ff:ff:ff
 
 It seems it can send packets, but not receive. dhclient fails to receive an
 address, but when configured manually my router complains:
 arp info overwritten for 10.3.3.23 by fe:e1:ba:d0:33:56 on cnmac1
 
 So it is sending something (with a fake mac). Almost there...

Try this:

Index: re.c
===
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.179
diff -u -p -r1.179 re.c
--- re.c24 Jun 2015 09:40:54 -  1.179
+++ re.c23 Aug 2015 03:29:10 -
@@ -245,6 +245,7 @@ static const struct re_revision {
{ RL_HWREV_8168F,   RTL8168F/8111F },
{ RL_HWREV_8168G,   RTL8168G/8111G },
{ RL_HWREV_8168GU,  RTL8168GU/8111GU },
+   { RL_HWREV_8168H,   RTL8168H/8111H },
{ RL_HWREV_8105E,   RTL8105E },
{ RL_HWREV_8105E_SPIN1, RTL8105E },
{ RL_HWREV_8168D,   RTL8168D/8111D },
@@ -771,6 +772,7 @@ re_attach(struct rl_softc *sc, const cha
break;
case RL_HWREV_8168EP:
case RL_HWREV_8168G:
+   case RL_HWREV_8168H:
case RL_HWREV_8411B:
sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP |
Index: rtl81x9reg.h
===
RCS file: /cvs/src/sys/dev/ic/rtl81x9reg.h,v
retrieving revision 1.94
diff -u -p -r1.94 rtl81x9reg.h
--- rtl81x9reg.h9 Apr 2015 02:08:55 -   1.94
+++ rtl81x9reg.h23 Aug 2015 03:24:19 -
@@ -202,6 +202,7 @@
 #define RL_HWREV_8168G 0x4c00
 #define RL_HWREV_8168EP0x5000
 #define RL_HWREV_8168GU0x5080
+#define RL_HWREV_8168H 0x5400
 #define RL_HWREV_8411B 0x5c80  
 #define RL_HWREV_8139  0x6000
 #define RL_HWREV_8139A 0x7000

Re: panic: no appropriate pool

[Jonathan Gray]

On Sat, Aug 01, 2015 at 08:46:00PM +0200, Mike Belopuhov wrote:
 On 1 August 2015 at 19:20, RD Thrush openbsd-t...@thrush.com wrote:
 
  The patch ran without panic for 20+ hours.
 
 
 Thanks for testing!
 
  I wondered about the removal of the panic() statement so I tried
  another kernel that added the memset() but kept the panic() statement, as 
  follows:
 
 [snip]
 
  That kernel panic'd as before with no appropriate pool.
 
 Well of course.  Not all rules are rdr/nat/route-to.
 
  Was the Jul 20 cvs commit (panic addition) incorrect?
 
 It has served it's purpose well: it has found this bug.
 But panic'ing here in general is of course incorrect.
 
  If not, it appears the memset() addition didn't fix the panic.
 
 
 It did, clearly.  You can run your setup again (-:
 
  I was able to take a crash dump with the above change and have
  attached a gdb transcript.  The stack is apparently damaged in the
  pf_postprocess_addr() function; however, I'm over my head at this
  point.  How may I help further troubleshoot?
 
 You're slightly overanalyzing here: panic has caught the unhandled
 case, but it's not needed per se.
 

The code directly after the panic assumes rpool is set.
Something is clearly wrong in the pf code if this triggers.

Without a pf.conf it is hard to guess as to why this triggers...

Re: panic: no appropriate pool

[Jonathan Gray]

On Mon, Aug 03, 2015 at 12:55:46AM +0200, Mike Belopuhov wrote:
 On 2 August 2015 at 22:00, RD Thrush openbsd-t...@thrush.com wrote:
  On 08/02/15 13:37, Mike Belopuhov wrote:
  most likely it's triggered by the reply-to statement.  you may try the 
  attached
  diff to see which rule the state belongs to. since you're using
  anchors, figuring
  out rule numbers will not be easy but you may try to see if one of those 
  give
  you something reasonable:
 
   pfctl -a '*' -vvsr
   pfctl -a 'ext1' -vvsr
   pfctl -a 'ext2' -vvsr
 
  Thanks, panic: no appropriate pool for 23/23 is the new result.  Since 
  the main pf has less than 23 rules and only one of the anchors has an 
  active interface, I assume it's rule 23 from the ext1 anchor.  I've 
  attached the pfctl results from above as well as a short gdb session w/ the 
  crash dump.
 
  panic: no appropriate pool for 23/23
 
 thanks for testing.  rule 23 is a reply-to rule.  jonathan, if
 you don't object, i think we should commit the dif as is at least
 for the release.
 

Well if we want to do that the diff should really be a return where
the panic is.

Index: pf_lb.c
===
RCS file: /cvs/src/sys/net/pf_lb.c,v
retrieving revision 1.48
diff -u -p -r1.48 pf_lb.c
--- pf_lb.c 20 Jul 2015 18:42:08 -  1.48
+++ pf_lb.c 3 Aug 2015 01:13:02 -
@@ -873,7 +873,7 @@ pf_postprocess_addr(struct pf_state *cur
else if (nr-route.addr.type != PF_ADDR_NONE)
rpool = nr-route;
else
-   panic(no appropriate pool);
+   return (0);
 
if (((rpool.opts  PF_POOL_TYPEMASK) != PF_POOL_LEASTSTATES))
return (0);

Re: z800 hp workstation OpenBSD 5.7 install attempt, hitting a wall

[Jonathan Gray]

On Sun, Aug 09, 2015 at 08:44:47PM -0700, Danny Nguyen wrote:
 Hi,
 
 I purchased a hewlett packard z800 workstation running windows 7 with the
 intention of running linux ubuntu as a sever but I've found OpenBSD to
 sound and contain more robust features (versus linux, FreeBSD, and NetBSD)
 when dealing with security.
 
 I have Michael W. Lucas's book, Absolute OpenBSD to help with OpenBSD
 install but I've hit a wall on the install process. I can to tear open both
 computer boxes and look for product numbers to identify the specific
 physical hardware to pinpoint the exact bottleneck.
 
 Things I have tried multiple times:
 
 *1.*The method being used to install OpenBSD 5.7 are two physical compact
 discs (one is the cd57.iso image and the other is the install57.iso image).
 Both were used.
 
 *2.* Both cds generate the same messages during the install process (on the
 z800 workstation) which
 is that the number of hard drives found is zero when there are two hard
 drives (not solid state drives) in 2 of the four bays. One is a seagate HD
 500G SATA3 6GSQ, it also says Firmware: HP73 on the drive. The other is a
 Hitachi with a capacity of 2TB with the labels LBA: 3,907,029,168
 sectors, RPM: 7200RPM, and SATA 6.0 Gb/s.

If the disks are plugged into SATA ports you may need to change
the mode in the bios from RAID to AHCI.  If they're plugged into SAS
ports it's possible you have the unsupported Intel SAS controller in
which case move them to SATA ports.

Re: z800 hp workstation OpenBSD 5.7 install attempt, hitting a wall

[Jonathan Gray]

It is worth trying a snapshot instead of 5.7.  You should be able to
mount a usb disk from an installer shell which would let you save the
output of dmesg or just do an install to a usb disk.

I would guess the IDE SATA Emulation would mean pciide(4).

On Mon, Aug 10, 2015 at 12:53:14AM -0700, Danny Nguyen wrote:
 I took some pictures of the hardware to assist in seeing what is going
 on more clearly.
 
 Based on the writing on the hardware, the connections from the hard drive
 connectors (from input to motherboard) are SATA.
 
 The pictures with the hard drives are to show all the different connectors.
 The screw driver was used as a point of reference.
 
 I inserted the following hard drives when booting into the bios: seagate
 500g and hitachi 2tb. I then proceeded to chose the optical drive to boot
 into the openbsd installation process using the install57.iso image. Same
 error which did not detect the hard drives and no link on the ethernet as
 mentioned before.
 
 I attempted to change the raid to ahci like suggested and something weird
 that said emulated showed up in the storage options. The last two images
 show what I mean.

Re: X with Broadwell GPU still not working

[Jonathan Gray]

On Sun, Nov 01, 2015 at 10:51:45AM +0100, Thomas Weinbrenner wrote:
> Thank you Jonathan.
> 
> I just upgraded to #1556.
> 
> X starts as fast as it should be. Acceleration doesn't work (fonts are
> not displayed, firefox doesn't display anything), but if I disable
> acceleration via xorg.conf everything is fine.
> I guess I have to wait for the next drm update to use hardware acceleration.
> 
> One of the dmesg warnings disappeared, the other is still there.

The warning is due to a mistake in the Intel code.  I will commit
a fix for that shortly.

With the following xenocara patch you should be able to use acceleration:

Index: driver/xf86-video-intel/src/sna/gen8_render.c
===
RCS file: /cvs/xenocara/driver/xf86-video-intel/src/sna/gen8_render.c,v
retrieving revision 1.3
diff -u -p -r1.3 gen8_render.c
--- driver/xf86-video-intel/src/sna/gen8_render.c   12 Apr 2015 19:42:06 
-  1.3
+++ driver/xf86-video-intel/src/sna/gen8_render.c   9 Oct 2015 02:01:54 
-
@@ -462,21 +462,21 @@ gen8_emit_urb(struct sna *sna)
 {
/* num of VS entries must be divisible by 8 if size < 9 */
OUT_BATCH(GEN8_3DSTATE_URB_VS | (2 - 2));
-   OUT_BATCH(1024 << URB_ENTRY_NUMBER_SHIFT |
+   OUT_BATCH(960 << URB_ENTRY_NUMBER_SHIFT |
  (2 - 1) << URB_ENTRY_SIZE_SHIFT |
- 0 << URB_STARTING_ADDRESS_SHIFT);
+ 4 << URB_STARTING_ADDRESS_SHIFT);
 
OUT_BATCH(GEN8_3DSTATE_URB_HS | (2 - 2));
OUT_BATCH(0 << URB_ENTRY_SIZE_SHIFT |
- 0 << URB_STARTING_ADDRESS_SHIFT);
+ 4 << URB_STARTING_ADDRESS_SHIFT);
 
OUT_BATCH(GEN8_3DSTATE_URB_DS | (2 - 2));
OUT_BATCH(0 << URB_ENTRY_SIZE_SHIFT |
- 0 << URB_STARTING_ADDRESS_SHIFT);
+ 4 << URB_STARTING_ADDRESS_SHIFT);
 
OUT_BATCH(GEN8_3DSTATE_URB_GS | (2 - 2));
OUT_BATCH(0 << URB_ENTRY_SIZE_SHIFT |
- 0 << URB_STARTING_ADDRESS_SHIFT);
+ 4 << URB_STARTING_ADDRESS_SHIFT);
 }
 
 static void

Re: X with Broadwell GPU still not working

[Jonathan Gray]

On Thu, Oct 08, 2015 at 08:50:29PM +0200, m...@tweinbrenner.net wrote:
> >Synopsis:X with Broadwell GPU still not working
> >Category:kernel
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8-current (GENERIC.MP) #1440: Thu Oct  8 
> 07:52:55 MDT 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When I start X (either using startx or xdm) it starts really slow and 
> the graphics are not really working. I don't know how to describe it exactly. 
> The patterns of my background are scrambled, windows arent recognizable. The 
> mouse moves slow  - if at all. The same is true for keystrokes.
> Curiously the very first snapshot with Broadwell support (I think it was 
> #1378) displayed the same behaviour, but startet to work after some time (or 
> after I managed to log in using xdm), but I wasn't able to reproduce that on 
> a later snapshot.
> when I tried to use xrandr to setup my to monitors the computer rebootet.
> 
> Some errors I have seen with the current snapshot:
> 
> error: [drm:pid28330:intel_pipe_set_base] *ERROR* pin & fence failed
> error: [drm:pid16808:ring_stuck] *ERROR* Kicking stuck wait on blitter ring
> 
> >How-To-Repeat:
>  Boot my computer and trying to start X using the Intel GPU.
> >Fix:
>  Use another graphic card. :(
> 
> 
> WARNING !((to_i915(dev)->info)->is_haswell) failed at 
> ../../../../dev/pci/drm/i915/i915_drv.c:557
> WARNING to_i915(dev)->info)->is_haswell) && ((dev)->pdev->device & 
> 0xFF00) == 0x0A00) || (((to_i915(dev)->info)->gen == 8) && 
> (((dev)->pdev->device & 0xf) == 0x2 || ((dev)->pdev->device & 0xf) == 0x6 || 
> ((dev)->pdev->device & 0xf) == 0xe))) failed at 
> ../../../../dev/pci/drm/i915/i915_drv.c:558

These warnings are harmless according to
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a35cc9d0c0118fb18f7c5dd7a44adb454868a679

So far all the broadwell testers have had mobile GT2 broadwell not desktops
with GT3e with the extra cache.

I would be interested to hear what happens when the ellc is enabled:

Index: sys/dev/pci/drm/i915/intel_uncore.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_uncore.c,v
retrieving revision 1.2
diff -u -p -r1.2 intel_uncore.c
--- sys/dev/pci/drm/i915/intel_uncore.c 25 Sep 2015 16:15:19 -  1.2
+++ sys/dev/pci/drm/i915/intel_uncore.c 9 Oct 2015 02:42:26 -
@@ -324,7 +324,7 @@ void intel_uncore_early_sanitize(struct 
if (HAS_FPGA_DBG_UNCLAIMED(dev))
__raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
 
-   if (IS_HASWELL(dev) &&
+   if ((IS_HASWELL(dev) || IS_BROADWELL(dev)) &&
(__raw_i915_read32(dev_priv, HSW_EDRAM_PRESENT) == 1)) {
/* The docs do not explain exactly how the calculation can be
 * made. It is somewhat guessable, but for now, it's always

Re: httpd crashes when fetching a hidden file located on a CD

[Jonathan Gray]

On Tue, Dec 08, 2015 at 12:31:09AM +, Stuart Henderson wrote:
> On 2015/12/07 15:44, Theo de Raadt wrote:
> > This bug report totally sucks.
> > 
> > Have you ever heard of ktrace, and if you have, why did you not try
> > to reproduce it?
> > 
> > You want us to reproduce it?  Why?
> > 
> > > Hi,
> > > I ran across an issue with httpd(8) on 5.8-RELEASE & -CURRENT (2/12/2015
> > > snapshot) where fetching a .hidden file located on a CD through httpd
> > > results in httpd crashing (no core file or error message logged).
> > > 
> > > To reproduce, mount CD in a location which is served by httpd. eg CentOS
> > > minimal install iso[1] has a hidden file in the root called .treeinfo
> > > 
> > > Try to fetch http://myweb/.treeinfo
> > > 
> > > Of course this is not a common scenario found in production, I happened
> > > to run into it whist taking a shortcut to save time & disk space by
> > > mounting the CentOS iso on a virtualbox guest which was running OpenBSD.
> > > 
> > > 
> > > Sevan
> > > [1]
> > > http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1503-01.iso
> > > 
> > 
> 
> It's not that bad a report, it has everything necessary to reproduce,
> tested on release and -current so it's obviously not pledge related.
> 
> There's one thing to add though, it looks like it happens for any file on
> cd9660, not just dotfiles.

It is worth pointing out that httpd has had trouble serving files off
specific filesystems in the past due to kqueue issues.

cd9660_vops does not currently set .vop_kqfilter, does anything change
if you set EVENT_NOKQUEUE before running httpd?

Re: pkg_sign incorrectly assumes -i by default

[Jonathan Gray]

On Mon, Jun 06, 2016 at 09:12:04AM +0200, Marc Espie wrote:
> 
> This should fix things.

Thanks, things work as expected here with this diff.

> 
> 
> Index: AddCreateDelete.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/AddCreateDelete.pm,v
> retrieving revision 1.34
> diff -u -p -r1.34 AddCreateDelete.pm
> --- AddCreateDelete.pm6 Apr 2015 11:07:24 -   1.34
> +++ AddCreateDelete.pm6 Jun 2016 07:09:49 -
> @@ -59,25 +59,11 @@ sub handle_options
>  {
>   my ($state, $opt_string, @usage) = @_;
>  
> - my $i;
> - $state->{opt}{i} //= sub {
> - $i++;
> - };
> - $state->SUPER::handle_options($opt_string.'IiL:mnx', @usage);
> + $state->SUPER::handle_options($opt_string.'L:mnx', @usage);
>  
>   $state->progress->setup($state->opt('x'), $state->opt('m'), $state);
>   $state->{not} = $state->opt('n');
> - if ($state->opt('I')) {
> - $i = 0;
> - } elsif (!defined $i) {
> - $i = -t STDIN;
> - }
> - if ($i) {
> - require OpenBSD::Interactive;
> - $state->{interactive} = OpenBSD::Interactive->new($state, $i);
> - } else {
> - $state->{interactive} = OpenBSD::InteractiveStub->new($state);
> - }
> + $state->{interactive} //= OpenBSD::InteractiveStub->new($state);
>  }
>  
>  
> Index: AddDelete.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/AddDelete.pm,v
> retrieving revision 1.72
> diff -u -p -r1.72 AddDelete.pm
> --- AddDelete.pm  25 May 2015 07:20:31 -  1.72
> +++ AddDelete.pm  6 Jun 2016 07:09:49 -
> @@ -167,11 +167,24 @@ sub handle_options
>   $state->{subst}->add($o, 1);
>   }
>   };
> + my $i;
> + $state->{opt}{i} //= sub {
> + $i++;
> + };
>   $state->{no_exports} = 1;
>   $state->SUPER::handle_options($opt_string.'aciInqsB:F:', @usage);
>  
>   if ($state->opt('s')) {
>   $state->{not} = 1;
> + }
> + if ($state->opt('I')) {
> + $i = 0;
> + } elsif (!defined $i) {
> + $i = -t STDIN;
> + }
> + if ($i) {
> + require OpenBSD::Interactive;
> + $state->{interactive} = OpenBSD::Interactive->new($state, $i);
>   }
>   # XXX RequiredBy
>   $main::not = $state->{not};
> 

pkg_sign incorrectly assumes -i by default

[Jonathan Gray]

The behaviour of pkg_sign acts as if -i is always specified and won't
sign/resign a package if it exists in the output directory.

In OpenBSD/PkgSign.pm sign_existing_package $state->opt('i')
path is always taken.  Does this come from some shared code
setting a default interactive level for pkg_add's different -i option?

$ pkg_info -v ./hexedit-1.2.12.tgz
...
@signer openbsd-60-pkg
@digital-signature 
signify:2016-06-05T21:12:25Z:RWQHIajRlT2mX2Co5PKjLtNprvAe8NjNXbxUabL3ySmJfLzFxod5BlCn+RvTB2coDd41rJdPJ+Ob/AUQMeAmEFETgJIVpn5YhAo=

$ signify -Gn -p test-pkg.pub -s test-pkg.sec
$ doas cp test-pkg.pub /etc/signify/

$ pkg_sign -v -D resign -s signify -s test-pkg.sec ./hexedit-1.2.12.tgz
Signed ./hexedit-1.2.12.tgz: ok
$ pkg_info -v ./hexedit-1.2.12.tgz
..
@signer openbsd-60-pkg
@digital-signature 
signify:2016-06-05T21:12:25Z:RWQHIajRlT2mX2Co5PKjLtNprvAe8NjNXbxUabL3ySmJfLzFxod5BlCn+RvTB2coDd41rJdPJ+Ob/AUQMeAmEFETgJIVpn5YhAo=

$ mkdir out
$ pkg_sign -v -o out -D resign -s signify -s test-pkg.sec ./hexedit-1.2.12.tgz
Resigning hexedit-1.2.12
Signed ./hexedit-1.2.12.tgz: ok
$ pkg_info -v ./out/hexedit-1.2.12.tgz
..
@signer test-pkg
@digital-signature 
signify:2016-06-06T05:47:46Z:RWRwvf7+8LjZmCFrf65S/RhowUT4+QvgVnEHg4ztH6ZIEVWDVWjlGyd/SWvb1apmxcoaO+lNFm+83OhvvuGsTyEGC95pcA2PTgc=

$ zfgrep signer ./dtb-4.6.tgz
$
$ pkg_sign -v -s signify -s test-pkg.sec ./dtb-4.6.tgz
$ zfgrep signer ./dtb-4.6.tgz
$

Re: Screen brightness is reset when changing from X to console

[Jonathan Gray]

On Mon, May 30, 2016 at 02:41:59PM +0200, Walter Alejandro Iglesias wrote:
> Stefan Sperling  wrote:
> 
> > On Sun, May 29, 2016 at 09:19:58PM +0200, Mark Kettenis wrote:
> > > And I can't reproduce this on my x220.  So either this issue depends on
> > > specific BIOS revisions, or the description of how to reproduce the 
> > > problem
> > > is incomplete.
> >
> > I've been seeing it on my x201 for a while.
> >
> > Isn't this the same issue as was discussed in the "ACPI thinkpad brightness
> > regression" thread back in Feburary? It seems this was never resolved.
> > http://marc.info/?t=14550124442=1=2
> 
> I've found out that setting UXA acceleration in xorg.conf solves not
> only this issue but the one about cwm menu fonts corruption I reported
> on May 21th.  So, am I wrong assuming it's not an acpi issue but a intel
> driver one?  (Sorry if I can't be more useful, my knowledge is poor).
> 
> But, using UXA it appears a new issue.  When I exit X, I end with a
> black empty screen and I must change manually to tty1.  X shows the
> error below:
> 
> ---
> X.Org X Server 1.18.3
> Release Date: 2016-04-04
> X Protocol Version 11, Revision 0
> Build Operating System: OpenBSD 6.0 amd64
> Current Operating System: OpenBSD mamuca.local 6.0 GENERIC.MP#2142 amd64
> Build Date: 30 May 2016  12:02:37AM
> 
> Current version of pixman: 0.32.8
>   Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 30 14:22:58 2016
> (==) Using config file: "/etc/X11/xorg.conf"
> (II) AIGLX: Suspending AIGLX clients for VT switch
> xinit: connection to X server lost
> 
> waiting for X server to shut down 
> X:/usr/X11R6/lib/modules/drivers/intel_drv.so: undefined symbol 
> 'intel_sync_close'
> lazy binding failed!
> (EE) Segmentation fault at address 0x0
> (EE)
> Fatal server error:
> (EE) Caught signal 11 (Segmentation fault). Server aborting
> (EE)
> (EE)
> Please consult the The X.Org Foundation support
>at http://wiki.x.org
>  for help.
> (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
> information.
> (EE)
> (EE) Bus error at address 0x1b427e38efd4
> (EE)
> FatalError re-entered, aborting
> (EE) Caught signal 10 (Bus error). Server aborting
> (EE)
> ---
> 
> (I've upgraded today to latest snapshot)

Here's a diff that might help, compile tested only:

Index: src/uxa/intel_driver.c
===
RCS file: /cvs/xenocara/driver/xf86-video-intel/src/uxa/intel_driver.c,v
retrieving revision 1.2
diff -u -p -r1.2 intel_driver.c
--- src/uxa/intel_driver.c  12 Apr 2015 19:42:07 -  1.2
+++ src/uxa/intel_driver.c  30 May 2016 13:08:02 -
@@ -1188,7 +1188,9 @@ static Bool I830CloseScreen(CLOSE_SCREEN
intel->dri3 = DRI_NONE;
}
 
+#if HAVE_DRI3
intel_sync_close(screen);
+#endif
 
xf86GARTCloseScreen(scrn->scrnIndex);
 

Re: Screen brightness is reset when changing from X to console

[Jonathan Gray]

On Mon, May 30, 2016 at 05:02:07PM +0200, Walter Alejandro Iglesias wrote:
> Jonathan Gray <j...@jsg.id.au> wrote:
> 
> > On Mon, May 30, 2016 at 02:41:59PM +0200, Walter Alejandro Iglesias wrote:
> > > Stefan Sperling <s...@stsp.name> wrote:
> > >
> > > > On Sun, May 29, 2016 at 09:19:58PM +0200, Mark Kettenis wrote:
> > > > > And I can't reproduce this on my x220.  So either this issue depends 
> > > > > on
> > > > > specific BIOS revisions, or the description of how to reproduce the 
> > > > > problem
> > > > > is incomplete.
> > > >
> > > > I've been seeing it on my x201 for a while.
> > > >
> > > > Isn't this the same issue as was discussed in the "ACPI thinkpad 
> > > > brightness
> > > > regression" thread back in Feburary? It seems this was never resolved.
> > > > http://marc.info/?t=14550124442=1=2
> > >
> > > I've found out that setting UXA acceleration in xorg.conf solves not
> > > only this issue but the one about cwm menu fonts corruption I reported
> > > on May 21th.  So, am I wrong assuming it's not an acpi issue but a intel
> > > driver one?  (Sorry if I can't be more useful, my knowledge is poor).
> > >
> > > But, using UXA it appears a new issue.  When I exit X, I end with a
> > > black empty screen and I must change manually to tty1.  X shows the
> > > error below:
> > >
> > > ---
> > > X.Org X Server 1.18.3
> > > Release Date: 2016-04-04
> > > X Protocol Version 11, Revision 0
> > > Build Operating System: OpenBSD 6.0 amd64
> > > Current Operating System: OpenBSD mamuca.local 6.0 GENERIC.MP#2142 amd64
> > > Build Date: 30 May 2016  12:02:37AM
> > >
> > > Current version of pixman: 0.32.8
> > >   Before reporting problems, check http://wiki.x.org
> > >   to make sure that you have the latest version.
> > > Markers: (--) probed, (**) from config file, (==) default setting,
> > >   (++) from command line, (!!) notice, (II) informational,
> > >   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> > > (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 30 14:22:58 2016
> > > (==) Using config file: "/etc/X11/xorg.conf"
> > > (II) AIGLX: Suspending AIGLX clients for VT switch
> > > xinit: connection to X server lost
> > >
> > > waiting for X server to shut down 
> > > X:/usr/X11R6/lib/modules/drivers/intel_drv.so: undefined symbol 
> > > 'intel_sync_close'
> > > lazy binding failed!
> > > (EE) Segmentation fault at address 0x0
> > > (EE)
> > > Fatal server error:
> > > (EE) Caught signal 11 (Segmentation fault). Server aborting
> > > (EE)
> > > (EE)
> > > Please consult the The X.Org Foundation support
> > >at http://wiki.x.org
> > >  for help.
> > > (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
> > > additional information.
> > > (EE)
> > > (EE) Bus error at address 0x1b427e38efd4
> > > (EE)
> > > FatalError re-entered, aborting
> > > (EE) Caught signal 10 (Bus error). Server aborting
> > > (EE)
> > > ---
> > >
> > > (I've upgraded today to latest snapshot)
> >
> > Here's a diff that might help, compile tested only:
> >
> > Index: src/uxa/intel_driver.c
> > ===
> > RCS file: /cvs/xenocara/driver/xf86-video-intel/src/uxa/intel_driver.c,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 intel_driver.c
> > --- src/uxa/intel_driver.c  12 Apr 2015 19:42:07 -  1.2
> > +++ src/uxa/intel_driver.c  30 May 2016 13:08:02 -
> > @@ -1188,7 +1188,9 @@ static Bool I830CloseScreen(CLOSE_SCREEN
> > intel->dri3 = DRI_NONE;
> > }
> >
> > +#if HAVE_DRI3
> > intel_sync_close(screen);
> > +#endif
> >
> > xf86GARTCloseScreen(scrn->scrnIndex);
> >
> 
> YES!
> 
> It took me a while because it's my first time compiling cvs xenocara.  I
> can confirm that at least at my end Jonathan's diff solves the intel UXA
> issue I mentioned in my last message.
> 
> Using UXA, changing to ttys from X is flawless, it doesn't affect the
> screen brightness at all.
> 
> Now, my question is, may I expect this diff be applied in default
> xenocara build?

Thanks for testing, I've committed this now and it will be in
future snapshots.

Re: Realtek RTL8111H is not correctly handled

[Jonathan Gray]

Support for RTL8168H/RTL8111H was added after 5.8.
It should work with snapshots and >= 5.9

On Wed, Jan 20, 2016 at 03:02:32AM +0900, hirosh...@borndigital.co.jp wrote:
> >Synopsis:Realtek RTL8111H is not correctly handled.
> >Category:Kernel
> >Environment:
>   System  : OpenBSD 5.8
>   Details : OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 
> 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   RTL8111H on ASUS N3150I-C is detected, but hardware address is 
> 00:00:00:00:00:00, not working.
> >How-To-Repeat:
>   Boot and ifconfig/dmesg.
> >Fix:
>   none
> 
> 
> dmesg:
> OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4116299776 (3925MB)
> avail mem = 3987648512 (3802MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebec0 (46 entries)
> bios0: vendor American Megatrends Inc. version "0304" date 05/28/2015
> bios0: ASUS All Series
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT CSRT
> acpi0: wakeup devices UAR1(S4) UAR2(S4) PS2K(S3) PS2M(S3) XHC1(S4) HDEF(S4) 
> PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
> BRCM(S0) BRC1(S0)
> 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) Celeron(R) CPU N3150 @ 1.60GHz, 1680.40 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu0: 1MB 64b/line 16-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 79MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz, 1679.94 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu1: 1MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz, 1679.94 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu2: 1MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz, 1679.94 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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu3: 1MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (RP01)
> acpiprt2 at acpi0: bus -1 (RP02)
> acpiprt3 at acpi0: bus 2 (RP03)
> acpiprt4 at acpi0: bus -1 (RP04)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0
> C2: state 6: substate 8 >= num 3
> C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0
> C2: state 6: substate 8 >= num 3
> C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0
> C2: state 6: substate 8 >= num 3
> C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0
> C2: state 6: substate 8 >= num 3
> C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: CLK0, resource for CAMD
> acpipwrres1 at acpi0: CLK0, resource for CAM1
> acpipwrres2 at acpi0: CLK1, resource for CAM2, CAM3
> acpipwrres3 at acpi0: USBC, resource for XHC1
> acpibat0 at acpi0: BAT0 not present
> acpibat1 at acpi0: BAT1 not present
> acpibat2 at acpi0: BAT2 not present
> acpibtn0 at acpi0: LID0
> acpibtn1 at acpi0: PWRB
> acpibtn2 at acpi0: SLPB
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD1F
> cpu0: Enhanced SpeedStep 1680 MHz: speeds: 1601, 1600, 1520, 1440, 1360, 
> 1280, 1200, 1120, 1040, 960, 880, 

Re: armv7: pmap_fault_fixup: va 00008000 ftype 5 u pte 7ff2a02e

[Jonathan Gray]

On Sat, Jun 25, 2016 at 12:34:39AM +0200, Juan Francisco Cantero Hurtado wrote:
> I'm trying to install OpenBSD on a Olimex LIME2 board. I didn't know
> exactly how to install the system on this board, so I used the
> cubieboard image, overwrote the u-boot image with
> u-boot-sunxi-with-spl.bin (from ports) and changed the dtb file to
> sun7i-a20-olinuxino-lime2.dtb (also from ports).
> 
> I don't know if this is a real bug or I fucked up something.

http://marc.info/?l=openbsd-arm=145629789513921=2

> 
> 
> Connected to /dev/cuaU0 (speed 115200)
> 
> U-Boot SPL 2016.05 (Jun 23 2016 - 01:28:15)
> DRAM: 1024 MiB
> CPU: 91200Hz, AXI/AHB/APB: 3/2/2
> Trying to boot from MMC1
> 
> 
> U-Boot 2016.05 (Jun 23 2016 - 01:28:15 -0600) Allwinner Technology
> 
> CPU:   Allwinner A20 (SUN7I)
> Model: Olimex A20-OLinuXino-LIME2
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> Net:   eth0: ethernet@01c5
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB OHCI 1.0
> USB2:   USB EHCI 1.00
> USB3:   USB OHCI 1.0
> scanning bus 0 for devices... 1 USB Device(s) found
> scanning bus 2 for devices... 1 USB Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> reading /sun7i-a20-olinuxino-lime2.dtb
> 29895 bytes read in 30 ms (972.7 KiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> reading efi/boot/bootarm.efi
> 65196 bytes read in 43 ms (1.4 MiB/s)
> ## Starting EFI application at 0x4200 ...
> Scanning disks on scsi...
> Scanning disks on usb...
> Scanning disks on mmc...
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 2 disks
> >> OpenBSD/armv7 BOOTARM 0.1
> boot>
> cannot open sd0a:/etc/random.seed: No such file or directory
> booting sd0a:/bsd: 2077592+7932172+435436 [64+294720+141677]=0xa6585c
> 
> OpenBSD/armv7 booting ...
> arg0 0x0 arg1 0x10bb arg2 0x4800
> Allocating page tables
> freestart = 0x40d66000, free_pages = 258714 (0x0003f29a)
> IRQ stack: p0x40d94000 v0xc0d94000
> ABT stack: p0x40d95000 v0xc0d95000
> UND stack: p0x40d96000 v0xc0d96000
> SVC stack: p0x40d97000 v0xc0d97000
> Creating L1 page table at 0x40d68000
> Mapping kernel
> Constructing L2 page tables
> undefined page pmap board type: 4283
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2016 OpenBSD. All rights reserved.  http://www.OpenBSD.org
> 
> OpenBSD 6.0-beta (RAMDISK) #78: Fri Jun 24 17:20:02 AEST 2016
> j...@armv7.jsg.id.au:/usr/src/sys/arch/armv7/compile/RAMDISK
> real mem  = 1073741824 (1024MB)
> avail mem = 1038819328 (990MB)
> mainbus0 at root: Olimex A20-OLinuXino-LIME2
> cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core)
> cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
> cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache
> cortex0 at mainbus0
> ampintc0 at cortex0 nirq 160
> agtimer0 at cortex0: tick rate 24000 KHz
> sunxi0 at mainbus0
> sxipio0 at sunxi0
> sxiccmu0 at sunxi0
> sxidog0 at sunxi0
> sxirtc0 at sunxi0
> ahci0 at sunxi0 AHCI 1.1
> scsibus0 at ahci0: 32 targets
> ehci0 at sunxi0
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1
> ehci1 at sunxi0
> usb1 at ehci1: USB revision 2.0
> uhub1 at usb1 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1
> gpio0 at sxipio0: 18 pins
> gpio1 at sxipio0: 24 pins
> gpio2 at sxipio0: 25 pins
> gpio3 at sxipio0: 28 pins
> gpio4 at sxipio0: 12 pins
> gpio5 at sxipio0: 6 pins
> gpio6 at sxipio0: 12 pins
> gpio7 at sxipio0: 28 pins
> gpio8 at sxipio0: 22 pins
> simplebus0 at mainbus0: "soc"
> sxiuart0 at simplebus0: console
> boot device: lookup 'sd0a:/bsd' failed.
> root on rd0a swap on rd0b dump on rd0b
> WARNING: clock lost 16976 days
> WARNING: CHECK AND RESET THE DATE!
> erase ^?, werase ^W, kill ^U, intr ^C, status ^T
> 
> Welcome to the OpenBSD/armv7 6.0 installation program.
> (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? i
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 u pte 7ff2a02e
> pmap_fault_fixup: va 8000 ftype 5 

Re: softraid panics

[Jonathan Gray]

On Sat, Feb 13, 2016 at 11:37:17AM +0100, Stefan Sperling wrote:
> On Sat, Feb 13, 2016 at 03:42:16PM +1100, Jonathan Gray wrote:
> > On Fri, Feb 12, 2016 at 11:07:35AM -0500, Johan Huldtgren wrote:
> > > uvm_fault(0x8193f240, 0x38, 0, 1) -> e
> > > kernel: page fault trap, code=0
> > > Stopped at  sr_validate_io+0x36:movl0x38(%r9),%r10d
> > > ddb{1}> trace
> > > sr_validate_io() at sr_validate_io+0x36
> > > sr_raid5_rw() at sr_raid5_rw+0x40
> > > sr_raid_recreate_wu() at sr_raid_recreate_wu+0x2c
> > > sr_wu_done_callback() at sr_wu_done_callback+0x17a
> > > taskq_thread() at taskq_thread+0x6c
> > 
> > Thanks for all the detail you've provided here.  The fault appears to be
> > caused by a NULL xs.  A diff to error in that case is provided below.
> > 
> > Perhaps someone familiar with the softraid/scsi code can comment as to
> > why this is occuring.
> 
> The trace of the first crash reported by Johan looks like it could perhaps
> be caused by a garbage xs, doesn't it?
> 
> Quoting http://marc.info/?l=openbsd-misc=14540306396=2
> panic: Non dma-reachable buffer at curaddr 0x81115888(raw)
> Stopped at Debugger+0x9: leave
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> *25637 25637 0 0x14000 0x200 1 srdis
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> _bus_dmamap_load_buffer() at _bus_dmamap_load_buffer+0x1b6
> _bus_dmamap_load() at _bus_dmamap_load+0x7f
> ahci_load_prdt() at ahci_load_prdt+0x97
> ahci_ata_cmd() at ahci_ata_cmd+0x69
> atascsi_disk_cmd() at atascsis_disk_cmd+0x1b1
> scsi_xs_exec() scsi_xs_exec+0x35
> sdstart() at sdstart+0x16f
> scsi_iopool_run() at scsi_iopool_run+0x5d
> scsi_xsh_runqueue() at scsi_xsh_runqueue+0x13d
> scsi_xsh_add() at scsi_xsh_add+0x98
> sdstrategy() at sdstrategy+0x10f
> spec_strategy() at spec_strategy+0x53
> end trace frame: 0x800032ca1e40, count: 0
> 
> Maybe there's an uninitialized variable which happened to contain
> zeros in this second instance of the crash?

The potentially uninitialised variable use turns out to be these:

Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.365
diff -u -p -r1.365 softraid.c
--- softraid.c  29 Dec 2015 04:46:28 -  1.365
+++ softraid.c  14 Feb 2016 00:28:14 -
@@ -3113,7 +3113,7 @@ sr_rebuild_init(struct sr_discipline *sd
struct disklabellabel;
struct vnode*vn;
u_int64_t   size;
-   int64_t csize;
+   int64_t csize = 0;
chardevname[32];
int rv = EINVAL, open = 0;
int cid, i, part, status;
@@ -3206,6 +3206,7 @@ sr_rebuild_init(struct sr_discipline *sd
devname);
goto done;
}
+   /* here */
if (size < csize) {
sr_error(sc, "%s partition too small, at least %lld bytes "
"required", devname, (long long)(csize << DEV_BSHIFT));
@@ -3657,7 +3658,7 @@ sr_ioctl_installboot(struct sr_softc *sc
 struct bioc_installboot *bb)
 {
void*bootblk = NULL, *bootldr = NULL;
-   struct sr_chunk *chunk;
+   struct sr_chunk *chunk = NULL;
struct sr_meta_opt_item *omi;
struct sr_meta_boot *sbm;
struct disk *dk;
@@ -3786,7 +3787,7 @@ sr_ioctl_installboot(struct sr_softc *sc
sd->sd_meta->ssdi.ssd_vol_flags |= BIOC_SCBOOTABLE;
if (sr_meta_save(sd, SR_META_DIRTY)) {
sr_error(sc, "could not save metadata to %s",
-   chunk->src_devname);
+   chunk ? chunk->src_devname : "disk");
goto done;
}
 

Re: UEFI Boot Report: Screen corruption and kernel panic

[Jonathan Gray]

On Tue, Feb 02, 2016 at 10:27:24PM +1100, Jonathan Gray wrote:
> On Tue, Feb 02, 2016 at 05:49:33AM -0500, James Hastings wrote:
> > On 2/2/16, Jonathan Gray <j...@jsg.id.au> wrote:
> > > On Tue, Feb 02, 2016 at 03:56:13AM -0500, James Hastings wrote:
> > >> On 2/2/16, Jonathan Gray <j...@jsg.id.au> wrote:
> > >> >
> > >> > The bios may have to be fetched from the acpi VFCT table for the uefi
> > >> > case.
> > >> >
> > >> > Here's a quick attempt at trying to avoid the crash at least:
> > >> >
> > >>
> > >> Different panic this time.
> > >
> > > Thanks.  Here is a version modified to have a better check for efi.
> > > Still may need some things shuffled around to deal with the root hook.
> > >
> > 
> > Identical panic again.
> > 
> > Thinking out loud; could these two issues be caused by bad information
> > passed by
> > the bootloader or firmware? memory maps? framebuffer address?
> 
> It's because one of the ways of getting the video bios is to check where
> it has long been mapped and reading out of that memory.
> 
> It sounds like your machine has enough of it there to convince the code
> that checks for a signature but not all of the expected 256k of memory
> after 0xc is actually mapped.
> 
> Putting a "return false;" at the top of radeon_read_platform_bios()
> should prevent this method from being tried entirely.
> 

Can you try this to limit the size?

Index: radeon_bios.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_bios.c,v
retrieving revision 1.6
diff -u -p -r1.6 radeon_bios.c
--- radeon_bios.c   12 Apr 2015 12:14:30 -  1.6
+++ radeon_bios.c   2 Feb 2016 21:30:25 -
@@ -48,11 +48,10 @@ radeon_read_platform_bios(struct radeon_
 {
 #if defined(__amd64__) || defined(__i386__)
uint8_t __iomem *bios;
-   bus_size_t size = 256 * 1024; /* ??? */
+   bus_size_t size = 0x2;
uint8_t *found = NULL;
int i;
-   
-   
+
if (!(rdev->flags & RADEON_IS_IGP))
if (!radeon_card_posted(rdev))
return false;

Re: UEFI Boot Report: Screen corruption and kernel panic

[Jonathan Gray]

On Tue, Feb 02, 2016 at 02:09:08AM -0500, James Hastings wrote:
> Testing UEFI booting. Willing to test patches and debug.
> 
> 1) Encountered screen corruption immediately after EFIBOOT.
>   http://imgur.com/mXURlgV
> 
> 2) Kernel panic unless radeondrm(4) disabled.
>   Provided dmesg, pcidump, acpidump from successful boot.
>   http://pastebin.com/1JSxgBfT
> 
> System boot results:
> 
> legacy RAMDISK_CD:screen ok, boot ok
> legacy GENERIC.MP:screen ok, boot ok
> uefi   RAMDISK_CD:screen garbage, boot ok
> uefi   GENERIC.MP:screen garbage, kernel panic
> uefi   GENERIC.MP disable radeondrm(4):   screen garbage, boot ok

The bios may have to be fetched from the acpi VFCT table for the uefi case.

Here's a quick attempt at trying to avoid the crash at least:

Index: radeon.h
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon.h,v
retrieving revision 1.17
diff -u -p -r1.17 radeon.h
--- radeon.h27 Sep 2015 11:09:26 -  1.17
+++ radeon.h2 Feb 2016 07:33:39 -
@@ -1554,6 +1554,7 @@ struct radeon_device {
struct drm_device   *ddev;
struct pci_dev  *pdev;
 
+   struct pci_attach_args  *pa;
pci_chipset_tag_t   pc;
pcitag_tpa_tag;
pci_intr_handle_t   intrh;
@@ -1595,6 +1596,7 @@ struct radeon_device {
/* BIOS */
uint8_t *bios;
boolis_atom_bios;
+   int uefi;
uint16_tbios_header_start;
struct radeon_bo*stollen_vga_memory;
/* Register mmio */
Index: radeon_bios.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_bios.c,v
retrieving revision 1.6
diff -u -p -r1.6 radeon_bios.c
--- radeon_bios.c   12 Apr 2015 12:14:30 -  1.6
+++ radeon_bios.c   2 Feb 2016 07:34:17 -
@@ -51,8 +51,10 @@ radeon_read_platform_bios(struct radeon_
bus_size_t size = 256 * 1024; /* ??? */
uint8_t *found = NULL;
int i;
-   
-   
+
+   if (rdev->uefi)
+   return false;
+
if (!(rdev->flags & RADEON_IS_IGP))
if (!radeon_card_posted(rdev))
return false;
Index: radeon_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
retrieving revision 1.46
diff -u -p -r1.46 radeon_kms.c
--- radeon_kms.c6 Jan 2016 19:56:08 -   1.46
+++ radeon_kms.c2 Feb 2016 07:33:05 -
@@ -41,6 +41,14 @@
 extern int vga_console_attached;
 #endif
 
+#ifdef __amd64__
+#include "efifb.h"
+#endif
+
+#if NEFIFB > 0
+#include 
+#endif
+
 #define DRIVER_NAME"radeon"
 #define DRIVER_DESC"ATI Radeon"
 #define DRIVER_DATE"20080613"
@@ -481,6 +489,7 @@ radeondrm_attach_kms(struct device *pare
id_entry = drm_find_description(PCI_VENDOR(pa->pa_id),
PCI_PRODUCT(pa->pa_id), radeondrm_pciidlist);
rdev->flags = id_entry->driver_data;
+   rdev->pa = pa;
rdev->pc = pa->pa_pc;
rdev->pa_tag = pa->pa_tag;
rdev->iot = pa->pa_iot;
@@ -501,6 +510,16 @@ radeondrm_attach_kms(struct device *pare
vga_console_attached = 1;
 #endif
}
+#if NEFIFB > 0
+   if (efifb_is_console(pa)) {
+   rdev->console = 1;
+   /* XXX better test */
+   rdev->uefi = 1;
+   }
+#else
+   rdev->uefi = 0;
+#endif
+
 #endif
 
 #define RADEON_PCI_MEM 0x10
@@ -713,6 +732,12 @@ radeondrm_attachhook(struct device *self
 #ifdef __sparc64__
fbwscons_setcolormap(>sf, radeondrm_setcolor);
 #endif
+
+#if NEFIFB > 0
+   if (efifb_is_console(rdev->pa))
+   efifb_cndetach();
+#endif
+
drm_modeset_lock_all(rdev->ddev);
drm_fb_helper_restore_fbdev_mode((void *)rdev->mode_info.rfbdev);
drm_modeset_unlock_all(rdev->ddev);

Re: UEFI Boot Report: Screen corruption and kernel panic

[Jonathan Gray]

On Tue, Feb 02, 2016 at 03:56:13AM -0500, James Hastings wrote:
> On 2/2/16, Jonathan Gray <j...@jsg.id.au> wrote:
> >
> > The bios may have to be fetched from the acpi VFCT table for the uefi case.
> >
> > Here's a quick attempt at trying to avoid the crash at least:
> >
> 
> Different panic this time.

Thanks.  Here is a version modified to have a better check for efi.
Still may need some things shuffled around to deal with the root hook.

Index: radeon.h
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon.h,v
retrieving revision 1.17
diff -u -p -r1.17 radeon.h
--- radeon.h27 Sep 2015 11:09:26 -  1.17
+++ radeon.h2 Feb 2016 07:33:39 -
@@ -1554,6 +1554,7 @@ struct radeon_device {
struct drm_device   *ddev;
struct pci_dev  *pdev;
 
+   struct pci_attach_args  *pa;
pci_chipset_tag_t   pc;
pcitag_tpa_tag;
pci_intr_handle_t   intrh;
@@ -1595,6 +1596,7 @@ struct radeon_device {
/* BIOS */
uint8_t *bios;
boolis_atom_bios;
+   int uefi;
uint16_tbios_header_start;
struct radeon_bo*stollen_vga_memory;
/* Register mmio */
Index: radeon_bios.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_bios.c,v
retrieving revision 1.6
diff -u -p -r1.6 radeon_bios.c
--- radeon_bios.c   12 Apr 2015 12:14:30 -  1.6
+++ radeon_bios.c   2 Feb 2016 07:34:17 -
@@ -51,8 +51,10 @@ radeon_read_platform_bios(struct radeon_
bus_size_t size = 256 * 1024; /* ??? */
uint8_t *found = NULL;
int i;
-   
-   
+
+   if (rdev->uefi)
+   return false;
+
if (!(rdev->flags & RADEON_IS_IGP))
if (!radeon_card_posted(rdev))
return false;
Index: radeon_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
retrieving revision 1.46
diff -u -p -r1.46 radeon_kms.c
--- radeon_kms.c6 Jan 2016 19:56:08 -   1.46
+++ radeon_kms.c2 Feb 2016 09:16:40 -
@@ -41,6 +41,15 @@
 extern int vga_console_attached;
 #endif
 
+#ifdef __amd64__
+#include "efifb.h"
+#endif
+
+#if NEFIFB > 0
+#include 
+#include 
+#endif
+
 #define DRIVER_NAME"radeon"
 #define DRIVER_DESC"ATI Radeon"
 #define DRIVER_DATE"20080613"
@@ -481,6 +490,7 @@ radeondrm_attach_kms(struct device *pare
id_entry = drm_find_description(PCI_VENDOR(pa->pa_id),
PCI_PRODUCT(pa->pa_id), radeondrm_pciidlist);
rdev->flags = id_entry->driver_data;
+   rdev->pa = pa;
rdev->pc = pa->pa_pc;
rdev->pa_tag = pa->pa_tag;
rdev->iot = pa->pa_iot;
@@ -501,6 +511,15 @@ radeondrm_attach_kms(struct device *pare
vga_console_attached = 1;
 #endif
}
+#if NEFIFB > 0
+   if (efifb_is_console(pa))
+   rdev->console = 1;
+   if (bios_efiinfo != NULL)
+   rdev->uefi = 1;
+#else
+   rdev->uefi = 0;
+#endif
+
 #endif
 
 #define RADEON_PCI_MEM 0x10
@@ -713,6 +732,12 @@ radeondrm_attachhook(struct device *self
 #ifdef __sparc64__
fbwscons_setcolormap(>sf, radeondrm_setcolor);
 #endif
+
+#if NEFIFB > 0
+   if (efifb_is_console(rdev->pa))
+   efifb_cndetach();
+#endif
+
drm_modeset_lock_all(rdev->ddev);
drm_fb_helper_restore_fbdev_mode((void *)rdev->mode_info.rfbdev);
drm_modeset_unlock_all(rdev->ddev);

Re: UEFI Boot Report: Screen corruption and kernel panic

[Jonathan Gray]

On Tue, Feb 02, 2016 at 05:49:33AM -0500, James Hastings wrote:
> On 2/2/16, Jonathan Gray <j...@jsg.id.au> wrote:
> > On Tue, Feb 02, 2016 at 03:56:13AM -0500, James Hastings wrote:
> >> On 2/2/16, Jonathan Gray <j...@jsg.id.au> wrote:
> >> >
> >> > The bios may have to be fetched from the acpi VFCT table for the uefi
> >> > case.
> >> >
> >> > Here's a quick attempt at trying to avoid the crash at least:
> >> >
> >>
> >> Different panic this time.
> >
> > Thanks.  Here is a version modified to have a better check for efi.
> > Still may need some things shuffled around to deal with the root hook.
> >
> 
> Identical panic again.
> 
> Thinking out loud; could these two issues be caused by bad information
> passed by
> the bootloader or firmware? memory maps? framebuffer address?

It's because one of the ways of getting the video bios is to check where
it has long been mapped and reading out of that memory.

It sounds like your machine has enough of it there to convince the code
that checks for a signature but not all of the expected 256k of memory
after 0xc is actually mapped.

Putting a "return false;" at the top of radeon_read_platform_bios()
should prevent this method from being tried entirely.

Re: std::ifstream is broken on arm

[Jonathan Gray]

On Tue, Feb 16, 2016 at 08:08:13PM +, Miod Vallat wrote:
> Actually, I had forgotten to disable the stack protector, and guess
> what? Disabling it produces a working libstdc++, at least for that
> simple use case; I have not tried to build cmake.
> 
> Therefore I suggest the following diff until someone with enough love
> for the utter crap known as `arm' comes with a real compiler fix:
> 
> Index: Makefile
> ===
> RCS file: /OpenBSD/src/gnu/lib/libstdc++-v3/Makefile,v
> retrieving revision 1.8
> diff -u -p -r1.8 Makefile
> --- Makefile  14 May 2015 02:56:01 -  1.8
> +++ Makefile  16 Feb 2016 20:04:20 -
> @@ -17,6 +17,9 @@ CFLAGS+=-frandom-seed=RepeatabilityCons
>  CXXFLAGS+=   -frandom-seed=RepeatabilityConsideredGood
>  CXXFLAGS+=   -fno-implicit-templates -ffunction-sections -fdata-sections \
>   -Wno-deprecated
> +.if ${MACHINE_ARCH} == "arm"
> +CXXFLAGS+=   -fno-stack-protector
> +.endif
>  
>  DPADD=   ${LIBM}
>  LDADD=   -lm
> 

After building src/xenocara and prequisite ports it seems cmake
still has issues:

c++  -O2 -pipe  -I/usr/ports/pobj/cmake-3.4.3/build-arm/Bootstrap.cmk 
-I/usr/ports/pobj/cmake-3.4.3/cmake-3.4.3/Source   
-I/usr/ports/pobj/cmake-3.4.3/build-arm/Bootstrap.cmk  cmake.o cmakemain.o 
cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o 
cmCommandArgumentParserHelper.o cmCommonTargetGenerator.o 
cmCPackPropertiesGenerator.o cmDefinitions.o cmDepends.o cmDependsC.o 
cmDocumentationFormatter.o cmPolicies.o cmProperty.o cmPropertyMap.o 
cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o 
cmExportFileGenerator.o cmExportInstallFileGenerator.o 
cmExportTryCompileFileGenerator.o cmExportSet.o cmExportSetMap.o 
cmExternalMakefileProjectGenerator.o cmGeneratorExpressionEvaluationFile.o 
cmGeneratedFileStream.o cmGeneratorTarget.o cmGeneratorExpressionContext.o 
cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluator.o 
cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o 
cmGeneratorExpressionParser.o cmGeneratorExpression.o cmGlobalCommonGenerator.o 
cmGlobalGenerator.o cmInstallDirectoryGenerator.o cmLocalCommonGenerator.o 
cmLocalGenerator.o cmInstalledFile.o cmInstallGenerator.o 
cmInstallExportGenerator.o cmInstallFilesGenerator.o cmInstallScriptGenerator.o 
cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o 
cmSourceFileLocation.o cmState.o cmSystemTools.o cmTestGenerator.o cmVersion.o 
cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o 
cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o 
cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o 
cmMakefileUtilityTargetGenerator.o cmOutputConverter.o cmOSXBundleGenerator.o 
cmNewLineStyle.o cmBootstrapCommands1.o cmBootstrapCommands2.o 
cmCommandsForBootstrap.o cmTarget.o cmTest.o cmCustomCommand.o 
cmCustomCommandGenerator.o cmCacheManager.o cmListFileCache.o 
cmComputeLinkDepends.o cmComputeLinkInformation.o cmOrderDirectories.o 
cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o 
cmExprParserHelper.o cmGlobalNinjaGenerator.o cmLocalNinjaGenerator.o 
cmNinjaTargetGenerator.o cmNinjaNormalTargetGenerator.o 
cmNinjaUtilityTargetGenerator.o cmListFileLexer.o Directory.o EncodingCXX.o 
FStream.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o 
String.o System.o Terminal.o -o cmake
cmCommandArgumentParserHelper.o: In function 
`cmCommandArgumentParserHelper::AddString(std::basic_string const&)':
cmCommandArgumentParserHelper.cxx:(.text+0x208): warning: warning: strcpy() is 
almost always misused, please use strlcpy()
cmBootstrapCommands2.o: In function 
`cmStringCommand::HandleRandomCommand(std::vector, 
std::allocator > > const&)':
cmBootstrapCommands2.cxx:(.text+0x43a0): warning: warning: rand() may return 
deterministic values, is that what you want?
cmCommandArgumentParserHelper.o: In function 
`cmCommandArgumentParserHelper::CombineUnions(char*, char*)':
cmCommandArgumentParserHelper.cxx:(.text+0x35c): warning: warning: strcat() is 
almost always misused, please use strlcat()
cmMakefile.o: In function `cmMakefile::AddDefaultDefinitions()':
cmMakefile.cxx:(.text+0x81c4): warning: warning: sprintf() is often misused, 
please use snprintf()
loading initial cache file 
/usr/ports/pobj/cmake-3.4.3/build-arm/Bootstrap.cmk/InitialCacheFlags.cmake
CMake Error: Error processing file: 
/usr/ports/pobj/cmake-3.4.3/build-arm/Bootstrap.cmk/InitialCacheFlags.cmake
assertion "cmSystemTools::FileExists(currentStart.c_str(), true)" failed: file 
"/usr/ports/pobj/cmake-3.4.3/cmake-3.4.3/Source/cmMakefile.cxx", line 1652, 
function "Configure"
Abort trap (core dumped) 
-
Error when bootstrapping 

Re: wsconsctl floating point exception

[Jonathan Gray]

On Fri, Apr 29, 2016 at 03:52:37PM +0200, Mark Kettenis wrote:
> > Date: Fri, 29 Apr 2016 23:12:57 +1000
> > From: Jonathan Gray <j...@jsg.id.au>
> > 
> > On Sat, Apr 23, 2016 at 10:20:15PM +0200, Joerg Jung wrote:
> > > On Tue, Apr 19, 2016 at 10:57:38AM +0200, Caspar Schutijser wrote:
> > > > Hi bugs@,
> > > > 
> > > > On my laptop, wsconsctl crashes with a floating point exception when it
> > > > wants to print keyboard.backlight. It divides by 0.
> > > > 
> > > > Below is a patch that fixes the issue, output from gdb and my dmesg.
> > > 
> > > Yes this is a known problem.  There were some suggestion to fix this not
> > > in wsconsctl (but instead in acpithinkpad?).
> > 
> > Given this still isn't fixed here is a diff to do just that and
> > return an error from the ioctl callback when max is 0.
> > 
> > Index: acpithinkpad.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
> > retrieving revision 1.51
> > diff -u -p -r1.51 acpithinkpad.c
> > --- acpithinkpad.c  10 Jan 2016 16:30:43 -  1.51
> > +++ acpithinkpad.c  29 Apr 2016 13:05:02 -
> > @@ -630,6 +630,9 @@ thinkpad_get_backlight(struct wskbd_back
> >  
> > kbl->min = 0;
> > kbl->max = (sc->sc_thinklight >> 8) & 0x0f;
> > +   if (kbl->max == 0)
> > +   return (-1);
> > +
> > kbl->curval = sc->sc_thinklight & 0x0f;
> > return 0;
> >  }
> 
> I think you should return ENOTTY, since that is what
> wskbd_displayioctl() would have returned if we had no keyboard
> backlight.

sure

Index: acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.51
diff -u -p -r1.51 acpithinkpad.c
--- acpithinkpad.c  10 Jan 2016 16:30:43 -  1.51
+++ acpithinkpad.c  29 Apr 2016 13:58:36 -
@@ -631,6 +631,10 @@ thinkpad_get_backlight(struct wskbd_back
kbl->min = 0;
kbl->max = (sc->sc_thinklight >> 8) & 0x0f;
kbl->curval = sc->sc_thinklight & 0x0f;
+
+   if (kbl->max == 0)
+   return (ENOTTY);
+
return 0;
 }
 
@@ -641,6 +645,9 @@ thinkpad_set_backlight(struct wskbd_back
int maxval = (sc->sc_thinklight >> 8) & 0x0f;
 
KASSERT(sc != NULL);
+
+   if (maxval == 0)
+   return (ENOTTY);
 
if (kbl->curval > maxval)
return EINVAL;

Re: efiboot can't find OpenBSD GPT partition on Lenovo Ideapad 100s

[Jonathan Gray]

The 100s is 32 bit uefi only.  It requires BOOTIA32.EFI.
The problems linux has are related to them communicating with the uefi runtime
after the kernel has booted.

Could it be this problem is related to
sys/arch/amd64/stand/efi/include/i386/efibind.h using sys/stdint.h 
which looks like it will make uint64_t unsigned long on for BOOTIA32.EFI
not unsigned long long?

On Fri, Apr 22, 2016 at 12:07:47PM -0400, Kenneth Westerback wrote:
> I see other reports on the 100s indicating that Ubuntu can't boot either; :-(.
> 
> e.g.
> 
> http://askubuntu.com/questions/684041/ubuntu-debian-on-a-lenovo-ideapad-100s-linux-has-issues-with-this-laptop
> 
> It appears that Lenovo has shipped it with a 32-bit UEFI firmware and
> this causes problems with a 64-bit boot loader. It certainly smells
> like the firmware only provided 32-bits of info for the lastblock
> value.
> 
> https://blogs.intel.com/evangelists/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems/
> 
> I don't know if there is a definitive way to detect this mismatch. We
> do appear to have a BOOTIA32.EFI but I've no idea if this means it can
> be used somehow.
> 
> I hope a uefi guru (i.e. someone who has a better grasp on the issue
> than my 10 minutes of googling has given me. :-)) can provide more
> information.
> 
>  Ken
> 
> 
> On 22 April 2016 at 11:01,   wrote:
> >>Synopsis:  efiboot can't find OpenBSD GPT partition on Lenovo Ideapad 
> >>100s
> >>Category:  amd64
> >>Environment:
> > System  : OpenBSD 5.9
> > Details : OpenBSD 5.9-current (GENERIC.MP) #1983: Mon Apr  4 
> > 21:50:41 MDT 2016
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> >>Description:
> > Dan Jones reported this issue to misc@ on Feb. 9, 2016:
> > [https://marc.info/?l=openbsd-misc=145499095625605=2]
> >
> > On the first reboot after initial install, efiboot fails with the
> > following error:
> >
> > probing: pc0 mem[572K 56K 511M 1391M 61M 9M 2M 124K 36K]
> > disk: hd0* hd1* hd2*
> > >> OpenBSD/amd64 EFIBOOT 3.30
> > open(hd0a:/etc/boot.conf): invalid argument
> > boot>  [enter]
> > cannot open hd0a:/etc/random.seed: invalid argument
> > booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
> >   failed(22). will try /bsd
> >
> > `machine diskinfo' prints garbage which scrolls off the screen, so I
> > added a printf to see what was going on -- see the efiboot.c diff 
> > below.
> > This produced the following output:
> >
> > MediaId=0 BlockSize=512 LastBlock=3a3dfff
> > MediaId=0 BlockSize=512 LastBlock=2000
> > MediaId=0 BlockSize=512 LastBlock=2000
> >
> > I think that 0x3a3dfff ought to be 0x3a3dfff, which would 
> > jive
> > with what the dmesg shows. Unless I'm missing something, this seems
> > like a firmware bug. I can try reporting this to Lenovo if you 
> > think I
> > should.
> >
> > As far as I can tell, this affects efiboot because of the heuristic 
> > it
> > uses to figure out whether the disk contains a GPT protective MBR.
> > Roughly:
> > - Check whether there's an MBR partition of type 0xEE
> > - Check whether that partition extends to the end of the 
> > disk
> >   or is UINT32_MAX long
> >
> > This logic fails on the Ideapad because the partition does extend to
> > the _real_ end of the disk, but not to what the firmware reports as 
> > the
> > end of the disk (LastBlock+1).
> >
> > To work around this issue, I've added a condition to the logic to
> > succeed when there's a protective partition and the disk size is
> > reported as greater than UINT32_MAX (see efidev.c diff below). It's
> > probably not the right fix, but it has me booting now.
> >
> > As far as I can figure, this affects a new installation and not the
> > installer because the installer disk image has an MBR. I tested this
> > hypothesis on a USB stick with a fresh install of -current, where I
> > selected MBR during the install and made an EFI partition manually. 
> > This
> > booted fine, where the same test with GPT didn't.
> >
> >>How-To-Repeat:
> > 1. Install OpenBSD with the default GPT on Ideapad 100s.
> > 2. Reboot.
> >>Fix:
> >
> > Index: efiboot.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
> > retrieving revision 1.11
> > diff -u -p -r1.11 efiboot.c
> > --- efiboot.c   4 Feb 2016 09:19:39 -   1.11
> > +++ efiboot.c   22 Apr 

Re: Sending gratutious ARP to a bridge interface

[Jonathan Gray]

On Wed, May 11, 2016 at 10:20:29PM -0400, michel.bell...@malaiwah.com wrote:
> >Synopsis:attempt to execute 0x0, arping to bridge
> >Category:system
> >Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 
> 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> panic: attempt to execute user address 0x0 in supervisor mode
> Stopped at  Debugger+0x9:   leave
>TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> *20236  20236  327670x13  00  arping
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> trap() at trap+0x7dd
> --- trap (number 6) ---
> (null)() at 0
> spec_write() at spec_write+0xbe
> VOP_WRITE() at VOP_WRITE+0x3f
> vn_write() at vn_write+0x98
> dofilewritev() at dofilewritev+0x205
> 
> Not sure if relevant in this bug report, but my Ferrari is a PC Engines APU2.
> 
> >How-To-Repeat:
> # create a bridge interface
> bridge28: flags=41
> groups: bridge
> priority 57344 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
> designated: id 00:00:00:00:00:00 priority 0
> vlan28 flags=7
> port 8 ifpriority 0 ifcost 0
> vlan128 flags=7
> port 7 ifpriority 0 ifcost 0
> Addresses (max cache: 100, timeout: 240):
> ac:f1:df:65:11:15 vlan28 0 flags=1
> # note my two underlying interfaces are down
> vlan28: flags=8942 mtu 1500
> lladdr 00:0d:b9:41:5d:2d
> priority: 0
> vlan: 28 parent interface: trunk0
> groups: vlan
> status: active
> vlan128: flags=8942 mtu 1500
> lladdr 00:0d:b9:41:5d:2d
> priority: 0
> vlan: 128 parent interface: trunk0
> groups: vlan
> status: active
> # arping -0 -B -i bridge28 -c 2 -P -s "00:11:22:33:44:55" -q
> ## also had the same results trying it with dnet arp op rep sha 
> "00:11:22:33:44:55" | dnet eth type arp dst ff:ff:ff:ff:ff:ff | dnet send 
> bridge28
> # boum.
> >Fix:
>   Fix is unknown

This sounds like the problem that was fixed in if_bridge.c 1.278

revision 1.278
date: 2016/04/12 06:20:30;  author: mpi;  state: Exp;  lines: +12 -2;  
commitid: Itzt9gWTLLzkrbM4;
Set bridge(4)'s if_output to a dummy function returning EAFNOSUPPORT as
it should not be used to output packets but we have to respect the ifp
driver API to some extend.

Prevent a panic found the hardway by espie@.

ok claudio@, mikeb@, jsg@, krw@

Index: if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.275
diff -u -p -r1.275 if_bridge.c
--- if_bridge.c 5 Dec 2015 10:07:55 -   1.275
+++ if_bridge.c 12 May 2016 07:06:20 -
@@ -127,6 +127,8 @@ struct mbuf *bridge_ip(struct bridge_sof
 struct ether_header *, struct mbuf *m);
 intbridge_ifenqueue(struct bridge_softc *, struct ifnet *, struct mbuf *);
 void   bridge_ifinput(struct ifnet *, struct mbuf *);
+intbridge_dummy_output(struct ifnet *, struct mbuf *, struct sockaddr *,
+struct rtentry *);
 void   bridge_fragment(struct bridge_softc *, struct ifnet *,
 struct ether_header *, struct mbuf *);
 #ifdef IPSEC
@@ -187,7 +189,7 @@ bridge_clone_create(struct if_clone *ifc
ifp->if_softc = sc;
ifp->if_mtu = ETHERMTU;
ifp->if_ioctl = bridge_ioctl;
-   ifp->if_output = NULL;
+   ifp->if_output = bridge_dummy_output;
ifp->if_start = NULL;
ifp->if_type = IFT_BRIDGE;
ifp->if_hdrlen = ETHER_HDR_LEN;
@@ -203,6 +205,14 @@ bridge_clone_create(struct if_clone *ifc
if_ih_insert(ifp, ether_input, NULL);
 
return (0);
+}
+
+int
+bridge_dummy_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst,
+struct rtentry *rt)
+{
+   m_freem(m);
+   return (EAFNOSUPPORT);
 }
 
 int

Re: ddb on armv7 beaglebone black

[Jonathan Gray]

On Fri, Jul 22, 2016 at 05:30:13PM +0300, Lars Noodn wrote:
> I'm getting errors with clean installs of the latest armv7 snapshot
> (Build date: 1469162775 - Fri Jul 22 04:46:15 UTC 2016) on a
> beaglebone black.  It ends up at a ddb prompt quite late in the boot
> process.  I've tried re-installation a half dozen times or so, booting
> each time to an error, though every once in a while it has gone
> through to a login prompt but I cannot find the pattern yet. The
> device also now tries to boot from the SD now rather than the built-in
> flash, so if I leave the SD in, I get the installer every time and
> have to remove it to get the built-in flash.
> 
> /Lars

The changes there were recently backed out
http://marc.info/?l=openbsd-cvs=146918611604557=2

Give the next snapshot a try when it appears in a day or two.

> 
> ...
> starting early daemons: syslogd pflogd ntpd.
> starting RPC daemons:.
> savecore: no core dump
> checking quotas: done.
> clearing /tmp
> kern.securelevel: 0 -> 1
> creating runtime link editor directory cache.
> preserving editor files.
> 
> uvm_fault(0xc92e75f0, 0, 1, 0) -> e
> Fatal kernel mode data abort: 'Translation Fault (P)'
> trapframe: 0xcb331d80
> DFSR=0007, DFAR=, spsr=6013
> r0 =cb331e60, r1 =cb331e64, r2 =, r3 =c92772a0
> r4 =, r5 =cb331e64, r6 =c92772a0, r7 =
> r8 =cb331e60, r9 =c06a8b54, r10=c06a8b54, r11=cb331dfc
> r12=cb331e00, ssp=cb331dd4, slr=c050a058, pc =c0509bfc
> 
> Stopped at  in6_selectsrc+0x14: ldrbr12, [r4]
> ddb> ps
>TID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
>  85993  17072  17072  0  2   0ntpd
> *34450  17072  17072 83  70x100010ntpd
>  32541  73818  73818  0  2 0x3perl
>  96177  75510  17072 83  30x100090  poll  ntpd
>  75510  17072  17072 83  30x100090  poll  ntpd
>  17072  1  17072  0  30x80  poll  ntpd
>  60851   7308   7308 74  30x100090  bpf   pflogd
>   7308  1   7308  0  30x80  netio pflogd
>  58622  83495  83495 73  20x100090syslogd
>  83495  1  83495  0  30x100080  netio syslogd
>  49500  1  49500 77  30x100090  poll  dhclient
>  15366  1  15366  0  30x80  poll  dhclient
>  73818  1  73818  0  30x10008b  pause sh
>  33201  0  0  0  2 0x14200zerothread
>  38418  0  0  0  3 0x14200  aiodoned  aiodoned
>  49637  0  0  0  3 0x14200  syncerupdate
>  44514  0  0  0  3 0x14200  cleaner   cleaner
>  73832  0  0  0  3 0x14200  reaperreaper
>  67925  0  0  0  3 0x14200  pgdaemon  pagedaemon
>  76330  0  0  0  3 0x14200  bored crynlk
>   3071  0  0  0  3 0x14200  bored crypto
>  22994  0  0  0  3 0x14200  pftm  pfpurge
>  53492  0  0  0  3 0x14200  mmctsksdmmc1
>882  0  0  0  3 0x14200  mmctsksdmmc0
>  14526  0  0  0  3 0x14200  bored softnet
>  14171  0  0  0  3 0x14200  bored systqmp
>  10775  0  0  0  3 0x14200  bored systq
>  70072  0  0  0  3  0x40014200idle0
>  70962  0  0  0  3 0x14200  kmalloc   kmthread
>  1  0  1  0  30x82  wait  init
>  0 -1  0  0  3 0x10200  scheduler swapper
> ddb> trace
> in6_selectsrc+0xc
> scp=0xc0509bf4 rlv=0xc050a058 (in6_pcbselsrc+0x240)
> rsp=0xcb331e00 rfp=0xcb331e54
> r10=0xc06a8b54 r8=0xcb331e60 r7=0x r6=0xc92772a0
> r5=0xcb331e64 r4=0x
> in6_pcbselsrc+0xc
> scp=0xc0509e24 rlv=0xc050568c (in6_pcbconnect+0xf8)
> rsp=0xcb331e58 rfp=0xcb331ea8
> r10=0xc06a8b54 r9=0xc9277258 r8=0xcb331e6c r7=0xc921e9c4
> r6=0xc9277284 r5=0xc9277258 r4=0xcb331e64
> in6_pcbconnect+0xc
> scp=0xc05055a0 rlv=0xc047542c ($a+0x448)
> rsp=0xcb331eac rfp=0xcb331eec
> r10=0xc91bc5bc r8=0x0004 r7=0xc921e9c4 r6=0xc9223400
> r5=0xc90c3004 r4=0x
> tcp_usrreq+0x10
> scp=0xc0474e6c rlv=0xc03dd3fc (soconnect+0xb4)
> rsp=0xcb331ef0 rfp=0xcb331f1c
> r10=0xbffd8bf8 r9=0x0004 r8=0xc069a854 r7=0x
> r6=0xc9223400 r5=0x r4=0xc91bc5bc
> soconnect+0xc
> scp=0xc03e15ec rlv=0xc0537ffc (swi_handler+0x174)
> rsp=0xcb331f50 rfp=0xcb331fac
> r8=0x0062 r7=0xc921e9c4 r6=0xcb331fb0 r5=0x0003
> r4=0xcb331fb4
> swi_handler+0xc
> scp=0xc0537e94 rlv=0xc053a5b0 (swi_entry+0x28)
> rsp=0xcb331fb0 rfp=0xbffd8bc8
> r10=0xbffd8bf8 r9=0x49bcf6a0 r8=0x001c 

Re: mesa is broken on macppc (__sync_add_and_fetch_8)

[Jonathan Gray]

On Fri, Jan 20, 2017 at 10:04:43PM +0100, Stefan Sperling wrote:
> Mesa doesn't run anymore on my 15" powerbook g4 which has a radeon R300.
> 
> glxinfo fails like this:
> 
> glxinfo:/usr/X11R6/lib/modules/dri/r300_dri.so: undefined symbol 
> '__sync_add_and_fetch_8'
> libGL error: unable to load driver: r300_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: r300
> glxinfo:/usr/X11R6/lib/modules/dri/swrast_dri.so: undefined symbol 
> '__sync_add_and_fetch_8'
> libGL error: unable to load driver: swrast_dri.so
> libGL error: failed to load driver: swrast
> X Error of failed request:  GLXBadContext
>   Major opcode of failed request:  155 (GLX)
>   Minor opcode of failed request:  6 (X_GLXIsDirect)
>   Serial number of failed request:  47
>   Current serial number in output stream:  0
> name of display: :0
> 
> The code which tries to use this atomic builtin on a 64bit integer is in
> /usr/xenocara/lib/mesa/src/compiler/glsl/cache.c (cache->size is 64 bits).
> 
> I cannot find any calls to this code. And there is a configure option to
> disable this cache. Using that allows at least glxgears to run again.

Which version previously ran? 11.2.2 ?

It might also be possible to patch xenocara/lib/mesa/src/util/u_atomic.h
but macppc runs MP.

Your diff should be

.if ${MACHINE_ARCH} == "powerpc"

as this is a 32 bit powerpc problem, and is not macppc specific.

ok with that changed.

> 
> ok?
> 
> Index: Makefile.bsd-wrapper
> ===
> RCS file: /cvs/xenocara/lib/mesa/Makefile.bsd-wrapper,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile.bsd-wrapper
> --- Makefile.bsd-wrapper  11 Dec 2016 08:53:19 -  1.7
> +++ Makefile.bsd-wrapper  20 Jan 2017 19:33:48 -
> @@ -38,6 +38,12 @@ CONFIGURE_ARGS=--with-dri-drivers=${DR
>  CONFIGURE_ARGS+= USER_CFLAGS="-march=i586" USER_CXXFLAGS="-march=i586"
>  .endif
>  
> +# macppc lacks the __sync_add_and_fetch8 gcc atomic builtin
> +# which is used by the shader cache implementation
> +.if ${MACHINE} == macppc
> +CONFIGURE_ARGS+= --disable-shader-cache
> +.endif
> +
>  .if ${MACHINE} == alpha
>  # -O2 causes gcc ICE on  main/format_pack.c and program/prog_execute.c
>  O1= -fdefer-pop  -fguess-branch-probability -fcprop-registers \
> 
> 
> glxinfo with this patch:
> 
> name of display: :0
> display: :0  screen: 0
> direct rendering: Yes
> server glx vendor string: SGI
> server glx version string: 1.4
> server glx extensions:
> GLX_ARB_create_context, GLX_ARB_create_context_profile, 
> GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
> GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
> GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
> GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
> GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
> GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
> GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
> client glx vendor string: Mesa Project and SGI
> client glx version string: 1.4
> client glx extensions:
> GLX_ARB_create_context, GLX_ARB_create_context_profile, 
> GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
> GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
> GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
> GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
> GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
> GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
> GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
> GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
> GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
> GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
> GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
> GLX_SGI_swap_control, GLX_SGI_video_sync
> GLX version: 1.4
> GLX extensions:
> GLX_ARB_create_context, GLX_ARB_create_context_profile, 
> GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
> GLX_ARB_get_proc_address, GLX_ARB_multisample, 
> GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
> GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
> GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
> GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
> GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
> GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
> GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
> GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
> GLX_SGI_swap_control, GLX_SGI_video_sync
> Extended renderer info (GLX_MESA_query_renderer):
> Vendor: X.Org R300 Project (0x1002)

Re: bgpctl large community parsing issues

[Jonathan Gray]

On Tue, Feb 14, 2017 at 01:04:40PM +0100, Sebastian Benoit wrote:
> Jonathan Gray(j...@jsg.id.au) on 2017.02.14 20:23:51 +1100:
> > On Tue, Feb 14, 2017 at 10:00:17AM +0100, Peter Hessler wrote:
> > > On 2017 Feb 14 (Tue) at 15:39:45 +1100 (+1100), Jonathan Gray wrote:
> > > :The bgpctl parser for large communities makes invalid assumptions about
> > > :the string passed into parse_largecommunity() and also seems to leak
> > > :the memory returned by strdup in the same function.
> > > :
> > > :(gdb) run show rib large-community 1:1
> > > :Starting program: /usr/obj/usr.sbin/bgpctl/bgpctl show rib 
> > > large-community 1:1
> > > :
> > > :Program received signal SIGBUS, Bus error.
> > > :getlargecommunity (
> > > :s=0x9940329f0b9b6d6e )
> > > :at /usr/src/usr.sbin/bgpctl/parser.c:1022
> > > :1022if (strcmp(s, "*") == 0)
> > > :(gdb) p s
> > > :$1 = 0x9940329f0b9b6d6e 
> > > :(gdb) bt
> > > :#0  getlargecommunity (
> > > :s=0x9940329f0b9b6d6e )
> > > :at /usr/src/usr.sbin/bgpctl/parser.c:1022
> > > 
> > > Easy fix.  Pre-initialize the array to NULL, then check if they are set.
> > > Also, check to see if we got too many ':'.
> > > 
> > > OK?
> > 
> > Would strsep be a better fit here?
> 
> 
> while ((p != NULL) && (i < 3)) {
> val = strsep(, ":");
> if (*val == '\0')
> errx(1, "Invalid Large-Community syntax");
> array[i++] = val;
> }
> 
> if ((p != NULL) || !(array[0] && array[1] && array[2]))
> errx(1, "Invalid Large-Community syntax");
> 
> 
> and actually the if (*val == '\0') ...
> can be removed, because that will just result in array[x] being NULL:

What about the memory leak?

Anyway ok jsg@ to commit your version or something like the below.

Index: parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.76
diff -u -p -r1.76 parser.c
--- parser.c13 Feb 2017 14:48:44 -  1.76
+++ parser.c14 Feb 2017 12:16:46 -
@@ -1033,21 +1033,26 @@ int
 parse_largecommunity(const char *word, struct parse_result *r)
 {
struct filter_set *fs;
-   char*p = strdup(word);
-   char*array[3];
+   char*p, *po = strdup(word);
+   char*array[3] = { NULL, NULL, NULL };
+   char*val;
int64_t  as, ld1, ld2;
int  i = 0;
 
-   while (p != NULL) {
-   array[i++] = p;
-   p = strchr(p, ':');
-   if (p)
-   *p++ = 0;
+   p = po;
+   while ((p != NULL) && (i < 3)) {
+   val = strsep(, ":");
+   array[i++] = val;
}
 
+   if ((p != NULL) || !(array[0] && array[1] && array[2]))
+   errx(1, "Invalid Large-Community syntax");
+
as   = getlargecommunity(array[0]);
ld1  = getlargecommunity(array[1]);
ld2  = getlargecommunity(array[2]);
+
+   free(po);
 
if ((fs = calloc(1, sizeof(struct filter_set))) == NULL)
err(1, NULL);

Re: Wandboard can't cold-boot after August 23rd snapshot

[Jonathan Gray]

On Tue, Sep 13, 2016 at 08:17:32PM -0400, Joe Gidi wrote:
> With the latest snapshot, I'm once again able to cold-boot my Wandboard.
> Latest dmesg follows:

Great, thanks for the report and confirming that the commit did
indeed fix this.

> 
> OpenBSD 6.0-current (GENERIC) #45: Tue Sep 13 03:12:56 MDT 2016
> dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC
> real mem  = 2147483648 (2048MB)
> avail mem = 2097598464 (2000MB)
> mainbus0 at root: Wandboard i.MX6 Quad Board
> cpu0 at mainbus0: ARM Cortex A9 R2 rev 10 (ARMv7 core)
> cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
> cpu0: 32KB(32b/l,4way) I-cache, 32KB(32b/l,4way) wr-back D-cache
> cortex0 at mainbus0
> amptimer0 at cortex0: tick rate 396000 KHz
> armliicc0 at cortex0: rtl 7 waymask: 0x000f
> imx0 at mainbus0
> imxccm0 at imx0: imx6 rev 1.5 CPU freq: 792 MHz
> imxiomuxc0 at imx0
> imxocotp0 at imx0
> simplebus0 at mainbus0: "soc"
> ampintc0 at simplebus0 nirq 160
> simplebus1 at simplebus0: "aips-bus"
> simplebus2 at simplebus1: "spba-bus"
> imxuart0 at simplebus2: console
> imxgpio0 at simplebus1
> imxgpio1 at simplebus1
> imxgpio2 at simplebus1
> imxgpio3 at simplebus1
> imxgpio4 at simplebus1
> imxgpio5 at simplebus1
> imxgpio6 at simplebus1
> imxdog0 at simplebus1
> imxtemp0 at simplebus1
> imxgpc0 at simplebus1
> simplebus3 at simplebus0: "aips-bus"
> imxehci0 at simplebus3
> usb0 at imxehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "i.MX6 EHCI root hub" rev
> 2.00/1.00 addr 1
> imxehci1 at simplebus3
> usb1 at imxehci1: USB revision 2.0
> uhub1 at usb1 configuration 1 interface 0 "i.MX6 EHCI root hub" rev
> 2.00/1.00 addr 1
> fec0 at simplebus3
> fec0: address 00:1f:7b:b4:22:5f
> atphy0 at fec0 phy 1: AR8035 10/100/1000 PHY, rev. 4
> imxesdhc0 at simplebus3
> imxesdhc0: 198 MHz base clock
> sdmmc0 at imxesdhc0: 4-bit, mmc high-speed, dma
> imxesdhc1 at simplebus3
> imxesdhc1: 198 MHz base clock
> sdmmc1 at imxesdhc1: 4-bit, mmc high-speed, dma
> imxesdhc2 at simplebus3
> imxesdhc2: 198 MHz base clock
> sdmmc2 at imxesdhc2: 4-bit, mmc high-speed, dma
> imxiic0 at simplebus3
> iic0 at imxiic0
> imxiic1 at simplebus3
> iic1 at imxiic1
> "fsl,sgtl5000" at iic1 addr 0xa not configured
> imxuart1 at simplebus3
> imxahci0 at simplebus0: AHCI 1.3
> scsibus0 at imxahci0: 32 targets
> simplebus4 at mainbus0: "regulators"
> scsibus1 at sdmmc2: 2 targets, initiator 0
> sd0 at scsibus1 targ 1 lun 0:  SCSI2 0/direct fixed
> sd0: 61056MB, 512 bytes/sector, 125042688 sectors
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> boot device: sd0
> root on sd0a (3c6fd48d06a0.a) swap on sd0b dump on sd0b
> WARNING: CHECK AND RESET THE DATE!
> 
> On Mon, September 12, 2016 9:13 pm, Jonathan Gray wrote:
> > As the 23rd is when sys/dev/ofw/fdt.c 1.19
> >
> > 
> > revision 1.19
> > date: 2016/08/23 18:12:09;  author: kettenis;  state: Exp;  lines: +4 -1;
> > commitid: QVPcH04Hp9qQOAgf;
> > Actually make fdt_find_node() return NULL if the node couldn't be found.
> >
> > ok tom@
> > 
> >
> > was committed, the commit matthieu@ reported fec(4) problems on
> > sabre lite with, try a snapshot after sys/arch/armv7/imx/imxiomuxc.c 1.7
> >
> > 
> > revision 1.7
> > date: 2016/09/10 18:33:01;  author: jsg;  state: Exp;  lines: +2 -2;
> > commitid: cFRL5ZcH1S6dcfC1;
> > Correct the path to the iomuxc fdt node so pinctrl setup will run.
> > Noticed when looking into a regression on sabre lite with fec(4)
> > bisected by matthieu@.  This fixes the sabre lite problems with fec and
> > also recent problems with the i2c rtc on cubox.
> >
> > ok kettenis@
> > 
> >
> > On Mon, Sep 12, 2016 at 08:51:46PM -0400, Joe Gidi wrote:
> >> My Wandboard Quad is unable to successfully cold-boot with any snapshot
> >> after August 23rd. I can successfully reboot into later kernels after an
> >> initial boot with the 8/23 kernel, but on cold boot they hang at this
> >> line:
> >>
> >> simplebus5 at mainbus0: "regulators"
> >>
> >> It appears something is no longer being initialized properly during the
> >> boot process.
> >>
> >> Full dmesg of the last working snapshot kernel and 'eeprom -p' output
> >> are
> >> attached. Please let me know if I can provide any further i

Re: Wandboard can't cold-boot after August 23rd snapshot

[Jonathan Gray]

As the 23rd is when sys/dev/ofw/fdt.c 1.19


revision 1.19
date: 2016/08/23 18:12:09;  author: kettenis;  state: Exp;  lines: +4 -1;  
commitid: QVPcH04Hp9qQOAgf;
Actually make fdt_find_node() return NULL if the node couldn't be found.

ok tom@


was committed, the commit matthieu@ reported fec(4) problems on
sabre lite with, try a snapshot after sys/arch/armv7/imx/imxiomuxc.c 1.7


revision 1.7
date: 2016/09/10 18:33:01;  author: jsg;  state: Exp;  lines: +2 -2;  commitid: 
cFRL5ZcH1S6dcfC1;
Correct the path to the iomuxc fdt node so pinctrl setup will run.
Noticed when looking into a regression on sabre lite with fec(4)
bisected by matthieu@.  This fixes the sabre lite problems with fec and
also recent problems with the i2c rtc on cubox.

ok kettenis@


On Mon, Sep 12, 2016 at 08:51:46PM -0400, Joe Gidi wrote:
> My Wandboard Quad is unable to successfully cold-boot with any snapshot
> after August 23rd. I can successfully reboot into later kernels after an
> initial boot with the 8/23 kernel, but on cold boot they hang at this
> line:
> 
> simplebus5 at mainbus0: "regulators"
> 
> It appears something is no longer being initialized properly during the
> boot process.
> 
> Full dmesg of the last working snapshot kernel and 'eeprom -p' output are
> attached. Please let me know if I can provide any further information.
> 
> -- 
> Joe Gidi
> j...@entropicblur.com
> 
> "You cannot buy skill." -- Ross Seyfried

> OpenBSD 6.0-current (GENERIC) #32: Tue Aug 23 03:13:41 MDT 2016
> dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC
> real mem  = 2147483648 (2048MB)
> avail mem = 2097623040 (2000MB)
> mainbus0 at root: Wandboard i.MX6 Quad Board
> cpu0 at mainbus0: ARM Cortex A9 R2 rev 10 (ARMv7 core)
> cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
> cpu0: 32KB(32b/l,4way) I-cache, 32KB(32b/l,4way) wr-back D-cache
> cortex0 at mainbus0
> amptimer0 at cortex0: tick rate 396000 KHz
> armliicc0 at cortex0: rtl 7 waymask: 0x000f
> imx0 at mainbus0
> imxccm0 at imx0: imx6 rev 1.5 CPU freq: 792 MHz
> imxiomuxc0 at imx0
> imxocotp0 at imx0
> simplebus0 at mainbus0: "soc"
> ampintc0 at simplebus0 nirq 160
> simplebus1 at simplebus0: "aips-bus"
> simplebus2 at simplebus1: "spba-bus"
> imxuart0 at simplebus2: console
> imxgpio0 at simplebus1
> imxgpio1 at simplebus1
> imxgpio2 at simplebus1
> imxgpio3 at simplebus1
> imxgpio4 at simplebus1
> imxgpio5 at simplebus1
> imxgpio6 at simplebus1
> imxdog0 at simplebus1
> imxtemp0 at simplebus1
> imxgpc0 at simplebus1
> simplebus3 at simplebus0: "aips-bus"
> imxehci0 at simplebus3
> usb0 at imxehci0: USB revision 2.0
> uhub0 at usb0 "i.MX6 EHCI root hub" rev 2.00/1.00 addr 1
> imxehci1 at simplebus3
> usb1 at imxehci1: USB revision 2.0
> uhub1 at usb1 "i.MX6 EHCI root hub" rev 2.00/1.00 addr 1
> fec0 at simplebus3
> fec0: address 00:1f:7b:b4:22:5f
> atphy0 at fec0 phy 1: AR8035 10/100/1000 PHY, rev. 4
> imxesdhc0 at simplebus3
> imxesdhc0: 198 MHz base clock
> sdmmc0 at imxesdhc0: 4-bit, mmc high-speed, dma
> imxesdhc1 at simplebus3
> imxesdhc1: 198 MHz base clock
> sdmmc1 at imxesdhc1: 4-bit, mmc high-speed, dma
> imxesdhc2 at simplebus3
> imxesdhc2: 198 MHz base clock
> sdmmc2 at imxesdhc2: 4-bit, mmc high-speed, dma
> imxiic0 at simplebus3
> iic0 at imxiic0
> imxiic1 at simplebus3
> iic1 at imxiic1
> "fsl,sgtl5000" at iic1 addr 0xa not configured
> imxuart1 at simplebus3
> imxahci0 at simplebus0: AHCI 1.3
> scsibus0 at imxahci0: 32 targets
> simplebus4 at mainbus0: "regulators"
> scsibus1 at sdmmc2: 2 targets, initiator 0
> sd0 at scsibus1 targ 1 lun 0:  SCSI2 0/direct fixed
> sd0: 61056MB, 512 bytes/sector, 125042688 sectors
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> boot device: sd0
> root on sd0a (3c6fd48d06a0.a) swap on sd0b dump on sd0b
> WARNING: CHECK AND RESET THE DATE!

> Node 0x48
> name: ''
> #address-cells: 0001
> #size-cells: 0001
> model: 'Wandboard i.MX6 Quad Board'
> compatible: 'wand,imx6q-wandboard' + 'fsl,imx6q'
> 
> Node 0xc4
> name: 'chosen'
> openbsd,bootduid: 3c6f.d48d06a0
> bootargs: 'sd0a:/bsd'
> 
> Node 0x100
> name: 'aliases'
> ethernet0: '/soc/aips-bus@0210/ethernet@02188000'
> can0: '/soc/aips-bus@0200/flexcan@0209'
> can1: '/soc/aips-bus@0200/flexcan@02094000'
> gpio0: '/soc/aips-bus@0200/gpio@0209c000'
> gpio1: '/soc/aips-bus@0200/gpio@020a'
> gpio2: '/soc/aips-bus@0200/gpio@020a4000'
> gpio3: '/soc/aips-bus@0200/gpio@020a8000'
> gpio4: '/soc/aips-bus@0200/gpio@020ac000'
> gpio5: '/soc/aips-bus@0200/gpio@020b'
> gpio6: '/soc/aips-bus@0200/gpio@020b4000'
> i2c0: '/soc/aips-bus@0210/i2c@021a'
> i2c1: 

Re: External monitors connected to docking station not detected properly on Intel HD Graphics 5500

[Jonathan Gray]

It very much sounds like you have a docking station that requires
support for displayport MST (Multi Stream Transport).

That was first available in Linux 3.17 where as the inteldrm
code in the tree is currently based on Linux 3.14.

On Sun, Sep 25, 2016 at 11:01:20PM +0200, S??awomir Gonet wrote:
> Good evening!
> 
> After few tries, I am finally sending bug-maybe-feature report:
> 
> * Software:
> - OpenBSD from most recent snapshot (problem exists)
> - OpenBSD from most recent snapshot with -current kernel, built with
>   DEBUGDRM (problem exists)
> 
> * Hardware:
> - Dell E7450
> - Dell E-Port Plus Replicator
> - 2?? BENQ G2420HD connected to Replicator via DVI-DVI cable
> 
> * Issue:
> External monitors, connected to two separate DVI ports on Port
> Replicator are cloned (they display exactly the same image) and are
> detected by `xrandr' as a single monitor (1920x1080, DP-1). In total,
> only two displays are being detected: eDP1 (internal laptop display) and
> DP-1 (both DVI-connected displays).
> 
> * Clues?:
> On the same machine with Linux 4.8.0-rc7 `xrandr' detects following
> displays:
> eDP1 (internal)
> DP1 (disconnected)
> DP1-1 (first DVI display)
> DP1-2 (second DPI display)
> DP1-3 (disconnected)
> DP2 (disconnected)
> HDMI1 (disconnected)
> HDMI2 (disconnected)
> 
> It seems like OpenBSD has no support/for any other reason is not
> detecting those ???nested??? DP's - DP1-1, -2 and -3 and instead showing
> "merged" DP1 as connected, with both displays assigned to it.
> 
> * Attachments:
> - From OpenBSD-current:
>   - /var/log/messages
>   - Xorg.0.log
>   - output of `xrandr --verbose'
> - From Linux 4.8.0-rc7:
>   - output of `dmesg'
>   - Xorg.0.log
>   - output of `xrandr --verbose'
> 
> Sorry for not sending this bug report using sendbug(1) - by the time I
> am writing it, it was impossible for me to boot into OpenBSD anytime
> soon by multiple reasons.
> 
> Best regards,
> Slawek
> 

Re: armv7 panic

[Jonathan Gray]

On Sun, Oct 16, 2016 at 07:02:55PM +1100, Jonathan Gray wrote:
> On Sun, Oct 16, 2016 at 12:45:36AM -0700, Philip Guenther wrote:
> > On Sun, 16 Oct 2016, Matthieu Herrb wrote:
> > > my Sabre Lite board paniced during the night for the 1st time in several 
> > > month. Here is the information I collected:
> > > 
> > > kernel diagnostic assertion "p->p_wchan == NULL" failed: file 
> > > "/usr/src/sys/ker
> > > n/kern_sched.c", line 333
> > 
> > This means a thread was somehow in the CPU's run-queue...but had a wait 
> > channel as if it was waiting to be woken.
> > 
> > ...
> > > ddb> ps
> > >TID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
> > ...
> > >  86009  0  0  0  2  0x40014200  miiautidle0
> > 
> > Bingo: S=2 --> SRUN!  Or in this case, WTF!?  idle threads must *NEVER* 
> > have a wait channel.  That smells like someone called tsleep() from an 
> > interrupt and arm doesn't have the low-level machinery to detect and panic 
> > at the call.
> > 
> > mii_phy_auto() is the source of the "miiaut" wait channel; are the mii 
> > flags not set right that it's taking the tsleep() path instead of 
> > timeout_* path?
> 
> Looks like.  I don't see a reason why anything using interrupts should
> set that flag.  So fec/sxie seem to get this wrong.
> 
> arch/armv7/imx/if_fec.c:mii->mii_flags = MIIF_AUTOTSLEEP;
> arch/armv7/sunxi/sxie.c:mii->mii_flags = MIIF_AUTOTSLEEP;
> dev/usb/if_aue.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
> dev/usb/if_axe.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
> dev/usb/if_mos.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
> dev/usb/if_udav.c:  mii->mii_flags = MIIF_AUTOTSLEEP;
> dev/usb/if_url.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
> dev/usb/if_smsc.c:  mii->mii_flags = MIIF_AUTOTSLEEP;
> dev/usb/if_axen.c:  mii->mii_flags = MIIF_AUTOTSLEEP;
> dev/usb/if_ure.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
> 

I have no hardware with sxie, so here is just the fec diff.

Index: if_fec.c
===
RCS file: /cvs/src/sys/arch/armv7/imx/if_fec.c,v
retrieving revision 1.18
diff -u -p -r1.18 if_fec.c
--- if_fec.c22 Sep 2016 12:43:22 -  1.18
+++ if_fec.c17 Oct 2016 00:46:49 -
@@ -413,7 +413,6 @@ fec_attach(struct device *parent, struct
mii->mii_readreg = fec_miibus_readreg;
mii->mii_writereg = fec_miibus_writereg;
mii->mii_statchg = fec_miibus_statchg;
-   mii->mii_flags = MIIF_AUTOTSLEEP;
 
ifmedia_init(>mii_media, 0, fec_ifmedia_upd, fec_ifmedia_sts);
mii_attach(self, mii, 0x, MII_PHY_ANY, MII_OFFSET_ANY, 0);

Re: armv7 panic

[Jonathan Gray]

On Sun, Oct 16, 2016 at 12:45:36AM -0700, Philip Guenther wrote:
> On Sun, 16 Oct 2016, Matthieu Herrb wrote:
> > my Sabre Lite board paniced during the night for the 1st time in several 
> > month. Here is the information I collected:
> > 
> > kernel diagnostic assertion "p->p_wchan == NULL" failed: file 
> > "/usr/src/sys/ker
> > n/kern_sched.c", line 333
> 
> This means a thread was somehow in the CPU's run-queue...but had a wait 
> channel as if it was waiting to be woken.
> 
> ...
> > ddb> ps
> >TID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
> ...
> >  86009  0  0  0  2  0x40014200  miiautidle0
> 
> Bingo: S=2 --> SRUN!  Or in this case, WTF!?  idle threads must *NEVER* 
> have a wait channel.  That smells like someone called tsleep() from an 
> interrupt and arm doesn't have the low-level machinery to detect and panic 
> at the call.
> 
> mii_phy_auto() is the source of the "miiaut" wait channel; are the mii 
> flags not set right that it's taking the tsleep() path instead of 
> timeout_* path?

Looks like.  I don't see a reason why anything using interrupts should
set that flag.  So fec/sxie seem to get this wrong.

arch/armv7/imx/if_fec.c:mii->mii_flags = MIIF_AUTOTSLEEP;
arch/armv7/sunxi/sxie.c:mii->mii_flags = MIIF_AUTOTSLEEP;
dev/usb/if_aue.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
dev/usb/if_axe.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
dev/usb/if_mos.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
dev/usb/if_udav.c:  mii->mii_flags = MIIF_AUTOTSLEEP;
dev/usb/if_url.c:   mii->mii_flags = MIIF_AUTOTSLEEP;
dev/usb/if_smsc.c:  mii->mii_flags = MIIF_AUTOTSLEEP;
dev/usb/if_axen.c:  mii->mii_flags = MIIF_AUTOTSLEEP;
dev/usb/if_ure.c:   mii->mii_flags = MIIF_AUTOTSLEEP;

Re: miniroot-panda-61.fs doesn't boot since March 8

[Jonathan Gray]

On Sat, Mar 25, 2017 at 06:29:32PM +, Florian Obser wrote:
> 
> ... it just sits here forever.
> 
> Using hostserver's archive I bisected miniroots and found that
> this one works:
>   
> https://ftp.hostserver.de/archive/2017-03-07-0105/snapshots/armv7/miniroot-panda-61.fs
>   OpenBSD 6.1-beta (RAMDISK) #52: Sun Mar  5 15:11:37 MST 2017
> 
> U-Boot SPL 2016.11 (Dec 24 2016 - 09:08:50)
> OMAP4460-GP ES1.1
> Trying to boot from MMC1
> SPL: Please implement spl_start_uboot() for your board
> SPL: Direct Linux boot not active!
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2016.11 (Dec 24 2016 - 09:08:50 -0700)
> 
> CPU  : OMAP4460-GP ES1.1
> Board: OMAP4 Panda
> I2C:   ready
> DRAM:  1 GiB
> MMC:   OMAP SD/MMC: 0
> reading uboot.env
> 
> ** Unable to read "uboot.env" from mmc0:1 **
> Using default environment
> 
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc0 is current device
> SD/MMC found on device 0
> reading boot.scr
> ** Unable to read file boot.scr **
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> reading /omap4-panda-es.dtb
> 58423 bytes read in 8 ms (7 MiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> reading efi/boot/bootarm.efi
> 64684 bytes read in 10 ms (6.2 MiB/s)
> ## Starting EFI application at 0x8200 ...
> CACHE: Misaligned operation at range [bcf36000, bcf45cac]
> Scanning disks on usb...
> Scanning disks on mmc...
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 5 disks
> >> OpenBSD/armv7 BOOTARM 0.5
> boot> 
> cannot open sd0a:/etc/random.seed: No such file or directory
> booting sd0a:/bsd: 2168072+7992960+438796 [80+305024+146122]=0xa90cc4
> 
> OpenBSD/armv7 booting ...
> arg0 0xc0d90cc4 arg1 0xae7 arg2 0x8800
> Allocating page tables
> freestart = 0x80d91000, free_pages = 258671 (0x0003f26f)
> [...]
> 
> and this one is busted:
>   
> https://ftp.hostserver.de/archive/2017-03-09-0105/snapshots/armv7/miniroot-panda-61.fs
>   OpenBSD 6.1-beta (RAMDISK) #54: Wed Mar  8 02:59:20 MST 2017
> 
> 
> U-Boot SPL 2017.01 (Feb 04 2017 - 18:38:04)
> OMAP4460-GP ES1.1
> Trying to boot from MMC1SPL: Please implement spl_start_uboot() for your board
> SPL: Direct Linux boot not active!
> reading u-boot.img
> reading u-boot.img
> 
> [and then nothing]
> 
> Using a working miniroot I can install the system and then use bsd.rd
> to upgrade the system past the breakage.

The u-boot port has had newer versions for some time now.  If you
install the u-boot-arm-2017.03 package from the amd64 packages
and copy
/usr/local/share/u-boot/omap4_panda/{MLO,u-boot.img}
to the msdos partition on the miniroot does that change anything?

Should look like:

U-Boot SPL 2017.03 (Mar 14 2017 - 15:01:11)
OMAP4460-GP ES1.1
Trying to boot from MMC1
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
reading u-boot.img
reading u-boot.img


U-Boot 2017.03 (Mar 14 2017 - 15:01:11 +1100)

CPU  : OMAP4460-GP ES1.1
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
MMC:   OMAP SD/MMC: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

Net:   No ethernet found.
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
** Unable to read file uEnv.txt **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /omap4-panda-es.dtb
58423 bytes read in 6 ms (9.3 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
64684 bytes read in 8 ms (7.7 MiB/s)
## Starting EFI application at 8200 ...
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 5 disks
>> OpenBSD/armv7 BOOTARM 0.5

> 
> Thanks,
> Florian
> 
> U-Boot SPL 2017.01 (Feb 04 2017 - 18:38:04)
> OMAP4460-GP ES1.1
> Trying to boot from MMC1SPL: Please implement spl_start_uboot() for your board
> SPL: Direct Linux boot not active!
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2017.01 (Feb 04 2017 - 18:38:04 -0700)
> 
> CPU  : OMAP4460-GP ES1.1
> Board: OMAP4 Panda
> I2C:   ready
> DRAM:  1 GiB
> MMC:   OMAP SD/MMC: 0
> reading uboot.env
> 
> ** Unable to read "uboot.env" from mmc0:1 **
> Using default environment
> 
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc0 is current device
> SD/MMC found on device 0
> reading boot.scr
> ** Unable to read file boot.scr **
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> reading /omap4-panda-es.dtb
> 58423 bytes read in 7 ms (8 MiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> reading efi/boot/bootarm.efi
> 64684 bytes read in 9 ms 

Re: Problem in installing: cannot recognize disk

[Jonathan Gray]

On Thu, Apr 13, 2017 at 08:18:00AM -0600, Todd C. Miller wrote:
> The problem is that the sdmmc driver is not present in the RAMDISK
> kernel, ony in GENERIC.  We have sdmmc in RAMDISK for arm and octeon.
> It should probably be added to amd64 (and i386?) RAMDISK as well.
> 
> Without the device in the RAMDISK kernel you won't be able to
> install.
> 
>  - todd
> 

It was added some time ago including 5.9.

/sys/arch/i386/conf/RAMDISK_CD:sdhc*at pci? # SD 
Host Controller
/sys/arch/i386/conf/RAMDISK_CD:sdmmc*   at sdhc?# 
SD/MMC bus
/sys/arch/i386/conf/RAMDISK_CD:sdmmc*   at rtsx?# 
SD/MMC bus
/sys/arch/amd64/conf/RAMDISK_CD:sdhc*   at acpi?
/sys/arch/amd64/conf/RAMDISK_CD:sdhc*   at pci? # SD 
Host Controller
/sys/arch/amd64/conf/RAMDISK_CD:sdmmc*  at sdhc?# 
SD/MMC bus
/sys/arch/amd64/conf/RAMDISK_CD:sdmmc*  at rtsx?# 
SD/MMC bus

Re: Problem in installing: cannot recognize disk

[Jonathan Gray]

sdmmc ends up attaching sd.

sdhc -> sdmmc -> scsibus -> sd

The submitter should try a release that isn't a year old and provide
details of which particular stream model this is as the branding spans
multiple generations of hardware with different variants.

On Thu, Apr 13, 2017 at 02:36:46PM +, Robert Peichaer wrote:
> This needs tweaking in the installer script. Right now, without looking, I'd 
> say only sd and wd devices are recognised. 
> 
> 
> 
> Am 13. April 2017 16:29:48 MESZ schrieb Jonathan Gray <j...@jsg.id.au>:
> >On Thu, Apr 13, 2017 at 08:18:00AM -0600, Todd C. Miller wrote:
> >> The problem is that the sdmmc driver is not present in the RAMDISK
> >> kernel, ony in GENERIC.  We have sdmmc in RAMDISK for arm and octeon.
> >> It should probably be added to amd64 (and i386?) RAMDISK as well.
> >> 
> >> Without the device in the RAMDISK kernel you won't be able to
> >> install.
> >> 
> >>  - todd
> >> 
> >
> >It was added some time ago including 5.9.
> >
> >/sys/arch/i386/conf/RAMDISK_CD:sdhc* at pci? # SD 
> >Host Controller
> >/sys/arch/i386/conf/RAMDISK_CD:sdmmc*at sdhc?
> ># SD/MMC bus
> >/sys/arch/i386/conf/RAMDISK_CD:sdmmc*at rtsx?
> ># SD/MMC bus
> >/sys/arch/amd64/conf/RAMDISK_CD:sdhc*at acpi?
> >/sys/arch/amd64/conf/RAMDISK_CD:sdhc*at pci? 
> ># SD Host Controller
> >/sys/arch/amd64/conf/RAMDISK_CD:sdmmc*   at sdhc?
> ># SD/MMC bus
> >/sys/arch/amd64/conf/RAMDISK_CD:sdmmc*   at rtsx?
> ># SD/MMC bus

Re: armv7/sunxi/sxie

[Jonathan Gray]

On Tue, Jul 25, 2017 at 05:29:06AM +0300, Artturi Alm wrote:
> On Mon, Jul 24, 2017 at 10:51:12PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 24 Jul 2017 23:07:00 +0300
> > > From: Artturi Alm 
> > > 
> > > On Sun, Jul 23, 2017 at 07:45:53PM +0200, Mark Kettenis wrote:
> > > > > Date: Sat, 22 Jul 2017 11:21:31 +0300
> > > > > From: Artturi Alm 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > anyone else having issues with sxie? w/bsd.rd from latest snapshot
> > > > > it was unable to get ip from dhcpd even.
> > > > > 
> > > > > this is what it does look like at the other side:
> > > > > 
> > > > > 11:01:15.170089 e6:29:5b:e9:e6:29 5b:e9:e6:29:5b:e9 5be9 342: 
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629
> > > > > 11:01:15.170353 e6:29:5b:e9:e6:29 5b:e9:e6:29:5b:e9 5be9 342: 
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629 5be9 e629 5be9 e629 5be9
> > > > >  e629 5be9 e629
> > > > > 
> > > > > just to make sure there was nothing physically wrong in my setup,
> > > > > i attached usb-ethernet(axen), and got the ip like expected, this
> > > > > was in a row to the earlier garbage w/o rebooting in between.
> > > > > 
> > > > > i haven't used it for like a year, so got no time frame when this
> > > > > has appeared, anyone w/ideas?
> > > > > -Artturi
> > > > 
> > > > I'm upgrading my A10s-ALinuXino-Micro over sxie(4), so the driver
> > > > defenitely still works for me.
> > > > 
> > > 
> > > That's good. Do you know if u-boot did init it? In my case i'm quite
> > > sure the u-boot i used did not, and i'm now guessing just by quick
> > > look at sxie.c, that iirc. there was some ugly hack somewhere to enable
> > > the use of some sram section in memory for the emac, and since i saw no
> > > trace of that hack in sxie.c, maybe it was elsewhere and got cleaned up?
> > > meaning sxie would rely on u-boot to work? i'll test when i have a free
> > > sd-card, will let you know.
> > 
> > Yes, U-Boot initializes the network interface.
> 
> Regression in /usr/local/share/u-boot/Cubieboard/u-boot-sunxi-with-spl.bin,
> w/2017.03 it is working:
> 
> U-Boot SPL 2017.03 (Apr 03 2017 - 12:27:12)
> DRAM: 1024 MiB
> CPU: 100800Hz, AXI/AHB/APB: 3/2/2
> Trying to boot from MMC1
> 
> 
> U-Boot 2017.03 (Apr 03 2017 - 12:27:12 -0600) Allwinner Technology
> 
> CPU:   Allwinner A10 (SUN4I)
> Model: Cubietech Cubieboard
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> Net:   eth0: ethernet@01c0b000
> 
> 
> and with current(.05) it doesn't:
> 
> U-Boot SPL 2017.05 (Jul 11 2017 - 16:35:33)
> DRAM: 1024 MiB
> CPU: 100800Hz, AXI/AHB/APB: 3/2/2
> Trying to boot from MMC1
> 
> 
> U-Boot 2017.05 (Jul 11 2017 - 16:35:33 -0600) Allwinner Technology
> 
> CPU:   Allwinner A10 (SUN4I)
> Model: Cubietech Cubieboard
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> SCSI:  SATA link 0 timeout.
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> Net:   No ethernet found.
> 
> 
> i guess that means, we either hope u-boot 2017.07 will fix this, or add
> the likely missing handling of "allwinner,sun4i-a10-sram-a3-a4"-compatible ?
> this is such a minor thing, that i hope you won't waste time on this anymore
> than deciding what should be done, and maybe ease my curiosity if the success
> you've had was w/2017.05 or not? :)
> 
> i cc'ed maintaineri, as i failed to build .07, and in case he would have any
> news about progress w/upgrade to it? or if the u-boot changelog for between
> .05 and .07 has been considered unworthy of the port-update?
> -Artturi

There is a 2017.07 update on ports@ that can't go in unless someone
tracks down the rpi3 problem.

Re: ikectl can't revoke certs

[Jonathan Gray]

On Wed, Jul 05, 2017 at 04:55:34PM -0700, jmo...@nodomain.net wrote:
> >Synopsis:ikectl can't revoke certs
> >Category:system
> >Environment:
>   System  : OpenBSD 6.1
>   Details : OpenBSD 6.1 (GENERIC.MP) #291: Sat Apr  1 13:53:41 MDT 
> 2017
>
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.i386
>   Machine : i386
> >Description:
> When attempting to use ikectl to revoke a cert the following error is 
> produced:
> Using configuration from /etc/ssl/testca/ca-revoke-ssl.cnf
> error on line 27 of config file '/etc/ssl/testca/ca-revoke-ssl.cnf'
> 2332407120:error:0EFFF068:configuration file 
> routines:CRYPTO_internal:variable has no 
> value:/usr/src/lib/libcrypto/conf/conf_def.c:563:line 27
> Using configuration from /etc/ssl/testca/ca-revoke-ssl.cnf
> error on line 27 of config file '/etc/ssl/testca/ca-revoke-ssl.cnf'
> 2170843792:error:0EFFF068:configuration file 
> routines:CRYPTO_internal:variable has no 
> value:/usr/src/lib/libcrypto/conf/conf_def.c:563:line 27
> 
> >How-To-Repeat:
> ikectl ca testca create
> ikectl ca testca install
> ikectl ca testca certificate foo.domain.com create (use defaults)
> ikectl ca testca certificate foo.domain.com revoke
> 
> >Fix:
> N/A

ikectl changes made in -current in May should have fixed this.

Re: [RPI3] Latest minirootfs

[Jonathan Gray]

On Mon, Jul 31, 2017 at 11:15:52PM +, R0me0 *** wrote:
> I wrote minirootfs as usual directly to usb flash drive
> 
> minirootfs61.fs31-Jul-2017 03:11  22020096
> 
> 
> 
> U-Boot> boot
> Card did not respond to voltage select!
> mmc_init: -95, time 24
> 
> USB device 0:
>Device 0: Vendor: Kingston Rev: 1.00 Prod: DataTraveler 2.0
>Type: Removable Hard Disk
>Capacity: 14762.4 MB = 14.4 GB (30233588 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 75732 bytes read in 75 ms (985.4 KiB/s)
> ## Starting EFI application at 0100 ...
> Card did not respond to voltage select!
> mmc_init: -95, time 24
> Found 0 disks
> BS->LocateHandle() returns 0
> "Synchronous Abort" handler, esr 0x0200
> ELR: 39b3ecfc
> LR:  39b421ec
> x0 :  x1 : 3afec000
> x2 : 0002 x3 : 003f
> x4 : 0010 x5 : 
> x6 : 3af96558 x7 : 39b3efa8
> x8 : 39b4c8ac x9 : 39b3e39c
> x10: 3ab4fa70 x11: 3ab4faf0
> x12: 3ab4fbc0 x13: 39b4d850
> x14: 3ab4fd6c x15: 
> x16: 4110 x17: ad7bd9a555f85ec4
> x18:  x19: 39b4db12
> x20: 39b4c920 x21: 0001
> x22: 39a3d030 x23: 39b4cb00
> x24: 39b4c920 x25: 0200
> x26: 3afa76b0 x27: 39b3e148
> x28:  x29: 3ab4fcd0
> 
> Resetting CPU ...
> 
> resetting ...

That is with only a USB drive?  You've previously blown the
fuse by setting the config.txt value and no SD card is present?

Try with a newer U-Boot
http://jsg.id.au/openbsd/u-boot.bin
SHA256 (u-boot.bin) = 
342af5b0331c502a0b1c64a96b2b7fc915b516567cc3bd293a5078ea493a6e49

Mount the msdos fs /dev/sdNi and copy u-boot.bin over the existing one.

The U-Boot build is based on the latest development version and
in particular includes:

commit 70bfcdc6bb6f969babd69efc49e1dc7a1faeca54
Author: xypron.g...@gmx.de 
Date:   Tue Jun 20 19:10:27 2017 +

efi_loader: disk: iterate only over valid block devices

The efi_loader currently stops iterating over the available
block devices stopping at the first device that fails.
This may imply that no block device is found.

With the patch efi_loader only iterates over valid devices.
...

Re: [RPI3] Latest minirootfs

[Jonathan Gray]

On Tue, Aug 01, 2017 at 06:40:26AM -0300, R0me0 *** wrote:
> Hello, Jonathan!
> 
> Copying the provided u-boot.bin worked :)
> 
> Yes, the issue just affects USB DRIVE.
> 
> Never touched config.txt.
> 
> The procedures were: dd if=minirootfs61.fs of=(USB drive or sd-card )
>  bs=1M
> 
> If I use sd-card, then I make sure that USB drive is not bootable and is
> empty and use both.
> 
> If USB Drive, just itself.
> 
> Thank you so much!
> 

The arm64 snapshot that went up today uses U-Boot 2017.09-rc1 which also
includes the recent U-Boot efi_loader changes.

Re: httpd crashes with SIGSEGV when using "block return 401"

[Jonathan Gray]

On Sun, May 14, 2017 at 10:05:37AM +0200, Jurjen Oskam wrote:
> Hi,
> 
> httpd crashes with a segmentation violation when servicing requests with
> the following (minimal) config file:
> 
> server "default" {
> listen on * port 80
> block return 401
> }
> 
> It starts up OK, but on the first request this happens:
> 
> # httpd -d -v -v
> startup
> server_privinit: adding server default
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> socket_rlimit: max open files 1024
> server_launch: configuring server default
> server_launch: running server default
> server_launch: configuring server default
> server_launch: running server default
> server_launch: configuring server default
> server_launch: running server default
> logger exiting, pid 88769
> lost child: pid 18355 terminated; signal 11
> server exiting, pid 90619
> server exiting, pid 37360
> parent terminating, pid 91332
> 
> 
> Altering the listening address or port results in the same symptom.
> Using other HTTP return codes (I've tried 402, 403, 404 and 405) does
> *not* result in a crash; these seem to work as expected.
> 
> This happens on OpenBSD 6.0, 6.1 as well as -current.
> 
> If I can do anything to diagnose/fix this, please let me know via a
> Cc:.
> 
> Regards,
> 
> Jurjen Oskam

Thanks for the report.  The crash occurs when stravis(3) is passed a
NULL msg value.

Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.116
diff -u -p -r1.116 server_http.c
--- server_http.c   16 Mar 2017 10:18:11 -  1.116
+++ server_http.c   14 May 2017 08:33:43 -
@@ -887,6 +887,8 @@ server_abort_http(struct client *clt, un
msg = buf;
break;
case 401:
+   if (msg == NULL)
+   break;
if (stravis(, msg, VIS_DQ) == -1) {
code = 500;
extraheader = NULL;
@@ -898,6 +900,8 @@ server_abort_http(struct client *clt, un
}
break;
case 416:
+   if (msg == NULL)
+   break;
if (asprintf(,
"Content-Range: %s\r\n", msg) == -1) {
code = 500;

Re: ARM64 Panic

[Jonathan Gray]

On Tue, Jun 27, 2017 at 12:04:26AM +0100, Stuart Henderson wrote:
> On 2017/06/26 09:30, R0me0 *** wrote:
> > Hello guys,
> > After Installed a snapshot from one week ago.
> 
> A problem with the dwctwo(4) driver which could result in this
> was fixed on 2017/06/20. I'm unsure whether this made it into a
> snapshot yet, but if you're not already running "OpenBSD
> 6.1-current (GENERIC) #0: Wed Jun 21 17:47:53 AEST 2017" you
> should update to at least that version, if it still occurs then
> you could build a new kernel or wait for a newer snap to be
> built.
> 

It does include it.  There will be no new snapshots until someone has
time to look into making lld handle the linker script the kernel now
requires.  This also means you can't build your own kernel till then.

httpd violates pledge with passworded private key

[Jonathan Gray]

when using a server.key with a passphrase, ie

openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048

server "default" {
listen on * port 80
listen on * tls port 443
directory { auto index }
}

types {
include "/usr/share/misc/mime.types"
text/plain  "log"
}

httpd(96368): syscall 5 "wpath"
httpd(87490): syscall 5 "wpath"
httpd(30649): syscall 5 "wpath"

#0  0x022b9356bc0a in _thread_sys_open () at {standard input}:5
#1  0x022b935d6299 in *_libc_open_cancel (path=Variable "path" is not 
available.
) at /usr/src/lib/libc/sys/w_open.c:36
#2  0x022b9359a642 in *_libc_fopen (file=0x22b2db5c9be "/dev/tty", 
mode=Variable "mode" is not available.
) at /usr/src/lib/libc/stdio/fopen.c:54
#3  0x022b2d92d26f in open_console (ui=Variable "ui" is not available.
) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304
#4  0x022b2d9e65da in UI_process (ui=0x22b217187c0) at 
/usr/src/lib/libcrypto/ui/ui_lib.c:455
#5  0x022b2d954b8f in EVP_read_pw_string_min (buf=0x7f7f19f0 "", min=4, 
len=Variable "len" is not available.
) at /usr/src/lib/libcrypto/evp/evp_key.c:117
#6  0x022b2d9dc018 in PEM_def_callback (buf=0x7f7f19f0 "", num=1024, 
w=0, key=Variable "key" is not available.
) at /usr/src/lib/libcrypto/pem/pem_lib.c:113
#7  0x022b2d9dc2c4 in PEM_do_header (cipher=0x7f7f1ec0,
data=0x22bc09b6000 
"d\vQ\212\222\035\006\227\221\004.H\033\225Y\nmKql}1i\034??Pz\033a@??\232??\220N??\037??APfVs\005r\226??\030\2273TW\t\201??\217??+\2033?^\226D\2340z:-+g\226*??\034",
 plen=0x7f7f1ee8, callback=Variable "callback" is not available.
)
at /usr/src/lib/libcrypto/pem/pem_lib.c:447
#8  0x022b2d9dc64c in PEM_bytes_read_bio (pdata=0x7f7f1f68, 
plen=0x7f7f1f60, pnm=0x7f7f1f78,
name=0x22b2db5dcb5 "ANY PRIVATE KEY", bp=0x22b514c9e00, cb=0, u=0x0) at 
/usr/src/lib/libcrypto/pem/pem_lib.c:296
#9  0x022b2d93112f in PEM_read_bio_PrivateKey (bp=Variable "bp" is not 
available.
) at /usr/src/lib/libcrypto/pem/pem_pkey.c:90
#10 0x022b6ef43b62 in tls_configure_ssl_keypair (ctx=0x22b514c9e80, 
ssl_ctx=0x22bcc86ce00, keypair=0x22b9294df00, required=Variable "required" is 
not available.
)
at /usr/src/lib/libtls/tls.c:347
#11 0x022b6ef42135 in tls_configure_server_ssl (ctx=0x22b514c9e80, 
ssl_ctx=0x22b514c9eb8, keypair=0x22b9294df00)
at /usr/src/lib/libtls/tls_server.c:261
#12 0x022b6ef427a1 in tls_configure_server (ctx=0x22b514c9e80) at 
/usr/src/lib/libtls/tls_server.c:361
#13 0x022920b1413c in server_tls_init (srv=0x22bd885d000) at 
/usr/src/usr.sbin/httpd/server.c:297
#14 0x022920b1431c in server_launch () at 
/usr/src/usr.sbin/httpd/server.c:359
#15 0x022920b16759 in server_dispatch_parent (fd=3, p=0x22920d301c0, 
imsg=0x7f7f25a0) at /usr/src/usr.sbin/httpd/server.c:1289
#16 0x022920b12f99 in proc_dispatch (fd=3, event=2, arg=0x22c1281) at 
/usr/src/usr.sbin/httpd/proc.c:652
#17 0x022c070a0808 in event_base_loop (base=0x22b94f5d000, flags=Variable 
"flags" is not available.
) at /usr/src/lib/libevent/event.c:350
#18 0x022920b12db4 in proc_run (ps=0x22c0f506000, p=0x22920d30080, 
procs=0x22920d301c0, nproc=2, run=0x22920b1424d ,
arg=0x0) at /usr/src/usr.sbin/httpd/proc.c:594
#19 0x022920b137b1 in server (ps=0x22c0f506000, p=0x22920d30080) at 
/usr/src/usr.sbin/httpd/server.c:87
#20 0x022920b11da5 in proc_init (ps=0x22c0f506000, procs=0x22920d30080, 
nproc=2, argc=5, argv=0x7f7f2898, proc_id=PROC_SERVER)
at /usr/src/usr.sbin/httpd/proc.c:249
#21 0x022920b0ac57 in main (argc=0, argv=0x7f7f2898) at 
/usr/src/usr.sbin/httpd/httpd.c:218

Re: no CPU frequency scaling on Purism Librem 13v2

[Jonathan Gray]

On Sat, Sep 16, 2017 at 10:03:58AM +0200, matth...@herrb.eu wrote:
> >Synopsis:no CPU frequency scaling on Purism Librem 13v2
> >Category:kern/amd64
> >Environment:
>   System  : OpenBSD 6.2
>   Details : OpenBSD 6.2-beta (GENERIC.MP) #0: Fri Sep 15 23:36:30 
> CEST 2017
>matth...@librem.herrb.net:/usr/obj/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   There is no hw.setperf sysctl available to control the CPU speed
> 
> >How-To-Repeat:
>   Try to use apmd -A to save some battery life
> >Fix:
>   unknown

If vendor supplied acpi tables neglect to include _PSS in the aml you
won't get different cpu speed states on anything more recent than
a pentium m.

> 
> 
> sysctl hw:
> 
> hw.machine=amd64
> hw.model=Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
> hw.ncpu=4
> hw.byteorder=1234
> hw.pagesize=4096
> hw.disknames=sd0:cab522578cd41f1b,sd1:,sd2:3e8a268bb4947e47
> hw.diskcount=3
> hw.sensors.cpu0.temp0=34.00 degC
> hw.sensors.acpiac0.indicator0=On (power supply)
> hw.sensors.acpibat0.volt0=7.40 VDC (voltage)
> hw.sensors.acpibat0.volt1=8.35 VDC (current voltage)
> hw.sensors.acpibat0.current0=unknown (rate), UNKNOWN
> hw.sensors.acpibat0.amphour0=6.06 Ah (last full capacity)
> hw.sensors.acpibat0.amphour1=0.91 Ah (warning capacity)
> hw.sensors.acpibat0.amphour2=0.60 Ah (low capacity)
> hw.sensors.acpibat0.amphour3=6.06 Ah (remaining capacity), OK
> hw.sensors.acpibat0.amphour4=6.04 Ah (design capacity)
> hw.sensors.acpibat0.raw0=0 (battery full), OK
> hw.sensors.acpibat0.raw1=0 (discharge cycles)
> hw.sensors.acpibtn0.indicator0=On (lid open)
> hw.sensors.pchtemp0.temp0=34.00 degC
> hw.sensors.softraid0.drive0=online (sd2), OK
> hw.cpuspeed=2304
> hw.vendor=Purism
> hw.product=Librem 13 v2
> hw.version=2.0
> hw.serialno=257785
> hw.physmem=17057374208
> hw.usermem=17009631232
> hw.ncpufound=4
> hw.allowpowerdown=1
> 
> dmesg:
> OpenBSD 6.2-beta (GENERIC.MP) #0: Fri Sep 15 23:36:30 CEST 2017
> matth...@librem.herrb.net:/usr/obj/GENERIC.MP
> real mem = 17057374208 (16267MB)
> avail mem = 16533397504 (15767MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7ab5a020 (8 entries)
> bios0: vendor coreboot version "4.6-a86d1b-Purism-5" date 07/27/2017
> bios0: Purism Librem 13 v2
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S2 S3 S4 S5
> acpi0: tables DSDT FACP SSDT MCFG TCPA APIC HPET
> acpi0: wakeup devices XHCI(S3) PWRB(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2304.00 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: TSC frequency 230400 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2304.00 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 3 (application processor)
> cpu2: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2304.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,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 1, package 0
> cpu3 at mainbus0: apid 2 (application processor)
> cpu3: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2304.00 MHz
> cpu3: 
> 

Re: no CPU frequency scaling on Purism Librem 13v2

[Jonathan Gray]

On Sat, Sep 16, 2017 at 02:07:47PM +0200, Matthieu Herrb wrote:
> On Sat, Sep 16, 2017 at 06:57:38PM +1000, Jonathan Gray wrote:
> > On Sat, Sep 16, 2017 at 10:03:58AM +0200, matth...@herrb.eu wrote:
> > > >Synopsis:no CPU frequency scaling on Purism Librem 13v2
> > > >Category:kern/amd64
> > > >Environment:
> > >   System  : OpenBSD 6.2
> > >   Details : OpenBSD 6.2-beta (GENERIC.MP) #0: Fri Sep 15 23:36:30 
> > > CEST 2017
> > >matth...@librem.herrb.net:/usr/obj/GENERIC.MP
> > > 
> > >   Architecture: OpenBSD.amd64
> > >   Machine : amd64
> > > >Description:
> > >   There is no hw.setperf sysctl available to control the CPU speed
> > > 
> > > >How-To-Repeat:
> > >   Try to use apmd -A to save some battery life
> > > >Fix:
> > >   unknown
> > 
> > If vendor supplied acpi tables neglect to include _PSS in the aml you
> > won't get different cpu speed states on anything more recent than
> > a pentium m.
> >
> Hi,
> 
> On PureOS (the Debian derivative shipped by Purism) it's the
> intel_pstate driver that is used to control the CPU core speeds.
> 
> Should I try to ask Purism  to provide the proper _PSS objects in
> their BIOS, or is there hope to get P states support at some point?

Given there is no _PSS or _CPC the alternative seems to be MSRs.
The ones related to hardware p states (HWP) available in broadwell
and later.

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20170303 (64-bit version)
 * Copyright (c) 2000 - 2017 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of SSDT.3, Sat Sep 16 23:19:18 2017
 *
 * Original Table Header:
 * Signature"SSDT"
 * Length   0x0308 (776)
 * Revision 0x02
 * Checksum 0xEF
 * OEM ID   "CORE  "
 * OEM Table ID "COREBOOT"
 * OEM Revision 0x002A (42)
 * Compiler ID  "CORE"
 * Compiler Version 0x002A (42)
 */
DefinitionBlock ("", "SSDT", 2, "CORE  ", "COREBOOT", 0x002A)
{
Device (CTBL)
{
Name (_HID, "BOOT")  // _HID: Hardware ID
Name (_UID, Zero)  // _UID: Unique ID
Method (_STA, 0, NotSerialized)  // _STA: Status
{
Return (0x0F)
}

Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
{
Memory32Fixed (ReadOnly,
0x7AB8F000, // Address Base
0x8000, // Address Length
)
})
}

Processor (\_PR.CP00, 0x00, 0x1800, 0x06)
{
Name (_CST, Package (0x04)  // _CST: C-States
{
0x0003, 
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW, 
0x01,   // Bit Width
0x02,   // Bit Offset
0x0001, // Address
0x01,   // Access Size
)
}, 

0x0001, 
0x, 
0x03E8
}, 

Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW, 
0x01,   // Bit Width
0x02,   // Bit Offset
0x0010, // Address
0x01,   // Access Size
)
}, 

0x0002, 
0x004F, 
0x01F4
}, 

Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW, 
0x01,   // Bit Width
0x02,   // Bit Offset
0x0033, // Address
0x01,   // Access Size
)
}, 

0x0003, 
0x0097, 
0x00C8
}
})
}

Processor (\_PR.CP01, 0x01, 0x, 0x00)
{
Name (_CST, Package (0x04)  // _CST: C-States
{
0x0003, 
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW, 
0x01,   // Bit Width
0x02,   // Bit Offset
   

Re: config(8) elf handling

[Jonathan Gray]

On Wed, Sep 13, 2017 at 10:23:46AM -0600, Theo de Raadt wrote:
> > On Wed, 13 Sep 2017, Miod Vallat wrote:
> > > 
> > > > Forcing uextraloc into .data via
> > > > int uextraloc __attribute__ ((section(".data"))) = 0;
> > > > avoids the crashes.
> > > 
> > > Regardless of this bug, the in-tree gcc was modified to default to put
> > > explicitly zero initialized data in .data rather than .bss, i.e. default
> > > to -fno-zero-initialized-in-bss.
> > > 
> > > It might be wise to make the default configuration of clang follow this
> > > behaviour as well.
> > 
> > Anyone recall the issues that it was originally changed to fix?
> > 
> > If it was the kernel config stuff, maybe we should just pass the option 
> > explicitly in the kernel Makefiles and not push it on all of userland.
> 
> I also don't like it much, because it changes the underlying ABI in such
> a subtle way.
> 
> How about initializing the variable to some 'illegal' value,
> recognizing that value when using it, and resetting it to 0 before
> use.  Then it doesn't need to rely some crazy ABI tweak.
> 

If the attribute to force it into .data isn't wanted the alternative
gets messy as config has a bunch of bogus types and casts and treats the
int values as longs.

Index: mkioconf.c
===
RCS file: /cvs/src/usr.sbin/config/mkioconf.c,v
retrieving revision 1.36
diff -u -p -r1.36 mkioconf.c
--- mkioconf.c  27 Oct 2016 14:33:30 -  1.36
+++ mkioconf.c  14 Sep 2017 02:11:17 -
@@ -183,7 +183,7 @@ static long loc[%d] = {", locators.used)
 #endif\n\
 long extraloc[MAXEXTRALOC] = { -1 };\n\
 int nextraloc = MAXEXTRALOC;\n\
-int uextraloc = 0;\n") < 0);
+int uextraloc = -1;\n") < 0);
 }
 
 static int nlocnames, maxlocnames = 8;
Index: ukcutil.c
===
RCS file: /cvs/src/usr.sbin/config/ukcutil.c,v
retrieving revision 1.22
diff -u -p -r1.22 ukcutil.c
--- ukcutil.c   27 Oct 2016 14:32:10 -  1.22
+++ ukcutil.c   14 Sep 2017 02:22:33 -
@@ -419,6 +419,14 @@ change(int devno)
 
j = (long *)adjust((caddr_t)nl[I_NEXTRALOC].n_value);
k = (long *)adjust((caddr_t)nl[I_UEXTRALOC].n_value);
+
+   /*
+* uextraloc is initialised to -1 not 0 so it will be
+* put in .data instead of .bss so config can modify it
+*/
+   if (*(int *)k == -1)
+   *k = 0;
+
if ((i + *k) > *j) {
printf("Not enough space to change device.\n");
return;
@@ -521,6 +529,14 @@ change_history(int devno, char *str)
 
j = (long *)adjust((caddr_t)nl[I_NEXTRALOC].n_value);
k = (long *)adjust((caddr_t)nl[I_UEXTRALOC].n_value);
+
+   /*
+* uextraloc is initialised to -1 not 0 so it will be
+* put in .data instead of .bss so config can modify it
+*/
+   if (*(int *)k == -1)
+   *k = 0;
+
if ((i + *k) > *j) {
printf("Not enough space to change device.\n");
return;

Re: config(8) elf handling

[Jonathan Gray]

On Wed, Sep 13, 2017 at 08:34:56PM -0600, Theo de Raadt wrote:
> > If the attribute to force it into .data isn't wanted the alternative
> > gets messy as config has a bunch of bogus types and casts and treats the
> > int values as longs.
> 
> Well, I believe that messiness is a result of trying to avoid the
> consequences of the ABI.  I feel the ABI shouldn't be exposed here
> and changing the compilers is wrong...
> 
> The -1 handling could be pushed to the very top.  At the very first
> moment anything in ukc runs, set it to 0.  No conditional logic later on.

Index: mkioconf.c
===
RCS file: /cvs/src/usr.sbin/config/mkioconf.c,v
retrieving revision 1.36
diff -u -p -U4 -r1.36 mkioconf.c
--- mkioconf.c  27 Oct 2016 14:33:30 -  1.36
+++ mkioconf.c  14 Sep 2017 02:11:17 -
@@ -182,9 +182,9 @@ static long loc[%d] = {", locators.used)
 #define MAXEXTRALOC 32\n\
 #endif\n\
 long extraloc[MAXEXTRALOC] = { -1 };\n\
 int nextraloc = MAXEXTRALOC;\n\
-int uextraloc = 0;\n") < 0);
+int uextraloc = -1;\n") < 0);
 }
 
 static int nlocnames, maxlocnames = 8;
 static char **locnames;
Index: ukc.c
===
RCS file: /cvs/src/usr.sbin/config/ukc.c,v
retrieving revision 1.22
diff -u -p -U4 -r1.22 ukc.c
--- ukc.c   19 Oct 2016 16:39:02 -  1.22
+++ ukc.c   14 Sep 2017 03:14:43 -
@@ -61,8 +61,9 @@ ukc(char *file, char *outfile, int uflag
kvm_t *kd;
char errbuf[_POSIX2_LINE_MAX];
int histlen = 0, ok = 1;
char history[1024], kversion[1024];
+   int *uextraloc;
 
if (file == NULL) {
warnx("no file specified");
usage();
@@ -71,8 +72,18 @@ ukc(char *file, char *outfile, int uflag
loadkernel(file);
 
if (nlist(file, nl) == -1)
errx(1, "nlist: %s", file);
+
+   /*
+* uextraloc is initialised to -1 not 0 so it will be put in .data
+* instead of .bss so config can modify it
+*/
+   if (nl[I_UEXTRALOC].n_type != 0) {
+   uextraloc = (int *)adjust((caddr_t)nl[I_UEXTRALOC].n_value);
+   if (*uextraloc == -1)
+   *uextraloc = 0;
+   }
 
if (uflag) {
if ((kd = kvm_openfiles(NULL,NULL,NULL,O_RDONLY, errbuf)) == 0)
errx(1, "kvm_openfiles: %s", errbuf);

config(8) elf handling

[Jonathan Gray]

config(8) creates ioconf.c containing

#ifndef MAXEXTRALOC
#define MAXEXTRALOC 32
#endif
long extraloc[MAXEXTRALOC] = { -1 };
int nextraloc = MAXEXTRALOC;
int uextraloc = 0;

When uextraloc gets stored in .bss where filesz < memsz the simplistic
way config(8) reads an entire elf file into memory without parsing
the program headers leads to various crashes or
"Not enough space to change device." if the offset for I_UEXTRALOC
returned by adjust() is within the address space.

Forcing uextraloc into .data via
int uextraloc __attribute__ ((section(".data"))) = 0;
avoids the crashes.

(gdb) run -ef /tmp/bsd.rd
Starting program: /usr/obj/usr.sbin/config/config -ef /tmp/bsd.rd
OpenBSD 6.2-beta (RAMDISK_CD) #88: Mon Sep 11 11:01:29 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
Enter 'help' for information
ukc> change pciide*
 80 pciide* at pci* dev -1 function -1 flags 0x0
change [n] y

Program received signal SIGSEGV, Segmentation fault.
memmove () at /usr/src/lib/libc/arch/amd64/string/memmove.S:62
62  rep
(gdb) bt
#0  memmove () at /usr/src/lib/libc/arch/amd64/string/memmove.S:62
#1  0x1a0a5b911d21 in change (devno=80) at 
/usr/src/usr.sbin/config/ukcutil.c:428
#2  0x1a0a5b913127 in common_dev (dev=0x7f7ec9c2 "pciide*", len=6, 
unit=0, state=2, 
routine=99 'c') at /usr/src/usr.sbin/config/ukcutil.c:889
#3  0x1a0a5b914faa in Xchange (cmd=0x7f7ec9b0) at 
/usr/src/usr.sbin/config/cmd.c:124
#4  0x1a0a5b914667 in config () at /usr/src/usr.sbin/config/ukcutil.c:1330
#5  0x1a0a5b910624 in ukc (file=0x7f7ee0f4 "/tmp/bsd.rd", outfile=0x0, 
uflag=0, 
force=1) at /usr/src/usr.sbin/config/ukc.c:156
#6  0x1a0a5b903e6f in main (argc=1, argv=0x7f7edfa8)
at /usr/src/usr.sbin/config/main.c:172

With the patch below to error out

$ ./obj/config -ef /tmp/bsd.rd  
OpenBSD 6.2-beta (RAMDISK_CD) #88: Mon Sep 11 11:01:29 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
Enter 'help' for information
ukc> change pciide*
 80 pciide* at pci* dev -1 function -1 flags 0x0
change [n] y
config: symbol 0x8189ea48 in section 5 ph 3 ELF filesz < memsz not 
handled
$ nm /tmp/bsd.rd | fgrep 8189ea48   
 
8189ea48 B uextraloc

$ readelf -Wa /tmp/bsd.rd | head -48
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x81000158
  Start of program headers:  64 (bytes into file)
  Start of section headers:  9080584 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 5
  Size of section headers:   64 (bytes)
  Number of section headers: 10
  Section header string table index: 7

Section Headers:
  [Nr] Name  TypeAddress  OffSize   ES Flg 
Lk Inf Al
  [ 0]   NULL 00 00 00  
0   0  0
  [ 1] .text PROGBITS81000158 000158 335e98 00  AX  
0   0 4096
  [ 2] .rodata   PROGBITS81336000 336000 161f90 00  WA  
0   0 16
  [ 3] .openbsd.randomda PROGBITS81498000 498000 002400 00  WA  
0   0 16
  [ 4] .data PROGBITS8149b000 49b000 3b2ad8 00  WA  
0   0 4096
  [ 5] .bss  NOBITS  8184e000 84dad8 092000 00  WA  
0   0 4096
  [ 6] .SUNW_ctf PROGBITS 84dad8 05b3da 00  
0   0  1
  [ 7] .shstrtab STRTAB   8a8eb2 52 00  
0   0  1
  [ 8] .symtab   SYMTAB   8a9188 068460 18  
9 1754  8
  [ 9] .strtab   STRTAB   9115e8 044d98 00  
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz 
  Flg Align
  LOAD   0x00 0x8100 0x0100 0x335ff0 
0x335ff0 R E 0x10
  LOAD   0x336000 0x81336000 0x01336000 0x164400 
0x164400 RW  0x10
  LOAD   0x49b000 0x8149b000 0x0149b000 0x3b2ad8 
0x3b2ad8 RW  0x10
  LOAD 

Re: config(8) elf handling

[Jonathan Gray]

On Wed, Sep 13, 2017 at 08:44:24AM +, Miod Vallat wrote:
> 
> > Forcing uextraloc into .data via
> > int uextraloc __attribute__ ((section(".data"))) = 0;
> > avoids the crashes.
> 
> Regardless of this bug, the in-tree gcc was modified to default to put
> explicitly zero initialized data in .data rather than .bss, i.e. default
> to -fno-zero-initialized-in-bss.
> 
> It might be wise to make the default configuration of clang follow this
> behaviour as well.
> 

Yes, that seems reasonable.

Index: gnu/llvm/tools/clang/lib/Driver/Tools.cpp
===
RCS file: /cvs/src/gnu/llvm/tools/clang/lib/Driver/Tools.cpp,v
retrieving revision 1.14
diff -u -p -r1.14 Tools.cpp
--- gnu/llvm/tools/clang/lib/Driver/Tools.cpp   28 Jul 2017 15:31:54 -  
1.14
+++ gnu/llvm/tools/clang/lib/Driver/Tools.cpp   13 Sep 2017 09:51:50 -
@@ -4463,8 +4463,13 @@ void Clang::ConstructJob(Compilation ,
 
   if (shouldUseFramePointer(Args, getToolChain().getTriple()))
 CmdArgs.push_back("-mdisable-fp-elim");
+
+  bool ZeroInitializedInBSSDefault = true;
+  if (getToolChain().getTriple().isOSOpenBSD())
+ZeroInitializedInBSSDefault = false;
   if (!Args.hasFlag(options::OPT_fzero_initialized_in_bss,
-options::OPT_fno_zero_initialized_in_bss))
+options::OPT_fno_zero_initialized_in_bss,
+ZeroInitializedInBSSDefault))
 CmdArgs.push_back("-mno-zero-initialized-in-bss");
 
   bool OFastEnabled = isOptimizationLevelFast(Args);
Index: share/man/man1/clang-local.1
===
RCS file: /cvs/src/share/man/man1/clang-local.1,v
retrieving revision 1.9
diff -u -p -r1.9 clang-local.1
--- share/man/man1/clang-local.129 Jul 2017 21:01:13 -  1.9
+++ share/man/man1/clang-local.113 Sep 2017 09:57:14 -
@@ -95,6 +95,14 @@ and
 .Xr free 3
 builtins are disabled to prevent undesriable optimizations of calls to
 these functions.
+.It
+.Nm clang
+will not move variables initialized with the value zero from the data section
+to the bss section.
+The default behaviour of
+.Nm clang
+on other systems is to perform this action, which can be restored with
+.Fl fzero-initialized-in-bss .
 .El
 .Sh SEE ALSO
 .Xr clang 1

Re: [rpi3] OpenBSD-6.2-beta does not boot after installer finish

[Jonathan Gray]

On Tue, Aug 22, 2017 at 12:27:55PM +1000, Jonathan Gray wrote:
> On Mon, Aug 21, 2017 at 06:28:16PM -0300, R0me0 *** wrote:
> > Hello,
> > 
> > Wrote miniroot62.fs to usb stick as usual, boots and installs
> > 
> > ( tried with miniroot from ftp.openbsd.org and ftp.hostserver.de )
> > 
> > miniroot62.fs 21-Aug-2017 03:10  22020096
> > 
> > 
> > But after reboot, rpi3 does not initialize. Just boot if I rewrite miniroot
> > to usb sitck
> > 
> > 
> > 
> > Relinking to create unique kernel...done.
> > 
> > CONGRATULATIONS! Your OpenBSD install has been successfully completed!
> > To boot the new system, enter 'reboot' at the command prompt.
> > When you login to your new system the first time, please read your mail
> > using the 'mail' command.
> > 
> > # reboot
> > syncing disks... done
> > rebooting...
> 
> scan_dmesg does not seem to work correctly for this.
> 
> # sed -n 's/^mainbus0 at root: \(.*\)$/\1/p' /var/run/dmesg.boot  
>  
> Raspberry Pi 3 Model B Rev 1.2
> 
> but scan_dmesg sorts the words of the string so that
> 
> $(scan_dmesg 's/^mainbus0 at root: \(.*\)$/\1/p') gives
> 
> "1.2 3 B Model Pi Raspberry Rev"
> 
> The next snapshot will include a revised version of the diff
> to use $(sysctl -n hw.product).

22nd August snapshot should work.  Thanks for the report.

> 
> armv7 should be changed to use the same.
> 
> Index: miniroot/Makefile
> ===
> RCS file: /cvs/src/distrib/arm64/miniroot/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- miniroot/Makefile 7 May 2017 12:00:12 -   1.4
> +++ miniroot/Makefile 22 Aug 2017 02:25:34 -
> @@ -65,6 +65,8 @@ do_files:
>   cp /usr/mdec/BOOTAA64.EFI ${MOUNT_POINT}/efi/boot/bootaa64.efi
>   echo bootaa64.efi > ${MOUNT_POINT}/efi/boot/startup.nsh
>   echo 
> 'arm_control=0x200\nenable_uart=1\ndevice_tree_address=0x100\nkernel=u-boot.bin'
>  > ${MOUNT_POINT}/config.txt
> + dd if=${PUBOOT}/pine64_plus/u-boot-sunxi-with-spl.bin \
> + of=${VND_CDEV} bs=1024 seek=8
>  
>  rd_setup:
>   dd if=/dev/zero of=${IMAGE} bs=512 count=${NBLKS}
> Index: ramdisk/Makefile
> ===
> RCS file: /cvs/src/distrib/arm64/ramdisk/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- ramdisk/Makefile  18 Feb 2017 02:01:53 -  1.2
> +++ ramdisk/Makefile  22 Aug 2017 02:25:34 -
> @@ -18,6 +18,7 @@ DISKTYPE=   rdroot
>  MAKEFSARGS_RD=   -o disklabel=${DISKTYPE},minfree=0,density=4096
>  
>  DIRS=\
> + pine64 \
>   rpi
>  
>  .ifndef DESTDIR
> Index: ramdisk/install.md
> ===
> RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
> retrieving revision 1.6
> diff -u -p -r1.6 install.md
> --- ramdisk/install.md28 Jul 2017 18:15:44 -  1.6
> +++ ramdisk/install.md22 Aug 2017 02:25:34 -
> @@ -38,23 +38,35 @@ MOUNT_ARGS_msdos="-o-l"
>  md_installboot() {
>   local _disk=/dev/$1 _mdec _plat
>  
> + case $(sysctl -n hw.product) in
> + *Pine64*)   _plat=pine64;;
> + *'Raspberry Pi'*)   _plat=rpi;;
> + esac
> +
>   # Mount MSDOS partition, extract U-Boot and copy UEFI boot program
>   mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
>   mkdir -p /mnt/mnt/efi/boot
>   cp /mnt/usr/mdec/BOOTAA64.EFI /mnt/mnt/efi/boot/bootaa64.efi
>   echo bootaa64.efi > /mnt/mnt/efi/boot/startup.nsh
>  
> - _plat=rpi
>   _mdec=/usr/mdec/$_plat
>  
> - cp $_mdec/{bootcode.bin,start.elf,fixup.dat,*.dtb} /mnt/mnt/
> - cp $_mdec/u-boot.bin /mnt/mnt/
> - cat > /mnt/mnt/config.txt<<-__EOT
> - arm_control=0x200
> - enable_uart=1
> - device_tree_address=0x100
> - kernel=u-boot.bin
> - __EOT
> + case $_plat in
> + pine64)
> + dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
> + bs=1024 seek=8 >/dev/null 2>&1
> + ;;
> + rpi)
> + cp $_mdec/{bootcode.bin,start.elf,fixup.dat,*.dtb} /mnt/mnt/
> + cp $_mdec/u-boot.bin /mnt/mnt/
> + cat > /mnt/mnt/config.txt<<-__EOT
> + arm_control=0x200
> + enable_uart=1
> + device_tree_address=0x100
> + kernel=u-boot.bin
> + __EOT
> + ;;
> + e

Re: [rpi3] OpenBSD-6.2-beta does not boot after installer finish

[Jonathan Gray]

On Mon, Aug 21, 2017 at 06:28:16PM -0300, R0me0 *** wrote:
> Hello,
> 
> Wrote miniroot62.fs to usb stick as usual, boots and installs
> 
> ( tried with miniroot from ftp.openbsd.org and ftp.hostserver.de )
> 
> miniroot62.fs 21-Aug-2017 03:10  22020096
> 
> 
> But after reboot, rpi3 does not initialize. Just boot if I rewrite miniroot
> to usb sitck
> 
> 
> 
> Relinking to create unique kernel...done.
> 
> CONGRATULATIONS! Your OpenBSD install has been successfully completed!
> To boot the new system, enter 'reboot' at the command prompt.
> When you login to your new system the first time, please read your mail
> using the 'mail' command.
> 
> # reboot
> syncing disks... done
> rebooting...

scan_dmesg does not seem to work correctly for this.

# sed -n 's/^mainbus0 at root: \(.*\)$/\1/p' /var/run/dmesg.boot   
Raspberry Pi 3 Model B Rev 1.2

but scan_dmesg sorts the words of the string so that

$(scan_dmesg 's/^mainbus0 at root: \(.*\)$/\1/p') gives

"1.2 3 B Model Pi Raspberry Rev"

The next snapshot will include a revised version of the diff
to use $(sysctl -n hw.product).

armv7 should be changed to use the same.

Index: miniroot/Makefile
===
RCS file: /cvs/src/distrib/arm64/miniroot/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- miniroot/Makefile   7 May 2017 12:00:12 -   1.4
+++ miniroot/Makefile   22 Aug 2017 02:25:34 -
@@ -65,6 +65,8 @@ do_files:
cp /usr/mdec/BOOTAA64.EFI ${MOUNT_POINT}/efi/boot/bootaa64.efi
echo bootaa64.efi > ${MOUNT_POINT}/efi/boot/startup.nsh
echo 
'arm_control=0x200\nenable_uart=1\ndevice_tree_address=0x100\nkernel=u-boot.bin'
 > ${MOUNT_POINT}/config.txt
+   dd if=${PUBOOT}/pine64_plus/u-boot-sunxi-with-spl.bin \
+   of=${VND_CDEV} bs=1024 seek=8
 
 rd_setup:
dd if=/dev/zero of=${IMAGE} bs=512 count=${NBLKS}
Index: ramdisk/Makefile
===
RCS file: /cvs/src/distrib/arm64/ramdisk/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- ramdisk/Makefile18 Feb 2017 02:01:53 -  1.2
+++ ramdisk/Makefile22 Aug 2017 02:25:34 -
@@ -18,6 +18,7 @@ DISKTYPE= rdroot
 MAKEFSARGS_RD= -o disklabel=${DISKTYPE},minfree=0,density=4096
 
 DIRS=\
+   pine64 \
rpi
 
 .ifndef DESTDIR
Index: ramdisk/install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.6
diff -u -p -r1.6 install.md
--- ramdisk/install.md  28 Jul 2017 18:15:44 -  1.6
+++ ramdisk/install.md  22 Aug 2017 02:25:34 -
@@ -38,23 +38,35 @@ MOUNT_ARGS_msdos="-o-l"
 md_installboot() {
local _disk=/dev/$1 _mdec _plat
 
+   case $(sysctl -n hw.product) in
+   *Pine64*)   _plat=pine64;;
+   *'Raspberry Pi'*)   _plat=rpi;;
+   esac
+
# Mount MSDOS partition, extract U-Boot and copy UEFI boot program
mount ${MOUNT_ARGS_msdos} ${_disk}i /mnt/mnt
mkdir -p /mnt/mnt/efi/boot
cp /mnt/usr/mdec/BOOTAA64.EFI /mnt/mnt/efi/boot/bootaa64.efi
echo bootaa64.efi > /mnt/mnt/efi/boot/startup.nsh
 
-   _plat=rpi
_mdec=/usr/mdec/$_plat
 
-   cp $_mdec/{bootcode.bin,start.elf,fixup.dat,*.dtb} /mnt/mnt/
-   cp $_mdec/u-boot.bin /mnt/mnt/
-   cat > /mnt/mnt/config.txt<<-__EOT
-   arm_control=0x200
-   enable_uart=1
-   device_tree_address=0x100
-   kernel=u-boot.bin
-   __EOT
+   case $_plat in
+   pine64)
+   dd if=$_mdec/u-boot-sunxi-with-spl.bin of=${_disk}c \
+   bs=1024 seek=8 >/dev/null 2>&1
+   ;;
+   rpi)
+   cp $_mdec/{bootcode.bin,start.elf,fixup.dat,*.dtb} /mnt/mnt/
+   cp $_mdec/u-boot.bin /mnt/mnt/
+   cat > /mnt/mnt/config.txt<<-__EOT
+   arm_control=0x200
+   enable_uart=1
+   device_tree_address=0x100
+   kernel=u-boot.bin
+   __EOT
+   ;;
+   esac
 }
 
 md_prep_fdisk() {
Index: ramdisk/list
===
RCS file: /cvs/src/distrib/arm64/ramdisk/list,v
retrieving revision 1.4
diff -u -p -r1.4 list
--- ramdisk/list8 Jul 2017 15:42:46 -   1.4
+++ ramdisk/list22 Aug 2017 02:25:34 -
@@ -124,4 +124,6 @@ COPY/usr/local/share/raspberrypi-firmwa
 COPY   /usr/local/share/raspberrypi-firmware/boot/fixup.dat 
usr/mdec/rpi/fixup.dat
 COPY   /usr/local/share/u-boot/rpi_3/u-boot.bin usr/mdec/rpi/u-boot.bin
 
+COPY   /usr/local/share/u-boot/pine64_plus/u-boot-sunxi-with-spl.bin 
usr/mdec/pine64/u-boot-sunxi-with-spl.bin
+
 TZ

ALPN rewrite broke httpd TLS

[Jonathan Gray]

After the ALPN rewrite chromium/firefox/curl all refuse to connect to
httpd.

$ curl -kv https://127.0.0.1 
* Rebuilt URL to: https://127.0.0.1/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS alert, Server hello (2):
* error:1400441A:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert decode error
* stopped the pause stream!
* Closing connection 0
curl: (35) error:1400441A:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert decode 
error

$ curl -kv --no-alpn https://127.0.0.1
* Rebuilt URL to: https://127.0.0.1/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*  subject: CN=raz.jsg.id.au
*  start date: Jun  6 11:20:37 2017 GMT
*  expire date: Jun  6 11:20:37 2018 GMT
*  issuer: CN=raz.jsg.id.au
*  SSL certificate verify result: self signed certificate (18), continuing 
anyway.
> GET / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.55.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Length: 66
< Content-Type: text/html
< Date: Tue, 29 Aug 2017 06:39:29 GMT
< Last-Modified: Tue, 13 May 2014 10:14:13 GMT
< Server: OpenBSD httpd
< 


/var/www/htdocs/index.html


* Connection #0 to host 127.0.0.1 left intact