Intel i210AT NICs
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
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?
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?
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?
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?
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?
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?
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?
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
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
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
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?
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?
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
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
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?
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
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?
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
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?
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?
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?
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?
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?
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?
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
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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
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
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
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
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?
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?
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?
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
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?
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