smtpctl show status
Correct me if I'm wrong, but there's no way to find out what parts of smtpd (mda, mta) are paused? I can always run smtpctl pause mta again to get an error message as confirmation, but a status command something like a one shot monitor would be nice.
inteldrm framebuffer not filling the entire screen
Hello everyone, I'm running OpenBSD 5.4. I noticed that (at least on my machine) the new framebuffer doesn't seem to fill the entire screen. I'm unsure if this is a real problem or just a misunderstanding on my part. Please, take a look here: http://i.imgur.com/OLO2uuL.jpg. As you can see, there is still space for another line at the bottom of the screen, but that space is never used. Thanks for any clarification! dmesg: OpenBSD 5.4 (GENERIC.MP) #1: Tue Nov 12 10:57:06 CET 2013 r...@binpatch-54-amd64.mtier.org: /home/jasper/binpatchng/work-binpatch54-amd64/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 3960664064 (3777MB) avail mem = 3847503872 (3669MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (70 entries) bios0: vendor LENOVO version G4ET90WW (2.50 ) date 12/20/2012 bios0: LENOVO 24297TG acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI MSDM SSDT SSDT UEFI DBG2 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.58 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 4 (EXP3) acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1, PSS acpicpu2 at acpi0: C2, C1, PSS acpicpu3 at acpi0: C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 103 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 45N1001 serial 29849 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel HD Graphics 4000 rev 0x09 intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1600x900 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 7 Series xHCI rev 0x04 at pci0 dev 20 function 0 not configured Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address 3c:97:0e:8b:90:a2 ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio rev 0x04: msi azalia0: codecs: Realtek ALC269, Intel/0x2806, using Realtek ALC269 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi
man radeon(4)
Hi there! As I think of replacing my old laptop with a new Lenovo S540 I checked radeon(4) if the 'HD 8670M' might be supported. I noticed the following on the man page that appears to be somewhat strange: OLAND Radeon HD 8000 series HAINAN Radeon HD 8000 series My first guess is that this is a typo on one of the chips. Otherwise I would appreciate a short hint if the above mentioned radeon card is support at this time. Cheers, STEFAN
Re: inteldrm framebuffer not filling the entire screen
I believe the font is 22 pixels high. Your screen resolution is 900 pixels high. That gives you 900 / 22 = 40 lines of text, leaving 900 - (22 * 40) = 20 pixels at the bottom. Almost, but just not, one line extra. If only your screen resolution was 902 pixels high ;) Cheers, Paul 'WEiRD' de Weerd On Thu, Feb 13, 2014 at 09:45:11AM +0100, Alessandro Gallo wrote: | Hello everyone, | | I'm running OpenBSD 5.4. I noticed that (at least on my machine) the new | framebuffer doesn't seem to fill the entire screen. I'm unsure if this is a | real problem or just a misunderstanding on my part. Please, take a look | here: http://i.imgur.com/OLO2uuL.jpg. As you can see, there is still space | for another line at the bottom of the screen, but that space is never used. | Thanks for any clarification! | | dmesg: | | OpenBSD 5.4 (GENERIC.MP) #1: Tue Nov 12 10:57:06 CET 2013 | r...@binpatch-54-amd64.mtier.org: | /home/jasper/binpatchng/work-binpatch54-amd64/src/sys/arch/amd64/compile/ | GENERIC.MP | real mem = 3960664064 (3777MB) | avail mem = 3847503872 (3669MB) | mainbus0 at root | bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (70 entries) | bios0: vendor LENOVO version G4ET90WW (2.50 ) date 12/20/2012 | bios0: LENOVO 24297TG | acpi0 at bios0: rev 2 | acpi0: sleep states S0 S3 S4 S5 | acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT | ASF! UEFI UEFI MSDM SSDT SSDT UEFI DBG2 | acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) | EHC2(S3) HDEF(S4) | acpitimer0 at acpi0: 3579545 Hz, 24 bits | acpihpet0 at acpi0: 14318179 Hz | acpimadt0 at acpi0 addr 0xfee0: PC-AT compat | cpu0 at mainbus0: apid 0 (boot processor) | cpu0: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.58 MHz | cpu0: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS | H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX | ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X | SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS | cpu0: 256KB 64b/line 8-way L2 cache | cpu0: smt 0, core 0, package 0 | cpu0: apic clock running at 99MHz | cpu1 at mainbus0: apid 1 (application processor) | cpu1: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz | cpu1: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS | H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX | ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X | SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS | cpu1: 256KB 64b/line 8-way L2 cache | cpu1: smt 1, core 0, package 0 | cpu2 at mainbus0: apid 2 (application processor) | cpu2: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz | cpu2: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS | H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX | ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X | SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS | cpu2: 256KB 64b/line 8-way L2 cache | cpu2: smt 0, core 1, package 0 | cpu3 at mainbus0: apid 3 (application processor) | cpu3: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz | cpu3: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS | H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX | ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X | SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS | cpu3: 256KB 64b/line 8-way L2 cache | cpu3: smt 1, core 1, package 0 | ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins | acpimcfg0 at acpi0 addr 0xf800, bus 0-63 | acpiec0 at acpi0 | acpiprt0 at acpi0: bus 0 (PCI0) | acpiprt1 at acpi0: bus -1 (PEG_) | acpiprt2 at acpi0: bus 2 (EXP1) | acpiprt3 at acpi0: bus 3 (EXP2) | acpiprt4 at acpi0: bus 4 (EXP3) | acpicpu0 at acpi0: C2, C1, PSS | acpicpu1 at acpi0: C2, C1, PSS | acpicpu2 at acpi0: C2, C1, PSS | acpicpu3 at acpi0: C2, C1, PSS | acpipwrres0 at acpi0: PUBS | acpitz0 at acpi0: critical temperature is 103 degC | acpibtn0 at acpi0: LID_ | acpibtn1 at acpi0: SLPB | acpibat0 at acpi0: BAT0 model 45N1001 serial 29849 type LION oem SANYO | acpibat1 at acpi0: BAT1 not present | acpiac0 at acpi0: AC unit online | acpithinkpad0 at acpi0 | cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400, 2300, | 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz | pci0 at mainbus0 bus 0 | pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09 | vga1 at pci0 dev 2 function 0 Intel HD Graphics 4000 rev 0x09 | intagp0 at vga1 | agp0 at intagp0: aperture at 0xe000, size 0x1000 | inteldrm0 at vga1 | drm0 at inteldrm0 | inteldrm0: 1600x900 | wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) | wsdisplay0: screen 1-5 added (std, vt100 emulation) | Intel 7 Series xHCI rev 0x04 at pci0
Re: inteldrm framebuffer not filling the entire screen
Mmm, that seems to make sense... :) Sorry for the dumb question. 2014-02-13 10:03 GMT+01:00 Paul de Weerd we...@weirdnet.nl: I believe the font is 22 pixels high. Your screen resolution is 900 pixels high. That gives you 900 / 22 = 40 lines of text, leaving 900 - (22 * 40) = 20 pixels at the bottom. Almost, but just not, one line extra. If only your screen resolution was 902 pixels high ;) Cheers, Paul 'WEiRD' de Weerd On Thu, Feb 13, 2014 at 09:45:11AM +0100, Alessandro Gallo wrote: | Hello everyone, | | I'm running OpenBSD 5.4. I noticed that (at least on my machine) the new | framebuffer doesn't seem to fill the entire screen. I'm unsure if this is a | real problem or just a misunderstanding on my part. Please, take a look | here: http://i.imgur.com/OLO2uuL.jpg. As you can see, there is still space | for another line at the bottom of the screen, but that space is never used. | Thanks for any clarification! | | dmesg: | | OpenBSD 5.4 (GENERIC.MP) #1: Tue Nov 12 10:57:06 CET 2013 | r...@binpatch-54-amd64.mtier.org: | /home/jasper/binpatchng/work-binpatch54-amd64/src/sys/arch/amd64/compile/ | GENERIC.MP | real mem = 3960664064 (3777MB) | avail mem = 3847503872 (3669MB) | mainbus0 at root | bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (70 entries) | bios0: vendor LENOVO version G4ET90WW (2.50 ) date 12/20/2012 | bios0: LENOVO 24297TG | acpi0 at bios0: rev 2 | acpi0: sleep states S0 S3 S4 S5 | acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT | ASF! UEFI UEFI MSDM SSDT SSDT UEFI DBG2 | acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) | EHC2(S3) HDEF(S4) | acpitimer0 at acpi0: 3579545 Hz, 24 bits | acpihpet0 at acpi0: 14318179 Hz | acpimadt0 at acpi0 addr 0xfee0: PC-AT compat | cpu0 at mainbus0: apid 0 (boot processor) | cpu0: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.58 MHz | cpu0: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS | H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX | ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X | SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS | cpu0: 256KB 64b/line 8-way L2 cache | cpu0: smt 0, core 0, package 0 | cpu0: apic clock running at 99MHz | cpu1 at mainbus0: apid 1 (application processor) | cpu1: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz | cpu1: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS | H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX | ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X | SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS | cpu1: 256KB 64b/line 8-way L2 cache | cpu1: smt 1, core 0, package 0 | cpu2 at mainbus0: apid 2 (application processor) | cpu2: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz | cpu2: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS | H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX | ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X | SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS | cpu2: 256KB 64b/line 8-way L2 cache | cpu2: smt 0, core 1, package 0 | cpu3 at mainbus0: apid 3 (application processor) | cpu3: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz | cpu3: | FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS | H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX | ,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,X | SAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS | cpu3: 256KB 64b/line 8-way L2 cache | cpu3: smt 1, core 1, package 0 | ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins | acpimcfg0 at acpi0 addr 0xf800, bus 0-63 | acpiec0 at acpi0 | acpiprt0 at acpi0: bus 0 (PCI0) | acpiprt1 at acpi0: bus -1 (PEG_) | acpiprt2 at acpi0: bus 2 (EXP1) | acpiprt3 at acpi0: bus 3 (EXP2) | acpiprt4 at acpi0: bus 4 (EXP3) | acpicpu0 at acpi0: C2, C1, PSS | acpicpu1 at acpi0: C2, C1, PSS | acpicpu2 at acpi0: C2, C1, PSS | acpicpu3 at acpi0: C2, C1, PSS | acpipwrres0 at acpi0: PUBS | acpitz0 at acpi0: critical temperature is 103 degC | acpibtn0 at acpi0: LID_ | acpibtn1 at acpi0: SLPB | acpibat0 at acpi0: BAT0 model 45N1001 serial 29849 type LION oem SANYO | acpibat1 at acpi0: BAT1 not present | acpiac0 at acpi0: AC unit online | acpithinkpad0 at acpi0 | cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400, 2300, | 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz | pci0 at mainbus0 bus 0 | pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09 | vga1 at pci0 dev 2 function 0 Intel HD Graphics 4000 rev 0x09 | intagp0 at vga1 | agp0 at intagp0: aperture at
Re: man radeon(4)
The radeon marketing names are a mess, each generation of marketing number names can contain multiple generations of hardware with varying levels of support. We don't have support in the kernel for the OLAND and HAINAN parts and only support basic modesetting on some of the GCN/Southern Islands parts. Have a look at http://xorg.freedesktop.org/wiki/RadeonFeature/ and avoid any Southern Islands or Sea Islands parts if you're interested in acceleration. On Thu, Feb 13, 2014 at 09:58:06AM +0100, Stefan Wollny wrote: Hi there! As I think of replacing my old laptop with a new Lenovo S540 I checked radeon(4) if the 'HD 8670M' might be supported. I noticed the following on the man page that appears to be somewhat strange: OLAND Radeon HD 8000 series HAINAN Radeon HD 8000 series My first guess is that this is a typo on one of the chips. Otherwise I would appreciate a short hint if the above mentioned radeon card is support at this time. Cheers, STEFAN
Re: Snmpd question
Le Wed, 12 Feb 2014 11:25:58 -0600, Bales, Tracy tracy.ba...@williams.com a écrit : Hello, Is it possible to have a shell script modify the contents of a user defined OID that is setup in snmpd.conf? I would like to have a cron event run a shell script and that script modify the OID values so that a remote SNMP server can monitor the changes using SNMP gets and mgets. I do not want to use SNMP traps. Thanks for any feedback! I don't know if snmpd can do this, I use net-snmpd (in ports) to pass user OID values. Regards,
OpenBSD on MacBook
Hello, I haven't tried out OpenBSD yet, but used Linux for some years. Recently I got a Macbook, thought first about installing Linux on it, but because of different reasons I am considering OpenBSD now. Does anybody have any experience with this? Would be glad for any information that would help me accomplish it. And would be great if the hardware is even supported yet. Since it is my first install, somebody with experience whom I can ask for help would be great, however I am aware that this is probably too much to ask for, and I will be glad for every piece of information I can get on the subject. I own the MacBook Pro Retina, mid 2012 version, which seems to be known as MacBookPro10,1. regards, Michael
Re: OpenBSD on MacBook
On Thu, Feb 13, 2014 at 02:54:54AM +0100, Michael Vetter wrote: Hello, I haven't tried out OpenBSD yet, but used Linux for some years. Recently I got a Macbook, thought first about installing Linux on it, but because of different reasons I am considering OpenBSD now. Does anybody have any experience with this? Would be glad for any information that would help me accomplish it. And would be great if the hardware is even supported yet. Since it is my first install, somebody with experience whom I can ask for help would be great, however I am aware that this is probably too much to ask for, and I will be glad for every piece of information I can get on the subject. I own the MacBook Pro Retina, mid 2012 version, which seems to be known as MacBookPro10,1. regards, Michael Can't you just boot it off the OpenBSD installation CD and send a dmesg? It would help a great deal. Without it we're all pretty much guessing what's in it. One thing's for sure: you have the 'dual GPU' model, one of which is a NVIDIA out of which you won't get any acceleration (the other is an Intel HD Graphics 4000). Cheers Zé
Sluggish text cursor on tmux
Hi all I believe nicm's recent changes to src/usr.bin/tmux/tty-keys.c and xterm-keys.c are the cause to what follows, but I have no idea on how to handle this... Since upgrading to Feb 7 -current, when using an editor inside a tmux session (occurs at least on vim and sc) the text cursor shows some sort of a lag when responding to 'arrow keys'. E.g., when scrolling up/down or sideways, you need to release the key before the cursor it at the desired spot, otherwise you'll overshoot (sorry if this isn't the clearest description). This happens with no tmux.conf and .vimrc files, so I don't think it's a config issue. Also, this can be seen both on xterm or on a virtual terminal. The same behaviour is *not* observed when using vim's usual movement keys (hjkl). I also think that Home/End started acting differently, since by using set nocompatible in vim I manage to get them to work as expected (line start/end). This used to work inside a tmux session, but not anymore. Are there/should there be some config-side workarounds for this, or am I going to forget cursor and home/end keys altogether? All the best Zé --
Re: OpenBSD on MacBook
On 13 Feb 2014, at 3:54, Michael Vetter michael.vet...@uni-konstanz.de wrote: Hello, I haven't tried out OpenBSD yet, but used Linux for some years. Recently I got a Macbook, thought first about installing Linux on it, but because of different reasons I am considering OpenBSD now. Does anybody have any experience with this? Would be glad for any information that would help me accomplish it. And would be great if the hardware is even supported yet. Since it is my first install, somebody with experience whom I can ask for help would be great, however I am aware that this is probably too much to ask for, and I will be glad for every piece of information I can get on the subject. I own the MacBook Pro Retina, mid 2012 version, which seems to be known as MacBookPro10,1. regards, Michael Not sure about the hardware in your model. But the biggest issue I had with installing OpenBSD on my Macbook (5,1) was the wireless adapter. Blasted BCM43xx, and there is good chance you have the same one. Wayne [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Sluggish text cursor on tmux
On Thu, Feb 13, 2014 at 12:07:00PM +, Zé Loff wrote: Hi all I believe nicm's recent changes to src/usr.bin/tmux/tty-keys.c and xterm-keys.c are the cause to what follows, but I have no idea on how to handle this... Since upgrading to Feb 7 -current, when using an editor inside a tmux session (occurs at least on vim and sc) the text cursor shows some sort of a lag when responding to 'arrow keys'. I'm seeing this too, in Vim and /usr/bin/vi. The lag is slight, but causes me to end up changing the wrong character when trying to do something fast. E.g. I noticed it when tyring to switch case of a character with ~. I didn't know the problem was due to tmux. But indeed, in a plain terminal the arrow keys are as responsive as they used to be. It also made me realise that I do indeed use arrow keys in vi... weird.
Re: Snmpd question
On 2014-02-12, Reyk Floeter r...@openbsd.org wrote: On 12.02.2014, at 18:25, Bales, Tracy tracy.ba...@williams.com wrote: Is it possible to have a shell script modify the contents of a user defined OID that is setup in snmpd.conf? I would like to have a cron event run a shell script and that script modify the OID values so that a remote SNMP server can monitor the changes using SNMP gets and mgets. I do not want to use SNMP traps. Thanks for any feedback! No. You would have to restart snmpd, there is no way to change it on runtime. But AgentX support might solve this in the future (you still need an shell - AgentX wrapper). Reyk If restarting snmpd is acceptable as an interim measure, you can use something like: oid 1.3.6.1.4.1.30155.42.3.1 name testStringValue read-only string $STRING and start snmpd with 'snmpd -D STRING=somevalue'.
Re: OpenBSD on MacBook
On Thu, Feb 13, 2014 at 02:17:08PM +0200, Wayne Oliver wrote: But the biggest issue I had with installing OpenBSD on my Macbook (5,1) was the wireless adapter. Blasted BCM43xx, and there is good chance you have the same one. Unlikely to be supported in the near term, if ever, unfortunately. No hardware docs, and the BSD-licensed vendor-provided driver[1] in Linux is a massive unreadable mess of magic numbers the size of OpenBSD's entire wifi stack (look at phy/phy_n.c for laughs). Which effectively means only the vendor can maintain this driver without unreasonable effort. A supported USB wifi stick can be used as a workaround until this situation improves. Or try swapping out the card inside the laptop with one that works. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/brcm80211/brcmsmac
Re: smtpctl show status
On Thu, Feb 13, 2014 at 02:09:53AM -0500, Ted Unangst wrote: Correct me if I'm wrong, but there's no way to find out what parts of smtpd (mda, mta) are paused? I can always run smtpctl pause mta again to get an error message as confirmation, but a status command something like a one shot monitor would be nice. Indeed, we'll add something :-) -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: Sluggish text cursor on tmux
Does this still happen if you rebuild tmux from current CVS? On Thu, Feb 13, 2014 at 01:18:38PM +0100, Stefan Sperling wrote: On Thu, Feb 13, 2014 at 12:07:00PM +, Z? Loff wrote: Hi all I believe nicm's recent changes to src/usr.bin/tmux/tty-keys.c and xterm-keys.c are the cause to what follows, but I have no idea on how to handle this... Since upgrading to Feb 7 -current, when using an editor inside a tmux session (occurs at least on vim and sc) the text cursor shows some sort of a lag when responding to 'arrow keys'. I'm seeing this too, in Vim and /usr/bin/vi. The lag is slight, but causes me to end up changing the wrong character when trying to do something fast. E.g. I noticed it when tyring to switch case of a character with ~. I didn't know the problem was due to tmux. But indeed, in a plain terminal the arrow keys are as responsive as they used to be. It also made me realise that I do indeed use arrow keys in vi... weird.
Re: Sluggish text cursor on tmux
On Feb 13 13:18:38, s...@openbsd.org wrote: I'm seeing this too, in Vim and /usr/bin/vi. The lag is slight, but causes me to end up changing the wrong character when trying to do something fast. E.g. I noticed it when tyring to switch case of a character with ~. Or when going through vim's search history with the keys. I didn't know the problem was due to tmux. But indeed, in a plain terminal the arrow keys are as responsive as they used to be. Same here.
Re: Sluggish text cursor on tmux
On Thu, Feb 13, 2014 at 03:39:09PM +, Nicholas Marriott wrote: Does this still happen if you rebuild tmux from current CVS? Seems already fixed in -current, thanks! I was running tmux from 5 Feb.
Re: Sluggish text cursor on tmux
On Thu, Feb 13, 2014 at 15:39, Nicholas Marriott wrote: Does this still happen if you rebuild tmux from current CVS? I don't think so. Confirmed it's a problem in the Feb 7 snapshot, but current CVS runs fine.
Re: Sluggish text cursor on tmux
On Thu, Feb 13, 2014 at 01:18:38PM +0100, Stefan Sperling wrote: On Thu, Feb 13, 2014 at 12:07:00PM +, Zé Loff wrote: Hi all I believe nicm's recent changes to src/usr.bin/tmux/tty-keys.c and xterm-keys.c are the cause to what follows, but I have no idea on how to handle this... Since upgrading to Feb 7 -current, when using an editor inside a tmux session (occurs at least on vim and sc) the text cursor shows some sort of a lag when responding to 'arrow keys'. I'm seeing this too, in Vim and /usr/bin/vi. The lag is slight, but causes me to end up changing the wrong character when trying to do something fast. E.g. I noticed it when tyring to switch case of a character with ~. I didn't know the problem was due to tmux. But indeed, in a plain terminal the arrow keys are as responsive as they used to be. It also made me realise that I do indeed use arrow keys in vi... weird. I had the same issue. I updated from CVS a few days ago and I can't reproduce the bug. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Sluggish text cursor on tmux
Great thanks for checking, must have been the bug fixed on the 10th. On Thu, Feb 13, 2014 at 04:47:32PM +0100, Stefan Sperling wrote: On Thu, Feb 13, 2014 at 03:39:09PM +, Nicholas Marriott wrote: Does this still happen if you rebuild tmux from current CVS? Seems already fixed in -current, thanks! I was running tmux from 5 Feb.
Re: Sluggish text cursor on tmux
Hi, Had the same issues for days, couldn't crack it. Simply did export TERM=linux before executing tmux and it did the trick (don t know why btw). The issue was only reproductible on xterm other term worked. Regards On Feb 13, 2014 6:09 PM, Juan Francisco Cantero Hurtado i...@juanfra.info wrote: On Thu, Feb 13, 2014 at 01:18:38PM +0100, Stefan Sperling wrote: On Thu, Feb 13, 2014 at 12:07:00PM +, Zé Loff wrote: Hi all I believe nicm's recent changes to src/usr.bin/tmux/tty-keys.c and xterm-keys.c are the cause to what follows, but I have no idea on how to handle this... Since upgrading to Feb 7 -current, when using an editor inside a tmux session (occurs at least on vim and sc) the text cursor shows some sort of a lag when responding to 'arrow keys'. I'm seeing this too, in Vim and /usr/bin/vi. The lag is slight, but causes me to end up changing the wrong character when trying to do something fast. E.g. I noticed it when tyring to switch case of a character with ~. I didn't know the problem was due to tmux. But indeed, in a plain terminal the arrow keys are as responsive as they used to be. It also made me realise that I do indeed use arrow keys in vi... weird. I had the same issue. I updated from CVS a few days ago and I can't reproduce the bug. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: new queue bursting
On Tue, Feb 11, 2014 at 10:31 PM, Ted Unangst t...@tedunangst.com wrote: How does bursting work in new queue? I'm unable to measure any effects. For instance, I start with something like: pass in on em0 proto tcp to port 80 queue web queue rootq on em0 bandwidth 100M max 100M queue web parent rootq bandwidth 10K max 5K queue std parent rootq bandwidth 100M default And sure enough, web downloads are crazy slow. So I tweak it: pass in on em0 proto tcp to port 80 queue web queue rootq on em0 bandwidth 100M max 100M queue web parent rootq bandwidth 10K max 50K burst 100M for 100ms queue std parent rootq bandwidth 100M default Even small downloads are still crazy slow though, although I would expect them to complete within 100ms at 100M. What does it mean for a queue to burst and what is the meaning of the duration? For 100ms per second? per connection? per ever? I'd LOVE a better explanation of this as well with practical examples (multiple HTTP and VoIP flows?). As it stands now, I'd assume the burst Ted configured would allow traffic to burst up to 1000Mbps (100Mb * 10). Or was this still throttled by max? That said, I assume bursting is less important with the higher bandwidth speeds that we have today. I imagine this is all explained in code, but it would be great if this could be explained in layman-ish terms as well. I also wonder how something like this plays with qlimit.
Re: Sluggish text cursor on tmux
On Thu, Feb 13, 2014 at 05:10:18PM +, Nicholas Marriott wrote: Great thanks for checking, must have been the bug fixed on the 10th. On Thu, Feb 13, 2014 at 04:47:32PM +0100, Stefan Sperling wrote: On Thu, Feb 13, 2014 at 03:39:09PM +, Nicholas Marriott wrote: Does this still happen if you rebuild tmux from current CVS? Seems already fixed in -current, thanks! I was running tmux from 5 Feb. As the OP, just wanted to thank everyone's input. Good to know it's solved. Cheers Zé --
Re: Baffling Syntax Errors When Adding altq Rules to pf Firewall
On 2014-02-13, Peter N. M. Hansteen pe...@bsdly.net wrote:
On Wed, Feb 12, 2014 at 09:18:09PM -0800, Scott Vanderbilt wrote:
This is running OpenBSD 5.5-beta on i386 (Jan. 22 snapshot).
5.5-beta has the new traffic shaping code in it, and there was an
irresolvable conflict over the 'queue' keyword.
In the general case I would say you could opt to switch over
to the new queues system (which requires a bit of man page reading
or waiting until the refreshed Book of PF that I'm working on comes out)
or for now do a simple search and replace to replace 'queue' with
'oldqueue' and keep most ALTQ setups intact until you have read up on
the new system a bit. But seeing that you use only priorities, you could
skip the queueing for now and just use the priorities that we've
had since OpenBSD 5.0.
This means, ditch this part
altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
queue q_pri on $ext_if priority 7
queue q_def on $ext_if priority 1 priq(default)
and replace this with
match out on $ext_if from $localnet nat-to ($ext_if) queue (q_def, q_pri )
something like
match out on $ext_if from $localnet nat-to ($ext_if) set prio (3, 6)
(the default priority is 3, do the two-priority trick with priorities only,
no queues necessary)
This is quite a different rule; the old one limits outgoing bandwidth to
100Kb/s and _within that 100Kb/s_ it prioritizes certain traffic. This
suggested replacement isn't throttling the packets going out of the
interface at all, so unless there's a huge amount of data being sent, the
priorities aren't going to come into play. If this is the common case
of queueing on a firewall that's behind a modem connected to a WAN link
that is slower than the ethernet interface, you're just going to fill
the modem's buffers..
I'm not sure how set prio fits together with the new queueing code yet,
I've played a bit but don't have a good way to visualize the traffic
and get a good feel for how it works (I used to use ttt to get nice
live-updating graphs per-flow when testing queue configuration, but that
needs tkBLT which doesn't run with current Tk versions; everything else
I've found that can produce graphs useful for this is after-the-fact,
which makes it harder to see the effect of config changes on a live
network).
Re: Baffling Syntax Errors When Adding altq Rules to pf Firewall
Stuart Henderson s...@spacehopper.org writes: This is quite a different rule; the old one limits outgoing bandwidth to 100Kb/s and _within that 100Kb/s_ it prioritizes certain traffic. This suggested replacement isn't throttling the packets going out of the interface at all, so unless there's a huge amount of data being sent, the priorities aren't going to come into play. Priorities won't make much difference unless you're close to your actual bandwidth limit, certainly. In the fairly common case where actually available bandwidth is different (less than) your interface bandwidth, you probably want a queue setup in place with a defined upper limit to play with. I'm not sure how set prio fits together with the new queueing code yet, Well, the main difference is that in the new world priorities and queues are independent-ish. Queues serve to slice up your bandwidth into known-sized chunks (which may be flexible, hfsc-style), while priorities play within whatever limits are in place. You can get rather close to the queues with fixed priorities scheme by using both set queue and set prio in the same match or pass rule. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Support for Intel i354 Quad GbE network adapter?
Hi All, I tried to install OpenBSD 5.4 (amd64) on a PC using a Supermicro A1SRi-2758F motherboard which is based on the Intel Atom C2000 (Rangeley) platform, and has an integrated i354 Quad-port GbE network adapter. The installation was unable to detect any of the network interfaces. Is anybody aware of some sort of workaround for this problem? I tried to do a PXE install which is ironic because it was over one of the interfaces. At the network configuration part of the installation, it detected a vlan0 interface which I was unable to configure. Thanks, Andrew
Re: Support for Intel i354 Quad GbE network adapter?
On Thu, Feb 13, 2014 at 11:30:14PM -0600, Andrew Lester wrote:
Hi All,
I tried to install OpenBSD 5.4 (amd64) on a PC using a Supermicro
A1SRi-2758F motherboard which is based on the Intel Atom C2000
(Rangeley) platform, and has an integrated i354 Quad-port GbE
network adapter. The installation was unable to detect any of the
network interfaces. Is anybody aware of some sort of workaround for
this problem? I tried to do a PXE install which is ironic because it
was over one of the interfaces. At the network configuration part of
the installation, it detected a vlan0 interface which I was unable
to configure.
Here is a diff against -current that may work but doesn't
handle some of the i354 special casing:
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 14 Feb 2014 05:55:27 -
@@ -144,6 +144,9 @@ 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_I354_BP_1GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_BP_2_5GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_SGMII },
{ 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 },
Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.75
diff -u -p -r1.75 if_em_hw.c
--- if_em_hw.c 27 Nov 2013 01:13:10 - 1.75
+++ if_em_hw.c 14 Feb 2014 05:54:27 -
@@ -523,6 +523,9 @@ em_set_mac_type(struct em_hw *hw)
case E1000_DEV_ID_I350_SERDES:
case E1000_DEV_ID_I350_SGMII:
case E1000_DEV_ID_I350_DA4:
+ case E1000_DEV_ID_I354_BACKPLANE_1GBPS:
+ case E1000_DEV_ID_I354_SGMII:
+ case E1000_DEV_ID_I354_BACKPLANE_2_5GBPS:
hw-mac_type = em_i350;
hw-initialize_hw_bits_disable = 1;
hw-eee_enable = 1;
Index: if_em_hw.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v
retrieving revision 1.56
diff -u -p -r1.56 if_em_hw.h
--- if_em_hw.h 27 Nov 2013 01:13:10 - 1.56
+++ if_em_hw.h 14 Feb 2014 05:55:22 -
@@ -571,6 +571,9 @@ int32_t em_check_phy_reset_block(struct
#define E1000_DEV_ID_I350_SGMII 0x1524
#define E1000_DEV_ID_82576_QUAD_CU_ET2 0x1526
#define E1000_DEV_ID_I350_DA40x1546
+#define E1000_DEV_ID_I354_BACKPLANE_1GBPS 0x1F40
+#define E1000_DEV_ID_I354_SGMII 0x1F41
+#define E1000_DEV_ID_I354_BACKPLANE_2_5GBPS 0x1F45
#define E1000_DEV_ID_82574L 0x10D3
#define E1000_DEV_ID_EP80579_LAN_1 0x5040
#define E1000_DEV_ID_EP80579_LAN_2 0x5044
Re: Support for Intel i354 Quad GbE network adapter?
On Fri, Feb 14, 2014 at 05:00:03PM +1100, Jonathan Gray wrote:
On Thu, Feb 13, 2014 at 11:30:14PM -0600, Andrew Lester wrote:
Hi All,
I tried to install OpenBSD 5.4 (amd64) on a PC using a Supermicro
A1SRi-2758F motherboard which is based on the Intel Atom C2000
(Rangeley) platform, and has an integrated i354 Quad-port GbE
network adapter. The installation was unable to detect any of the
network interfaces. Is anybody aware of some sort of workaround for
this problem? I tried to do a PXE install which is ironic because it
was over one of the interfaces. At the network configuration part of
the installation, it detected a vlan0 interface which I was unable
to configure.
Here is a diff against -current that may work but doesn't
handle some of the i354 special casing:
And here is one that might give the phy more chance of working:
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 14 Feb 2014 05:55:27 -
@@ -144,6 +144,9 @@ 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_I354_BP_1GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_BP_2_5GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_SGMII },
{ 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 },
Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
retrieving revision 1.75
diff -u -p -r1.75 if_em_hw.c
--- if_em_hw.c 27 Nov 2013 01:13:10 - 1.75
+++ if_em_hw.c 14 Feb 2014 06:22:25 -
@@ -225,6 +225,7 @@ em_set_phy_type(struct em_hw *hw)
case M88E1000_I_PHY_ID:
case M88E1011_I_PHY_ID:
case M88E_I_PHY_ID:
+ case M88E1543_E_PHY_ID:
hw-phy_type = em_phy_m88;
break;
case IGP01E1000_I_PHY_ID:
@@ -523,6 +524,9 @@ em_set_mac_type(struct em_hw *hw)
case E1000_DEV_ID_I350_SERDES:
case E1000_DEV_ID_I350_SGMII:
case E1000_DEV_ID_I350_DA4:
+ case E1000_DEV_ID_I354_BACKPLANE_1GBPS:
+ case E1000_DEV_ID_I354_SGMII:
+ case E1000_DEV_ID_I354_BACKPLANE_2_5GBPS:
hw-mac_type = em_i350;
hw-initialize_hw_bits_disable = 1;
hw-eee_enable = 1;
@@ -5178,7 +5182,9 @@ em_match_gig_phy(struct em_hw *hw)
break;
case em_82580:
case em_i350:
- if (hw-phy_id == I82580_I_PHY_ID || hw-phy_id ==
I350_I_PHY_ID) {
+ if (hw-phy_id == I82580_I_PHY_ID ||
+ hw-phy_id == I350_I_PHY_ID ||
+ hw-phy_id == M88E1543_E_PHY_ID) {
uint32_t mdic;
mdic = EM_READ_REG(hw, E1000_MDICNFG);
Index: if_em_hw.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v
retrieving revision 1.56
diff -u -p -r1.56 if_em_hw.h
--- if_em_hw.h 27 Nov 2013 01:13:10 - 1.56
+++ if_em_hw.h 14 Feb 2014 06:20:45 -
@@ -571,6 +571,9 @@ int32_t em_check_phy_reset_block(struct
#define E1000_DEV_ID_I350_SGMII 0x1524
#define E1000_DEV_ID_82576_QUAD_CU_ET2 0x1526
#define E1000_DEV_ID_I350_DA40x1546
+#define E1000_DEV_ID_I354_BACKPLANE_1GBPS 0x1F40
+#define E1000_DEV_ID_I354_SGMII 0x1F41
+#define E1000_DEV_ID_I354_BACKPLANE_2_5GBPS 0x1F45
#define E1000_DEV_ID_82574L 0x10D3
#define E1000_DEV_ID_EP80579_LAN_1 0x5040
#define E1000_DEV_ID_EP80579_LAN_2 0x5044
@@ -3374,6 +3377,7 @@ struct em_host_command_info {
#define GG82563_E_PHY_ID 0x01410CA0
#define BME1000_E_PHY_ID 0x01410CB0
#define BME1000_E_PHY_ID_R2 0x01410CB1
+#define M88E1543_E_PHY_ID0x01410EA0
#define I82577_E_PHY_ID 0x01540050
#define I82578_E_PHY_ID 0x004DD040
#define I82579_E_PHY_ID 0x01540090
Re: Support for Intel i354 Quad GbE network adapter?
Jonathan,
Thanks for the reply (I also saw the update you sent). How would I make use
of that?
Simply use the install files from /pub/OpenBSD/snapshots/amd64 versus
/pub/OpenBSD/5.4/amd64? Could you elaborate what you mean by not handling
some of the special casing? Sorry, this is my first run with any sort of
BSD!
Thanks,
Andrew
-Original Message-
From: Jonathan Gray [mailto:j...@jsg.id.au]
Sent: Friday, February 14, 2014 12:00 AM
To: Andrew Lester
Cc: misc@openbsd.org
Subject: Re: Support for Intel i354 Quad GbE network adapter?
On Thu, Feb 13, 2014 at 11:30:14PM -0600, Andrew Lester wrote:
Hi All,
I tried to install OpenBSD 5.4 (amd64) on a PC using a Supermicro
A1SRi-2758F motherboard which is based on the Intel Atom C2000
(Rangeley) platform, and has an integrated i354 Quad-port GbE
network adapter. The installation was unable to detect any of the
network interfaces. Is anybody aware of some sort of workaround for
this problem? I tried to do a PXE install which is ironic because it
was over one of the interfaces. At the network configuration part of
the installation, it detected a vlan0 interface which I was unable
to configure.
Here is a diff against -current that may work but doesn't handle some of the
i354 special casing:
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 14 Feb 2014 05:55:27 -
@@ -144,6 +144,9 @@ 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_I354_BP_1GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_BP_2_5GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_SGMII },
{ 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 },
Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v retrieving revision 1.75 diff -u
-p -r1.75 if_em_hw.c
--- if_em_hw.c 27 Nov 2013 01:13:10 - 1.75
+++ if_em_hw.c 14 Feb 2014 05:54:27 -
@@ -523,6 +523,9 @@ em_set_mac_type(struct em_hw *hw)
case E1000_DEV_ID_I350_SERDES:
case E1000_DEV_ID_I350_SGMII:
case E1000_DEV_ID_I350_DA4:
+ case E1000_DEV_ID_I354_BACKPLANE_1GBPS:
+ case E1000_DEV_ID_I354_SGMII:
+ case E1000_DEV_ID_I354_BACKPLANE_2_5GBPS:
hw-mac_type = em_i350;
hw-initialize_hw_bits_disable = 1;
hw-eee_enable = 1;
Index: if_em_hw.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v retrieving revision 1.56 diff -u
-p -r1.56 if_em_hw.h
--- if_em_hw.h 27 Nov 2013 01:13:10 - 1.56
+++ if_em_hw.h 14 Feb 2014 05:55:22 -
@@ -571,6 +571,9 @@ int32_t em_check_phy_reset_block(struct
#define E1000_DEV_ID_I350_SGMII 0x1524
#define E1000_DEV_ID_82576_QUAD_CU_ET2 0x1526
#define E1000_DEV_ID_I350_DA40x1546
+#define E1000_DEV_ID_I354_BACKPLANE_1GBPS 0x1F40
+#define E1000_DEV_ID_I354_SGMII 0x1F41
+#define E1000_DEV_ID_I354_BACKPLANE_2_5GBPS 0x1F45
#define E1000_DEV_ID_82574L 0x10D3
#define E1000_DEV_ID_EP80579_LAN_1 0x5040
#define E1000_DEV_ID_EP80579_LAN_2 0x5044
Re: Support for Intel i354 Quad GbE network adapter?
Well, you'd ideally install a snapshot and check out
the src tree as described here:
http://www.openbsd.org/faq/faq5.html#Bld
apply the diff via patch before building a kernel.
cd /usr/src/sys/dev/pci
patch -p0 /path/to/patch
If that sounds a bit overwhelming I can perhaps
build a snapshot with the change here over
the weekend.
The 'special casing' meaning some of the i354 specific
code in the Intel driver in FreeBSD/Linux I have not
included in the diff.
On Fri, Feb 14, 2014 at 12:29:03AM -0600, Andrew Lester wrote:
Jonathan,
Thanks for the reply (I also saw the update you sent). How would I make use
of that?
Simply use the install files from /pub/OpenBSD/snapshots/amd64 versus
/pub/OpenBSD/5.4/amd64? Could you elaborate what you mean by not handling
some of the special casing? Sorry, this is my first run with any sort of
BSD!
Thanks,
Andrew
-Original Message-
From: Jonathan Gray [mailto:j...@jsg.id.au]
Sent: Friday, February 14, 2014 12:00 AM
To: Andrew Lester
Cc: misc@openbsd.org
Subject: Re: Support for Intel i354 Quad GbE network adapter?
On Thu, Feb 13, 2014 at 11:30:14PM -0600, Andrew Lester wrote:
Hi All,
I tried to install OpenBSD 5.4 (amd64) on a PC using a Supermicro
A1SRi-2758F motherboard which is based on the Intel Atom C2000
(Rangeley) platform, and has an integrated i354 Quad-port GbE
network adapter. The installation was unable to detect any of the
network interfaces. Is anybody aware of some sort of workaround for
this problem? I tried to do a PXE install which is ironic because it
was over one of the interfaces. At the network configuration part of
the installation, it detected a vlan0 interface which I was unable
to configure.
Here is a diff against -current that may work but doesn't handle some of the
i354 special casing:
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 14 Feb 2014 05:55:27 -
@@ -144,6 +144,9 @@ 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_I354_BP_1GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_BP_2_5GBPS },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_I354_SGMII },
{ 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 },
Index: if_em_hw.c
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v retrieving revision 1.75 diff -u
-p -r1.75 if_em_hw.c
--- if_em_hw.c27 Nov 2013 01:13:10 - 1.75
+++ if_em_hw.c14 Feb 2014 05:54:27 -
@@ -523,6 +523,9 @@ em_set_mac_type(struct em_hw *hw)
case E1000_DEV_ID_I350_SERDES:
case E1000_DEV_ID_I350_SGMII:
case E1000_DEV_ID_I350_DA4:
+ case E1000_DEV_ID_I354_BACKPLANE_1GBPS:
+ case E1000_DEV_ID_I354_SGMII:
+ case E1000_DEV_ID_I354_BACKPLANE_2_5GBPS:
hw-mac_type = em_i350;
hw-initialize_hw_bits_disable = 1;
hw-eee_enable = 1;
Index: if_em_hw.h
===
RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v retrieving revision 1.56 diff -u
-p -r1.56 if_em_hw.h
--- if_em_hw.h27 Nov 2013 01:13:10 - 1.56
+++ if_em_hw.h14 Feb 2014 05:55:22 -
@@ -571,6 +571,9 @@ int32_t em_check_phy_reset_block(struct
#define E1000_DEV_ID_I350_SGMII 0x1524
#define E1000_DEV_ID_82576_QUAD_CU_ET2 0x1526
#define E1000_DEV_ID_I350_DA40x1546
+#define E1000_DEV_ID_I354_BACKPLANE_1GBPS 0x1F40
+#define E1000_DEV_ID_I354_SGMII 0x1F41
+#define E1000_DEV_ID_I354_BACKPLANE_2_5GBPS 0x1F45
#define E1000_DEV_ID_82574L 0x10D3
#define E1000_DEV_ID_EP80579_LAN_1 0x5040
#define E1000_DEV_ID_EP80579_LAN_2 0x5044
