Re: faq 11 can be clarified

[bian]

On 2015-11-14 17:22, Mike Burns wrote:

On 2015-11-14 16.27.30 +0100, bian wrote:

* mention that the "segmentation fault"-message when running the X
-configure is harmless and that the xorg.conf.new file was created as 
it

should.


That's a bug, and while I likely can't fix it (will gladly look), 
we'll

need your dmesg and the backtrace from the coredump, in the least.



I believe Xorg -configure has been useless for a long time.
With a hardware that just works, X just works. If a xorg.conf is needed
(as when e.g. using vesa instead of a misbehaving driver),
it is easier to write a simple one from xorg.conf(5) by hand.

Jan


This is one way of looking at it, yes. However, the quality of the 
produced xorg.conf.new is fine.


/Birger

OT:Paris..

[noah pugsley]

I hope I don't seem like a cheerleader for reflecting your sentiments. Null
politics. Null comment. Geopolitical associations are outside the scope of
this list.

People got hurt. Can't say why from my armchair. Always a bummer. Can't or
won't do much about it but genuinely hope folks are A OK.

peace ok@?

On Sat, Nov 14, 2015 at 9:03 AM, John Long  wrote:

> Miod, are you ok? Condolences and hoping for the best for you guys.
>
> /jl
>
> --
> ASCII ribbon campaign ( ) Powered by Lemote Fuloong
>  against HTML e-mail   X  Loongson MIPS and OpenBSD
>and proprietary/ \http://www.mutt.org
>  attachments /   \  Code Blue or Go Home!
>  Encrypted email preferred  PGP Key 2048R/DA65BC04

Re: em(4) watchdog timeouts

[David Gwynne]

On Fri, Nov 13, 2015 at 10:18:51AM -0500, Sonic wrote:
> On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best  wrote:
> > I've done some further testing and I think I've narrowed it down to the
> > "Unlocking em(4) a bit further"-patch [0].

could you try this? its not written with the wdog stuff in mind,
but it does touch that stuff so it might help.

Index: if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.310
diff -u -p -r1.310 if_em.c
--- if_em.c 29 Oct 2015 03:19:42 -  1.310
+++ if_em.c 15 Nov 2015 14:01:39 -
@@ -605,16 +605,20 @@ em_start(struct ifnet *ifp)
}
 
for (;;) {
-   IFQ_POLL(>if_snd, m_head);
-   if (m_head == NULL)
-   break;
-
-   if (em_encap(sc, m_head)) {
+   if (sc->num_tx_desc_avail < EM_MAX_SCATTER + 2) {
ifp->if_flags |= IFF_OACTIVE;
break;
}
 
IFQ_DEQUEUE(>if_snd, m_head);
+   if (m_head == NULL)
+   break;
+
+   if (em_encap(sc, m_head)) {
+   m_freem(m_head);
+   ifp->if_oerrors++;
+   continue;
+   }
 
 #if NBPFILTER > 0
/* Send a copy of the frame to the BPF listener */
@@ -622,9 +626,6 @@ em_start(struct ifnet *ifp)
bpf_mtap_ether(ifp->if_bpf, m_head, BPF_DIRECTION_OUT);
 #endif
 
-   /* Set timeout in case hardware has problems transmitting */
-   ifp->if_timer = EM_TX_TIMEOUT;
-
post = 1;
}
 
@@ -637,8 +638,11 @@ em_start(struct ifnet *ifp)
 * this tells the E1000 that this frame is
 * available to transmit.
 */
-   if (post)
+   if (post) {
E1000_WRITE_REG(>hw, TDT, sc->next_avail_tx_desc);
+
+   ifp->if_timer = EM_TX_TIMEOUT;
+   }
}
 }
 
