Intel i210AT NICs

2014-02-06 Thread Marc Peters
Hi List,

we have a couple of Supermicro boxes with Supmicro X10SLM+-LN4F Boards.
These are featuring the Intel i210AT Chipsets. Are there any plans or
patches to get them working? Downloaded today's snapshot but they aren't
getting configured either.

Is anyone working on it (and have a patch for me to test ;))?

dmesg below.

Cheers,
Marc

dmesg:

OpenBSD 5.5-beta (GENERIC.MP) #284: Mon Feb  3 07:57:32 MST 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8531181568 (8135MB)
avail mem = 8295866368 (7911MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec090 (38 entries)
bios0: vendor American Megatrends Inc. version 1.1a date 11/01/2013
bios0: Supermicro X10SLM+-LN4F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT SSDT SSDT MCFG PRAD
HPET SSDT SSDT SPMI DMAR EINJ ERST HEST BERT
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4)
RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP07(S4) PXSX(S4)
RP08(S4) GLAN(S4) EHC1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz, 3100.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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
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.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz, 3100.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz, 3100.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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz, 3100.00 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 4 (RP04)
acpiprt4 at acpi0: bus 5 (RP07)
acpiprt5 at acpi0: bus 6 (RP08)
acpiprt6 at acpi0: bus -1 (PEG0)
acpiec0 at acpi0: Failed to read resource settings
acpicpu0 at acpi0: C1, PSS
acpicpu1 at acpi0: C1, PSS
acpicpu2 at acpi0: C1, PSS
acpicpu3 at acpi0: C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 3100 MHz: speeds: 3101, 3100, 2900, 2800, 2600,
2400, 2300, 2100, 1900, 1800, 1600, 1500, 1300, 1100, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product 0x0c08
rev 0x06
Intel 8 Series xHCI rev 0x05 at pci0 dev 20 function 0 not configured
Intel 8 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured
Intel 8 Series MEI rev 0x04 at pci0 dev 22 function 1 not configured
ehci0 at pci0 dev 26 function 0 Intel 

Re: Intel i210AT NICs

2014-02-06 Thread Jonathan Gray
On Thu, Feb 06, 2014 at 10:26:19AM +0100, Marc Peters wrote:
 Hi List,
 
 we have a couple of Supermicro boxes with Supmicro X10SLM+-LN4F Boards.
 These are featuring the Intel i210AT Chipsets. Are there any plans or
 patches to get them working? Downloaded today's snapshot but they aren't
 getting configured either.
 
 Is anyone working on it (and have a patch for me to test ;))?

I'm not aware of anyone working on this.  It should be possible
to add support within em(4) but it is another mac type/phy type
and it looks like they changed the eeprom access again.

If anyone is interested in donating a card mail me off list
and I'll take a look.



Re: urtw0 wpa2 working on Lemote?

2014-02-06 Thread Sebastian Reitenbach
On Wednesday, February 5, 2014 22:15 CET, Alexey Suslikov 
alexey.susli...@gmail.com wrote: 
 
 Sebastian Reitenbach sebastia at l00-bugdead-prods.de writes:
  Anyways, at work I specify the nwid and the wpakey like this:
  
  ifconfig urtw0 nwid MYID wpakey SECRETKEY up
  
  but status keeps telling me: no network
  however, the manual page tells me that WPA and WPA2 should work.
 
 from ifconfig(8):
 
 wpakey passphrase | hexkey
Set the WPA key and enable WPA.  The key can be given using
either a passphrase or a full length hex key, starting with 0x.
If a passphrase is used the nwid option must be set prior to
specifying the wpakey option, since ifconfig will hash the nwid
along with the passphrase to create the key.
 

stupid /me. I was fairly sure that I also tried it manually, setting the
different values with different commands. I tried it now with a clean boot
in the correct order and it just works.
Thanks for cluebatting ;)

The only thing I still wonder is why all networks I see from a scan
show 143 dB network strength.

Sebastian



Upgrade path from 4.1?

2014-02-06 Thread davy
Hi,

I’ve recently was asked to take over the maintenance of an old OpenBSD machine, 
which has not been updated in the last 7 years. 

Currently the machine has been running for close to 1000 days on 4.1. It has 
been a while since I worked with OpenBSD (shame on me), and I’m really not sure 
what the best way would be to upgrade this machine, knowning I don’t have a 
serial or local access to the box. 

Can I do a 4.1 - 5.4 in one shot? 

thx!
Davy 



Re: Upgrade path from 4.1?

2014-02-06 Thread Kapetanakis Giannis

On 06/02/14 12:49, davy wrote:

Hi,

I’ve recently was asked to take over the maintenance of an old OpenBSD machine, 
which has not been updated in the last 7 years.

Currently the machine has been running for close to 1000 days on 4.1. It has 
been a while since I worked with OpenBSD (shame on me), and I’m really not sure 
what the best way would be to upgrade this machine, knowning I don’t have a 
serial or local access to the box.

Can I do a 4.1 - 5.4 in one shot?

thx!
Davy



The upgrade path has to be 4.1 - 4.2 - 4.3 ... - 5.4

I would suggest
Full Backup - Format - Install 5.4 - reconfigure the system to do the 
same staff


G



Re: Upgrade path from 4.1?

2014-02-06 Thread Andy
Setup 'puppet', then you can reinstall every box, every release and 
have puppet configure everything in 10 mins! ;)


Sorry, sound like I'm boasting! Haha, I just really love that we put in 
the initial effort to get puppet working even though we only have a 
small fleet of OBSD boxes as upgrades, scaling and change control is 
really easy (and so saves what little is left of my sanity) :)


Andy

On Thu 06 Feb 2014 11:24:43 GMT, Kapetanakis Giannis wrote:

On 06/02/14 12:49, davy wrote:

Hi,

I’ve recently was asked to take over the maintenance of an old
OpenBSD machine, which has not been updated in the last 7 years.

Currently the machine has been running for close to 1000 days on 4.1.
It has been a while since I worked with OpenBSD (shame on me), and
I’m really not sure what the best way would be to upgrade this
machine, knowning I don’t have a serial or local access to the box.

Can I do a 4.1 - 5.4 in one shot?

thx!
Davy



The upgrade path has to be 4.1 - 4.2 - 4.3 ... - 5.4

I would suggest
Full Backup - Format - Install 5.4 - reconfigure the system to do
the same staff

G




Re: Upgrade path from 4.1?

2014-02-06 Thread Riccardo Mottola

Hi,

davy wrote:

Hi,

I’ve recently was asked to take over the maintenance of an old OpenBSD machine, 
which has not been updated in the last 7 years.

OpenBSD is stable, isn't it? :)


Currently the machine has been running for close to 1000 days on 4.1. It has 
been a while since I worked with OpenBSD (shame on me), and I’m really not sure 
what the best way would be to upgrade this machine, knowning I don’t have a 
serial or local access to the box.

Can I do a 4.1 - 5.4 in one shot?
No. You should always do a one-by-one update. I got a tach in that too. 
You can skip perhaps one release, but not soo many. I had troubles with 
5.2 - 5.4 which I was able to fix, but I would have spent less time by 
issuing upgrades...


If you have enough disk-space, I'd just download all releases and using 
the very fine upgrade tool... the advantage is that you can keep the 
machine running at any moment and continue at a later stage, quick!


Otherwise, backup, format, reinstall...

Riccardo



Re: Is [binary] package signing planned?

