Re: zskbd_device_lookup is not used anymore
On Friday, May 3, 2013 17:16 CEST, Mike Belopuhov m...@belopuhov.com wrote:
hi,
as far as i can tell these functions are not used anymore.
my sparcbook 3gx seems to be happy with it.
Sebastian
ok?
diff --git sys/arch/sparc/dev/z8530kbd.c sys/arch/sparc/dev/z8530kbd.c
index 0a9c364..c746e56 100644
--- sys/arch/sparc/dev/z8530kbd.c
+++ sys/arch/sparc/dev/z8530kbd.c
@@ -213,8 +213,6 @@ static void zs_modem(struct zskbd_softc *, int);
static void zs_hwiflow(struct zskbd_softc *);
static void zs_maskintr(struct zskbd_softc *);
-struct zskbd_softc *zskbd_device_lookup(struct cfdriver *, int);
-
/* Low-level routines. */
static void zskbd_rxint(struct zs_chanstate *);
static void zskbd_stint(struct zs_chanstate *, int);
@@ -240,14 +238,6 @@ struct wskbd_consops zskbd_consops = {
#define ZSKBDUNIT(x)(minor(x) 0x7)
-struct zskbd_softc *
-zskbd_device_lookup(cf, unit)
- struct cfdriver *cf;
- int unit;
-{
- return (struct zskbd_softc *)device_lookup(cf, unit);
-}
-
/*
* zskbd_match: how is this zs channel configured?
*/
diff --git sys/arch/sparc64/dev/z8530kbd.c sys/arch/sparc64/dev/z8530kbd.c
index e985544..1359964 100644
--- sys/arch/sparc64/dev/z8530kbd.c
+++ sys/arch/sparc64/dev/z8530kbd.c
@@ -212,8 +212,6 @@ static void zs_modem(struct zskbd_softc *, int);
static void zs_hwiflow(struct zskbd_softc *);
static void zs_maskintr(struct zskbd_softc *);
-struct zskbd_softc *zskbd_device_lookup(struct cfdriver *, int);
-
/* Low-level routines. */
static void zskbd_rxint(struct zs_chanstate *);
static void zskbd_stint(struct zs_chanstate *, int);
@@ -239,14 +237,6 @@ struct wskbd_consops zskbd_consops = {
#define ZSKBDUNIT(x)(minor(x) 0x7)
-struct zskbd_softc *
-zskbd_device_lookup(cf, unit)
- struct cfdriver *cf;
- int unit;
-{
- return (struct zskbd_softc *)device_lookup(cf, unit);
-}
-
/*
* zskbd_match: how is this zs channel configured?
*/
Re: uthum dropping out [was re ugold]
On 2013/05/04 01:49, Stuart Henderson wrote:
On 2013/05/04 01:40, Stuart Henderson wrote:
--- uthum.c 15 Apr 2013 09:23:02 - 1.19
+++ uthum.c 4 May 2013 00:19:28 -
@@ -515,7 +515,7 @@ uthum_ntc_getdata(struct uthum_softc *sc
return EIO;
/* get sensor value */
- if (uthum_read_data(sc, CMD_GETDATA_NTC, buf, sizeof(buf), 10) != 0) {
+ if (uthum_read_data(sc, CMD_GETDATA_NTC, buf, sizeof(buf), 1000) != 0) {
DPRINTF((uthum: data read fail\n));
return EIO;
}
@@ -600,6 +600,7 @@ uthum_ntc_tuning(struct uthum_softc *sc,
}
ostate = state;
}
+ tsleep(sc-sc_sensortask, 0, uthum, hz * 10);
DPRINTF((uthum: ntc tuning done. state change: 0x%.2x-0x%.2x\n,
s-cur_state, state));
...of course, as soon as I send the diff out, I get a handful of
messages even with the huge delays
uthum_ntc_getdata: broken ntc data 0x16 0x00 0x31
uthum_refresh_temperntc: data read fail
uthum_ntc_getdata: broken ntc data 0x16 0x00 0x31
uthum_refresh_temperntc: data read fail
uthum_ntc_getdata: broken ntc data 0x16 0x00 0x31
uthum_refresh_temperntc: data read fail
but so far it has not got stuck, and the sensors stay attached.
I'll re-check later...
so... each time this happens, the sensor device disappears, which
some userland monitoring programs don't cope with particularly well.
This happens fairly often, e.g. at
11:38:28
11:38:44
11:39:18
11:52:43
11:53:00
11:53:17
12:05:42
12:07:16 ...
I noticed that uthum_ntc_tuning() calls uthum_ntc_getdata() and permits
it to retry 3 times. New diff below takes a different approach: leave
timeouts as they were, and move this retry code up into uthum_ntc_getdata().
With this I do hit some broken ntc data DPRINTFs, however after retrying
the read is successful; sensor is updated and things are more robust.
I've also changed some DPRINTF() to make it clear which function
they're called from.
May 4 14:31:16 slate /bsd: uhidev0 at uhub0 port 2 configuration 1 interface 0
Ten X Technology, Inc. TEMPer sensor rev 1.10/1.50 addr 2
May 4 14:31:16 slate /bsd: uhidev0: iclass 3/1
May 4 14:31:16 slate /bsd: uthum0 at uhidev0
May 4 14:31:16 slate /bsd: uhidev1 at uhub0 port 2 configuration 1 interface 1
Ten X Technology, Inc. TEMPer sensor rev 1.10/1.50 addr 2
May 4 14:31:16 slate /bsd: uhidev1: iclass 3/0
May 4 14:31:16 slate /bsd: uthum1 at uhidev1
May 4 14:31:16 slate /bsd: uthum1: type ds75/12bit (temperature), calibration
offset -1.0 degC
May 4 14:31:16 slate /bsd: uthum1: type NTC (temperature), calibration offset
1.0 degC
May 4 14:31:16 slate /bsd: uthum_attach: complete
May 4 14:31:16 slate /bsd: uthum: ntc tuning start. cur state = 0x61, val =
0x83d4
May 4 14:31:17 slate /bsd: uthum: ntc tuning done. state change: 0x61-0x65
May 4 14:34:39 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
May 4 14:38:53 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
May 4 14:39:16 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x90 0x31
May 4 14:39:38 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
May 4 14:40:01 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
May 4 14:40:24 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
any comments? OK?
Index: uthum.c
===
RCS file: /cvs/src/sys/dev/usb/uthum.c,v
retrieving revision 1.20
diff -u -p -r1.20 uthum.c
--- uthum.c 4 May 2013 12:22:14 - 1.20
+++ uthum.c 4 May 2013 13:44:54 -
@@ -489,21 +489,31 @@ uthum_setup_sensors(struct uthum_softc *
int
uthum_ntc_getdata(struct uthum_softc *sc, int *val)
{
+ int retry = 3;
uint8_t buf[8];
if (val == NULL)
return EIO;
- /* get sensor value */
- if (uthum_read_data(sc, CMD_GETDATA_NTC, buf, sizeof(buf), 10) != 0) {
- DPRINTF((uthum: data read fail\n));
- return EIO;
+ while (retry) {
+ /* get sensor value */
+ if (uthum_read_data(sc, CMD_GETDATA_NTC,
+ buf, sizeof(buf), 10) != 0) {
+ DPRINTF((%s: data read fail\n, __FUNCTION__));
+ retry--;
+ continue;
+ }
+ /* check data integrity */
+ if (buf[2] != CMD_GETDATA_EOF2) {
+ DPRINTF((%s: broken ntc data 0x%.2x 0x%.2x 0x%.2x\n,
+ __FUNCTION__, buf[0], buf[1], buf[2]));
+ retry--;
+ continue;
+ }
+ break;
}
-
- /* check data integrity */
- if (buf[2] != CMD_GETDATA_EOF2) {
- DPRINTF((uthum: broken ntc data 0x%.2x 0x%.2x 0x%.2x\n,
- buf[0], buf[1], buf[2]));
+ if (retry = 0) {
+ DPRINTF((%s: too many failures,
1GE SFP+ media support to Intel 82599 patch
This patch adds 1GE SFP+ media support to Intel's 82599_SFP.
I wasn't able to find a 1GE SFP/SFP+ LR (single mode) optic module for 82599,
and therefore needed to bring my E10GSFPLR optics down in speed (possible in
some other operating systems).
Some notes:
* The patch is extensively tested on 82599_SFP (link ups/downs, reboot, used in
production)
* It seems to work on other NICs as well (82599_SFP_SF2, for example) but I've
not been enable to perform careful testing on those
* The patch is designed not to produce any functional change for people not
explicitly setting media, in order to simplify testing and reviewing
* I realise that 1000baseT is not the optimal media name for fibre, but since
it was aleady used to report 1GE status in the driver, I didn't change it (in
order to keep the patch small and reviewable)
--- sys/dev/pci/if_ix.c-before-speedThu May 2 11:05:16 2013
+++ sys/dev/pci/if_ix.c Fri May 3 16:56:26 2013
@@ -1067,8 +1067,44 @@
int
ixgbe_media_change(struct ifnet * ifp)
{
- /* ignore */
- return (0);
+ struct ix_softc *sc = ifp-if_softc;
+ struct ifmedia *ifm = sc-media;
+ ixgbe_link_speed speed;
+ int err = 0;
+
+ INIT_DEBUGOUT(ixgbe_media_change: begin);
+
+ if (IFM_TYPE(ifm-ifm_media) != IFM_ETHER)
+ return (EINVAL);
+
+ switch (IFM_SUBTYPE(ifm-ifm_media)) {
+ case IFM_AUTO:
+ speed = IXGBE_LINK_SPEED_100_FULL |
+ IXGBE_LINK_SPEED_1GB_FULL |
+ IXGBE_LINK_SPEED_10GB_FULL;
+ break;
+ case IFM_10G_T:
+ case IFM_10G_LR:
+ case IFM_10G_SR:
+ case IFM_10G_SFP_CU:
+ case IFM_10G_CX4:
+ speed = IXGBE_LINK_SPEED_10GB_FULL;
+ break;
+ case IFM_1000_T:
+ speed = IXGBE_LINK_SPEED_1GB_FULL;
+ break;
+ case IFM_100_TX:
+ speed = IXGBE_LINK_SPEED_100_FULL;
+ break;
+ default:
+ printf(%s: Unsupported media type\n, ifp-if_xname);
+ return (EINVAL);
+ }
+
+ if (sc-hw.mac.ops.setup_link)
+ err = sc-hw.mac.ops.setup_link(sc-hw, speed, FALSE,
sc-link_up);
+
+ return (err);
}
/*
@@ -1632,6 +1668,10 @@
ifmedia_add(sc-media,
IFM_ETHER | IFM_1000_T, 0, NULL);
}
+ if (hw-device_id == PCI_PRODUCT_INTEL_82599_SFP) {
+ ifmedia_add(sc-media,
+ IFM_ETHER | IFM_1000_T | IFM_FDX, 0, NULL);
+ }
ifmedia_add(sc-media, IFM_ETHER | IFM_AUTO, 0, NULL);
ifmedia_set(sc-media, IFM_ETHER | IFM_AUTO);
@@ -1645,6 +1685,8 @@
void
ixgbe_config_link(struct ix_softc *sc)
{
+ struct ixgbe_hw *hw = sc-hw;
+ struct ifmedia *ifm = sc-media;
uint32_tautoneg, err = 0;
int sfp, negotiate = FALSE;
@@ -1688,6 +1730,13 @@
err = sc-hw.mac.ops.setup_link(sc-hw, autoneg,
negotiate, sc-link_up);
}
+
+ /* 82599_SFP defaults to 10G when brought up, sync with user set */
+ if ((hw-device_id == PCI_PRODUCT_INTEL_82599_SFP)
+ (IFM_SUBTYPE(ifm-ifm_media) == IFM_1000_T)
+ (sc-hw.mac.ops.setup_link))
+ err = sc-hw.mac.ops.setup_link(sc-hw,
+ IXGBE_LINK_SPEED_1GB_FULL, FALSE, sc-link_up);
}
Re: uthum dropping out [was re ugold]
Hi,
Only I can remember is the NTC sensor calibration mechanism is
very complicated and it was hard to reverse engineering.
To fix (or discuss) the problem, I have to find my memo of the device.
Would you wait till next week? (all temper devices are in my office and
maybe the memo also in my office)
And... If you can capture the usb bus, would you send it to me?
It is very helpful to check.
-- Yojiro UO
On 2013/05/04, at 22:52, Stuart Henderson wrote:
On 2013/05/04 01:49, Stuart Henderson wrote:
On 2013/05/04 01:40, Stuart Henderson wrote:
--- uthum.c 15 Apr 2013 09:23:02 - 1.19
+++ uthum.c 4 May 2013 00:19:28 -
@@ -515,7 +515,7 @@ uthum_ntc_getdata(struct uthum_softc *sc
return EIO;
/* get sensor value */
- if (uthum_read_data(sc, CMD_GETDATA_NTC, buf, sizeof(buf), 10) != 0) {
+ if (uthum_read_data(sc, CMD_GETDATA_NTC, buf, sizeof(buf), 1000) != 0) {
DPRINTF((uthum: data read fail\n));
return EIO;
}
@@ -600,6 +600,7 @@ uthum_ntc_tuning(struct uthum_softc *sc,
}
ostate = state;
}
+ tsleep(sc-sc_sensortask, 0, uthum, hz * 10);
DPRINTF((uthum: ntc tuning done. state change: 0x%.2x-0x%.2x\n,
s-cur_state, state));
...of course, as soon as I send the diff out, I get a handful of
messages even with the huge delays
uthum_ntc_getdata: broken ntc data 0x16 0x00 0x31
uthum_refresh_temperntc: data read fail
uthum_ntc_getdata: broken ntc data 0x16 0x00 0x31
uthum_refresh_temperntc: data read fail
uthum_ntc_getdata: broken ntc data 0x16 0x00 0x31
uthum_refresh_temperntc: data read fail
but so far it has not got stuck, and the sensors stay attached.
I'll re-check later...
so... each time this happens, the sensor device disappears, which
some userland monitoring programs don't cope with particularly well.
This happens fairly often, e.g. at
11:38:28
11:38:44
11:39:18
11:52:43
11:53:00
11:53:17
12:05:42
12:07:16 ...
I noticed that uthum_ntc_tuning() calls uthum_ntc_getdata() and permits
it to retry 3 times. New diff below takes a different approach: leave
timeouts as they were, and move this retry code up into uthum_ntc_getdata().
With this I do hit some broken ntc data DPRINTFs, however after retrying
the read is successful; sensor is updated and things are more robust.
I've also changed some DPRINTF() to make it clear which function
they're called from.
May 4 14:31:16 slate /bsd: uhidev0 at uhub0 port 2 configuration 1 interface
0 Ten X Technology, Inc. TEMPer sensor rev 1.10/1.50 addr 2
May 4 14:31:16 slate /bsd: uhidev0: iclass 3/1
May 4 14:31:16 slate /bsd: uthum0 at uhidev0
May 4 14:31:16 slate /bsd: uhidev1 at uhub0 port 2 configuration 1 interface
1 Ten X Technology, Inc. TEMPer sensor rev 1.10/1.50 addr 2
May 4 14:31:16 slate /bsd: uhidev1: iclass 3/0
May 4 14:31:16 slate /bsd: uthum1 at uhidev1
May 4 14:31:16 slate /bsd: uthum1: type ds75/12bit (temperature),
calibration offset -1.0 degC
May 4 14:31:16 slate /bsd: uthum1: type NTC (temperature), calibration
offset 1.0 degC
May 4 14:31:16 slate /bsd: uthum_attach: complete
May 4 14:31:16 slate /bsd: uthum: ntc tuning start. cur state = 0x61, val =
0x83d4
May 4 14:31:17 slate /bsd: uthum: ntc tuning done. state change: 0x61-0x65
May 4 14:34:39 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
May 4 14:38:53 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
May 4 14:39:16 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x90 0x31
May 4 14:39:38 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
May 4 14:40:01 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
May 4 14:40:24 slate /bsd: uthum_ntc_getdata: broken ntc data 0x18 0x80 0x31
any comments? OK?
Index: uthum.c
===
RCS file: /cvs/src/sys/dev/usb/uthum.c,v
retrieving revision 1.20
diff -u -p -r1.20 uthum.c
--- uthum.c 4 May 2013 12:22:14 - 1.20
+++ uthum.c 4 May 2013 13:44:54 -
@@ -489,21 +489,31 @@ uthum_setup_sensors(struct uthum_softc *
int
uthum_ntc_getdata(struct uthum_softc *sc, int *val)
{
+ int retry = 3;
uint8_t buf[8];
if (val == NULL)
return EIO;
- /* get sensor value */
- if (uthum_read_data(sc, CMD_GETDATA_NTC, buf, sizeof(buf), 10) != 0) {
- DPRINTF((uthum: data read fail\n));
- return EIO;
+ while (retry) {
+ /* get sensor value */
+ if (uthum_read_data(sc, CMD_GETDATA_NTC,
+ buf, sizeof(buf), 10) != 0) {
+ DPRINTF((%s: data read fail\n, __FUNCTION__));
+ retry--;
+ continue;
+ }
+ /* check data integrity */
+ if (buf[2] != CMD_GETDATA_EOF2) {
+ DPRINTF((%s: broken ntc data 0x%.2x 0x%.2x
Re: uthum dropping out [was re ugold]
On 2013/05/04 23:32, Yojiro UO wrote: Hi, Only I can remember is the NTC sensor calibration mechanism is very complicated and it was hard to reverse engineering. To fix (or discuss) the problem, I have to find my memo of the device. Would you wait till next week? (all temper devices are in my office and maybe the memo also in my office) Yes, this is totally fine with me. Since posting I have hit the too many failures case with my diff now, right after tuning, so this helps my device a lot, but isn't perfect. It recovered after this, and there have been many other times when it has made 1 or 2 retries. May 4 16:05:28 symphytum /bsd: uthum1: type ds75/12bit (temperature), calibration offset -1.0 degC May 4 16:05:28 symphytum /bsd: uthum1: type NTC (temperature), calibration offset 1.0 degC May 4 16:05:28 symphytum /bsd: uthum_attach: complete May 4 16:05:28 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0xff 0xff 0xff May 4 16:05:28 symphytum /bsd: uthum: ntc tuning start. cur state = 0x65, val = 0x83bb May 4 16:05:28 symphytum /bsd: uthum: ntc tuning done. state change: 0x65-0x66 May 4 16:05:28 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x30 0x31 May 4 16:05:28 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x70 0x31 May 4 16:05:28 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x60 0x31 May 4 16:05:28 symphytum /bsd: uthum_ntc_getdata: too many failures May 4 16:05:28 symphytum /bsd: uthum_refresh_temperntc: data read fail ... May 4 16:07:43 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x60 0x31 May 4 16:08:35 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x50 0x31 May 4 16:11:33 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x30 0x31 May 4 16:11:33 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x30 0x31 ^^ so here, it retried 2 times May 4 16:20:58 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x30 0x31 May 4 16:26:55 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x60 0x31 May 4 16:28:17 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x50 0x31 May 4 16:29:02 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x40 0x31 May 4 16:29:17 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x40 0x31 May 4 16:31:46 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x50 0x31 May 4 16:31:46 symphytum /bsd: uthum_ntc_getdata: broken ntc data 0x15 0x50 0x31 ^^ and here And... If you can capture the usb bus, would you send it to me? It is very helpful to check. I have no hardware bus analyser, but maybe I can find a Windows machine with a software analyser to see if ThermoHID / UTAC do something different.
remove amd64 ioperm
We have never implemented amd64_get_ioperm and amd64_set_ioperm. There
are libarch stubs, but the kernel support has never been enabled. I'm
guessing nobody will miss it when it's gone.
The man page also contains amusing lies like The permission bitmap
contains 1024 bits in 32 longwords. It's hard to say how big the
permission bitmap is because it doesn't exist, but in any case 1024 /
64 is only 16.
Index: sys/arch/amd64/amd64/sys_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/sys_machdep.c,v
retrieving revision 1.12
diff -u -p -r1.12 sys_machdep.c
--- sys/arch/amd64/amd64/sys_machdep.c 13 Apr 2011 02:49:12 - 1.12
+++ sys/arch/amd64/amd64/sys_machdep.c 5 May 2013 01:22:07 -
@@ -60,10 +60,6 @@
extern struct vm_map *kernel_map;
-#if 0
-int amd64_get_ioperm(struct proc *, void *, register_t *);
-int amd64_set_ioperm(struct proc *, void *, register_t *);
-#endif
int amd64_iopl(struct proc *, void *, register_t *);
#ifdef APERTURE
@@ -99,42 +95,6 @@ amd64_iopl(struct proc *p, void *args, r
return 0;
}
-#if 0
-
-int
-amd64_get_ioperm(struct proc *p, void *args, register_t *retval)
-{
- int error;
- struct pcb *pcb = p-p_addr-u_pcb;
- struct amd64_get_ioperm_args ua;
-
- if ((error = copyin(args, ua, sizeof(ua))) != 0)
- return (error);
-
- return copyout(pcb-pcb_iomap, ua.iomap, sizeof(pcb-pcb_iomap));
-}
-
-int
-amd64_set_ioperm(struct proc *p, void *args, register_t *retval)
-{
- int error;
- struct pcb *pcb = p-p_addr-u_pcb;
- struct amd64_set_ioperm_args ua;
-
- if (securelevel 1)
- return EPERM;
-
- if ((error = suser(p, 0)) != 0)
- return error;
-
- if ((error = copyin(args, ua, sizeof(ua))) != 0)
- return (error);
-
- return copyin(ua.iomap, pcb-pcb_iomap, sizeof(pcb-pcb_iomap));
-}
-
-#endif
-
int
amd64_get_fsbase(struct proc *p, void *args)
{
@@ -171,16 +131,6 @@ sys_sysarch(struct proc *p, void *v, reg
case AMD64_IOPL:
error = amd64_iopl(p, SCARG(uap, parms), retval);
break;
-
-#if 0
- case AMD64_GET_IOPERM:
- error = amd64_get_ioperm(p, SCARG(uap, parms), retval);
- break;
-
- case AMD64_SET_IOPERM:
- error = amd64_set_ioperm(p, SCARG(uap, parms), retval);
- break;
-#endif
#if defined(PERFCTRS) 0
case AMD64_PMC_INFO:
Index: lib/libarch/amd64/Makefile
===
RCS file: /cvs/src/lib/libarch/amd64/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- lib/libarch/amd64/Makefile 13 Apr 2011 02:49:12 - 1.10
+++ lib/libarch/amd64/Makefile 5 May 2013 01:23:54 -
@@ -2,16 +2,13 @@
# $NetBSD: Makefile,v 1.1 1996/02/21 02:45:47 jtk Exp $
MANSUBDIR=amd64
-MAN+= amd64_iopl.2 amd64_get_ioperm.2 \
- amd64_get_fsbase.2
-MLINKS+=amd64_get_ioperm.2 amd64_set_ioperm.2 \
- amd64_get_fsbase.2 amd64_set_fsbase.2
+MAN+= amd64_iopl.2 amd64_get_fsbase.2
+MLINKS+=amd64_get_fsbase.2 amd64_set_fsbase.2
.if ${MACHINE_ARCH} == amd64
.PATH: ${LIBC}/amd64
NOPIC=
-SRCS+= amd64_iopl.c amd64_get_ioperm.c amd64_set_ioperm.c \
- amd64_get_fsbase.c amd64_set_fsbase.c
+SRCS+= amd64_iopl.c amd64_get_fsbase.c amd64_set_fsbase.c
.include bsd.lib.mk
.else
NOPROG=
Index: lib/libarch/amd64/amd64_iopl.2
===
RCS file: /cvs/src/lib/libarch/amd64/amd64_iopl.2,v
retrieving revision 1.6
diff -u -p -r1.6 amd64_iopl.2
--- lib/libarch/amd64/amd64_iopl.2 26 Jun 2008 05:42:04 - 1.6
+++ lib/libarch/amd64/amd64_iopl.2 5 May 2013 01:29:06 -
@@ -74,8 +74,6 @@ The caller was not the superuser, or the
has not been set to a non-zero value.
.El
.Sh SEE ALSO
-.Xr amd64_get_ioperm 2 ,
-.Xr amd64_set_ioperm 2 ,
.Xr securelevel 7
.Sh REFERENCES
.Rs
and deleted files...
i387 cleanup
remove some old 387 flotsam and jetsam.
Index: include/npx.h
===
RCS file: /cvs/src/sys/arch/i386/include/npx.h,v
retrieving revision 1.17
diff -u -p -r1.17 npx.h
--- include/npx.h 23 Mar 2011 16:54:35 - 1.17
+++ include/npx.h 5 May 2013 02:06:28 -
@@ -126,15 +126,7 @@ union savefpu {
struct savexmm sv_xmm;
};
-/* Cyrix EMC memory - mapped coprocessor context switch information */
-struct emcsts {
- longem_msw; /* memory mapped status register when swtched */
- longem_tar; /* memory mapped temp A register when swtched */
- longem_dl; /* memory mapped D low register when swtched */
-};
-
/* Intel prefers long real (53 bit) precision */
-#define __BDE_NPXCW__ 0x1272 /* FreeBSD */
#define__OpenBSD_NPXCW__ 0x37f
/*
@@ -150,8 +142,6 @@ struct emcsts {
* 64-bit precision
* all exceptions masked.
*/
-
-#define__INITIAL_NPXCW__ __OpenBSD_NPXCW__
voidprocess_xmm_to_s87(const struct savexmm *, struct save87 *);
voidprocess_s87_to_xmm(const struct save87 *, struct savexmm *);
Index: include/pcb.h
===
RCS file: /cvs/src/sys/arch/i386/include/pcb.h,v
retrieving revision 1.16
diff -u -p -r1.16 pcb.h
--- include/pcb.h 23 Mar 2011 16:54:35 - 1.16
+++ include/pcb.h 5 May 2013 02:06:28 -
@@ -63,7 +63,6 @@ struct pcb {
int pcb_ldt_len;/* number of LDT entries */
union savefpu pcb_savefpu;/* floating point state for FPU */
int pcb_cr0;/* saved image of CR0 */
- struct emcsts pcb_saveemc; /* Cyrix EMC state */
struct segment_descriptor pcb_threadsegs[2];
/* per-thread descriptors */
/*
Index: isa/npx.c
===
RCS file: /cvs/src/sys/arch/i386/isa/npx.c,v
retrieving revision 1.57
diff -u -p -r1.57 npx.c
--- isa/npx.c 11 Jul 2011 15:40:47 - 1.57
+++ isa/npx.c 5 May 2013 02:06:28 -
@@ -770,10 +770,6 @@ npxdna_s87(struct cpu_info *ci)
* not trigger an error (e.g., fnclex). On at least one 486
* system all of the no-wait instructions are broken the same
* as frstor, so our treatment does not amplify the breakage.
-* On at least one 386/Cyrix 387 system, fnclex works correctly
-* while frstor and fnsave are broken, so our treatment breaks
-* fnclex if it is the first FPU instruction after a context
-* switch.
*/
frstor(sfp-sv_87);
}
@@ -813,14 +809,6 @@ npxsave_cpu(struct cpu_info *ci, int sav
* Set ci-ci_fpsaving, so that any pending exception will be
* thrown away. (It will be caught again if/when the FPU
* state is restored.)
- *
- * XXX on i386 and earlier, this routine should always be
- * called at spl0; if it might called with the NPX interrupt
- * masked, it would be necessary to forcibly unmask the NPX
- * interrupt so that it could succeed.
- * XXX this is irrelevant on 486 and above (systems
- * which report FP failures via traps rather than irq13).
- * XXX punting for now..
*/
clts();
ci-ci_fpsaving = 1;
@@ -915,7 +903,7 @@ fpu_kernel_enter(void)
/* Initialize the FPU */
fninit();
- cw = __INITIAL_NPXCW__;
+ cw = __OpenBSD_NPXCW__;
fldcw(cw);
if (i386_has_sse || i386_has_sse2) {
cw = __INITIAL_MXCSR__;
Re: remove amd64 ioperm
On Sat, May 4, 2013 at 6:32 PM, Ted Unangst t...@tedunangst.com wrote: We have never implemented amd64_get_ioperm and amd64_set_ioperm. There are libarch stubs, but the kernel support has never been enabled. I'm guessing nobody will miss it when it's gone. ok guenther@ The man page also contains amusing lies like The permission bitmap contains 1024 bits in 32 longwords. It's hard to say how big the permission bitmap is because it doesn't exist, but in any case 1024 / 64 is only 16. Clearly copied from the i386_set_ioperm() manpage without adjustment...
