Re: Stop abusing rcvif pointer to pass wireless nodes

2014-03-18 Thread Claudio Jeker 
On Mon, Mar 17, 2014 at 11:41:38AM -0600, Theo de Raadt wrote:
  What about using a more generic name which is not bound to 80211 since the
  field is a generic pointer. This may allow us to use something similar in
  other drivers like mpe(4), gif(4), gre(4).
 
 That is basically the only thought I had.  I mean you could also start
 passing it as a mbuf tag, but probably don't want the allocate/free
 overhead.

It would only make sense to use mbuf tags if the allocate/lookup/free
path of mbuf tags can be made very small. Did somebody profile them after
the switch to a pool backend? 

-- 
:wq Claudio

bgpctl show_attr bad length fix

2014-03-18 Thread rivo nurges 
Hi!

When show_attr reads data length from provided data it reads carbage
to alen and fails afterwards. This patch fixes the problem by casting
the data to u_char. While at it I noticed data gets assigned twice.


bgpctl.c: /* bad imsg len how can that happen!? */
bgpctl.c: if (alen  len)
bgpctl.c:   errx(1, show_attr: bad length);

It can happen:D


Example failing prefix with long community list:
Before:
BGP routing table entry for 5.44.0.0/20
25478 31499 39812
Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
Last update: 00:12:11 ago
bgpctl: show_attr: bad length

After:
BGP routing table entry for 5.44.0.0/20
25478 31499 39812
Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
Last update: 00:11:13 ago
Communities: 0:5429 0:6719 0:8241 0:8636 0:8641 0:24955 0:25478 0:25532
0:29000 0:29319 0:30784 0:31225 0:41349 0:41475 0:42511 0:42754 0:43973 0:44020
0:44053 0:44281 0:47104 0:47119 0:47321 0:48166 0:48293 0:48297 0:48781 0:49060
0:49124 0:50384 0:50448 0:50577 0:50911 0:50952 0:56462 0:57073 0:57363 1299:150
3249:10643 3249:11000 3249:11001 3356:90 6854:1009 6854:1509 6854:1605 6854:1665
8359:2094 8631:8631 8744:52994 8744:53124 8744:53134 8744:59994 12389:6992
12389:7130 12389:7993 12389:8020 12389:8995 25478:10011 25478:10931 25478:24000
25478:29000 31133:10008 31133:25002
Originator Id: x.y.z.w
Cluster ID List: x.y.z.w z.x.y.w


-- 
rix



Index: usr.sbin/bgpctl/bgpctl.c
===
RCS file: /OpenBSD/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.173
diff -u -p -r1.173 bgpctl.c
--- usr.sbin/bgpctl/bgpctl.c13 Nov 2013 22:52:41 -  1.173
+++ usr.sbin/bgpctl/bgpctl.c3 Mar 2014 13:21:23 -
@@ -1346,7 +1346,6 @@ show_attr(void *b, u_int16_t len)
u_int16_talen, ioff;
u_int8_t flags, type;
 
-   data = b;
if (len  3)
errx(1, show_attr: too short bgp attr);
 
@@ -1362,7 +1361,7 @@ show_attr(void *b, u_int16_t len)
data += 4;
len -= 4;
} else {
-   alen = data[2];
+   alen = (u_char)data[2];
data += 3;
len -= 3;
}

fix for fs tests

2014-03-18 Thread Sergey Bronnikov 
Somehow fstests from src/regress were broken.
Patch fix creation of temporary files and
add mark test target as required root permissions.
Ok?

Was: 3053 tests completed, 2738 failed.
Now: 3053 tests completed, 275 failed.

Another failes connected to abcense of syscalls (lchflags),
abcense of flags for chflags (like SF_SNAPSHOT). Do we need to
remove such tests?

P.S. pjd@ test source tree differs from OpenBSD test for at least
tests with ftruncate - https://github.com/pjd/pjdfstest
Is it worth to add absent tests?

Sergey B.
Index: Makefile
===
RCS file: /cvs/src/regress/sys/ffs/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile18 Apr 2011 16:52:11 -  1.4
+++ Makefile16 Mar 2014 07:52:23 -
@@ -2,6 +2,8 @@
 
 PROG=  fstest
 
+REGRESS_ROOT_TARGETS=  run-regress-fstest
+
 mount:
dd if=/dev/zero of=${.CURDIR}/fakeobj bs=512 count=4k
vnconfig vnd0 ${.CURDIR}/fakeobj
Index: run
===
RCS file: /cvs/src/regress/sys/ffs/run,v
retrieving revision 1.1
diff -u -p -u -r1.1 run
--- run 30 Mar 2007 19:02:51 -  1.1
+++ run 16 Mar 2014 07:52:23 -
@@ -45,7 +45,7 @@ test_check()
 # Generate a random file/directory name.
 namegen()
 {
-  echo fstest_`dd if=/dev/urandom bs=1k count=1 2/dev/null | openssl md5`
+  echo fstest_`dd if=/dev/urandom bs=1k count=1 2/dev/null | openssl md5 | 
awk '{ print $2 }'`
 }
 
 for arg in $*; do

Re: Stop abusing rcvif pointer to pass wireless nodes

2014-03-18 Thread Mike Belopuhov 
On 18 March 2014 07:20, Claudio Jeker cje...@diehard.n-r-g.com wrote:
 On Mon, Mar 17, 2014 at 11:41:38AM -0600, Theo de Raadt wrote:
  What about using a more generic name which is not bound to 80211 since the
  field is a generic pointer. This may allow us to use something similar in
  other drivers like mpe(4), gif(4), gre(4).

 That is basically the only thought I had.  I mean you could also start
 passing it as a mbuf tag, but probably don't want the allocate/free
 overhead.

 It would only make sense to use mbuf tags if the allocate/lookup/free
 path of mbuf tags can be made very small.

meh.  i'd say the cookie pointer is fine here.

 Did somebody profile them after the switch to a pool backend?


that i did, yes.

Re: Stop abusing rcvif pointer to pass wireless nodes

2014-03-18 Thread Martin Pieuchot 
On 18/03/14(Tue) 11:26, Mike Belopuhov wrote:
 On 18 March 2014 07:20, Claudio Jeker cje...@diehard.n-r-g.com wrote:
  On Mon, Mar 17, 2014 at 11:41:38AM -0600, Theo de Raadt wrote:
   What about using a more generic name which is not bound to 80211 since 
   the
   field is a generic pointer. This may allow us to use something similar in
   other drivers like mpe(4), gif(4), gre(4).
 
  That is basically the only thought I had.  I mean you could also start
  passing it as a mbuf tag, but probably don't want the allocate/free
  overhead.
 
  It would only make sense to use mbuf tags if the allocate/lookup/free
  path of mbuf tags can be made very small.
 
 meh.  i'd say the cookie pointer is fine here.
 
  Did somebody profile them after the switch to a pool backend?
 
 
 that i did, yes.

So here's a diff with a more generic name for the pointer and an update
of the structure in the manpage, ok?

diff --git share/man/man9/mbuf.9 share/man/man9/mbuf.9
index e3db548..ed0a511 100644
--- share/man/man9/mbuf.9
+++ share/man/man9/mbuf.9
@@ -119,6 +119,7 @@ struct pkthdr {
u_int16_t csum_flags;
u_int16_t ether_vtag;
u_int   rdomain;
+   void*ph_cookie;
struct  pkthdr_pf pf;
 };
 