2014-02-06 Thread Marc Espie
On Wed, Feb 05, 2014 at 03:59:57PM -0200, Giancarlo Razzolini wrote:
 Em 04-02-2014 18:03, Marc Espie escreveu:
  I *encourage* you guys to read signify and pkg_add code and poke holes
  in them! 
 I did read both last night. Signify is very easy and straightforward to
 understand. I wasn't really poking for holes, more for understanding
 than that. The pkg part is a lot more code and I didn't read them all yet.

No kidding. It's cool we have signify, but the pkg_add code was a lot more
effort over quite a few more years :)



Re: Upgrade path from 4.1?

2014-02-06 Thread Marc Espie
On Thu, Feb 06, 2014 at 12:31:44PM +0100, Riccardo Mottola wrote:
 Hi,
 
 davy wrote:
 Hi,
 
 I?ve recently was asked to take over the maintenance of an old OpenBSD 
 machine, which has not been updated in the last 7 years.
 OpenBSD is stable, isn't it? :)
 
 Currently the machine has been running for close to 1000 days on 4.1. It has 
 been a while since I worked with OpenBSD (shame on me), and I?m really not 
 sure what the best way would be to upgrade this machine, knowning I don?t 
 have a serial or local access to the box.
 
 Can I do a 4.1 - 5.4 in one shot?
 No. You should always do a one-by-one update. I got a tach in that
 too. You can skip perhaps one release, but not soo many. I had
 troubles with 5.2 - 5.4 which I was able to fix, but I would have
 spent less time by issuing upgrades...
 
 If you have enough disk-space, I'd just download all releases and
 using the very fine upgrade tool... the advantage is that you can
 keep the machine running at any moment and continue at a later
 stage, quick!
 
 Otherwise, backup, format, reinstall...

From 4.1, I'd recommend figuring out what's special, and reinstall to
a snapshot.

the time_t jump means you're going to have to reinstall base for 5.5
anyways, so save time.



Re: Intel i210AT NICs

2014-02-06 Thread Joerg Goltermann

Hi,

On 06.02.2014 10:26, Marc Peters wrote:

Hi List,

we have a couple of Supermicro boxes with Supmicro X10SLM+-LN4F Boards.
These are featuring the Intel i210AT Chipsets. Are there any plans or
patches to get them working? Downloaded today's snapshot but they aren't
getting configured either.

Is anyone working on it (and have a patch for me to test ;))?



yesterday I got my I210 cards for testing and this is the first
version of a patch. The card can be used but I did rare testing
on it.

I can't find an unknown ethernet device in your attached
dmesg, maybe this device is attached on an unsupported
pci bridge?



It would be really cool if we can get do the split of the em
driver in e1000 and igb to get closer to the original Intel code.
Which will make further updates easier and support a lot of
new features like multiple queues 




Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.275
diff -u -p -r1.275 if_em.c
--- if_em.c 28 Dec 2013 03:34:54 -  1.275
+++ if_em.c 6 Feb 2014 10:49:24 -
@@ -144,6 +144,13 @@ const struct pci_matchid em_devices[] =
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_FIBER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SERDES },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SGMII },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_COPPER },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_FIBER },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SERDES },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SGMII },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_COPPER_NF },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SERDES_NF },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I211_COPPER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_82567V_3 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE_G },
@@ -408,6 +415,8 @@ em_attach(struct device *parent, struct
case em_82575:
case em_82580:
case em_i350:
+   case em_i210:
+   case em_i211:
case em_ich9lan:
case em_ich10lan:
case em_80003es2lan:
@@ -475,7 +484,8 @@ em_attach(struct device *parent, struct
}

if (sc-hw.mac_type == em_80003es2lan || sc-hw.mac_type == em_82575 ||
-   sc-hw.mac_type == em_82580 || sc-hw.mac_type == em_i350) {
+   sc-hw.mac_type == em_82580 || sc-hw.mac_type == em_i350 ||
+   sc-hw.mac_type == em_i210 || sc-hw.mac_type == em_i211 ) {
uint32_t reg = EM_READ_REG(sc-hw, E1000_STATUS);
sc-hw.bus_func = (reg  E1000_STATUS_FUNC_MASK) 
E1000_STATUS_FUNC_SHIFT;
@@ -776,6 +786,10 @@ em_init(void *arg)
case em_i350:
pba = E1000_PBA_32K; /* 32K for Rx, 16K for Tx */
break;
+   case em_i210:
+   case em_i211:
+   pba = E1000_PBA_34K;
+   break;
case em_82573: /* 82573: Total Packet Buffer is 32K */
/* Jumbo frames not supported */
pba = E1000_PBA_12K; /* 12K for Rx, 20K for Tx */
@@ -1119,7 +1133,8 @@ em_encap(struct em_softc *sc, struct mbu
goto fail;

if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82575 
-   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350)
+   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350 
+   sc-hw.mac_type != em_i210  sc-hw.mac_type != em_i211)
em_transmit_checksum_setup(sc, m_head, txd_upper, txd_lower);
else
txd_upper = txd_lower = 0;
@@ -1758,7 +1773,9 @@ em_hardware_init(struct em_softc *sc)
  sc-hw.mac_type == em_82572 ||
  sc-hw.mac_type == em_82575 ||
  sc-hw.mac_type == em_82580 ||
- sc-hw.mac_type == em_i350)) {
+ sc-hw.mac_type == em_i350 ||
+ sc-hw.mac_type == em_i210 ||
+ sc-hw.mac_type == em_i211)) {
uint16_t phy_tmp = 0;

/* Speed up time to link by disabling smart power down */
@@ -1838,13 +1855,15 @@ em_setup_interface(struct em_softc *sc)
ifp-if_capabilities = IFCAP_VLAN_MTU;

 #if NVLAN  0
-   if (sc-hw.mac_type != em_82575  sc-hw.mac_type != em_82580 
-   sc-hw.mac_type != em_i350)
+   if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82580 
+   sc-hw.mac_type != em_i350  sc-hw.mac_type != em_i210 
+   sc-hw.mac_type != em_i211)
ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING;
 #endif

if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82575 
-   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350)
+   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350 
+   sc-hw.mac_type != em_i210  sc-hw.mac_type != em_i211)

Panic using tmpfs on current

2014-02-06 Thread Kim Twain
So, I know this may be the wrong mailing list, well, it is, but I'm a
first time user and I don't think I have enough information to open a
bug report.

I am trying openbsd 5.5 (current) on an smp amd64 machine.

after some late-night experimentations with systrace, I decided that,
for untrusted applications, it would be better to have a separate user
(let's say temp1).

I added, on /etc/rc.local
mount_tmpfs -u temp1 -g temp1 -s 8G tmpfs /home/temp1

to recreate the home directory of the user at every startup. I could
have done it via fstab, I know.


The machine has 16G of ram installed.

I was watching a long (1h+) video with minitube, so data may have
been written to /home/temp1, and I had a kernel panic.

trace:
panic() at panic+0xee
amap_wipeout() at amap_wipeout+0xf0
uvm_unmap_detach() at uvm_unmap_detach+0x90
sys_munmap() at sys_munmap+0x120
syscall() at syscall+0x24f

end trace frame: 0x832e23dc0, count: 0


show map:
MAP 0x81345da5: [0x71880c70a74-0x1c28348]
brk() allocate range: 0xc3c9df7540fa8348-0x90669066
stack allocate range: 0x53e589485590-0x48b486508ec8348
sz=1216454588, ref=838853055, version=2685829333, flags=0x48b48d2

show page:
PAGE 0x81345da5:
flags=40fa8348CLEAN,FAKE,ZERO,FREE,ACTIVE,ENCRYPT,PMAP0,
vers=-1010180235, wire_count=-1872337306, pa=0x53e589485590

uobject=0x71880c70a74, uanon=0xc0854881a01680d5,
offset=0xc28348 loan_count=-1872337306
[page ownership tracking disabled] wm_page_md 0x81345e0d

I also had show mount, show vnode and registers, but apparently output
is truncated...


I'm not sure about the cause, but after the panic, every time I ran
firefox X froze, I couldn't switch back to a tty and had to perform a
hard reset.

now I unmounted the tmpfs over /home/temp1 and so far, I had no trouble.

I did run tmpfs without problems for some time, without specifiying -s
8G and -u temp1 -g temp1.



Re: Intel i210AT NICs

2014-02-06 Thread Marc Peters
On 02/06/14 12:52, Joerg Goltermann wrote:
 Hi,
 
 On 06.02.2014 10:26, Marc Peters wrote:
 Hi List,

 we have a couple of Supermicro boxes with Supmicro X10SLM+-LN4F Boards.
 These are featuring the Intel i210AT Chipsets. Are there any plans or
 patches to get them working? Downloaded today's snapshot but they aren't
 getting configured either.

 Is anyone working on it (and have a patch for me to test ;))?
 
 
 yesterday I got my I210 cards for testing and this is the first
 version of a patch. The card can be used but I did rare testing
 on it.
 
 I can't find an unknown ethernet device in your attached
 dmesg, maybe this device is attached on an unsupported
 pci bridge?

