Re: sdmmc(4) support for suspend/resume with eMMC devices
> Do you know how other OSes handle this case? What kind of changes > would be required to handle this in OpenBSD? At which layer? USB > currently follows the same logic, so it could be solved there as > well with the same stone. No USB is much much harder. If I understand correctly the entire bus needs to be probed, all devices powered up freshly, and consider hubs also...
Re: sdmmc(4) support for suspend/resume with eMMC devices
There are two types of SD cards. Ones that go away, and ones that don't. > You could borrow bits of mpath(4), specifically the devid parts that > are used to identify whether a device is the same or not. However, > devids rely on a device providing unique identifiers, and we know that > this isn't reliable. In regards to either, I still really dislike the mpath model. It is difficult to actually push a device to detach, therefore there is no unwinding. For instance vnodes stay around. I've objected to this "keep it around" approach since the beginning. Always, the problem was identifying do we want it to detach or not, but the mpath model is "keep it around". > I'd go a bit further than using properties of a device and and try to > compare something on the disk that should be unique, eg, the duid from > the disklabel. But that requires an IO. And new IO's must not happen, because once a new IO is done other queued IO's from before suspend will flow through the code paths, perhaps say doing a write to the wrong SD card...
Re: sdmmc(4) support for suspend/resume with eMMC devices
On 12/11/18(Mon) 23:36, Ben Pye wrote: > On Mon, Nov 12, 2018 at 06:46:26PM -0200, Martin Pieuchot wrote: > > On 11/11/18(Sun) 13:10, Ben Pye wrote: > > > Hey all, > > > > > > In my quest for better OpenBSD support on my Chromebook 13 I have found > > > that sdmmc(4)'s current strategy for suspend/resume only really works > > > for removable storage. Upon a suspend it marks the device as dying, and > > > upon resume will detach the card and re-scan the bus. This makes sense > > > for removable SD cards as they may be removed whilst the device is > > > asleep, however for non-removable eMMC we can make the assumption that > > > the device will not be removed during sleep. > > > > > > By assuming the device stays present over a sleep we can avoid the > > > detach and re-scan behaviour that sdmmc(4) currently uses. This is > > > important if you root storage device is an eMMC device /and/ you are > > > using softraid(4) as softraid(4) will not handle the detach/attach. > > > Despite this on my hardware at least suspend/resume works more reliably > > > if we can avoid this detach behaviour too, on this device we would > > > really have to detach before we enter sleep as the bus can break during > > > suspend and then the detach/reattach fails after resume meaning that my > > > sd0 device just disappears. > > > > > > Instead for non-removable devices upon sleep we can deselect the card > > > but otherwise leave it configured. On resume we still perform a host > > > reset in sdhc(4) and then we can re-do the device initialisation in > > > sdmmc(4). During initialisation we use some of the values determined in > > > the initial sdmmc(4) init as the goal is to put the device into the same > > > state. We also hook up to the same sdmmc_function's etc so that the > > > child devices (scsibus etc) do not have to do anything special on a > > > resume. With this behaviour suspend/resume works reliably on my HP > > > Chromebook 13 and softraid for encryption continues to work. > > > > > > There are a few unresolved questions however and that's why I'm posting > > > this here now: > > > > > > 1. How do we know if a device is non-removable, I don't think an MMC > > > device indicates this, maybe we have to determine this by the > > > controller? > > > > If you find a way to know that would be interesting. However that > > doesn't mean we want to go this road. > > > > I'd rephrase the question differently. How do we know if a device, > > attached to a removable bus, has been removed or swapped while the > > machine was suspended? > > > > Do you know how other OSes handle this case? What kind of changes > > would be required to handle this in OpenBSD? At which layer? USB > > currently follows the same logic, so it could be solved there as > > well with the same stone. > > Good point. As far as I can tell Linux attempts to keep the device > initialised, removable card or not. They check the CID and if it has > changed I think they are detaching it - so for example, a removable > card. If you go down this road you need a way to ensure no IO will reach the medium until you've finished to check & validate the CID. Or is there any other way to do it? That is my question, what other OSes do? :) Did you look at USB as well? > Perhaps taking this approach would be better - if we could keep > removable devices attached if they haven't changed then it would be > possible to use them as your root device for example. That would be great but, as usual, somebody has to do the work :)
Re: sdmmc(4) support for suspend/resume with eMMC devices
> On 13 Nov 2018, at 9:36 am, Ben Pye wrote: > > On Mon, Nov 12, 2018 at 06:46:26PM -0200, Martin Pieuchot wrote: >> On 11/11/18(Sun) 13:10, Ben Pye wrote: >>> Hey all, >>> >>> In my quest for better OpenBSD support on my Chromebook 13 I have found >>> that sdmmc(4)'s current strategy for suspend/resume only really works >>> for removable storage. Upon a suspend it marks the device as dying, and >>> upon resume will detach the card and re-scan the bus. This makes sense >>> for removable SD cards as they may be removed whilst the device is >>> asleep, however for non-removable eMMC we can make the assumption that >>> the device will not be removed during sleep. >>> >>> By assuming the device stays present over a sleep we can avoid the >>> detach and re-scan behaviour that sdmmc(4) currently uses. This is >>> important if you root storage device is an eMMC device /and/ you are >>> using softraid(4) as softraid(4) will not handle the detach/attach. >>> Despite this on my hardware at least suspend/resume works more reliably >>> if we can avoid this detach behaviour too, on this device we would >>> really have to detach before we enter sleep as the bus can break during >>> suspend and then the detach/reattach fails after resume meaning that my >>> sd0 device just disappears. >>> >>> Instead for non-removable devices upon sleep we can deselect the card >>> but otherwise leave it configured. On resume we still perform a host >>> reset in sdhc(4) and then we can re-do the device initialisation in >>> sdmmc(4). During initialisation we use some of the values determined in >>> the initial sdmmc(4) init as the goal is to put the device into the same >>> state. We also hook up to the same sdmmc_function's etc so that the >>> child devices (scsibus etc) do not have to do anything special on a >>> resume. With this behaviour suspend/resume works reliably on my HP >>> Chromebook 13 and softraid for encryption continues to work. >>> >>> There are a few unresolved questions however and that's why I'm posting >>> this here now: >>> >>> 1. How do we know if a device is non-removable, I don't think an MMC >>> device indicates this, maybe we have to determine this by the >>> controller? >> >> If you find a way to know that would be interesting. However that >> doesn't mean we want to go this road. >> >> I'd rephrase the question differently. How do we know if a device, >> attached to a removable bus, has been removed or swapped while the >> machine was suspended? >> >> Do you know how other OSes handle this case? What kind of changes >> would be required to handle this in OpenBSD? At which layer? USB >> currently follows the same logic, so it could be solved there as >> well with the same stone. > > Good point. As far as I can tell Linux attempts to keep the device > initialised, removable card or not. They check the CID and if it has > changed I think they are detaching it - so for example, a removable > card. You could borrow bits of mpath(4), specifically the devid parts that are used to identify whether a device is the same or not. However, devids rely on a device providing unique identifiers, and we know that this isn't reliable. I'd go a bit further than using properties of a device and and try to compare something on the disk that should be unique, eg, the duid from the disklabel. > Perhaps taking this approach would be better - if we could keep > removable devices attached if they haven't changed then it would be > possible to use them as your root device for example. This would have a > greater impact though and might have a more potential for breaking > other devices. I'd argue that the problem of / going away is greater than the other problems that will come up. > >> >>> 2. There are some error cases in sdmmc_mem_scan that are unhandled. They >>> shouldn't ever be hit, if they were it would indicate that something to >>> do with our non-removable card has changed over a suspend/resume cycle. >> >> What should happen if such error occurs? > > I think just propagating the error up to sdmmc_activate should be > sufficient as I believe this should result in the device and it's > children being detached and freed. In fact if we wanted to take this > approach for removable devices then this is where I suppose we would > notice that the device has changed. > >> >>> 3. I appear to hit an issue with some commands failing after a suspend >>> if I don't add a small delay to sdhc_wait_intr_cold, I haven't yet been >>> able to work out why this is. Specifically, the second time we read >>> EXT_CSD in sdmmc_mem_mmc_init fails. >> >> That would be nice to investigate. Such workarounds are a good start, >> but not a nice solution. > > Understood. I just wanted to get it working for now so we could work out > when we should even be going down this code path.
Re: sdmmc(4) support for suspend/resume with eMMC devices
On Mon, Nov 12, 2018 at 06:46:26PM -0200, Martin Pieuchot wrote: > On 11/11/18(Sun) 13:10, Ben Pye wrote: > > Hey all, > > > > In my quest for better OpenBSD support on my Chromebook 13 I have found > > that sdmmc(4)'s current strategy for suspend/resume only really works > > for removable storage. Upon a suspend it marks the device as dying, and > > upon resume will detach the card and re-scan the bus. This makes sense > > for removable SD cards as they may be removed whilst the device is > > asleep, however for non-removable eMMC we can make the assumption that > > the device will not be removed during sleep. > > > > By assuming the device stays present over a sleep we can avoid the > > detach and re-scan behaviour that sdmmc(4) currently uses. This is > > important if you root storage device is an eMMC device /and/ you are > > using softraid(4) as softraid(4) will not handle the detach/attach. > > Despite this on my hardware at least suspend/resume works more reliably > > if we can avoid this detach behaviour too, on this device we would > > really have to detach before we enter sleep as the bus can break during > > suspend and then the detach/reattach fails after resume meaning that my > > sd0 device just disappears. > > > > Instead for non-removable devices upon sleep we can deselect the card > > but otherwise leave it configured. On resume we still perform a host > > reset in sdhc(4) and then we can re-do the device initialisation in > > sdmmc(4). During initialisation we use some of the values determined in > > the initial sdmmc(4) init as the goal is to put the device into the same > > state. We also hook up to the same sdmmc_function's etc so that the > > child devices (scsibus etc) do not have to do anything special on a > > resume. With this behaviour suspend/resume works reliably on my HP > > Chromebook 13 and softraid for encryption continues to work. > > > > There are a few unresolved questions however and that's why I'm posting > > this here now: > > > > 1. How do we know if a device is non-removable, I don't think an MMC > > device indicates this, maybe we have to determine this by the > > controller? > > If you find a way to know that would be interesting. However that > doesn't mean we want to go this road. > > I'd rephrase the question differently. How do we know if a device, > attached to a removable bus, has been removed or swapped while the > machine was suspended? > > Do you know how other OSes handle this case? What kind of changes > would be required to handle this in OpenBSD? At which layer? USB > currently follows the same logic, so it could be solved there as > well with the same stone. Good point. As far as I can tell Linux attempts to keep the device initialised, removable card or not. They check the CID and if it has changed I think they are detaching it - so for example, a removable card. Perhaps taking this approach would be better - if we could keep removable devices attached if they haven't changed then it would be possible to use them as your root device for example. This would have a greater impact though and might have a more potential for breaking other devices. > > > 2. There are some error cases in sdmmc_mem_scan that are unhandled. They > > shouldn't ever be hit, if they were it would indicate that something to > > do with our non-removable card has changed over a suspend/resume cycle. > > What should happen if such error occurs? I think just propagating the error up to sdmmc_activate should be sufficient as I believe this should result in the device and it's children being detached and freed. In fact if we wanted to take this approach for removable devices then this is where I suppose we would notice that the device has changed. > > > 3. I appear to hit an issue with some commands failing after a suspend > > if I don't add a small delay to sdhc_wait_intr_cold, I haven't yet been > > able to work out why this is. Specifically, the second time we read > > EXT_CSD in sdmmc_mem_mmc_init fails. > > That would be nice to investigate. Such workarounds are a good start, > but not a nice solution. Understood. I just wanted to get it working for now so we could work out when we should even be going down this code path.
Re: [PATCH] Add elan(4) touchpad driver
On Mon, Nov 12, 2018 at 06:50:27PM -0200, Martin Pieuchot wrote:
> On 09/11/18(Fri) 16:25, Ben Pye wrote:
> > On Thu, Nov 08, 2018 at 11:25:37PM -0600, joshua stein wrote:
> > > On Fri, 09 Nov 2018 at 03:30:07 +, b...@curlybracket.co.uk wrote:
> > > > Hi all,
> > > >
> > > > This patch adds a new touchpad driver, elan(4), which supports older non
> > > > PTP I2C Elantech touchpads. I have tested this on my HP Chromebook 13
> > > > and it appears to work well, multitouch is working as well as the three
> > > > physical mouse buttons. I do not know how well this will work on other
> > > > Elantech touchpads however; I believe there are a few devices that use
> > > > the same protocol though they may have different ACPI hids.
> > > >
> > > > This driver is similar to iatp(4) and is largely based upon it although
> > > > the actual protocol used by the touchpad is quite different.
> > > >
> > > > I have added a basic man page following iatp(4) as a guide. I wasn't
> > > > sure if I should add the copyright and OpenBSD headers and so for this
> > > > first patch I have omitted them.
> > > >
> > > > This together with my previous sdhc(4) patch results in a mostly working
> > > > OpenBSD install on the HP Chromebook 13, unfortunately apm(4) is still
> > > > problematic and the device gets stuck in sleep.
> > >
> > > Hi,
> > >
> > > Well done! The code looks mostly ok. There are a bunch of 8-space
> > > indentations instead of tabs that need to be fixed. You should
> > > include a comment header with your copyright and a license,
> > > preferably /usr/share/misc/license.template.
> >
> > I have updated both the man page and my code to include this as well as
> > fixing the identation and some trailing whitespace issues.
> >
> > > We have a habit of naming USB and i2c devices starting with 'u' and
> > > 'i', and since there is already a bunch of Elantech touchpad device
> > > support in pms(4), it would be best to rename this from 'elan' to
> > > something more narrow. Maybe ietp (since iatp is for i2c Atmel
> > > touchpads) or ielantp or something.
> >
> > I have renamed everything to ietp to mirror iatp(4).
> >
> > > As for the driver itself, is this implementing a specific protocol
> > > version for Elantech devices like the four in pms(4)? If this
> > > driver is limited to a specific protocol version or model, it would
> > > be beneficial to mention that in the driver code and man page.
> >
> > Unfortunately I can't find a specific list of devices using this
> > protocol however some searching indicates that there are certainly more
> > than just the "ELAN" device present on my laptop. I unfortunately do
> > not have any other hardware with an Elantech trackpad so I can't really
> > see if this will work on those devices though I believe it should.
> >
> > The updated patch is given below.
>
> Two questions below.
>
> > +int
> > +ietp_activate(struct device *self, int act)
> > +{
> > + struct ietp_softc *sc = (struct ietp_softc *)self;
> > +
> > + switch(act) {
> > + case DVACT_WAKEUP:
> > + sc->sc_busy = 1;
>
> What are you trying to serialize with this field? Can you describe the
> scenario that you're trying to avoid?
>
During init we reset and then write some configuration, I don't think
anything awful would happen if we didn't serialise this but we are more
likely to get reports we don't understand.
> > + ietp_init(sc);
> > + sc->sc_busy = 0;
> > + break;
> > + }
> > +
> > + config_activate_children(self, act);
> > +
> > + return 0;
> > +}
> > +
> > +
> > +void
> > +ietp_sleep(struct ietp_softc *sc, int ms)
> > +{
> > + int to = ms * hz / 1000;
>
> This function is never called, or it's me?
Not you, I based this driver on iatp(4) and the equivalent function is
needed there. I have removed it.
>
> > +
> > + if (cold)
> > + delay(ms * 1000);
> > + else {
> > + if (to <= 0)
> > + to = 1;
> > + tsleep(, PWAIT, "ietp", to);
> > + }
> > +}
> > +
I have updated this change set to remove the unused ietp_sleep function.
I have also added ietp_sleep (apologies, same name) to put the device
into a sleep state before we suspend. I don't really have any way to
confirm that this state is lower power but the device certainly does
still work on resume.
The updated diff is below.
Thanks,
Ben
Index: sys/dev/i2c/ietp.c
===
RCS file: sys/dev/i2c/ietp.c
diff -N sys/dev/i2c/ietp.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/dev/i2c/ietp.c 12 Nov 2018 21:32:04 -
@@ -0,0 +1,529 @@
+/*
+ * Elantech i2c touchpad driver
+ *
+ * Copyright (c) 2018 Ben Pye
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS
Re: prevent bgpd from starting when control socket already used
Stuart Henderson(s...@spacehopper.org) on 2018.11.11 21:55:19 +: > On 2018/11/11 22:45, Job Snijders wrote: > > Shouldnt we already bomb out at the following? > > > > cannot bind to 0.0.0.0:179: Address already in use > > cannot bind to [::]:179: Address already in use > > > > In any regard, I agree with the functionality proposed. No strong opinion > > on the diff itself. > > Should: probably, yes, but we don't at present. > > Last time I did this by mistake I ended up having to get onto the *peer* > via OOB, I can't remember if killing bgpd was enough, I have a feeling I > had to force a reboot.. I was the other one who happened to fat finger this recently (and suggest to remi to do this). I think i also rebootet the router as fast as i could, because i wanted to rid myself of more dropped packets.
Re: [PATCH] Add elan(4) touchpad driver
On 09/11/18(Fri) 16:25, Ben Pye wrote: > On Thu, Nov 08, 2018 at 11:25:37PM -0600, joshua stein wrote: > > On Fri, 09 Nov 2018 at 03:30:07 +, b...@curlybracket.co.uk wrote: > > > Hi all, > > > > > > This patch adds a new touchpad driver, elan(4), which supports older non > > > PTP I2C Elantech touchpads. I have tested this on my HP Chromebook 13 > > > and it appears to work well, multitouch is working as well as the three > > > physical mouse buttons. I do not know how well this will work on other > > > Elantech touchpads however; I believe there are a few devices that use > > > the same protocol though they may have different ACPI hids. > > > > > > This driver is similar to iatp(4) and is largely based upon it although > > > the actual protocol used by the touchpad is quite different. > > > > > > I have added a basic man page following iatp(4) as a guide. I wasn't > > > sure if I should add the copyright and OpenBSD headers and so for this > > > first patch I have omitted them. > > > > > > This together with my previous sdhc(4) patch results in a mostly working > > > OpenBSD install on the HP Chromebook 13, unfortunately apm(4) is still > > > problematic and the device gets stuck in sleep. > > > > Hi, > > > > Well done! The code looks mostly ok. There are a bunch of 8-space > > indentations instead of tabs that need to be fixed. You should > > include a comment header with your copyright and a license, > > preferably /usr/share/misc/license.template. > > I have updated both the man page and my code to include this as well as > fixing the identation and some trailing whitespace issues. > > > We have a habit of naming USB and i2c devices starting with 'u' and > > 'i', and since there is already a bunch of Elantech touchpad device > > support in pms(4), it would be best to rename this from 'elan' to > > something more narrow. Maybe ietp (since iatp is for i2c Atmel > > touchpads) or ielantp or something. > > I have renamed everything to ietp to mirror iatp(4). > > > As for the driver itself, is this implementing a specific protocol > > version for Elantech devices like the four in pms(4)? If this > > driver is limited to a specific protocol version or model, it would > > be beneficial to mention that in the driver code and man page. > > Unfortunately I can't find a specific list of devices using this > protocol however some searching indicates that there are certainly more > than just the "ELAN" device present on my laptop. I unfortunately do > not have any other hardware with an Elantech trackpad so I can't really > see if this will work on those devices though I believe it should. > > The updated patch is given below. Two questions below. > Index: sys/dev/i2c/ietp.c > === > RCS file: sys/dev/i2c/ietp.c > diff -N sys/dev/i2c/ietp.c > --- /dev/null 1 Jan 1970 00:00:00 - > +++ sys/dev/i2c/ietp.c9 Nov 2018 16:12:32 - > @@ -0,0 +1,529 @@ > +/* > + * Elantech i2c touchpad driver > + * > + * Copyright (c) 2018 Ben Pye > + * > + * Permission to use, copy, modify, and distribute this software for any > + * purpose with or without fee is hereby granted, provided that the above > + * copyright notice and this permission notice appear in all copies. > + * > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#include > +#include > +#include > +#include > + > +/* #define IETP_DEBUG */ > + > +#ifdef IETP_DEBUG > +#define DPRINTF(x) printf x > +#else > +#define DPRINTF(x) > +#endif > + > +#define IETP_INPUT 0x0003 > +#define IETP_MAX_X_AXIS 0x0106 > +#define IETP_MAX_Y_AXIS 0x0107 > +#define IETP_RESOLUTION 0x0108 > + > +#define IETP_COMMAND 0x0005 > +#define IETP_CONTROL 0x0300 > + > +#define IETP_CMD_WAKEUP 0x0800 > +#define IETP_CMD_SLEEP 0x0801 > +#define IETP_CMD_RESET 0x0100 > + > +#define IETP_CTRL_ABSOLUTE 0x0001 > +#define IETP_CTRL_STANDARD 0x > + > +#define IETP_MAX_REPORT_LEN 34 > +#define IETP_MAX_FINGERS 5 > + > +#define IETP_REPORT_ABSOLUTE 0x5D > + > +#define IETP_REPORT_ID 2 > +#define IETP_TOUCH_INFO 3 > +#define IETP_FINGER_DATA 4 > + > +#define IETP_TOUCH_LMB (1 << 0) > +#define IETP_TOUCH_RMB (1 << 1) > +#define IETP_TOUCH_MMB
Re: sdmmc(4) support for suspend/resume with eMMC devices
On 11/11/18(Sun) 13:10, Ben Pye wrote: > Hey all, > > In my quest for better OpenBSD support on my Chromebook 13 I have found > that sdmmc(4)'s current strategy for suspend/resume only really works > for removable storage. Upon a suspend it marks the device as dying, and > upon resume will detach the card and re-scan the bus. This makes sense > for removable SD cards as they may be removed whilst the device is > asleep, however for non-removable eMMC we can make the assumption that > the device will not be removed during sleep. > > By assuming the device stays present over a sleep we can avoid the > detach and re-scan behaviour that sdmmc(4) currently uses. This is > important if you root storage device is an eMMC device /and/ you are > using softraid(4) as softraid(4) will not handle the detach/attach. > Despite this on my hardware at least suspend/resume works more reliably > if we can avoid this detach behaviour too, on this device we would > really have to detach before we enter sleep as the bus can break during > suspend and then the detach/reattach fails after resume meaning that my > sd0 device just disappears. > > Instead for non-removable devices upon sleep we can deselect the card > but otherwise leave it configured. On resume we still perform a host > reset in sdhc(4) and then we can re-do the device initialisation in > sdmmc(4). During initialisation we use some of the values determined in > the initial sdmmc(4) init as the goal is to put the device into the same > state. We also hook up to the same sdmmc_function's etc so that the > child devices (scsibus etc) do not have to do anything special on a > resume. With this behaviour suspend/resume works reliably on my HP > Chromebook 13 and softraid for encryption continues to work. > > There are a few unresolved questions however and that's why I'm posting > this here now: > > 1. How do we know if a device is non-removable, I don't think an MMC > device indicates this, maybe we have to determine this by the > controller? If you find a way to know that would be interesting. However that doesn't mean we want to go this road. I'd rephrase the question differently. How do we know if a device, attached to a removable bus, has been removed or swapped while the machine was suspended? Do you know how other OSes handle this case? What kind of changes would be required to handle this in OpenBSD? At which layer? USB currently follows the same logic, so it could be solved there as well with the same stone. > 2. There are some error cases in sdmmc_mem_scan that are unhandled. They > shouldn't ever be hit, if they were it would indicate that something to > do with our non-removable card has changed over a suspend/resume cycle. What should happen if such error occurs? > 3. I appear to hit an issue with some commands failing after a suspend > if I don't add a small delay to sdhc_wait_intr_cold, I haven't yet been > able to work out why this is. Specifically, the second time we read > EXT_CSD in sdmmc_mem_mmc_init fails. That would be nice to investigate. Such workarounds are a good start, but not a nice solution.
Re: Sync calendars.judaic with reality
On Mon, 2018-11-12 at 15:01 -0500, Brian Callahan wrote: > > On 11/12/18 1:13 PM, John Long wrote: > > On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote: > > > On 11/12/18 11:20 AM, John Long wrote: > > > > On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote: > > > > > On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan > > > > > wrote: > > > > > > Hi tech -- > > > > > > > > > > > > Reminded by the recent email to tech@ about > > > > > > calendar.christian, I > > > > > > took a look at syncing calendar.judaic. > > > > > > > > > > > > This diff does the following: > > > > > > 1. Sync the holiday days that are not connected to Pesach, > > > > > > which > > > > > > on > > > > > > our calendar is Chanukah, Fast of 10 Tevet, and Yom > > > > > > Yerushalayim. > > > > > > > > I am not sure what this means. All of the Jewish holidays move > > > > on > > > > the > > > > civil calendar year to year. However, since every time the > > > > calendar > > > > includes an additional month (a second Adar) the month is > > > > inserted > > > > before Pesach; therefore the holidays which fall after that > > > > time > > > > do > > > > not move *relative to Pesach* but they do move on the civil > > > > calendar. > > > > > > What are you talking about? This is in reference to the code in > > > calendar(1) that sets the dates for the Judaic calendar. If you > > > think > > > there's something wrong there, I await your patch to > > > usr.bin/calendar/pesach.c > > > > > > > I haven't seen the code. I responded to the comment that "days are > > not > > connected to Pesach." All Jewish holidays are connected to Pesach, > > it > > is one of the points from which years are calculated. And my > > statement > > above and the explanation how it works is correct as I wrote it. > > > > So what are you talking about? Exactly what did I write that you > > are > > disputing here? > > If you haven't read pesach.c or the calendar.judaic code, then you > can't > be helped because it is obvious from a quick glance at the code > that > some of the dates on calendar.judaic are listed as Westernized > dates > (aka the ones my diff changes) and others are dates in the form of > Pesach+/-n. I looked at it and there is no revelation there, the code is just an implementation of Gauss's Pesach algorithm, as it says. From that, with an understanding of how the years are laid out along with some basic math and in some cases specific rules for various fasts that can't fall on Shabbes, etc. it's possible to write code that works forever i.e. does not need to be changed every year. You said the calendar has to be changed every year and is based on western [civil] dates, so it's clear whoever is maintaing it doesn't understand our calendar. > I'll be moving forward with the oks I have and without your > opinion on everything else below because you can go be a shanda > somewhere else and not on this list, as this list is no place for > your > nonsense diatribe as to what counts as Judaism or not. I'm qualified to correct issues with the transliterations and I pointed out several inconsistencies earlier, and also to differentiate between Jewish and civil holidays. When you translate these holidays into English and if you want to include both major communities (Ashkenaz and Sephard) you will have to have two sets of transliterations. There is a third significant community (Yemenite) but an English transliteration according to the Sephardi community would be acceptable to them. We use our calendar daily. In addition to info about when holidays occur, we also have to know how the various times work out each day of the year for religious observances during the day. So any useful Jewish calendar necessarily includes things like astronomical sunrise/sunset by geographic location and based on legal rulings over history in each place where there was a Jewish community. We also need to know about other times of the day derived from the length of the daylight period as the days get longer and shorter. We have many obligations and prohibitions based on the day of the year and time of day. So we have a vital interest in understanding the calendar as it was calculated and ratified thousands of years ago and it is in use until now because to us it is actually relevant in our lives day by day, hour by hour. If you would like to see an example of what a Jewish calendar looks like I can send you a couple of snapshots of the one I use. It is really excellent and has a section explaining the various legal opinions as well as providing the times based on those calculations. /jl
Re: Sync calendars.judaic with reality
On 11/12/18 1:13 PM, John Long wrote: On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote: On 11/12/18 11:20 AM, John Long wrote: On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote: On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote: Hi tech -- Reminded by the recent email to tech@ about calendar.christian, I took a look at syncing calendar.judaic. This diff does the following: 1. Sync the holiday days that are not connected to Pesach, which on our calendar is Chanukah, Fast of 10 Tevet, and Yom Yerushalayim. I am not sure what this means. All of the Jewish holidays move on the civil calendar year to year. However, since every time the calendar includes an additional month (a second Adar) the month is inserted before Pesach; therefore the holidays which fall after that time do not move *relative to Pesach* but they do move on the civil calendar. What are you talking about? This is in reference to the code in calendar(1) that sets the dates for the Judaic calendar. If you think there's something wrong there, I await your patch to usr.bin/calendar/pesach.c I haven't seen the code. I responded to the comment that "days are not connected to Pesach." All Jewish holidays are connected to Pesach, it is one of the points from which years are calculated. And my statement above and the explanation how it works is correct as I wrote it. So what are you talking about? Exactly what did I write that you are disputing here? If you haven't read pesach.c or the calendar.judaic code, then you can't be helped because it is obvious from a quick glance at the code that some of the dates on calendar.judaic are listed as Westernized dates (aka the ones my diff changes) and others are dates in the form of Pesach+/-n. I'll be moving forward with the oks I have and without your opinion on everything else below because you can go be a shanda somewhere else and not on this list, as this list is no place for your nonsense diatribe as to what counts as Judaism or not. ~Brian Yes, I know how the Hebrew calendar works. mickey@'s calculation is actually quite nice IMO. 2. Add the holidays that are explicitly mentioned on the Wikipedia page of Jewish holidays, which adds Tu B'Shevat to our calendar. 3. Replace the year marker on Rosh Hashana with the current Jewish year (5741 => 5779). This calendar has to be updated yearly as it is anyway, so it seems odd to me not to put the current year if we're going to list a year in connection with Rosh Hashanah. It looks like mickey@ removed Yom HaAtzmaut some years ago due to the understanding that this be a religious and not secular calendar. Which is a perfectly legitimate stance, as there is no universal yes or no as to whether or not the Israeli rememberance holidays are religious holidays, both in Israel and in the dispora. There is. Yom Hatzmaut, Yom HaShoah, Yom Hazikaron, Yom Yerushalayim are all Israeli (civil) holidays not connected to the Jewish religion. Reform Judaism and Conservative Judaism (in the US, at least) both treat Yom HaShoah as a religious holiday, with both crafting prayers specifically for the holiday and with Conservative Judaism writing a new liturgy for the day. If the calendar we are talking about is supposed to be representative of mainstream Jewish belief and practice which has remained the same for the past 3,500 years then those demominations will need their own calendars. This is considered so "common knowledge" that Wikipedia has a whole section on it: https://en.wikipedia.org/wiki/Yom_HaShoah#Religious_observances_and_liturgy This is no proof of anything except activism which isn't representative of the Jewish religion. Additionally, there is no reason that calendar.judaic cannot be both a religious and secular calendar. mickey@ clearly had reasons for preferring to it to be religious only but I can't go ask him his reasoning for it. So my question is whether or not people prefer one over the other. I slightly prefer it to be both religious and secular but I care more about the dates being maintained so am willing to go either way. I have no preference either, since I don't use it, rather I use calendars from reliable sources and I have also written my own which aligns with those. Again, I was responding to what Jason wrote. Regardless, some of the holidays mentioned are Jewish, some are Israeli. There is no overlap. So we either need to remove Yom Yerushalayim for the same reason, or add back Yom HaAtzmaut, and add Yom HaShoah and Yom Hazikaron. Doesn't matter to me either way. It might be nice to include Yom HaShoah in either event, as it is likely to become a universal Jewish religious holiday within our lifetimes. That is absolutely not true. No major religious authority has ever recognized any of the Israeli civil holidays. This again is so not true that Wikipedia has a section on it: https://en.wikipedia.org/wiki/Yom_HaShoah#Religious_observances_and_liturgy There is no major
Re: ksh: fc -s and SIGINT
> Even if this looks more like an ad-hoc solution, I find it easier to > grasp and review than the trap-based diff. Works fine here and seems to > solve miod's problem. > > ok jca@ I concur. I'm slightly annoyed by the asymmetry between c_fc_depth++ vs c_fc_reset(), but I think we've had enough bikeshedding on this patch. Put it in. ok
Re: ksh: fc -s and SIGINT
On Mon, Nov 12 2018, Martijn van Duren wrote:
> On 10/29/18 12:01 PM, Anton Lindqvist wrote:
>> On Mon, Oct 29, 2018 at 09:55:38AM +0100, Martijn van Duren wrote:
>>> On 10/28/18 8:13 PM, Anton Lindqvist wrote:
Hi,
Bug reported by miod@, how to reproduce:
$ command -v r
alias r='fc -s'
$ sleep 5
$ r sleep
^C # abort sleep before finishing
$ r sleep
ksh: fc: history function called recursively
The c_fc() function has some internal state used to prevent recursive
invocations that gets out of sync when the re-executed command is
aborted by SIGINT. My proposal is to temporarily register a SIGINT
handler before re-executing the command in order to reset the call depth
counter upon signal delivery.
Comments? OK?
>>> You diff always unsets the shtrap pointer, which most likely unsets
>>> custom SIGINT handlers installed by the user (untested). Next to that
>>> this feels like special-casing and I'm afraid that there are some cases
>>> we might be overlooking here.
>>
>> Thanks for the feedback. A few drive by thoughts, will look more closely
>> this evening: a user supplied SIGINT handler is never registered as a
>> one shot handler so it should never be overwritten. The hist_sigint()
>> one shot handler is registered before executing the command, if the
>> command does register a SIGINT handler it takes higher precedence and
>> hist_execute() will return under such circumstances implying that
>> fc_depth will be correctly decremented. The one shot handler is only
>> used when the command does not register a SIGINT handler.
>>
>>>
>>> The source with this issue is that a SIGINT triggers a list of
>>> siglongjmps, which don't allow us to return to c_fc and decrement the
>>> pointer. The diff below detects if we're on the lowest level of the
>>> unwinding by abusing the interactive variable. This works because
>>> calling fc from a non-interactive session is prohibited.
>>>
>>> I'm not 100% convinced that the placement of fc_depth = 0 should be
>>> placed in shell(), or that we maybe should place it in unwind(). The
>>> reason I choose for shell() is because interactive is guaranteed to
>>> be setup for checking, because it's already there.
>>>
>>> This diff is only lightly tested and the code here is very hard to
>>> untangle, so extreme scrutiny is desirable.
>>>
>>> martijn@
>>>
> After some back and forth with anton@ we came up with the following
> diff. I would like to have some extra scrutiny on this one before
> actually committing this.
Even if this looks more like an ad-hoc solution, I find it easier to
grasp and review than the trap-based diff. Works fine here and seems to
solve miod's problem.
ok jca@
> martijn@
>
> Index: history.c
> ===
> RCS file: /cvs/src/bin/ksh/history.c,v
> retrieving revision 1.80
> diff -u -p -r1.80 history.c
> --- history.c 15 Jan 2018 22:30:38 - 1.80
> +++ history.c 12 Nov 2018 15:46:35 -
> @@ -48,6 +48,8 @@ static uint32_t line_co;
>
> static struct stat last_sb;
>
> +static volatile sig_atomic_t c_fc_depth;
> +
> int
> c_fc(char **wp)
> {
> @@ -58,9 +60,8 @@ c_fc(char **wp)
> int optc, ret;
> char *first = NULL, *last = NULL;
> char **hfirst, **hlast, **hp;
> - static int depth;
>
> - if (depth != 0) {
> + if (c_fc_depth != 0) {
> bi_errorf("history function called recursively");
> return 1;
> }
> @@ -146,9 +147,9 @@ c_fc(char **wp)
> hist_get_newest(false);
> if (!hp)
> return 1;
> - depth++;
> + c_fc_depth++;
> ret = hist_replace(hp, pat, rep, gflag);
> - depth--;
> + c_fc_reset();
> return ret;
> }
>
> @@ -268,11 +269,20 @@ c_fc(char **wp)
> shf_close(shf);
> *xp = '\0';
> strip_nuls(Xstring(xs, xp), Xlength(xs, xp));
> - depth++;
> + c_fc_depth++;
> ret = hist_execute(Xstring(xs, xp));
> - depth--;
> + c_fc_reset();
> return ret;
> }
> +}
> +
> +/* Reset the c_fc depth counter.
> + * Made available for when an fc call is interrupted.
> + */
> +void
> +c_fc_reset(void)
> +{
> + c_fc_depth = 0;
> }
>
> /* Save cmd in history, execute cmd (cmd gets trashed) */
> Index: main.c
> ===
> RCS file: /cvs/src/bin/ksh/main.c,v
> retrieving revision 1.93
> diff -u -p -r1.93 main.c
> --- main.c29 Sep 2018 14:13:19 - 1.93
> +++ main.c12 Nov 2018 15:46:35 -
> @@ -549,6 +549,7 @@ shell(Source *volatile s, volatile int t
> case LERROR:
> case LSHELL:
> if (interactive) {
> + c_fc_reset();
>
Re: Sync calendars.judaic with reality
On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote: > > On 11/12/18 11:20 AM, John Long wrote: > > On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote: > > > On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote: > > > > Hi tech -- > > > > > > > > Reminded by the recent email to tech@ about > > > > calendar.christian, I > > > > took a look at syncing calendar.judaic. > > > > > > > > This diff does the following: > > > > 1. Sync the holiday days that are not connected to Pesach, > > > > which > > > > on > > > > our calendar is Chanukah, Fast of 10 Tevet, and Yom > > > > Yerushalayim. > > > > I am not sure what this means. All of the Jewish holidays move on > > the > > civil calendar year to year. However, since every time the > > calendar > > includes an additional month (a second Adar) the month is inserted > > before Pesach; therefore the holidays which fall after that time > > do > > not move *relative to Pesach* but they do move on the civil > > calendar. > > What are you talking about? This is in reference to the code in > calendar(1) that sets the dates for the Judaic calendar. If you > think > there's something wrong there, I await your patch to > usr.bin/calendar/pesach.c > I haven't seen the code. I responded to the comment that "days are not connected to Pesach." All Jewish holidays are connected to Pesach, it is one of the points from which years are calculated. And my statement above and the explanation how it works is correct as I wrote it. So what are you talking about? Exactly what did I write that you are disputing here? > Yes, I know how the Hebrew calendar works. mickey@'s calculation is > actually quite nice IMO. > > > > 2. Add the holidays that are explicitly mentioned on the > > > > Wikipedia > > > > page of Jewish holidays, which adds Tu B'Shevat to our > > > > calendar. > > > > 3. Replace the year marker on Rosh Hashana with the current > > > > Jewish > > > > year (5741 => 5779). This calendar has to be updated yearly as > > > > it > > > > is anyway, so it seems odd to me not to put the current year > > > > if > > > > we're going to list a year in connection with Rosh Hashanah. > > > > > > > > It looks like mickey@ removed Yom HaAtzmaut some years ago due > > > > to > > > > the understanding that this be a religious and not secular > > > > calendar. Which is a perfectly legitimate stance, as there is > > > > no > > > > universal yes or no as to whether or not the Israeli > > > > rememberance > > > > holidays are religious holidays, both in Israel and in the > > > > dispora. > > > > There is. Yom Hatzmaut, Yom HaShoah, Yom Hazikaron, Yom > > Yerushalayim > > are all Israeli (civil) holidays not connected to the Jewish > > religion. > > > > Reform Judaism and Conservative Judaism (in the US, at least) both > treat > Yom HaShoah as a religious holiday, with both crafting prayers > specifically for the holiday and with Conservative Judaism writing a > new > liturgy for the day. If the calendar we are talking about is supposed to be representative of mainstream Jewish belief and practice which has remained the same for the past 3,500 years then those demominations will need their own calendars. > > This is considered so "common knowledge" that Wikipedia has a whole > section on it: > https://en.wikipedia.org/wiki/Yom_HaShoah#Religious_observances_and_liturgy This is no proof of anything except activism which isn't representative of the Jewish religion. > > Additionally, there is no reason that calendar.judaic cannot be both > a > religious and secular calendar. mickey@ clearly had reasons for > preferring to it to be religious only but I can't go ask him his > reasoning for it. So my question is whether or not people prefer > one > over the other. I slightly prefer it to be both religious and > secular > but I care more about the dates being maintained so am willing to > go > either way. I have no preference either, since I don't use it, rather I use calendars from reliable sources and I have also written my own which aligns with those. Again, I was responding to what Jason wrote. Regardless, some of the holidays mentioned are Jewish, some are Israeli. There is no overlap. > > > > > So we either need to remove Yom Yerushalayim for the same > > > > reason, > > > > or add back Yom HaAtzmaut, and add Yom HaShoah and Yom > > > > Hazikaron. > > > > Doesn't matter to me either way. It might be nice to include > > > > Yom > > > > HaShoah in either event, as it is likely to become a universal > > > > Jewish religious holiday within our lifetimes. > > > > That is absolutely not true. No major religious authority has ever > > recognized any of the Israeli civil holidays. > > > > This again is so not true that Wikipedia has a section on it: > https://en.wikipedia.org/wiki/Yom_HaShoah#Religious_observances_and_liturgy There is no major religious authority that has recognized any Israeli holidays. And all the nonsense you find online or
Re: Sync calendars.judaic with reality
On 11/12/18 11:20 AM, John Long wrote: On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote: On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote: Hi tech -- Reminded by the recent email to tech@ about calendar.christian, I took a look at syncing calendar.judaic. This diff does the following: 1. Sync the holiday days that are not connected to Pesach, which on our calendar is Chanukah, Fast of 10 Tevet, and Yom Yerushalayim. I am not sure what this means. All of the Jewish holidays move on the civil calendar year to year. However, since every time the calendar includes an additional month (a second Adar) the month is inserted before Pesach; therefore the holidays which fall after that time do not move *relative to Pesach* but they do move on the civil calendar. What are you talking about? This is in reference to the code in calendar(1) that sets the dates for the Judaic calendar. If you think there's something wrong there, I await your patch to usr.bin/calendar/pesach.c Yes, I know how the Hebrew calendar works. mickey@'s calculation is actually quite nice IMO. 2. Add the holidays that are explicitly mentioned on the Wikipedia page of Jewish holidays, which adds Tu B'Shevat to our calendar. 3. Replace the year marker on Rosh Hashana with the current Jewish year (5741 => 5779). This calendar has to be updated yearly as it is anyway, so it seems odd to me not to put the current year if we're going to list a year in connection with Rosh Hashanah. It looks like mickey@ removed Yom HaAtzmaut some years ago due to the understanding that this be a religious and not secular calendar. Which is a perfectly legitimate stance, as there is no universal yes or no as to whether or not the Israeli rememberance holidays are religious holidays, both in Israel and in the dispora. There is. Yom Hatzmaut, Yom HaShoah, Yom Hazikaron, Yom Yerushalayim are all Israeli (civil) holidays not connected to the Jewish religion. Reform Judaism and Conservative Judaism (in the US, at least) both treat Yom HaShoah as a religious holiday, with both crafting prayers specifically for the holiday and with Conservative Judaism writing a new liturgy for the day. This is considered so "common knowledge" that Wikipedia has a whole section on it: https://en.wikipedia.org/wiki/Yom_HaShoah#Religious_observances_and_liturgy Additionally, there is no reason that calendar.judaic cannot be both a religious and secular calendar. mickey@ clearly had reasons for preferring to it to be religious only but I can't go ask him his reasoning for it. So my question is whether or not people prefer one over the other. I slightly prefer it to be both religious and secular but I care more about the dates being maintained so am willing to go either way. So we either need to remove Yom Yerushalayim for the same reason, or add back Yom HaAtzmaut, and add Yom HaShoah and Yom Hazikaron. Doesn't matter to me either way. It might be nice to include Yom HaShoah in either event, as it is likely to become a universal Jewish religious holiday within our lifetimes. That is absolutely not true. No major religious authority has ever recognized any of the Israeli civil holidays. This again is so not true that Wikipedia has a section on it: https://en.wikipedia.org/wiki/Yom_HaShoah#Religious_observances_and_liturgy But again, we can make the calendar religious and secular. You may disagree with the Reform and Conservative movement, but both are major religious authorities and normative Judaism. Whatever is decided having Yom Yerushalayim by itself is the strangest of all worlds. And I'll volunteer to keep this calendar synced since I might be the only one who cares about it. OK? ~Brian morning. if you're willing to do the work, i say go for it. i don;t have enough knowledge about dates/holidays to provide any useful feedback. if you have any opinion on the .christian diff, please do reply. i'm about to as well, but again i just don;t have the knowledge to deal with this. I can help with this. Contact me offline with any questions. In the diff below I see some conflicts in terms of transliteration. There are two main communities of Jews and the transliterations below do not align with either one in all cases. Honestly, the transliterations are fine. I'll write them all in Yiddish though if you have concerns. ~Brian /jl jmc Index: calendar.judaic == = RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.judaic,v retrieving revision 1.5 diff -u -p -r1.5 calendar.judaic --- calendar.judaic 6 Sep 2005 23:42:59 - 1.5 +++ calendar.judaic 12 Nov 2018 00:11:04 - @@ -7,7 +7,7 @@ #ifndef _calendar_judaic_ #define _calendar_judaic_ -Pesach+163 First Day of Rosh Hashanah (Jewish Lunar New Year; 5741 == 1980; +Pesach+163 First Day of Rosh Hashanah (Jewish Lunar New Year; 5779 == 2018; sabbatical)
Re: 6.4 - RX not working on new supported BCM574xx (bnxt)
Hello there, Sorry I haven't access to my server until today. Please find the requested output here : https://pastebin.com/V5ayBfyS (dmesg, ifconfig bnxt, vmstat -zi) I modified mac addresses on my different outputs, the mac addresses are normal. Cheers Luthing -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html
Re: Sync calendars.judaic with reality
On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote: > On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote: > > Hi tech -- > > > > Reminded by the recent email to tech@ about calendar.christian, I > > took a look at syncing calendar.judaic. > > > > This diff does the following: > > 1. Sync the holiday days that are not connected to Pesach, which > > on > > our calendar is Chanukah, Fast of 10 Tevet, and Yom Yerushalayim. I am not sure what this means. All of the Jewish holidays move on the civil calendar year to year. However, since every time the calendar includes an additional month (a second Adar) the month is inserted before Pesach; therefore the holidays which fall after that time do not move *relative to Pesach* but they do move on the civil calendar. > > 2. Add the holidays that are explicitly mentioned on the Wikipedia > > page of Jewish holidays, which adds Tu B'Shevat to our calendar. > > 3. Replace the year marker on Rosh Hashana with the current Jewish > > year (5741 => 5779). This calendar has to be updated yearly as it > > is anyway, so it seems odd to me not to put the current year if > > we're going to list a year in connection with Rosh Hashanah. > > > > It looks like mickey@ removed Yom HaAtzmaut some years ago due to > > the understanding that this be a religious and not secular > > calendar. Which is a perfectly legitimate stance, as there is no > > universal yes or no as to whether or not the Israeli rememberance > > holidays are religious holidays, both in Israel and in the > > dispora. There is. Yom Hatzmaut, Yom HaShoah, Yom Hazikaron, Yom Yerushalayim are all Israeli (civil) holidays not connected to the Jewish religion. > > So we either need to remove Yom Yerushalayim for the same reason, > > or add back Yom HaAtzmaut, and add Yom HaShoah and Yom Hazikaron. > > Doesn't matter to me either way. It might be nice to include Yom > > HaShoah in either event, as it is likely to become a universal > > Jewish religious holiday within our lifetimes. That is absolutely not true. No major religious authority has ever recognized any of the Israeli civil holidays. > > Whatever is decided > > having Yom Yerushalayim by itself is the strangest of all worlds. > > > > And I'll volunteer to keep this calendar synced since I might be > > the only one who cares about it. > > > > OK? > > > > ~Brian > > > > morning. > > if you're willing to do the work, i say go for it. i don;t have > enough > knowledge about dates/holidays to provide any useful feedback. > > if you have any opinion on the .christian diff, please do reply. i'm > about to as well, but again i just don;t have the knowledge to deal > with this. I can help with this. Contact me offline with any questions. In the diff below I see some conflicts in terms of transliteration. There are two main communities of Jews and the transliterations below do not align with either one in all cases. /jl > > jmc > > > Index: calendar.judaic > > == > > = > > RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.judaic,v > > retrieving revision 1.5 > > diff -u -p -r1.5 calendar.judaic > > --- calendar.judaic 6 Sep 2005 23:42:59 - 1.5 > > +++ calendar.judaic 12 Nov 2018 00:11:04 - > > @@ -7,7 +7,7 @@ > > #ifndef _calendar_judaic_ > > #define _calendar_judaic_ > > > > -Pesach+163 First Day of Rosh Hashanah (Jewish Lunar New Year; > > 5741 == 1980; > > +Pesach+163 First Day of Rosh Hashanah (Jewish Lunar New Year; > > 5779 == 2018; > > sabbatical) > > Pesach+164 Rosh Hashanah (sabbatical) > > Pesach+166 Fast of Gedalya (Murder of Gedalya and subsequent > > Exile; fast day) > > @@ -17,8 +17,9 @@ Pesach+179Succot (sabbatical) > > Pesach+184 Hoshanah Rabba (7th day of Succos) > > Pesach+185 Shmini Atzeres (8th Day of Gathering; sabbatical) > > Pesach+186 Shmini Atzeres/Simchas Torah (Rejoicing of the Law; > > sabbatical) > > -12/12* First Day of Chanukah > > -12/27* Fast of Asara B'Tevet (Babylonians put siege on > > Jerusalem; fast day) > > +12/03* First Day of Chanukah > > +12/18* Fast of Asara B'Tevet (Babylonians put siege on > > Jerusalem; fast day) > > +01/20* Tu B'Shevat (New Year of the Trees) > > Pesach-31 Fast of Esther (Battle of Purim; fast day) > > Pesach-30 Purim (Feast of Lots) > > Pesach-29 Purim (Feast of Lots) > > @@ -27,10 +28,10 @@ Pesach+1Pesach (sabbatical) > > Pesach+6 Pesach (sabbatical) > > Pesach+7 Pesach (Last Day of Passover; 8th day of Pesach; > > sabbatical) > > Pesach+34 Lag Ba`omer (Commemoration of the Great Rebellion) > > -05/22* Yom Yerushalayim (Reunification of Jerusalem) > > +06/01* Yom Yerushalayim (Reunification of Jerusalem) > > Pesach+50 Shavuot (Festival of Weeks; sabbatical) > > Pesach+51 Shavuot (Festival of Weeks; sabbatical) > > -07/10* Fast of Shiv'a Asar B'Tammuz (Romans breach Wall of > > Jerusalem; fast day) > > +07/21*
Re: snmpctl segfault
On Mon, Nov 12, 2018 at 04:51:38PM +0100, Martijn van Duren wrote:
> ping
>
> On 11/1/18 11:57 AM, Martijn van Duren wrote:
> > When experimenting with snmpd I found the following crash:
> > $ snmpctl snmp walk 127.0.0.1 oid 1
> > Segmentation fault (core dumped)
> >
> > The problem is a NULL dereference in ber_free_elements:
> > #0 0x0370920d24ca in ber_free_elements (root=0x0) at
> > /usr/src/usr.sbin/snmpctl/../snmpd/ber.c:897
> > #1 0x0370920d4386 in ber_printf_elements (ber=0x0, fmt=0x370920c79b9
> > "0}}") at /usr/src/usr.sbin/snmpctl/../snmpd/ber.c:645
> > #2 0x0370920dbd0d in snmpc_sendreq (sc=0x7f7bdcf0, type=1) at
> > /usr/src/usr.sbin/snmpctl/snmpclient.c:413
> > #3 0x0370920dba93 in snmpc_request (sc=0x7f7bdcf0, type=1) at
> > /usr/src/usr.sbin/snmpctl/snmpclient.c:217
> > #4 0x0370920dba38 in snmpc_run (sc=0x7f7bdcf0, action=WALK,
> > oid=0x373171110e0 "1") at /usr/src/usr.sbin/snmpctl/snmpclient.c:207
> > #5 0x0370920db891 in snmpclient (res=0x3709211f4e8) at
> > /usr/src/usr.sbin/snmpctl/snmpclient.c:175
> > #6 0x0370920dc8b4 in main (argc=5, argv=0x7f7be1a0) at
> > /usr/src/usr.sbin/snmpctl/snmpctl.c:133
> >
> > A simple NULL-check fixes the issue, but since I'm new to BER and snmp
> > I'm not sure if this is the right approach or whether there's a logic-
> > fault somewhere else.
> >
> > $ ./snmpctl snmp walk 127.0.0.1 oid 1
> > snmpctl: request failed: Invalid argument
> >
> > martijn@
> >
> > Index: ber.c
> > ===
> > RCS file: /cvs/src/usr.sbin/snmpd/ber.c,v
> > retrieving revision 1.48
> > diff -u -p -r1.48 ber.c
> > --- ber.c 12 Aug 2018 22:04:09 - 1.48
> > +++ ber.c 1 Nov 2018 10:56:47 -
> > @@ -894,6 +894,8 @@ ber_free_element(struct ber_element *roo
> > void
> > ber_free_elements(struct ber_element *root)
> > {
> > + if (root == NULL)
> > + return;
> > if (root->be_sub && (root->be_encoding == BER_TYPE_SEQUENCE ||
> > root->be_encoding == BER_TYPE_SET))
> > ber_free_elements(root->be_sub);
> >
OK claudio@
Please sync all ber.c versions to do the same.
PS: ber_free_elements() could be refactored to use ber_free_element() but
that is for another time.
--
:wq Claudio
Re: snmpctl segfault
ping
On 11/1/18 11:57 AM, Martijn van Duren wrote:
> When experimenting with snmpd I found the following crash:
> $ snmpctl snmp walk 127.0.0.1 oid 1
> Segmentation fault (core dumped)
>
> The problem is a NULL dereference in ber_free_elements:
> #0 0x0370920d24ca in ber_free_elements (root=0x0) at
> /usr/src/usr.sbin/snmpctl/../snmpd/ber.c:897
> #1 0x0370920d4386 in ber_printf_elements (ber=0x0, fmt=0x370920c79b9
> "0}}") at /usr/src/usr.sbin/snmpctl/../snmpd/ber.c:645
> #2 0x0370920dbd0d in snmpc_sendreq (sc=0x7f7bdcf0, type=1) at
> /usr/src/usr.sbin/snmpctl/snmpclient.c:413
> #3 0x0370920dba93 in snmpc_request (sc=0x7f7bdcf0, type=1) at
> /usr/src/usr.sbin/snmpctl/snmpclient.c:217
> #4 0x0370920dba38 in snmpc_run (sc=0x7f7bdcf0, action=WALK,
> oid=0x373171110e0 "1") at /usr/src/usr.sbin/snmpctl/snmpclient.c:207
> #5 0x0370920db891 in snmpclient (res=0x3709211f4e8) at
> /usr/src/usr.sbin/snmpctl/snmpclient.c:175
> #6 0x0370920dc8b4 in main (argc=5, argv=0x7f7be1a0) at
> /usr/src/usr.sbin/snmpctl/snmpctl.c:133
>
> A simple NULL-check fixes the issue, but since I'm new to BER and snmp
> I'm not sure if this is the right approach or whether there's a logic-
> fault somewhere else.
>
> $ ./snmpctl snmp walk 127.0.0.1 oid 1
> snmpctl: request failed: Invalid argument
>
> martijn@
>
> Index: ber.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/ber.c,v
> retrieving revision 1.48
> diff -u -p -r1.48 ber.c
> --- ber.c 12 Aug 2018 22:04:09 - 1.48
> +++ ber.c 1 Nov 2018 10:56:47 -
> @@ -894,6 +894,8 @@ ber_free_element(struct ber_element *roo
> void
> ber_free_elements(struct ber_element *root)
> {
> + if (root == NULL)
> + return;
> if (root->be_sub && (root->be_encoding == BER_TYPE_SEQUENCE ||
> root->be_encoding == BER_TYPE_SET))
> ber_free_elements(root->be_sub);
>
Re: ksh: fc -s and SIGINT
On 10/29/18 12:01 PM, Anton Lindqvist wrote:
> On Mon, Oct 29, 2018 at 09:55:38AM +0100, Martijn van Duren wrote:
>> On 10/28/18 8:13 PM, Anton Lindqvist wrote:
>>> Hi,
>>> Bug reported by miod@, how to reproduce:
>>>
>>> $ command -v r
>>> alias r='fc -s'
>>> $ sleep 5
>>> $ r sleep
>>> ^C # abort sleep before finishing
>>> $ r sleep
>>> ksh: fc: history function called recursively
>>>
>>> The c_fc() function has some internal state used to prevent recursive
>>> invocations that gets out of sync when the re-executed command is
>>> aborted by SIGINT. My proposal is to temporarily register a SIGINT
>>> handler before re-executing the command in order to reset the call depth
>>> counter upon signal delivery.
>>>
>>> Comments? OK?
>>>
>> You diff always unsets the shtrap pointer, which most likely unsets
>> custom SIGINT handlers installed by the user (untested). Next to that
>> this feels like special-casing and I'm afraid that there are some cases
>> we might be overlooking here.
>
> Thanks for the feedback. A few drive by thoughts, will look more closely
> this evening: a user supplied SIGINT handler is never registered as a
> one shot handler so it should never be overwritten. The hist_sigint()
> one shot handler is registered before executing the command, if the
> command does register a SIGINT handler it takes higher precedence and
> hist_execute() will return under such circumstances implying that
> fc_depth will be correctly decremented. The one shot handler is only
> used when the command does not register a SIGINT handler.
>
>>
>> The source with this issue is that a SIGINT triggers a list of
>> siglongjmps, which don't allow us to return to c_fc and decrement the
>> pointer. The diff below detects if we're on the lowest level of the
>> unwinding by abusing the interactive variable. This works because
>> calling fc from a non-interactive session is prohibited.
>>
>> I'm not 100% convinced that the placement of fc_depth = 0 should be
>> placed in shell(), or that we maybe should place it in unwind(). The
>> reason I choose for shell() is because interactive is guaranteed to
>> be setup for checking, because it's already there.
>>
>> This diff is only lightly tested and the code here is very hard to
>> untangle, so extreme scrutiny is desirable.
>>
>> martijn@
>>
After some back and forth with anton@ we came up with the following
diff. I would like to have some extra scrutiny on this one before
actually committing this.
martijn@
Index: history.c
===
RCS file: /cvs/src/bin/ksh/history.c,v
retrieving revision 1.80
diff -u -p -r1.80 history.c
--- history.c 15 Jan 2018 22:30:38 - 1.80
+++ history.c 12 Nov 2018 15:46:35 -
@@ -48,6 +48,8 @@ static uint32_t line_co;
static struct stat last_sb;
+static volatile sig_atomic_t c_fc_depth;
+
int
c_fc(char **wp)
{
@@ -58,9 +60,8 @@ c_fc(char **wp)
int optc, ret;
char *first = NULL, *last = NULL;
char **hfirst, **hlast, **hp;
- static int depth;
- if (depth != 0) {
+ if (c_fc_depth != 0) {
bi_errorf("history function called recursively");
return 1;
}
@@ -146,9 +147,9 @@ c_fc(char **wp)
hist_get_newest(false);
if (!hp)
return 1;
- depth++;
+ c_fc_depth++;
ret = hist_replace(hp, pat, rep, gflag);
- depth--;
+ c_fc_reset();
return ret;
}
@@ -268,11 +269,20 @@ c_fc(char **wp)
shf_close(shf);
*xp = '\0';
strip_nuls(Xstring(xs, xp), Xlength(xs, xp));
- depth++;
+ c_fc_depth++;
ret = hist_execute(Xstring(xs, xp));
- depth--;
+ c_fc_reset();
return ret;
}
+}
+
+/* Reset the c_fc depth counter.
+ * Made available for when an fc call is interrupted.
+ */
+void
+c_fc_reset(void)
+{
+ c_fc_depth = 0;
}
/* Save cmd in history, execute cmd (cmd gets trashed) */
Index: main.c
===
RCS file: /cvs/src/bin/ksh/main.c,v
retrieving revision 1.93
diff -u -p -r1.93 main.c
--- main.c 29 Sep 2018 14:13:19 - 1.93
+++ main.c 12 Nov 2018 15:46:35 -
@@ -549,6 +549,7 @@ shell(Source *volatile s, volatile int t
case LERROR:
case LSHELL:
if (interactive) {
+ c_fc_reset();
if (i == LINTR)
shellf("\n");
/* Reset any eof that was read as part of a
Index: sh.h
===
RCS file: /cvs/src/bin/ksh/sh.h,v
retrieving revision 1.73
diff -u -p -r1.73 sh.h
--- sh.h18
Re: [PATCH] httpd: Write X-Forwarded-For to access.log
On 11.11.18 18:43, Claudio Jeker wrote:
> On Sun, Nov 11, 2018 at 06:32:53PM +0100, Bruno Flueckiger wrote:
> > On 11.11.18 15:29, Florian Obser wrote:
> > > On Sun, Nov 11, 2018 at 01:46:06PM +0100, Sebastian Benoit wrote:
> > > > Bruno Flueckiger(inform...@gmx.net) on 2018.11.11 10:31:34 +0100:
> > > > > Hi
> > > > >
> > > > > When I run httpd(8) behind relayd(8) the access log of httpd contains
> > > > > the IP address of relayd, but not the IP address of the client. I've
> > > > > tried to match the logs of relayd(8) and httpd(8) using some scripting
> > > > > and failed.
> > > > >
> > > > > So I've written a patch for httpd(8). It stores the content of the
> > > > > X-Forwarded-For header in the third field of the log entry:
> > > > >
> > > > > www.example.com 192.0.2.99 192.0.2.134 - [11/Nov/2018:09:28:48 ...
> > > > >
> > > > > Cheers,
> > > > > Bruno
> > > >
> > > > I'm not sure we should do this unconditionally. With no relayd or other
> > > > proxy infront of httpd, this is (more) data the client controls.
> > >
> > > Isn't what httpd(8) currently logs apache's common log format? If
> > > people are shoving that through webalizer or something that will
> > > break. I don't think we can do this without a config option.
> > > Do we need LogFormat?
> > >
> > > >
> > > > Could this be a problem?
> > > >
> > > > code reads ok.
> > > >
> > > > /Benno
> > > >
> >
> > I've extended my patch with an option to the log directive. Both log xff
> > and log combined must be set for a server to log the content of the
> > X-Forwarded-For header. If only log combined is set the log entries
> > remain in the well-known format.
> >
> > This prevents clients from getting unwanted data in the log by default.
> > And it makes sure the log format remains default until one decides
> > actively to change it.
>
> From my experience with webservices is that today logging the IP is
> seldomly good enough. Please also include X-Forwarded-Port and maybe
> X-Forwarded-Proto.
> In general thanks to CG-NAT logging only IP is a bit pointless.
>
> --
> :wq Claudio
>
Thanks for the hint, Claudio.
This version of my diff includes the two headers X-Forwarded-For and
X-Forwarded-Port. Instead of using the third field of the log entry I
add two additional fileds to it. The first one contains the value of
X-Forwarded-For and the second one that of X-Forwarded-Port.
I think that appending two fields might do less harm than replacing one
field at the beginning of the log entry. I'm not sure that adding
X-Forwarded-Proto to the log really brings a benefit, so I left it away
in this diff.
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.55
diff -u -p -r1.55 config.c
--- usr.sbin/httpd/config.c 20 Jun 2018 16:43:05 - 1.55
+++ usr.sbin/httpd/config.c 12 Nov 2018 10:18:41 -
@@ -427,6 +427,10 @@ config_getserver_config(struct httpd *en
if ((srv_conf->flags & f) == 0)
srv_conf->flags |= parent->flags & f;
+ f = SRVFLAG_XFF|SRVFLAG_NO_XFF;
+ if ((srv_conf->flags & f) == 0)
+ srv_conf->flags |= parent->flags & f;
+
f = SRVFLAG_AUTH|SRVFLAG_NO_AUTH;
if ((srv_conf->flags & f) == 0) {
srv_conf->flags |= parent->flags & f;
Index: usr.sbin/httpd/httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.101
diff -u -p -r1.101 httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5 20 Jun 2018 16:43:05 - 1.101
+++ usr.sbin/httpd/httpd.conf.5 12 Nov 2018 10:18:41 -
@@ -455,6 +455,16 @@ If not specified, the default is
Enable or disable logging to
.Xr syslog 3
instead of the log files.
+.It Oo Ic no Oc Ic xff
+Enable or disable logging of the request headers
+.Ar X-Forwarded-For
+and
+.Ar X-Forwarded-Port
+if
+.Cm log combined
+is set. These headers can be set by a reverse proxy like
+.Xr relayd 8
+and should contain the IP address and TCP port of the client.
.El
.It Ic pass
Disable any previous
Index: usr.sbin/httpd/httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.142
diff -u -p -r1.142 httpd.h
--- usr.sbin/httpd/httpd.h 11 Oct 2018 09:52:22 - 1.142
+++ usr.sbin/httpd/httpd.h 12 Nov 2018 10:18:41 -
@@ -400,6 +400,8 @@ SPLAY_HEAD(client_tree, client);
#define SRVFLAG_DEFAULT_TYPE 0x0080
#define SRVFLAG_PATH_REWRITE 0x0100
#define SRVFLAG_NO_PATH_REWRITE0x0200
+#define SRVFLAG_XFF0x0400
+#define SRVFLAG_NO_XFF 0x0800
#define SRVFLAG_BITS \
"\10\01INDEX\02NO_INDEX\03AUTO_INDEX\04NO_AUTO_INDEX" \
Index:
Re: prevent bgpd from starting when control socket already used
On Mon, Nov 12, 2018 at 08:12:37AM +0100, Claudio Jeker wrote:
> On Sun, Nov 11, 2018 at 04:40:54PM -0700, Theo de Raadt wrote:
> > Makes sense to me, I suppose.
> >
> > Isn't another approach to swap the opening of the sockets?
> >
> > Or why does failure to control :179 sockets not stop startup?
>
> Because you can change them during reload and if they are incorrect for a
> reason it would kill running bgpd with all sessions.
> Having bgpd die on a config reload is for sure something we should not
> introduce.
Exactly!
It would be easy to change log_warn to fatalx. But think of this scenario:
Change "listen on" in bgpd.conf with a typo in the address and reload bgpd.
I think it's not desirable that bgpd exits and turns down all session in this
situation.
>
> > > I heard from two devs that started a 2nd bgpd by accident (forgot -n for
> > > a config check) which then caused downtime.
> > >
> > > Below diff adds a check to bgpd similar to the one we have now in ospfd
> > > and
> > > ospf6d: if another process is listening on the control socket bgpd exits.
> > >
> > > The situation is a bit different than in the ospfd case:
> > > - The socket path is defined in the config and not with an option.
> > > - The config is parsed relatively late (after daemon).
> > >
> > > Because of that rcctl would not detect that bgpd exits. But this only
> > > applies
> > > when the first bgpd was started without using the rc scripts.
> > >
> > > bgpd already detects that it can not bind the port if another instance is
> > > running. Adding a fatal there can have an effect when reloading after a
> > > config change. Loosing all sessions is not nice.
> > >
> > > Of course if the socket path is changed in the config and then reloaded
> > > the
> > > same can happen. I think this is less likely than changing a listen
> > > address.
> > >
> > > I think it is sufficient to add this check only to the control socket and
> > > not to the restricted socket.
> > >
> > > The diff in action:
> > >
> > > # /usr/src/usr.sbin/bgpd/obj/bgpd -dv
> > > startup
> > > session engine ready
> > > rereading config
> > > cannot bind to 0.0.0.0:179: Address already in use
> > > cannot bind to [::]:179: Address already in use
> > > control_check: socket in use
> > > fatal in bgpd: control socket check failed
> > > rib_new: Adj-RIB-In -> 0
> > > rib_new: Adj-RIB-Out -> 1
> > > route decision engine ready
> > > peer closed imsg connection
> > > fatal in RDE: Lost connection to parent
> > > peer closed imsg connection
> > > SE: Lost connection to parent
> > > session engine exiting
> > > #
> > >
> > > Comments? OKs?
> > >
> > > Remi
> > >
> > >
> > > cvs diff: Diffing .
> > > Index: bgpd.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
> > > retrieving revision 1.204
> > > diff -u -p -r1.204 bgpd.c
> > > --- bgpd.c29 Sep 2018 08:11:11 - 1.204
> > > +++ bgpd.c11 Nov 2018 20:33:32 -
> > > @@ -939,6 +939,8 @@ control_setup(struct bgpd_config *conf)
> > > }
> > > if ((cname = strdup(conf->csock)) == NULL)
> > > fatal("strdup");
> > > + if ((control_check(cname)) == -1)
> > > + fatalx("control socket check failed");
> > > if ((fd = control_init(0, cname)) == -1)
> > > fatalx("control socket setup failed");
> > > if (control_listen(fd) == -1)
> > > Index: control.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
> > > retrieving revision 1.90
> > > diff -u -p -r1.90 control.c
> > > --- control.c 11 Aug 2017 16:02:53 - 1.90
> > > +++ control.c 10 Nov 2018 20:52:46 -
> > > @@ -38,6 +38,32 @@ voidcontrol_result(struct ctl_conn *,
> > > ssize_t imsg_read_nofd(struct imsgbuf *);
> > >
> > > int
> > > +control_check(char *path)
> > > +{
> > > + struct sockaddr_un sun;
> > > + int fd;
> > > +
> > > + bzero(, sizeof(sun));
> > > + sun.sun_family = AF_UNIX;
> > > + strlcpy(sun.sun_path, path, sizeof(sun.sun_path));
> > > +
> > > + if ((fd = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
> > > + log_warn("control_check: socket check");
> > > + return (-1);
> > > + }
> > > +
> > > + if (connect(fd, (struct sockaddr *), sizeof(sun)) == 0) {
> > > + log_warnx("control_check: socket in use");
> > > + close(fd);
> > > + return (-1);
> > > + }
> > > +
> > > + close(fd);
> > > +
> > > + return (0);
> > > +}
> > > +
> > > +int
> > > control_init(int restricted, char *path)
> > > {
> > > struct sockaddr_un sun;
> > > Index: session.h
> > > ===
> > > RCS file: /cvs/src/usr.sbin/bgpd/session.h,v
> > > retrieving revision 1.125
> > > diff -u -p -r1.125 session.h
> > > --- session.h 24 Oct 2018