diff --git sys/dev/ic/acx.c sys/dev/ic/acx.c
index 39910bc..07c04e6 100644
--- sys/dev/ic/acx.c
+++ sys/dev/ic/acx.c
@@ -948,8 +948,7 @@ acx_start(struct ifnet *ifp)
IF_DEQUEUE(ic-ic_mgtq, m);
/* first dequeue management frames */
if (m != NULL) {
-   ni = (struct ieee80211_node *)m-m_pkthdr.rcvif;
-   m-m_pkthdr.rcvif = NULL;
+   ni = m-m_pkthdr.ph_cookie;
 
/*
 * probe response mgmt frames are handled by the
@@ -976,8 +975,7 @@ acx_start(struct ifnet *ifp)
/* then dequeue packets on the powersave queue */
IF_DEQUEUE(ic-ic_pwrsaveq, m);
if (m != NULL) {
-   ni = (struct ieee80211_node *)m-m_pkthdr.rcvif;
-   m-m_pkthdr.rcvif = NULL;
+   ni = m-m_pkthdr.ph_cookie;
goto encapped;
} else {
IFQ_DEQUEUE(ifp-if_snd, m);
diff --git sys/dev/ic/ath.c sys/dev/ic/ath.c
index 83cd233..6c1bdca 100644
--- sys/dev/ic/ath.c
+++ sys/dev/ic/ath.c
@@ -897,17 +897,7 @@ ath_start(struct ifnet *ifp)
}
wh = mtod(m, struct ieee80211_frame *);
} else {
-   /*
-* Hack!  The referenced node pointer is in the
-* rcvif field of the packet header.  This is
-* placed there by ieee80211_mgmt_output because
-* we need to hold the reference with the frame
-* and there's no other way (other than packet
-* tags which we consider too expensive to use)
-* to pass it along.
-*/
-   ni = (struct ieee80211_node *) m-m_pkthdr.rcvif;
-   m-m_pkthdr.rcvif = NULL;
+   ni = m-m_pkthdr.ph_cookie;
 
wh = mtod(m, struct ieee80211_frame *);
if ((wh-i_fc[0]  IEEE80211_FC0_SUBTYPE_MASK) ==
diff --git sys/dev/ic/athn.c sys/dev/ic/athn.c
index 3aa4f0b..dafd00a 100644
--- sys/dev/ic/athn.c
+++ sys/dev/ic/athn.c
@@ -2554,7 +2554,7 @@ athn_start(struct ifnet *ifp)
/* Send pending management frames first. */
IF_DEQUEUE(ic-ic_mgtq, m);
if (m != NULL) {
-   ni = (void *)m-m_pkthdr.rcvif;
+   ni = m-m_pkthdr.ph_cookie;
goto sendit;
}
if (ic-ic_state != IEEE80211_S_RUN)
@@ -2562,7 +2562,7 @@ athn_start(struct ifnet *ifp)
 
IF_DEQUEUE(ic-ic_pwrsaveq, m);
if (m != NULL) {
-   ni = (void *)m-m_pkthdr.rcvif;
+   ni = m-m_pkthdr.ph_cookie;
goto sendit;
}
if (ic-ic_state != IEEE80211_S_RUN)
diff --git sys/dev/ic/atw.c sys/dev/ic/atw.c
index 443c1c0..8a0fd64 100644
--- sys/dev/ic/atw.c
+++ sys/dev/ic/atw.c
@@ -3605,8 +3605,7 @@ atw_start(struct ifnet *ifp)
 */
IF_DEQUEUE(ic-ic_mgtq, m0);
if (m0 != NULL) {
-   ni = (struct ieee80211_node *)m0-m_pkthdr.rcvif;
-   m0-m_pkthdr.rcvif = NULL;
+   ni = m0-m_pkthdr.ph_cookie;
} else {
/* send no data packets until we are associated */
if (ic-ic_state != IEEE80211_S_RUN)
diff --git sys/dev/ic/bwi.c sys/dev/ic/bwi.c

Re: Stop abusing rcvif pointer to pass wireless nodes

2014-03-18 Thread Claudio Jeker 
On Tue, Mar 18, 2014 at 12:28:41PM +0100, Martin Pieuchot wrote:
 On 18/03/14(Tue) 11:26, Mike Belopuhov wrote:
  On 18 March 2014 07:20, Claudio Jeker cje...@diehard.n-r-g.com wrote:
   On Mon, Mar 17, 2014 at 11:41:38AM -0600, Theo de Raadt wrote:
What about using a more generic name which is not bound to 80211 since 
the
field is a generic pointer. This may allow us to use something similar 
in
other drivers like mpe(4), gif(4), gre(4).
  
   That is basically the only thought I had.  I mean you could also start
   passing it as a mbuf tag, but probably don't want the allocate/free
   overhead.
  
   It would only make sense to use mbuf tags if the allocate/lookup/free
   path of mbuf tags can be made very small.
  
  meh.  i'd say the cookie pointer is fine here.
  
   Did somebody profile them after the switch to a pool backend?
  
  
  that i did, yes.
 
 So here's a diff with a more generic name for the pointer and an update
 of the structure in the manpage, ok?

Yeah, lets go with this. OK claudio@
 
 diff --git share/man/man9/mbuf.9 share/man/man9/mbuf.9
 index e3db548..ed0a511 100644
 --- share/man/man9/mbuf.9
 +++ share/man/man9/mbuf.9
 @@ -119,6 +119,7 @@ struct pkthdr {
   u_int16_t csum_flags;
   u_int16_t ether_vtag;
   u_int   rdomain;
 + void*ph_cookie;
   struct  pkthdr_pf pf;
  };
  
 diff --git sys/dev/ic/acx.c sys/dev/ic/acx.c
 index 39910bc..07c04e6 100644
 --- sys/dev/ic/acx.c
 +++ sys/dev/ic/acx.c
 @@ -948,8 +948,7 @@ acx_start(struct ifnet *ifp)
   IF_DEQUEUE(ic-ic_mgtq, m);
   /* first dequeue management frames */
   if (m != NULL) {
 - ni = (struct ieee80211_node *)m-m_pkthdr.rcvif;
 - m-m_pkthdr.rcvif = NULL;
 + ni = m-m_pkthdr.ph_cookie;
  
   /*
* probe response mgmt frames are handled by the
 @@ -976,8 +975,7 @@ acx_start(struct ifnet *ifp)
   /* then dequeue packets on the powersave queue */
   IF_DEQUEUE(ic-ic_pwrsaveq, m);
   if (m != NULL) {
 - ni = (struct ieee80211_node *)m-m_pkthdr.rcvif;
 - m-m_pkthdr.rcvif = NULL;
 + ni = m-m_pkthdr.ph_cookie;
   goto encapped;
   } else {
   IFQ_DEQUEUE(ifp-if_snd, m);
 diff --git sys/dev/ic/ath.c sys/dev/ic/ath.c
 index 83cd233..6c1bdca 100644
 --- sys/dev/ic/ath.c
 +++ sys/dev/ic/ath.c
 @@ -897,17 +897,7 @@ ath_start(struct ifnet *ifp)
   }
   wh = mtod(m, struct ieee80211_frame *);
   } else {
 - /*
 -  * Hack!  The referenced node pointer is in the
 -  * rcvif field of the packet header.  This is
 -  * placed there by ieee80211_mgmt_output because
 -  * we need to hold the reference with the frame
 -  * and there's no other way (other than packet
 -  * tags which we consider too expensive to use)
 -  * to pass it along.
 -  */
 - ni = (struct ieee80211_node *) m-m_pkthdr.rcvif;
 - m-m_pkthdr.rcvif = NULL;
 + ni = m-m_pkthdr.ph_cookie;
  
   wh = mtod(m, struct ieee80211_frame *);
   if ((wh-i_fc[0]  IEEE80211_FC0_SUBTYPE_MASK) ==
 diff --git sys/dev/ic/athn.c sys/dev/ic/athn.c
 index 3aa4f0b..dafd00a 100644
 --- sys/dev/ic/athn.c
 +++ sys/dev/ic/athn.c
 @@ -2554,7 +2554,7 @@ athn_start(struct ifnet *ifp)
   /* Send pending management frames first. */
   IF_DEQUEUE(ic-ic_mgtq, m);
   if (m != NULL) {
 - ni = (void *)m-m_pkthdr.rcvif;
 + ni = m-m_pkthdr.ph_cookie;
   goto sendit;
   }
   if (ic-ic_state != IEEE80211_S_RUN)
 @@ -2562,7 +2562,7 @@ athn_start(struct ifnet *ifp)
  
   IF_DEQUEUE(ic-ic_pwrsaveq, m);
   if (m != NULL) {
 - ni = (void *)m-m_pkthdr.rcvif;
 + ni = m-m_pkthdr.ph_cookie;
   goto sendit;
   }
   if (ic-ic_state != IEEE80211_S_RUN)
 diff --git sys/dev/ic/atw.c sys/dev/ic/atw.c
 index 443c1c0..8a0fd64 100644
 --- sys/dev/ic/atw.c
 +++ sys/dev/ic/atw.c
 @@ -3605,8 +3605,7 @@ atw_start(struct ifnet *ifp)
*/
   IF_DEQUEUE(ic-ic_mgtq, m0);
   if (m0 != NULL) {
 - ni = (struct ieee80211_node *)m0-m_pkthdr.rcvif;
 - m0-m_pkthdr.rcvif = NULL;
 + ni = m0-m_pkthdr.ph_cookie;
   } else {
   /* send no data packets until we are associated */

Re: bgpctl show_attr bad length fix

2014-03-18 Thread Stuart Henderson 
On 2014/03/18 08:57, rivo nurges wrote:
 Hi!
 
 When show_attr reads data length from provided data it reads carbage
 to alen and fails afterwards. This patch fixes the problem by casting
 the data to u_char. While at it I noticed data gets assigned twice.
 
 
 bgpctl.c: /* bad imsg len how can that happen!? */
 bgpctl.c: if (alen  len)
 bgpctl.c:   errx(1, show_attr: bad length);
 
 It can happen:D
 
 
 Example failing prefix with long community list:
 Before:
 BGP routing table entry for 5.44.0.0/20
 25478 31499 39812
 Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
 Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
 Last update: 00:12:11 ago
 bgpctl: show_attr: bad length

Haven't found any in my route views yet, though I only got part-way
through when I realised quite how much cpu time session engine was
burning doing a sh rib d (hundreds of clock_gettime a second)
and stopped as I worried about it not maintaining sessions and
tripping idle timers.

 Index: usr.sbin/bgpctl/bgpctl.c
 ===
 RCS file: /OpenBSD/src/usr.sbin/bgpctl/bgpctl.c,v
 retrieving revision 1.173
 diff -u -p -r1.173 bgpctl.c
 --- usr.sbin/bgpctl/bgpctl.c  13 Nov 2013 22:52:41 -  1.173
 +++ usr.sbin/bgpctl/bgpctl.c  3 Mar 2014 13:21:23 -
 @@ -1346,7 +1346,6 @@ show_attr(void *b, u_int16_t len)
   u_int16_talen, ioff;
   u_int8_t flags, type;
  
 - data = b;
   if (len  3)
   errx(1, show_attr: too short bgp attr);
  
 @@ -1362,7 +1361,7 @@ show_attr(void *b, u_int16_t len)
   data += 4;
   len -= 4;
   } else {
 - alen = data[2];
 + alen = (u_char)data[2];
   data += 3;
   len -= 3;
   }

This is OK sthen@

Re: bgpctl show_attr bad length fix

2014-03-18 Thread Florian Obser 
Commited, thanks

On Tue, Mar 18, 2014 at 08:57:40AM +, rivo nurges wrote:
 Hi!
 
 When show_attr reads data length from provided data it reads carbage
 to alen and fails afterwards. This patch fixes the problem by casting
 the data to u_char. While at it I noticed data gets assigned twice.
 
 
 bgpctl.c: /* bad imsg len how can that happen!? */
 bgpctl.c: if (alen  len)
 bgpctl.c:   errx(1, show_attr: bad length);
 
 It can happen:D
 
 
 Example failing prefix with long community list:
 Before:
 BGP routing table entry for 5.44.0.0/20
 25478 31499 39812
 Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
 Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
 Last update: 00:12:11 ago
 bgpctl: show_attr: bad length
 
 After:
 BGP routing table entry for 5.44.0.0/20
 25478 31499 39812
 Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
 Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
 Last update: 00:11:13 ago
 Communities: 0:5429 0:6719 0:8241 0:8636 0:8641 0:24955 0:25478 0:25532
 0:29000 0:29319 0:30784 0:31225 0:41349 0:41475 0:42511 0:42754 0:43973 
 0:44020
 0:44053 0:44281 0:47104 0:47119 0:47321 0:48166 0:48293 0:48297 0:48781 
 0:49060
 0:49124 0:50384 0:50448 0:50577 0:50911 0:50952 0:56462 0:57073 0:57363 
 1299:150
 3249:10643 3249:11000 3249:11001 3356:90 6854:1009 6854:1509 6854:1605 
 6854:1665
 8359:2094 8631:8631 8744:52994 8744:53124 8744:53134 8744:59994 12389:6992
 12389:7130 12389:7993 12389:8020 12389:8995 25478:10011 25478:10931 
 25478:24000
 25478:29000 31133:10008 31133:25002
 Originator Id: x.y.z.w
 Cluster ID List: x.y.z.w z.x.y.w
 
 
 -- 
 rix
 
 
 
 Index: usr.sbin/bgpctl/bgpctl.c
 ===
 RCS file: /OpenBSD/src/usr.sbin/bgpctl/bgpctl.c,v
 retrieving revision 1.173
 diff -u -p -r1.173 bgpctl.c
 --- usr.sbin/bgpctl/bgpctl.c  13 Nov 2013 22:52:41 -  1.173
 +++ usr.sbin/bgpctl/bgpctl.c  3 Mar 2014 13:21:23 -
 @@ -1346,7 +1346,6 @@ show_attr(void *b, u_int16_t len)
   u_int16_talen, ioff;
   u_int8_t flags, type;
  
 - data = b;
   if (len  3)
   errx(1, show_attr: too short bgp attr);
  
 @@ -1362,7 +1361,7 @@ show_attr(void *b, u_int16_t len)
   data += 4;
   len -= 4;
   } else {
 - alen = data[2];
 + alen = (u_char)data[2];
   data += 3;
   len -= 3;
   }
 

-- 
I'm not entirely sure you are real.

Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

2014-03-18 Thread sven falempin 
Some issue here, using install55.fs (today 18/3/2014 downloaded snaps)

boot is ok (warn: entropy file missing)

but /dev has no /dev/sd1 (is the usb key) and so i cannot look for the sets .

I did MAKEDEV all so i can mount keys to get the dmesg.

currently outputing dmesg on usb3 key, the machine has no plug for the
com port, no idea how to get the boot infos (i am bad at soldering)

I fdisk the key, but i cannot disklabel it ( out of inode )

OpenBSD 5.5-current (RAMDISK_CD) #2: Mon Mar 17 17:19:05 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 4143271936 (3951MB)
avail mem = 4027494400 (3840MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb630 (78 entries)
bios0: vendor American Megatrends Inc. version 7920D103 date 01/07/2013
bios0: NORCO BPC-7920
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT ASF!
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2197.54 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,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (PEG3)
acpiprt5 at acpi0: bus -1 (P0P1)
acpiprt6 at acpi0: bus 1 (RP01)
acpiprt7 at acpi0: bus 2 (RP02)
acpiprt8 at acpi0: bus 3 (RP03)
acpiprt9 at acpi0: bus 4 (RP04)
acpiprt10 at acpi0: bus 5 (RP05)
acpiprt11 at acpi0: bus -1 (RP06)
acpiprt12 at acpi0: bus -1 (RP07)
acpiprt13 at acpi0: bus -1 (RP08)
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09
vga1 at pci0 dev 2 function 0 Intel HD Graphics 3000 rev 0x09
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
Intel 7 Series xHCI rev 0x04 at pci0 dev 20 function 0 not configured
Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured
Intel 7 Series KT rev 0x04 at pci0 dev 22 function 3 not configured
em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address
00:50:c2:21:60:70
ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
Intel 7 Series HD Audio rev 0x04 at pci0 dev 27 function 0 not configured
ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi
pci1 at ppb0 bus 1
em1 at pci1 dev 0 function 0 Intel 82583V rev 0x00: msi, address
00:50:c2:21:60:6b
ppb1 at pci0 dev 28 function 1 Intel 7 Series PCIE rev 0xc4: msi
pci2 at ppb1 bus 2
em2 at pci2 dev 0 function 0 Intel 82583V rev 0x00: msi, address
00:50:c2:21:60:6c
ppb2 at pci0 dev 28 function 2 Intel 7 Series PCIE rev 0xc4: msi
pci3 at ppb2 bus 3
em3 at pci3 dev 0 function 0 Intel 82583V rev 0x00: msi, address
00:50:c2:21:60:6d
ppb3 at pci0 dev 28 function 3 Intel 7 Series PCIE rev 0xc4: msi
pci4 at ppb3 bus 4
em4 at pci4 dev 0 function 0 Intel 82583V rev 0x00: msi, address
00:50:c2:21:60:6e
ppb4 at pci0 dev 28 function 4 Intel 7 Series PCIE rev 0xc4: msi
pci5 at ppb4 bus 5
em5 at pci5 dev 0 function 0 Intel 82583V rev 0x00: msi, address
00:50:c2:21:60:6f
ehci1 at pci0 dev 29 function 0 Intel 7 Series USB rev 0x04: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
Intel QM77 LPC rev 0x04 at pci0 dev 31 function 0 not configured
ahci0 at pci0 dev 31 function 2 Intel 7 Series AHCI rev 0x04: msi, AHCI 1.3
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, ST9160314AS, 0001 SCSI3 0/direct
fixed naa.5000c50022660557
sd0: 152627MB, 512 bytes/sector, 312581808 sectors
Intel 7 Series SMBus rev 0x04 at pci0 dev 31 function 3 not configured
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
uhub2 at uhub0 port 1 vendor 0x8087 product 0x0024 rev 2.00/0.00 addr 2
uhidev0 at uhub2 port 2 configuration 1 interface 0 Dell Dell USB
Keyboard rev 1.10/3.06 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhub3 at uhub1 port 1 vendor 0x8087 product 0x0024 rev 2.00/0.00 addr 2
umass0 at uhub3 port 4 configuration 1 interface 0 Kingston
DataTraveler G2 rev 2.00/2.00 addr 3

Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

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

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

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

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

Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

2014-03-18 Thread sven falempin 
On Tue, Mar 18, 2014 at 12:39 PM, Chris Cappuccio ch...@nmedia.net wrote:

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

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


the installer proposed http and i was not able to go to the right disk



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

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




-- 
-
() ascii ribbon campaign - against html e-mail
/\