These are the cards:

ppb2 at pci0 dev 28 function 2 Intel 8 Series PCIE rev 0xd5: msi
pci3 at ppb2 bus 3
Intel I210 rev 0x03 at pci3 dev 0 function 0 not configured
ppb3 at pci0 dev 28 function 3 Intel 8 Series PCIE rev 0xd5: msi
pci4 at ppb3 bus 4
Intel I210 rev 0x03 at pci4 dev 0 function 0 not configured
ppb4 at pci0 dev 28 function 6 Intel 8 Series PCIE rev 0xd5: msi
pci5 at ppb4 bus 5
Intel I210 rev 0x03 at pci5 dev 0 function 0 not configured
ppb5 at pci0 dev 28 function 7 Intel 8 Series PCIE rev 0xd5: msi
pci6 at ppb5 bus 6
Intel I210 rev 0x03 at pci6 dev 0 function 0 not configured

It's a quad core onboard.

I will give your patch a try, thanks.

 
 
 
 It would be really cool if we can get do the split of the em
 driver in e1000 and igb to get closer to the original Intel code.
 Which will make further updates easier and support a lot of
 new features like multiple queues 
 
 
 
 
 Index: if_em.c
 ===
 RCS file: /cvs/src/sys/dev/pci/if_em.c,v
 retrieving revision 1.275
 diff -u -p -r1.275 if_em.c
 --- if_em.c28 Dec 2013 03:34:54 -1.275
 +++ if_em.c6 Feb 2014 10:49:24 -
 @@ -144,6 +144,13 @@ const struct pci_matchid em_devices[] =
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_FIBER },
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SERDES },
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SGMII },
 +{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_COPPER },
 +{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_FIBER },
 +{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SERDES },
 +{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SGMII },
 +{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_COPPER_NF },
 +{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SERDES_NF },
 +{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I211_COPPER },
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_82567V_3 },
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE },
  { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE_G },
 @@ -408,6 +415,8 @@ em_attach(struct device *parent, struct
  case em_82575:
  case em_82580:
  case em_i350:
 +case em_i210:
 +case em_i211:
  case em_ich9lan:
  case em_ich10lan:
  case em_80003es2lan:
 @@ -475,7 +484,8 @@ em_attach(struct device *parent, struct
  }
 
  if (sc-hw.mac_type == em_80003es2lan || sc-hw.mac_type ==
 em_82575 ||
 -sc-hw.mac_type == em_82580 || sc-hw.mac_type == em_i350) {
 +sc-hw.mac_type == em_82580 || sc-hw.mac_type == em_i350 ||
 +sc-hw.mac_type == em_i210 || sc-hw.mac_type == em_i211 ) {
  uint32_t reg = EM_READ_REG(sc-hw, E1000_STATUS);
  sc-hw.bus_func = (reg  E1000_STATUS_FUNC_MASK) 
  E1000_STATUS_FUNC_SHIFT;
 @@ -776,6 +786,10 @@ em_init(void *arg)
  case em_i350:
  pba = E1000_PBA_32K; /* 32K for Rx, 16K for Tx */
  break;
 +case em_i210:
 +case em_i211:
 +pba = E1000_PBA_34K;
 +break;
  case em_82573: /* 82573: Total Packet Buffer is 32K */
  /* Jumbo frames not supported */
  pba = E1000_PBA_12K; /* 12K for Rx, 20K for Tx */
 @@ -1119,7 +1133,8 @@ em_encap(struct em_softc *sc, struct mbu
  goto fail;
 
  if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82575 
 -sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350)
 +sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350 
 +sc-hw.mac_type != em_i210  sc-hw.mac_type != em_i211)
  em_transmit_checksum_setup(sc, m_head, txd_upper, txd_lower);
  else
  txd_upper = txd_lower = 0;
 @@ -1758,7 +1773,9 @@ em_hardware_init(struct em_softc *sc)
sc-hw.mac_type == em_82572 ||
sc-hw.mac_type == em_82575 ||
sc-hw.mac_type == em_82580 ||
 -  sc-hw.mac_type == em_i350)) {
 +  sc-hw.mac_type == em_i350 ||
 +  sc-hw.mac_type == em_i210 ||
 +  sc-hw.mac_type == em_i211)) {
  uint16_t phy_tmp = 0;
 
  /* Speed up time to link by disabling smart power down */
 @@ -1838,13 +1855,15 @@ em_setup_interface(struct em_softc *sc)
  ifp-if_capabilities = IFCAP_VLAN_MTU;
 
  #if NVLAN  0
 -if (sc-hw.mac_type != em_82575  sc-hw.mac_type != em_82580 
 -

Re: Upgrade path from 4.1?

2014-02-06 Thread Nick Holland
On 02/06/14 05:49, davy wrote:
 Hi,
 
 I’ve recently was asked to take over the maintenance of an old
 OpenBSD machine, which has not been updated in the last 7 years.
 
 Currently the machine has been running for close to 1000 days on 4.1.
 It has been a while since I worked with OpenBSD (shame on me), and
 I’m really not sure what the best way would be to upgrade this
 machine, knowning I don’t have a serial or local access to the box.
 
 Can I do a 4.1 - 5.4 in one shot?
 
 thx! Davy
 

You have a seven+ year old machine, with comparibly old disks.

My suggestion:
Build out a new machine using -current (yes, not 5.4.  you have a big
bump coming with 5.4 to 5.5, but if you install -current now, you are
over the bump...then start back on releases/stable with 5.5).  Configure
the new machine exactly as you want it.  Now, put it in service, decom
the old machine...or minimum, swap the disks out of the old machine with
these newly configured disks.

This way, you never lose your functioning system...and you can freshen
your hardware, too.

Nick.



Re: Upgrade path from 4.1?

2014-02-06 Thread davy van de moere
Hmm, you do have an excellent point there. Those disks, it's a miracle they
're still working. I'll think the re-start from bare metal is the best way
forward.

Thank you for your honest answers! At least I didn't get frustrated because
of upgrade hell! :)




2014-02-06 Nick Holland n...@holland-consulting.net:

 On 02/06/14 05:49, davy wrote:
  Hi,
 
  I've recently was asked to take over the maintenance of an old
  OpenBSD machine, which has not been updated in the last 7 years.
 
  Currently the machine has been running for close to 1000 days on 4.1.
  It has been a while since I worked with OpenBSD (shame on me), and
  I'm really not sure what the best way would be to upgrade this
  machine, knowning I don't have a serial or local access to the box.
 
  Can I do a 4.1 - 5.4 in one shot?
 
  thx! Davy
 

 You have a seven+ year old machine, with comparibly old disks.

 My suggestion:
 Build out a new machine using -current (yes, not 5.4.  you have a big
 bump coming with 5.4 to 5.5, but if you install -current now, you are
 over the bump...then start back on releases/stable with 5.5).  Configure
 the new machine exactly as you want it.  Now, put it in service, decom
 the old machine...or minimum, swap the disks out of the old machine with
 these newly configured disks.

 This way, you never lose your functioning system...and you can freshen
 your hardware, too.

 Nick.



Re: Intermittent stops in network traffic with urtw interface

2014-02-06 Thread Alexey Suslikov
Brian Curran brian at brianpcurran.com writes:

  when it stops passing traffic, does issuing ifconfig urtw0 scan help?
  
 
 I test this just now and it seemed to help, although I only started
 seeing ping replies about 10 seconds after issuing the scan. There is
 a similar small delay, though usually not as long, when bringing the
 interface down then up.
 
 Also maybe of note is that the status of the interface as reported by
 ifconfig remains active when it is not receiving any traffic.

I have urtwn(4) which also experience intermittent stops
with some Access Points (not all).

Looks like it is common problem for urtw(4) and urtwn(4).



Re: Intermittent stops in network traffic with urtw interface

2014-02-06 Thread Brad Smith

On 06/02/14 9:25 AM, Alexey Suslikov wrote:

Brian Curran brian at brianpcurran.com writes:


when it stops passing traffic, does issuing ifconfig urtw0 scan help?



I test this just now and it seemed to help, although I only started
seeing ping replies about 10 seconds after issuing the scan. There is
a similar small delay, though usually not as long, when bringing the
interface down then up.

Also maybe of note is that the status of the interface as reported by
ifconfig remains active when it is not receiving any traffic.


I have urtwn(4) which also experience intermittent stops
with some Access Points (not all).

Looks like it is common problem for urtw(4) and urtwn(4).


and rsu(4).


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: Upgrade path from 4.1?

2014-02-06 Thread L. V. Lammert
On Thu, 6 Feb 2014, davy wrote:

 Can I do a 4.1 - 5.4 in one shot?

Nope. One version at a time, .. though the better solution would be to do
a fresh install and copy data.

Lee



Re: Intel i210AT NICs

2014-02-06 Thread Marc Peters
On 02/06/14 13:58, Marc Peters wrote:
 On 02/06/14 12:52, Joerg Goltermann wrote:
 
 These are the cards:
 
 ppb2 at pci0 dev 28 function 2 Intel 8 Series PCIE rev 0xd5: msi
 pci3 at ppb2 bus 3
 Intel I210 rev 0x03 at pci3 dev 0 function 0 not configured
 ppb3 at pci0 dev 28 function 3 Intel 8 Series PCIE rev 0xd5: msi
 pci4 at ppb3 bus 4
 Intel I210 rev 0x03 at pci4 dev 0 function 0 not configured
 ppb4 at pci0 dev 28 function 6 Intel 8 Series PCIE rev 0xd5: msi
 pci5 at ppb4 bus 5
 Intel I210 rev 0x03 at pci5 dev 0 function 0 not configured
 ppb5 at pci0 dev 28 function 7 Intel 8 Series PCIE rev 0xd5: msi
 pci6 at ppb5 bus 6
 Intel I210 rev 0x03 at pci6 dev 0 function 0 not configured
 
 It's a quad core onboard.
 
 I will give your patch a try, thanks.
 

Cards are working and cvs checkout looked good. Will test a bit more and
report success or failure.



Re: Upgrade path from 4.1?

2014-02-06 Thread Kenneth Westerback
Shudder. NO! :-)

