Re: Question regarding wi-fi card support
Thanks a lot for the answers. Now I can order some some cards and replace the one on my notebook and some other old Thinkpads I have floating around. > BTW Bluetooth is not supported, with no card. I highly recommand, do > not > start the BT topic again because the list is full of it. If you > are > interested, just use the search function. Thanks for the headsup but I don´t use BT ever on my devices. It´s a nice tech for some stuff but absolutely not needed in my every day life/work. Fabian ___ Always exit with 42 to return the answer. ‐‐‐ Original Message ‐‐‐ On Friday, August 9, 2019 4:06 AM, wrote: > flauenroth flauenr...@protonmail.com writes: > > > Dear list, > > I am in the need for a proper wi-fi solution for my Lenovo E485. > > The original card was some qualcom stuff that went right into my > > trashcan. I´ve replaced it with a Intel Wireless AC 9260 2230 2x2 + BT > > Gigabit vPro since it was catching dust but no success. Now before I > > spent money on a proper card I want to make sure the card is supported > > and works properly. I am aware of the OpenBSD network FAQ and the > > hardware listed there but hopefully some fellow OpenBSD user can > > recommend a card. My EDIMAX EW-7811UN Wireless USB Adapter works > > pretty decent but it´s no real solution. > > Thanks in advance and have a nice weekend. > > Fabian > > I replaced the default wireless card with following which has worked just > fine on my e485: > > > iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, > > msi > > Timo signature.asc Description: OpenPGP digital signature
Re: Question regarding wi-fi card support
Welcome. As I told you, keep in mind to check the FRU list before ordering. 9. August 2019 14:53, "flauenroth" schrieb: > Thanks a lot for the answers. Now I can order some some cards and replace the > one on my notebook > and some other old Thinkpads I have floating around. > >> BTW Bluetooth is not supported, with no card. I highly recommand, do > not >> start the BT topic again >> because the list is full of it. If you > are interested, just use the search >> function. > > Thanks for the headsup but I don´t use BT ever on my devices. It´s a nice > tech for some stuff but > absolutely not needed in my every day life/work. > > Fabian > ___ > Always exit with 42 to return the answer. > > ‐‐‐ Original Message ‐‐‐ > On Friday, August 9, 2019 4:06 AM, wrote: > >> flauenroth flauenr...@protonmail.com writes: >> >> Dear list, >> I am in the need for a proper wi-fi solution for my Lenovo E485. >> The original card was some qualcom stuff that went right into my >> trashcan. I´ve replaced it with a Intel Wireless AC 9260 2230 2x2 + BT >> Gigabit vPro since it was catching dust but no success. Now before I >> spent money on a proper card I want to make sure the card is supported >> and works properly. I am aware of the OpenBSD network FAQ and the >> hardware listed there but hopefully some fellow OpenBSD user can >> recommend a card. My EDIMAX EW-7811UN Wireless USB Adapter works >> pretty decent but it´s no real solution. >> Thanks in advance and have a nice weekend. >> Fabian >> >> I replaced the default wireless card with following which has worked just >> fine on my e485: >> >> iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, >> msi >> >> Timo
Re: Question regarding wi-fi card support
On Thu, Aug 08, 2019 at 09:30:20PM +, flauenroth wrote: > I am in the need for a proper wi-fi solution for my Lenovo E485. I've replaced the original one in my work Dell XPS13 with: iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 8260" rev 0x3a, msi iwm0: hw rev 0x200, fw ver 16.242414.0, It's M.2 card, works well. Tim
s.th. strange happening?
Hi there! As I never did any changes to 'www/squid/Makefile' the following irritates me: /usr/ports $ doas cvs -q up -Pd -A cvs server: conflict: INDEX is modified but no longer in the repository C INDEX M www/squid/Makefile Can some kind soul give me a hint? Anything I should do? TIA. Best, STEFAN
Re: s.th. strange happening?
On Fri, 9 Aug 2019 17:01:13 +0200, Stefan Wollny wrote: > As I never did any changes to 'www/squid/Makefile' the following > irritates me: > > /usr/ports $ doas cvs -q up -Pd -A don't use doas > cvs server: conflict: INDEX is modified but no longer in the > repository > C INDEX rm INDEX > M www/squid/Makefile cvs diff www/squid/Makefile if the change is useless, rm it and re run cvs up. In doubt, rm the whole tree and fetch a new one ;) Cheers, Dnaiel
Re: ampd(8) -Z option
On Aug 04 17:33:41, w...@roquesor.com wrote: > Now I gave a try to the apmd(8) -Z option but, so far, I couldn't make > it work in a reliable way. I added to rc.conf.local: > > apmd_flags="-A -Z 20" > > But, after doing some tests, sometimes it works, other it seems like > it's totally ignored. Similar here (Dell Latitude E5570, dmesg below). Eventualy it does suspend, but much later than when the battery life goes below the specified value. dell# pgrep -fl apmd 13368 /usr/sbin/apmd -A -z 93 -t 60 77336 man -m /home/hans/man apmd dell# apm Battery state: high, 90% remaining, 217 minutes life estimate A/C adapter state: not connected Performance adjustment mode: auto (800 MHz) This should suspend already, right? Eventualy, Aug 9 18:05:22 dell apmd: estimated battery life 89%, autoaction limit set to 93% . Aug 9 18:05:22 dell apmd: system suspending > Curious because power management seems to work fine in my T410. It > sleeps, resumes and hibernates perfectly. Yes, manual standby/suspend/hibernate and resume works perfectly on this machine too. On Aug 04 11:43:19, ed...@pettijohn-web.com wrote: > Is your laptop plugged in during the tests? No. On Aug 04 14:23:46, ed...@pettijohn-web.com wrote: > Probably has a lot to do with the quality of the battery. This is a brand new original Dell battery. acpibat0 at acpi0: BAT0 model "DELL 7V69Y53" serial 2106 type LiP oem "SMP" Jan OpenBSD 6.5-current (GENERIC.MP) #0: Thu Aug 8 12:10:50 CEST 2019 h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16810340352 (16031MB) avail mem = 16290713600 (15536MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeac10 (107 entries) bios0: vendor Dell Inc. version "1.5.0" date 04/22/2016 bios0: Dell Inc. Latitude E5570 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP DBG2 SSDT UEFI SSDT SSDT SLIC ASF! acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(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) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2295.29 MHz, 06-5e-03 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN 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 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN 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) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN 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) Core(TM) i5-6440HQ CPU @ 2.60GHz, 2294.66 MHz, 06-5e-03 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSG
Re: lrint(INT_MAX) != INT_MAX
On Jul 31 14:40:42, mailinglists.boudew...@indes.com wrote:
> Op Tue, 30 Jul 2019 17:12:56 +0200 schreef :
> > This is what happens on my relatively current
> > OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7(BeagleBone Black)
> > OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)
> >
> > #include
> > #include
> > #include
> >
> > int
> > main()
> > {
> > long l;
> > double d = INT_MAX;
> >
> > l = lrint(d);
> > printf("%f is %ld\n", d, l);
> >
> > l = lround(d);
> > printf("%f is %ld\n", d, l);
> >
> > return 0;
> > }
> >
> > 2147483647.00 is -1
> > 2147483647.00 is -1
> >
> > That doesn't seem right: isn't INT_MAX representable as a long,
> > even on these machines where sizeof(int) == sizeof(long)?
>
> If it is less than LONG_MAX, then yes.
Less than, as in strictly less?
Why? Do you mean <= ?
> > If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?
>
> If the double type provides enough mantisse (which I think it does on all
> platforms), and if I read a few C standards correctly, then yes.
>
> > On i386 (an ALIX), I see
> >
> > 2147483647.00 is 2147483647
> > 2147483647.00 is -1
> >
> > so lrint() returns the expected value but lround() does not.
> >
> > On the amd64s I have, I see the expected:
> > 2147483647.00 is 2147483647
> > 2147483647.00 is 2147483647
> >
> > Is this a bug or am I missing something obvious?
>
> I'd say it's a bug. Also with a float variable and with lrintf/lroundf the
> outcome should ideally be 2147483647.
OK, how can I help debug this?
(The code in lib/libm/src/*rint*.c seems a bit over my head.)
Jan
Re: lrint(INT_MAX) != INT_MAX
On Fri, Aug 09, 2019 at 07:19:14PM +0200, Jan Stary wrote:
> On Jul 31 14:40:42, mailinglists.boudew...@indes.com wrote:
> > Op Tue, 30 Jul 2019 17:12:56 +0200 schreef :
> > > This is what happens on my relatively current
> > > OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7 (BeagleBone Black)
> > > OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc (an old MacMini)
> > >
> > > #include
> > > #include
> > > #include
> > >
> > > int
> > > main()
> > > {
> > > long l;
> > > double d = INT_MAX;
> > >
> > > l = lrint(d);
> > > printf("%f is %ld\n", d, l);
> > >
> > > l = lround(d);
> > > printf("%f is %ld\n", d, l);
> > >
> > > return 0;
> > > }
> > >
> > > 2147483647.00 is -1
> > > 2147483647.00 is -1
> > >
> > > That doesn't seem right: isn't INT_MAX representable as a long,
> > > even on these machines where sizeof(int) == sizeof(long)?
> >
> > If it is less than LONG_MAX, then yes.
>
> Less than, as in strictly less?
> Why? Do you mean <= ?
>
> > > If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?
> >
> > If the double type provides enough mantisse (which I think it does on all
> > platforms), and if I read a few C standards correctly, then yes.
> >
> > > On i386 (an ALIX), I see
> > >
> > > 2147483647.00 is 2147483647
> > > 2147483647.00 is -1
> > >
> > > so lrint() returns the expected value but lround() does not.
> > >
> > > On the amd64s I have, I see the expected:
> > > 2147483647.00 is 2147483647
> > > 2147483647.00 is 2147483647
> > >
> > > Is this a bug or am I missing something obvious?
> >
> > I'd say it's a bug. Also with a float variable and with lrintf/lroundf the
> > outcome should ideally be 2147483647.
>
> OK, how can I help debug this?
> (The code in lib/libm/src/*rint*.c seems a bit over my head.)
>
> Jan
>
A way would be to check with Net and FreeBSD to se if they have
anything fixed in that area.
-Otto
Good Quality Microphone for Podcasts compatible with OpenBSD
Hi All, just wondering any of you audiophiles who use OpenBSD do you have recommended Microphones / Sound cards / data acquisition interfaces that would work well with OpenBSD... any recommendations suggestions welcome ... Sound is not something I have messed much with OpenBSD... and I may as well ask people in the know Thanks and Happy Friday Folks -- Kindest regards, Tom Smyth.
Re: Good Quality Microphone for Podcasts compatible with OpenBSD
Hi Tom, What are you actually doing? What kind of audio are you processing? Can you tell us more about your project? Andrew On 9 August 2019 19:43:12 BST, Tom Smyth wrote: >Hi All, > >just wondering any of you audiophiles who use OpenBSD do you have >recommended Microphones / Sound cards / data acquisition interfaces >that would work well with OpenBSD... >any recommendations suggestions welcome ... Sound is not something >I have messed much with OpenBSD... and I may as well ask people in the >know > >Thanks and Happy Friday Folks > > >-- >Kindest regards, >Tom Smyth.
Re: Good Quality Microphone for Podcasts compatible with OpenBSD
At a minimum, just spoken voice and pipe it to Skype and another web app that collects different podcast participant's audio. I use a Blue Yeti, but that's on Windows. ;-) - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "U'll Be King Of The Stars" To: misc@openbsd.org, "Tom Smyth" , "Misc" Sent: Friday, August 9, 2019 2:27:00 PM Subject: Re: Good Quality Microphone for Podcasts compatible with OpenBSD Hi Tom, What are you actually doing? What kind of audio are you processing? Can you tell us more about your project? Andrew On 9 August 2019 19:43:12 BST, Tom Smyth wrote: >Hi All, > >just wondering any of you audiophiles who use OpenBSD do you have >recommended Microphones / Sound cards / data acquisition interfaces >that would work well with OpenBSD... >any recommendations suggestions welcome ... Sound is not something >I have messed much with OpenBSD... and I may as well ask people in the >know > >Thanks and Happy Friday Folks > > >-- >Kindest regards, >Tom Smyth.
Re: Good Quality Microphone for Podcasts compatible with OpenBSD
Hi thanks for your question Just Chatting with a bunch of people about IT stuff... I dont think Im going to be the next boyzone or u2 ... (though I hear the money is good if only you make it :) ) couple of interviews... possibly some screen share demos of how to get started at things in OpenBSD.. (for the people who dont know that man pages exist yet... Thanks for coming back to me and your interest On Fri, 9 Aug 2019 at 20:27, U'll Be King Of The Stars wrote: > > Hi Tom, > > What are you actually doing? What kind of audio are you processing? > > Can you tell us more about your project? > > Andrew > > On 9 August 2019 19:43:12 BST, Tom Smyth wrote: >> >> Hi All, >> >> just wondering any of you audiophiles who use OpenBSD do you have >> recommended Microphones / Sound cards / data acquisition interfaces >> that would work well with OpenBSD... >> any recommendations suggestions welcome ... Sound is not something >> I have messed much with OpenBSD... and I may as well ask people in the >> know >> >> Thanks and Happy Friday Folks >> -- Kindest regards, Tom Smyth.
Re: ulpt vs kernel relinking
On Fri, 10 May 2019, Benjamin Baier wrote: On Fri, 10 May 2019, Antoine Jacoutot wrote: On Thu, 09 May 2019, Theo de Raadt wrote: config -e is incompatible with the KARL relinking sequence. You can probably do something like this in /etc/rc.shutdown: printf 'disable ulpt\nq\n' | config -ef /bsd sha256 /bsd >/var/db/kernel.SHA256 +KERNEL_CONF=/etc/kernel.conf +# Configure custom kernel options +if [[ -f $KERNEL_CONF ]]; then + while read _option; do + printf "%s\nquit" "$_option" | config -fe bsd + done < $KERNEL_CONF +fi Hi all, Sorry to dredge up an old thread, but I just wanted to mention that I ran into a similar problem today, and a Google search brought me here... After running "syspatch", I too noticed the following... error? warning? kernel relinking failed; see /usr/share/relink/kernel/GENERIC.MP/relink.log Following the directions, I also synced up the sha256 checksum: root# sha256 -h /var/db/kernel.SHA256 /bsd then re-ran "/usr/libexec/reorder_kernel" and rebooted... Unfortunately, this left my system in a completely unusable state! :-( The problem was, I needed to "disable inteldrm", but reorder_kernel "un-disables" that, and my system completely locked up trying to talk out the HDMI port. (And this fracking Dell has HDMI _AND_ DisplayPort, but *NO VGA!*) [Aside: To make matters even worse, the UKC> prompt I get when I "boot -c" won't recognize my USB keyboard — even though the boot prompt did — and of course there's no PS2 option to fall back to, either! But that's a whole 'nother issue... «sigh»] Anyway, I ended up booting from CD and doing: # mount /dev/sd0a /mnt # chroot /mnt # mount -a # config -ef /bsd UKC> disable inteldrm UKC> quit # reboot But then when "/etc/rc" tried to call "/usr/libexec/reorder_kernel" again, I was right back to the old "kernel relinking failed" message... At any rate, I just wanted to add my voice to the list of people affected by this. Benjamin's patch seems the most like what I would expect... Antoine's is good, too, but I worry that "rc.shutdown" could be too late; if the power goes out, or something, it might never run. My only other thought was similar to what Ted Unangst proposed here: https://www.mail-archive.com/tech@openbsd.org/msg51628.html i.e., teaching "config -c " to read from a file — or even command-line arguments. (And, by extension, it would be nice if "boot -c" inherited this behavior as well, since I need this to run before "/etc/rc" has run.) Cheers, -- :- Dabe
