Re: vmctl: parse_size(): Use local variable instead of function parameter
* Klemens Nanni [2019-12-16 23:42:04 +0100]: On Fri, Dec 06, 2019 at 06:49:52PM +0100, Klemens Nanni wrote: The parse_size() wrapper around scan_scaled(3) writes its intermediate result to the function argument which is always passed as literal zero. This seems odd, the function parameter has no meaning but merely serves as storage, so let's use a proper function scoped variable instead. OK? Ping. That's better. ok! -- Pratik
audio(4): *sleep(9) -> *sleep_nsec(9)
ok?
Index: audio.c
===
RCS file: /cvs/src/sys/dev/audio.c,v
retrieving revision 1.183
diff -u -p -r1.183 audio.c
--- audio.c 7 Oct 2019 10:47:08 - 1.183
+++ audio.c 17 Dec 2019 00:52:48 -
@@ -1492,8 +1492,8 @@ audio_drain(struct audio_softc *sc)
* work, useful only for debugging drivers
*/
sc->play.blocking = 1;
- error = msleep(>play.blocking, _lock,
- PWAIT | PCATCH, "au_dr", 5 * hz);
+ error = msleep_nsec(>play.blocking, _lock,
+ PWAIT | PCATCH, "au_dr", SEC_TO_NSEC(5));
if (!(sc->dev.dv_flags & DVF_ACTIVE))
error = EIO;
if (error) {
@@ -1547,8 +1547,8 @@ audio_read(struct audio_softc *sc, struc
}
DPRINTFN(1, "%s: read sleep\n", DEVNAME(sc));
sc->rec.blocking = 1;
- error = msleep(>rec.blocking,
- _lock, PWAIT | PCATCH, "au_rd", 0);
+ error = msleep_nsec(>rec.blocking,
+ _lock, PWAIT | PCATCH, "au_rd", INFSLP);
if (!(sc->dev.dv_flags & DVF_ACTIVE))
error = EIO;
if (error) {
@@ -1620,8 +1620,8 @@ audio_write(struct audio_softc *sc, stru
}
DPRINTFN(1, "%s: write sleep\n", DEVNAME(sc));
sc->play.blocking = 1;
- error = msleep(>play.blocking,
- _lock, PWAIT | PCATCH, "au_wr", 0);
+ error = msleep_nsec(>play.blocking,
+ _lock, PWAIT | PCATCH, "au_wr", INFSLP);
if (!(sc->dev.dv_flags & DVF_ACTIVE))
error = EIO;
if (error) {
Re: [PATCH] add support for more Nuvoton chips to lm(4)
Hi Joe, On Mon, Dec 16, 2019 at 12:04:57PM -0500, Joe Gidi wrote: > Hi Todd, > > Thanks for taking the time to review and offer improvements. I'm attaching > a new diff that incorporates your suggestion for simplifying the matching > and eliminating the unneeded struct and function. It is definitely a > cleaner, simpler approach. I also corrected the whitespace issue you > pointed out. > > I made a few tweaks to the voltage calculations. I actually spent quite a > bit of time going down the rabbit hole here, and while I made some > improvements, it is definitely not perfect yet. I removed the division by > 2 from Vcore; I'm pretty confident this is correct, because I'm now seeing > the voltage I expect, and the datasheet says: > > "The CPUVCORE pin feeds directly into the ADC with no voltage divider > since the nominal voltage on this pin is only 1.2V." I think this is right - I read the docs the same way, and the nnumber is right. > I actually installed Windows on this machine so I could run HWiNFO64 and > see how the sensors looked there; I'm including a screenshot for your > reference. Under Windows, it looks like the sensors are enumerated and > displayed in the same order, though VBAT and VTT are skipped. Windows > appears to have VIN2 and VIN3 labeled as +12V and +5V, though the values I > see in HWiNFO64 are both slightly low and disagree with the values I see > in the BIOS. With the current version of my patch, VIN3 looks correct and > matches the BIOS value for +5V but VIN2 is low by a factor of about 3.5. I > adjusted VIN4, VIN5 and VIN6 by dividing by 2; this brings their readings > in line with what I see in HWiNFO64. This is indeed a rabbit hole. :-) My reading of the datasheet leads me to believe interpreting the VIN values depends on what is hooked up to them, so this is just trial and error, as you say below. > From what I've read from the Linux lm_sensors folks, it's a > trial-and-error process to adjust these values correctly, and sometimes > the readings are just garbage. As it stands, the patch is definitely > better than not having sensors, and these values could always be tweaked > with subsequent patches. If you have any suggestions for improvements > here, please let me know. Patch looks good to me. As you say, tweaking the voltage adjustments is easy if we find we need to later. > Thanks again for your help; I hope this patch is able to go in. I committed it as is just now. Thank you! Cheers, Todd
Re: vmctl: parse_size(): Use local variable instead of function parameter
On Fri, Dec 06, 2019 at 06:49:52PM +0100, Klemens Nanni wrote:
> The parse_size() wrapper around scan_scaled(3) writes its intermediate
> result to the function argument which is always passed as literal zero.
>
> This seems odd, the function parameter has no meaning but merely serves
> as storage, so let's use a proper function scoped variable instead.
>
> OK?
Ping.
Index: main.c
===
RCS file: /cvs/src/usr.sbin/vmctl/main.c,v
retrieving revision 1.59
diff -u -p -r1.59 main.c
--- main.c 27 Oct 2019 08:59:48 - 1.59
+++ main.c 16 Dec 2019 22:41:18 -
@@ -407,8 +407,10 @@ parse_network(struct parse_result *res,
}
int
-parse_size(struct parse_result *res, char *word, long long val)
+parse_size(struct parse_result *res, char *word)
{
+ long long val = 0;
+
if (word != NULL) {
if (scan_scaled(word, ) != 0) {
warn("invalid size: %s", word);
@@ -576,7 +578,7 @@ ctl_create(struct parse_result *res, int
err(1, "unveil");
break;
case 's':
- if (parse_size(res, optarg, 0) != 0)
+ if (parse_size(res, optarg) != 0)
errx(1, "invalid size: %s", optarg);
break;
default:
@@ -872,7 +874,7 @@ ctl_start(struct parse_result *res, int
case 'm':
if (res->size)
errx(1, "memory specified multiple times");
- if (parse_size(res, optarg, 0) != 0)
+ if (parse_size(res, optarg) != 0)
errx(1, "invalid memory size: %s", optarg);
break;
case 'n':
Index: vmctl.h
===
RCS file: /cvs/src/usr.sbin/vmctl/vmctl.h,v
retrieving revision 1.32
diff -u -p -r1.32 vmctl.h
--- vmctl.h 11 May 2019 23:07:46 - 1.32
+++ vmctl.h 16 Dec 2019 22:41:18 -
@@ -77,7 +77,7 @@ struct imsgbuf*ibuf;
int vmmaction(struct parse_result *);
int parse_ifs(struct parse_result *, char *, int);
int parse_network(struct parse_result *, char *);
-int parse_size(struct parse_result *, char *, long long);
+int parse_size(struct parse_result *, char *);
int parse_disktype(const char *, const char **);
int parse_disk(struct parse_result *, char *, int);
int parse_vmid(struct parse_result *, char *, int);
openssl.1: note default -md value for openssl enc and how to get list of available hashes
This diff changes the documentation of openssl(1) enc to note the
default value (sha256) and replace the "hardcoded" list of md5, sha1
with instructions to use list-message-digest-algorithms instead.
Inspired by a conversation on misc@ a few weeks ago ("LibreSSL vs.
OpenSSL enc command").
Perhaps it's also worthwhile to have a HISTORY section/subsection or
historical note about this since it's probably of interoperability
concern for older files.
Index: usr.bin/openssl/openssl.1
===
RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
retrieving revision 1.116
diff -u -p -r1.116 openssl.1
--- usr.bin/openssl/openssl.1 28 Nov 2019 11:21:33 - 1.116
+++ usr.bin/openssl/openssl.1 16 Dec 2019 18:09:54 -
@@ -416,10 +416,10 @@ The default is
.Cm pem .
.It Fl md Ar alg
The message digest to use.
-Possible values include
-.Ar md5
-and
-.Ar sha1 .
+A list of possible values can be obtained with the pseudo-command
+.Cm list-message-digest-algorithms .
+The default value is
+.Ar sha256 .
This option also applies to CRLs.
.It Fl msie_hack
This is a legacy option to make
Re: piixpm(4) add support for newer AMD chipsets
On Mon, Dec 16, 2019 at 09:05:47PM +0100, Claudio Jeker wrote:
> On Mon, Dec 16, 2019 at 08:02:55PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 16 Dec 2019 12:37:51 +0100
> > > From: Claudio Jeker
> > >
> > > This diff should add support for newer smbus controllers used on newer AMD
> > > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the
> > > iic(4) busses attach but there is nothing detected on them (well possible
> > > that I missed something). I also implemented the up to 4 busses available
> > > on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports).
> > >
> > > I would be interested if on systems with Ryzen CPUs something attaches to
> > > those iic(4) busses. Could be that I missed something and fail to properly
> > > access the bus.
> > > --
> > > :wq Claudio
> >
> > Looks good to me. A few nits below. Otherwise ok kettenis@
> >
> > > Index: piixpm.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/piixpm.c,v
> > > retrieving revision 1.39
> > > diff -u -p -r1.39 piixpm.c
> > > --- piixpm.c 1 Oct 2013 20:06:02 - 1.39
> > > +++ piixpm.c 16 Dec 2019 11:26:11 -
> > > @@ -45,15 +45,24 @@
> > > #define PIIXPM_DELAY 200
> > > #define PIIXPM_TIMEOUT 1
> > >
> > > +struct piixpm_smbus {
> > > + int sb_bus;
> > > + struct piixpm_softc *sb_sc;
> > > +};
> > > +
> > > struct piixpm_softc {
> > > struct device sc_dev;
> > >
> > > bus_space_tag_t sc_iot;
> > > bus_space_handle_t sc_ioh;
> > > + bus_space_handle_t sc_sb800_ioh;
> > > void * sc_ih;
> > > int sc_poll;
> > > + int sc_is_sb800;
> > > + int sc_is_kerncz;
> >
> > Can this be called sc_is_hudson2 or maybe sc_is_fch instead? It makes
> > more sense to have this variable describe the oldest variant instead
> > of the newest. I actually think sc_is_fch is the best name.
>
> Changed it to sc_is_fch.
>
> > >
> > > - struct i2c_controller sc_i2c_tag;
> > > + struct piixpm_smbus sc_busses[4];
> > > + struct i2c_controller sc_i2c_tag[4];
> > > struct rwlock sc_i2c_lock;
> > > struct {
> > > i2c_op_t op;
> > > @@ -86,6 +95,7 @@ struct cfdriver piixpm_cd = {
> > >
> > > const struct pci_matchid piixpm_ids[] = {
> > > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SMB },
> > > + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_KERNCZ_SMB },
> > >
> > > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB200_SMB },
> > > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB300_SMB },
> > > @@ -117,17 +127,21 @@ piixpm_attach(struct device *parent, str
> > > struct piixpm_softc *sc = (struct piixpm_softc *)self;
> > > struct pci_attach_args *pa = aux;
> > > bus_space_handle_t ioh;
> > > - u_int16_t smb0en;
> > > + u_int16_t val, smb0en;
> > > bus_addr_t base;
> > > pcireg_t conf;
> > > pci_intr_handle_t ih;
> > > const char *intrstr = NULL;
> > > struct i2cbus_attach_args iba;
> > > + int numbusses, i;
> > >
> > > sc->sc_iot = pa->pa_iot;
> > > + numbusses = 1;
> > >
> > > if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> > > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB) ||
> > > + (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> > > + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_KERNCZ_SMB) ||
> > > (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI &&
> > > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SBX00_SMB &&
> > > PCI_REVISION(pa->pa_class) >= 0x40)) {
> > > @@ -136,10 +150,7 @@ piixpm_attach(struct device *parent, str
> > >* hidden. We need to look at the "SMBus0En" Power
> > >* Management register to find out where they live.
> > >* We use indirect IO access through the index/data
> > > - * pair at 0xcd6/0xcd7 to access "SMBus0En". Since
> > > - * the index/data pair may be needed by other drivers,
> > > - * we only map them for the duration that we actually
> > > - * need them.
> > > + * pair at 0xcd6/0xcd7 to access "SMBus0En".
> > >*/
> >
> > I don't remember why we chose to immediately unmap the registers here.
> > So this may cause some breakage. Probably worth the risk.
>
> If someone wants to write a watchdog driver then something would be needed
> to allow both drivers access to this io range. Nothing else is using the
> piixreg.h file so I doubt this is a big issue. If we hit it than we can
> refactor the drivers.
Yes, I did this because I wasn't sure if some other driver might end
up needing to access those registers. The 0xcd6/0xcd7 pair were only
used to find the SMBus address, as the PCI device had no BARs.
I'm ok with this (and the rest).
> > > if (bus_space_map(sc->sc_iot, SB800_PMREG_BASE,
> > > SB800_PMREG_SIZE, 0, ) != 0) {
> > > @@ -147,29 +158,61 @@ piixpm_attach(struct device
Re: piixpm(4) add support for newer AMD chipsets
> Date: Mon, 16 Dec 2019 21:05:47 +0100
> From: Claudio Jeker
> Cc: tech@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Mon, Dec 16, 2019 at 08:02:55PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 16 Dec 2019 12:37:51 +0100
> > > From: Claudio Jeker
> > >
> > > This diff should add support for newer smbus controllers used on newer AMD
> > > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the
> > > iic(4) busses attach but there is nothing detected on them (well possible
> > > that I missed something). I also implemented the up to 4 busses available
> > > on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports).
> > >
> > > I would be interested if on systems with Ryzen CPUs something attaches to
> > > those iic(4) busses. Could be that I missed something and fail to properly
> > > access the bus.
> > > --
> > > :wq Claudio
> >
> > Looks good to me. A few nits below. Otherwise ok kettenis@
> >
> > > Index: piixpm.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/piixpm.c,v
> > > retrieving revision 1.39
> > > diff -u -p -r1.39 piixpm.c
> > > --- piixpm.c 1 Oct 2013 20:06:02 - 1.39
> > > +++ piixpm.c 16 Dec 2019 11:26:11 -
> > > @@ -45,15 +45,24 @@
> > > #define PIIXPM_DELAY 200
> > > #define PIIXPM_TIMEOUT 1
> > >
> > > +struct piixpm_smbus {
> > > + int sb_bus;
> > > + struct piixpm_softc *sb_sc;
> > > +};
> > > +
> > > struct piixpm_softc {
> > > struct device sc_dev;
> > >
> > > bus_space_tag_t sc_iot;
> > > bus_space_handle_t sc_ioh;
> > > + bus_space_handle_t sc_sb800_ioh;
> > > void * sc_ih;
> > > int sc_poll;
> > > + int sc_is_sb800;
> > > + int sc_is_kerncz;
> >
> > Can this be called sc_is_hudson2 or maybe sc_is_fch instead? It makes
> > more sense to have this variable describe the oldest variant instead
> > of the newest. I actually think sc_is_fch is the best name.
>
> Changed it to sc_is_fch.
>
> > >
> > > - struct i2c_controller sc_i2c_tag;
> > > + struct piixpm_smbus sc_busses[4];
> > > + struct i2c_controller sc_i2c_tag[4];
> > > struct rwlock sc_i2c_lock;
> > > struct {
> > > i2c_op_t op;
> > > @@ -86,6 +95,7 @@ struct cfdriver piixpm_cd = {
> > >
> > > const struct pci_matchid piixpm_ids[] = {
> > > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SMB },
> > > + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_KERNCZ_SMB },
> > >
> > > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB200_SMB },
> > > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB300_SMB },
> > > @@ -117,17 +127,21 @@ piixpm_attach(struct device *parent, str
> > > struct piixpm_softc *sc = (struct piixpm_softc *)self;
> > > struct pci_attach_args *pa = aux;
> > > bus_space_handle_t ioh;
> > > - u_int16_t smb0en;
> > > + u_int16_t val, smb0en;
> > > bus_addr_t base;
> > > pcireg_t conf;
> > > pci_intr_handle_t ih;
> > > const char *intrstr = NULL;
> > > struct i2cbus_attach_args iba;
> > > + int numbusses, i;
> > >
> > > sc->sc_iot = pa->pa_iot;
> > > + numbusses = 1;
> > >
> > > if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> > > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB) ||
> > > + (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> > > + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_KERNCZ_SMB) ||
> > > (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI &&
> > > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SBX00_SMB &&
> > > PCI_REVISION(pa->pa_class) >= 0x40)) {
> > > @@ -136,10 +150,7 @@ piixpm_attach(struct device *parent, str
> > >* hidden. We need to look at the "SMBus0En" Power
> > >* Management register to find out where they live.
> > >* We use indirect IO access through the index/data
> > > - * pair at 0xcd6/0xcd7 to access "SMBus0En". Since
> > > - * the index/data pair may be needed by other drivers,
> > > - * we only map them for the duration that we actually
> > > - * need them.
> > > + * pair at 0xcd6/0xcd7 to access "SMBus0En".
> > >*/
> >
> > I don't remember why we chose to immediately unmap the registers here.
> > So this may cause some breakage. Probably worth the risk.
>
> If someone wants to write a watchdog driver then something would be needed
> to allow both drivers access to this io range. Nothing else is using the
> piixreg.h file so I doubt this is a big issue. If we hit it than we can
> refactor the drivers.
>
> > > if (bus_space_map(sc->sc_iot, SB800_PMREG_BASE,
> > > SB800_PMREG_SIZE, 0, ) != 0) {
> > > @@ -147,29 +158,61 @@ piixpm_attach(struct device *parent, str
> > > return;
> > > }
> > >
> > > - /* Read "SmBus0En" */
> > > -
Re: piixpm(4) add support for newer AMD chipsets
On Mon, Dec 16, 2019 at 08:02:55PM +0100, Mark Kettenis wrote:
> > Date: Mon, 16 Dec 2019 12:37:51 +0100
> > From: Claudio Jeker
> >
> > This diff should add support for newer smbus controllers used on newer AMD
> > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the
> > iic(4) busses attach but there is nothing detected on them (well possible
> > that I missed something). I also implemented the up to 4 busses available
> > on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports).
> >
> > I would be interested if on systems with Ryzen CPUs something attaches to
> > those iic(4) busses. Could be that I missed something and fail to properly
> > access the bus.
> > --
> > :wq Claudio
>
> Looks good to me. A few nits below. Otherwise ok kettenis@
>
> > Index: piixpm.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/piixpm.c,v
> > retrieving revision 1.39
> > diff -u -p -r1.39 piixpm.c
> > --- piixpm.c1 Oct 2013 20:06:02 - 1.39
> > +++ piixpm.c16 Dec 2019 11:26:11 -
> > @@ -45,15 +45,24 @@
> > #define PIIXPM_DELAY 200
> > #define PIIXPM_TIMEOUT 1
> >
> > +struct piixpm_smbus {
> > + int sb_bus;
> > + struct piixpm_softc *sb_sc;
> > +};
> > +
> > struct piixpm_softc {
> > struct device sc_dev;
> >
> > bus_space_tag_t sc_iot;
> > bus_space_handle_t sc_ioh;
> > + bus_space_handle_t sc_sb800_ioh;
> > void * sc_ih;
> > int sc_poll;
> > + int sc_is_sb800;
> > + int sc_is_kerncz;
>
> Can this be called sc_is_hudson2 or maybe sc_is_fch instead? It makes
> more sense to have this variable describe the oldest variant instead
> of the newest. I actually think sc_is_fch is the best name.
Changed it to sc_is_fch.
> >
> > - struct i2c_controller sc_i2c_tag;
> > + struct piixpm_smbus sc_busses[4];
> > + struct i2c_controller sc_i2c_tag[4];
> > struct rwlock sc_i2c_lock;
> > struct {
> > i2c_op_t op;
> > @@ -86,6 +95,7 @@ struct cfdriver piixpm_cd = {
> >
> > const struct pci_matchid piixpm_ids[] = {
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SMB },
> > + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_KERNCZ_SMB },
> >
> > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB200_SMB },
> > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB300_SMB },
> > @@ -117,17 +127,21 @@ piixpm_attach(struct device *parent, str
> > struct piixpm_softc *sc = (struct piixpm_softc *)self;
> > struct pci_attach_args *pa = aux;
> > bus_space_handle_t ioh;
> > - u_int16_t smb0en;
> > + u_int16_t val, smb0en;
> > bus_addr_t base;
> > pcireg_t conf;
> > pci_intr_handle_t ih;
> > const char *intrstr = NULL;
> > struct i2cbus_attach_args iba;
> > + int numbusses, i;
> >
> > sc->sc_iot = pa->pa_iot;
> > + numbusses = 1;
> >
> > if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB) ||
> > + (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> > + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_KERNCZ_SMB) ||
> > (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI &&
> > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SBX00_SMB &&
> > PCI_REVISION(pa->pa_class) >= 0x40)) {
> > @@ -136,10 +150,7 @@ piixpm_attach(struct device *parent, str
> > * hidden. We need to look at the "SMBus0En" Power
> > * Management register to find out where they live.
> > * We use indirect IO access through the index/data
> > -* pair at 0xcd6/0xcd7 to access "SMBus0En". Since
> > -* the index/data pair may be needed by other drivers,
> > -* we only map them for the duration that we actually
> > -* need them.
> > +* pair at 0xcd6/0xcd7 to access "SMBus0En".
> > */
>
> I don't remember why we chose to immediately unmap the registers here.
> So this may cause some breakage. Probably worth the risk.
If someone wants to write a watchdog driver then something would be needed
to allow both drivers access to this io range. Nothing else is using the
piixreg.h file so I doubt this is a big issue. If we hit it than we can
refactor the drivers.
> > if (bus_space_map(sc->sc_iot, SB800_PMREG_BASE,
> > SB800_PMREG_SIZE, 0, ) != 0) {
> > @@ -147,29 +158,61 @@ piixpm_attach(struct device *parent, str
> > return;
> > }
> >
> > - /* Read "SmBus0En" */
> > - bus_space_write_1(sc->sc_iot, ioh, 0, SB800_PMREG_SMB0EN);
> > - smb0en = bus_space_read_1(sc->sc_iot, ioh, 1);
> > - bus_space_write_1(sc->sc_iot, ioh, 0, SB800_PMREG_SMB0EN + 1);
> > - smb0en |= (bus_space_read_1(sc->sc_iot, ioh, 1) << 8);
> > -
> > -
Re: piixpm(4) add support for newer AMD chipsets
On Mon, Dec 16, 2019 at 12:37:51PM +0100, Claudio Jeker wrote: > This diff should add support for newer smbus controllers used on newer AMD > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the > iic(4) busses attach but there is nothing detected on them (well possible > that I missed something). I also implemented the up to 4 busses available > on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports). > > I would be interested if on systems with Ryzen CPUs something attaches to > those iic(4) busses. Could be that I missed something and fail to properly > access the bus. > -- > :wq Claudio On a ThinkPad x395 with: cpu0: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2296.08 MHz, 17-18-01 I observe this change in dmesg: -"AMD FCH SMBus" rev 0x61 at pci0 dev 20 function 0 not configured +piixpm0 at pci0 dev 20 function 0 "AMD FCH SMBus" rev 0x61: polling +iic0 at piixpm0 +iic1 at piixpm0 Full dmesg below: OpenBSD 6.6-current (GENERIC.MP) #1: Mon Dec 16 20:44:36 CET 2019 jas...@tau.office.jasper.la:/sys/arch/amd64/compile/GENERIC.MP real mem = 14888513536 (14198MB) avail mem = 14424879104 (13756MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xb9ecc000 (63 entries) bios0: vendor LENOVO version "R13ET39W(1.13 )" date 10/11/2019 bios0: LENOVO 20NLCTO1WW acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT MSDM SLIC BATB HPET APIC MCFG SBST WSMT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) L850(S3) GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2296.00 MHz, 17-18-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2295.67 MHz, 17-18-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2295.67 MHz, 17-18-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx, 2295.67 MHz, 17-18-01 cpu3:
Re: [PATCH] add support for more Nuvoton chips to lm(4)
Joe Gidi wrote: > Hi Todd, > > Thanks for taking the time to review and offer improvements. I'm attaching > a new diff that incorporates your suggestion for simplifying the matching > and eliminating the unneeded struct and function. It is definitely a > cleaner, simpler approach. I also corrected the whitespace issue you > pointed out. > > I made a few tweaks to the voltage calculations. I actually spent quite a > bit of time going down the rabbit hole here, and while I made some > improvements, it is definitely not perfect yet. I removed the division by > 2 from Vcore; I'm pretty confident this is correct, because I'm now seeing > the voltage I expect, and the datasheet says: > > "The CPUVCORE pin feeds directly into the ADC with no voltage divider > since the nominal voltage on this pin is only 1.2V." > > I actually installed Windows on this machine so I could run HWiNFO64 and > see how the sensors looked there; I'm including a screenshot for your > reference. Under Windows, it looks like the sensors are enumerated and > displayed in the same order, though VBAT and VTT are skipped. Windows > appears to have VIN2 and VIN3 labeled as +12V and +5V, though the values I > see in HWiNFO64 are both slightly low and disagree with the values I see > in the BIOS. With the current version of my patch, VIN3 looks correct and > matches the BIOS value for +5V but VIN2 is low by a factor of about 3.5. I > adjusted VIN4, VIN5 and VIN6 by dividing by 2; this brings their readings > in line with what I see in HWiNFO64. > > From what I've read from the Linux lm_sensors folks, it's a > trial-and-error process to adjust these values correctly, and sometimes > the readings are just garbage. As it stands, the patch is definitely > better than not having sensors, and these values could always be tweaked > with subsequent patches. If you have any suggestions for improvements > here, please let me know. What you just said is *on your machine*, or maybe not. It is a disaster out there. Do not worry about the inaccuracies. There are no tables which map this either.
Re: [PATCH] add support for more Nuvoton chips to lm(4)
Hi Todd, Thanks for taking the time to review and offer improvements. I'm attaching a new diff that incorporates your suggestion for simplifying the matching and eliminating the unneeded struct and function. It is definitely a cleaner, simpler approach. I also corrected the whitespace issue you pointed out. I made a few tweaks to the voltage calculations. I actually spent quite a bit of time going down the rabbit hole here, and while I made some improvements, it is definitely not perfect yet. I removed the division by 2 from Vcore; I'm pretty confident this is correct, because I'm now seeing the voltage I expect, and the datasheet says: "The CPUVCORE pin feeds directly into the ADC with no voltage divider since the nominal voltage on this pin is only 1.2V." I actually installed Windows on this machine so I could run HWiNFO64 and see how the sensors looked there; I'm including a screenshot for your reference. Under Windows, it looks like the sensors are enumerated and displayed in the same order, though VBAT and VTT are skipped. Windows appears to have VIN2 and VIN3 labeled as +12V and +5V, though the values I see in HWiNFO64 are both slightly low and disagree with the values I see in the BIOS. With the current version of my patch, VIN3 looks correct and matches the BIOS value for +5V but VIN2 is low by a factor of about 3.5. I adjusted VIN4, VIN5 and VIN6 by dividing by 2; this brings their readings in line with what I see in HWiNFO64. >From what I've read from the Linux lm_sensors folks, it's a trial-and-error process to adjust these values correctly, and sometimes the readings are just garbage. As it stands, the patch is definitely better than not having sensors, and these values could always be tweaked with subsequent patches. If you have any suggestions for improvements here, please let me know. Thanks again for your help; I hope this patch is able to go in. Joe > Hello, > > On Fri, Dec 13, 2019 at 06:32:36PM -0500, Joe Gidi wrote: >> Hi all, >> >> I recently built a new system with an ASRock B450M Pro4 motherboard. > > I literally fired up a new system with the exact same board today and > saw the temp sensors didn't appear to be supported, so I'm very happy > that you posted this! > >> This board has a Nuvoton NCT6779D chip to monitor temperatures, fans and >> voltages. OpenBSD's lm(4) currently only supports the Nuvoton NCT6776F >> chip, added by Marco Pfatschbacher in 2011: >> >> https://marc.info/?l=openbsd-cvs=132318770131497=2 >> >> NetBSD's lm(4) gained support for several other Nuvoton chips in this >> commit by SAITOH Masanobu in 2017: >> >> http://mail-index.netbsd.org/source-changes/2017/07/11/msg086253.html >> >> I have adapted the NetBSD code to OpenBSD and confirmed that it appears >> to >> work correctly with my NCT6779D chip. With the attached patch, I get >> this >> in dmesg: >> >> wbsio0 at isa0 port 0x2e/2: NCT6779D rev 0x62 >> lm1 at wbsio0 port 0x290/8: NCT6779D >> >> And here's the sensor data: >> >> $ sysctl hw.sensors.lm1 >> hw.sensors.lm1.temp0=29.00 degC (MB Temperature) >> hw.sensors.lm1.temp1=31.00 degC (CPU Temperature) >> hw.sensors.lm1.temp2=78.00 degC (Aux Temp0) >> hw.sensors.lm1.temp3=98.00 degC (Aux Temp1) >> hw.sensors.lm1.temp4=22.50 degC (Aux Temp2) >> hw.sensors.lm1.temp5=-23.00 degC (Aux Temp3) >> hw.sensors.lm1.fan0=1095 RPM (System Fan) >> hw.sensors.lm1.fan1=739 RPM (CPU Fan) >> hw.sensors.lm1.fan2=400 RPM (Aux Fan0) >> hw.sensors.lm1.fan3=0 RPM (Aux Fan1) >> hw.sensors.lm1.fan4=387 RPM (Aux Fan2) >> hw.sensors.lm1.volt0=0.74 VDC (VCore) >> hw.sensors.lm1.volt1=2.16 VDC (VIN1) >> hw.sensors.lm1.volt2=3.33 VDC (AVCC) >> hw.sensors.lm1.volt3=3.33 VDC (+3.3V) >> hw.sensors.lm1.volt4=21.56 VDC (VIN0) >> hw.sensors.lm1.volt5=0.87 VDC (VIN8) >> hw.sensors.lm1.volt6=0.59 VDC (VIN4) >> hw.sensors.lm1.volt7=3.46 VDC (+3.3VSB) >> hw.sensors.lm1.volt8=0.00 VDC (VBAT) >> hw.sensors.lm1.volt9=0.00 VDC (VTT) >> hw.sensors.lm1.volt10=0.45 VDC (VIN5) >> hw.sensors.lm1.volt11=2.13 VDC (VIN6) >> hw.sensors.lm1.volt12=3.38 VDC (VIN2) >> hw.sensors.lm1.volt13=5.12 VDC (VIN3) >> hw.sensors.lm1.volt14=1.81 VDC (VIN7) >> >> The motherboard and CPU temperature values look very reasonable; the Aux >> Temp values look like garbage, possibly because there aren't any other >> sensors on this board? Fan values look reasonable. I am unsure about the >> voltage values, but the ones that claim to be 3.3 volts look sane. > > I see similar numbers with your patch applied. > > The BIOS doesn't show any other temperature values, so it is possble the > Aux Temp sensors aren't hooked up to anything. In any event, the read > procedure looks the same as the others (according to the datasheet), so > I don't think it is wrong. > >> This is the first non-trivial patch I'm submitting and my C is pretty >> rusty, so I would appreciate review and corrections. I don't have any >> other systems with different Nuvoton chips to test, so I can't confirm >> that this works for the other chips. >> >>
Re: piixpm(4) add support for newer AMD chipsets
> Date: Mon, 16 Dec 2019 12:37:51 +0100
> From: Claudio Jeker
>
> This diff should add support for newer smbus controllers used on newer AMD
> chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the
> iic(4) busses attach but there is nothing detected on them (well possible
> that I missed something). I also implemented the up to 4 busses available
> on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports).
>
> I would be interested if on systems with Ryzen CPUs something attaches to
> those iic(4) busses. Could be that I missed something and fail to properly
> access the bus.
> --
> :wq Claudio
Looks good to me. A few nits below. Otherwise ok kettenis@
> Index: piixpm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/piixpm.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 piixpm.c
> --- piixpm.c 1 Oct 2013 20:06:02 - 1.39
> +++ piixpm.c 16 Dec 2019 11:26:11 -
> @@ -45,15 +45,24 @@
> #define PIIXPM_DELAY 200
> #define PIIXPM_TIMEOUT 1
>
> +struct piixpm_smbus {
> + int sb_bus;
> + struct piixpm_softc *sb_sc;
> +};
> +
> struct piixpm_softc {
> struct device sc_dev;
>
> bus_space_tag_t sc_iot;
> bus_space_handle_t sc_ioh;
> + bus_space_handle_t sc_sb800_ioh;
> void * sc_ih;
> int sc_poll;
> + int sc_is_sb800;
> + int sc_is_kerncz;
Can this be called sc_is_hudson2 or maybe sc_is_fch instead? It makes
more sense to have this variable describe the oldest variant instead
of the newest. I actually think sc_is_fch is the best name.
>
> - struct i2c_controller sc_i2c_tag;
> + struct piixpm_smbus sc_busses[4];
> + struct i2c_controller sc_i2c_tag[4];
> struct rwlock sc_i2c_lock;
> struct {
> i2c_op_t op;
> @@ -86,6 +95,7 @@ struct cfdriver piixpm_cd = {
>
> const struct pci_matchid piixpm_ids[] = {
> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SMB },
> + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_KERNCZ_SMB },
>
> { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB200_SMB },
> { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB300_SMB },
> @@ -117,17 +127,21 @@ piixpm_attach(struct device *parent, str
> struct piixpm_softc *sc = (struct piixpm_softc *)self;
> struct pci_attach_args *pa = aux;
> bus_space_handle_t ioh;
> - u_int16_t smb0en;
> + u_int16_t val, smb0en;
> bus_addr_t base;
> pcireg_t conf;
> pci_intr_handle_t ih;
> const char *intrstr = NULL;
> struct i2cbus_attach_args iba;
> + int numbusses, i;
>
> sc->sc_iot = pa->pa_iot;
> + numbusses = 1;
>
> if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB) ||
> + (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_KERNCZ_SMB) ||
> (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI &&
> PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SBX00_SMB &&
> PCI_REVISION(pa->pa_class) >= 0x40)) {
> @@ -136,10 +150,7 @@ piixpm_attach(struct device *parent, str
>* hidden. We need to look at the "SMBus0En" Power
>* Management register to find out where they live.
>* We use indirect IO access through the index/data
> - * pair at 0xcd6/0xcd7 to access "SMBus0En". Since
> - * the index/data pair may be needed by other drivers,
> - * we only map them for the duration that we actually
> - * need them.
> + * pair at 0xcd6/0xcd7 to access "SMBus0En".
>*/
I don't remember why we chose to immediately unmap the registers here.
So this may cause some breakage. Probably worth the risk.
> if (bus_space_map(sc->sc_iot, SB800_PMREG_BASE,
> SB800_PMREG_SIZE, 0, ) != 0) {
> @@ -147,29 +158,61 @@ piixpm_attach(struct device *parent, str
> return;
> }
>
> - /* Read "SmBus0En" */
> - bus_space_write_1(sc->sc_iot, ioh, 0, SB800_PMREG_SMB0EN);
> - smb0en = bus_space_read_1(sc->sc_iot, ioh, 1);
> - bus_space_write_1(sc->sc_iot, ioh, 0, SB800_PMREG_SMB0EN + 1);
> - smb0en |= (bus_space_read_1(sc->sc_iot, ioh, 1) << 8);
> -
> - bus_space_unmap(sc->sc_iot, ioh, SB800_PMREG_SIZE);
> + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> + (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB ||
> + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_KERNCZ_SMB)) {
> + bus_space_write_1(sc->sc_iot, ioh, 0,
> + AMDFCH41_PM_DECODE_EN);
> + val = bus_space_read_1(sc->sc_iot, ioh,
fix HW_IF_CONFIG register write in iwm(4)
I noticed that iwm(4) is overwriting the entire HW_IF_CONFIG register
with a hardcoded value, while Linux does a "read + clear some bits +
set some bits + write" operation instead (see iwl_mvm_nic_config() in
the Linux source file drivers/net/wireless/intel/iwlwifi/mvm/ops.c).
Our old code wrote 0xff0f, on my hardware this new code writes 0x18089000
like Linux does, though the exact value written will depend on what the
hardware returns when we read this register.
This register is documented as "hardware interface config". It's unclear
what all these bits are really doing but our current code is clearly wrong.
Please test for regressions.
diff 417cf047a3f739a26c23a52ee0780853d1afaa1e /usr/src
blob - dff9f8047f5c0300a4ddde4d9b090f58c28dd8f9
file + sys/dev/pci/if_iwm.c
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -1975,7 +1975,7 @@ void
iwm_nic_config(struct iwm_softc *sc)
{
uint8_t radio_cfg_type, radio_cfg_step, radio_cfg_dash;
- uint32_t reg_val = 0;
+ uint32_t mask, val, reg_val = 0;
radio_cfg_type = (sc->sc_fw_phy_config & IWM_FW_PHY_CFG_RADIO_TYPE) >>
IWM_FW_PHY_CFG_RADIO_TYPE_POS;
@@ -1994,15 +1994,18 @@ iwm_nic_config(struct iwm_softc *sc)
reg_val |= radio_cfg_step << IWM_CSR_HW_IF_CONFIG_REG_POS_PHY_STEP;
reg_val |= radio_cfg_dash << IWM_CSR_HW_IF_CONFIG_REG_POS_PHY_DASH;
- IWM_WRITE(sc, IWM_CSR_HW_IF_CONFIG_REG,
- IWM_CSR_HW_IF_CONFIG_REG_MSK_MAC_DASH |
+ mask = IWM_CSR_HW_IF_CONFIG_REG_MSK_MAC_DASH |
IWM_CSR_HW_IF_CONFIG_REG_MSK_MAC_STEP |
IWM_CSR_HW_IF_CONFIG_REG_MSK_PHY_STEP |
IWM_CSR_HW_IF_CONFIG_REG_MSK_PHY_DASH |
IWM_CSR_HW_IF_CONFIG_REG_MSK_PHY_TYPE |
IWM_CSR_HW_IF_CONFIG_REG_BIT_RADIO_SI |
- IWM_CSR_HW_IF_CONFIG_REG_BIT_MAC_SI |
- reg_val);
+ IWM_CSR_HW_IF_CONFIG_REG_BIT_MAC_SI;
+
+ val = IWM_READ(sc, IWM_CSR_HW_IF_CONFIG_REG);
+ val &= ~mask;
+ val |= reg_val;
+ IWM_WRITE(sc, IWM_CSR_HW_IF_CONFIG_REG, val);
/*
* W/A : NIC is stuck in a reset state after Early PCIe power off
Re: attention please: host's IP stack behavior got changed slightly
Hello, On Mon, Dec 16, 2019 at 03:21:43PM +0100, Claudio Jeker wrote: > On Mon, Dec 16, 2019 at 02:13:50PM +0100, Alexander Bluhm wrote: > > On Sun, Dec 15, 2019 at 03:17:26PM +0100, Alexandr Nedvedicky wrote: > > > Hello Daniel, > > > > > > thanks for reporting back. > > > > > > > > > > Should the rdr-to rule still work? I fixed it with using the "Port foo" > > > > directive in my sshd config (and a simple "pass in to port foo") in the > > > > meantime. > > > > > > My earlier indeed change omits your usecase. The rdr rule should still > > > work. Patch below should fix it. The idea is to check whether the > > > packet got NATed to loopback. We let packet in, if it got changed > > > by PF. > > > > > > The IPv6 part does not need similar fix. According to quick check > > > of existing code it works. > > > > > > OK ? > > > > Redirect to localhost is a violation of the strict host model. > > Why not encourage people to use divert-to for local delivery? > > I think this is a "do as I want" kind of thing. If I use pf(4) to redirect > traffic to a different address then I think our version of strict host > model should step back and accept the connection. > and also the change makes IPv4 behavior consistent with IPv6. so if we won't be committing diff for IPv4, then we should change IPv6 to enforce divert-to for IPv6 too. thanks and regards sashan
Re: ublink(4), led(4) and ledctl(1)
On Mon, Dec 16, 2019 at 01:57:41PM +, Stuart Henderson wrote: > On 2019/12/13 22:34, Patrick Wildt wrote: > > uhidev1 at uhub0 port 3 configuration 1 interface 0 "ThingM blink(1) mk2" > > rev 2.00/0.02 addr 2 > > uhidev1: iclass 3/0, 1 report id > > ublink0 at uhidev1 reportid 1 > > led0 at ublink0: 2 LEDs > > Does this attachment break the normal software used with these? > (in ports as misc/blink1) Of course it does! This means that you can use the device only with led(4), and that you can use all of the features provided by led(4), and nothing else. If you want to run it insecurely, with some external tool accessing your USB devices, you will *have to* explicitly disable the kernel driver.
Re: piixpm(4) add support for newer AMD chipsets
On Mon, Dec 16, 2019 at 03:19:30PM +0100, Claudio Jeker wrote: > On Mon, Dec 16, 2019 at 08:46:21AM -0500, Bryan Steele wrote: > > On Mon, Dec 16, 2019 at 12:37:51PM +0100, Claudio Jeker wrote: > > > This diff should add support for newer smbus controllers used on newer AMD > > > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the > > > iic(4) busses attach but there is nothing detected on them (well possible > > > that I missed something). I also implemented the up to 4 busses available > > > on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports). > > > > > > I would be interested if on systems with Ryzen CPUs something attaches to > > > those iic(4) busses. Could be that I missed something and fail to properly > > > access the bus. > > > -- > > > :wq Claudio > > > > I had a similar diff (except without the additional busses), and didn't > > go further as none of my machines show any devices either (not even > > spdmem(4)), I assumed it was on another bus.. but maybe it's on an > > entirely different controller now. > > > > bios0: vendor American Megatrends Inc. version "5220" date 09/11/2019 > > bios0: ASUSTeK COMPUTER INC. PRIME X470-PRO > > .. > > piixpm0 at pci0 dev 20 function 0 "AMD FCH SMBus" rev 0x59: polling > > iic0 at piixpm0 > > iic1 at piixpm0 > > > > Otherwise, diff "looks" ok. I'll try it on my MateBook later, but > > I have a feeling it was the same story. > > > > Otherwise, diff "looks" ok. > > > > spdmem(4) needs an update to support DDR4 to show up on the bus. I did not > realize that until after I sent this out. This is why spdmem(4) does not > attach. I'm working now on spdmem(4) support for DDR4. Oh interesting. I hadn't considered that. Look forward to testing that then! :-) > -- > :wq Claudio >
Re: attention please: host's IP stack behavior got changed slightly
On Mon, Dec 16, 2019 at 02:13:50PM +0100, Alexander Bluhm wrote: > On Sun, Dec 15, 2019 at 03:17:26PM +0100, Alexandr Nedvedicky wrote: > > Hello Daniel, > > > > thanks for reporting back. > > > > > > > Should the rdr-to rule still work? I fixed it with using the "Port foo" > > > directive in my sshd config (and a simple "pass in to port foo") in the > > > meantime. > > > > My earlier indeed change omits your usecase. The rdr rule should still > > work. Patch below should fix it. The idea is to check whether the > > packet got NATed to loopback. We let packet in, if it got changed > > by PF. > > > > The IPv6 part does not need similar fix. According to quick check > > of existing code it works. > > > > OK ? > > Redirect to localhost is a violation of the strict host model. > Why not encourage people to use divert-to for local delivery? I think this is a "do as I want" kind of thing. If I use pf(4) to redirect traffic to a different address then I think our version of strict host model should step back and accept the connection. > Daniel, is your sshd bound to a * or to a 127.0.0.1 socket? If it > is a * socket, does it work to redirect to the IP address of the > incoming interface? > -- :wq Claudio
Re: piixpm(4) add support for newer AMD chipsets
On Mon, Dec 16, 2019 at 08:46:21AM -0500, Bryan Steele wrote: > On Mon, Dec 16, 2019 at 12:37:51PM +0100, Claudio Jeker wrote: > > This diff should add support for newer smbus controllers used on newer AMD > > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the > > iic(4) busses attach but there is nothing detected on them (well possible > > that I missed something). I also implemented the up to 4 busses available > > on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports). > > > > I would be interested if on systems with Ryzen CPUs something attaches to > > those iic(4) busses. Could be that I missed something and fail to properly > > access the bus. > > -- > > :wq Claudio > > I had a similar diff (except without the additional busses), and didn't > go further as none of my machines show any devices either (not even > spdmem(4)), I assumed it was on another bus.. but maybe it's on an > entirely different controller now. > > bios0: vendor American Megatrends Inc. version "5220" date 09/11/2019 > bios0: ASUSTeK COMPUTER INC. PRIME X470-PRO > .. > piixpm0 at pci0 dev 20 function 0 "AMD FCH SMBus" rev 0x59: polling > iic0 at piixpm0 > iic1 at piixpm0 > > Otherwise, diff "looks" ok. I'll try it on my MateBook later, but > I have a feeling it was the same story. > > Otherwise, diff "looks" ok. > spdmem(4) needs an update to support DDR4 to show up on the bus. I did not realize that until after I sent this out. This is why spdmem(4) does not attach. I'm working now on spdmem(4) support for DDR4. -- :wq Claudio
Re: ublink(4), led(4) and ledctl(1)
On 2019/12/13 22:34, Patrick Wildt wrote: > uhidev1 at uhub0 port 3 configuration 1 interface 0 "ThingM blink(1) mk2" rev > 2.00/0.02 addr 2 > uhidev1: iclass 3/0, 1 report id > ublink0 at uhidev1 reportid 1 > led0 at ublink0: 2 LEDs Does this attachment break the normal software used with these? (in ports as misc/blink1)
Re: attention please: host's IP stack behavior got changed slightly
On 2019/12/16 13:44, Alexander Bluhm wrote: > On Sat, Dec 14, 2019 at 09:26:06PM -0500, Daniel Jakots wrote: > > My sshd doesn't listen on port 22 but I was too lazy to change it in my > > sshd config so I have a rule > > > > pass in [...] rdr-to 127.0.0.1 port ssh [...] > > A pf divert-to rule is better for this use case. Note that the divert destination will need to be the address the socket is bound to, i.e. usually "pass in [...] divert-to 0.0.0.0 port ssh [...]" for sshd.
Re: piixpm(4) add support for newer AMD chipsets
On Mon, Dec 16, 2019 at 12:37:51PM +0100, Claudio Jeker wrote:
> This diff should add support for newer smbus controllers used on newer AMD
> chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the
> iic(4) busses attach but there is nothing detected on them (well possible
> that I missed something). I also implemented the up to 4 busses available
> on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports).
>
> I would be interested if on systems with Ryzen CPUs something attaches to
> those iic(4) busses. Could be that I missed something and fail to properly
> access the bus.
> --
> :wq Claudio
I had a similar diff (except without the additional busses), and didn't
go further as none of my machines show any devices either (not even
spdmem(4)), I assumed it was on another bus.. but maybe it's on an
entirely different controller now.
bios0: vendor American Megatrends Inc. version "5220" date 09/11/2019
bios0: ASUSTeK COMPUTER INC. PRIME X470-PRO
..
piixpm0 at pci0 dev 20 function 0 "AMD FCH SMBus" rev 0x59: polling
iic0 at piixpm0
iic1 at piixpm0
Otherwise, diff "looks" ok. I'll try it on my MateBook later, but
I have a feeling it was the same story.
Otherwise, diff "looks" ok.
> Index: piixpm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/piixpm.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 piixpm.c
> --- piixpm.c 1 Oct 2013 20:06:02 - 1.39
> +++ piixpm.c 16 Dec 2019 11:26:11 -
> @@ -45,15 +45,24 @@
> #define PIIXPM_DELAY 200
> #define PIIXPM_TIMEOUT 1
>
> +struct piixpm_smbus {
> + int sb_bus;
> + struct piixpm_softc *sb_sc;
> +};
> +
> struct piixpm_softc {
> struct device sc_dev;
>
> bus_space_tag_t sc_iot;
> bus_space_handle_t sc_ioh;
> + bus_space_handle_t sc_sb800_ioh;
> void * sc_ih;
> int sc_poll;
> + int sc_is_sb800;
> + int sc_is_kerncz;
>
> - struct i2c_controller sc_i2c_tag;
> + struct piixpm_smbus sc_busses[4];
> + struct i2c_controller sc_i2c_tag[4];
> struct rwlock sc_i2c_lock;
> struct {
> i2c_op_t op;
> @@ -86,6 +95,7 @@ struct cfdriver piixpm_cd = {
>
> const struct pci_matchid piixpm_ids[] = {
> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SMB },
> + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_KERNCZ_SMB },
>
> { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB200_SMB },
> { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB300_SMB },
> @@ -117,17 +127,21 @@ piixpm_attach(struct device *parent, str
> struct piixpm_softc *sc = (struct piixpm_softc *)self;
> struct pci_attach_args *pa = aux;
> bus_space_handle_t ioh;
> - u_int16_t smb0en;
> + u_int16_t val, smb0en;
> bus_addr_t base;
> pcireg_t conf;
> pci_intr_handle_t ih;
> const char *intrstr = NULL;
> struct i2cbus_attach_args iba;
> + int numbusses, i;
>
> sc->sc_iot = pa->pa_iot;
> + numbusses = 1;
>
> if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB) ||
> + (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_KERNCZ_SMB) ||
> (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI &&
> PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SBX00_SMB &&
> PCI_REVISION(pa->pa_class) >= 0x40)) {
> @@ -136,10 +150,7 @@ piixpm_attach(struct device *parent, str
>* hidden. We need to look at the "SMBus0En" Power
>* Management register to find out where they live.
>* We use indirect IO access through the index/data
> - * pair at 0xcd6/0xcd7 to access "SMBus0En". Since
> - * the index/data pair may be needed by other drivers,
> - * we only map them for the duration that we actually
> - * need them.
> + * pair at 0xcd6/0xcd7 to access "SMBus0En".
>*/
> if (bus_space_map(sc->sc_iot, SB800_PMREG_BASE,
> SB800_PMREG_SIZE, 0, ) != 0) {
> @@ -147,29 +158,61 @@ piixpm_attach(struct device *parent, str
> return;
> }
>
> - /* Read "SmBus0En" */
> - bus_space_write_1(sc->sc_iot, ioh, 0, SB800_PMREG_SMB0EN);
> - smb0en = bus_space_read_1(sc->sc_iot, ioh, 1);
> - bus_space_write_1(sc->sc_iot, ioh, 0, SB800_PMREG_SMB0EN + 1);
> - smb0en |= (bus_space_read_1(sc->sc_iot, ioh, 1) << 8);
> -
> - bus_space_unmap(sc->sc_iot, ioh, SB800_PMREG_SIZE);
> + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> + (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB ||
> + PCI_PRODUCT(pa->pa_id) ==
Re: attention please: host's IP stack behavior got changed slightly
On Sun, Dec 15, 2019 at 03:17:26PM +0100, Alexandr Nedvedicky wrote:
> Hello Daniel,
>
> thanks for reporting back.
>
>
> > Should the rdr-to rule still work? I fixed it with using the "Port foo"
> > directive in my sshd config (and a simple "pass in to port foo") in the
> > meantime.
>
> My earlier indeed change omits your usecase. The rdr rule should still
> work. Patch below should fix it. The idea is to check whether the
> packet got NATed to loopback. We let packet in, if it got changed
> by PF.
>
> The IPv6 part does not need similar fix. According to quick check
> of existing code it works.
>
> OK ?
Redirect to localhost is a violation of the strict host model.
Why not encourage people to use divert-to for local delivery?
Daniel, is your sshd bound to a * or to a 127.0.0.1 socket? If it
is a * socket, does it work to redirect to the IP address of the
incoming interface?
bluhm
> 8<---8<---8<--8<
> diff --git a/sys/netinet/ip_input.c b/sys/netinet/ip_input.c
> index 058b2f038fa..f4114f45045 100644
> --- a/sys/netinet/ip_input.c
> +++ b/sys/netinet/ip_input.c
> @@ -753,7 +753,8 @@ in_ouraddr(struct mbuf *m, struct ifnet *ifp, struct
> rtentry **prt)
> }
> }
> } else if (ipforwarding == 0 && rt->rt_ifidx != ifp->if_index &&
> - !((ifp->if_flags & IFF_LOOPBACK) || (ifp->if_type == IFT_ENC))) {
> + !((ifp->if_flags & IFF_LOOPBACK) || (ifp->if_type == IFT_ENC) ||
> + (m->m_pkthdr.pf.flags & PF_TAG_TRANSLATE_LOCALHOST))) {
> /* received on wrong interface. */
> #if NCARP > 0
> struct ifnet *out_if;
Re: attention please: host's IP stack behavior got changed slightly
On Sat, Dec 14, 2019 at 09:26:06PM -0500, Daniel Jakots wrote: > My sshd doesn't listen on port 22 but I was too lazy to change it in my > sshd config so I have a rule > > pass in [...] rdr-to 127.0.0.1 port ssh [...] A pf divert-to rule is better for this use case. bluhm
piixpm(4) add support for newer AMD chipsets
This diff should add support for newer smbus controllers used on newer AMD
chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the
iic(4) busses attach but there is nothing detected on them (well possible
that I missed something). I also implemented the up to 4 busses available
on chipsets of the SBx00 series (on Hudson-2 and Kerncz only 2 ports).
I would be interested if on systems with Ryzen CPUs something attaches to
those iic(4) busses. Could be that I missed something and fail to properly
access the bus.
--
:wq Claudio
Index: piixpm.c
===
RCS file: /cvs/src/sys/dev/pci/piixpm.c,v
retrieving revision 1.39
diff -u -p -r1.39 piixpm.c
--- piixpm.c1 Oct 2013 20:06:02 - 1.39
+++ piixpm.c16 Dec 2019 11:26:11 -
@@ -45,15 +45,24 @@
#define PIIXPM_DELAY 200
#define PIIXPM_TIMEOUT 1
+struct piixpm_smbus {
+ int sb_bus;
+ struct piixpm_softc *sb_sc;
+};
+
struct piixpm_softc {
struct device sc_dev;
bus_space_tag_t sc_iot;
bus_space_handle_t sc_ioh;
+ bus_space_handle_t sc_sb800_ioh;
void * sc_ih;
int sc_poll;
+ int sc_is_sb800;
+ int sc_is_kerncz;
- struct i2c_controller sc_i2c_tag;
+ struct piixpm_smbus sc_busses[4];
+ struct i2c_controller sc_i2c_tag[4];
struct rwlock sc_i2c_lock;
struct {
i2c_op_t op;
@@ -86,6 +95,7 @@ struct cfdriver piixpm_cd = {
const struct pci_matchid piixpm_ids[] = {
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON2_SMB },
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_KERNCZ_SMB },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB200_SMB },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB300_SMB },
@@ -117,17 +127,21 @@ piixpm_attach(struct device *parent, str
struct piixpm_softc *sc = (struct piixpm_softc *)self;
struct pci_attach_args *pa = aux;
bus_space_handle_t ioh;
- u_int16_t smb0en;
+ u_int16_t val, smb0en;
bus_addr_t base;
pcireg_t conf;
pci_intr_handle_t ih;
const char *intrstr = NULL;
struct i2cbus_attach_args iba;
+ int numbusses, i;
sc->sc_iot = pa->pa_iot;
+ numbusses = 1;
if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB) ||
+ (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
+ PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_KERNCZ_SMB) ||
(PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI &&
PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SBX00_SMB &&
PCI_REVISION(pa->pa_class) >= 0x40)) {
@@ -136,10 +150,7 @@ piixpm_attach(struct device *parent, str
* hidden. We need to look at the "SMBus0En" Power
* Management register to find out where they live.
* We use indirect IO access through the index/data
-* pair at 0xcd6/0xcd7 to access "SMBus0En". Since
-* the index/data pair may be needed by other drivers,
-* we only map them for the duration that we actually
-* need them.
+* pair at 0xcd6/0xcd7 to access "SMBus0En".
*/
if (bus_space_map(sc->sc_iot, SB800_PMREG_BASE,
SB800_PMREG_SIZE, 0, ) != 0) {
@@ -147,29 +158,61 @@ piixpm_attach(struct device *parent, str
return;
}
- /* Read "SmBus0En" */
- bus_space_write_1(sc->sc_iot, ioh, 0, SB800_PMREG_SMB0EN);
- smb0en = bus_space_read_1(sc->sc_iot, ioh, 1);
- bus_space_write_1(sc->sc_iot, ioh, 0, SB800_PMREG_SMB0EN + 1);
- smb0en |= (bus_space_read_1(sc->sc_iot, ioh, 1) << 8);
-
- bus_space_unmap(sc->sc_iot, ioh, SB800_PMREG_SIZE);
+ if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
+ (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB ||
+ PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_KERNCZ_SMB)) {
+ bus_space_write_1(sc->sc_iot, ioh, 0,
+ AMDFCH41_PM_DECODE_EN);
+ val = bus_space_read_1(sc->sc_iot, ioh, 1);
+ smb0en = val & AMDFCH41_SMBUS_EN;
+
+ bus_space_write_1(sc->sc_iot, ioh, 0,
+ AMDFCH41_PM_DECODE_EN + 1);
+ val = bus_space_read_1(sc->sc_iot, ioh, 1) << 8;
+ base = val;
+ } else {
+ /* Read "SmBus0En" */
+ bus_space_write_1(sc->sc_iot, ioh, 0,
+ SB800_PMREG_SMB0EN);
+ val = bus_space_read_1(sc->sc_iot, ioh, 1);
+
Infinite sleeps in sys/kern
Convert the remaining ones to {m,t}sleep_nsec(9), ok?
Index: kern/kern_bufq.c
===
RCS file: /cvs/src/sys/kern/kern_bufq.c,v
retrieving revision 1.32
diff -u -p -r1.32 kern_bufq.c
--- kern/kern_bufq.c16 Aug 2017 17:52:17 - 1.32
+++ kern/kern_bufq.c16 Dec 2019 10:08:31 -
@@ -109,7 +109,7 @@ bufq_init(struct bufq *bq, int type)
mtx_enter(_mtx);
while (bufqs_stop) {
- msleep(_stop, _mtx, PRIBIO, "bqinit", 0);
+ msleep_nsec(_stop, _mtx, PRIBIO, "bqinit", INFSLP);
}
SLIST_INSERT_HEAD(, bq, bufq_entries);
mtx_leave(_mtx);
@@ -168,7 +168,7 @@ bufq_destroy(struct bufq *bq)
mtx_enter(_mtx);
while (bufqs_stop) {
- msleep(_stop, _mtx, PRIBIO, "bqdest", 0);
+ msleep_nsec(_stop, _mtx, PRIBIO, "bqdest", INFSLP);
}
SLIST_REMOVE(, bq, bufq, bufq_entries);
mtx_leave(_mtx);
@@ -180,7 +180,8 @@ bufq_queue(struct bufq *bq, struct buf *
{
mtx_enter(>bufq_mtx);
while (bq->bufq_stop) {
- msleep(>bufq_stop, >bufq_mtx, PRIBIO, "bqqueue", 0);
+ msleep_nsec(>bufq_stop, >bufq_mtx, PRIBIO, "bqqueue",
+ INFSLP);
}
bp->b_bq = bq;
@@ -244,8 +245,8 @@ bufq_wait(struct bufq *bq)
mtx_enter(>bufq_mtx);
while (bq->bufq_outstanding >= bq->bufq_hi) {
bq->bufq_waiting++;
- msleep(>bufq_waiting, >bufq_mtx,
- PRIBIO, "bqwait", 0);
+ msleep_nsec(>bufq_waiting, >bufq_mtx,
+ PRIBIO, "bqwait", INFSLP);
bq->bufq_waiting--;
}
mtx_leave(>bufq_mtx);
@@ -282,8 +283,8 @@ bufq_quiesce(void)
mtx_enter(>bufq_mtx);
bq->bufq_stop = 1;
while (bq->bufq_outstanding) {
- msleep(>bufq_outstanding, >bufq_mtx,
- PRIBIO, "bqquies", 0);
+ msleep_nsec(>bufq_outstanding, >bufq_mtx,
+ PRIBIO, "bqquies", INFSLP);
}
mtx_leave(>bufq_mtx);
}
Index: kern/kern_exit.c
===
RCS file: /cvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.181
diff -u -p -r1.181 kern_exit.c
--- kern/kern_exit.c11 Dec 2019 07:30:09 - 1.181
+++ kern/kern_exit.c16 Dec 2019 10:07:34 -
@@ -164,7 +164,7 @@ exit1(struct proc *p, int xexit, int xsi
if ((p->p_flag & P_THREAD) == 0) {
/* main thread gotta wait because it has the pid, et al */
while (pr->ps_refcnt > 1)
- tsleep(>ps_threads, PWAIT, "thrdeath", 0);
+ tsleep_nsec(>ps_threads, PWAIT, "thrdeath", INFSLP);
if (pr->ps_flags & PS_PROFIL)
stopprofclock(pr);
}
@@ -412,7 +412,8 @@ reaper(void *arg)
for (;;) {
mtx_enter(_mutex);
while ((p = LIST_FIRST()) == NULL)
- msleep(, _mutex, PVM, "reaper", 0);
+ msleep_nsec(, _mutex, PVM, "reaper",
+ INFSLP);
/* Remove us from the deadproc list. */
LIST_REMOVE(p, p_hash);
@@ -567,7 +568,7 @@ loop:
retval[0] = 0;
return (0);
}
- if ((error = tsleep(q->p_p, PWAIT | PCATCH, "wait", 0)) != 0)
+ if ((error = tsleep_nsec(q->p_p, PWAIT | PCATCH, "wait", INFSLP)) != 0)
return (error);
goto loop;
}
Index: kern/kern_fork.c
===
RCS file: /cvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.218
diff -u -p -r1.218 kern_fork.c
--- kern/kern_fork.c29 Nov 2019 21:32:04 - 1.218
+++ kern/kern_fork.c16 Dec 2019 10:08:43 -
@@ -491,7 +491,7 @@ fork1(struct proc *curp, int flags, void
*/
if (flags & FORK_PPWAIT)
while (curpr->ps_flags & PS_ISPWAIT)
- tsleep(curpr, PWAIT, "ppwait", 0);
+ tsleep_nsec(curpr, PWAIT, "ppwait", INFSLP);
/*
* If we're tracing the child, alert the parent too.
Index: kern/kern_malloc.c
===
RCS file: /cvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.140
diff -u -p -r1.140 kern_malloc.c
--- kern/kern_malloc.c 28 Nov 2019 16:23:11 - 1.140
+++ kern/kern_malloc.c 16 Dec 2019 10:08:55 -
@@ -218,7 +218,7 @@ malloc(size_t size, int type, int flags)
#endif
if (ksp->ks_limblocks < 65535)
ksp->ks_limblocks++;
- msleep(ksp, _mtx, PSWP+2, memname[type], 0);
+ msleep_nsec(ksp, _mtx,
Re: ospf6d: rework priority handling
On Sun, Dec 15, 2019 at 04:07:11PM +0100, Sebastian Benoit wrote:
> unrelated to this diff: I wonder if the manpage (of both ospfd and pspf6d)
> should mention that changing fib-priority with a reload is equivalent toa
> uncouple/couple?
>
If I understand correctly what you mean, I don't think they are equivalent.
un/couple is implied with reload but only reading conf file ("reload") will
change fib_prio value.
Re: bktr(4): tsleep(9) -> tsleep_nsec(9)
On Sun, Dec 15, 2019 at 10:28:32PM -0600, Scott Cheloha wrote: > I don't have any of these cards, but these are straightforward conversions. > > ok? > ok
