Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Klemens Nanni
On Sun, Dec 29, 2019 at 03:30:15AM +0100, Klemens Nanni wrote: > > link->target isn't the right place to put this, for one thing it's only 16 > > bits > > and the wwn is 64 bits, and it's used throughout the driver to look up > > devices > > in an array, so changing it will break things. I

Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Klemens Nanni
On Sun, Dec 29, 2019 at 05:58:02AM +0100, Klemens Nanni wrote: > Now I need to work around the first digit's mismatch; for reasons still > unknown to me, official documentation states that the RAID volume WWID's > first digit --if it is zero-- must be replaced with three, so the > bootpath

Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Klemens Nanni
On Sun, Dec 29, 2019 at 01:59:38PM +1000, Jonathan Matthew wrote: > I think we have the wrong size for the volume name, hence the difference > between the size reported by the controller and the size of vpg. Indeed, good catch! OBP's `create-raid*-volume' commands also prompt for names no longer

Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Jonathan Matthew
On Sun, Dec 29, 2019 at 03:30:15AM +0100, Klemens Nanni wrote: > On Sun, Dec 29, 2019 at 10:29:48AM +1000, Jonathan Matthew wrote: > > > + memset(, 0, sizeof(vpg)); > > > + pagelen = hdr.page_length * 4; > > > > We probably should check that this isn't larger than the size of vpg.

Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Klemens Nanni
On Sun, Dec 29, 2019 at 10:29:48AM +1000, Jonathan Matthew wrote: > > + memset(, 0, sizeof(vpg)); > > + pagelen = hdr.page_length * 4; > > We probably should check that this isn't larger than the size of vpg. pagelen is 64, sizeof(vpg) is 80. > link->target isn't the right

Re: net80211: post-bgscan RSSI threshold check

2019-12-28 Thread Patrick Dohman
> On Dec 28, 2019, at 6:11 AM, Stefan Sperling wrote: > > Access points at 36c3 use low transmit power on purpose, and often fall below > the RSSI threshold which trigger background scans. At some locations (e.g. > at the lake in CCL) I've seen iwm(4) ping-pong between APs repeatedly even >

Re: cdio(1): remove CDDB support

2019-12-28 Thread Bryan Steele
On Sat, Dec 28, 2019 at 08:03:17PM -0500, Bryan Steele wrote: > On Sat, Dec 28, 2019 at 07:48:47PM -0500, Bryan Steele wrote: > > With FreeDB announcing[0] that the service will be shutting down as of > > March 31st of 2020, and the only other alternative (MusicBrainz) already > > having shutdown

Re: cdio(1): remove CDDB support

2019-12-28 Thread Bryan Steele
On Sat, Dec 28, 2019 at 07:48:47PM -0500, Bryan Steele wrote: > With FreeDB announcing[0] that the service will be shutting down as of > March 31st of 2020, and the only other alternative (MusicBrainz) already > having shutdown their freedb/cddb gateway in favour of their own API > early this

cdio(1): remove CDDB support

2019-12-28 Thread Bryan Steele
With FreeDB announcing[0] that the service will be shutting down as of March 31st of 2020, and the only other alternative (MusicBrainz) already having shutdown their freedb/cddb gateway in favour of their own API early this year, it likely makes sense to remove support from cdio(1). CDDB is used

Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Jonathan Matthew
On Fri, Dec 27, 2019 at 07:50:34PM +0100, Klemens Nanni wrote: > On Fri, Dec 27, 2019 at 09:46:56AM +0100, Mike Belopuhov wrote: > > Looks like WWID for the RAID volume can be read from the RAID Volume > > Page 1 (mpii_cfg_raid_vol_pg1). > jmatthew also suggested that, thanks. > > I'm looking

Re: sparc64: find root device on hardware RAID

2019-12-28 Thread Klemens Nanni
On Fri, Dec 27, 2019 at 07:50:34PM +0100, Klemens Nanni wrote: > Diff below is what I booted last, but for reasons yet unkown to me the > kernel just hangs afer debug printf() > > ... > mpii0 at pci15 dev 0 function 0 "Symbios Logic SAS2008" rev 0x03: msi > mpii0: Solana

sort: do not perform top level comparison if -k supplied with -c

