Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Fri, Feb 7, 2014 at 4:03 PM, David Coppa dco...@gmail.com wrote:
On Fri, Feb 7, 2014 at 3:49 PM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Thu, 6 Feb 2014 23:07:58 -0800
From: Martynas Venckus marty...@venck.us
Yup.Does this diff fix it for you?
Here's a diff that sticks a bit closer to the original code. It's
equivalent to your diff, and admittedly purely a matter of taste which
version to prefer.
Index: s_floorl.c
===
RCS file: /home/cvs/src/lib/libm/src/ld80/s_floorl.c,v
retrieving revision 1.2
diff -u -p -r1.2 s_floorl.c
--- s_floorl.c 25 Jul 2011 16:20:09 - 1.2
+++ s_floorl.c 7 Feb 2014 14:43:19 -
@@ -38,7 +38,7 @@ floorl(long double x)
if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
if(sx==0) {se=0;i0=i1=0;}
else if(((se0x7fff)|i0|i1)!=0)
- { se=0xbfff;i0=i1=0;}
+ { se=0xbfff;i0=0x8000;i1=0;}
}
} else {
i = (0x7fff)jj0;
Just tested, and this one works too, of course...
I'd be happy if this or the other one could be committed.
Ping
Re: responding to buttonpress ACPI event sent by KVM/Qemu (same behavior in v5.2)
On 02/04/2014 01:49 AM, Robert Urban wrote: On 02/03/2014 10:12 PM, Mike Larkin wrote: I'd run with acpi debug enabled, try to see if we are dropping an event. On a 5.4 test system I compiled a new generic MP kernel with option ACPI_DEBUG and booted it. I set up a serial console. During boot there is a lot a ACPI debug output. I can make it available if anyone would like to see it. I then ran virsh shutdown guest. The guest froze without writing a single character to the console. I found this description in a RedHat bugzilla entry: Gleb Natapov 2009-12-23 10:37:44 EST I posted patch to provide correct PCI irq routing info in mptable to kvm mailing list. It works for all devices except for SCI interrupt. BIOS programs SCI interrupt to be 9 as spec requires, but OpenBSD thinks that it is smarter and moves it to interrupts 10. Qemu will still send it on vector 9 and OpenBSD will enter the same infinity recursion. This can be triggered by issuing system_powerdown on qemu monitor. the entry: https://bugzilla.redhat.com/show_bug.cgi?id=508801#c34 It sounds plausible. There is a discussion about this on the KVM list: http://www.spinics.net/lists/kvm/msg51563.html I would be grateful if someone could have a look at this. I can make a OpenBSD VM guest available. Rob Urban
Patch for netcat manpage
It was pointed out in a FreeBSD PR that one of the the nc(1) man page examples no longer works. FreeBSD imports OpenBSD netcat. With a commit on Wed Mar 20 09:27:56 2013 UTC nc.1 rev 1.62: Don't shutdown nc(1)'s network socket when stdin closes. Matches *Hobbit*'s original netcat and GNU netcat; revert to old behaviour with the new -N flag if needed. After much discussion with otto deraadt tedu and Martin Pelikan. ok deraadt@ the new -N flag was introduced to get the old auto-shutdown behaviour. One of the examples depends on his behaviour to work correctly. The attached patch updates the man page to include the -N flag in that example FreeBSD PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/185353 -- Allan Jude Index: usr.bin/nc/nc.1 === RCS file: /cvs/src/usr.bin/nc/nc.1,v retrieving revision 1.65 diff -u -p -r1.65 nc.1 --- usr.bin/nc/nc.1 20 Aug 2013 21:05:20 - 1.65 +++ usr.bin/nc/nc.1 10 Feb 2014 16:16:43 - @@ -356,7 +356,7 @@ Using a second machine, connect to the l .Nm process, feeding it the file which is to be transferred: .Pp -.Dl $ nc host.example.com 1234 \*(Lt filename.in +.Dl $ nc -N host.example.com 1234 \*(Lt filename.in .Pp After the file has been transferred, the connection will close automatically. .Sh TALKING TO SERVERS signature.asc Description: OpenPGP digital signature
Re: Patch for netcat manpage
On Mon, Feb 10, 2014 at 11:23:33AM -0500, Allan Jude wrote: It was pointed out in a FreeBSD PR that one of the the nc(1) man page examples no longer works. FreeBSD imports OpenBSD netcat. With a commit on Wed Mar 20 09:27:56 2013 UTC nc.1 rev 1.62: Don't shutdown nc(1)'s network socket when stdin closes. Matches *Hobbit*'s original netcat and GNU netcat; revert to old behaviour with the new -N flag if needed. After much discussion with otto deraadt tedu and Martin Pelikan. ok deraadt@ the new -N flag was introduced to get the old auto-shutdown behaviour. One of the examples depends on his behaviour to work correctly. The attached patch updates the man page to include the -N flag in that example FreeBSD PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/185353 -- Allan Jude right, just fixed it (-r1.66 this side). thanks for the mail, jmc Index: usr.bin/nc/nc.1 === RCS file: /cvs/src/usr.bin/nc/nc.1,v retrieving revision 1.65 diff -u -p -r1.65 nc.1 --- usr.bin/nc/nc.1 20 Aug 2013 21:05:20 - 1.65 +++ usr.bin/nc/nc.1 10 Feb 2014 16:16:43 - @@ -356,7 +356,7 @@ Using a second machine, connect to the l .Nm process, feeding it the file which is to be transferred: .Pp -.Dl $ nc host.example.com 1234 \*(Lt filename.in +.Dl $ nc -N host.example.com 1234 \*(Lt filename.in .Pp After the file has been transferred, the connection will close automatically. .Sh TALKING TO SERVERS
Patch for rc.conf(8) man page
As mentioned before on misc@, some user got confused and copied the entire rc.conf file to rc.conf.local and then proceeded editing it. This patch brings the rc.conf man page closer to the text that is in the OpenBSD faq. Hopefully it will help newcomers avoiding this mistake. Index: share/man/man8/rc.conf.8 === RCS file: /cvs/src/share/man/man8/rc.conf.8,v retrieving revision 1.20 diff -u -p -u -r1.20 rc.conf.8 --- share/man/man8/rc.conf.817 Mar 2012 14:46:40 - 1.20 +++ share/man/man8/rc.conf.810 Feb 2014 19:59:00 - @@ -45,11 +45,13 @@ in the series in order to set shell variables used therein to control the behaviour of the scripts. .Pp -It is advisable to leave +We strongly suggest you do not alter .Nm rc.conf -untouched, and instead create and edit a new +itself. Instead create and edit a new .Nm rc.conf.local -file. +file and copy only the variables you wish to change from +.Nm rc.conf +and adjust them as you like. Variables set in this file will override variables previously set in .Nm rc.conf . .Pp -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Patch for rc.conf(8) man page
Em 10-02-2014 18:28, Mark Kettenis escreveu: Date: Mon, 10 Feb 2014 18:05:38 -0200 From: Giancarlo Razzolini grazzol...@gmail.com As mentioned before on misc@, some user got confused and copied the entire rc.conf file to rc.conf.local and then proceeded editing it. This patch brings the rc.conf man page closer to the text that is in the OpenBSD faq. Hopefully it will help newcomers avoiding this mistake. I think your new text is not an improvement. Index: share/man/man8/rc.conf.8 === RCS file: /cvs/src/share/man/man8/rc.conf.8,v retrieving revision 1.20 diff -u -p -u -r1.20 rc.conf.8 --- share/man/man8/rc.conf.817 Mar 2012 14:46:40 - 1.20 +++ share/man/man8/rc.conf.810 Feb 2014 19:59:00 - @@ -45,11 +45,13 @@ in the series in order to set shell variables used therein to control the behaviour of the scripts. .Pp -It is advisable to leave +We strongly suggest you do not alter .Nm rc.conf -untouched, and instead create and edit a new +itself. Instead create and edit a new .Nm rc.conf.local -file. +file and copy only the variables you wish to change from +.Nm rc.conf +and adjust them as you like. Variables set in this file will override variables previously set in .Nm rc.conf . .Pp -- Giancarlo Razzolini GPG: 4096R/77B981BC The text on the faq should be revised then. This patch only makes the text on the man page closer to the faq. I believe that the man pages are to be considered the de facto source for documentation, not the other way around. What's your suggestion for the text? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Patch for rc.conf(8) man page
On 2014/02/10 18:42, Giancarlo Razzolini wrote: Em 10-02-2014 18:28, Mark Kettenis escreveu: Date: Mon, 10 Feb 2014 18:05:38 -0200 From: Giancarlo Razzolini grazzol...@gmail.com As mentioned before on misc@, some user got confused and copied the entire rc.conf file to rc.conf.local and then proceeded editing it. This patch brings the rc.conf man page closer to the text that is in the OpenBSD faq. Hopefully it will help newcomers avoiding this mistake. I think your new text is not an improvement. Index: share/man/man8/rc.conf.8 === RCS file: /cvs/src/share/man/man8/rc.conf.8,v retrieving revision 1.20 diff -u -p -u -r1.20 rc.conf.8 --- share/man/man8/rc.conf.817 Mar 2012 14:46:40 - 1.20 +++ share/man/man8/rc.conf.810 Feb 2014 19:59:00 - @@ -45,11 +45,13 @@ in the series in order to set shell variables used therein to control the behaviour of the scripts. .Pp -It is advisable to leave +We strongly suggest you do not alter .Nm rc.conf -untouched, and instead create and edit a new +itself. Instead create and edit a new .Nm rc.conf.local -file. +file and copy only the variables you wish to change from +.Nm rc.conf +and adjust them as you like. Variables set in this file will override variables previously set in .Nm rc.conf . .Pp -- Giancarlo Razzolini GPG: 4096R/77B981BC The text on the faq should be revised then. This patch only makes the text on the man page closer to the faq. I believe that the man pages are to be considered the de facto source for documentation, not the other way around. What's your suggestion for the text? The existing text, Create and edit a _new_ rc.conf.local file seems fine to me - man pages are generally non-verbose - if copying was intended, the manual would have said so. The faq is more chatty, and I don't see a problem with the faq's text in this area either..
Re: Patch for rc.conf(8) man page
The existing text, Create and edit a _new_ rc.conf.local file seems fine to me - man pages are generally non-verbose - if copying was intended, the manual would have said so. Disagree. Create and edit... is ambiguous. I can create a new file by copying an old file and often do so. If you want the new file start out empty then say so. We strongly suggest you do not alter .Nm rc.conf . Instead, create an empty file named .Nm rc.conf.local . Edit the new file ... blah blah blah
Re: Patch for rc.conf(8) man page
Em 10-02-2014 19:34, Marco S Hyman escreveu: The existing text, Create and edit a _new_ rc.conf.local file seems fine to me - man pages are generally non-verbose - if copying was intended, the manual would have said so. Disagree. Create and edit... is ambiguous. I can create a new file by copying an old file and often do so. If you want the new file start out empty then say so. We strongly suggest you do not alter .Nm rc.conf . Instead, create an empty file named .Nm rc.conf.local . Edit the new file ... blah blah blah Follows the diff suggesting the creation of an empty file. Stuart, I don't think that in this case it's verbose. It's only changing the idea of advisable with a strong suggestion. The strong, makes all difference, specifically in the case mentioned on misc@, where the poster did not carefully read the man page. As I mentioned, our brain try to fill in the gaps and in this case, the word strong might shout: Hey, this is important, pay attention. But since I'm not a native English speaker, perhaps someone could suggest a change in the text both of the man page and the faq. Index: share/man/man8/rc.conf.8 === RCS file: /cvs/src/share/man/man8/rc.conf.8,v retrieving revision 1.20 diff -u -p -u -r1.20 rc.conf.8 --- share/man/man8/rc.conf.817 Mar 2012 14:46:40 - 1.20 +++ share/man/man8/rc.conf.810 Feb 2014 21:36:58 - @@ -45,11 +45,13 @@ in the series in order to set shell variables used therein to control the behaviour of the scripts. .Pp -It is advisable to leave +We strongly suggest you do not alter .Nm rc.conf -untouched, and instead create and edit a new +itself. Instead create an empty file named .Nm rc.conf.local -file. +file and copy only the variables you wish to change from +.Nm rc.conf +and adjust them as you like. Variables set in this file will override variables previously set in .Nm rc.conf . .Pp -- Giancarlo Razzolini GPG: 4096R/77B981BC
Supporting unsupported Intel wireless
I'm looking for people with one of the following unsupported Intel
wireless chips:
Intel Centrino Wireless-N 2200 (shows up as Wireless-N 2000 in dmesg)
Intel Centrino Wireless-N 135
Intel Centrino Wireless-N 105
If you have one of these, please try the attached diff. It might give
you a working iwn(4).
Thanks,
Mark
Index: if_iwn.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.128
diff -u -p -r1.128 if_iwn.c
--- if_iwn.c10 Feb 2014 19:08:58 - 1.128
+++ if_iwn.c10 Feb 2014 21:34:41 -
@@ -96,6 +96,12 @@ static const struct pci_matchid iwn_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_2 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_1 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_2 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2000_1 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2000_2 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_135_1 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_135_2 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_105_1 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_105_2 },
};
intiwn_match(struct device *, void *, void *);
@@ -364,7 +370,7 @@ iwn_attach(struct device *parent, struct
printf(: %s, intrstr);
/* Read hardware revision and attach. */
- sc-hw_type = (IWN_READ(sc, IWN_HW_REV) 4) 0xf;
+ sc-hw_type = (IWN_READ(sc, IWN_HW_REV) 4) 0x1f;
if (sc-hw_type == IWN_HW_REV_TYPE_4965)
error = iwn4965_attach(sc, PCI_PRODUCT(pa-pa_id));
else
@@ -659,6 +665,19 @@ iwn5000_attach(struct iwn_softc *sc, pci
sc-fwname = iwn-2030;
sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
break;
+ case IWN_HW_REV_TYPE_2000:
+ sc-limits = iwn2000_sensitivity_limits;
+ sc-fwname = iwn-2000;
+ break;
+ case IWN_HW_REV_TYPE_135:
+ sc-limits = iwn2000_sensitivity_limits;
+ sc-fwname = iwn-135;
+ sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
+ break;
+ case IWN_HW_REV_TYPE_105:
+ sc-limits = iwn2000_sensitivity_limits;
+ sc-fwname = iwn-105;
+ break;
default:
printf(: adapter type %d not supported\n, sc-hw_type);
return ENOTSUP;
@@ -1537,7 +1556,10 @@ iwn5000_read_eeprom(struct iwn_softc *sc
hdr.version, hdr.pa_type, letoh16(hdr.volt)));
sc-calib_ver = hdr.version;
- if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+ if (sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_2000 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135 ||
+ sc-hw_type == IWN_HW_REV_TYPE_105) {
sc-eeprom_voltage = letoh16(hdr.volt);
iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
sc-eeprom_temp = letoh16(val);
@@ -2112,7 +2134,10 @@ iwn5000_rx_calib_results(struct iwn_soft
switch (calib-code) {
case IWN5000_PHY_CALIB_DC:
if (sc-hw_type == IWN_HW_REV_TYPE_5150 ||
- sc-hw_type == IWN_HW_REV_TYPE_2030)
+ sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_2000 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135 ||
+ sc-hw_type == IWN_HW_REV_TYPE_105)
idx = 0;
break;
case IWN5000_PHY_CALIB_LO:
@@ -4181,7 +4206,8 @@ iwn_send_advanced_btcoex(struct iwn_soft
struct iwn_btcoex_prot btprot;
int error, i;
- if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+ if (sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135) {
struct iwn2000_btcoex_config btconfig;
memset(btconfig, 0, sizeof btconfig);
@@ -4284,7 +4310,12 @@ iwn_config(struct iwn_softc *sc)
sc-sc_dev.dv_xname);
return error;
}
- } else if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+ }
+
+ if (sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_2000 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135 ||
+ sc-hw_type == IWN_HW_REV_TYPE_105) {
error = iwn2000_temp_offset_calib(sc);
if (error != 0) {
printf(%s: could not set temperature offset\n,
@@ -5783,7 +5814,10 @@ iwn5000_nic_config(struct iwn_softc *sc)
}
if (sc-hw_type == IWN_HW_REV_TYPE_6005)
IWN_SETBITS(sc, IWN_GP_DRIVER, IWN_GP_DRIVER_6050_1X2);
- if (sc-hw_type == IWN_HW_REV_TYPE_2030)
+ if (sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_2000 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135 ||
+ sc-hw_type ==
Re: Supporting unsupported Intel wireless
Works as expected on:
iwn0 at pci2 dev 0 function 0 Intel Centrino Wireless-N 2000 rev 0xc4: msi,
MIMO 2T2R, BGN, address 9c:4e:36:47:d3:24
Thanks!
-ml
On Mon, Feb 10, 2014 at 11:10:02PM +0100, Mark Kettenis wrote:
I'm looking for people with one of the following unsupported Intel
wireless chips:
Intel Centrino Wireless-N 2200 (shows up as Wireless-N 2000 in dmesg)
Intel Centrino Wireless-N 135
Intel Centrino Wireless-N 105
If you have one of these, please try the attached diff. It might give
you a working iwn(4).
Thanks,
Mark
Index: if_iwn.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.128
diff -u -p -r1.128 if_iwn.c
--- if_iwn.c 10 Feb 2014 19:08:58 - 1.128
+++ if_iwn.c 10 Feb 2014 21:34:41 -
@@ -96,6 +96,12 @@ static const struct pci_matchid iwn_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_6235_2 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_1 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2030_2 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2000_1 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_2000_2 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_135_1 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_135_2 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_105_1 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_105_2 },
};
int iwn_match(struct device *, void *, void *);
@@ -364,7 +370,7 @@ iwn_attach(struct device *parent, struct
printf(: %s, intrstr);
/* Read hardware revision and attach. */
- sc-hw_type = (IWN_READ(sc, IWN_HW_REV) 4) 0xf;
+ sc-hw_type = (IWN_READ(sc, IWN_HW_REV) 4) 0x1f;
if (sc-hw_type == IWN_HW_REV_TYPE_4965)
error = iwn4965_attach(sc, PCI_PRODUCT(pa-pa_id));
else
@@ -659,6 +665,19 @@ iwn5000_attach(struct iwn_softc *sc, pci
sc-fwname = iwn-2030;
sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
break;
+ case IWN_HW_REV_TYPE_2000:
+ sc-limits = iwn2000_sensitivity_limits;
+ sc-fwname = iwn-2000;
+ break;
+ case IWN_HW_REV_TYPE_135:
+ sc-limits = iwn2000_sensitivity_limits;
+ sc-fwname = iwn-135;
+ sc-sc_flags |= IWN_FLAG_ADV_BT_COEX;
+ break;
+ case IWN_HW_REV_TYPE_105:
+ sc-limits = iwn2000_sensitivity_limits;
+ sc-fwname = iwn-105;
+ break;
default:
printf(: adapter type %d not supported\n, sc-hw_type);
return ENOTSUP;
@@ -1537,7 +1556,10 @@ iwn5000_read_eeprom(struct iwn_softc *sc
hdr.version, hdr.pa_type, letoh16(hdr.volt)));
sc-calib_ver = hdr.version;
- if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+ if (sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_2000 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135 ||
+ sc-hw_type == IWN_HW_REV_TYPE_105) {
sc-eeprom_voltage = letoh16(hdr.volt);
iwn_read_prom_data(sc, base + IWN5000_EEPROM_TEMP, val, 2);
sc-eeprom_temp = letoh16(val);
@@ -2112,7 +2134,10 @@ iwn5000_rx_calib_results(struct iwn_soft
switch (calib-code) {
case IWN5000_PHY_CALIB_DC:
if (sc-hw_type == IWN_HW_REV_TYPE_5150 ||
- sc-hw_type == IWN_HW_REV_TYPE_2030)
+ sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_2000 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135 ||
+ sc-hw_type == IWN_HW_REV_TYPE_105)
idx = 0;
break;
case IWN5000_PHY_CALIB_LO:
@@ -4181,7 +4206,8 @@ iwn_send_advanced_btcoex(struct iwn_soft
struct iwn_btcoex_prot btprot;
int error, i;
- if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+ if (sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135) {
struct iwn2000_btcoex_config btconfig;
memset(btconfig, 0, sizeof btconfig);
@@ -4284,7 +4310,12 @@ iwn_config(struct iwn_softc *sc)
sc-sc_dev.dv_xname);
return error;
}
- } else if (sc-hw_type == IWN_HW_REV_TYPE_2030) {
+ }
+
+ if (sc-hw_type == IWN_HW_REV_TYPE_2030 ||
+ sc-hw_type == IWN_HW_REV_TYPE_2000 ||
+ sc-hw_type == IWN_HW_REV_TYPE_135 ||
+ sc-hw_type == IWN_HW_REV_TYPE_105) {
error = iwn2000_temp_offset_calib(sc);
if (error != 0) {
printf(%s: could not set temperature offset\n,
@@ -5783,7 +5814,10 @@ iwn5000_nic_config(struct iwn_softc *sc)
}
if (sc-hw_type == IWN_HW_REV_TYPE_6005)
IWN_SETBITS(sc, IWN_GP_DRIVER, IWN_GP_DRIVER_6050_1X2);
- if (sc-hw_type == IWN_HW_REV_TYPE_2030)
+ if
[patch] sparc64 ofwboot.net manual config
Hello,
I patched the sparc64 bootloader to allow users to manually specify
network config and where to load the kernel from via openfirmware
parameters instead of always requiring rarp/bootparams/bootp.
This enables remote bootstrapping of semi-recent sun boxes (like
the T1000) on networks where you are unable to set up the required
daemons. With this patch, the only thing required to bootstrap a
server with blank disks is access to the remote management port,
any tftp server to serve ofwboot.net, and any nfs server to serve
the kernel.
I'm not the first one to want to be able to do this, and I tried
to make it behave as users expect: http://marc.info/?t=13712989785
Historically it made sense for ofwboot to assume the user already
has the relevant daemons on the network because they were required
to get ofwboot loaded in the first place, but at some point sun's
firmware allowed people to specify network config and a tftp
server/file to load. So, for newer machines all the daemons are an
artificial requirement imposed only by OpenBSD's ofwboot.
If someone happens to have a variety of sun hardware laying around,
I'm particularly interested in the format and availability of the
/options/network-boot-arguments ofw property across different
firmware versions. I expect only newer boxes to have it at all;
older ones still require rarp friends to load ofwboot in the first
place, so these changes shouldn't affect them.
I know you guys are busy with all the other stuff you're trying to
fit in before 5.5, but if someone does find some time to test this
and/or give some feedback it'd be much appreciated.
This patch also includes various style(9), alphabetizing, and
whitespace changes which are unrelated to the netbooting logic. I
could put them in a separate diff if it helps.
Index: share/man/man8/man8.sparc64/boot_sparc64.8
===
RCS file: /cvs/src/share/man/man8/man8.sparc64/boot_sparc64.8,v
retrieving revision 1.13
diff -u -p -r1.13 boot_sparc64.8
--- share/man/man8/man8.sparc64/boot_sparc64.8 3 Jan 2010 16:43:46 -
1.13
+++ share/man/man8/man8.sparc64/boot_sparc64.8 11 Feb 2014 00:39:13 -
@@ -105,6 +105,26 @@ as soon as the kernel console has been i
Boot the system single-user.
The system will be booted multi-user unless this option is specified.
.El
+.Ss Specifying netboot configuration
+An alternative to setting up all the daemons described in
+.Xr diskless 8
+is to manually specify your configuration via
+.Tn Open Firmware
+parameters.
+To make this work, set the
+.Va host-ip ,
+.Va router-ip ,
+and
+.Va subnet-mask
+fields in the
+.Va network-boot-arguments
+parameter, and use an NFS URL of form
+.Pp
+.Dl nfs://1.2.3.4//var/nfs/bsd.rd -options
+.Pp
+as the
+.Va boot-file
+parameter.
.Ss Accessing the PROM during runtime
If the
.Xr sysctl 8
@@ -144,8 +164,9 @@ secondary bootstrap (usually also instal
network bootstrap
.El
.Sh SEE ALSO
-.Xr ddb 4 ,
.Xr boot_config 8 ,
+.Xr ddb 4 ,
+.Xr diskless 8 ,
.Xr halt 8 ,
.Xr init 8 ,
.Xr installboot 8 ,
Index: sys/arch/sparc64/stand/libsa/Makefile
===
RCS file: /cvs/src/sys/arch/sparc64/stand/libsa/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- sys/arch/sparc64/stand/libsa/Makefile 1 Jan 2013 18:49:33 -
1.9
+++ sys/arch/sparc64/stand/libsa/Makefile 11 Feb 2014 00:39:13 -
@@ -16,8 +16,9 @@ CFLAGS= ${CEXTRAFLAGS} ${AFLAGS} -O2 -D_
CPPFLAGS+= -D__INTERNAL_LIBSA_CREAD
# stand routines
-SRCS= alloc.c exit.c getfile.c gets.c globals.c \
- memcmp.c memcpy.c memset.c printf.c snprintf.c strerror.c strncpy.c
+SRCS= alloc.c exit.c getfile.c gets.c globals.c memcmp.c memcpy.c memset.c \
+ printf.c snprintf.c strchr.c strerror.c strncmp strncpy.c strrchr.c \
+ strsep.c
# io routines
SRCS+= close.c closeall.c dev.c disklabel.c dkcksum.c fstat.c ioctl.c lseek.c \
Index: sys/arch/sparc64/stand/ofwboot/Makefile
===
RCS file: /cvs/src/sys/arch/sparc64/stand/ofwboot/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- sys/arch/sparc64/stand/ofwboot/Makefile 30 Aug 2012 19:29:14 -
1.18
+++ sys/arch/sparc64/stand/ofwboot/Makefile 11 Feb 2014 00:39:13 -
@@ -18,14 +18,14 @@ SRCS= srt0.s Locore.c alloc.c boot.c el
ofdev.c vers.c
.PATH: ${S}/lib/libkern/arch/sparc64 ${S}/lib/libkern
-SRCS+= strlcpy.c strcmp.c strlcat.c strlen.c
+SRCS+= strcmp.c strlcat.c strlcpy.c strlen.c
CWARNFLAGS+= -Wno-main
AFLAGS+= -Wa,-Av9a
AFLAGS+= -x assembler-with-cpp -D_LOCORE -D__ELF__ -fno-pie
CFLAGS+= ${COPTS} -fno-pie
CPPFLAGS+= -D_STANDALONE -DSUN4U -nostdinc
-#CPPFLAGS+=-DNETIF_DEBUG
+#CPPFLAGS+=-DNETIF_DEBUG
BINMODE= 444
Index: sys/arch/sparc64/stand/ofwboot/boot.c
questions about boot-time entropy loading
Hello, While hacking on the sparc64 bootloader (patch in another mail) I had some questions about the recently added super-early entropy loading code. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/stand/ofwboot/boot.c.diff?r1=1.19;r2=1.20 From the commit message: Try to load entropy data from disk:/etc/random.seed Except it doesn't actually load it from disk, it loads it from whatever device you're loading the kernel from (in my case, the network). Other architectures may do the same. There are a few things I'm not sure about: 1) The way it's currently implemented, it causes two separate config-discovery attempts because it does a separate open/close of the device. If you're using bootp, it waits for the bootparams timeout twice, etc. However, I don't see a way to improve this that doesn't increase the complexity of the code too much, so (although it seems silly) perhaps it should stay that way. 2) I suspect that seeding your PRNG with data sent in the clear isn't a great idea in the first place. 3) If you're netbooting anyway, by the time you actually fetch the kernel you've already done a bunch of network operations. Wouldn't timing information from that be safer than some seed sent in the clear? 4) Could just be my lack of understanding, but I'm not sure that serving /etc/random.seed via NFS is a good idea. Wouldn't it need to be the same as the NFS server's? As far as I can tell, exports(5) doesn't allow you to export some arbitrary (not /etc) tree and have it appear to others as /etc. I really don't know what the best thing to do is, but it seems a bit odd in its current state.
Re: [patch] sparc64 ofwboot.net manual config
Here's some documentation of it for www/ I think there should also be some mention of this functionality in diskless(8), but I don't know where to put it, and I don't want to just .Xr it to boot_sparc64 because diskless is for all archs and none of the other boot_*s are referenced. Index: sparc64.html === RCS file: /cvs/www/sparc64.html,v retrieving revision 1.356 diff -u -p -r1.356 sparc64.html --- sparc64.html1 Nov 2013 21:36:17 - 1.356 +++ sparc64.html11 Feb 2014 01:06:40 - @@ -721,7 +721,12 @@ as well as network and diskless installs the ttbsd.rd/tt standalone miniroot over NFS. Refer to the a href=http://www.openbsd.org/cgi-bin/man.cgi?query=disklessamp;sektion=8;diskless(8)/a - manual page for details on how to setup a network boot environment. + manual page for details on how to setup a network boot environment in + general, and + a href=http://www.openbsd.org/cgi-bin/man.cgi?query=boot_sparc64amp;sektion=8amp;arch=sparc64;boot_sparc64(8)/a + for information about manually specifying network boot options on newer sparc64 + machines in such a way that does not require all the daemons described in + diskless(8). /ul p
Re: questions about boot-time entropy loading
On Mon, Feb 10, 2014 at 20:58, Jean-Philippe Ouellet wrote: 2) I suspect that seeding your PRNG with data sent in the clear isn't a great idea in the first place. 3) If you're netbooting anyway, by the time you actually fetch the kernel you've already done a bunch of network operations. Wouldn't timing information from that be safer than some seed sent in the clear? True, but if everything goes according to plan, all the inputs to the random device are mixed together. Knowing those inputs reduces (eliminates) their value, but doesn't compromise the design itself. The other inputs are still unknown. Also consider anybody in a position to see random.seed is going to be in a position to see /etc/ssh/ host keys, which is a far more serious compromise. Don't let the naughty people sniff your NFS traffic. 4) Could just be my lack of understanding, but I'm not sure that serving /etc/random.seed via NFS is a good idea. Wouldn't it need to be the same as the NFS server's? As far as I can tell, exports(5) doesn't allow you to export some arbitrary (not /etc) tree and have it appear to others as /etc. You don't have to export the server's /. Indeed this won't even work if they're different architectures. The typical approach is to export a separate partition from the server. There are some details in the diskless man page. It is true that multiple clients will share the same random.seed unless you have multiple /etc directories configured.
Re: Patch for rc.conf(8) man page
I prefer this ... --- rc.conf.8 Tue Feb 11 21:24:16 2014 +++ rc.conf.new.8 Fri Jan 3 00:44:18 2014 @@ -47,11 +47,11 @@ .Pp It is advisable to leave .Nm rc.conf -untouched, and instead create and edit a new +untouched. The +.Nm rc.conf +file includes a check for .Nm rc.conf.local -file. -Variables set in this file will override variables previously set in -.Nm rc.conf . +which can be used to override variables as required. .Pp Some variables are used to turn features on or off. For example, whether the system runs the
Re: dd status output
I would completely support the addition of these options to dd.
Re: dd status output
I know and feel the same way. But I consider 2/dev/null in shell scripts more evil. Instead of inventing something new, I used GNU. Perhaps we should ask ourselves the question why this gets printed on stderr instead of stdout? Well, moving the output to stdout now would create a more grave incompatibility. I think the GNU compatible direction is best here.
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
Here's a diff that sticks a bit closer to the original code. It's
equivalent to your diff, and admittedly purely a matter of taste which
version to prefer.
I prefer my version better. It's not '93 anymore and compilers are
able to convert 0.0L and -1.0L precisely, otherwise we have a huge
problem. There's no need to obfuscate here by manually converting
to floating point representation.
Here's a diff which also includes same fix for ld128. OK?
Index: ld128/s_floorl.c
===
RCS file: /cvs/src/lib/libm/src/ld128/s_floorl.c,v
retrieving revision 1.1
diff -u -r1.1 s_floorl.c
--- ld128/s_floorl.c6 Jul 2011 00:02:42 - 1.1
+++ ld128/s_floorl.c11 Feb 2014 05:24:15 -
@@ -34,10 +34,11 @@
jj0 = ((i048)0x7fff)-0x3fff;
if(jj048) {
if(jj00) { /* raise inexact if x != 0 */
- if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
- if(i0=0) {i0=i1=0;}
+ if(huge+x0.0) {
+ if(i0=0)
+ return 0.0L;
else if(((i00x7fffLL)|i1)!=0)
- { i0=0xbfffULL;i1=0;}
+ return -1.0L;
}
} else {
i = (0xULL)jj0;
Index: ld80/s_floorl.c
===
RCS file: /cvs/src/lib/libm/src/ld80/s_floorl.c,v
retrieving revision 1.2
diff -u -r1.2 s_floorl.c
--- ld80/s_floorl.c 25 Jul 2011 16:20:09 - 1.2
+++ ld80/s_floorl.c 11 Feb 2014 05:24:01 -
@@ -35,10 +35,11 @@
jj0 = (se0x7fff)-0x3fff;
if(jj031) {
if(jj00) { /* raise inexact if x != 0 */
- if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
- if(sx==0) {se=0;i0=i1=0;}
+ if(huge+x0.0) {
+ if(sx==0)
+ return 0.0L;
else if(((se0x7fff)|i0|i1)!=0)
- { se=0xbfff;i0=i1=0;}
+ return -1.0L;
}
} else {
i = (0x7fff)jj0;
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Tue, Feb 11, 2014 at 6:35 AM, Martynas Venckus
marty...@cvs.openbsd.org wrote:
Here's a diff that sticks a bit closer to the original code. It's
equivalent to your diff, and admittedly purely a matter of taste which
version to prefer.
I prefer my version better. It's not '93 anymore and compilers are
able to convert 0.0L and -1.0L precisely, otherwise we have a huge
problem. There's no need to obfuscate here by manually converting
to floating point representation.
Here's a diff which also includes same fix for ld128. OK?
OK with me.
Ciao,
David
Index: ld128/s_floorl.c
===
RCS file: /cvs/src/lib/libm/src/ld128/s_floorl.c,v
retrieving revision 1.1
diff -u -r1.1 s_floorl.c
--- ld128/s_floorl.c6 Jul 2011 00:02:42 - 1.1
+++ ld128/s_floorl.c11 Feb 2014 05:24:15 -
@@ -34,10 +34,11 @@
jj0 = ((i048)0x7fff)-0x3fff;
if(jj048) {
if(jj00) { /* raise inexact if x != 0 */
- if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
- if(i0=0) {i0=i1=0;}
+ if(huge+x0.0) {
+ if(i0=0)
+ return 0.0L;
else if(((i00x7fffLL)|i1)!=0)
- { i0=0xbfffULL;i1=0;}
+ return -1.0L;
}
} else {
i = (0xULL)jj0;
Index: ld80/s_floorl.c
===
RCS file: /cvs/src/lib/libm/src/ld80/s_floorl.c,v
retrieving revision 1.2
diff -u -r1.2 s_floorl.c
--- ld80/s_floorl.c 25 Jul 2011 16:20:09 - 1.2
+++ ld80/s_floorl.c 11 Feb 2014 05:24:01 -
@@ -35,10 +35,11 @@
jj0 = (se0x7fff)-0x3fff;
if(jj031) {
if(jj00) { /* raise inexact if x != 0 */
- if(huge+x0.0) {/* return 0*sign(x) if |x|1 */
- if(sx==0) {se=0;i0=i1=0;}
+ if(huge+x0.0) {
+ if(sx==0)
+ return 0.0L;
else if(((se0x7fff)|i0|i1)!=0)
- { se=0xbfff;i0=i1=0;}
+ return -1.0L;
}
} else {
i = (0x7fff)jj0;