Aside from the very valid hardware concerns Nick mentioned, there are
too many flag days of various kinds strewn along that path. Skip them
all, start fresh with a -current
snapshot.

 Ken

On 6 February 2014 05:49, davy davy.van.de.mo...@gmail.com wrote:
 Hi,

 I've recently was asked to take over the maintenance of an old OpenBSD 
 machine, which has not been updated in the last 7 years.

 Currently the machine has been running for close to 1000 days on 4.1. It has 
 been a while since I worked with OpenBSD (shame on me), and I'm really not 
 sure what the best way would be to upgrade this machine, knowning I don't 
 have a serial or local access to the box.

 Can I do a 4.1 - 5.4 in one shot?

 thx!
 Davy



Re: Intel i210AT NICs

2014-02-06 Thread Joerg Goltermann

On 06.02.2014 12:52, Joerg Goltermann wrote:

Hi,

On 06.02.2014 10:26, Marc Peters wrote:

Hi List,

we have a couple of Supermicro boxes with Supmicro X10SLM+-LN4F Boards.
These are featuring the Intel i210AT Chipsets. Are there any plans or
patches to get them working? Downloaded today's snapshot but they aren't
getting configured either.

Is anyone working on it (and have a patch for me to test ;))?




Updated, against the latest tree:

Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.275
diff -u -p -r1.275 if_em.c
--- if_em.c 28 Dec 2013 03:34:54 -  1.275
+++ if_em.c 6 Feb 2014 14:48:32 -
@@ -144,6 +144,13 @@ const struct pci_matchid em_devices[] =
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_FIBER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SERDES },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SGMII },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_COPPER },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_FIBER },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SERDES },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SGMII },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_COPPER_NF },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SERDES_NF },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I211_COPPER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_82567V_3 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE_G },
@@ -408,6 +415,8 @@ em_attach(struct device *parent, struct
case em_82575:
case em_82580:
case em_i350:
+   case em_i210:
+   case em_i211:
case em_ich9lan:
case em_ich10lan:
case em_80003es2lan:
@@ -475,7 +484,8 @@ em_attach(struct device *parent, struct
}

if (sc-hw.mac_type == em_80003es2lan || sc-hw.mac_type == em_82575 ||
-   sc-hw.mac_type == em_82580 || sc-hw.mac_type == em_i350) {
+   sc-hw.mac_type == em_82580 || sc-hw.mac_type == em_i350 ||
+   sc-hw.mac_type == em_i210 || sc-hw.mac_type == em_i211 ) {
uint32_t reg = EM_READ_REG(sc-hw, E1000_STATUS);
sc-hw.bus_func = (reg  E1000_STATUS_FUNC_MASK) 
E1000_STATUS_FUNC_SHIFT;
@@ -776,6 +786,10 @@ em_init(void *arg)
case em_i350:
pba = E1000_PBA_32K; /* 32K for Rx, 16K for Tx */
break;
+   case em_i210:
+   case em_i211:
+   pba = E1000_PBA_34K;
+   break;
case em_82573: /* 82573: Total Packet Buffer is 32K */
/* Jumbo frames not supported */
pba = E1000_PBA_12K; /* 12K for Rx, 20K for Tx */
@@ -1119,7 +1133,8 @@ em_encap(struct em_softc *sc, struct mbu
goto fail;

if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82575 
-   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350)
+   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350 
+   sc-hw.mac_type != em_i210  sc-hw.mac_type != em_i211)
em_transmit_checksum_setup(sc, m_head, txd_upper, txd_lower);
else
txd_upper = txd_lower = 0;
@@ -1758,7 +1773,9 @@ em_hardware_init(struct em_softc *sc)
  sc-hw.mac_type == em_82572 ||
  sc-hw.mac_type == em_82575 ||
  sc-hw.mac_type == em_82580 ||
- sc-hw.mac_type == em_i350)) {
+ sc-hw.mac_type == em_i350 ||
+ sc-hw.mac_type == em_i210 ||
+ sc-hw.mac_type == em_i211)) {
uint16_t phy_tmp = 0;

/* Speed up time to link by disabling smart power down */
@@ -1838,13 +1855,15 @@ em_setup_interface(struct em_softc *sc)
ifp-if_capabilities = IFCAP_VLAN_MTU;

 #if NVLAN  0
-   if (sc-hw.mac_type != em_82575  sc-hw.mac_type != em_82580 
-   sc-hw.mac_type != em_i350)
+   if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82580 
+   sc-hw.mac_type != em_i350  sc-hw.mac_type != em_i210 
+   sc-hw.mac_type != em_i211)
ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING;
 #endif