2019-12-28 Thread Richard Ipsum
Hi, I think there may be a bug in OpenBSD's sort utility. The bug is that when -c is used in combination with a key field, a "top level" sort is performed when the key field does not have disorder. This differs from what might be expected and certainly from what occurs with other versions of

Re: ksh: support "function name()"

2019-12-28 Thread Andras Farkas
On Sat, Dec 28, 2019 at 10:08 AM Mark Kettenis wrote: > [snip] > Are there other ksh implementations that have this "feature"? As for this question, I can at least confirm that no version of ksh93 has it.

Re: ksh: support "function name()"

2019-12-28 Thread Klemens Nanni
On Sat, Dec 28, 2019 at 04:07:02PM +0100, Mark Kettenis wrote: > Are there other ksh implementations that have this "feature"? MirBSD's ksh allows all three forms but treats `function name()' like `name()', that is $0 stays the same and will not be set to the funtion's name: $ echo

Re: ksh: support "function name()"

2019-12-28 Thread Klemens Nanni
On Sat, Dec 28, 2019 at 09:53:28AM -0500, Andras Farkas wrote: > That said, I personally think to define a function with both > 'function' and '()' is a genuine syntax error. Right now it definitely is a syntax error, what that is what this diff tries to fix ;-) I think compatibility to other

Re: ksh: support "function name()"

2019-12-28 Thread Mark Kettenis
> From: Jeremie Courreges-Anglas > Date: Sat, 28 Dec 2019 14:40:27 +0100 > > We have a few ports (~12) patched because of shell script constructs > like > > function usage() > { What is the #! for those scripts? > which are rejected by our ksh. Indeed ksh only supports either > >

Re: ksh: support "function name()"

2019-12-28 Thread Klemens Nanni
On Sat, Dec 28, 2019 at 02:40:27PM +0100, Jeremie Courreges-Anglas wrote: > We have a few ports (~12) patched because of shell script constructs > like > > function usage() > { > > which are rejected by our ksh. Indeed ksh only supports either > > usage() > { > > or > > function

Re: ksh: support "function name()"

2019-12-28 Thread Andras Farkas
If this diff gets accepted, in ksh's man page, you'll probably have to change the following line as it's not entirely disambiguous how a function would behave if it had both 'function' and '()' where it was defined: "Functions defined with the function reserved word are treated differently in the

Re: increase IEEE80211_CACHE_SIZE

2019-12-28 Thread Peter Hessler
OK On 2019 Dec 28 (Sat) at 14:27:01 +0100 (+0100), Stefan Sperling wrote: :The number of entries in the node cache is currently capped to 100. : :This limit is outdated. Modern hardware like iwm(4) 8265 supports 46 :distinct channels (1-13, 36-165) each of which can host multiple APs. : :The

ksh: support "function name()"

2019-12-28 Thread Jeremie Courreges-Anglas
We have a few ports (~12) patched because of shell script constructs like function usage() { which are rejected by our ksh. Indeed ksh only supports either usage() { or function usage { Both bash and zsh also allow an optional "()". The diff below implements the missing bits.

Re: OpenBSD perl 5.30.1 - Call for Testing

2019-12-28 Thread Stuart Henderson
On 2019/12/26 18:08, Andrew Hewus Fresh wrote: > Anyone running a speedy bulk ports cluster who could do a full build for > me would be appreciated. The only failure in the build which looks like it can be attributed to the perl update is japanese/kanjips which I've just fixed. ../text2x/text2c

increase IEEE80211_CACHE_SIZE

2019-12-28 Thread Stefan Sperling
The number of entries in the node cache is currently capped to 100. This limit is outdated. Modern hardware like iwm(4) 8265 supports 46 distinct channels (1-13, 36-165) each of which can host multiple APs. The limit is easily reached at 36c6 which makes use of much of the available spectrum and

net80211: post-bgscan RSSI threshold check

2019-12-28 Thread Stefan Sperling
Access points at 36c3 use low transmit power on purpose, and often fall below the RSSI threshold which trigger background scans. At some locations (e.g. at the lake in CCL) I've seen iwm(4) ping-pong between APs repeatedly even while the laptop is stationary. I am now running with the diff below