Re: Have sysupgrade run fw_update -vv
Il Dom 13 Ago 2023, 21:17 Mikhail ha scritto: This will be useful in the installer too, when I first installed OpenBSD > with network connection I thought installation was stuck after > "Multiprocessor machine; using bsd.mp instead of bsd.", only after > some time I understood that the installer was downloading firmware. > +1 for this. Cheers, David
Re: UPDATE: freetype 2.8.1
Il 10 dic 2017 10:44 AM, "Matthieu Herrb" ha scritto: On Sun, Sep 24, 2017 at 10:03:13AM +0200, David Coppa wrote: > On Wed, Sep 20, 2017 at 7:06 PM, David Coppa wrote: > > > > Here's the update to FreeType-2.8.1. > > > > I don't know if there's enough time to have it in for 6.2. > > Just catching up with icb logs... > > i'm uncomfortable with updating freetype at this point. i'm > more afraid of runtime fallout than build problems. > ok no freetype upgrade before release. > > ok with me too, we'll come back to this after the unlock. Ping ? Can I commit it?
Re: UPDATE: freetype 2.8.1
On Wed, Sep 20, 2017 at 7:06 PM, David Coppa wrote: > > Here's the update to FreeType-2.8.1. > > I don't know if there's enough time to have it in for 6.2. Just catching up with icb logs... i'm uncomfortable with updating freetype at this point. i'm more afraid of runtime fallout than build problems. ok no freetype upgrade before release. ok with me too, we'll come back to this after the unlock. Ciao! David
Add "PNP0303" to acpi_isa_hids[]
Is the diff below ok?
It makes the line
"PNP0303" at acpi0 not configured
disappear from my dmesg.
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.330
diff -u -p -u -p -r1.330 acpi.c
--- dev/acpi/acpi.c 22 Jul 2017 21:06:17 - 1.330
+++ dev/acpi/acpi.c 9 Aug 2017 09:12:46 -
@@ -2801,6 +2801,7 @@ const char *acpi_skip_hids[] = {
/* ISA devices for which we attach a driver later */
const char *acpi_isa_hids[] = {
+ "PNP0303", /* 8042 PS/2 Controller */
"PNP0501", /* 16550A-compatible COM Serial Port */
NULL
};
Re: freetype-config.in
Il 19 giu 2017 22:32, "Stuart Henderson" ha scritto: On 2017/06/19 22:18, David Coppa wrote: > Il 19 giu 2017 21:23, "Stuart Henderson" ha scritto: > > On 2017/06/19 17:46, David Coppa wrote: > > > > > > Il 19 giu 2017 16:19, "Stuart Henderson" ha > > scritto: > > > > I'm looking at updating freetype, mostly to unbreak PCF font names > > which are currently different on different machines (e.g. I have > > "xos4 > > Terminus" on a more recently installed laptop but just "Terminus" > > on > > other machines that have been upgraded from older versions). This > > is a > > problem for ports which hardcode the font name like dwm and dmenu > > as > > there isn't any one name which will work on all machines. > > > > It looks mostly straightforward to update (new functions -> minor > > bump), > > but it looks like there's something odd with builds/unix/ > > freetype-config.in, > > our file isn't the same as upstream's last release, any suggestions > > on what > > to do with this? > > > > > > I've already posted an update to freetype-2.8, asking for a bulk build, > > and Matthieu already tested it... Have you missed it for some reasons? > > > > > > > > Ah, found it now. I'll do an i386 bulk after my current one is done. > > There's a difference in include/freetype/config/ftoption.h compared to > upstream's; they has PCF_CONFIG_OPTION_LONG_FAMILY_NAMES commented-out, > your diff has it enabled. I'd really like to get this disabled and > back to the normal names for PCF fonts, unless someone can fix it so > that it's consistent between newly installed and upgraded machines. > > > Here' a bit of rationale: > > The PCF change to show more "colourful" family names (introduced > in version 2.7.1) was too radical; it can now be configured with > PCF_CONFIG_OPTION_LONG_FAMILY_NAMES at compile time. > If activated, it can be switched off at run time with the new pcf > property 'no-long-family-names': > > export FREETYPE_PROPERTIES="pcf:no-long-family-names=1" > > Some users think the long family names are useful, some other not. > I think, by enabling the option, we can leave users the freedom of choice. Several ports (including dwm, dmenu) have "Terminus" hardcoded and won't work correctly on the machines which use the new naming. But only some machines use the new names, some use the old ones, and we don't know why. It's not just me, others confirmed on my ports@ post about it. So if we change those ports to use the new naming like "xos4 Terminus" then they break on other machines. > Arch Linux also enabled the option. And they had to make an faq telling people to add an XML file to create an alias - and then the only way to get consistent behaviour is to use the old name "Terminus" in configs and rely on it being picked up via the alias on newer systems Convincing enough. I'll keep it disabled. Thanks, David
Re: freetype-config.in
Il 19 giu 2017 21:23, "Stuart Henderson" ha scritto: On 2017/06/19 17:46, David Coppa wrote: > > > Il 19 giu 2017 16:19, "Stuart Henderson" ha > scritto: > > I'm looking at updating freetype, mostly to unbreak PCF font names > which are currently different on different machines (e.g. I have > "xos4 > Terminus" on a more recently installed laptop but just "Terminus" > on > other machines that have been upgraded from older versions). This > is a > problem for ports which hardcode the font name like dwm and dmenu > as > there isn't any one name which will work on all machines. > > It looks mostly straightforward to update (new functions -> minor > bump), > but it looks like there's something odd with builds/unix/ > freetype-config.in, > our file isn't the same as upstream's last release, any suggestions > on what > to do with this? > > > I've already posted an update to freetype-2.8, asking for a bulk build, > and Matthieu already tested it... Have you missed it for some reasons? > > > Ah, found it now. I'll do an i386 bulk after my current one is done. There's a difference in include/freetype/config/ftoption.h compared to upstream's; they has PCF_CONFIG_OPTION_LONG_FAMILY_NAMES commented-out, your diff has it enabled. I'd really like to get this disabled and back to the normal names for PCF fonts, unless someone can fix it so that it's consistent between newly installed and upgraded machines. Here' a bit of rationale: The PCF change to show more "colourful" family names (introduced in version 2.7.1) was too radical; it can now be configured with PCF_CONFIG_OPTION_LONG_FAMILY_NAMES at compile time. If activated, it can be switched off at run time with the new pcf property 'no-long-family-names': export FREETYPE_PROPERTIES="pcf:no-long-family-names=1" Some users think the long family names are useful, some other not. I think, by enabling the option, we can leave users the freedom of choice. Arch Linux also enabled the option. Ciao! David
Re: freetype-config.in
Il 19 giu 2017 16:19, "Stuart Henderson" ha scritto: I'm looking at updating freetype, mostly to unbreak PCF font names which are currently different on different machines (e.g. I have "xos4 Terminus" on a more recently installed laptop but just "Terminus" on other machines that have been upgraded from older versions). This is a problem for ports which hardcode the font name like dwm and dmenu as there isn't any one name which will work on all machines. It looks mostly straightforward to update (new functions -> minor bump), but it looks like there's something odd with builds/unix/freetype-config.in, our file isn't the same as upstream's last release, any suggestions on what to do with this? I've already posted an update to freetype-2.8, asking for a bulk build, and Matthieu already tested it... Have you missed it for some reasons?
Re: detect post threaded condition
Il 30 mag 2017 09:48, "Ted Unangst" ha scritto:
talking to stsp, he reminded me of a problematic bug that took some time to
track down in some desktop software that shall not be named. after a program
calls fork(), the child has only a single thread. per the standard, it needs
to get to exec() as quickly as possible. per the quality standards of modern
software, this doesn't always happen, and then strangeness happens.
this adds a quick check for this error condition. after a fork, we set a new
variable in the child that we are post threaded. this can be checked
elsewhere
in the library. i added a check to pthread_join because that's a notable
problem function.
Index: rthread.c
===
RCS file: /cvs/src/lib/librthread/rthread.c,v
retrieving revision 1.94
diff -u -p -r1.94 rthread.c
--- rthread.c 4 Sep 2016 10:13:35 - 1.94
+++ rthread.c 30 May 2017 07:43:12 -
@@ -64,6 +64,7 @@ REDIRECT_SYSCALL(thrkill);
static int concurrency_level; /* not used */
int _threads_ready;
+int _post_threaded;
size_t _thread_pagesize;
struct listhead _thread_list = LIST_HEAD_INITIALIZER(_thread_list);
_atomic_lock_t _thread_lock = _SPINLOCK_UNLOCKED;
@@ -358,6 +359,11 @@ pthread_join(pthread_t thread, void **re
pthread_t self;
PREP_CANCEL_POINT(tib);
+ if (_post_threaded) {
+#define GREATSCOTT "great scott! serious repurcussions on future events!\n"
As a BTTF fan I laughed loudly, but please fix the typo ;)
Ciao!
David
+ write(2, GREATSCOTT, sizeof(GREATSCOTT));
+ abort();
+ }
if (!_threads_ready)
_rthread_init();
self = tib->tib_thread;
Index: rthread_fork.c
===
RCS file: /cvs/src/lib/librthread/rthread_fork.c,v
retrieving revision 1.19
diff -u -p -r1.19 rthread_fork.c
--- rthread_fork.c 4 Sep 2016 10:13:35 - 1.19
+++ rthread_fork.c 30 May 2017 07:41:29 -
@@ -58,6 +58,7 @@ _dofork(pid_t (*sys_fork)(void))
pthread_t me;
pid_t newid;
int i;
+ extern int _post_threaded;
if (!_threads_ready)
return sys_fork();
@@ -110,6 +111,7 @@ _dofork(pid_t (*sys_fork)(void))
/* single threaded now */
__isthreaded = 0;
+ _post_threaded = 1;
}
#ifndef NO_PIC
else if (_DYNAMIC)
Fix comment into sys/dev/acpi/acpibtn.c
I think this comment was copy-pasted as is from the comment some lines below, but this is about hibernation, not sleep. Ok? Index: acpibtn.c === RCS file: /cvs/src/sys/dev/acpi/acpibtn.c,v retrieving revision 1.44 diff -u -p -u -p -r1.44 acpibtn.c --- acpibtn.c 2 Mar 2017 10:38:10 - 1.44 +++ acpibtn.c 11 May 2017 11:10:21 - @@ -236,7 +236,7 @@ acpibtn_notify(struct aml_node *node, in goto sleep; #ifdef HIBERNATE case 2: - /* Request to go to sleep */ + /* Request hibernation */ if (acpi_record_event(sc->sc_acpi, APM_USER_HIBERNATE_REQ)) acpi_addtask(sc->sc_acpi, acpi_sleep_task, sc->sc_acpi, ACPI_SLEEP_HIBERNATE);
freetype: fixes for CVE-2017-8105 and CVE-2017-8287
Hi!
Fixes for:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8105
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8287
>From upstream via Arch Linux.
Patches for -current and 6.1.
Ok?
Ciao,
David
Index: src/psaux/psobjs.c
===
RCS file: /cvs/xenocara/lib/freetype/src/psaux/psobjs.c,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 psobjs.c
--- src/psaux/psobjs.c 13 Jan 2017 11:19:59 - 1.18
+++ src/psaux/psobjs.c 9 May 2017 07:35:12 -
@@ -1718,6 +1718,14 @@
first = outline->n_contours <= 1
? 0 : outline->contours[outline->n_contours - 2] + 1;
+/* in malformed fonts it can happen that a contour was started */
+/* but no points were added*/
+if ( outline->n_contours && first == outline->n_points )
+{
+ outline->n_contours--;
+ return;
+}
+
/* We must not include the last point in the path if it */
/* is located on the first point. */
if ( outline->n_points > 1 )
Index: src/psaux/t1decode.c
===
RCS file: /cvs/xenocara/lib/freetype/src/psaux/t1decode.c,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 t1decode.c
--- src/psaux/t1decode.c 13 Jan 2017 11:20:00 - 1.18
+++ src/psaux/t1decode.c 9 May 2017 07:35:12 -
@@ -780,10 +780,19 @@
/* point without adding any point to the outline*/
idx = decoder->num_flex_vectors++;
if ( idx > 0 && idx < 7 )
+{
+ /* in malformed fonts it is possible to have other */
+ /* opcodes in the middle of a flex (which don't*/
+ /* increase `num_flex_vectors'); we thus have to */
+ /* check whether we can add a point*/
+ if ( FT_SET_ERROR( t1_builder_check_points( builder, 1 ) ) )
+goto Syntax_Error;
+
t1_builder_add_point( builder,
x,
y,
(FT_Byte)( idx == 3 || idx == 6 ) );
+}
}
break;
Index: src/psaux/psobjs.c
===
RCS file: /cvs/xenocara/lib/freetype/src/psaux/psobjs.c,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 psobjs.c
--- src/psaux/psobjs.c 13 Jan 2017 11:19:59 - 1.18
+++ src/psaux/psobjs.c 9 May 2017 07:39:38 -
@@ -1718,6 +1718,14 @@
first = outline->n_contours <= 1
? 0 : outline->contours[outline->n_contours - 2] + 1;
+/* in malformed fonts it can happen that a contour was started */
+/* but no points were added*/
+if ( outline->n_contours && first == outline->n_points )
+{
+ outline->n_contours--;
+ return;
+}
+
/* We must not include the last point in the path if it */
/* is located on the first point. */
if ( outline->n_points > 1 )
Index: src/psaux/t1decode.c
===
RCS file: /cvs/xenocara/lib/freetype/src/psaux/t1decode.c,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 t1decode.c
--- src/psaux/t1decode.c 13 Jan 2017 11:20:00 - 1.18
+++ src/psaux/t1decode.c 9 May 2017 07:39:38 -
@@ -780,10 +780,19 @@
/* point without adding any point to the outline*/
idx = decoder->num_flex_vectors++;
if ( idx > 0 && idx < 7 )
+{
+ /* in malformed fonts it is possible to have other */
+ /* opcodes in the middle of a flex (which don't*/
+ /* increase `num_flex_vectors'); we thus have to */
+ /* check whether we can add a point*/
+ if ( FT_SET_ERROR( t1_builder_check_points( builder, 1 ) ) )
+goto Syntax_Error;
+
t1_builder_add_point( builder,
x,
y,
(FT_Byte)( idx == 3 || idx == 6 ) );
+}
}
break;
Re: FreeType 2.7.1
On Thu, Jan 12, 2017 at 1:46 PM, Stuart Henderson wrote: > On 2017/01/09 15:29, David Coppa wrote: >> Here's the update to freetype-2.7.1, both inline and as attachment. > >> As usual, please test it. >> >> And, if you can, put it in your next bulk build. > > i386 bulk was clean. Thank you, Stuart. So... Ok to commit? Ciao! David
Re: FreeType 2.7
On Sat, Oct 22, 2016 at 11:52 AM, Matthieu Herrb wrote: > On Mon, Oct 10, 2016 at 12:46:41PM +0200, David Coppa wrote: >> >> Hi all, >> >> Here's the update to FreeType 2.7 (a gzipped diff is also attached). >> >> The biggest change is that now Subpixel hinting, also known as >> ClearType hinting, is enabled by default. >> >> As usual, a ports bulk build is appreciated. > > Hi, > > I'm not really sure that the bumping of the major revision of > libfontconfig, libXft and libXfont is needed or will help with out of > date packages. Can you explain ? We did this before. Yes, it's to avoid problems like the message below. But if you think it's just excessive paranoia, no problems, I'll drop the diffs. ---8<--- Date: Fri, 12 Aug 2016 22:34:11 +0200 From: Walter Alejandro Iglesias To: b...@openbsd.org Subject: Issues after upgrading fontconfig Message-ID: <20160812203411.GA13011@mamuca.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.6.2 (2016-07-01) List-Help: <mailto:majord...@openbsd.org?body=help> List-ID: List-Owner: <mailto:owner-b...@openbsd.org> List-Post: <mailto:b...@openbsd.org> List-Subscribe: <mailto:majord...@openbsd.org?body=sub%20bugs> List-Unsubscribe: <mailto:majord...@openbsd.org?body=unsub%20bugs> X-Loop: b...@openbsd.org Precedence: list Sender: owner-b...@openbsd.org After latest fontconfig update (aug 10 snapshot) cwm shows the following message and fails to start: $ cwm: XftFontOpenName Other applications that use xft fonts show warnings complaining about being linked to the old freetype lib (need to be recompiled?). Some examples: mwm:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_arab_nonbase_uniranges) size mismatch, relink your program mwm:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_cyrl_uniranges) size mismatch, relink your program mwm:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_blue_strings) size mismatch, relink your program mwm:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_script_classes) size mismatch, relink your program mwm:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_blue_stringsets) size mismatch, relink your program mwm:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_style_classes) size mismatch, relink your program fvwm2:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_arab_nonbase_uniranges) size mismatch, relink your program fvwm2:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_cyrl_uniranges) size mismatch, relink your program fvwm2:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_blue_strings) size mismatch, relink your program fvwm2:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_script_classes) size mismatch, relink your program fvwm2:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_blue_stringsets) size mismatch, relink your program fvwm2:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_style_classes) size mismatch, relink your program xpdf:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_arab_nonbase_uniranges) size mismatch, relink your program xpdf:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_cyrl_uniranges) size mismatch, relink your program xpdf:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_blue_strings) size mismatch, relink your program xpdf:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_script_classes) size mismatch, relink your program xpdf:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_blue_stringsets) size mismatch, relink your program xpdf:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_style_classes) size mismatch, relink your program inkscape:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_arab_nonbase_uniranges) size mismatch, relink your program inkscape:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_cyrl_uniranges) size mismatch, relink your program inkscape:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/lib/libfreetype.so.25.0 : WARNING: symbol(af_blue_strings) size mismatch, relink your program inkscape:/usr/X11R6/lib/libfreetype.so.26.0: /usr/X11R6/
Re: Default softraid crypto PBKDF2 rounds
Il 6 settembre 2016 14:56:32 CEST, Filippo Valsorda ha scritto: >Hello, > >I recently had the occasion to dive into the softraid crypto code [1] >and was quite pleased with the cleanliness of it all. However, I found >surprising the default value of 8k PBKDF2 rounds. > >I know it is easy to override and I should have RTFM, but I (naively, >I'll admit) assumed OpenBSD would pick very robust defaults, erring on >the conservative side. Is it maybe time to bump it up, or pick it based >on a quick machine benchmark? > >If there's consensus I might also provide a patch for the live >benchmark >option. yes, autodetection of a sensible value would be cool... Cheers David
Re: ifconfig baudrate
Il 31 agosto 2016 17:19:36 CEST, Reyk Floeter ha scritto:
>On Wed, Aug 31, 2016 at 09:12:30AM -0600, Theo de Raadt wrote:
>> > This makes ifconfig display baudrates defined in ifmedia.h tables.
>> >
>> > Before (prints media subtype):
>> >
>> > $ ifconfig iwn0 | grep media:
>> > media: IEEE802.11 autoselect (OFDM6 mode 11a)
>> > $ ifconfig em0 | grep media:
>> > media: Ethernet autoselect (100baseTX
>full-duplex,rxpause,txpause)
>> >
>> > After (prints corresponding baudrate):
>> >
>> > $ ifconfig iwn0 | grep media:
>> > media: IEEE802.11 autoselect (6Mbps mode 11a)
>> > $ ifconfig em0 | grep media:
>> > media: Ethernet autoselect (100Mbps
>full-duplex,rxpause,txpause)
>> >
>> > The output of 'ifconfig media' (which prints command syntax) is
>unchanged
>> > and we fall back to printing the media subtype if no baudrate is
>found.
>>
>> It makes no sense to change ethernet.
>>
>> The values it prints now is intended to match what you pass as
>> parameters for the 'media' and 'mediaopt' subcommands. That's why
>the
>> line is prefixed with the word "media", not "speed". There are
>legacy
>> options at the 100mbit level:
>>
>> if_media.h: { IFM_ETHER|IFM_100_TX, "100baseTX" },
> \
>> if_media.h: { IFM_ETHER|IFM_100_FX, "100baseFX" },
> \
>> if_media.h: { IFM_ETHER|IFM_100_T4, "100baseT4" },
> \
>> if_media.h: { IFM_ETHER|IFM_100_VG, "100baseVG" },
> \
>> if_media.h: { IFM_ETHER|IFM_100_T2, "100baseT2" },
> \
>>
>> Now they all become the opaque "100Mbps"? Sure many of those don't
>> exist at the moment, or are not used.
>>
>> But look at gig:
>>
>> if_media.h: { IFM_ETHER|IFM_1000_SX,"1000baseSX" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_SX,"1000SX" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_LX,"1000baseLX" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_LX,"1000LX" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_CX,"1000baseCX" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_CX,"1000CX" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_T, "1000baseT" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_T, "1000T" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_T, "1000baseTX" },
> \
>> if_media.h: { IFM_ETHER|IFM_1000_T, "1000TX" },
> \
>>
>> this is on cvs:
>>
>> media: Ethernet autoselect (10GSFP+Cu full-duplex)
>>
>> That is information, you'd replace that with a speed? No thanks,
>> it does not make sense.
>>
>
>Ok, it makes some sense to have this information for Ethernet.
>
>For 11n and all these new wireless rates it doesn't provide any useful
>information, what does "HT-MCS0" mean? Or "HT-MCS70"? In this case
>it would be much more useful to have the actual speed and not some
>obscure technical details from 802.11.
I also am in the "ok-for-wifi-but-not-for-wired" camp.
Ciao!
David
Re: Update: FreeType 2.6.5
On Fri, Aug 5, 2016 at 2:41 PM, Matthieu Herrb wrote: > On Thu, Aug 04, 2016 at 10:55:29AM +0200, David Coppa wrote: >> >> Here's the update to the latest freetype. >> >> $ check_sym >> /usr/X11R6/lib/libfreetype.so.25.0 --> obj/libfreetype.so.25.0 >> Dynamic export changes: >> added: >> [ bunch deleted] >> And thus I've bumped minor to 1. > > Theo recommends to not commit stuff with ABI changes until the ports > start building again (and some commits were reverted earlier this week > because of that). > > So please hold on a bit... Sure, no problems. > PS: I've an update to fontconfig 2.12 (and soon 2.12.1) ready, but > waiting because of that. Great! I was just starting to work on an update of fontconfig... Ciao! David -- "If you try a few times and give up, you'll never get there. But if you keep at it... There's a lot of problems in the world which can really be solved by applying two or three times the persistence that other people will." -- Stewart Nelson
Re: MBIM Patch (Round 2)
On Wed, Jun 1, 2016 at 8:34 PM, Stefan Sperling wrote:
> On Wed, Jun 01, 2016 at 08:18:13PM +0200, David Coppa wrote:
>> On Wed, Jun 1, 2016 at 6:11 PM, Stefan Sperling wrote:
>>
>> > I agree. And the driver can keep using the MBIM_ prefix for such macros
>> > even when we rename it to ubm.
>>
>> iirc, the chosen name for the new driver was "umb" (USB Mobile
>> Broadband), not "ubm"...
>> Has it changed again or it's just a typo?
>
> Oh, you're right, that was a typo.
>
> I suggested umb(4) ("USB Mobile Broadband") in the other thread,
> and still do.
+1 for umb(4) from me too, fwiw...
ciao!
David
Re: MBIM Patch (Round 2)
On Wed, Jun 1, 2016 at 6:11 PM, Stefan Sperling wrote: > I agree. And the driver can keep using the MBIM_ prefix for such macros > even when we rename it to ubm. iirc, the chosen name for the new driver was "umb" (USB Mobile Broadband), not "ubm"... Has it changed again or it's just a typo?
Re: Firefox, malloc(3) and threads
On Sun, Jan 24, 2016 at 7:47 PM, Adam Wolk wrote: > On Fri, 22 Jan 2016 22:46:39 +0100 (CET) > Mark Kettenis wrote: > >> Firefox makes a lot of concurrent malloc(3) calls. The locking to >> make malloc(3) thread-safe is a bit...suboptimal. This diff makes >> things better by using a mutex instead of spinlock. If you're running >> Firefox you want to try it; it makes video watchable on some machines. >> If you're not running Firefox you want to try it; to make sure it >> doesn't break things. >> >> Enjoy, >> >> Mark >> ' > > Applied to a Jan 15h snapshot sources. Youtube is not fully 'watchable' > on firefox but feels significantly better. I can also now watch full > screen youtube videos on chromium 1920x1080 with no stutter (lenovo > g50-70). > > Generally gnome 3 feels a bit snappier especially on first load, > bringing up the menu searching for 'terminal' leads to a faster > rendering of the results. This might be just 'imagined' by me. > > On a more measurable front. I ran the octane benchmark against firefox > post and before the patch. It resulted in a slight improvement from > 12486 to 12826 score [1]. Besides performance related issues, the problem we saw in the past was firefox using a huge amount of CPU resources with no apparent reasons... So please also try to test if you still see this erratic behavior with Mark's patch applied. ciao, David
Re: libressl cert chain problem.
On Tue, 22 Dec 2015, Stuart Henderson wrote: > Could some libressl people look at this please? We have a problem where > the chain coming from a server roots from a certificate that isn't in > the root store, but an intermediary certificate *is* in the root store. > Thanks. > > > As reported by dcoppa, connecting with HTTPS to tuner.pandora.com fails > with the current root cert store in OpenBSD. Found the bug while trying to use pianobar (a pandora.com client for the console): $ pianobar Welcome to pianobar (2015.11.22)! Press ? for a list of commands. (i) Login... Network error: Peer certificate cannot be authenticated with given CA certificates I will test patches and give feedback... Thanks, David
pppd and ioctl(TIOCSETD) (was: CVS: cvs.openbsd.org: src)
On Mon, 21 Dec 2015, Stefan Fritsch wrote: > CVSROOT: /cvs > Module name: src > Changes by: s...@cvs.openbsd.org2015/12/21 14:49:03 > > Modified files: > sys/kern : tty_conf.c tty_endrun.c tty_msts.c tty_nmea.c > sys/net: ppp_tty.c > sys/sys: tty.h > > Log message: > Move ppp, nmea, endrun, and msts prototypes to tty.h > > Fix inconsistent arguments for pppopen/pppclose/pppstart. > Use passed in argument p in pppopen instead of curproc. > > "Looks good to me" deraadt@ I suspect this broke my 3G connection: Dec 22 13:22:51 t420 chat[16397]: send (ATDT*99***1#^M) Dec 22 13:22:52 t420 chat[16397]: timeout set to 30 seconds Dec 22 13:22:52 t420 chat[16397]: expect (CONNECT) Dec 22 13:22:52 t420 chat[16397]: ^M Dec 22 13:22:52 t420 chat[16397]: ^M Dec 22 13:22:52 t420 chat[16397]: CONNECT Dec 22 13:22:52 t420 chat[16397]: -- got it Dec 22 13:22:52 t420 chat[16397]: send (\\d) Dec 22 13:22:53 t420 pppd[12116]: Serial connection established. Dec 22 13:22:54 t420 pppd[12116]: ioctl(TIOCSETD): Operation not supported by device I start this connection using: /usr/sbin/pppd file /etc/ppp/peers/postemobile And it always worked w/o problems until now. It's a -current from ~1 hour ago: $ sysctl kern.version kern.version=OpenBSD 5.9-beta (GENERIC.MP) #0: Tue Dec 22 12:08:24 CET 2015 dco...@t420.bsdgeek.it:/usr/src/sys/arch/amd64/compile/GENERIC.MP Ideas? TIA! David
Re: scan regression fixes
On Thu, Dec 17, 2015 at 10:34 PM, Stefan Sperling wrote:
> On Thu, Dec 17, 2015 at 08:13:03PM +0100, Stefan Sperling wrote:
>> This should fix the infinite scanning loops people have been
>> reporting with 11n-enabled iwn(4), as well as the issue where
>> clients associating to 11g APs end up in 11b mode and can't
>> use OFDM data rates.
>>
>> ok?
>
> Updated diff which allows scanning to work after somebody decided
> to run 'ifconfig iwn0 media autoselect mode 11n' for some reason.
> (Don't do that, it won't enforce 11n -- 11n cannot really be set
> a priori because it's negotiated during association.)
>
> Also delete a bit of code from ieee80211_newstate() in ieee80211_proto.c
> which is pointless now that ieee80211_chan2mode() won't return MODE_11N.
A minor problem I've noticed was dhclient being slower to get the link
from my AP.
The patch below fixed it.
Thanks again
David
> Index: ieee80211.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 ieee80211.c
> --- ieee80211.c 16 Dec 2015 12:52:03 - 1.52
> +++ ieee80211.c 17 Dec 2015 21:16:03 -
> @@ -856,10 +856,12 @@ ieee80211_next_mode(struct ifnet *ifp)
> {
> struct ieee80211com *ic = (void *)ifp;
>
> - if (IFM_MODE(ic->ic_media.ifm_cur->ifm_media) != IFM_AUTO) {
> + if (IFM_MODE(ic->ic_media.ifm_cur->ifm_media) != IFM_AUTO &&
> + ic->ic_curmode != IEEE80211_MODE_11N) {
> /*
> * Reset the scan state and indicate a wrap around
> * if we're running in a fixed, user-specified phy mode.
> +* But 11n is not a valid phy mode for scanning (see below).
> */
> ieee80211_reset_scan(ifp);
> return (IEEE80211_MODE_AUTO);
> @@ -874,6 +876,16 @@ ieee80211_next_mode(struct ifnet *ifp)
> /* Wrap around and ignore turbo mode */
> if (ic->ic_curmode == IEEE80211_MODE_TURBO)
> continue;
> +#ifndef IEEE80211_NO_HT
> + /*
> +* Skip 11n mode while scanning. Its set of channels is
> +* the superset of all channels supported by other modes
> +* and 11n features cannot be negotiated without exchanging
> +* frames in another mode first.
> +*/
> + if (ic->ic_curmode == IEEE80211_MODE_11N)
> + continue;
> +#endif
> if (ic->ic_curmode >= IEEE80211_MODE_MAX) {
> ic->ic_curmode = IEEE80211_MODE_AUTO;
> break;
> @@ -893,6 +905,11 @@ ieee80211_next_mode(struct ifnet *ifp)
> * caller can select a rate set. This is problematic and the
> * work here assumes how things work elsewhere in this code.
> *
> + * Because the result of this function is ultimately used to select
> + * a rate from the rate set of the returned mode, it must not return
> + * IEEE80211_MODE_11N. This function may be called in 11n mode to find
> + * a non-MCS rate to use for sending frames to non-HT STAs.
> + *
> * XXX never returns turbo modes -dcy
> */
> enum ieee80211_phymode
> @@ -911,11 +928,6 @@ ieee80211_chan2mode(struct ieee80211com
> * characteristics. We assume that turbo-only channels
> * are not considered when the channel set is constructed.
> */
> -#ifndef IEEE80211_NO_HT
> - if (IEEE80211_IS_CHAN_N(chan))
> - return IEEE80211_MODE_11N;
> - else
> -#endif
> if (IEEE80211_IS_CHAN_T(chan))
> return IEEE80211_MODE_TURBO;
> else if (IEEE80211_IS_CHAN_5GHZ(chan))
> Index: ieee80211_input.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
> retrieving revision 1.145
> diff -u -p -r1.145 ieee80211_input.c
> --- ieee80211_input.c 12 Dec 2015 13:56:10 - 1.145
> +++ ieee80211_input.c 17 Dec 2015 18:42:06 -
> @@ -2257,16 +2257,8 @@ ieee80211_recv_assoc_resp(struct ieee802
>
> /* Hop out of 11n mode after associating to a non-HT AP. */
> if (ic->ic_curmode == IEEE80211_MODE_11N &&
> - (ni->ni_flags & IEEE80211_NODE_HT) == 0) {
> - if (IEEE80211_IS_CHAN_T(ni->ni_chan))
> - ieee80211_setmode(ic, IEEE80211_MODE_TURBO);
> - else if (IEEE80211_IS_CHAN_A(ni->ni_chan))
> - ieee80211_setmode(ic, IEEE80211_MODE_11A);
> - else if (IEEE80211_IS_CHAN_G(ni->ni_chan))
> - ieee80211_setmode(ic, IEEE80211_MODE_11G);
> - else
> - ieee80211_setmode(ic, IEEE80211_MODE_11B);
> - }
> + (ni->ni_flags & IEEE80211_NODE_HT) == 0)
> + ieee80211_setmode(ic, ieee80211_chan2mode(ic, ni->ni_chan));
> #endif
> /*
> * Configure st
Re: initial 11n support for iwn (n, not m)
On Wed, 16 Dec 2015, Stefan Sperling wrote: > This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver. > > It also tweaks replay detection for CCMP encrypted frames, which needed > tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes > this driver was discarding some retransmitted frames for no good reason. > > This driver supports a very wide range of hardware so please test this > with as many iwn(4) adapters as possible. If we don't get enough tests > this change may not be able to make the 5.9 release. > > Works for me on: > iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, > MIMO 2T2R, MoW > > Please post here or let me know in private which hardware you're testing on. > Thanks. Works fine on my ThinkPad T420 with: iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, MIMO 2T2R, MoW, address 08:11:96:0b:b3:28 Connected to my phone's hotspot: iwn0: flags=8843 mtu 1500 lladdr 08:11:96:0b:b3:28 priority: 4 groups: wlan egress media: IEEE802.11 autoselect (HT-MCS7 mode 11n) status: active ieee80211: nwid LG-P880_0710 chan 6 bssid bc:f5:ac:f7:2a:7f -29dBm wpakey wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip powersave on (100ms sleep) inet 192.168.43.207 netmask 0xff00 broadcast 192.168.43.255 My wlan at home: iwn0: flags=8843 mtu 1500 lladdr 08:11:96:0b:b3:28 priority: 4 groups: wlan egress media: IEEE802.11 autoselect (HT-MCS4 mode 11n) status: active ieee80211: nwid vitewlan chan 6 bssid 44:94:fc:f1:4d:ba -61dBm wpakey wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip powersave on (100ms sleep) inet 192.168.2.78 netmask 0xff00 broadcast 192.168.2.255 Ciao! David
Re: FreeType-2.6.1 !!header files layout changed again!!
On Tue, 13 Oct 2015, Christian Weisgerber wrote: > David Coppa: > > > New freetype version, new header file layout :( :( > > [...] > > Obviously, I'm expecting some fallouts from a bulk build with this... > > The only initial fallout from this is devel/xulrunner/24. > > However, without xulrunner ~750 further packages aren't built, so > we need a fix for xulrunner before we can see what the overall > breakage is. diff below. Cheers! David Index: Makefile === RCS file: /cvs/ports/devel/xulrunner/24/Makefile,v retrieving revision 1.23 diff -u -p -u -p -r1.23 Makefile --- Makefile24 Sep 2015 20:19:15 - 1.23 +++ Makefile14 Oct 2015 07:25:24 - @@ -7,8 +7,8 @@ MOZILLA_PROJECT = xulrunner MOZILLA_DIST = firefox PKGSPEC-devel =xulrunner-devel->=24.0,<31.0 PKGSPEC-main = xulrunner->=24.0,<31.0 -REVISION-main =5 -REVISION-devel = 5 +REVISION-main =6 +REVISION-devel = 6 SO_VERSION = 0.0 MOZILLA_LIBS = mozgnome mozalloc xul Index: patches/patch-config_system-headers === RCS file: /cvs/ports/devel/xulrunner/24/patches/patch-config_system-headers,v retrieving revision 1.4 diff -u -p -u -p -r1.4 patch-config_system-headers --- patches/patch-config_system-headers 30 Jun 2015 07:08:28 - 1.4 +++ patches/patch-config_system-headers 14 Oct 2015 07:25:24 - @@ -1,15 +1,15 @@ $OpenBSD: patch-config_system-headers,v 1.4 2015/06/30 07:08:28 dcoppa Exp $ -Fix building with freetype-2.6 or later -https://hg.mozilla.org/mozilla-central/rev/afd840d66e6a +Fix building with freetype-2.6.1 +https://hg.mozilla.org/mozilla-central/rev/af40750720b5 --- config/system-headers.orig Mon Jun 29 16:25:46 2015 +++ config/system-headers Mon Jun 29 16:28:26 2015 -@@ -415,6 +415,7 @@ freetype/ftbitmap.h - freetype/ftxf86.h - freetype.h - ftcache.h -+ftfntfmt.h - ftglyph.h - ftsynth.h - ftoutln.h +@@ -402,6 +402,7 @@ frame/log.h + frame/req.h + freetype/freetype.h + freetype/ftcache.h ++freetype/ftfntfmt.h + freetype/ftglyph.h + freetype/ftsynth.h + freetype/ftoutln.h Index: patches/patch-js_src_config_system-headers === RCS file: /cvs/ports/devel/xulrunner/24/patches/patch-js_src_config_system-headers,v retrieving revision 1.4 diff -u -p -u -p -r1.4 patch-js_src_config_system-headers --- patches/patch-js_src_config_system-headers 30 Jun 2015 07:08:28 - 1.4 +++ patches/patch-js_src_config_system-headers 14 Oct 2015 07:25:24 - @@ -1,15 +1,15 @@ $OpenBSD: patch-js_src_config_system-headers,v 1.4 2015/06/30 07:08:28 dcoppa Exp $ -Fix building with freetype-2.6 or later -https://hg.mozilla.org/mozilla-central/rev/afd840d66e6a +Fix building with freetype-2.6.1 +https://hg.mozilla.org/mozilla-central/rev/af40750720b5 --- js/src/config/system-headers.orig Mon Jun 29 16:35:12 2015 +++ js/src/config/system-headers Mon Jun 29 16:35:14 2015 -@@ -415,6 +415,7 @@ freetype/ftbitmap.h - freetype/ftxf86.h - freetype.h - ftcache.h -+ftfntfmt.h - ftglyph.h - ftsynth.h - ftoutln.h +@@ -402,6 +402,7 @@ frame/log.h + frame/req.h + freetype/freetype.h + freetype/ftcache.h ++freetype/ftfntfmt.h + freetype/ftglyph.h + freetype/ftsynth.h + freetype/ftoutln.h
Re: FreeType-2.6.1 !!header files layout changed again!!
On Wed, Oct 7, 2015 at 3:01 PM, Stuart Henderson wrote: > On 2015/10/07 14:40, David Coppa wrote: >> On Wed, Oct 7, 2015 at 2:12 PM, David Coppa wrote: >> > >> > Hi! >> > >> > New freetype version, new header file layout :( :( >> > >> > Now, all header files except 'ft2build.h' are (again) into >> > /usr/X11R6/include/freetype2/freetype/. >> > >> > Luckily, no ABI changes this time. >> > >> > So, to apply the patches: >> > >> > >> > $ cd /usr/src/ >> > $ patch -NE -i /path/to/mtree.diff >> > >> > -> as root <- >> > # cat /usr/src/etc/mtree/BSD.x11.dist > /etc/mtree/BSD.x11.dist >> > # rm -rf /usr/X11R6/include/freetype2 >> > >> > $ cd /usr/xenocara/ >> > $ make bootstrap >> > $ cd /usr/xenocara/lib/freetype >> > $ mkdir -p include/freetype/config >> > $ mkdir -p include/freetype/internal/services >> > $ patch -NEp0 -i /path/to/freetype-2.6.1.diff >> > $ make depend >> > $ make clean ; make >> > >> > -> as root <- >> > # cd /usr/xenocara/lib/freetype ; make install >> > >> > >> > >> > Obviously, I'm expecting some fallouts from a bulk build with this... >> > >> > Cheers, >> > David >> >> This update is also security related, addressing some CVEs: >> >> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9745 >> >> http://seclists.org/bugtraq/2015/Oct/41 >> >> http://www.openwall.com/lists/oss-security/2015/09/11/4 >> >> Ciao! >> David > > *grmbl* somebody slap them, please > > Maybe backport the security fixes first? It'll need doing anyway if they > are to go into -stable.. Ehm... Nevermind, these security bugs were already fixed in freetype-2.6.0. Sorry for the noise! Btw, this is the changelog for freetype-2.6.1: http://sourceforge.net/projects/freetype/files/freetype2/2.6.1/ The request for a bulk build with freetype-2.6.1 is still valid :) ciao David
Re: FreeType-2.6.1 !!header files layout changed again!!
On Wed, Oct 7, 2015 at 3:01 PM, Stuart Henderson wrote: > On 2015/10/07 14:40, David Coppa wrote: >> On Wed, Oct 7, 2015 at 2:12 PM, David Coppa wrote: >> > >> > Hi! >> > >> > New freetype version, new header file layout :( :( >> > >> > Now, all header files except 'ft2build.h' are (again) into >> > /usr/X11R6/include/freetype2/freetype/. >> > >> > Luckily, no ABI changes this time. >> > >> > So, to apply the patches: >> > >> > >> > $ cd /usr/src/ >> > $ patch -NE -i /path/to/mtree.diff >> > >> > -> as root <- >> > # cat /usr/src/etc/mtree/BSD.x11.dist > /etc/mtree/BSD.x11.dist >> > # rm -rf /usr/X11R6/include/freetype2 >> > >> > $ cd /usr/xenocara/ >> > $ make bootstrap >> > $ cd /usr/xenocara/lib/freetype >> > $ mkdir -p include/freetype/config >> > $ mkdir -p include/freetype/internal/services >> > $ patch -NEp0 -i /path/to/freetype-2.6.1.diff >> > $ make depend >> > $ make clean ; make >> > >> > -> as root <- >> > # cd /usr/xenocara/lib/freetype ; make install >> > >> > >> > >> > Obviously, I'm expecting some fallouts from a bulk build with this... >> > >> > Cheers, >> > David >> >> This update is also security related, addressing some CVEs: >> >> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9745 >> >> http://seclists.org/bugtraq/2015/Oct/41 >> >> http://www.openwall.com/lists/oss-security/2015/09/11/4 >> >> Ciao! >> David > > *grmbl* somebody slap them, please > > Maybe backport the security fixes first? It'll need doing anyway if they > are to go into -stable.. I'm going to have a look in a minute...
Re: FreeType-2.6.1 !!header files layout changed again!!
On Wed, Oct 7, 2015 at 2:12 PM, David Coppa wrote: > > Hi! > > New freetype version, new header file layout :( :( > > Now, all header files except 'ft2build.h' are (again) into > /usr/X11R6/include/freetype2/freetype/. > > Luckily, no ABI changes this time. > > So, to apply the patches: > > > $ cd /usr/src/ > $ patch -NE -i /path/to/mtree.diff > > -> as root <- > # cat /usr/src/etc/mtree/BSD.x11.dist > /etc/mtree/BSD.x11.dist > # rm -rf /usr/X11R6/include/freetype2 > > $ cd /usr/xenocara/ > $ make bootstrap > $ cd /usr/xenocara/lib/freetype > $ mkdir -p include/freetype/config > $ mkdir -p include/freetype/internal/services > $ patch -NEp0 -i /path/to/freetype-2.6.1.diff > $ make depend > $ make clean ; make > > -> as root <- > # cd /usr/xenocara/lib/freetype ; make install > > > > Obviously, I'm expecting some fallouts from a bulk build with this... > > Cheers, > David This update is also security related, addressing some CVEs: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9745 http://seclists.org/bugtraq/2015/Oct/41 http://www.openwall.com/lists/oss-security/2015/09/11/4 Ciao! David
Re: minor release of libxcb (1.11.1)
On Mon, Sep 28, 2015 at 10:23 PM, Matthieu Herrb wrote: > On Wed, Sep 16, 2015 at 02:37:38AM -0600, David Coppa wrote: >> >> Hi! >> >> Here's an update to libxcb-1.11.1 >> >> Changes: >> >> - Expose 64-bit sequence numbers for XLib >> - Call _xcb_wake_up_next_reader from xcb_wait_for_special_event >> - Fix a thread hang with xcb_wait_for_special_event() >> >> Tested in a full xenocara rebuild on amd64. >> I think a minor crank is required. > > The diff looks ok, but we currently don't have anything in xenocara > using the new functions. Do you know any application in ports that > would use it if available ? I don't know, I've just followed the "rule" new functions->minor bump. Maybe Stuart can grep the ports tree with ag... The new functions are: uint64_t xcb_send_request64(xcb_connection_t *c, int flags, struct iovec *vector, const xcb_protocol_request_t *request); void *xcb_wait_for_reply64(xcb_connection_t *c, uint64_t request, xcb_generic_error_t **e); int xcb_poll_for_reply64(xcb_connection_t *c, uint64_t request, void **reply, xcb_generic_error_t **error); Ciao! David
Re: panic with latest ugen.c and pcsc-lite
On Tue, Sep 15, 2015 at 6:50 AM, Grant Czajkowski wrote: > On Fri, Sep 11, 2015 at 02:41:04AM -0600, David Coppa wrote: >> >> Hi! >> >> Repeatedly hit the panic below with latest ugen.c code (v 1.88) and >> pcsc-lite. > > Thanks for the report. Could you please try this patch? Yes, this fixes the panic. Ciao! David
Re: panic with latest ugen.c and pcsc-lite
On Fri, Sep 11, 2015 at 10:41 AM, David Coppa wrote:
>
> Hi!
>
> Repeatedly hit the panic below with latest ugen.c code (v 1.88) and
> pcsc-lite.
>
> libusb1 is version 1.0.20-rc3.
Reverting to v 1.85 fixes the issue for me.
Ciao!
David
packages are:
libusb1-1.0.20rc3
ccid-1.4.20
pcsc-lite-1.8.14
> panic: ehci_device_clear_toggle: queue active
> Stopped at Debugger+0x9: leave
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
> usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24
> ugen_do_read() at ugen_do_read+0x43c
> ugenread() at ugenread+0x48
> spec_read() at spec_read+0x2c3
> VOP_READ() at VOP_READ+0x3f
> vn_read() at vn_read+0xa1
> dofilereadv() at dofilereadv+0x204
> end trace frame: 0x800032f23e50, count: 0
> http://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{1}> show panic
> ehci_device_clear_toggle: queue active
> ddb{1}> trace
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
> usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24
> ugen_do_read() at ugen_do_read+0x43c
> ugenread() at ugenread+0x48
> spec_read() at spec_read+0x2c3
> VOP_READ() at VOP_READ+0x3f
> vn_read() at vn_read+0xa1
> dofilereadv() at dofilereadv+0x204
> sys_read() at sys_read+0x89
> syscall() at syscall+0x358
> --- syscall (number 3) ---
> end trace frame: 0x0, count: -12
> 0x4dd4348019a:
> ddb{1}> mach ddbcpu 0
> Stopped at Debugger+0x9: leave
> Debugger() at Debugger+0x9
> x86_ipi_handler() at x86_ipi_handler+0x76
> Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
> --- interrupt ---
> acpicpu_idle() at acpicpu_idle+0x13c
> cpu_idle_cycle() at cpu_idle_cycle+0x10
> end trace frame: 0x0, count: 6
> http://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{0}> trace
> Debugger() at Debugger+0x9
> x86_ipi_handler() at x86_ipi_handler+0x76
> Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
> --- interrupt ---
> acpicpu_idle() at acpicpu_idle+0x13c
> cpu_idle_cycle() at cpu_idle_cycle+0x10
> end trace frame: 0x0, count: -5
> ddb{0}> mach ddbcpu 2
> Stopped at Debugger+0x9: leave
> Debugger() at Debugger+0x9
> x86_ipi_handler() at x86_ipi_handler+0x76
> Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
> --- interrupt ---
> acpicpu_idle() at acpicpu_idle+0x13c
> cpu_idle_cycle() at cpu_idle_cycle+0x10
> end trace frame: 0x0, count: 6
> http://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{2}> trace
> Debugger() at Debugger+0x9
> x86_ipi_handler() at x86_ipi_handler+0x76
> Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
> --- interrupt ---
> acpicpu_idle() at acpicpu_idle+0x13c
> cpu_idle_cycle() at cpu_idle_cycle+0x10
> end trace frame: 0x0, count: -5
> ddb{2}> mach ddbcpu 3
> Stopped at Debugger+0x9: leave
> Debugger() at Debugger+0x9
> x86_ipi_handler() at x86_ipi_handler+0x76
> Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
> --- interrupt ---
> acpicpu_idle() at acpicpu_idle+0x13c
> cpu_idle_cycle() at cpu_idle_cycle+0x10
> end trace frame: 0x0, count: 6
> http://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{3}> trace
> Debugger() at Debugger+0x9
> x86_ipi_handler() at x86_ipi_handler+0x76
> Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
> --- interrupt ---
> acpicpu_idle() at acpicpu_idle+0x13c
> cpu_idle_cycle() at cpu_idle_cycle+0x10
> end trace frame: 0x0, count: -5
> ddb{3}> mach ddbcpu 1
> Stopped at Debugger+0x9: leave
> Debugger() at Debugger+0x9
> panic() at panic+0xfe
> ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
> usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24
> ugen_do_read() at ugen_do_read+0x43c
> ugenread() at ugenread+0x48
> spec_read() at spec_read+0x2c3
> VOP_READ() at VOP_READ+0x3f
> vn_read() at vn_read+0xa1
> dofilereadv() at dofilereadv+0x204
> end trace frame: 0x800032f23e50, count: 0
> http://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{1}> ps
>PID PPID PGRPUID S FLAGS WAIT COMMAND
> 21818 21220 21818 1000 30x83 selectopensc-tool
> 21417 1 19487 0 30x81 s
panic with latest ugen.c and pcsc-lite
Hi!
Repeatedly hit the panic below with latest ugen.c code (v 1.88) and
pcsc-lite.
libusb1 is version 1.0.20-rc3.
panic: ehci_device_clear_toggle: queue active
Stopped at Debugger+0x9: leave
Debugger() at Debugger+0x9
panic() at panic+0xfe
ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24
ugen_do_read() at ugen_do_read+0x43c
ugenread() at ugenread+0x48
spec_read() at spec_read+0x2c3
VOP_READ() at VOP_READ+0x3f
vn_read() at vn_read+0xa1
dofilereadv() at dofilereadv+0x204
end trace frame: 0x800032f23e50, count: 0
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{1}> show panic
ehci_device_clear_toggle: queue active
ddb{1}> trace
Debugger() at Debugger+0x9
panic() at panic+0xfe
ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24
ugen_do_read() at ugen_do_read+0x43c
ugenread() at ugenread+0x48
spec_read() at spec_read+0x2c3
VOP_READ() at VOP_READ+0x3f
vn_read() at vn_read+0xa1
dofilereadv() at dofilereadv+0x204
sys_read() at sys_read+0x89
syscall() at syscall+0x358
--- syscall (number 3) ---
end trace frame: 0x0, count: -12
0x4dd4348019a:
ddb{1}> mach ddbcpu 0
Stopped at Debugger+0x9: leave
Debugger() at Debugger+0x9
x86_ipi_handler() at x86_ipi_handler+0x76
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
acpicpu_idle() at acpicpu_idle+0x13c
cpu_idle_cycle() at cpu_idle_cycle+0x10
end trace frame: 0x0, count: 6
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}> trace
Debugger() at Debugger+0x9
x86_ipi_handler() at x86_ipi_handler+0x76
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
acpicpu_idle() at acpicpu_idle+0x13c
cpu_idle_cycle() at cpu_idle_cycle+0x10
end trace frame: 0x0, count: -5
ddb{0}> mach ddbcpu 2
Stopped at Debugger+0x9: leave
Debugger() at Debugger+0x9
x86_ipi_handler() at x86_ipi_handler+0x76
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
acpicpu_idle() at acpicpu_idle+0x13c
cpu_idle_cycle() at cpu_idle_cycle+0x10
end trace frame: 0x0, count: 6
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{2}> trace
Debugger() at Debugger+0x9
x86_ipi_handler() at x86_ipi_handler+0x76
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
acpicpu_idle() at acpicpu_idle+0x13c
cpu_idle_cycle() at cpu_idle_cycle+0x10
end trace frame: 0x0, count: -5
ddb{2}> mach ddbcpu 3
Stopped at Debugger+0x9: leave
Debugger() at Debugger+0x9
x86_ipi_handler() at x86_ipi_handler+0x76
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
acpicpu_idle() at acpicpu_idle+0x13c
cpu_idle_cycle() at cpu_idle_cycle+0x10
end trace frame: 0x0, count: 6
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{3}> trace
Debugger() at Debugger+0x9
x86_ipi_handler() at x86_ipi_handler+0x76
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x1c
--- interrupt ---
acpicpu_idle() at acpicpu_idle+0x13c
cpu_idle_cycle() at cpu_idle_cycle+0x10
end trace frame: 0x0, count: -5
ddb{3}> mach ddbcpu 1
Stopped at Debugger+0x9: leave
Debugger() at Debugger+0x9
panic() at panic+0xfe
ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b
usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24
ugen_do_read() at ugen_do_read+0x43c
ugenread() at ugenread+0x48
spec_read() at spec_read+0x2c3
VOP_READ() at VOP_READ+0x3f
vn_read() at vn_read+0xa1
dofilereadv() at dofilereadv+0x204
end trace frame: 0x800032f23e50, count: 0
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{1}> ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
21818 21220 21818 1000 30x83 selectopensc-tool
21417 1 19487 0 30x81 selectpcscd
10601 1 19487 0 3 0x481 nanosleep pcscd
7889 1 19487 0 3 0x481 ugenripcscd
*17528 1 19487 0 7 0x401pcscd
21220 1 21220 1000 30x8b pause ksh
29910 2020 2020 0 30xb0 netio Xorg
2020190 2020 1000 30xb2 selectXorg
31599190 2020 1000 3 0x4b2 thrsleep Xorg
190 1190 0 30x80 poll slim
9250 1 9250 0 30x83 ttyin getty
28118 1 28118 0 30x83 ttyin getty
11978 1 11978 0 30x83 ttyin getty
2738 1 2738 0 30x83 ttyin getty
12234
Re: jail_bin_add: script to add binary and libs to chroot
On Tue, Jun 9, 2015 at 10:06 AM, Marc Espie wrote: > On Mon, Jun 08, 2015 at 03:37:27PM +0200, Landry Breuil wrote: >> On Mon, Jun 08, 2015 at 02:59:28PM +0200, Marc Espie wrote: >> > On Mon, Jun 08, 2015 at 01:46:17AM -0400, dan mclaughlin wrote: >> > > i figure this should be useful to some. >> > > any nits welcome. >> > >> > Unfortunately, this will become increasingly useless in >> > gtk-land. >> > >> > Compare ldd firefox vs a ktrace of the running binary... :( >> >> Totally pointless example - firefox is a very specific case, in that >> case you want ldd /usr/local/lib/firefox-*/libxul.so.* i dont know >> of many gtk applications doing this (bundling everything in a dlopen'ed >> library with tons of linking hacks to improve startup times...) > > I took firefox because it is the most blatant example, but Antoine told > me about it in general before I took a look at firefox. > Chrooting firefox is perfectly doable. I'm now using a chrooted firefox-esr as my primary browser. I've used dan's recipe as a starting point. Just be sure to copy all of the nss' shared libraries into the chroot: it took me a while to understand why firefox refused to work yelling at me about mysterious connectivity errors ;) Ciao! David
Re: freetype-2.6
On Sun, Jun 21, 2015 at 9:26 PM, Matthieu Herrb wrote: > On Sat, Jun 20, 2015 at 09:26:25PM +0200, David Coppa wrote: >> On Sat, Jun 20, 2015 at 12:24 PM, Matthieu Herrb wrote: >> > On Wed, Jun 17, 2015 at 04:34:15AM -0600, David Coppa wrote: >> >> >> >> Hi all, >> >> >> >> Here's an update to freetype-2.6 >> >> >> >> I'd like to have it in a ports bulk build. >> >> >> >> Already tested in a xenocara build: built successfully and it seems >> >> fine so far. >> >> >> > >> > Two nits: >> > >> > - from my analysis there were 2 public symbols removed from >> > libfreetype.so (ft_raccess_guess_table and ft_raster5_renderer_class) >> > so it should be a major shlib_version bump. >> >> Fixed, thanks >> >> > - the patches to the windows and wince build files failed because of >> > DOS style line separators that got mangled somehow. Be careful with >> > those when doing the actual commit. >> >> Probably the mail transfer. It applied correctly to my local tree. >> >> Here's the new diff gzipped, it should be safe. > > New diff applies cleanly. ok matthieu@ Thanks. Waiting for the bulk build's results...
Re: process stuck in a sched_yield() loop
On Sat, 09 May 2015, Philip Guenther wrote:
> Looks like the problem is that while one thread is calling vfork(),
> another thread does something that acquires the spinlock inside
> rthread_dl_lock() (probably another vfork). The child of the vfork tries
> to acquire the spinlock so that it can release the recursive lock itself
> and spins forever. The solution is to have the child reset that lock.
> I'm unable to reproduce after applying the diff below.
>
> oks?
>
With your diff applied, the test suite from latest libinotify-kqueue's
git snapshot (which was even more prone to hangs than libinotify-20141104
currently in our ports tree) also runs w/o problems.
Thanks a lot Philip!
David
> Index: rthread.c
> ===
> RCS file: /data/src/openbsd/src/lib/librthread/rthread.c,v
> retrieving revision 1.81
> diff -u -p -r1.81 rthread.c
> --- rthread.c 29 Apr 2015 06:01:37 - 1.81
> +++ rthread.c 9 May 2015 23:22:25 -
> @@ -671,8 +671,7 @@ _rthread_dl_lock(int what)
> static struct pthread_queue lockers = TAILQ_HEAD_INITIALIZER(lockers);
> static int count = 0;
>
> - if (what == 0)
> - {
> + if (what == 0) {
> pthread_t self = pthread_self();
>
> /* lock, possibly recursive */
> @@ -689,9 +688,7 @@ _rthread_dl_lock(int what)
> }
> count++;
> _spinunlock(&lock);
> - }
> - else
> - {
> + } else if (what == 1) {
> /* unlock, possibly recursive */
> if (--count == 0) {
> pthread_t next;
> @@ -704,6 +701,12 @@ _rthread_dl_lock(int what)
> if (next != NULL)
> __thrwakeup(next, 1);
> }
> + } else {
> + /* reinit: used in child after fork to clear the queue */
> + lock = _SPINLOCK_UNLOCKED_ASSIGN;
> + if (--count == 0)
> + owner = NULL;
> + TAILQ_INIT(&lockers);
> }
> }
>
> Index: rthread_fork.c
> ===
> RCS file: /data/src/openbsd/src/lib/librthread/rthread_fork.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 rthread_fork.c
> --- rthread_fork.c7 Apr 2015 01:27:07 - 1.11
> +++ rthread_fork.c9 May 2015 23:12:01 -
> @@ -105,12 +105,12 @@ _dofork(int is_vfork)
> _thread_malloc_unlock();
> _thread_atexit_unlock();
>
> + if (newid == 0) {
> #if defined(__ELF__)
> - if (_DYNAMIC)
> - _rthread_dl_lock(1);
> + /* reinitialize the lock in the child */
> + if (_DYNAMIC)
> + _rthread_dl_lock(2);
> #endif
> -
> - if (newid == 0) {
> /* update this thread's structure */
> me->tid = getthrid();
> me->donesem.lock = _SPINLOCK_UNLOCKED_ASSIGN;
> @@ -128,6 +128,10 @@ _dofork(int is_vfork)
> /* single threaded now */
> __isthreaded = 0;
> }
> +#if defined(__ELF__)
> + else if (_DYNAMIC)
> + _rthread_dl_lock(1);
> +#endif
> return newid;
> }
>
rev 1.37 of src/bin/cp/utils.c broke 'cp -p'
Hi, As found while running the git test-suite (for an upcoming update to git-2.4.0): $ cd sub $ rm -rf .git $ cp -R -P -p ../.git/modules/sub .git cp: chflags: .git/refs/heads: Invalid argument cp: chflags: .git/refs/tags: Invalid argument cp: chflags: .git/refs/remotes/origin: Invalid argument cp: chflags: .git/refs/remotes: Invalid argument cp: chflags: .git/refs: Invalid argument cp: chflags: .git/branches: Invalid argument cp: chflags: .git/hooks: Invalid argument cp: chflags: .git/info: Invalid argument cp: chflags: .git/objects/pack: Invalid argument cp: chflags: .git/objects/info: Invalid argument cp: chflags: .git/objects/87: Invalid argument cp: chflags: .git/objects/d0: Invalid argument cp: chflags: .git/objects/91: Invalid argument cp: chflags: .git/objects/b2: Invalid argument cp: chflags: .git/objects: Invalid argument cp: chflags: .git/logs/refs/remotes/origin: Invalid argument cp: chflags: .git/logs/refs/remotes: Invalid argument cp: chflags: .git/logs/refs/heads: Invalid argument cp: chflags: .git/logs/refs: Invalid argument cp: chflags: .git/logs: Invalid argument cp: chflags: .git/: Invalid argument Reverting to 1.36 makes cp work again as expected. Ciao! David
process stuck in a sched_yield() loop
Can somebody with the necessary skills help me with this?
$ cd /usr/ports/devel/libinotify/ && make clean fake && make test
I remember this used to work... Now, most of the times, the
'check_libinotify' process brings the CPU to 100% and it's stuck
in a sched_yield() loop:
31456/1022146 check_libinotify RET __thrwakeup 0
31456/1022569 check_libinotify RET __thrsleep 0
31456/1022146 check_libinotify CALL sigprocmask(SIG_BLOCK,0x8)
31456/1000130 check_libinotify CALL __thrwakeup(0x15cb19881800,1)
31456/1022569 check_libinotify CALL gettimeofday(0x15caa18674c0,0)
31456/1022146 check_libinotify RET sigprocmask 0<>
31456/1022569 check_libinotify STRU struct timeval { 1430986026<"May 7
10:07:06 2015">.729702 }
31456/1022146 check_libinotify CALL sigprocmask(SIG_BLOCK,~0<>)
31456/1000130 check_libinotify RET __thrwakeup 0
31456/1022569 check_libinotify RET gettimeofday 0
31456/1022146 check_libinotify RET sigprocmask 0x8
31456/1000130 check_libinotify CALL sigprocmask(SIG_BLOCK,0x8)
31456/1022569 check_libinotify CALL gettimeofday(0x15caa18674c0,0)
31456/1000130 check_libinotify RET sigprocmask 0<>
31456/1022569 check_libinotify STRU struct timeval { 1430986026<"May 7
10:07:06 2015">.729739 }
31456/1027161 check_libinotify RET __thrsleep 0
31456/1022146 check_libinotify CALL vfork()
31456/1000130 check_libinotify CALL
__thrsleep(0x15caad133000,CLOCK_REALTIME,0,0x15cac88bc640,0)
31456/1022569 check_libinotify RET gettimeofday 0
31456/1027161 check_libinotify CALL gettimeofday(0x15cb0aa9be50,0)
31456/1022569 check_libinotify CALL poll(0x15caa18675d0,1,2000)
31456/1027161 check_libinotify STRU struct timeval { 1430986026<"May 7
10:07:06 2015">.729760 }
31456/1027161 check_libinotify RET gettimeofday 0
2372/1002372 check_libinotify RET vfork 0
31456/1027161 check_libinotify CALL gettimeofday(0x15cb0aa9be50,0)
31456/1027161 check_libinotify STRU struct timeval { 1430986026<"May 7
10:07:06 2015">.730012 }
31456/1027161 check_libinotify RET gettimeofday 0
31456/1027161 check_libinotify CALL poll(0x15cb0aa9bf60,1,2000)
2372/1002372 check_libinotify CALL sigprocmask(SIG_SETMASK,0x8)
2372/1002372 check_libinotify RET sigprocmask ~0x10100
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotify CALL sched_yield()
2372/1002372 check_libinotify RET sched_yield 0
2372/1002372 check_libinotif
fix sndiod.1: 7680 vs 7860
Hi! Code says "7860": $ grep 7860 * sndiod.c:#define DEFAULT_BUFSZ 7860 While manpage says "7680": $ grep 7680 * sndiod.1:The default is 7680 or twice the block size Ciao, David Index: sndiod.1 === RCS file: /cvs/src/usr.bin/sndiod/sndiod.1,v retrieving revision 1.4 diff -u -p -u -p -r1.4 sndiod.1 --- sndiod.113 Aug 2014 08:42:46 - 1.4 +++ sndiod.124 Apr 2015 15:33:45 - @@ -140,7 +140,7 @@ The buffer size of the audio device in f A frame consists of one sample for each channel in the stream. This is the number of frames that will be buffered before being played and thus controls the playback latency. -The default is 7680 or twice the block size +The default is 7860 or twice the block size .Pq Fl z , if the block size is set. .It Xo
Re: [UPDATE] xcb-util-cursor-0.1.2
On Sat, 28 Mar 2015, Matthieu Herrb wrote: > On Fri, Mar 27, 2015 at 01:55:56PM +0100, David Coppa wrote: > > > > Minor update, no important stuff for us. > > > > Comments? > > > > Index: Makefile.in > > === > > RCS file: /cvs/xenocara/lib/xcb-util-cursor/Makefile.in,v > > retrieving revision 1.1.1.1 > > diff -u -p -u -p -r1.1.1.1 Makefile.in > > --- Makefile.in 14 Apr 2014 19:28:48 - 1.1.1.1 > > +++ Makefile.in 27 Mar 2015 12:51:21 - > > @@ -1,7 +1,7 @@ > > -# Makefile.in generated by automake 1.12.6 from Makefile.am. > > +# Makefile.in generated by automake 1.14.1 from Makefile.am. > > Hi, > > You have not regenrated the autotools files using the tools in ports. > > It may look pointless, but we have a number of patches to > automake/autoconf that are needed for some stuff. > So I prefer to always regenerate the build system with our tools (ie > env XENOCARA_RERUN_AUTOCONF=yes make -f Makefile.bsd-wrapper). Here's the diff with regenerated autotools files: Index: ChangeLog === RCS file: /cvs/xenocara/lib/xcb-util-cursor/ChangeLog,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 ChangeLog --- ChangeLog 14 Apr 2014 19:28:46 - 1.1.1.1 +++ ChangeLog 30 Mar 2015 06:02:54 - @@ -1,3 +1,51 @@ +commit 8eb844d39a06f42019dede515c70e7a0b155357d +Author: Michael Stapelberg +Date: Wed Mar 25 23:06:23 2015 +0100 + +set version to 0.1.2 + +commit cf26479ece9ab9e04616bc10ba674d88a284e5b0 +Author: Martin Grlin +Date: Tue Mar 17 18:41:07 2015 +0100 + +Perform safety check before trying to load glyph cursor + +The passed in cursor name to xcb_cursor_load_cursor might not match +one of the predefined font cursor values. Without the check the +call to create glyph cursor will fail with a BadValue error, but +the library returns the id allocated for the xcb_cursor_t. A user +of the library gets a value which looks like a valid cursor, but +when using it for e.g. a cursor value in xcb_create_window it raises +a BadCursor error. + +commit f03cc278c6cce0cf721adf9c3764d3c5fba63392 +Author: Jeremy Huddleston Sequoia +Date: Sat Apr 5 15:50:28 2014 -0700 + +darwin: Use OSByteOrder.h rather than CF. + +Signed-off-by: Jeremy Huddleston Sequoia + +commit a08bbf0e20995d29cbf890957c898059d4a9ece2 +Author: Niclas Zeising +Date: Mon Aug 12 13:53:10 2013 +0200 + +Check submodules before running autoconf. + +Exit early with an informative message if the submodules are missing, +since they are needed. Without this autoconf throws a bunch of +uninformative errors which does not point to the actual problem. +This was taken from util-keysyms. + +Signed-off-by: Niclas Zeising +Reviewed-By: Arnaud Fontaine + +commit d25806902ee6050ec3d52480d0bc8f4889942350 +Author: Marcus Crestani +Date: Mon Dec 23 23:30:04 2013 +0100 + +Use CFSwapInt32LittleToHost from CoreFoundation.h on Mac OS X to implement le32toh. + commit f557760c56ba4eb44063936d8fa49473532e21c6 Author: Michael Stapelberg Date: Tue Nov 12 21:47:50 2013 +0100 Index: INSTALL === RCS file: /cvs/xenocara/lib/xcb-util-cursor/INSTALL,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 INSTALL --- INSTALL 14 Apr 2014 19:28:45 - 1.1.1.1 +++ INSTALL 30 Mar 2015 06:02:56 - @@ -1,11 +1,13 @@ Installation Instructions * -Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005, -2006, 2007, 2008 Free Software Foundation, Inc. +Copyright (C) 1994-1996, 1999-2002, 2004-2011 Free Software Foundation, +Inc. - This file is free documentation; the Free Software Foundation gives -unlimited permission to copy, distribute and modify it. + Copying and distribution of this file, with or without modification, +are permitted in any medium without royalty provided the copyright +notice and this notice are preserved. This file is offered as-is, +without warranty of any kind. Basic Installation == @@ -13,7 +15,11 @@ Basic Installation Briefly, the shell commands `./configure; make; make install' should configure, build, and install this package. The following more-detailed instructions are generic; see the `README' file for -instructions specific to this package. +instructions specific to this package. Some packages provide this +`INSTALL' file but do not implement all of the features documented +below. The lack of an optional feature in a given package is not +necessarily a bug. More recommendations for GNU packages can be found +in *note Makefile Conventions: (standards)Makefile Conventions. The `configure&#x
Re: freetype vulns
Il giorno 10/mar/2015 20.48, "Ted Unangst" ha scritto: > > Boudewijn Dijkstra wrote: > > Op Sat, 07 Mar 2015 20:13:45 +0100 schreef David Coppa : > > > On Sat, Mar 7, 2015 at 7:28 PM, Ted Unangst wrote: > > > > > >> Or you could start with the linked Ubuntu advisory and try to discover where > > >> they hide the relevant patches. Heaven forbid they directly link to them, > > >> somebody might discover Ubuntu is based on open source software. > > > > > > Here are the patches Ubuntu ships with its freetype package > > > (downloaded from http://packages.ubuntu.com/). > > > They're at 2.5.2 as of now. > > > > > > $ tar tzf patches-freetype.tar.gz > > > [...] > > > > $ cat patches-freetype/*.patch patches-freetype/*/*.patch|wc > > 5301 23118 190131 > > > > Not much larger than the xserver patch. > > OK. So we've got a list of patch filenames. And a line count. I feel we're > getting really close to seeing an actual patch that applies to OpenBSD... :) > > As my senior scrumm lord used to say in our stand up meetings, > Let's drive this thing home! > Tomorrow...
Re: freetype vulns
On Sat, Mar 7, 2015 at 7:28 PM, Ted Unangst wrote: > Or you could start with the linked Ubuntu advisory and try to discover where > they hide the relevant patches. Heaven forbid they directly link to them, > somebody might discover Ubuntu is based on open source software. Here are the patches Ubuntu ships with its freetype package (downloaded from http://packages.ubuntu.com/). They're at 2.5.2 as of now. Ciao, David $ tar tzf patches-freetype.tar.gz patches-freetype/ patches-freetype/freetype-2.1.7-backwards.compat.patch patches-freetype/CVE-2014-96xx/ patches-freetype/CVE-2014-96xx/CVE-2014-9670-2.patch patches-freetype/CVE-2014-96xx/CVE-2014-9660.patch patches-freetype/CVE-2014-96xx/CVE-2014-9665-1.patch patches-freetype/CVE-2014-96xx/CVE-2014-9663.patch patches-freetype/CVE-2014-96xx/CVE-2014-9659-1.patch patches-freetype/CVE-2014-96xx/CVE-2014-9664-2.patch patches-freetype/CVE-2014-96xx/CVE-2014-9657.patch patches-freetype/CVE-2014-96xx/CVE-2014-9666.patch patches-freetype/CVE-2014-96xx/CVE-2014-9662.patch patches-freetype/CVE-2014-96xx/CVE-2014-9659-2.patch patches-freetype/CVE-2014-96xx/CVE-2014-9671-2.patch patches-freetype/CVE-2014-96xx/CVE-2014-9670-1.patch patches-freetype/CVE-2014-96xx/CVE-2014-9675-1.patch patches-freetype/CVE-2014-96xx/CVE-2014-9674-1.patch patches-freetype/CVE-2014-96xx/CVE-2014-9658.patch patches-freetype/CVE-2014-96xx/CVE-2014-9665-2.patch patches-freetype/CVE-2014-96xx/CVE-2014-9664-1.patch patches-freetype/CVE-2014-96xx/CVE-2014-9674-4.patch patches-freetype/CVE-2014-96xx/CVE-2014-9671-3.patch patches-freetype/CVE-2014-96xx/CVE-2014-9661-2.patch patches-freetype/CVE-2014-96xx/CVE-2014-9656.patch patches-freetype/CVE-2014-96xx/CVE-2014-9669.patch patches-freetype/CVE-2014-96xx/CVE-2014-9675-2.patch patches-freetype/CVE-2014-96xx/CVE-2014-9671-1.patch patches-freetype/CVE-2014-96xx/CVE-2014-9673.patch patches-freetype/CVE-2014-96xx/CVE-2014-9674-2.patch patches-freetype/CVE-2014-96xx/CVE-2014-9667.patch patches-freetype/CVE-2014-96xx/CVE-2014-9674-3.patch patches-freetype/CVE-2014-96xx/CVE-2014-9668.patch patches-freetype/CVE-2014-96xx/CVE-2014-9672.patch patches-freetype/CVE-2014-96xx/CVE-2014-9661-1.patch patches-freetype/series patches-freetype/enable-old-cff.patch patches-freetype/no-uninitialized-bbox.patch patches-freetype/enable-gxvalid-otvalid.patch patches-freetype/CVE-2014-2240.patch patches-freetype/freetype-config.diff patches-freetype/revert_scalable_fonts_metric.patch patches-freetype/enable-subpixel-rendering.patch patches-freetype/CVE-2014-2241.patch patches-freetype/0002-Fix-Savannah-bug-42418.patch patches-freetype/verbose-libtool.patch patches-freetype/0001-Fix-Savannah-bug-40997.patch patches-freetype/multi-thread-violations.patch patches-freetype.tar.gz Description: GNU Zip compressed data
Re: libpcap monitor_mode() handle s/EINVAL/ENOTTY/ for unknown ioctls
On Fri, Feb 13, 2015 at 6:19 PM, Stuart Henderson wrote: > In sys/net/if_media.c r1.19 (2007/12/20) the return code for unknown > ioctl requests was changed from EINVAL to ENOTTY. > > libpcap uses a SIOCGIFMEDIA to determine whether an interface can use > rfmon mode; this change breaks this. Noticed because wireshark doesn't > identify the correct DLT for interfaces (like pflog0 or lo0) which > don't support this ioctl. > > Diff below allows libpcap to accept either EINVAL or ENOTTY as "can't > lookup capabilities so just say the device doesn't support it". It might > be appropriate to just replace the existing EINVAL case but I thought > this would be safer for now (in case some interface does have a specific > handler for SIOCGIFMEDIA which returns EINVAL). > > OK? Yes, ok with me. ciao, David
Re: OK... how dare you both even to not publish patches...
On Tue, Feb 10, 2015 at 5:05 AM, Ted Unangst wrote: > Sebastian's emails don't make it to the list, but in the interest of > transparency and not hiding any secrets about OpenBSD's security, I'm > forwarding it along as requested. Uff. Another one who forgot to get his meds... Ciao! David > Sebastian Rother wrote:
handle hibernate button in the same way as suspend does
Hi,
Currently, when you hibernate your thinkpad using the hibernate
button (Fn+F12), /etc/apm/hibernate does not get executed. It is
only when you hibernate using 'ZZZ'.
The diff below makes the hibernate button behave like the suspend
one.
I have chosen 0x000D as the value for APM_USER_HIBERNATE_REQ: is
it right? If it's not please suggest a valid alternative.
Cheers!
David
Index: sys/arch/amd64/include/apmvar.h
===
RCS file: /cvs/src/sys/arch/amd64/include/apmvar.h,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 apmvar.h
--- sys/arch/amd64/include/apmvar.h 8 Jul 2012 18:02:45 - 1.5
+++ sys/arch/amd64/include/apmvar.h 4 Feb 2015 10:35:22 -
@@ -172,6 +172,7 @@
#defineAPM_USER_SUSPEND_REQ0x000A
#defineAPM_SYS_STANDBY_RESUME 0x000B
#defineAPM_CAPABILITY_CHANGE 0x000C /* apm v1.2 */
+#defineAPM_USER_HIBERNATE_REQ 0x000D
/* 0x000d - 0x00ff Reserved system events */
/* 0x0100 - 0x01ff Reserved device events */
/* 0x0200 - 0x02ff OEM-defined APM events */
Index: sys/arch/i386/include/apmvar.h
===
RCS file: /cvs/src/sys/arch/i386/include/apmvar.h,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 apmvar.h
--- sys/arch/i386/include/apmvar.h 8 Jul 2012 18:02:45 - 1.19
+++ sys/arch/i386/include/apmvar.h 4 Feb 2015 10:35:22 -
@@ -171,6 +171,7 @@
#defineAPM_USER_SUSPEND_REQ0x000A
#defineAPM_SYS_STANDBY_RESUME 0x000B
#defineAPM_CAPABILITY_CHANGE 0x000C /* apm v1.2 */
+#defineAPM_USER_HIBERNATE_REQ 0x000D
/* 0x000d - 0x00ff Reserved system events */
/* 0x0100 - 0x01ff Reserved device events */
/* 0x0200 - 0x02ff OEM-defined APM events */
Index: sys/dev/acpi/acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.42
diff -u -p -u -p -r1.42 acpithinkpad.c
--- sys/dev/acpi/acpithinkpad.c 13 Dec 2014 05:29:50 - 1.42
+++ sys/dev/acpi/acpithinkpad.c 4 Feb 2015 10:35:22 -
@@ -347,8 +347,9 @@ thinkpad_hotkey(struct aml_node *node, i
break;
case THINKPAD_BUTTON_HIBERNATE:
#if defined(HIBERNATE) && !defined(SMALL_KERNEL)
- acpi_addtask(sc->sc_acpi, acpi_sleep_task,
- sc->sc_acpi, ACPI_STATE_S4);
+ if (acpi_record_event(sc->sc_acpi,
APM_USER_HIBERNATE_REQ))
+ acpi_addtask(sc->sc_acpi, acpi_sleep_task,
+ sc->sc_acpi, ACPI_STATE_S4);
#endif
handled = 1;
break;
Index: usr.sbin/apmd/apmd.c
===
RCS file: /cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.74
diff -u -p -u -p -r1.74 apmd.c
--- usr.sbin/apmd/apmd.c16 Jan 2015 06:40:15 - 1.74
+++ usr.sbin/apmd/apmd.c4 Feb 2015 10:35:23 -
@@ -348,7 +348,7 @@ int
main(int argc, char *argv[])
{
const char *fname = apmdev;
- int ctl_fd, sock_fd, ch, suspends, standbys, resumes;
+ int ctl_fd, sock_fd, ch, suspends, standbys, hibernates, resumes;
int statonly = 0;
int powerstatus = 0, powerbak = 0, powerchange = 0;
int noacsleep = 0;
@@ -487,7 +487,7 @@ main(int argc, char *argv[])
continue;
if (ev->ident == ctl_fd) {
- suspends = standbys = resumes = 0;
+ suspends = standbys = hibernates = resumes = 0;
syslog(LOG_DEBUG, "apmevent %04x index %d",
(int)APM_EVENT_TYPE(ev->data),
(int)APM_EVENT_INDEX(ev->data));
@@ -503,6 +503,9 @@ main(int argc, char *argv[])
case APM_STANDBY_REQ:
standbys++;
break;
+ case APM_USER_HIBERNATE_REQ:
+ hibernates++;
+ break;
#if 0
case APM_CANCEL:
suspends = standbys = 0;
@@ -536,6 +539,8 @@ main(int argc, char *argv[])
suspend(ctl_fd);
else if (standbys)
stand_by(ctl_fd);
+ else if (hibernates)
+ hibernate(ctl_fd);
else if (resumes) {
do_etc_file(_PATH_APM_ETC_RESUME);
syslog(LOG_NOTICE,
Unbreak !HIBERNATE builds (amd64)
ok? Ciao, David Index: arch/amd64/amd64/acpi_wakecode.S === RCS file: /cvs/src/sys/arch/amd64/amd64/acpi_wakecode.S,v retrieving revision 1.35 diff -u -p -u -p -r1.35 acpi_wakecode.S --- arch/amd64/amd64/acpi_wakecode.S8 Dec 2014 07:12:37 - 1.35 +++ arch/amd64/amd64/acpi_wakecode.S3 Feb 2015 10:32:43 - @@ -627,12 +627,14 @@ _ACPI_TRMP_DATA_LABEL(acpi_saved_sfmask) .align 4 _ACPI_TRMP_DATA_LABEL(acpi_pdirpa) .long 0 +#ifdef HIBERNATE _ACPI_TRMP_DATA_LABEL(hibernate_indirect_16) .long hibernate_resume_vector_3 .word 0x18 _ACPI_TRMP_DATA_LABEL(hibernate_indirect_16b) .long hibernate_resume_vector_3b .word 0x18 +#endif /* HIBERNATE */ _C_LABEL(acpi_tramp_data_end):
Re: correct spelling of center
On Tue, Jan 20, 2015 at 10:35 AM, Jason McIntyre wrote: > also for the record this would be an instance of preferring US spelling > over UK (er, French even). centre vs center, colour vs color, armour vs armor, and so on... And, btw, gmail's integrated spell checker marks centre, colour, and armour as errors: damn yankees! ;)
Re: ASLR bypass on OpenBSD-5.6
On Wed, Jan 14, 2015 at 5:52 PM, Theo de Raadt wrote: > And what breaks? > > Did you do an assessment? > > Hypothetically, if we do this and it improves security but breaks > mplayer or firefox and people are forced to run some other system > instead, is it then a security improvement? Indeed. On a Linux machine of mine, I've tried booting a grsecurity patched kernel (v3.18.2). First, enabling Grsecurity/PaX options automatically disables HIBERNATE support, thus hibernation is no more possible. Second, I've tried booting with it and the KDE desktop blew up with a lot of segfaults :( I have no polemic intentions, I just wanted to report some facts... Ciao! David
Re: ftp proxy host header
On Mon, Jan 12, 2015 at 1:39 PM, Stuart Henderson wrote: > On 2015/01/12 12:35, Alexander Bluhm wrote: >> Hi, >> >> Fetching port distfiles with ftp from githup does not work when >> using a https proxy. The problem is that the http Host header is >> not not set and githup.com needs that. >> >> So remember the host form the url and write it into the http request. >> Also write the http request into the debugging output to see what >> is going on. >> >> Note that using Proxy-Authorization together with Cookie did not >> work. I have fixed the format string. >> >> ok? > > Definitely! This also fixes a long-standing problem using HTTP over > proxy servers that cannot reconstruct a Host: header from the supplied > URL (IIRC mikeb ran into a problem with this with an old work proxy). > for example when using cntlm (I suspect...) Thanks! David
Re: freetype-2.5.5
On Wed, Jan 7, 2015 at 9:54 AM, David Coppa wrote: > > An update to freetype-2.5.5. > > They were faster this time! > > Btw, it's a bugfixing update so I think we do not need another bulk > build... > > I didn't see significant API/ABI changes and abi-compliance-checker > also reports 2.5.4_to_2.5.5 as Compatible. No comment? ciao, David freetype-2.5.5.diff.gz Description: GNU Zip compressed data
Re: update rxvt-unicode terminfo entry
On Wed, Jan 7, 2015 at 2:20 PM, Nicholas Marriott wrote: > This diff looks big but in fact there are only three changes, cnorm, > cvvis and sgr. Indeed. As usual I've used: $ sudo TERMINFO=/usr/share/terminfo tic -x rxvt-unicode.terminfo $ infocmp rxvt-unicode Don't know why it shuffled things around...
update rxvt-unicode terminfo entry
Keep it in sync with rxvt-unicode-9.21.
ok?
Ciao,
David
Index: termtypes.master
===
RCS file: /cvs/src/share/termtypes/termtypes.master,v
retrieving revision 1.50
diff -u -p -u -p -r1.50 termtypes.master
--- termtypes.master17 Sep 2014 15:35:25 - 1.50
+++ termtypes.master7 Jan 2015 09:17:31 -
@@ -5015,50 +5015,51 @@ rxvt-16color|xterm with 16 colors like a
# Updated: Oezguer Kesim 02 Nov 1997
# Updated: Marc Lehmann , 17 Feb 2005
# Updated: Marc Lehmann , 04 Nov 2008: change init/reset
sequences
+# Updated: Marc Lehmann , 24 Nov 2014: implement cvvis as
blinking cursor
+# Updated: Marc Lehmann , 13 Dec 2014: removed superfluous
0 from sgr
rxvt-unicode|rxvt-unicode terminal (X Window System),
- bw, am, bce, ccc, xenl, eo, km, hs, mir, msgr, npc, mc5i, xon,
- btns#5, cols#80, it#8, lines#24, lm#0, colors#88, pairs#7744,
- ncv#0,
+ am, bce, bw, ccc, eo, hs, km, mc5i, mir, msgr, npc, xenl, xon,
+ btns#5, colors#88, cols#80, it#8, lines#24, lm#0, ncv#0,
+ pairs#7744,
acsc=+C\,D-A.B0E``aaffgghFiGjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
- bel=^G, cr=^M, csr=\E[%i%p1%d;%p2%dr, tbc=\E[3g,
- clear=\E[H\E[2J, el1=\E[1K, el=\E[K, ed=\E[J,
- hpa=\E[%i%p1%dG, cup=\E[%i%p1%d;%p2%dH, cud1=^J,
- home=\E[H, civis=\E[?25l, cub1=^H, cnorm=\E[?25h,
- cuf1=\E[C, cuu1=\E[A, cvvis=\E[?25h, dch1=\E[P, dl1=\E[M,
- dsl=\E]2;\007, enacs=, smacs=\E(0, smam=\E[?7h,
- blink=\E[5m, bold=\E[1m, smcup=\E[?1049h, smir=\E[4h,
- sitm=\E[3m, rev=\E[7m, smso=\E[7m, smul=\E[4m,
- ech=\E[%p1%dX, rmacs=\E(B, rmam=\E[?7l, sgr0=\E[m\E(B,
- rmcup=\E[r\E[?1049l, rmir=\E[4l, ritm=\E[23m,
- rmso=\E[27m, rmul=\E[24m, flash=\E[?5h$<20/>\E[?5l,
- fsl=^G, is1=\E[!p,
- is2=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
+ dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
+ el1=\E[1K, enacs=, flash=\E[?5h$<20/>\E[?5l, fsl=^G,
+ home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
+ ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
initc=\E]4;%p1%d;rgb\:%p2%{65535}%*%{1000}%/%4.4X/%p3%{65535}%*%{1000}%/%4.4X/%p4%{65535}%*%{1000}%/%4.4X\E\\,
- ich1=\E[@, il1=\E[L, ka1=\EOw, ka3=\EOy, kb2=\EOu, kbs=\177,
- kcbt=\E[Z, kc1=\EOq, kc3=\EOs, kdch1=\E[3~, kcud1=\E[B,
- kend=\E[8~, kent=\EOM, kel=\E[8\^, kf1=\E[11~, kf10=\E[21~,
- kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
- kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~,
- kf19=\E[33~, kf2=\E[12~, kf20=\E[34~, kf3=\E[13~,
- kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
- kf9=\E[20~, kfnd=\E[1~, khome=\E[7~, kich1=\E[2~,
- kcub1=\E[D, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kcuf1=\E[C,
- kDC=\E[3$, kslt=\E[4~, kEND=\E[8$, kHOM=\E[7$, kIC=\E[2$,
- kLFT=\E[d, kNXT=\E[6$, kPRV=\E[5$, kRIT=\E[c, kcuu1=\E[A,
- rmkx=\E>, smkx=\E=, op=\E[39;49m, dch=\E[%p1%dP,
- dl=\E[%p1%dM, cud=\E[%p1%dB, ich=\E[%p1%d@,
- indn=\E[%p1%dS, il=\E[%p1%dL, cub=\E[%p1%dD,
- cuf=\E[%p1%dC, rin=\E[%p1%dT, cuu=\E[%p1%dA, mc0=\E[i,
- mc4=\E[4i, mc5=\E[5i, rs1=\Ec,
+ is1=\E[!p,
+ is2=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
+ kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kIC=\E[2$, kLFT=\E[d,
+ kNXT=\E[6$, kPRV=\E[5$, kRIT=\E[c, ka1=\EOw, ka3=\EOy,
+ kb2=\EOu, kbs=\177, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[3~, kel=\E[8\^, kend=\E[8~, kent=\EOM, kf1=\E[11~,
+ kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
+ kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
+ kf18=\E[32~, kf19=\E[33~, kf2=\E[12~, kf20=\E[34~,
+ kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
+ kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
+ kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~,
+ mc0=\E[i, mc4=\E[4i, mc5=\E[5i, op=\E[39;49m, rc=\E8,
+ rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
+ rmam=\E[?7l, rmcup=\E[r\E[?1049l, rmir=\E[4l, rmkx=\E>,
+ rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
rs2=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
- rc=\E8, vpa=\E[%i%p1%dd, sc=\E7, ind=^J, ri=\EM, s0ds=\E(B,
- s1ds=\E(0, s2ds=\E*B, s3ds=\E+B, setab=\E[48;5;%p1%dm,
- setaf=\E[38;5;%p1%dm,
-
sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;,
+ s0ds=\E(B, s1ds=\E(0,
/etc/rc: remove "RC4" in a comment
Hi!
RC4 is no more. It's better to be more generic.
comments / oks ?
Ciao,
David
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.444
diff -u -p -u -p -r1.444 rc
--- rc 17 Nov 2014 18:19:08 - 1.444
+++ rc 29 Nov 2014 18:54:54 -
@@ -359,7 +359,7 @@ if [ -f /etc/resolv.conf.save ]; then
touch /etc/resolv.conf
fi
sh /etc/netstart
-dmesg > /dev/random# any write triggers an RC4 rekey
+dmesg > /dev/random# any write triggers a rekey
if [ X"${pf}" != X"NO" ]; then
if [ -f ${pf_rules} ]; then
Re: Atheros UB94 Diff Files
On Fri, Oct 31, 2014 at 8:42 PM, Mike Larkin wrote:
> On Fri, Oct 31, 2014 at 03:36:50PM -0400, Ted Unangst wrote:
>> On Fri, Oct 31, 2014 at 10:24, Matt Markfort wrote:
>> > I have made these recent changes to my personal code base of the
>> > OpenBSD_5_4-release kernel, and it may be useful to commit to -current.
>> >
>> > I found the information here for the ATHEROS UB94 USB 802.11a/b/g/n
>> > adapter, and I have tested it with my system.
>> >
>> > http://wireless.kernel.org/en/users/Drivers/ath9k_htc#Chipsets_supported
>> >
>> > Please reply with any pertinent comments.
>>
>> Inline patches are preferred, as below.
>>
>> Otherwise, pretty simple. Looks alright to me. (usbdevs.h will be
>> regenerated after usbdevs changes.)
>>
>> --- /var/tmp/src/sys/dev/usb/usbdevs.hSun Jul 21 11:48:13 2013
>> +++ /usr/src/sys/dev/usb/usbdevs.hThu Oct 30 21:26:03 2014
>> @@ -3115,6 +3115,7 @@
>> #define USB_PRODUCT_PANASONIC_LS120 0x0901 /* LS-120 */
>> #define USB_PRODUCT_PANASONIC_SDCAAE0x1b00 /*
>> MultiMediaCard */
>> #define USB_PRODUCT_PANASONIC_TYTP50P6S 0x3900 /* TY-TP50P6-S
>> 50in Touch Panel */
>> +#define USB_PRODUCT_PANASONIC_N5HBZ055 0x3904 /* N5HBZ055
>> AR7010+AR9280 USB (UB94) */
>>
>
> Probably want to wrap that line for KNF.
>
>> /* Papouch products */
>> #define USB_PRODUCT_PAPOUCH_SB485_1 0x0100 /* SB485
>> USB-485/422 */
>>
>> --- /var/tmp/src/sys/dev/usb/usbdevs Sun Jul 21 11:48:13 2013
>> +++ /usr/src/sys/dev/usb/usbdevs Thu Oct 30 21:15:17 2014
>> @@ -3108,6 +3108,7 @@
>> product PANASONIC LS120 0x0901 LS-120
>> product PANASONIC SDCAAE 0x1b00 MultiMediaCard
>> product PANASONIC TYTP50P6S 0x3900 TY-TP50P6-S 50in Touch Panel
>> +product PANASONIC N5HBZ055 0x3904 UB94
>>
>> /* Papouch products */
>> product PAPOUCH SB485_1 0x0100 SB485 USB-485/422
>>
>>
>> --- /var/tmp/src/sys/dev/usb/if_athn_usb.cSun Jul 7 11:22:36 2013
>> +++ /usr/src/sys/dev/usb/if_athn_usb.cThu Oct 30 21:35:48 2014
>> @@ -80,6 +80,8 @@
>> ATHN_USB_FLAG_AR7010 },
>> {{ USB_VENDOR_ATHEROS2, USB_PRODUCT_ATHEROS2_AR9287 },
>> ATHN_USB_FLAG_AR7010 },
>> + {{ USB_VENDOR_PANASONIC, USB_PRODUCT_PANASONIC_N5HBZ055 },
>> +ATHN_USB_FLAG_AR7010 },
>> {{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_AR9271_1 }},
>> {{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_AR9271_2 }},
>> {{ USB_VENDOR_AZUREWAVE, USB_PRODUCT_AZUREWAVE_AR9271_3 }},
>>
And please keep the entries sorted alphabetically.
other than that, it's ok with me.
Ciao!
David
--
"If you try a few times and give up, you'll never get there. But if
you keep at it... There's a lot of problems in the world which can
really be solved by applying two or three times the persistence that
other people will."
-- Stewart Nelson
apmd: remove useless defines
Remove now useless defines. ok? Index: apmd.c === RCS file: /cvs/src/usr.sbin/apmd/apmd.c,v retrieving revision 1.72 diff -u -p -u -p -r1.72 apmd.c --- apmd.c 26 Oct 2014 22:16:16 - 1.72 +++ apmd.c 27 Oct 2014 08:27:00 - @@ -61,11 +61,6 @@ const char sockfile[] = _PATH_APM_SOCKET int debug = 0; int doperf = PERF_NONE; -#define PERFDEC 20 -#define PERFMIN 0 -#define PERFMAX 100 -#define PERFINCTHRES 50 -#define PERFDECTHRES 60 extern char *__progname;
Re: mention lkm removal on current.html
On Mon, Oct 13, 2014 at 3:22 PM, Stuart Henderson wrote: > On 2014/10/13 14:56, Theo Buehler wrote: >> Here's a shot at removing the binaries and manuals that are obsolete >> after the lkm removal. I hope I caught them all. > > Thanks, committed. > >> There remains the user _lkm in /etc/groups. I am unsure how to remove that >> one properly. groupdel _lkm ? Ciao, David -- "If you try a few times and give up, you'll never get there. But if you keep at it... There's a lot of problems in the world which can really be solved by applying two or three times the persistence that other people will." -- Stewart Nelson
hibernate button and !HIBERNATE kernels
Hi! When running a kernel built without "option HIBERNATE", if I press the hibernate button (Fn+F12) on my ThinkPad T420, the system abruptly shuts down and I'm welcomed by fsck on the next boot. What about the following diff? Index: dev/acpi/acpithinkpad.c === RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v retrieving revision 1.40 diff -u -p -u -p -r1.40 acpithinkpad.c --- dev/acpi/acpithinkpad.c 7 Oct 2014 11:28:59 - 1.40 +++ dev/acpi/acpithinkpad.c 8 Oct 2014 07:14:06 - @@ -345,7 +345,7 @@ thinkpad_hotkey(struct aml_node *node, i handled = 1; break; case THINKPAD_BUTTON_HIBERNATE: -#ifndef SMALL_KERNEL +#if defined(HIBERNATE) && !defined(SMALL_KERNEL) acpi_addtask(sc->sc_acpi, acpi_sleep_task, sc->sc_acpi, ACPI_STATE_S4); #endif
Re: PATCH: fix iwn(4) scan hangs
On Wed, Sep 10, 2014 at 3:02 PM, Stuart Henderson wrote: > On 2014/09/10 14:42, Marcin Piotr Pawlowski wrote: >> Yes, I think that it could be is possible to double clean the node cache. >> >> Updated diff with suggestion from Stefan. > > Only tested lightly so far, but this seems to be working nicely for me, > thanks Marcin. Works fine here too. Ok dcoppa@ fwiw
Re: apmd hangs
On Tue, Sep 9, 2014 at 7:58 PM, Ingo Schwarze wrote: > Hi David, > > David Coppa wrote on Tue, Sep 09, 2014 at 07:44:47PM +0200: >> On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze wrote: > >>> i'm sorry to say it makes no difference for me (i'm not opposed to the >>> diff, though). >>> >>> On my laptop, building ports works fine, running firefox works fine, >>> but whenever i surf the web with firefox while building ports, >>> the machine locks up hard. Sometimes, the lockup already happens >>> when merely starting firefox while building ports. Often, it >>> happens not when requesting a new URI, but when merely scrolling >>> within the page in firefox. >>> >>> After the lockup, CapsLk and NmLk still toggle the respective LEDs, >>> Fn-PgUp still switches on and off the torch, but nothing else has >>> any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace >>> or Ctrl-Alt-F1. >>> >>> Unfortunately, i cannot break into ddb because i don't have a >>> docking station, hence no serial console, and when going to the >>> PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0, >>> and starting firefox from the console, i was unable to get any >>> lockup. Apparently, it only happens when X (or whatever) is >>> actually painting something onto the screen. >>> >>> Whether i run with the defaults or with apm -A doesn't appear to >>> make a difference. > >> I'm a bit confused... Is this hang happening without apmd running? > > Yes. That doesn't make a difference, either. > > Usually, i run with apmd in default mode: > > ischwarze@isnote $ grep apm /etc/rc.conf.local > apmd_flags="" > > But with apmd_flags="-A" or apmd_flags=NO the hangs happen in > exactly the same way. So I'm with Mark here, I also think your hang is unrelated to this diff. ciao! David
Re: apmd hangs
On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze wrote: > i'm sorry to say it makes no difference for me (i'm not opposed to the > diff, though). > > On my laptop, building ports works fine, running firefox works fine, > but whenever i surf the web with firefox while building ports, > the machine locks up hard. Sometimes, the lockup already happens > when merely starting firefox while building ports. Often, it > happens not when requesting a new URI, but when merely scrolling > within the page in firefox. > > After the lockup, CapsLk and NmLk still toggle the respective LEDs, > Fn-PgUp still switches on and off the torch, but nothing else has > any effect, not even Ctrl-Alt-Esc, Ctrl-Alt-Delete, Ctrl-Alt-Backspace > or Ctrl-Alt-F1. > > Unfortunately, i cannot break into ddb because i don't have a > docking station, hence no serial console, and when going to the > PC virtual console (Ctrl-Alt-F1), setting export DISPLAY=:0, > and starting firefox from the console, i was unable to get any > lockup. Apparently, it only happens when X (or whatever) is > actually painting something onto the screen. > > Whether i run with the defaults or with apm -A doesn't appear to > make a difference. I'm a bit confused... Is this hang happening without apmd running?
Re: PATCH: fix iwn(4) scan hangs
On Tue, Sep 9, 2014 at 5:29 PM, Fabian Raetz wrote:
> On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote:
>> Hi,
>>
>> below is a patch for iwn(4) which hopefully fixes a problem where iwn(4)
>> does not return from a scan, if the interface is up.
>
> here's an updated version which does not
> set hdr->max_svc / hdr->pause_svc.
>
> Cristoph Zimmermann noticed that scan requests return no APs on his
> device (thanks for testing).
> iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO
> 1T2R, MoW, address 00:21:6b:a3:70:7a
>
> As Piotr and Mike tested the patch from Piotr which does not set this
> values either and it still works on my card, this should the way to go
> for now.
Little inaccuracy:
While comments talk about IWL_GOOD_CRC_TH_NEVER,
IWL_GOOD_CRC_TH_DISABLED, these are IWN_GOOD_CRC_TH_NEVER,
IWN_GOOD_CRC_TH_DISABLED in the code, so comments should be amended
accordingly...
Ciao!
David
>
> Index: if_iwn.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
> retrieving revision 1.133
> diff -u -p -r1.133 if_iwn.c
> --- if_iwn.c22 Jul 2014 13:12:11 - 1.133
> +++ if_iwn.c9 Sep 2014 14:57:34 -
> @@ -220,6 +220,9 @@ int iwn_send_btcoex(struct iwn_softc *)
> intiwn_send_advanced_btcoex(struct iwn_softc *);
> intiwn5000_runtime_calib(struct iwn_softc *);
> intiwn_config(struct iwn_softc *);
> +uint16_t iwn_get_active_dwell_time(struct iwn_softc *, uint16_t,
> uint8_t);
> +uint16_t iwn_limit_dwell(struct iwn_softc *, uint16_t);
> +uint16_t iwn_get_passive_dwell_time(struct iwn_softc *, uint16_t);
> intiwn_scan(struct iwn_softc *, uint16_t);
> intiwn_auth(struct iwn_softc *);
> intiwn_run(struct iwn_softc *);
> @@ -4424,6 +4427,66 @@ iwn_config(struct iwn_softc *sc)
> return 0;
> }
>
> +uint16_t
> +iwn_get_active_dwell_time(struct iwn_softc *sc,
> +uint16_t flags, uint8_t n_probes)
> +{
> + /* No channel? Default to 2GHz settings */
> + if (flags & IEEE80211_CHAN_2GHZ) {
> + return (IWN_ACTIVE_DWELL_TIME_2GHZ +
> + IWN_ACTIVE_DWELL_FACTOR_2GHZ * (n_probes + 1));
> + }
> +
> + /* 5GHz dwell time */
> + return (IWN_ACTIVE_DWELL_TIME_5GHZ +
> + IWN_ACTIVE_DWELL_FACTOR_5GHZ * (n_probes + 1));
> +}
> +
> +/*
> + * Limit the total dwell time to 85% of the beacon interval.
> + *
> + * Returns the dwell time in milliseconds.
> + */
> +uint16_t
> +iwn_limit_dwell(struct iwn_softc *sc, uint16_t dwell_time)
> +{
> + struct ieee80211com *ic = &sc->sc_ic;
> + struct ieee80211_node *ni = ic->ic_bss;
> + int bintval = 0;
> +
> + /* bintval is in TU (1.024mS) */
> + if (ni != NULL)
> + bintval = ni->ni_intval;
> +
> + /*
> +* If it's non-zero, we should calculate the minimum of
> +* it and the DWELL_BASE.
> +*
> +* XXX Yes, the math should take into account that bintval
> +* is 1.024mS, not 1mS..
> +*/
> + if (bintval > 0) {
> + return (MIN(IWN_PASSIVE_DWELL_BASE, ((bintval * 85) / 100)));
> + }
> +
> + /* No association context? Default */
> + return (IWN_PASSIVE_DWELL_BASE);
> +}
> +
> +uint16_t
> +iwn_get_passive_dwell_time(struct iwn_softc *sc, uint16_t flags)
> +{
> + uint16_t passive;
> + if (flags & IEEE80211_CHAN_2GHZ) {
> + passive = IWN_PASSIVE_DWELL_BASE +
> IWN_PASSIVE_DWELL_TIME_2GHZ;
> + } else {
> + passive = IWN_PASSIVE_DWELL_BASE +
> IWN_PASSIVE_DWELL_TIME_5GHZ;
> + }
> +
> + /* Clamp to the beacon interval if we're associated */
> + return (iwn_limit_dwell(sc, passive));
> +}
> +
> int
> iwn_scan(struct iwn_softc *sc, uint16_t flags)
> {
> @@ -4436,9 +4499,9 @@ iwn_scan(struct iwn_softc *sc, uint16_t
> struct ieee80211_rateset *rs;
> struct ieee80211_channel *c;
> uint8_t *buf, *frm;
> - uint16_t rxchain;
> + uint16_t rxchain, dwell_active, dwell_passive;
> uint8_t txant;
> - int buflen, error;
> + int buflen, error, is_active;
>
> buf = malloc(IWN_SCAN_MAXSZ, M_DEVBUF, M_NOWAIT | M_ZERO);
> if (buf == NULL) {
> @@ -4474,7 +4537,6 @@ iwn_scan(struct iwn_softc *sc, uint16_t
> tx->lifetime = htole32(IWN_LIFETIME_INFINITE);
>
> if (flags & IEEE80211_CHAN_5GHZ) {
> - hdr->crc_threshold = 0x;
> /* Send probe requests at 6Mbps. */
> tx->plcp = iwn_rates[IWN_RIDX_OFDM6].plcp;
> rs = &ic->ic_sup_rates[IEEE80211_MODE_11A];
> @@ -4488,12 +4550,23 @@ iwn_scan(struct iwn_softc *sc, uint16_t
> /* Use the first valid TX antenna. */
> txant = IWN_LSB(sc->txchainmask);
> tx->rflags |= IWN_RFLAG_ANT(txant);
> +
> + /*
> +* Only do
Re: PATCH: fix iwn(4) scan hangs
On Tue, Sep 9, 2014 at 4:30 PM, Erling Westenvik wrote: > On Tue, Sep 09, 2014 at 12:38:04PM +0200, Fabian Raetz wrote: >> Devices tested so far: >> >> Inter WiFi Link 5100 (Marcin Piotr Pawlowski) >> Intel Centrino Advanced-N 6205(Mike Burns, who also reported the >> problem on misc@, thanks!) >> Intel Centrino Wireless-N 2230(Fabian Raetz) >> >> More tests are much appreciated :) > > Tested on the Intel WiFi Link 5300 in my ThinkPad T500 and iwn(4) seem > to retain the current connection through a scan. > > However, I'm getting a "ifconfig: SIOCG80211ALLNODES: Inappropriate > ioctl for device" and the scan does not return any access points; I have > to set it manually (ifconfig iwn0 nwid wpakey ). You need to recompile ifconfig, cause now it's not in sync with your kernel due to this commit: http://marc.info/?l=openbsd-cvs&m=140890331516734 Cheers! David
Re: pckbd volume keys (part 1), diff to test
On Fri, May 23, 2014 at 12:42 PM, Alexandre Ratchov wrote: > On Wed, Apr 30, 2014 at 01:06:48AM +0200, Alexandre Ratchov wrote: >> This diff attempts to "unify" volume keys; it makes pckbd and ukbd >> volume keys behave like all other volume keys (acpithinkpad, >> acpiasus, macppc/abtn and similar drivers): simply adjust the >> hardware volume without passing keystroke events to upper layers >> (i.e. "consume" the keystroke). >> >> If your volume keys tend to mess the volume while in X (example >> mplayer), try this diff and see if it makes things better (or >> worse). > > No test reports so far. To test this: start X, then: > > - press the "vol -" button many times (don't hold is pressed), > until volume goes to zero. > > - start a movie in mplayer, there's no sound as volume is zero. > > - press the "vol +" button and hold it down; now mplayer indicates > the volume reached the maximum. Still you don't hear anything. > > Confusing, isn't it? Then rebuild the kernel with this diff and > retry. With the diff volume keys are simple and deterministic: they > simply adjust the volume and don't trigger hot-keys or whatever. Tested on my laptop: it follows the principle of least astonishment, thus I like it. Thanks, David
Re: _Xsetlocale
On Wed, May 21, 2014 at 4:12 PM, Stefan Sperling wrote: > On Wed, May 21, 2014 at 02:20:08PM +0200, David Coppa wrote: >> >> Hi! >> >> Found this while analyzing rxvt-unicode's config.log: >> >> configure:7078: checking for working X setlocale >> configure:7095: c++ -o conftest -O2 -pipe -w -I/usr/X11R6/include >> conftest.cpp -lsupc++ -L/usr/X11R6/lib -R/usr/X11R6/lib -lX11 >&5 >> /tmp//cc2K0U3P.o(.text+0x11): In function `main': >> : undefined reference to `_Xsetlocale' >> collect2: ld returned 1 exit status >> configure:7095: $? = 1 >> configure: failed program was: >> >> The diff below makes Xsetlocale fall back to setlocale() like they >> did for Apple and Cygwin... >> >> Opinions / OKs ? > > In my mind, this raises a couple of questions I don't know any answers to. > > What's the impact of this change on rxvt-unicode? > > http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/2556 > What does "proper locale support" mean to them? > Does our setlocale() qualify? It returns errors for most things except > LC_CTYPE and LC_MESSAGES, which wouldn't happen on most other systems. > > What do applications expect from _Xsetlocale? How is this API used? So _Xsetlocale is an alternative setlocale() for when the OS does not provide one... I think you can just forget my patch ;) ciao, David
Re: _Xsetlocale
On Wed, May 21, 2014 at 4:12 PM, Stefan Sperling wrote: > On Wed, May 21, 2014 at 02:20:08PM +0200, David Coppa wrote: >> >> Hi! >> >> Found this while analyzing rxvt-unicode's config.log: >> >> configure:7078: checking for working X setlocale >> configure:7095: c++ -o conftest -O2 -pipe -w -I/usr/X11R6/include >> conftest.cpp -lsupc++ -L/usr/X11R6/lib -R/usr/X11R6/lib -lX11 >&5 >> /tmp//cc2K0U3P.o(.text+0x11): In function `main': >> : undefined reference to `_Xsetlocale' >> collect2: ld returned 1 exit status >> configure:7095: $? = 1 >> configure: failed program was: >> >> The diff below makes Xsetlocale fall back to setlocale() like they >> did for Apple and Cygwin... >> >> Opinions / OKs ? > > In my mind, this raises a couple of questions I don't know any answers to. > > What's the impact of this change on rxvt-unicode? > > http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/2556 > What does "proper locale support" mean to them? > Does our setlocale() qualify? It returns errors for most things except > LC_CTYPE and LC_MESSAGES, which wouldn't happen on most other systems. > > What do applications expect from _Xsetlocale? How is this API used? Something is still wrong btw... Our libX11 has Xlocale support (it's not compiled using --disable-xlocale and /usr/X11R6/include/X11/Xlocale.h is there). Yet, if you try to use the _Xsetlocale function, it fails with the error above. My patch is the less instrusive thing I could think of... cheers! David
_Xsetlocale
Hi!
Found this while analyzing rxvt-unicode's config.log:
configure:7078: checking for working X setlocale
configure:7095: c++ -o conftest -O2 -pipe -w -I/usr/X11R6/include conftest.cpp
-lsupc++ -L/usr/X11R6/lib -R/usr/X11R6/lib -lX11 >&5
/tmp//cc2K0U3P.o(.text+0x11): In function `main':
: undefined reference to `_Xsetlocale'
collect2: ld returned 1 exit status
configure:7095: $? = 1
configure: failed program was:
The diff below makes Xsetlocale fall back to setlocale() like they
did for Apple and Cygwin...
Opinions / OKs ?
ciao
David
Index: src/SetLocale.c
===
RCS file: /cvs/xenocara/lib/libX11/src/SetLocale.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 SetLocale.c
--- src/SetLocale.c 27 Aug 2011 15:34:15 - 1.5
+++ src/SetLocale.c 21 May 2014 12:09:48 -
@@ -117,7 +117,7 @@ _Xsetlocale(
#else /* X_LOCALE */
-#if defined(__APPLE__) || defined(__CYGWIN__)
+#if defined(__APPLE__) || defined(__CYGWIN__) || defined(__OpenBSD__)
char *
_Xsetlocale(
int category,
@@ -126,7 +126,7 @@ _Xsetlocale(
{
return setlocale(category, name);
}
-#endif /* __APPLE__ || __CYGWIN__ */
+#endif /* __APPLE__ || __CYGWIN__ || __OpenBSD__ */
/*
* _XlcMapOSLocaleName is an implementation dependent routine that derives
Re: umsm support for Alcatel OneTouch L100V
On Fri, May 16, 2014 at 3:31 PM, Łukasz Ratajski
wrote:
> Am 16.05.2014 13:10, schrieb David Coppa:
>> On Fri, May 16, 2014 at 1:02 PM, Łukasz Ratajski
>> wrote:
>>> Attached is a diff for umsm+man page which enables support for the
>>> Alcatel OneTouch L100V USB 2G/3G/LTE modem, known in Germany as Telekom
>>> SpeedStick LTE II.
>>>
>>> The storage part has to be ejected first. Connectivity tested with
>>> userland ppp on amd64. Patch is against 5.5-STABLE.
>>
>> Is it ejecting automatically?
>> I mean, is this using "{{ USB_VENDOR_TCTMOBILE,
>> USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3}" ?
>>
>> If so, then it's ok with me.
>
> I had to eject the umass part manually in order to access the modem.
> Now, after some inspection, I am certain that I found the solution.
> After manual ejection the usbdevs output changed as following:
>
> - port 5 addr 3: high speed, power 500 mA, config 1, Mobile Broad
> Band(0xf017), USBModem(0x1bbb), rev 0.00
> + port 5 addr 3: high speed, power 500 mA, config 1, Mobile Broad
> Band(0x011e), USBModem(0x1bbb), rev 0.00
>
> Apparently the umass device uses a different product ID, so I decided to
> add it to usbdevs, and change umsm.c accordingly. Plugged in, and dmesg
> shows this (without any manual interaction):
>
> umsm0 at uhub0 port 5 configuration 1 interface 0 "USBModem Mobile Broad
> Band" rev 2.00/0.00 addr 3
> umsm1 at uhub0 port 5 configuration 1 interface 1 "USBModem Mobile Broad
> Band" rev 2.00/0.00 addr 3
> umsm0 detached
> umsm1 detached
> umsm0 at uhub0 port 5 configuration 1 interface 0 "USBModem Mobile Broad
> Band" rev 2.00/0.00 addr 3
> ucom0 at umsm0
> umsm1 at uhub0 port 5 configuration 1 interface 1 "USBModem Mobile Broad
> Band" rev 2.00/0.00 addr 3
> ucom1 at umsm1
> umass1 at uhub0 port 5 configuration 1 interface 2 "USBModem Mobile
> Broad Band" rev 2.00/0.00 addr 3
> umass1: using SCSI over Bulk-Only
> scsibus3 at umass1: 2 targets, initiator 0
> sd2 at scsibus3 targ 1 lun 0: SCSI2
> 0/direct removable
> umsm2 at uhub0 port 5 configuration 1 interface 3 "USBModem Mobile Broad
> Band" rev 2.00/0.00 addr 3
> ucom2 at umsm2
> umsm3 at uhub0 port 5 configuration 1 interface 4 "USBModem Mobile Broad
> Band" rev 2.00/0.00 addr 3
> ucom3 at umsm3
>
> Firing up ppp confirmed that it's working. Here is the revised patch:
It's committed.
Thanks && ciao!
David
Re: umsm support for Alcatel OneTouch L100V
On Fri, May 16, 2014 at 1:02 PM, Łukasz Ratajski
wrote:
> Attached is a diff for umsm+man page which enables support for the
> Alcatel OneTouch L100V USB 2G/3G/LTE modem, known in Germany as Telekom
> SpeedStick LTE II.
>
> The storage part has to be ejected first. Connectivity tested with
> userland ppp on amd64. Patch is against 5.5-STABLE.
Is it ejecting automatically?
I mean, is this using "{{ USB_VENDOR_TCTMOBILE,
USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3}" ?
If so, then it's ok with me.
ciao,
David
> umass1 at uhub0 port 5 configuration 1 interface 2 "USBModem Mobile
> Broad Band" rev 2.00/0.00 addr 3
> umass1: using SCSI over Bulk-Only
> scsibus3 at umass1: 2 targets, initiator 0
> sd2 at scsibus3 targ 1 lun 0: SCSI2
> 0/direct removable
> umsm2 at uhub0 port 5 configuration 1 interface 3 "USBModem Mobile Broad
> Band" rev 2.00/0.00 addr 3
> ucom2 at umsm2
> umsm3 at uhub0 port 5 configuration 1 interface 4 "USBModem Mobile Broad
> Band" rev 2.00/0.00 addr 3
> ucom3 at umsm3
>
> Index: umsm.c
> ===
> RCS file: /cvs/src/sys/dev/usb/umsm.c,v
> retrieving revision 1.96
> diff -u -p -u -p -r1.96 umsm.c
> --- umsm.c 13 Dec 2013 17:43:07 - 1.96
> +++ umsm.c 16 May 2014 10:20:16 -
> @@ -251,6 +251,7 @@ static const struct umsm_type umsm_devs[
> {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
> {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM }, 0},
> {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM_2 }, 0},
> + {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMSM_3 }, 0},
>
> {{ USB_VENDOR_TOSHIBA, USB_PRODUCT_TOSHIBA_HSDPA }, 0},
>
> Index: usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.623
> diff -u -p -u -p -r1.623 usbdevs
> --- usbdevs 15 Feb 2014 02:16:57 - 1.623
> +++ usbdevs 16 May 2014 10:20:16 -
> @@ -3969,6 +3969,7 @@ product SYNTECH CIPHERLAB100 0x1000 Ciph
> /* TCT Mobile products */
> product TCTMOBILE UMSM 0x Modem mode
> product TCTMOBILE UMSM_2 0x0017 Modem mode
> +product TCTMOBILE UMSM_3 0x011e Modem mode
> product TCTMOBILE UMASS0xf000 Storage mode
>
> /* Tangtop products */
> Index: umsm.4
> ===
> RCS file: /cvs/src/share/man/man4/umsm.4,v
> retrieving revision 1.88
> diff -u -p -u -p -r1.88 umsm.4
> --- umsm.4 16 Jul 2013 16:05:49 - 1.88
> +++ umsm.4 16 May 2014 10:20:42 -
> @@ -37,6 +37,7 @@ driver:
> .Bl -column "Medion Mobile S4012 (Huawei E1550 OEM)" "Bus" -offset 6n
> .It Em Device Ta Em Bus
> .It Li "AirPrime PC5220" Ta "CardBus"
> +.It Li "Alcatel One Touch L100V" Ta "USB"
> .It Li "Alcatel One Touch X060" Ta "USB"
> .It Li "Alcatel One Touch X200" Ta "USB"
> .It Li "Alcatel One Touch X210" Ta "USB"
>
> With best regards,
>
> Łukasz
>
> --
> PGP Key 0x7F0B40F4 | 9E98 D004 EEF8 1B49 38DD AE51 162A 0644 7F0B 40F4
>
Re: umodem.c: debug message fix
Il giorno 30/apr/2014 23.11, "SASANO Takayoshi" ha
scritto:
>
> Hello,
>
> I found some debug messages need to be fixed in sys/dev/usb/umodem.c.
> Can I commit the diff?
Ok dcoppa@
>
> SASANO Takayoshi
>
> Index: umodem.c
> ===
> RCS file: /cvs/src/sys/dev/usb/umodem.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 umodem.c
> --- umodem.c30 Jan 2014 20:37:03 - 1.55
> +++ umodem.c30 Apr 2014 19:50:23 -
> @@ -576,7 +576,7 @@ umodem_ioctl(void *addr, int portno, u_l
> if (usbd_is_dying(sc->sc_udev))
> return (EIO);
>
> - DPRINTF(("umodemioctl: cmd=0x%08lx\n", cmd));
> + DPRINTF(("umodem_ioctl: cmd=0x%08lx\n", cmd));
>
> switch (cmd) {
> case USB_GET_CM_OVER_DATA:
> @@ -590,7 +590,7 @@ umodem_ioctl(void *addr, int portno, u_l
> break;
>
> default:
> - DPRINTF(("umodemioctl: unknown\n"));
> + DPRINTF(("umodem_ioctl: unknown\n"));
> error = ENOTTY;
> break;
> }
> @@ -601,7 +601,7 @@ umodem_ioctl(void *addr, int portno, u_l
> void
> umodem_dtr(struct umodem_softc *sc, int onoff)
> {
> - DPRINTF(("umodem_modem: onoff=%d\n", onoff));
> + DPRINTF(("umodem_dtr: onoff=%d\n", onoff));
>
> if (sc->sc_dtr == onoff)
> return;
> @@ -613,7 +613,7 @@ umodem_dtr(struct umodem_softc *sc, int
> void
> umodem_rts(struct umodem_softc *sc, int onoff)
> {
> - DPRINTF(("umodem_modem: onoff=%d\n", onoff));
> + DPRINTF(("umodem_rts: onoff=%d\n", onoff));
>
> if (sc->sc_rts == onoff)
> return;
>
>
tedu .klogin
Is it ok to zap .klogin?
cheers
David
Index: distrib/sets/lists/etc/mi
===
RCS file: /cvs/src/distrib/sets/lists/etc/mi,v
retrieving revision 1.162
diff -u -p -u -p -r1.162 mi
--- distrib/sets/lists/etc/mi 24 Apr 2014 21:07:37 - 1.162
+++ distrib/sets/lists/etc/mi 29 Apr 2014 14:13:14 -
@@ -205,7 +205,6 @@
./root/.Xdefaults
./root/.cshrc
./root/.cvsrc
-./root/.klogin
./root/.login
./root/.profile
./var/crash/minfree
Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.356
diff -u -p -u -p -r1.356 Makefile
--- etc/Makefile24 Apr 2014 15:05:10 - 1.356
+++ etc/Makefile29 Apr 2014 14:13:14 -
@@ -131,8 +131,6 @@ distribution-etc-root-var: distrib-dirs
cd root; \
${INSTALL} -c -o root -g wheel -m 644 dot.cshrc \
${DESTDIR}/root/.cshrc; \
- ${INSTALL} -c -o root -g wheel -m 600 dot.klogin \
- ${DESTDIR}/root/.klogin; \
${INSTALL} -c -o root -g wheel -m 644 dot.login \
${DESTDIR}/root/.login; \
${INSTALL} -c -o root -g wheel -m 644 dot.profile \
Index: etc/changelist
===
RCS file: /cvs/src/etc/changelist,v
retrieving revision 1.86
diff -u -p -u -p -r1.86 changelist
--- etc/changelist 22 Apr 2014 10:24:29 - 1.86
+++ etc/changelist 29 Apr 2014 14:13:14 -
@@ -153,7 +153,6 @@
/etc/ypldap.conf
/root/.Xdefaults
/root/.cshrc
-/root/.klogin
/root/.login
/root/.profile
/root/.rhosts
Index: etc/mtree/special
===
RCS file: /cvs/src/etc/mtree/special,v
retrieving revision 1.103
diff -u -p -u -p -r1.103 special
--- etc/mtree/special 22 Apr 2014 10:48:36 - 1.103
+++ etc/mtree/special 29 Apr 2014 14:13:17 -
@@ -118,7 +118,6 @@ uucptype=dir mode=0755 uname=root gnam
root type=dir mode=0700 uname=root gname=wheel
.cshrc type=file mode=0644 uname=root gname=wheel
-.klogintype=file mode=0600 uname=root gname=wheel optional
.login type=file mode=0644 uname=root gname=wheel
.profile type=file mode=0644 uname=root gname=wheel
.rhoststype=file mode=0600 uname=root gname=wheel optional
Index: etc/root/dot.klogin
===
RCS file: etc/root/dot.klogin
diff -N etc/root/dot.klogin
--- etc/root/dot.klogin 9 Jun 2002 06:15:15 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,4 +0,0 @@
-# $OpenBSD: dot.klogin,v 1.4 2002/06/09 06:15:15 todd Exp $
-
-#user1.root@your.realm.wherever
-#user2.root@your.realm.wherever
Index: libexec/security/security
===
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 security
--- libexec/security/security 21 Apr 2014 15:46:03 - 1.26
+++ libexec/security/security 29 Apr 2014 14:14:00 -
@@ -103,7 +103,7 @@ sub check_passwd {
"\t by root; cannot check for existence " .
"of alternate access files."
or check_access_file "$home/.$_", $name
- foreach qw(ssh rhosts shosts klogin);
+ foreach qw(ssh rhosts shosts);
}
nag $uid == 0 && $name ne 'root',
"Login $name has a user ID of 0.";
@@ -407,7 +407,7 @@ sub check_dot_writeable {
return if $name =~ /^[+-]/; # skip YP lines
foreach my $f (qw(
.bashrc .bash_profile .bash_login .bash_logout .cshrc
- .emacs .exrc .forward .fvwmrc .inputrc .klogin .kshrc .login
+ .emacs .exrc .forward .fvwmrc .inputrc .kshrc .login
.logout .nexrc .profile .screenrc .ssh .ssh/config
.ssh/authorized_keys .ssh/authorized_keys2 .ssh/environment
.ssh/known_hosts .ssh/rc .tcshrc .twmrc .xsession .xinitrc
Re: 12 seconds delay when starting X.org
On Tue, Apr 22, 2014 at 10:29 AM, Kārlis Miķelsons wrote: >> It's the pms(4) driver. It happens on some Dell laptops that have a crappy >> non fully standard synaptics (alps?) touchpad. > > It seems so, today this laptop booted up without pms device for some reason, > and without it X.org started up instantly. Try to disable pms: # config -e -f /bsd UKC>disable pms And see if you can reproduce the problem.
Re: 12 seconds delay when starting X.org
Il giorno 22/apr/2014 06.59, "Kārlis Miķelsons" ha scritto: > > Hello, > > >> Your DNS is broken. xauth is trying to resolve the current hostname. >> Fix DNS or add something to /etc/hosts. > > Thank you for your suggestion, but it didn't help. > > $ cat /etc/resolv.conf > family inet4 inet6 > nameserver 8.8.8.8 > lookup file bind > > $ hostname > host.domain.com > > $ host host.domain.com > host.domain.com has address 127.0.0.1 > > $ cat /etc/hosts | grep -v "#" > 127.0.0.1 localhost > ::1 localhost > 127.0.0.1 host host.domain.com > > I also made sure that reverse DNS for my IP address works fine and > without any delays and tried multiple different DNS servers in > resolv.conf It's the pms(4) driver. It happens on some Dell laptops that have a crappy non fully standard synaptics (alps?) touchpad.
xcb-util-cursor broken
Hi! x11/i3 (and x11/awesome too) wants to use libxcb-cursor. Back in the days I patched upstream code and reverted it to use libXcursor. Now that we have xcb-util-cursor I want to remove those patches. However, xcb-util-cursor is currently broken: [i3] CC src/config_parser.c cc -DI3_VERSION=\"'4.7.2 (2014-01-23, branch \"tags/4.7.2\")'\" -DMAJOR_VERSION=4 -DMINOR_VERSION=7 -DPATCH_VERSION=2 -DSYSCONFDIR=\"/etc\" -DI3__FILE__=__FILE__ -DPCRE_HAS_UCP=1 -DPANGO_SUPPORT=1 -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/local/include/cairo -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include/pango-1.0 -I/usr/local/include/cairo -I/usr/X11R6/include/pixman-1 -I/usr/local/include/libpng16 -I/usr/X11R6/include -I/usr/local/include/harfbuzz -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/X11R6/include/freetype2 -I/usr/local/include/yajl -idirafter /usr/ports/pobj/i3-4.7.2/i3-4.7.2/yajl-fallbac! k -I/usr/local/include -I/usr/local/include/startup-notification-1.0 -std=c99 -Wall -Wunused-value -Iinclude -I/usr/X11R6/include -I/usr/local/include -O2 -pipe -L/usr/X11R6/lib -L/usr/local/lib -DTEST_PARSER -g -o test.config_parser src/config_parser.c -L/usr/ports/pobj/i3-4.7.2/i3-4.7.2 -li3 -lm -liconv -L/usr/X11R6/lib -lxcb -L/usr/X11R6/lib -lxcb-util -lxcb -L/usr/X11R6/lib -lxcb-util -lxcb -L/usr/X11R6/lib -lxcb-keysyms -lxcb -L/usr/X11R6/lib -lxcb-icccm -lxcb -L/usr/X11R6/lib -lxcb-xinerama -lxcb -L/usr/X11R6/lib -lxcb-randr -lxcb -L/usr/X11R6/lib -lX11 -L/usr/X11R6/lib -lxcb-cursor -lxcb -L/usr/local/lib -Wl,-rpath-link,/usr/X11R6/lib -lcairo -L/usr/local/lib -Wl,-rpath-link,/usr/X11R6/lib -L/usr/X11R6/lib -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lgobject-2.0 -lglib-2.0 -lintl -lfreetype -lz -lfontconfig -L/usr/local/lib -lyajl -lev -L/usr/local/lib -lpcre -L/usr/local/lib -lstartup-notification-1 -lm src/config_parser.c:162: warning: type qualifiers ignored on function return type /usr/local/lib/libglib-2.0.so.4000.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libglib-2.0.so.4000.0: warning: stpcpy() is dangerous GNU crap; don't use it /tmp//ccBo5VvY.o(.text+0x1a21): In function `parse_config': src/config_parser.c:498: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libcairo.so.12.2: warning: rand() isn't random; consider using arc4random() /usr/X11R6/lib/libX11.so.16.0: warning: strcat() is almost always misused, please use strlcat() /usr/X11R6/lib/libX11.so.16.0: warning: sprintf() is often misused, please use snprintf() /usr/X11R6/lib/libxcb-cursor.so.0.0: undefined reference to `le32toh' collect2: ld returned 1 exit status src/i3.mk:55: recipe for target 'src/config_parser.o' failed gmake: *** [src/config_parser.o] Error 1 If I got it right, letoh32 is equivalent to linux' le32toh. The following diff works for me. OK? Index: cursor/parse_cursor_file.c === RCS file: /cvs/xenocara/lib/xcb-util-cursor/cursor/parse_cursor_file.c,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 parse_cursor_file.c --- cursor/parse_cursor_file.c 14 Apr 2014 19:28:48 - 1.1.1.1 +++ cursor/parse_cursor_file.c 15 Apr 2014 08:50:12 - @@ -42,6 +42,9 @@ #endif #ifdef HAVE_SYS_ENDIAN_H #include +# ifndef HAVE_LE32TOH +# define le32toh(x) letoh32(x) +# endif #endif #ifdef HAVE_SYS_BYTEORDER_H #include
Re: inteldrm/radeondrm suspend/resume diff
On Thu, Mar 13, 2014 at 12:31 PM, David Coppa wrote: > On Thu, Mar 13, 2014 at 11:53 AM, Gregor Best wrote: >> On Thu, Mar 13, 2014 at 11:16:42AM +0100, Gregor Best wrote: >>> [...] >>> Couldn't test hibernate yet because my system has root on a softraid >>> crypto device and the swap is outside the crypto area. >>> [...] >> >> David gave me a hint on how to hardwire my kernel for swap on sd0b. >> >> With that, hibernate works slowly, but it works. The full hibernate + >> resume cycle takes about one or two minutes, which I guess is fine. >> >> I'm not sure whether hibernation working is a direct consequence of this >> diff, but I think that's OK since the diff didn't break it either. > > I currently have a regression with hibernate (reboot during resume, it > was working fine before). > I will test tonight if Mark's diff unbreaks it... I confirm this diff fixed my regression with ZZZ. Thanks a lot, Mark. Ciao! David
Re: [xenocara] [UPDATE] freetype-2.5.3
On Thu, Mar 13, 2014 at 3:06 PM, Mark Kettenis wrote: >> Date: Thu, 13 Mar 2014 02:34:17 -0600 >> From: David Coppa >> >> Hi! >> >> This diff updates freetype to version 2.5.3. >> >> It fixes a vulnerability in the CFF driver (CVE-2014-2240). >> >> Minor bumped due to the addition of FT_MulFix_x86_64() in >> /usr/X11R6/include/freetype2/config/ftconfig.h (is this really >> needed?) > > No, that's not needed. FT_MulFix_x86_64() is defined as a static > inline so it is not part of the ABI. Thanks, Mark. I will fix my diff asap... Ciao! David
Re: inteldrm/radeondrm suspend/resume diff
On Thu, Mar 13, 2014 at 11:53 AM, Gregor Best wrote: > On Thu, Mar 13, 2014 at 11:16:42AM +0100, Gregor Best wrote: >> [...] >> Couldn't test hibernate yet because my system has root on a softraid >> crypto device and the swap is outside the crypto area. >> [...] > > David gave me a hint on how to hardwire my kernel for swap on sd0b. > > With that, hibernate works slowly, but it works. The full hibernate + > resume cycle takes about one or two minutes, which I guess is fine. > > I'm not sure whether hibernation working is a direct consequence of this > diff, but I think that's OK since the diff didn't break it either. I currently have a regression with hibernate (reboot during resume, it was working fine before). I will test tonight if Mark's diff unbreaks it... Ciao, David
Re: [xenocara] [UPDATE] freetype-2.5.3
On Thu, Mar 13, 2014 at 9:34 AM, David Coppa wrote: > > Hi! > > This diff updates freetype to version 2.5.3. > > It fixes a vulnerability in the CFF driver (CVE-2014-2240). > > Minor bumped due to the addition of FT_MulFix_x86_64() in > /usr/X11R6/include/freetype2/config/ftconfig.h (is this really > needed?) Please wait. There's a problem wrt the creation of the freetype2.pc file that needs further investigation :( Ciao, David
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Tue, Feb 11, 2014 at 6:35 AM, Martynas Venckus
wrote:
>> Here's a diff that sticks a bit closer to the original code. It's
>> equivalent to your diff, and admittedly purely a matter of taste which
>> version to prefer.
>
> I prefer my version better. It's not '93 anymore and compilers are
> able to convert 0.0L and -1.0L precisely, otherwise we have a huge
> problem. There's no need to obfuscate here by manually converting
> to floating point representation.
>
> Here's a diff which also includes same fix for ld128. OK?
OK with me.
Ciao,
David
> Index: ld128/s_floorl.c
> ===
> RCS file: /cvs/src/lib/libm/src/ld128/s_floorl.c,v
> retrieving revision 1.1
> diff -u -r1.1 s_floorl.c
> --- ld128/s_floorl.c6 Jul 2011 00:02:42 - 1.1
> +++ ld128/s_floorl.c11 Feb 2014 05:24:15 -
> @@ -34,10 +34,11 @@
> jj0 = ((i0>>48)&0x7fff)-0x3fff;
> if(jj0<48) {
> if(jj0<0) { /* raise inexact if x != 0 */
> - if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
> - if(i0>=0) {i0=i1=0;}
> + if(huge+x>0.0) {
> + if(i0>=0)
> + return 0.0L;
> else if(((i0&0x7fffLL)|i1)!=0)
> - { i0=0xbfffULL;i1=0;}
> + return -1.0L;
> }
> } else {
> i = (0xULL)>>jj0;
> Index: ld80/s_floorl.c
> ===
> RCS file: /cvs/src/lib/libm/src/ld80/s_floorl.c,v
> retrieving revision 1.2
> diff -u -r1.2 s_floorl.c
> --- ld80/s_floorl.c 25 Jul 2011 16:20:09 - 1.2
> +++ ld80/s_floorl.c 11 Feb 2014 05:24:01 -
> @@ -35,10 +35,11 @@
> jj0 = (se&0x7fff)-0x3fff;
> if(jj0<31) {
> if(jj0<0) { /* raise inexact if x != 0 */
> - if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
> - if(sx==0) {se=0;i0=i1=0;}
> + if(huge+x>0.0) {
> + if(sx==0)
> + return 0.0L;
> else if(((se&0x7fff)|i0|i1)!=0)
> - { se=0xbfff;i0=i1=0;}
> + return -1.0L;
> }
> } else {
> i = (0x7fff)>>jj0;
>
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Fri, Feb 7, 2014 at 4:03 PM, David Coppa wrote:
> On Fri, Feb 7, 2014 at 3:49 PM, Mark Kettenis wrote:
>>> Date: Thu, 6 Feb 2014 23:07:58 -0800
>>> From: Martynas Venckus
>>>
>>> Yup.Does this diff fix it for you?
>>
>> Here's a diff that sticks a bit closer to the original code. It's
>> equivalent to your diff, and admittedly purely a matter of taste which
>> version to prefer.
>>
>> Index: s_floorl.c
>> ===
>> RCS file: /home/cvs/src/lib/libm/src/ld80/s_floorl.c,v
>> retrieving revision 1.2
>> diff -u -p -r1.2 s_floorl.c
>> --- s_floorl.c 25 Jul 2011 16:20:09 - 1.2
>> +++ s_floorl.c 7 Feb 2014 14:43:19 -
>> @@ -38,7 +38,7 @@ floorl(long double x)
>> if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
>> if(sx==0) {se=0;i0=i1=0;}
>> else if(((se&0x7fff)|i0|i1)!=0)
>> - { se=0xbfff;i0=i1=0;}
>> + { se=0xbfff;i0=0x8000;i1=0;}
>> }
>> } else {
>> i = (0x7fff)>>jj0;
>>
>
> Just tested, and this one works too, of course...
>
> I'd be happy if this or the other one could be committed.
Ping
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Fri, Feb 7, 2014 at 3:49 PM, Mark Kettenis wrote:
>> Date: Thu, 6 Feb 2014 23:07:58 -0800
>> From: Martynas Venckus
>>
>> Yup.Does this diff fix it for you?
>
> Here's a diff that sticks a bit closer to the original code. It's
> equivalent to your diff, and admittedly purely a matter of taste which
> version to prefer.
>
> Index: s_floorl.c
> ===
> RCS file: /home/cvs/src/lib/libm/src/ld80/s_floorl.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 s_floorl.c
> --- s_floorl.c 25 Jul 2011 16:20:09 - 1.2
> +++ s_floorl.c 7 Feb 2014 14:43:19 -
> @@ -38,7 +38,7 @@ floorl(long double x)
> if(huge+x>0.0) {/* return 0*sign(x) if |x|<1 */
> if(sx==0) {se=0;i0=i1=0;}
> else if(((se&0x7fff)|i0|i1)!=0)
> - { se=0xbfff;i0=i1=0;}
> + { se=0xbfff;i0=0x8000;i1=0;}
> }
> } else {
> i = (0x7fff)>>jj0;
>
Just tested, and this one works too, of course...
I'd be happy if this or the other one could be committed.
ciao,
David
Re: exp() / expl() on Linux and OpenBSD (expl() bug?)
On Fri, Feb 7, 2014 at 8:07 AM, Martynas Venckus wrote:
> Yup.Does this diff fix it for you?
Yeah! It works.
And R-3's testsuite is also happy now.
Thanks a lot! And thanks to Daniel too...
ok dcoppa@ to commit it, obviously
Ciao,
David
> On 2/6/14, Daniel Dickman wrote:
>> I think I recently ran into a similar issue but I suspect the root cause
>> might be the same. I think the floorl function is wrong for numbers slightly
>> larger than -1 to numbers slightly below 0. In this range floorl returns -0
>> instead of -1.
>>
>>> On Feb 5, 2014, at 3:57 AM, David Coppa wrote:
>>>
>>>
>>> Hi!
>>>
>>> I hit this problem while working on updating math/R from version
>>> 2.15.3 to the latest version (3.0.2).
>>>
>>> It started happening since upstream switched from double functions
>>> to C99 long double functions (expl, fabsl, ...), during the R-3
>>> development cycle.
>>>
>>> Take the following reduced test-case, adapted from what R's code
>>> does:
>>>
>>> ---8<---
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> int main(void) {
>>>double theta = 1;
>>>long double lambda, pr, pr2;
>>>
>>>lambda = (0.5*theta);
>>>pr = exp(-lambda);
>>>pr2 = expl(-lambda);
>>>
>>>printf("theta == %g, pr == %Lg, pr2 == %Lg\n", theta, pr, pr2);
>>>exit(0);
>>> }
>>>
>>> ---8<---
>>>
>>> This produces the following output on Linux (x86_64):
>>>
>>> theta == 1, pr == 0.606531, pr2 == 0.606531
>>>
>>> While on OpenBSD -current amd64:
>>>
>>> theta == 1, pr == 0.606531, pr2 == nan
>>>
>>> And indeed R-3's testsuite fails with the error message
>>> "NaNs produced":
>>>
>>> Warning in pchisq(1e-300, df = 0, ncp = lam) : NaNs produced
>>>> stopifnot(all.equal(p00, exp(-lam/2)),
>>> + all.equal(p.0, exp(-lam/2)))
>>> Error: all.equal(p.0, exp(-lam/2)) is not TRUE
>>> Execution halted
>>>
>>> Is this a bug in our expl() ?
>>>
>>> Ciao,
>>> David
>>>
>>
Re: somewhat important inteldrm fix
On Wed, Feb 5, 2014 at 11:43 AM, Mark Kettenis wrote: >> From: David Coppa >> Date: Wed, 5 Feb 2014 09:01:45 +0100 >> >> On Tue, Feb 4, 2014 at 11:55 PM, Mark Kettenis >> wrote: >> > Running the updated xf86-video-intel driver uncovered a bug in the >> > kernel drm code. The page fault handler wasn't handling some of the >> > possible errors correctly. This made the X server die with a SIGSEGV. >> > The diff below brings things closer to what Linux does, and seems to >> > fix the crashes I was seeing. A bit more testing would be welcome >> > though. Note that this needs the commit to drmP.h I just made, which >> > might not have made it to all the anoncvs servers yet. >> >> I saw the X server crash yesterday, while watching a video in >> fullscreen using minitube. >> I will apply your diff and report back asap... > > Since matthieu@ confirmed it fixes his problems as well, I've > committed the diff. So it should show up on your favourite anoncvs > mirror shortly. OK, thanks. cheers, david
exp() / expl() on Linux and OpenBSD (expl() bug?)
Hi!
I hit this problem while working on updating math/R from version
2.15.3 to the latest version (3.0.2).
It started happening since upstream switched from double functions
to C99 long double functions (expl, fabsl, ...), during the R-3
development cycle.
Take the following reduced test-case, adapted from what R's code
does:
---8<---
#include
#include
#include
int main(void) {
double theta = 1;
long double lambda, pr, pr2;
lambda = (0.5*theta);
pr = exp(-lambda);
pr2 = expl(-lambda);
printf("theta == %g, pr == %Lg, pr2 == %Lg\n", theta, pr, pr2);
exit(0);
}
---8<---
This produces the following output on Linux (x86_64):
theta == 1, pr == 0.606531, pr2 == 0.606531
While on OpenBSD -current amd64:
theta == 1, pr == 0.606531, pr2 == nan
And indeed R-3's testsuite fails with the error message
"NaNs produced":
Warning in pchisq(1e-300, df = 0, ncp = lam) : NaNs produced
> stopifnot(all.equal(p00, exp(-lam/2)),
+ all.equal(p.0, exp(-lam/2)))
Error: all.equal(p.0, exp(-lam/2)) is not TRUE
Execution halted
Is this a bug in our expl() ?
Ciao,
David
Re: somewhat important inteldrm fix
On Tue, Feb 4, 2014 at 11:55 PM, Mark Kettenis wrote: > Running the updated xf86-video-intel driver uncovered a bug in the > kernel drm code. The page fault handler wasn't handling some of the > possible errors correctly. This made the X server die with a SIGSEGV. > The diff below brings things closer to what Linux does, and seems to > fix the crashes I was seeing. A bit more testing would be welcome > though. Note that this needs the commit to drmP.h I just made, which > might not have made it to all the anoncvs servers yet. I saw the X server crash yesterday, while watching a video in fullscreen using minitube. I will apply your diff and report back asap... ciao, David
Re: unbreak ftp progressbar
> From: Antoine Jacoutot
> Date: Wed, Jan 29, 2014 at 3:24 PM
> Subject: Re: unbreak ftp progressbar
> To: Jasper Lievisse Adriaanse
> Cc: tech@openbsd.org
>
>
> On Wed, Jan 29, 2014 at 02:53:12PM +0100, Jasper Lievisse Adriaanse wrote:
> > Hi,
> >
> > At least with ftp -Vm the progressbar was messing up the display as it was
> > printing the output on the same line and would wrap around creating displays
> > such as http://pbot.rmdir.de/gOeAYNv30HnQk-4I4xmKZg
> > Seems like typo from the introduction of the -D flag.
> >
> > OK?
>
> There is already the same diff by David in bugs@
That diff was wrong.
What about this?
Index: util.c
===
RCS file: /cvs/src/usr.bin/ftp/util.c,v
retrieving revision 1.65
diff -u -p -u -p -r1.65 util.c
--- util.c 23 Jan 2014 00:39:15 - 1.65
+++ util.c 29 Jan 2014 14:28:41 -
@@ -811,7 +811,7 @@ progressmeter(int flag, const char *file
dotdot);
overhead += l + 1;
} else
- snprintf(buf, sizeof(buf), "");
+ snprintf(buf, sizeof(buf), "\r");
if (!verbose && title != NULL) {
int l = strlen(title);
Re: unbreak ftp progressbar
On Wed, Jan 29, 2014 at 2:53 PM, Jasper Lievisse Adriaanse wrote: > Hi, > > At least with ftp -Vm the progressbar was messing up the display as it was > printing the output on the same line and would wrap around creating displays > such as http://pbot.rmdir.de/gOeAYNv30HnQk-4I4xmKZg > Seems like typo from the introduction of the -D flag. > > OK? I had the same diff, but it breaks "ftp -D 'BlahBlah' -Vmo" > Index: util.c > === > RCS file: /cvs/src/usr.bin/ftp/util.c,v > retrieving revision 1.65 > diff -u -p -r1.65 util.c > --- util.c 23 Jan 2014 00:39:15 - 1.65 > +++ util.c 29 Jan 2014 13:52:07 - > @@ -825,7 +825,7 @@ progressmeter(int flag, const char *file > overhead += 3; > } > snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), > - "%-*.*s%s %3d%% ", l, l, title, > + "\r%-*.*s%s %3d%% ", l, l, title, > dotdot, ratio); > overhead += l + 1; > } else >
Re: dump vs. dumps
On Fri, Jan 24, 2014 at 12:07 PM, Stuart Henderson wrote: > On 2014/01/24 03:41, David Coppa wrote: >> >> Is there a particular reason for dmesg saying "dump" while the >> kernel config option is "dumps"? > > hmm, not sure I like mixing root/swap (noun) with dumps (verb) within > the single dmesg line... > > root on sd1a (5b1b292fa70c813b.a) swap on sd1b dump on sd1b > root on sd1a (5b1b292fa70c813b.a) swap on sd1b dumps on sd1b I intended this as singular vs. plural, not noun vs. verb
dump vs. dumps
Is there a particular reason for dmesg saying "dump" while the
kernel config option is "dumps"?
I find it confusing...
Index: sys/kern/subr_disk.c
===
RCS file: /cvs/src/sys/kern/subr_disk.c,v
retrieving revision 1.163
diff -u -p -u -p -r1.163 subr_disk.c
--- sys/kern/subr_disk.c24 Jan 2014 10:25:56 - 1.163
+++ sys/kern/subr_disk.c24 Jan 2014 10:31:48 -
@@ -1349,7 +1349,7 @@ gotswap:
DISKUNIT(swdevt[0].sw_dev),
'a' + DISKPART(swdevt[0].sw_dev));
if (dumpdev != NODEV)
- printf(" dump on %s%d%c", findblkname(major(dumpdev)),
+ printf(" dumps on %s%d%c", findblkname(major(dumpdev)),
DISKUNIT(dumpdev), 'a' + DISKPART(dumpdev));
printf("\n");
}
Re: Add spi-inc.org CA root?
> From: Stuart Henderson > Date: Mon, Jan 13, 2014 at 9:24 PM > Subject: Add spi-inc.org CA root? > To: tech > > > Any comments on adding this to cert.pem? It is for SPI, non-profit org which > was originally created as a 501c(3) for Debian, this cert is used to sign keys > for alioth.debian.org which affects as it's a site hosting distfiles for > various ports, it's also used to sign certificates for OFTC.net IRC servers. > > http://en.wikipedia.org/wiki/Software_in_the_Public_Interest Is this the error? ===> Checking files for pcsc-lite-1.8.10 >> Fetch >> https://alioth.debian.org/frs/download.php/latestfile/39/pcsc-lite-1.8.10.tar.bz2 10386432:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:/usr/src/lib/libssl/ssl/../src/ssl/s3_clnt.c:1166: >> Fetch http://ftp.openbsd.org/pub/OpenBSD/distfiles//pcsc-lite-1.8.10.tar.bz2 > OK? Sure, ok with me. ciao, David
Re: Patriot Wireless N USB Adapter
On Sat, Sep 14, 2013 at 7:48 PM, Kyle R. W. Milz wrote: > I'll stop being lazy, maybe this will make things easier for you. Full > disclosure: first patch I've sent to this list. > > > Index: share/man/man4/urtwn.4 > === > RCS file: /cvs/src/share/man/man4/urtwn.4,v > retrieving revision 1.24 > diff -u -p -r1.24 urtwn.4 > --- share/man/man4/urtwn.4 20 Aug 2013 13:46:54 - 1.24 > +++ share/man/man4/urtwn.4 14 Sep 2013 17:30:35 - > @@ -106,6 +106,7 @@ The following adapters should work: > .It Hercules Wireless N USB Pico HWNUp-150 > .It IO-DATA WN-G150UM > .It Netgear WNA1000A > +.It Patriot PCUSBW1150 > .It Planex GW-USEco300 > .It Planex GW-USNano2 > .It Planex GW-USValue-EZ > jmc already committed it.
Re: more /dev/ugen*
On Fri, Sep 13, 2013 at 4:01 PM, Kirill Bychkov wrote: > On Fri, September 13, 2013 13:19, Stuart Henderson wrote: >> On 2013/09/13 10:59, David Coppa wrote: >>> On Fri, Sep 13, 2013 at 10:57 AM, Martin Pieuchot >>> wrote: >>> >>> > Out of curiosity, can I see the dmesg for this machine? I'd like to >>> > know which devices attach at ugen(4). >>> >>> ask djm@ >>> >>> > Makes sense to me, it's not too difficult to have more than 2 usb >>> > devices attached as ugen(4) these days, for example a scanner, >>> > a camera and a music player... >>> >>> exactly... >>> >> >> Is 4 devices enough? This is typically a problem which is not very well >> reported to the user in error messages) - other things that might use >> this include wifi scanner, rtl-sdr, smartcard reader, rocket launcher >> :), etc.. So maybe 6 or 8 would make more sense? >> > > Or even UPS > ugen0 at uhub1 port 2 "American Power Conversion Back-UPS RS 500 FW:30.j5.I > USB FW:j5" rev 1.10/0.06 addr 2 > > 8 is a good number. > my 2 cents... Indeed. We settled on 8 as of now.
Re: more /dev/ugen*
On Fri, Sep 13, 2013 at 11:19 AM, Stuart Henderson wrote: > On 2013/09/13 10:59, David Coppa wrote: >> On Fri, Sep 13, 2013 at 10:57 AM, Martin Pieuchot >> wrote: >> >> > Out of curiosity, can I see the dmesg for this machine? I'd like to >> > know which devices attach at ugen(4). >> >> ask djm@ >> >> > Makes sense to me, it's not too difficult to have more than 2 usb >> > devices attached as ugen(4) these days, for example a scanner, >> > a camera and a music player... >> >> exactly... >> > > Is 4 devices enough? This is typically a problem which is not very well > reported to the user in error messages) - other things that might use > this include wifi scanner, rtl-sdr, smartcard reader, rocket launcher > :), etc.. So maybe 6 or 8 would make more sense? Sure. target(usb, ugen, 0, 1, 2, 3, 4, 5, 6, 7)dnl that's the axe to cut all eventual problems ;)
Re: more /dev/ugen*
On Fri, Sep 13, 2013 at 10:57 AM, Martin Pieuchot wrote: > Out of curiosity, can I see the dmesg for this machine? I'd like to > know which devices attach at ugen(4). ask djm@ > Makes sense to me, it's not too difficult to have more than 2 usb > devices attached as ugen(4) these days, for example a scanner, > a camera and a music player... exactly...
more /dev/ugen*
While debugging a problem with pcscd from security/pcsc-lite
06361622 hotplug_libusb.c:514:HPAddHotPluggable() Adding USB device: 3:2:0
0191 hotplug_libusb.c:558:HPAddHotPluggable() libusb_open failed: -4
We (Damien and me) quickly found that the cause was:
16097 pcscdGIO fd 1 wrote 75 bytes
"04421857 hotplug_libusb.c:514:HPAddHotPluggable() Adding USB device:
3:2:0"
16097 pcscdRET write 75/0x4b
16097 pcscdCALL open(0x74d05fa7bd0,0x2)
16097 pcscdNAMI "/dev/ugen2.00"
16097 pcscdRET open -1 errno 2 No such file or directory
16097 pcscdCALL gettimeofday(0x74d05fa7320,0)
16097 pcscdSTRU struct timeval { 1379032621.501928 }
16097 pcscdRET gettimeofday 0
16097 pcscdCALL write(0x1,0x74cfc0cc000,0x49)
16097 pcscdGIO fd 1 wrote 73 bytes
"0157 hotplug_libusb.c:558:HPAddHotPluggable() libusb_open failed:
-4"
I think only two /dev/ugen* are too few, what about increasing the
number a bit?
Index: MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revision 1.70
diff -u -p -u -p -r1.70 MAKEDEV.common
--- MAKEDEV.common 5 Sep 2013 06:36:16 - 1.70
+++ MAKEDEV.common 13 Sep 2013 08:14:54 -
@@ -183,7 +183,7 @@ target(usb, usb, 0, 1, 2, 3, 4, 5, 6, 7)
target(usb, urio, 0)dnl
target(usb, uhid, 0, 1, 2, 3)dnl
target(usb, ulpt, 0, 1)dnl
-target(usb, ugen, 0, 1)dnl
+target(usb, ugen, 0, 1, 2, 3)dnl
target(usb, ttyU, 0, 1, 2, 3)dnl
dnl
__devitem({-uall-}, uall, All USB devices,usb)dnl
Re: Typo in nfs_boot.c
On Thu, Sep 12, 2013 at 1:33 PM, Eivind Evensen wrote: > Hello. > > Trying to figure out what I've done wrong to have a diskless setup > boot the kernel and then try to talk to a broadcast address rather than > the nfsserver, I saw this typo. > > Eivind > > > Index: sys/nfs/nfs_boot.c > === > RCS file: /cvs/src/sys/nfs/nfs_boot.c,v > retrieving revision 1.27 > diff -u -u -p -r1.27 nfs_boot.c > --- sys/nfs/nfs_boot.c 22 May 2013 09:13:36 - 1.27 > +++ sys/nfs/nfs_boot.c 12 Sep 2013 11:14:07 - > @@ -196,7 +196,7 @@ nfs_boot_init(struct nfs_diskless *nd, s > * Use the old broadcast address for the WHOAMI > * call because we do not yet know our netmask. > * The server address returned by the WHOAMI call > -* is used for all subsequent booptaram RPCs. > +* is used for all subsequent bootparam RPCs. > */ > bzero((caddr_t)&bp_sin, sizeof(bp_sin)); > bp_sin.sin_len = sizeof(bp_sin); > Thanks. jmc?
Re: diff: /etc/rc.d/spamd rc_reload=NO
On Thu, Sep 5, 2013 at 9:31 PM, Craig R. Skinner
wrote:
> Doesn't seem to reload once chrooted:
>
> $ sudo /etc/rc.d/spamd -d reload
> doing rc_read_runfile
> doing rc_check
> spamd
> doing rc_reload
> Sep 5 19:57:54 oak spamd[22335]: greyreader failed (Error 0)
> doing rc_wait reload
> doing rc_check
> doing rc_check
> ...
> ..
> .
> doing rc_check
> (failed)
>
>
>
>
>
> Index: spamd
> ===
> RCS file: /cvs/src/etc/rc.d/spamd,v
> retrieving revision 1.2
> diff -u -r1.2 spamd
> --- spamd 8 Jul 2011 02:15:34 - 1.2
> +++ spamd 5 Sep 2013 19:19:54 -
> @@ -7,6 +7,7 @@
> . /etc/rc.d/rc.subr
>
> pexp="spamd: \[priv\]"
> +rc_reload=NO
>
> rc_pre() {
> [ X"${spamd_black}" != X"NO" ] && \
OK with me.
ciao,
David
src/sbin/ifconfig: missing include
This misses util.h: cc -O2 -pipe -fno-pie -Wall -DINET6 -c /usr/src/sbin/ifconfig/ifconfig.c /usr/src/sbin/ifconfig/ifconfig.c: In function 'setifwpakey': /usr/src/sbin/ifconfig/ifconfig.c:1759: warning: implicit declaration of function 'pkcs5_pbkdf2' OK? Index: ifconfig.c === RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.268 diff -u -p -u -p -r1.268 ifconfig.c --- ifconfig.c 16 Aug 2013 12:29:17 - 1.268 +++ ifconfig.c 19 Aug 2013 10:52:06 - @@ -100,6 +100,7 @@ #include #include #include +#include #include #include "brconfig.h"
Re: add lid status sensor to acpibtn
On Mon, Aug 12, 2013 at 5:40 PM, Landry Breuil wrote: > Hi, > > this diff adds a sensor for acpibtn to show lid status. This allows > userland to monitor/react on lid close/open events, in case one is not > using machdep.lidsuspend. I know sysutils/upower can make use of this, i > just need to add the corresponding code there. > > comments ? I wonder if/how the case when aml_evalinteger() fails should > be handled in acpibtn_attach().. Where's the diff?
Re: man.conf(5) _subdir search order
On Fri, Jul 12, 2013 at 5:51 PM, Ingo Schwarze wrote:
> Here is the fix, making sure that section 1 from ports still
> overrides section 6 from base, but cat from ports does *not*
> override man from base.
Definitely makes sense.
> OK?
Ok with me.
> Yours,
> Ingo
>
ciao,
David
> Index: man.conf
> ===
> RCS file: /cvs/src/etc/man.conf,v
> retrieving revision 1.17
> diff -u -r1.17 man.conf
> --- man.conf11 Apr 2011 14:45:41 - 1.17
> +++ man.conf12 Jul 2013 15:25:14 -
> @@ -9,7 +9,7 @@
> _whatdb/usr/X11R6/man/whatis.db
>
> # Subdirectories for paths ending in '/', IN SEARCH ORDER.
> -_subdircat1 man1 cat8 man8 cat6 man6 cat2 man2 cat3 man3
> cat5 man5 cat7 man7 cat4 man4 cat9 man9 cat3p man3p cat3f man3f catn mann
> +_subdir{cat,man}1 {cat,man}8 {cat,man}6 {cat,man}2
> {cat,man}3 {cat,man}5 {cat,man}7 {cat,man}4 {cat,man}9 {cat,man}3p
> {cat,man}3f {cat,man}n
>
> # Files typed by suffix and their commands.
> # Note the order: .Z must come after .[1-9n].Z, or it will match first.
>
procmap: removing setgid kmem
$ procmap
procmap: invalid address (0) == -1 vs. 224 @ 0
Since procmap does not work anymore for users, what about removing
the setgid kmem?
ciao,
David
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/procmap/Makefile,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 Makefile
--- Makefile23 Feb 2004 21:09:28 - 1.4
+++ Makefile25 Jun 2013 08:57:38 -
@@ -2,8 +2,6 @@
PROG= procmap
SRCS= procmap.c
-BINGRP=kmem
-BINMODE= 2555
CFLAGS+= -Wall
LDADD= -lkvm
DPADD= ${LIBKVM}
Re: binary integer constants in gcc
On Fri, Jun 21, 2013 at 1:03 PM, Stuart Henderson wrote: > only for sparc64: >> net/rtorrent Yes, this is due to a gcc bug: https://github.com/rakshasa/rtorrent/issues/28
Re: bzip2
On Thu, Jun 6, 2013 at 2:20 PM, Mark Kettenis wrote: > > I'm a Perl hater > > > I've ranted before about implementing "standard" tools in Perl. The > user experience just isn't the same as with C code. > > But even more so than with nl(1), why would we want to use something > that's different from what everybody else uses? If we want bzip2 in > base (and I think there are good reasons for having it) we should > simply use the standard bzip2 code. Seconded. ciao, David
Re: options(4) man page: bump BUFCACHEPERCENT
On Wed, May 22, 2013 at 3:42 PM, Lawrence Teo wrote: > BUFCACHEPERCENT has been set to 20 by default for a while now, so bump > it in the options(4) man page accordingly. > > OK? ok for me. thanks for catching this. David > Index: options.4 > === > RCS file: /cvs/src/share/man/man4/options.4,v > retrieving revision 1.231 > diff -u -p -r1.231 options.4 > --- options.4 22 Mar 2013 16:40:24 - 1.231 > +++ options.4 17 May 2013 15:23:48 - > @@ -278,7 +278,7 @@ for details. > .Bl -ohang > .It Cd option BUFCACHEPERCENT= Ns Ar integer > Percentage of RAM to use as a file system buffer. > -It defaults to 5. > +It defaults to 20. > .It Cd option EXT2FS_SYSTEM_FLAGS > This option changes the behavior of the APPEND and IMMUTABLE flags > for a file on an >