if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82575 
-   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350)
+   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350 
+   sc-hw.mac_type != em_i210  sc-hw.mac_type != em_i211)
ifp-if_capabilities |= IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;

/*
@@ -2199,7 +2218,8 @@ em_initialize_transmit_unit(struct em_so
sc-txd_cmd = E1000_TXD_CMD_IFCS;

if (sc-hw.mac_type == em_82575 || sc-hw.mac_type == em_82580 ||
-   sc-hw.mac_type == em_i350) {
+   sc-hw.mac_type == em_i350 || sc-hw.mac_type == em_i210 ||
+   sc-hw.mac_type == em_i211) {
   

Re: Upgrade path from 4.1?

2014-02-06 Thread Marc Espie
Heck, even pkg_add won't be too happy.

I've finally scraped a few compatibility items that were around 7 years
ago, like support for @md5 checksums...



Re: Upgrade path from 4.1?

2014-02-06 Thread L. V. Lammert
On Thu, 6 Feb 2014, Kenneth Westerback wrote:

 Shudder. NO! :-)

 Aside from the very valid hardware concerns Nick mentioned, there are
 too many flag days of various kinds strewn along that path. Skip them
 all, start fresh with a -current
 snapshot.

Much better to start with new CD set, eh?

Lee



Re: Upgrade path from 4.1?

2014-02-06 Thread Kenneth Westerback
On 6 February 2014 11:44, L. V. Lammert l...@omnitec.net wrote:
 On Thu, 6 Feb 2014, Kenneth Westerback wrote:

 Shudder. NO! :-)

 Aside from the very valid hardware concerns Nick mentioned, there are
 too many flag days of various kinds strewn along that path. Skip them
 all, start fresh with a -current
 snapshot.

 Much better to start with new CD set, eh?

Well, that would imply waiting for May 1 or whenever the physical CD's
are available.

Starting now with a -current snapshot means getting everything working
in the meantime and then ordering the new CD's and installing the
-release (or -stable) files without worrying about flag days. We are
very close to locking 5.5 so very little major will be changing
between now and CD delivery.

 Ken


 Lee



Re: Upgrade path from 4.1?

2014-02-06 Thread L. V. Lammert
On Thu, 6 Feb 2014, Kenneth Westerback wrote:

 Well, that would imply waiting for May 1 or whenever the physical CD's
 are available.

5.4 is available now, ..

 Starting now with a -current snapshot means getting everything working
 in the meantime and then ordering the new CD's and installing the

Far better to recommend CD installs, .. -current or -release may require a
tad more expertise to manage.

Lee



Re: Upgrade path from 4.1?

2014-02-06 Thread Chris Cappuccio
L. V. Lammert [l...@omnitec.net] wrote:
 On Thu, 6 Feb 2014, davy wrote:
 
  Can I do a 4.1 - 5.4 in one shot?
 
 Nope. One version at a time, .. though the better solution would be to do
 a fresh install and copy data.
 

I don't see why everyone recommends install one version at a time.
It is insane. Except for the time_t bump, i'd just upgrade. With the
bump, I'd either upgrade if it was a remote system, or do a fresh 
install. There may be gotchas that you can only figure out by replicating
it locally first. But there is no requirement in OpenBSD to upgrade
one version at a time that is just a total fucking waste of time and
bandwidth.



Re: Upgrade path from 4.1?

2014-02-06 Thread Chris Cappuccio
L. V. Lammert [l...@omnitec.net] wrote:
 On Thu, 6 Feb 2014, davy wrote:
 
  Can I do a 4.1 - 5.4 in one shot?
 
 Nope. One version at a time, .. though the better solution would be to do
 a fresh install and copy data.
 

What I'm recommending isn't really an upgrade so much as using the old
box to bootstrap a newest snapshot. As long as the bootblocks are still
compatible, you can do it.



Re: openvpn in rdomain hangs

2014-02-06 Thread Chris Cappuccio
Giancarlo Razzolini [grazzol...@gmail.com] wrote:
 I've used rdomains, but not for this. In this case I would use mpath and
 pf only. I really do not see the need for using rdomains in this case.
 It introduces too much complexity for a simple thing.
 

That's nice. But what about the problem?



Re: Upgrade path from 4.1?

2014-02-06 Thread L. V. Lammert
On Thu, 6 Feb 2014, Chris Cappuccio wrote:

 I don't see why everyone recommends install one version at a time.

It's not a recommendation, it is reality. Each upgrade is based on the
previuos version - skipping versions is not supported.

Lee



Re: Upgrade path from 4.1?

2014-02-06 Thread L. V. Lammert
On Thu, 6 Feb 2014, Chris Cappuccio wrote:

 What I'm recommending isn't really an upgrade so much as using the old
 box to bootstrap a newest snapshot. As long as the bootblocks are still
 compatible, you can do it.

Why? A clean build on a new machine would be the best solution in that
case, .. then reconfigure with data from the old box/disk.

Also, it is not good to recommend snapshots - most users do not need that
level of complexity. CDs are a much better alternative, and give something
back to the project. You DO purchase more than one set of CDs for every
release, right?

Lee



Re: Upgrade path from 4.1?

2014-02-06 Thread Brad Smith

On 06/02/14 12:45 PM, L. V. Lammert wrote:

On Thu, 6 Feb 2014, Chris Cappuccio wrote:


I don't see why everyone recommends install one version at a time.


It's not a recommendation, it is reality. Each upgrade is based on the
previuos version - skipping versions is not supported.


There is a difference between supported and supported. What Chris said
is true. Its the difference between people blindly following how-to's
and actually understanding what they're doing and this is not very
complex at all.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: Upgrade path from 4.1?

2014-02-06 Thread Kenneth Westerback
On 6 February 2014 12:31, L. V. Lammert l...@omnitec.net wrote:
 On Thu, 6 Feb 2014, Kenneth Westerback wrote:

 Well, that would imply waiting for May 1 or whenever the physical CD's
 are available.

 5.4 is available now, ..

 Starting now with a -current snapshot means getting everything working
 in the meantime and then ordering the new CD's and installing the

 Far better to recommend CD installs, .. -current or -release may require a
 tad more expertise to manage.

 Lee

I violently disagree! And particularly in this case. Where it would be
far better to
avoid one whole upgrade cycle by getting the environment working with
-current and moving to 5.5-stable safe in the knowledge that you don't
have to re-check for flag days,  configuration parsing changes, etc.

Now, *buying* CD's is always highly recommended. The more the better!

 Ken



Re: Upgrade path from 4.1?

2014-02-06 Thread Marc Espie
On Thu, Feb 06, 2014 at 11:45:52AM -0600, L. V. Lammert wrote:
 On Thu, 6 Feb 2014, Chris Cappuccio wrote:
 
  I don't see why everyone recommends install one version at a time.
 
 It's not a recommendation, it is reality. Each upgrade is based on the
 previuos version - skipping versions is not supported.
 
   Lee

Nah, if you know what you're doing you can skip lots of versions.
It's not recommmended because if you fuck up, well, you're on your own.

Developers will laugh at you and not help (even more so than usual, I mean)



Re: Upgrade path from 4.1?

2014-02-06 Thread Kenneth Westerback
On 6 February 2014 12:40, Chris Cappuccio ch...@nmedia.net wrote:
 L. V. Lammert [l...@omnitec.net] wrote:
 On Thu, 6 Feb 2014, davy wrote:

  Can I do a 4.1 - 5.4 in one shot?
 
 Nope. One version at a time, .. though the better solution would be to do
 a fresh install and copy data.


 What I'm recommending isn't really an upgrade so much as using the old
 box to bootstrap a newest snapshot. As long as the bootblocks are still
 compatible, you can do it.


And, surprise!, boot blocks do change. 5.5 will be an example as things are
rearranged and unified.

 Ken



Re: Upgrade path from 4.1?

2014-02-06 Thread Kenneth Westerback
On 6 February 2014 12:40, Chris Cappuccio ch...@nmedia.net wrote:
 L. V. Lammert [l...@omnitec.net] wrote:
 On Thu, 6 Feb 2014, davy wrote:

  Can I do a 4.1 - 5.4 in one shot?
 
 Nope. One version at a time, .. though the better solution would be to do
 a fresh install and copy data.


 What I'm recommending isn't really an upgrade so much as using the old
 box to bootstrap a newest snapshot. As long as the bootblocks are still
 compatible, you can do it.



Re: Upgrade path from 4.1?

2014-02-06 Thread L. V. Lammert
On Thu, 6 Feb 2014, Marc Espie wrote:

 Nah, if you know what you're doing you can skip lots of versions.
 It's not recommmended because if you fuck up, well, you're on your own.

The OP gave no such indication, .. hence my recommendation for
step-by-step or new machine.

 Developers will laugh at you and not help (even more so than usual, I mean)

AND create a lot of troll fodder, .. best avoided.

Lee



Re: Upgrade path from 4.1?

2014-02-06 Thread Ted Unangst
On Thu, Feb 06, 2014 at 13:03, L. V. Lammert wrote:
 On Thu, 6 Feb 2014, Marc Espie wrote:
 
 Nah, if you know what you're doing you can skip lots of versions.
 It's not recommmended because if you fuck up, well, you're on your own.

 The OP gave no such indication, .. hence my recommendation for
 step-by-step or new machine.

well, none of 4.2, 4.3, 4.4, 4.5, , ... are supported now either, or
even available on most ftp mirrors, so any problems encountered midway
through will be met with the same response of try something newer.



Re: Upgrade path from 4.1?

2014-02-06 Thread Matt M
Your best option would be to backup data and configs, and reinstall fresh.
There are so many releases between 4.1 and 5.4 that you're going to spend a
lot of time just to get to -current or -stable 5.4, while you're still
gonna have to modify config files that have changes since 4.1 that it
probably wouldn't be worth the time and effort. As far as skipping
versions, first you're gonna have a lot of issues going straight from 4.1
to 5.4. If you just look at the changelogs between each version, you'll see
a lot of things have been removed or considered defunct, and configuration
for services may have changed dramatically (pf and softraid, for example).

Do yourself the favor and save the headaches by just reloading fresh and
porting over any configs.


On Thu, Feb 6, 2014 at 4:49 AM, davy davy.van.de.mo...@gmail.com wrote:

 Hi,

 I've recently was asked to take over the maintenance of an old OpenBSD
 machine, which has not been updated in the last 7 years.

 Currently the machine has been running for close to 1000 days on 4.1. It
 has been a while since I worked with OpenBSD (shame on me), and I'm really
 not sure what the best way would be to upgrade this machine, knowning I
 don't have a serial or local access to the box.

 Can I do a 4.1 - 5.4 in one shot?

 thx!
 Davy



Re: Upgrade path from 4.1?

2014-02-06 Thread Chris Cappuccio
L. V. Lammert [l...@omnitec.net] wrote:
 On Thu, 6 Feb 2014, Chris Cappuccio wrote:
 
  I don't see why everyone recommends install one version at a time.
 
 It's not a recommendation, it is reality. Each upgrade is based on the
 previuos version - skipping versions is not supported.
 

Because it takes a little more knowledge of what changes between releases.

Nobody who uses OpenBSD in a serious capacity sits around upgrading from
release to release. That advice is for people who follow directions for
upgrading from each release to each successive release. 



Re: Upgrade path from 4.1?

2014-02-06 Thread Chris Cappuccio
Kenneth Westerback [kwesterb...@gmail.com] wrote:
 
 And, surprise!, boot blocks do change. 5.5 will be an example as things are
 rearranged and unified.
 

But you can still use old bootblocks to run the new kernel as a bootstrap

You don't get the proper random seed functionality until you update your 
bootblocks,
so obviously, do so.

I'm not sure there was ever a release where old bootblocks wouldn't work with
a new kernel, at least on amd64.



Re: Upgrade path from 4.1?

2014-02-06 Thread Jiri B
Back to reality... Let's suppose I have very old OpenBSD box
like it was written.

Usually data should be OK (ftp data, web data, DB data dump??...), but can
I just copy for example /etc/master.passwd to a new fresh installed 5.5-current?
I'm asking because one had to regenerate /etc/{pwd,spwd}.db files
(http://www.openbsd.org/faq/current.html#20130813)?

I think upgraded one by one is bizarre but one should know what
part of OS was involved in old data, so he can be sure such old
data are still usable.

Any advices where one should be careful if one is trying to import
data from very old OpenBSD to latest versions? (In current.html
there's at least rrdtool, but are there any others?)

jirib



Re: Upgrade path from 4.1?

2014-02-06 Thread Chris Cappuccio
Brad Smith [b...@comstyle.com] wrote:
 On 06/02/14 12:45 PM, L. V. Lammert wrote:
 On Thu, 6 Feb 2014, Chris Cappuccio wrote:
 
 I don't see why everyone recommends install one version at a time.
 
 It's not a recommendation, it is reality. Each upgrade is based on the
 previuos version - skipping versions is not supported.
 
 There is a difference between supported and supported. What Chris said
 is true. Its the difference between people blindly following how-to's
 and actually understanding what they're doing and this is not very
 complex at all.
 

There are some complexities, and I have most of them memorized, so if someone
wants to discuss how to do this on the list, just ask.

I dare say this instruction set will even work for a jump from 4.1, although
I wouldn't guarantee it :)

So, to jump over the time_t bump remotely, I typically do something like:

echo /usr/sbin/pwd_mkdb /etc/master.passwd /etc/rc.local
cp /sbin/reboot /reboot
mv /distloc/bsd.mp /bsd
cd /
rm -r /usr/X11R6 /usr/include /usr/share /var/log/lastlog /var/log/wtmp
touch /var/log/lastlog /var/log/wtmp
pkg_info -mq /root/pkg_list_manual
pkg_info -q /root/pkg_list_full
do anything else related to your ports like dump SQL database tables
tar xzpf /distloc/base55.tgz
now you can no longer run old binaries, goodbye!
/reboot

That's as far as you can go once the new ABI is unpacked over the old
system!!

Now when you reboot, you have an old set of /etc scripts, and non-functional
compiler, X11, packages, etc. But you have a working base system that you
can finish the rest with. Basic finish:

cd /
tar xzpf /distloc/comp55.tgz
tar xzpf /distloc/man55.tgz
tar xzpf /distloc/game55.tgz
cd /dev
./MAKEDEV all
installboot rootdisk0

And if you want X11 for server-only (no workstation) the also unpack xbase55
and xshare55. If you are sitting at a workstation, you're better off using
bsd.rd and 'U'pgrade.

Now you can replace all packages, upgrade /etc with sysmerge or by hand,
and reinstall packages like so:

pkg_add -z -l /root/pkg_list_manual
pkg_add -za -l /root/pkg_list_full

Also you are good to clean up old shared object crap out of /usr/lib.
You can identify these because they will have old timestamps in ls -l.

Now, reboot again and you are fully upgraded. Reinstall any SQL
databases or whatever by hand too.

I skipped a lot of the 'rm /usr/share/man/blah' crap because it's
already removed in the rm -r step. But with the ABI change, you
will want to clean out old binaries from /usr/bin, /usr/sbin, and so on.

Honestly I've never used sysmerge and would probably benefit by learning
it. I did steal the pkg_list idea from faq/current.html. That is always
a good place to look when you're fucking around like this.

If you have remote IPMI access, you might be better off just following
the faq directions and doing bsd.rd upgrade. Beats me. I don't have IPMI.
Most of the work involved here you have to do anyways, like dump/restore
databases, reinstall packages, sysmerge or hand-merge /etc, and so on.

Chris



Re: Intel i210AT NICs

2014-02-06 Thread Joerg Goltermann

Thanks Brad, here is an updated version:



Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.275
diff -u -p -r1.275 if_em.c
--- if_em.c 28 Dec 2013 03:34:54 -  1.275
+++ if_em.c 6 Feb 2014 21:00:48 -
@@ -144,6 +144,13 @@ const struct pci_matchid em_devices[] =
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_FIBER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SERDES },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I350_SGMII },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_COPPER },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_FIBER },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SERDES },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SGMII },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_COPPER_NF },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I210_SERDES_NF },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I211_COPPER },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_82567V_3 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_ICH8_IFE_G },
@@ -408,6 +415,8 @@ em_attach(struct device *parent, struct
case em_82575:
case em_82580:
case em_i350:
+   case em_i210:
+   case em_i211:
case em_ich9lan:
case em_ich10lan:
case em_80003es2lan:
@@ -475,7 +484,8 @@ em_attach(struct device *parent, struct
}
 
 	if (sc-hw.mac_type == em_80003es2lan || sc-hw.mac_type == em_82575 ||

-   sc-hw.mac_type == em_82580 || sc-hw.mac_type == em_i350) {
+   sc-hw.mac_type == em_82580 || sc-hw.mac_type == em_i350 ||
+   sc-hw.mac_type == em_i210 || sc-hw.mac_type == em_i211 ) {
uint32_t reg = EM_READ_REG(sc-hw, E1000_STATUS);
sc-hw.bus_func = (reg  E1000_STATUS_FUNC_MASK) 
E1000_STATUS_FUNC_SHIFT;
@@ -776,6 +786,10 @@ em_init(void *arg)
case em_i350:
pba = E1000_PBA_32K; /* 32K for Rx, 16K for Tx */
break;
+   case em_i210:
+   case em_i211:
+   pba = E1000_PBA_34K;
+   break;
case em_82573: /* 82573: Total Packet Buffer is 32K */
/* Jumbo frames not supported */
pba = E1000_PBA_12K; /* 12K for Rx, 20K for Tx */
@@ -1119,7 +1133,8 @@ em_encap(struct em_softc *sc, struct mbu
goto fail;
 
 	if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82575 

-   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350)
+   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350 
+   sc-hw.mac_type != em_i210  sc-hw.mac_type != em_i211)
em_transmit_checksum_setup(sc, m_head, txd_upper, txd_lower);
else
txd_upper = txd_lower = 0;
@@ -1758,7 +1773,9 @@ em_hardware_init(struct em_softc *sc)
  sc-hw.mac_type == em_82572 ||
  sc-hw.mac_type == em_82575 ||
  sc-hw.mac_type == em_82580 ||
