[solved] strange artefacts with inteldrm on samsung 900X3F

2014-02-20 Thread Remi Locherer 
I installed the snapshot from February 17 and the artefacts in X are
gone. X now works fine on the Samsung 900X3F. Thanks!

On Mon, Oct 28, 2013 at 08:36:14AM +0100, Remi Locherer wrote:
 Synopsis:strange artefacts with inteldrm on samsung 900X3F
 
 Environment:
 System  : OpenBSD 5.4
 Details : OpenBSD 5.4-current (GENERIC.MP) #92: Sat Oct 26 20:22:52 MDT 
 2013

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 Architecture: OpenBSD.amd64
 Machine : amd64
 
 Description:
 Strange lines apear when running X. The longer X is running the worse 
 it gets. Sometimes the artefacts are even visible in the console  after
 terminating X. It looks the same as this bugreport for Linux that was fixed
 with Linux 3.10: https://bugs.freedesktop.org/show_bug.cgi?id=64332
 Here a picture how it looks: http://picpaste.com/D7Uf2OrP.png (also at the 
 end of the mail base64 encoded).
 
 
 dmesg:
 OpenBSD 5.4-current (GENERIC.MP) #92: Sat Oct 26 20:22:52 MDT 2013
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 3881746432 (3701MB)
 avail mem = 3770277888 (3595MB)
 User Kernel Config
 UKC disable acpitz
 357 acpitz* disabled
 UKC quit
 Continuing...
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries)
 bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013
 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI 
 MSDM UEFI UEFI
 acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) 
 PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
 PXSX(S4) RP07(S4) [...]
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpihpet0 at acpi0: 14318179 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.42 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,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
 cpu0: apic clock running at 99MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 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,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 1, core 0, package 0
 cpu2 at mainbus0: apid 2 (application processor)
 cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 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,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu2: 256KB 64b/line 8-way L2 cache
 cpu2: smt 0, core 1, package 0
 cpu3 at mainbus0: apid 3 (application processor)
 cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 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,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu3: 256KB 64b/line 8-way L2 cache
 cpu3: smt 1, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
 acpimcfg0 at acpi0 addr 0xf800, bus 0-63
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus -1 (P0P1)
 acpiprt2 at acpi0: bus 1 (RP01)
 acpiprt3 at acpi0: bus -1 (RP02)
 acpiprt4 at acpi0: bus -1 (RP03)
 acpiprt5 at acpi0: bus 2 (RP04)
 acpiprt6 at acpi0: bus 3 (RP05)
 acpiprt7 at acpi0: bus -1 (RP06)
 acpiprt8 at acpi0: bus -1 (RP07)
 acpiprt9 at acpi0: bus -1 (RP08)
 acpiprt10 at acpi0: bus -1 (PEG0)
 acpiprt11 at acpi0: bus -1 (PEG1)
 acpiprt12 at acpi0: bus -1 (PEG2)
 acpiprt13 at acpi0: bus -1 (PEG3)
 acpiec0 at acpi0
 acpicpu0 at acpi0: C3, C2, C1, PSS
 acpicpu1 at acpi0: C3, C2, C1, PSS
 acpicpu2 at acpi0: C3, C2, C1, PSS
 acpicpu3 at acpi0: C3, C2, C1, PSS
 acpipwrres0 at acpi0: FN00
 acpipwrres1 at acpi0: FN01
 acpipwrres2 at acpi0: FN02
 acpipwrres3 at acpi0: FN03
 acpipwrres4 at acpi0: FN04
 acpitz at acpi0 not configured
 acpitz at acpi0 not configured
 acpibat0 at acpi0: BAT1 not present
 acpiac0 at acpi0: AC unit offline
 acpibtn0 at acpi0: LID0
 acpibtn1 at acpi0: PWRB
 acpivideo0 at acpi0: GFX0

Re: [solved] strange artefacts with inteldrm on samsung 900X3F

2014-02-20 Thread Mark Kettenis 
 Date: Thu, 20 Feb 2014 22:49:41 +0100
 From: Remi Locherer remi.loche...@relo.ch
 
 I installed the snapshot from February 17 and the artefacts in X are
 gone. X now works fine on the Samsung 900X3F. Thanks!
 
 On Mon, Oct 28, 2013 at 08:36:14AM +0100, Remi Locherer wrote:
  Synopsis:  strange artefacts with inteldrm on samsung 900X3F
  
  Environment:
  System  : OpenBSD 5.4
  Details : OpenBSD 5.4-current (GENERIC.MP) #92: Sat Oct 26 20:22:52 MDT 
  2013


Heh, well, some significant fixes went in since then ;)

Glad it's working.

Re: Bad return value for getpwnam_r et al

2014-02-20 Thread Theo de Raadt 
  Date: Tue, 18 Feb 2014 17:01:24 +0100
  From: Ingo Schwarze schwa...@usta.de
 
   So: we need to
- clear errno in the success and no match cases,
  
  This is incorrect and shouldn't be done.
  When no error occurs, errno has to stay as it is.
 
 Indeed.  POSIX explicitly says:
 
   No function in this volume of POSIX.1-2008 shall set errno to zero.
 
 The standard is slightly ambiguous on what getpwnam_r() should do, but
 the way I read it, it should not touch errno at all.  So it should
 save errno at the start of the function, and restore it just before
 return.

That is the only sane approach.

I would like to see a diff in which at least solves the non-YP cases.
The YP cases have other issues in other functions as well, that are
somewhat known..

Re: [patch] fix ld.so crash

2014-02-20 Thread Brad Smith 

On 31/01/14 9:10 PM, Philip Guenther wrote:

On Wed, 29 Jan 2014, Sviatoslav Chagaev wrote:

When unloading, ld.so removes elements from grpref list too soon, not
allowing code which runs later to destroy objects in the list. Next time
we dlopen, there are undead objects with e.g. freed elements in child
list. Sooner or later something bad happens, in my case div by zero.

Patch:


Your patch reverts this commit:


revision 1.34
date: 2011/07/13 20:49:44;  author: drahn;  state: Exp;  lines: +4 -2;
Delete items on grpreflist when walking them to decrement the count,
otherwise double decrement can occur. ok kurt@ timeout on other reviewers.
=

I'm not sure if there's a regress for the issue Dale was fixing, but
simply reverting his fix and reintroducing the original problem isn't much
better than where we are now.

I'll stare at this some and see if I can see how to avoid leaving group
leaders on the global list...


Any update on this?

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Bad return value for getpwnam_r et al

2014-02-20 Thread Ingo Schwarze 
Hi Theo,

Theo de Raadt wrote on Thu, Feb 20, 2014 at 05:43:18PM -0700:
 kettenis@ wrote:

 Indeed.  POSIX explicitly says:
 
   No function in this volume of POSIX.1-2008 shall set errno to zero.
 
 The standard is slightly ambiguous on what getpwnam_r() should do, but
 the way I read it, it should not touch errno at all.  So it should
 save errno at the start of the function, and restore it just before
 return.

 That is the only sane approach.
 
 I would like to see a diff in which at least solves the non-YP cases.
 The YP cases have other issues in other functions as well, that are
 somewhat known..

I have sent two diffs in this thread doing that:
 * fix the return values
   http://marc.info/?l=openbsd-bugsm=139282907725368
 * and avoid clobbering errno in the non-YP case
   http://marc.info/?l=openbsd-bugsm=139283817129480

So as soon as i get OKs for them, i can commit these two.


Rushing a diff into the release to change the basic behaviour of
getpwnam_r() - i.e. no longer setting errno even in the case of
important failure - seems too dangerous and should be postponed
until after release, i think.

Yours,
  Ingo