Re: Scheduler hack for multi-threaded processes
Am 03/21/16 um 01:29 schrieb Mark Kettenis: > > No. It's a hack. It points out aproblem that should be investigated > deeper. > Maybe that's not only thread related. This diff only makes a difference with multi-threaded processes. It may be worth considering looking at the process level as well.
Re: Scheduler hack for multi-threaded processes
s/approves/improves/g
Re: Scheduler hack for multi-threaded processes
The java based Netbeans IDE performs a lot of things in the background using threads like indexing sources, downloading artifacts, unpacking archives, compiling sources in addition to the normal java background tasks like JIT compiling. This change approves UI responsiveness on my T60.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Am 08/09/15 um 23:38 schrieb Theo de Raadt: Awful lot of noise wherein people tell someone else what they should need to do with their time and their code. Sorry. It wasn't meant that way. I was just trying to be helpful to someone saying I don't have time for that and this effort is too much for my spare time. Not a developer. Ok. No more noise from me. Thank you everyone for providing this OS the way you do.
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Am 08/07/15 um 23:46 schrieb Alexey Suslikov: Christian Schulte cs at schulte.it writes: Now, I believe that this effort is too much for my spare time. Then why not release that scanner? That effort could be shared. What's so secret about it? You have been asked several times already. Start sharing right now. Brainy OpenBSD page contains info about lot of bugs already found. There is no secret to start writing diffs and pushing them. I was thinking about automating that process. Scan-before-commit, for example. Need not be that particular scanner. Some pre-commit analysis beyond what the compiler can warn about. How can I be sure the issues found by that scanner are not issues with the scanner itself?
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Am 08/08/15 um 15:06 schrieb Alexey Suslikov:
On Sat, Aug 8, 2015 at 2:21 PM, Christian Schulte c...@schulte.it wrote:
Am 08/07/15 um 23:46 schrieb Alexey Suslikov:
Christian Schulte cs at schulte.it writes:
Now, I believe that this effort is too much for my spare time.
Then why not release that scanner? That effort could be shared. What's
so secret about it? You have been asked several times already.
Start sharing right now. Brainy OpenBSD page contains info about
lot of bugs already found. There is no secret to start writing
diffs and pushing them.
I was thinking about automating that process. Scan-before-commit, for
example. Need not be that particular scanner. Some pre-commit analysis
beyond what the compiler can warn about. How can I be sure the issues found
by that scanner are not issues with the scanner itself?
Looks like you haven't read carefully. Quote:
Developing, improving and maintaining Brainy takes time and energy, as
well as investigating and packaging the bugs and vulnerabilities it
finds.
You already have bugs found. Next step in the process is to write diffs.
Are you referring to this?
http://m00nbsd.net/e5ab5f6e59d6a0feb7d1a518acc8233d.html
_11/ MEMORY LEAK: sys/dev/ic/ti.c rev1.15
Leak of 'm_new' with MGETHDR() at l.648.
_14/ UNINITIALIZED VARIABLE: sys/arch/hppa64/dev/apic.c rev1.8
At l.176, 'cnt' is not initialized.
Index: sys/dev/ic/ti.c
===
RCS file: /cvs/src/sys/dev/ic/ti.c,v
retrieving revision 1.12
diff -u -r1.12 ti.c
--- sys/dev/ic/ti.c 22 Dec 2014 02:28:51 - 1.12
+++ sys/dev/ic/ti.c 8 Aug 2015 15:00:55 -
@@ -655,6 +655,7 @@
if (bus_dmamap_load_mbuf(sc-sc_dmatag, dmamap, m_new,
BUS_DMA_NOWAIT)) {
+ m_freem(m_new);
m_freem(m);
return (ENOBUFS);
}
Possible memory leak in sys/dev/ic/ti.c (was: Re: Brainy: User-Triggerable Kernel Memory Leak in execve())
While at it. I cannot test this as I do not have corresponding hardware.
Index: sys/dev/ic/ti.c
===
RCS file: /cvs/src/sys/dev/ic/ti.c,v
retrieving revision 1.12
diff -u -r1.12 ti.c
--- sys/dev/ic/ti.c 22 Dec 2014 02:28:51 - 1.12
+++ sys/dev/ic/ti.c 8 Aug 2015 15:36:21 -
@@ -561,7 +561,7 @@
}
/*
- * Intialize a standard receive ring descriptor.
+ * Initialize a standard receive ring descriptor.
*/
int
ti_newbuf_std(struct ti_softc *sc, int i, struct mbuf *m,
@@ -621,7 +621,7 @@
}
/*
- * Intialize a mini receive ring descriptor. This only applies to
+ * Initialize a mini receive ring descriptor. This only applies to
* the Tigon 2.
*/
int
@@ -655,6 +655,7 @@
if (bus_dmamap_load_mbuf(sc-sc_dmatag, dmamap, m_new,
BUS_DMA_NOWAIT)) {
+ m_freem(m_new);
m_freem(m);
return (ENOBUFS);
}
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
Am 08/07/15 um 21:55 schrieb Maxime Villard: Developing, improving and maintaining Brainy takes time and energy, as well as investigating and packaging the bugs and vulnerabilities it finds. I've so far sent some reports here just because I'm friendly enough, and because modifying a few things for Brainy to properly understand the OpenBSD code does not require a Herculean work. Now, I believe that this effort is too much for my spare time. Then why not release that scanner? That effort could be shared. What's so secret about it? You have been asked several times already. Regards, -- Christian Schulte
Wrong word used in make(1) manpage.
Patch correcting a wrong word in the make(1) manpage. Index: usr.bin/make/make.1 === RCS file: /cvs/src/usr.bin/make/make.1,v retrieving revision 1.106 diff -r1.106 make.1 500c500 Redefining the corresponding suffix (or suffixes) will re-active the rule. --- Redefining the corresponding suffix (or suffixes) will re-activate the rule.
Re: PATCH: Disengaged mode for ThinkPad laptops
Am 12/09/12 20:58, schrieb Vadim Zhukov: Hello all. This is a bit improved version of the patch showed up on tech@ in... er-r-r... don't mind. This makes my ThinkPad usable under high load for more than a year, and should not cause problems mentioned before (spinning higher and lower constantly) by using two temperature marks instead of one. I also found that disengaged mode should be enabled separately off other modes, so now Alexander Polyakov's X100e should behave correctly. Any ThinkPad users willing to test? Hello, I am using a previous version of the patch with some temperature constants modified to match the temperatures my R60 produces. My R60 overheats (screen starts to flicker - system freezes) even when running the fan in disengaged mode constantly. I bet the patch will only increase the time it takes for the system to overheat. Ever run at 100% load for a few hours with a disengaged fan without problems ? -- Christian
Re: PATCH: Disengaged mode for ThinkPad laptops
Am 12/10/12 05:00, schrieb Vadim Zhukov: 10.12.2012 1:43 пользователь Christian Schulte c...@schulte.it написал: Am 12/09/12 20:58, schrieb Vadim Zhukov: Hello all. This is a bit improved version of the patch showed up on tech@ in... er-r-r... don't mind. This makes my ThinkPad usable under high load for more than a year, and should not cause problems mentioned before (spinning higher and lower constantly) by using two temperature marks instead of one. I also found that disengaged mode should be enabled separately off other modes, so now Alexander Polyakov's X100e should behave correctly. Any ThinkPad users willing to test? Hello, I am using a previous version of the patch with some temperature constants modified to match the temperatures my R60 produces. My R60 overheats (screen starts to flicker - system freezes) even when running the fan in disengaged mode constantly. I bet the patch will only increase the time it takes for the system to overheat. Ever run at 100% load for a few hours with a disengaged fan without problems ? Well, I didn't need disengaged mode on X60 Tablet, it overhearted rarely, especially if you clean up fan at least once a year. And X201i with i5 runs fine with this patch, if you doesn't place it on the wool. Could you please show dmesg and sysctl hw.sensors output from your system with any version of the patch being applied? I did not manage to solve the thermal problems I am having with the R60 in any way. Without your patch, I cannot use the machine for more than 10 minutes without overheating even when nearly idle. It also happened when the machine was brandnew. The problem was there right from the start. Replaced the fan two times already due to defects. With the latest patch applied I noticed the following: hw.sensors.acpithinkpad0.fan0=2652 RPM hw.sensors.acpithinkpad0.raw0=128 (fan mode: disengaged), WARNING It reads (fan mode: disengaged) although the fan isn't spinning full-speed. It does start spinning full-speed when getting hot. So the fan-mode string seems to not get updated correctly when switching from disengaged mode back to auto or somethng like that. dmesg and sysctl hw.sensors with your latest patch applied. Script started on Mon Dec 10 05:44:39 2012 # uptime 5:44AM up 5:30, 0 users, load averages: 0.12, 0.20, 0.26 # dmesg OpenBSD 5.2-current (GENERIC.MP) #1: Mon Dec 10 00:05:29 CET 2012 r...@r60.schulte.it:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu0: FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF real mem = 3219517440 (3070MB) avail mem = 3155935232 (3009MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/28/09, BIOS32 rev. 0 @ 0xfd690, SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version 7CETD3WW (2.23 ) date 08/28/2009 bios0: LENOVO 9461DXG acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu1: FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 92P1141 serial 3397 type LION oem SONY acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) bios0: ROM list: 0xc/0xfe00 0xdc000/0x4000! 0xe/0x1! cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE
Incompatibility between 'rthread' and 'uthread' implementation of function 'pthread_stackseg_np'.
The 'rthread' implementation of function 'pthread_stackseq_np' returns
stack information including the default guard page in 'stack_t *sinfo'
whereas the 'uthread' implementation of that function does not include
the default guard page. The following patch makes the 'rthread'
implementation behave the same way the 'uthread' implementation behaves
updating that function to stop returning references to protected memory.
Index: rthread_np.c
===
RCS file: /cvs/src/lib/librthread/rthread_np.c,v
retrieving revision 1.7
diff -u -r1.7 rthread_np.c
--- rthread_np.c18 Feb 2012 21:12:09 - 1.7
+++ rthread_np.c26 Sep 2012 22:30:46 -
@@ -71,6 +71,9 @@
#endif
sinfo-ss_sp = base;
sinfo-ss_size = thread-stack-len;
+ if (thread-stack-guardsize != 1)
+ sinfo-ss_size -= thread-stack-guardsize;
+
sinfo-ss_flags = 0;
ret = 0;
} else if (thread == _initial_thread) {