- sc-hw.mac_type == em_i350)) {
+ sc-hw.mac_type == em_i350 ||
+ sc-hw.mac_type == em_i210 ||
+ sc-hw.mac_type == em_i211)) {
uint16_t phy_tmp = 0;
 
 		/* Speed up time to link by disabling smart power down */

@@ -1838,13 +1855,15 @@ em_setup_interface(struct em_softc *sc)
ifp-if_capabilities = IFCAP_VLAN_MTU;
 
 #if NVLAN  0

-   if (sc-hw.mac_type != em_82575  sc-hw.mac_type != em_82580 
-   sc-hw.mac_type != em_i350)
+   if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82580 
+   sc-hw.mac_type != em_i350  sc-hw.mac_type != em_i210 
+   sc-hw.mac_type != em_i211)
ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING;
 #endif
 
 	if (sc-hw.mac_type = em_82543  sc-hw.mac_type != em_82575 

-   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350)
+   sc-hw.mac_type != em_82580  sc-hw.mac_type != em_i350 
+   sc-hw.mac_type != em_i210  sc-hw.mac_type != em_i211)
ifp-if_capabilities |= IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4;
 
 	/*

@@ -2199,7 +2218,8 @@ em_initialize_transmit_unit(struct em_so
sc-txd_cmd = E1000_TXD_CMD_IFCS;
 
 	if (sc-hw.mac_type == em_82575 || sc-hw.mac_type == em_82580 ||

-   sc-hw.mac_type == em_i350) {
+   sc-hw.mac_type == em_i350 || sc-hw.mac_type == em_i210 ||
+   sc-hw.mac_type == em_i211) {
/* 82575/6 need to enable the TX queue and lack the IDE bit */
reg_tctl = E1000_READ_REG(sc-hw, TXDCTL);
reg_tctl |= E1000_TXDCTL_QUEUE_ENABLE;
@@ -2624,7 +2644,8 @@ em_initialize_receive_unit(struct em_sof
 * asked to or not.  So ask for stripped CRC here and
 * cope in rxeof
 */
-   if (sc-hw.mac_type == em_i350)
+   if (sc-hw.mac_type == em_i350 || 

Re: Intermittent stops in network traffic with urtw interface

2014-02-06 Thread Brian Curran
On Thu, Feb 06, 2014 at 09:29:37AM -0500, Brad Smith wrote:
 On 06/02/14 9:25 AM, Alexey Suslikov wrote:
 Brian Curran brian at brianpcurran.com writes:
 
 when it stops passing traffic, does issuing ifconfig urtw0 scan help?
 
 
 I test this just now and it seemed to help, although I only started
 seeing ping replies about 10 seconds after issuing the scan. There is
 a similar small delay, though usually not as long, when bringing the
 interface down then up.
 
 Also maybe of note is that the status of the interface as reported by
 ifconfig remains active when it is not receiving any traffic.
 
 I have urtwn(4) which also experience intermittent stops
 with some Access Points (not all).
 
 Looks like it is common problem for urtw(4) and urtwn(4).
 
 and rsu(4).
 

Also perhaps of note is that 'arp -a' hangs indefinitely while the
interface isn't receiving traffic. I did notice however that I am still
seeing RSTP messages from the router during the outage. The arp command
returns some stuff immediately after I bring the interface down then
back up.

Does anyone have any idea as to how this might be troubleshot further?

FWIW, this is the relevant output of 'usbdevs -v':

port 4 addr 2: high speed, power 500 mA, config 1, RTL8187(0x8187),
Realtek(0x0bda), rev 1.00, iSerialNumber 00C0CA753185

I've seen similar behavior on OpenBSD in years past with various
wireless adapters and have never been able to solve it. I don't want to
go back to Debian and iptables :(((.

-Brian



Re: Intermittent stops in network traffic with urtw interface

2014-02-06 Thread Brian Curran
On Thu, Feb 06, 2014 at 01:37:46PM -0800, Philip Guenther wrote:
 On Thu, Feb 6, 2014 at 1:28 PM, Brian Curran br...@brianpcurran.com wrote:
  Also perhaps of note is that 'arp -a' hangs indefinitely while the
  interface isn't receiving traffic.
 
 arp does IP-hostname lookups by default, which probably involve DNS.
 Condition yourself to use the -n option with arp.
 
A ha, good catch. I thought I had a local DNS server configured but
turns out I had a public one in resolv.conf so that explains the hang.



Re: Intermittent stops in network traffic with urtw interface

2014-02-06 Thread Philip Guenther
On Thu, Feb 6, 2014 at 1:28 PM, Brian Curran br...@brianpcurran.com wrote:
 Also perhaps of note is that 'arp -a' hangs indefinitely while the
 interface isn't receiving traffic.

arp does IP-hostname lookups by default, which probably involve DNS.
Condition yourself to use the -n option with arp.


Philip Guenther



Re: Upgrade path from 4.1?

2014-02-06 Thread Chris Bennett
On Thu, Feb 06, 2014 at 11:56:05AM -0600, L. V. Lammert wrote:
 On Thu, 6 Feb 2014, Chris Cappuccio wrote:
 
  What I'm recommending isn't really an upgrade so much as using the old
  box to bootstrap a newest snapshot. As long as the bootblocks are still
  compatible, you can do it.
 
 Why? A clean build on a new machine would be the best solution in that
 case, .. then reconfigure with data from the old box/disk.
 
 Also, it is not good to recommend snapshots - most users do not need that
 level of complexity. CDs are a much better alternative, and give something
 back to the project. You DO purchase more than one set of CDs for every
 release, right?
 
   Lee
 

I DO NOT recommend going straight to -current, twice I have made that
jump on my remote server only to find that the packages for something
important suddenly don't work even though my -current box at home
worked OK.

Buy a CD. Do a fresh install. And since a special moment with lock
showing up is soon to happen, then upgrading that to -current should
work fine. But yes upgrade to 5.5 -current afterwards.

Or wait a little and put -current at home/office and test and then
install if OK.

It never hurts to be careful. And backup everything before you turn off
those disks since they are old. Old disks keep running but often can't
restart from a stop.

Chris Bennett



Re: Upgrade path from 4.1?

2014-02-06 Thread Shawn K. Quinn
On Thu, Feb 6, 2014, at 04:07 PM, Chris Bennett wrote:
 It never hurts to be careful. And backup everything before you turn off
 those disks since they are old. Old disks keep running but often can't
 restart from a stop.

If for some reason you do find yourself with disks that will not spin up
again after being spun down, try leaving the box powered up at the
failed boot screen for a time (at least 15 minutes, I recommend at least
30 minutes) before rebooting. This at least worked for me on a 200
megabyte disk in the 1990s (I fortunately have not had the problem
since).

-- 
  Shawn K. Quinn
  skqu...@rushpost.com



Re: Upgrade path from 4.1?

2014-02-06 Thread Chris Cappuccio
Chris Bennett [chrisbenn...@bennettconstruction.us] wrote:
 On Thu, Feb 06, 2014 at 11:56:05AM -0600, L. V. Lammert wrote:
  On Thu, 6 Feb 2014, Chris Cappuccio wrote:
  
   What I'm recommending isn't really an upgrade so much as using the old
   box to bootstrap a newest snapshot. As long as the bootblocks are still
   compatible, you can do it.
  
  Why? A clean build on a new machine would be the best solution in that
  case, .. then reconfigure with data from the old box/disk.
  
  Also, it is not good to recommend snapshots - most users do not need that
  level of complexity. CDs are a much better alternative, and give something
  back to the project. You DO purchase more than one set of CDs for every
  release, right?
  
  Lee
  
 
 I DO NOT recommend going straight to -current, twice I have made that
 jump on my remote server only to find that the packages for something
 important suddenly don't work even though my -current box at home
 worked OK.
 

It might help to report package problems. The current snapshots are now
very close to what you are going to see in the 5.5 release.

 Buy a CD. Do a fresh install. And since a special moment with lock
 showing up is soon to happen, then upgrading that to -current should
 work fine. But yes upgrade to 5.5 -current afterwards.
 

This is probably the time where most people would recommend against
that since it is essentially a complete reinstall of all items to upgrade
from pre-5.5 to 5.5 due to time_t ABI change.

 Or wait a little and put -current at home/office and test and then
 install if OK.
 
 It never hurts to be careful. And backup everything before you turn off
 those disks since they are old. Old disks keep running but often can't
 restart from a stop.

Yeah keep backups any of this crazy stuff will drive you nuts when you
fuck up all your data and can't figure out how to fix it.

Chris



Re: Intel i210AT NICs

2014-02-06 Thread Jonathan Gray
Some other things to think about when comparing
to the intel code in FreeBSD/Linux:

igb_read_phy_reg_gs40g/igb_write_phy_reg_gs40g
clearing of GS40G_CS_POWER_DOW to power up phy

i210 specific part of igb_has_link()

igb_acquire_swfw_sync_i210/igb_release_swfw_sync_i210
igb_init_nvm_params_i210/igb_get_flash_presence_i210 etc

The phy seems to be a marvell one instead of the intel?
one used in the 82580/i350, ie compare the callbacks

case I82580_I_PHY_ID:
case I350_I_PHY_ID:
phy-type = e1000_phy_82580;
phy-ops.force_speed_duplex =
 igb_phy_force_speed_duplex_82580;
phy-ops.get_cable_length = igb_get_cable_length_82580;
phy-ops.get_phy_info = igb_get_phy_info_82580;
phy-ops.set_d0_lplu_state = igb_set_d0_lplu_state_82580;
phy-ops.set_d3_lplu_state = igb_set_d3_lplu_state_82580;
break;
case I210_I_PHY_ID:
phy-type   = e1000_phy_i210;
phy-ops.check_polarity = igb_check_polarity_m88;
phy-ops.get_phy_info   = igb_get_phy_info_m88;
phy-ops.get_cable_length = igb_get_cable_length_m88_gen2;
phy-ops.set_d0_lplu_state = igb_set_d0_lplu_state_82580;
phy-ops.set_d3_lplu_state = igb_set_d3_lplu_state_82580;
phy-ops.force_speed_duplex = igb_phy_force_speed_duplex_m88;

A new phy type should be added rather than using em_phy_82580.

And if you want to look at offloading with the legacy
descriptor format on the 75+ server adapters it seems
the first descriptor has to be used rather than the last.
See http://mail-index.netbsd.org/source-changes/2012/08/29/msg036938.html
for a writeup.



Re: Upgrade path from 4.1?

2014-02-06 Thread Chris Bennett
On Thu, Feb 06, 2014 at 03:54:17PM -0800, Chris Cappuccio wrote:
  
  It never hurts to be careful. And backup everything before you turn off
  those disks since they are old. Old disks keep running but often can't
  restart from a stop.
 
 Yeah keep backups any of this crazy stuff will drive you nuts when you
 fuck up all your data and can't figure out how to fix it.
 
 Chris
 

Thats what vim and perl are for.

:%s/fucked_up_data/good_data/g

and perl automagically fixes any lost data.

Voila! All is well again. ;-)

Chris