@@ -1104,12 +1108,6 @@ em_encap(struct em_softc *sc, struct mbu
struct em_buffer   *tx_buffer, *tx_buffer_mapped;
struct em_tx_desc *current_tx_desc = NULL;
 
-   /* Check that we have least the minimal number of TX descriptors. */
-   if (sc->num_tx_desc_avail <= EM_TX_OP_THRESHOLD) {
-   sc->no_tx_desc_avail1++;
-   return (ENOBUFS);
-   }
-
if (sc->hw.mac_type == em_82547) {
bus_dmamap_sync(sc->txdma.dma_tag, sc->txdma.dma_map, 0,
sc->txdma.dma_map->dm_mapsize,
@@ -1147,9 +1145,6 @@ em_encap(struct em_softc *sc, struct mbu
 
EM_KASSERT(map->dm_nsegs!= 0, ("em_encap: empty packet"));
 
-   if (map->dm_nsegs > sc->num_tx_desc_avail - 2)
-   goto fail;
-
if (sc->hw.mac_type >= em_82543 && sc->hw.mac_type != em_82575 &&
sc->hw.mac_type != em_82580 && sc->hw.mac_type != em_i210 &&
sc->hw.mac_type != em_i350)
@@ -1168,9 +1163,9 @@ em_encap(struct em_softc *sc, struct mbu
 * Check the Address and Length combination and
 * split the data accordingly
 */
-   array_elements = 
em_fill_descriptors(map->dm_segs[j].ds_addr,
-
map->dm_segs[j].ds_len,
-_array);
+   array_elements = em_fill_descriptors(
+   map->dm_segs[j].ds_addr,
+   map->dm_segs[j].ds_len, _array);
for (counter = 0; counter < array_elements; counter++) {
if (txd_used == sc->num_tx_desc_avail) {
sc->next_avail_tx_desc = txd_saved;
@@ -2481,8 +2476,7 @@ em_txeof(struct em_softc *sc)
 * If we have enough room, clear IFF_OACTIVE to tell the stack
 * that it is OK to send packets.
 */
-   if (ISSET(ifp->if_flags, IFF_OACTIVE) &&
-   num_avail > EM_TX_OP_THRESHOLD) {
+   if (num_avail > 0 && ISSET(ifp->if_flags, IFF_OACTIVE)) {
KERNEL_LOCK();
CLR(ifp->if_flags, IFF_OACTIVE);
em_start(ifp);

Re: faq 11 can be clarified

[bian]

On 2015-11-14 19:58, bian wrote:

On 2015-11-14 17:22, Mike Burns wrote:

On 2015-11-14 16.27.30 +0100, bian wrote:

* clear up the links 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64
and 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386
. The linked text refers to the page where the links are. This is not 
very
helpful as the user never would have clicked the link if the info 
already

was available. Furthermore, the linked text ends with the phrase
"problem_blurb" suggesting that it is unfinished.


Perhaps you have a patch that clarifies this?


No patch, but a short term improvement is to replace the text which
the above links point at with the text in /usr/X11R6/README included
in the 5.8 release.


Which is the following:

--- README.amd64Sun Nov 15 14:44:32 2015
+++ README.5.8  Sun Nov 15 14:45:10 2015
@@ -27,9 +27,9 @@ Conventions used in this document:

See also Xorg(1), xorg.conf(5).

-3. With X.Org XOrgVersion, you can use anti-aliased fonts in many 
applications.

+3. With X.Org 7.7, you can use anti-aliased fonts in many applications.
visit http://www.openbsd.org/faq/truetype.html for more information.

-problem_blurb
+

 $OpenBSD: README.amd64,v 1.8 2014/07/30 20:06:30 matthieu Exp $

Re: faq 11 can be clarified

[ropers]

On 15 November 2015 at 09:18, bian  wrote:

> On 2015-11-14 17:22, Mike Burns wrote:
>
> I believe Xorg -configure has been useless for a long time.
>> With a hardware that just works, X just works. If a xorg.conf is needed
>> (as when e.g. using vesa instead of a misbehaving driver),
>> it is easier to write a simple one from xorg.conf(5) by hand.
>>
>> Jan
>>
>
> This is one way of looking at it, yes. However, the quality of the
> produced xorg.conf.new is fine.
>

I realise these are relatively rare cases for maybe somewhat exotic needs,
but there are legitimate reasons why you might want to use Xorg -configure.

tl;dr: Just because you can autodetect once (i.e. "X just works") doesn't
mean you can autodetect every time.

Suppose your video output is connected using a VGA connector (not
necessarily one still on your graphics card, maybe just in the form of a
DVI to VGA adapter somewhere along the line), and suppose your VGA cabling
does not connect the I²C  / DDC <
https://en.wikipedia.org/wiki/Display_Data_Channel> pins.
Why might those pins not be connected?
First, not all 15-pin VGA cables are equal (and there even were very early
cables with a DE-9M on at least one end instead of DE-15M D-subs on both
ends, cf. ).
Second, someone might be using this kind of a balun <
http://www.dx.com/p/utp8201ar-300-single-channel-twisted-pair-vga-video-balun
-receiver-black-184382>
or any number of similar devices, which only connect 8 pins, because the
VGA signal is carried (balanced, but still carried) over existing Cat
5/6/whatever twisted pair with 8P8C/RJ45 connectors (count the shielding if
fully connected and you might say that's 9 pins).

Without the Display Data Channel, monitor/resolution/etc. autodetection
will not work.

You might still wish to rely on autodetection for initial setup, when you
would have a compatible monitor directly connected WITH DDC. Xorg
-configure would write you a nice xorg.conf.
Afterwards, in regular use, your monitor would be connected WITHOUT DDC,
preventing any sensing/plug and play/autodetection from working.

Don't assume that just because you can do X once, you'll always be able to
do X ('scuse the pun).

regards,
–ropers

Re: OT:Paris..

[Eric Furman]

I am Christian.
I have friends who are Muslim.
This is what we can both agree upon.

Outside the scope of this list
People got hurt
Can't say why
Always a bummer
Hope folks are A OK.
peace ok@ please

On Sun, Nov 15, 2015, at 04:41 AM, noah pugsley wrote:
> I hope I don't seem like a cheerleader for reflecting your sentiments.
> Null
> politics. Null comment. Geopolitical associations are outside the scope
> of
> this list.
> 
> People got hurt. Can't say why from my armchair. Always a bummer. Can't
> or
> won't do much about it but genuinely hope folks are A OK.
> 
> peace ok@?
> 
> On Sat, Nov 14, 2015 at 9:03 AM, John Long  wrote:
> 
> > Miod, are you ok? Condolences and hoping for the best for you guys.
> >
> > /jl
> >
> > --
> > ASCII ribbon campaign ( ) Powered by Lemote Fuloong
> >  against HTML e-mail   X  Loongson MIPS and OpenBSD
> >and proprietary/ \http://www.mutt.org
> >  attachments /   \  Code Blue or Go Home!
> >  Encrypted email preferred  PGP Key 2048R/DA65BC04

Sony Vaio OBSD 5.8 screen blanking forever

[Jack J. Woehr]

I've done xset s off. KDE is set not to blank.

But on my Sony Vaio OBSD 5.8 in Xwindows with any manager after about 10 
minutes of inactivity
the screen blanks and won't come back, forcing me to kill the session 
(ctl-alt-bkspc).

Must be something in the card's VGA graphics mode? Any tips or tricks?

Last note in the archives I find about this was over a decade ago.

Yes, I know about NVIDIA vs. open source operating systems but this laptop was 
used, cheap, powerful
and has a large solid-state disk :) It runs OpenBSD just great otherwise on 7 
cores and thanks to
OpenBSD porter Daniel Dickman I've got NetBeans 8.1 running on it and am in 
heaven except for the
gosh-durned screen blanking when I turn my back!

OpenBSD 5.8-stable (GENERIC.MP) #0: Fri Nov 13 18:35:52 MST 2015
root@varian.jaxrcfb:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8553762816 (8157MB)
avail mem = 8290631680 (7906MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb040 (17 entries)
bios0: vendor American Megatrends Inc. version "R0200V3" date 02/10/2011
bios0: Sony Corporation VPCF215FX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC HPET SLIC MCFG SSDT SSDT ECDT SSDT
acpi0: wakeup devices PEG0(S4) B0D4(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S4) PXSX(S4) 
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.78 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 1, core 1, package 0
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu6: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu6: 256KB 64b/line 8-way L2 cache
cpu6: smt 1, core 2, package 0
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu7: 

Re: Sony Vaio OBSD 5.8 screen blanking forever

[Dutch Ingraham]

On Sun, Nov 15, 2015 at 12:34:33PM -0700, Jack J. Woehr wrote:
> I've done xset s off. KDE is set not to blank.
> 
You could try this combination:

xset -dpms; xset s off

See xset(1).

Re: Sony Vaio OBSD 5.8 screen blanking forever

[Jack J. Woehr]

Dutch Ingraham wrote:

xset -dpms

Bingo. Thanks!

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: em(4) watchdog timeouts

[Gregor Best]

On Mon, Nov 16, 2015 at 12:05:12AM +1000, David Gwynne wrote:
> On Fri, Nov 13, 2015 at 10:18:51AM -0500, Sonic wrote:
> > On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best  wrote:
> > > I've done some further testing and I think I've narrowed it down to the
> > > "Unlocking em(4) a bit further"-patch [0].
> 
> could you try this? its not written with the wdog stuff in mind,
> but it does touch that stuff so it might help.
> [...]

Just tried it, sadly it doesn't seem to help :/

To be sure, I enabled debug on the routers em's, but apart from the watchdog 
timeout, there's nothing in there.

-- 
Gregor

Fwd: Re: pledge() enhancement

[Luke Small]

-- Forwarded message --
From: "Ingo Schwarze" 
Date: Nov 13, 2015 7:32 PM
Subject: Re: pledge() enhancement
To: "Luke Small" 
Cc: 

Hi Luke,

Luke Small wrote on Fri, Nov 13, 2015 at 06:01:37PM -0600:

> I didn't like how rmdir(2) managed to not work when there were contents to
> be deleted, so I wrote a function that would. Obviously leaving a function
> like this laying around is dangerous, especially in an application server.
> Can you put in pledge functionality that would reduce the ability to
access
> locally accessible functions?

I see why you might sometimes wish to restrict the use of functions
you write yourself inside your program.  However, that is not
possible with pledge(2), it's the wrong tool for the job.  Pledge
is a kernel feature.  When you call your own function in a userland
program, the kernel never sees the calls to that function, so it
can't do anything about it.

With pledge, it is not even possible to restrict the use of C library
functions that work without performing syscalls, for exactly the same
reason: Such calls never make it into the kernel, so the kernel cannot
intercept and deny them.

In case somebody wants to continue this discussion, please do so
on the misc@ mailing list, not on bugs@.  There is no bug here.

Yours,
  Ingo

Re: Paris..

[Marc Espie]

On Fri, Nov 13, 2015 at 04:10:53PM -0800, Ryan Freeman wrote:
> Completely off-topic but I am concerned for the .fr devs..
> 
> http://www.theglobeandmail.com/news/world/paris-police-report-shootout-at-restaurant-explosion-near-stadium/article27256201/
> 
> Can I get a ping to this thread from all the .fr folks?
> Stay strong France...

sorry, got busy on other things.
As far as i know, all .fr people are okay. some of us more than other
since we actually live in Paris.