Re: Patch to add 2 words to share/dict/web2
On 03/05/18 19:16, Stuart Henderson wrote: On 2018/03/05 17:14, Kurt Mosiejczuk wrote: It was annoying me that "aspirational" wasn't in common spellcheck dictionaries and afresh@ suggested I submit a patch to at least get the situation corrected for OpenBSD. Before getting around to this, I noticed "supremacist" wasn't there either so added that. hmm, according to README, this file is supposed to be "Webster's Second International Dictionary, all 234,936 words worth. The 1934 copyright has lapsed" ... should additions go in some other file or should the description be changed? It seems to have grown a bit already, $ wc -l web2 235971 web2 Definitely it should just grow. Having multiple files doesn't make sense, to me. English is a growing language. --STeve Andre'
Re: Regulators as sensors?
On 11/22/17 13:06, Anders Andersson wrote: On Tue, Nov 21, 2017 at 11:19 PM, STeve Andre' <and...@msu.edu> wrote: On 11/21/17 16:31, Mark Kettenis wrote: The diff below exposes voltage regulators as sensors. This makes it easy to look at the current settings of these regulators. The downside is that these aren't really sensors as the voltages are not actually measured. The functionality is optional; callers can pass NULL in the regulator_register() if the regulators aren't particularly interesting. This is what it looks like on the rk3399-firefly: milhaud$ sysctl hw.sensors hw.sensors.rktemp0.temp0=23.89 degC (CPU) hw.sensors.rktemp0.temp1=28.75 degC (GPU) hw.sensors.rkpmic0.volt0=0.90 VDC (vdd_cpu_l) hw.sensors.rkpmic0.volt1=1.80 VDC (vcc1v8_dvp) hw.sensors.rkpmic0.volt2=1.80 VDC (vcc1v8_pmu) hw.sensors.rkpmic0.volt3=3.00 VDC (vcc_sd) hw.sensors.rkpmic0.volt4=1.80 VDC (vcca1v8_codec) hw.sensors.rkpmic0.volt5=3.00 VDC (vcc_3v0) thoughts? As someone who does hardware stuff, having easy access to these sensorts can't hurt, and might be useful in some situations. I've measured voltages before and found during extreme temperature conditions things changed. So it's possibly useful and doesn't cost much. This reply illustrates the problem, and I think it won't be the last time someone misunderstands the feature. They are *not* sensors, so they will not vary under load. They don't reflect the actual voltage, so they are useless for checking if the hardware works as it should. I bet that a lot of people will still assume that they can be used as such, leading people to believe that everything is OK with their hardware when it's not. That's true. Hardware often lies. That's why I like the ability to monitor stuff. --STeve Andre'
Re: Regulators as sensors?
On 11/21/17 16:31, Mark Kettenis wrote: The diff below exposes voltage regulators as sensors. This makes it easy to look at the current settings of these regulators. The downside is that these aren't really sensors as the voltages are not actually measured. The functionality is optional; callers can pass NULL in the regulator_register() if the regulators aren't particularly interesting. This is what it looks like on the rk3399-firefly: milhaud$ sysctl hw.sensors hw.sensors.rktemp0.temp0=23.89 degC (CPU) hw.sensors.rktemp0.temp1=28.75 degC (GPU) hw.sensors.rkpmic0.volt0=0.90 VDC (vdd_cpu_l) hw.sensors.rkpmic0.volt1=1.80 VDC (vcc1v8_dvp) hw.sensors.rkpmic0.volt2=1.80 VDC (vcc1v8_pmu) hw.sensors.rkpmic0.volt3=3.00 VDC (vcc_sd) hw.sensors.rkpmic0.volt4=1.80 VDC (vcca1v8_codec) hw.sensors.rkpmic0.volt5=3.00 VDC (vcc_3v0) thoughts? As someone who does hardware stuff, having easy access to these sensorts can't hurt, and might be useful in some situations. I've measured voltages before and found during extreme temperature conditions things changed. So it's possibly useful and doesn't cost much. --STeve Andre'
Re: [WWW] Reverse chronological order for faq/current.html
On 01/24/17 04:08, Theo de Raadt wrote: Another way to look at it is, "Let me have a look if there's anything new on faq/current.html - I open the page and, *without* moving forward, can see straight away if something new has been added. No? Then I move on with my life without scrolling down or doing anything else apart from opening the page". Given OpenBSD's rapid development, new entries on faq/current.html appear quite frequently - I'm only thinking of the tiny amount of time saved each time. Yes clearly I'm not considering your valuable time. Raf, think about the physical world. When people add things to a list like a posting on a bulletin board, it goes at the end. People just know to look at the end for anything new. So it is online. The effort to scroll down is pretty small. --STeve Andre'
Re: patch: hide processes non owned by a user
On 01/27/15 02:26, Renaud Allard wrote: Hello, I wrote a patch which adds a new kernel sysctl (hideproc) to hide processes non owned by a user, except for root. This should be mostly useful on shell servers and on servers with chroots. I know some controversial patches have been presented in the past, but this one only does only one thing and should have a small enough impact. While writing it, I was using a snapshot of about 1 week old, and the patch didn't work for a reason I have not found. But it works fine on 5.6 (that's why this one applies to 5.6). So there might be or have been a regression somewhere. This seems like another knob, to me. As someone who has helped administrate open access systems, I'm not sure this is useful. You forgot to include the man page additions, too. ;-) --STeve Andre'
Re: Following Current / Flag Day
On 01/27/15 00:16, Theo de Raadt wrote: On 01/26/15 19:34, Kurt Miller wrote: We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older version of -current, upgrade via snapshots prior to building a new kernel from source to get over this flag day. -Kurt Is the below the change that is the flag day? Or, when is the FD? Modified files: sys/kern : exec_elf.c Log message: Require EFT shared objects have a PT_PHDR entry to be considered a pie binary. The kernel will now reject executing a typical shared library with EINVAL. This breaks compatibility with initial static pie binaries and requires a recent user-land prior to upgrading. In addition, more fine grained errors can be returned from execve(2) when errors occur while attempting to execute ELF objects. okay guenther@, kettenis@, deraadt@ Look, you'll be fine. There is approximately a 3-4 day window about a 4 weeks or a month back, depending on architecture. Use snapshots, if in doubt. OK, already did that. The tense of the message is what made me question this. Thanks. --STeve Andre'
Re: Following Current / Flag Day
On 01/26/15 19:34, Kurt Miller wrote: We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older version of -current, upgrade via snapshots prior to building a new kernel from source to get over this flag day. -Kurt Is the below the change that is the flag day? Or, when is the FD? Modified files: sys/kern : exec_elf.c Log message: Require EFT shared objects have a PT_PHDR entry to be considered a pie binary. The kernel will now reject executing a typical shared library with EINVAL. This breaks compatibility with initial static pie binaries and requires a recent user-land prior to upgrading. In addition, more fine grained errors can be returned from execve(2) when errors occur while attempting to execute ELF objects. okay guenther@, kettenis@, deraadt@ --STeve Andre'
Re: [source-changes] relayd.conf.5 (an hex - a hex)
On 12/22/14 05:02, thev...@openmailbox.org wrote: On Mon, 22 Dec 2014 08:53:04 + Jason McIntyre j...@kerhand.co.uk wrote: On Mon, Dec 22, 2014 at 03:29:13AM -0500, thev...@openmailbox.org wrote: From: Jason McIntyre j...@cvs.openbsd.org Date: Thu, 18 Dec 2014 14:26:09 -0700 (MST) To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org 2014/12/18 14:26:09 Modified files: usr.sbin/relayd: relayd.conf.5 Log message: an hex - a hex; as far as i am aware, 'an hex' is actually correct english. 'h' is a special case for a consonant. i am not quite sure why, perhaps some more ancient pronunciation of 'a', but it is commonly used eg 'an historial event'. it is a somewhat more obscure nuance in the language, so i am actually slightly surprised someone got it right the first time. it is correct only if you want to sound like a pillock. modern english does not routinely use an before words beginning h. it depends on the sound. you could have an h-bomb, but not an house. an historical event...well some folks would insist that reads better. of course, you *can* do it for comic effect, but it's best not to just drop an because the noun starts with an h. some folks do drop their aitches, so they might say an ex. that would be ok, but confusing. i'm sure if you scout online you'll find some better details (as well as some conflicting ones ;) jmc seems like this particular case may be in a grey area. a quick check of wikipedia (English_articles): Some speakers and writers use an before a word beginning with the sound /h/ in an unstressed syllable: an historical novel, an hotel.^[12] However, where the h is clearly pronounced, this usage is now less common, and a is preferred. ^[11] 11. ^ ^a ^b How to Use Articles (a/an/the) ? The OWL at Purdue 12. ^ Peters, Pam (2004). a or an. The Cambridge Guide to English Usage. Cambridge, England: Cambridge University Press. p. 1. ISBN 0-521-62181-X. so there is a conflict right there. by and large though i tend to give more credit to something from Cambridge University Press. 'an hex' sounds to me (literally) like it fits the words where this is more common, but it's hard to say, since it is based on how the individual word is pronounced, and so is relative to the accent, and thus there may not be a correct usage for some words across all english accents... it may also depend on how one pronounces 'a' too. 'an hex' sounds better than 'uh hex' (a common pronunciation of 'a'), but long 'a' sounds better than 'an'. so upon some reflection, i don't think there is a correct answer for this case. however, even if it is 'less common', it may be still be appropriate for the written word/documentation. whoever wrote that man page originally perhaps thought so. either way. natural languages aren't really mathematical. This isn't grey. A hex something, not an hex. None of my teachers who stressed good writing would have let that pass. --STeve Andre'
Re: changing ffs mount between rw and ro while preserving softdep
On 08/27/14 16:59, Philip Guenther wrote: On Wed, Aug 27, 2014 at 11:50 AM, Miod Vallat m...@online.fr wrote: Why not keep the softdep flag when updating rw-ro? E.g. via mount -ur /usr/obj fstab(5) already allows ro+softdep. Because if we were to apply this diff, there would be no way to switch from rw+softdep to rw. And what exactly is the operational/behavioral difference between ro and ro+softdep? Extra code being executed when it doesn't have to be? --STeve Andre'
Re: lynx: disable old protocols
On 07/16/14 17:00, Shawn K. Quinn wrote: On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: I'd also like to point out that Shawn has broken the social contract here, it's well known that it's generally considered rude to direct developers, in this forum. Every single free or open-source software project I have ever used has been shaped by user feedback. Most take it seriously when users say they still use functionality that's being slated for removal. So Patric, you can take this social contract of yours and shove it up your ass. I don't recognize it as anything but toilet paper. Shawn, I'm sorry but that's really out of line. Lynx will move to ports, which is the best of both worlds. It may be of questionable quality, so not in base, but with lots of other software, also of questionable quality *but available to all*. So that's it. Case closed, in a reasonable manner, I think. --STeve Andre'
Re: lynx: disable old protocols
On 07/10/14 23:05, Daniel Dickman wrote: Patch below turns off the following ancient protocols built into lynx: bibp, finger, gopher, and news. For some urls, lynx will invoke an external command. Turn off telnet, rlogin and tn3270 urls by defining them to false(1) as documented in the lynx manual. Finally, turn off the file editor which can be accessed with g.enter using the --disable-dired switch. ok to commit? No. Just because it's an older crufty protocol, it shouldn't be removed 'just because'. I keep on bumping into gopher. bibp is definitely used by others. --STeve Andre'
Re: OpenSSH hole, April 9
On 04/09/14 16:49, Devin Reade wrote: Quoting Theo de Raadt dera...@cvs.openbsd.org: If tomorrow Damien or I had to announce a major OpenSSH hole, how screwed would the Internet be? Would you mind clarifying this a bit? Was the post strictly a (justified) comment about the lack of funding, or should we be anticipating another announcement in addition to the existing OpenSSL mess? Devin That was a rhetorical question.
Re: HEADS UP: librt revert
On 03/23/14 14:34, Marc Espie wrote: kili@ just committed a revert of the librt addition in src and corresponding patches in ports. If you've built a tree with librt, you want to # rm -f /usr/lib/librt.a Shouldn't that be librt*a to get rid of librt_p.a too? --STeve Andre'
Re: unknown products found in Dell Optiplex 9020
On 09/09/13 07:45, Paul de Weerd wrote: Found a couple of unknown Intel products in a Dell Optiplex 9020: vendor Intel, unknown product 0x153a (class network subclass ethernet, rev 0x04) at pci0 dev 25 function 0 not configured vendor Intel, unknown product 0x8c22 (class serial bus subclass SMBus, rev 0x04) at pci0 dev 31 function 3 not configured vendor Intel, unknown product 0x8c31 (class serial bus subclass USB, rev 0x04) at pci0 dev 20 function 0 not configured vendor Intel, unknown product 0x8c3a (class communications subclass miscellaneous, rev 0x04) at pci0 dev 22 function 0 not configured vendor Intel, unknown product 0x8c3d (class communications subclass serial, rev 0x04) at pci0 dev 22 function 3 not configured The included diff adds these to pcidevs, resulting in the following (none of these devices are supported by actual drivers yet): Intel C220 xHCI USB rev 0x04 at pci0 dev 20 function 0 not configured Intel C220 MEI controller rev 0x04 at pci0 dev 22 function 0 not configured Intel C220 KT controller rev 0x04 at pci0 dev 22 function 3 not configured Intel I217-LM rev 0x04 at pci0 dev 25 function 0 not configured The 217-LM is the Listening Monitor, by the NSA. Intel C220 SMBus controller rev 0x04 at pci0 dev 31 function 3 not configured Note that the diff below also adds I217-V, which got me confused while I was figuring out what I had in this machine. That part is not in the machine (as I understand it, it's basically a simplified version of the same NIC, lacking some enterprise features). Full dmesg after the diff. The 217-V was made by GCHQ.
Re: man pages: wireless frequency nit 2GHz vs 2.4GHz
On 02/14/13 07:33, Stuart Henderson wrote: Amit Kulkarni amitkulz at gmail.com writes: I was reading the manpages of athn/iwn for purchasing a suitable wireless card and found repeated occurences of 2GHz, when in fact it should be 2.4GHz. That is the standard frequency when purchasing a wireless a/b/g/n card. The code is filled with 2GHz references but just changed to man pages in section 4. I don't think there is anything 'wrong' in saying operates in the 2GHz spectrum. Saying 2.4GHz in documentation seems like it might be a good idea as it's more common usage, but it seems wrong to say 2.4GHz spectrum, it seems like 2.4GHz band would make more sense if doing this. (But then mixing 'band' and 'spectrum' would also be weird so the references to 5GHz would need changing to 'bands' (not 'band' there as there are 3 non-continuous ranges). Is it worth it? I don't know. Yes, exactly right--2.4GHz band is correct and consistent with many governmental agencies terminology. This is a picky point that isn't major, but there are clear definitions of the wireless bands, and using them is better. And, consistent with OpenBSD's striving to get it right. --STeve Andre'
Re: ntfs: respect the MNT_FORCE flag upon unmount
On 12/19/11 19:33, Mike Belopuhov wrote: this is an improved diff that addresses the problem with forced unmount of the ntfs filesystem in situations like the one described here: http://marc.info/?l=openbsd-bugsm=132257956328474w=2 ntfs keeps a bunch of vnodes opened and marked as VSYSTEM including the mount point: it's usecount is 1 and it is incremented if you do cd /mnt. when you pull out a usb stick and ntfs_unmount is called it flushes all but system vnodes and then checks if system vnodes' usecount is not more than 1 (somebody is using a vnode). in case this is not true (and it's not true for the mount point since shell process is holding that vnode) it returns EBUSY. the only thing is ntfs is a read-only filesystem so there's no real reason to not to succeed and forceclose all the vnodes. the following change makes it respect the MNT_FORCE flag and proceed even if there's someone holding a vnode. also it silences the ntfs_reclaim (like ufs_reclaim is silenced by the prtactive). it might not be a perfect diff, but it improves the situation by a vast margin and still reports fs as being busy when unmount is not forced (e.g. you run umount(1)). This sounds great, speaking as a user of this when extracting data from a diseased Windows disk. Thank you. --STeve Andre'
Re: dd(1) support for uppercase size modifiers
On 10/02/11 14:25, Thomas Pfaff wrote: Simple patch to allow uppercase size modifiers (K, M, and G). Is there a reason why not to? Plus, as a bonus you're less likely to mess up if you've been naughty and used dd on Linux. Index: args.c === [snip] What other commands allow case insensitive options? I don't see it as desirable to emulate Linuxisms unless there is a good reason, myself. --STeve Andre'
Re: ksh completion
On 06/19/11 14:38, LEVAI Daniel wrote: On sze, maj 11, 2011 at 16:13:45 +0200, LEVAI Daniel wrote: On Tue, May 10, 2011 at 15:23:52 +0400, Alexander Polakov wrote: * LEVAI Daniell...@ecentrum.hu [110510 14:33]: On Tue, May 10, 2011 at 12:28:06 +0200, LEVAI Daniel wrote: [...] Apperantly, adding ':' to ESCAPEDCHARS solves the problem. Do you think there is any sideeffect to this? No, I don't think so. Let's just add it and find out in practice. So far so good. I really like this patch. Thanks for it :) Is it acceptable in the tree? Is this really going down the sewers? Daniel I hope not. I've seen this as well. I want to test this, seeing as how I just bumped into this. Can you post the last patch for this? --STeve Andre'
Re: Small pgrep/pkill enhancement
On 06/11/11 16:44, Ingo Schwarze wrote: Hi, Jonathan Perkin wrote on Tue, May 17, 2011 at 11:02:05PM +0100: Add -i to ignore case when matching process name It seems nobody picked this up, so i had a look at it. NetBSD has that since March 2005 (committed by sketch@). FreeBSD copied it from NetBSD a few days later. procps.cvs.sourceforge.net (used e.g. in Debian) does not have -i. OpenSolaris does not have -i. So I'd say we shouldn't add it. It is not terribly useful; hopefully, you at least know how the processes you are searching for are called. Even if not, you can use ps ax | grep -i to find out, then use the exact name you found for pkill. Personally, i never felt a need for pkill -i, although i'm using pkill a lot. It is not universal, so it is likely to degrade interoperability. Yours, Ingo Hmmm. Two of (arguably) the four best known BSD distributions have it. The idea of -i meaning case insensitivity is there already in other (1) commands, so I'd say it makes sense to add. From a practical standpoint, I'm all for it. I've missed killing things because of this. --STeve Andre'
Re: -current kernel freeze
On 04/07/11 20:33, Florian Fuessl wrote: Hi, upgrading GENERIC kernel from snapshot 24-Mar-2011 to -current results in system freezes after some minutes (up to some hours) without any error message, here: OpenBSD 4.9-current (GENERIC) #1: Fri Apr 8 02:20:49 CEST 2011 root@[...]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Xeon(TM) CPU 3.00GHz (GenuineIntel 686-class) 3.01 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT PR real mem = 1073258496 (1023MB) avail mem = 1045561344 (997MB) [snip] I can confirm this. Twice in the last day or so my package builder has frozen after a few hours. Previously on Wednesday the kernel paniced. OpenBSD 4.9-current (GENERIC.MP) #11: Thu Apr 7 21:29:35 EDT 2011 root@sata6:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu0: FPU,V86,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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX real mem = 3209814016 (3061MB) avail mem = 3147149312 (3001MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 10/20/10, SMBIOS rev. 2.7 @ 0xead50 (20 entries) bios0: vendor American Megatrends Inc. version 4.6.4 date 02/17/2011 bios0: BIOSTAR Group TP67B+ acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC SSDT MCFG HPET ASPT acpi0: wakeup devices PS2K(S1) PS2M(S1) UAR1(S4) BR20(S1) EUSB(S4) USBE(S4) P0P1(S4) P0P2(S4) P0P3(S4) P0P4(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) SLPB(S0) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: unknown i686 model 0x2a, can't get bus clock (0x0) cpu0: apic clock running at 102MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu1: FPU,V86,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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu2: FPU,V86,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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu3: FPU,V86,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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu4: FPU,V86,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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu5: FPU,V86,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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu6: FPU,V86,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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (GenuineIntel 686-class) 3.51 GHz cpu7: FPU,V86,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,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (P0P2) acpiprt3 at acpi0: bus -1 (P0P3) acpiprt4 at acpi0: bus -1 (P0P4) acpiprt5 at acpi0: bus 2 (PEX0) acpiprt6 at acpi0: bus 3 (PEX1) acpiprt7 at acpi0: bus 4 (PEX2) acpiprt8 at acpi0: bus -1 (PEX3) acpiprt9 at acpi0: bus -1 (PEX4) acpiprt10 at acpi0: bus -1 (PEX5) acpiprt11 at acpi0: bus -1 (PEX6)
Re: softraid cleanup
I have just built a system where I'm going to do raid, and included this.
So far I have found that I have hardware problems which I need to work
on before I can comment. I'll be using this hopefully this weekend unless
I have major hardware problems.-STeve Andre'
On 10/21/10 15:17, Marco Peereboom wrote:
anyone?
On Wed, Oct 20, 2010 at 08:47:00PM -0500, Marco Peereboom wrote:
On Thu, Sep 30, 2010 at 03:35:33AM +0200, Tobias Ulmer wrote:
I got this after a while:
panic: softraid0: sr_crypto_finish_io
No serial, so there's no more info. You know where to find me
new diff that should fix all them issues.
please test, especially raid 1 including rebuild and stuff.
Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.215
diff -u -p -r1.215 softraid.c
--- dev/softraid.c 12 Oct 2010 00:53:32 - 1.215
+++ dev/softraid.c 21 Oct 2010 01:36:32 -
@@ -126,6 +126,7 @@ voidsr_rebuild(void *);
void sr_rebuild_thread(void *);
void sr_roam_chunks(struct sr_discipline *);
int sr_chunk_in_use(struct sr_softc *, dev_t);
+void sr_startwu_callback(void *, void *);
/* don't include these on RAMDISK */
#ifndef SMALL_KERNEL
@@ -1806,6 +1807,8 @@ sr_wu_put(struct sr_workunit *wu)
wu-swu_fake = 0;
wu-swu_flags = 0;
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_wu_put, DEVNAME(sd-sd_sc));
while ((ccb = TAILQ_FIRST(wu-swu_ccb)) != NULL) {
TAILQ_REMOVE(wu-swu_ccb, ccb, ccb_link);
sr_ccb_put(ccb);
@@ -2563,6 +2566,9 @@ sr_hotspare_rebuild(struct sr_discipline
busy = 0;
s = splbio();
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_hotspare_rebuild,
+ DEVNAME(sd-sd_sc));
TAILQ_FOREACH(wu,sd-sd_wu_pendq, swu_link) {
TAILQ_FOREACH(ccb,wu-swu_ccb, ccb_link) {
if (ccb-ccb_target == chunk_no)
@@ -2816,6 +2822,11 @@ sr_ioctl_createraid(struct sr_softc *sc,
sd = malloc(sizeof(struct sr_discipline), M_DEVBUF, M_WAITOK | M_ZERO);
sd-sd_sc = sc;
SLIST_INIT(sd-sd_meta_opt);
+ sd-sd_workq = workq_create(srdis, 1, IPL_BIO);
+ if (sd-sd_workq == NULL) {
+ printf(%s: could not create workq\n);
+ goto unwind;
+ }
if (sr_discipline_init(sd, bc-bc_level)) {
printf(%s: could not initialize discipline\n, DEVNAME(sc));
goto unwind;
@@ -3407,6 +3418,9 @@ sr_discipline_shutdown(struct sr_discipl
sr_chunks_unwind(sc,sd-sd_vol.sv_chunk_list);
+ if (sd-sd_workq)
+ workq_destroy(sd-sd_workq);
+
if (sd)
sr_discipline_free(sd);
@@ -3625,10 +3639,29 @@ sr_raid_sync(struct sr_workunit *wu)
}
void
+sr_startwu_callback(void *arg1, void *arg2)
+{
+ struct sr_discipline*sd = arg1;
+ struct sr_workunit *wu = arg2;
+ struct sr_ccb *ccb;
+ int s;
+
+ s = splbio();
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_startwu_callback, DEVNAME(sd-sd_sc));
+ wu-swu_cb_active = 1;
+
+ TAILQ_FOREACH(ccb,wu-swu_ccb, ccb_link)
+ VOP_STRATEGY(ccb-ccb_buf);
+
+ wu-swu_cb_active = 0;
+ splx(s);
+}
+
+void
sr_raid_startwu(struct sr_workunit *wu)
{
struct sr_discipline*sd = wu-swu_dis;
- struct sr_ccb *ccb;
splassert(IPL_BIO);
@@ -3643,9 +3676,8 @@ sr_raid_startwu(struct sr_workunit *wu)
TAILQ_INSERT_TAIL(sd-sd_wu_pendq, wu, swu_link);
/* start all individual ios */
- TAILQ_FOREACH(ccb,wu-swu_ccb, ccb_link) {
- VOP_STRATEGY(ccb-ccb_buf);
- }
+ workq_queue_task(sd-sd_workq,wu-swu_wqt, 0, sr_startwu_callback,
+ sd, wu);
}
void
Index: dev/softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.57
diff -u -p -r1.57 softraid_crypto.c
--- dev/softraid_crypto.c 27 Sep 2010 19:49:43 - 1.57
+++ dev/softraid_crypto.c 5 Oct 2010 20:49:24 -
@@ -164,11 +164,11 @@ sr_crypto_create(struct sr_discipline *s
} else if (sr_crypto_get_kdf(bc, sd))
goto done;
-
+
/* Passphrase volumes cannot be automatically assembled. */
if (!(bc-bc_flags BIOC_SCNOAUTOASSEMBLE) bc-bc_key_disk == NODEV)
goto done;
-
+
strlcpy(sd-sd_name, CRYPTO, sizeof(sd-sd_name));
sd-sd_meta-ssdi.ssd_size = coerced_size;
@@ -194,15 +194,12 @@ sr_crypto_assemble(struct sr_discipline
goto done
Re: Adding support for Camellia on OpenSSH.
On Monday 19 July 2010 18:26:15 Ted Unangst wrote: On Sun, Jul 18, 2010 at 11:14 AM, Yoshisato YANAGISAWA yanagis...@csg.is.titech.ac.jp wrote: Not to mention there are software patent claims againt camellia. That's a no go right there. OpenBSD has already included Camellia source code as a part of OpenSSL. It is disabled by default, though. At the time OpenSSL included Camellia, NTT had shown following news release: http://www.ntt.co.jp/news/news01e/0104/010417.html NTT also announced that their Camellia implementation also becomes open source distributed under BSDL, GPL, and so on: http://www.ntt.co.jp/news/news06e/0604/060413a.html Are there any problems? The first link says Caution: This statement is valid only for implementing Camellia, EPOC, PSEC, and ESIGN, respectively, as is, and does not permit modification of said algorithms. The second link says you no longer need to apply to get a license, but still restricts it to only people using Camellia. Free software you can't modify is not free software. That's especially galling for software where there are real security considerations: suppose you find a flaw in the algorithm--you can't fix it? Gag. -- STeve Andre' Disease Control Warden Dept. of Political Science Michigan State University A day without Windows is like a day without a nuclear incident.
Re: Thank you for making p2k9 possible!
You can see whats been happening if you are subscribed to the cvs src changes list. Offhand at least 30 new ports were added, more than 250 were updated, lots were tweaked, and the pkg_add code was worked on. Likely I missed a lot, too--I was mostly focused on the ports changes so more stuff was done than I saw. When you want to find out whats happened (happening) at a hackathon, watching the commits is the best way to see whats going on. --STeve Andre' On Friday 16 October 2009 17:37:18 Nick Rivera wrote: Sounds interesting. Can we wait on resulting materials? On Sun, Oct 11, 2009 at 5:56 PM, Robert Nagy rob...@openbsd.org wrote: Hello p2k9 (the ports hackathon in Budapest) is on since Friday. People are working on different things like GNOME, GCC4, BluRay support or even ACPI. I would like to thank everyone who donated money to the project because the individual donors made it possible to organize this event. So ... BIG THANKS GOES TO OUR USERS, to people supporting the project even at these times. I'd also like to thank NIIF and Sun Microsystems Hungary for lending us a nice hackroom and hardware for the hackathon.
Partition question (Was new installer disklabel question)
On Thursday 09 July 2009 12:44:40 Theo de Raadt wrote: As an OpenBSD hobby user, I really appreciate your new installer and your automatic disklabel feature it is of GREAT help. I'm not very comfortable with fdisk and disklabel so this is a really welcomed feature and aid. Though, I'm missing 1 disklabel, the /altroot label, as it helped me several times in the past. Is there any reason why you omit this label creation? Do you think it could be added in the future to the automatic label creation or may be adding it after f.ex. answering a question (do you want an /altroot blah blah ...?) ? I know it should not be considered as a standard backup solution, but it still is a nice help. We have 16 partitions. Amongst that are b and c. So we have 14 partitions. We can potentially discover i - p using MBR reading or whatnot on other architectures, so we have potentially even less. We never did altroot automatically, and we don't do it now. What reasons are there for not extending partitions to z? With 2T disks out, having 14 partitions means not being able to make smaller ones. --STeve Andre'
