Searched hist:144194 (Results 1 - 5 of 5) sorted by relevance

/freebsd-10.0-release/sys/x86/cpufreq/
H A Dpowernow.c144194 Sun Mar 27 19:44:21 MST 2005 njl Add the powernow driver, which handles AMD Mobile Athlon PowerNow! (k7)
and AMD Cool&Quiet PowerNow! (k8) cpufreq control. This driver is enabled
for both i386 and amd64 architectures. It has both acpi and legacy BIOS
attachments. Thanks to Bruno Ducrot for writing this driver and Jung-uk
Kim for testing.

Submitted by: Bruno Ducrot (ducrot:poupinou.org)
/freebsd-10.0-release/sys/compat/linux/
H A Dlinux_emul.hdiff 215664 Mon Nov 22 07:21:48 MST 2010 netchild By using the 32-bit Linux version of Sun's Java Development Kit 1.6
on FreeBSD (amd64), invocations of "javac" (or "java") eventually
end with the output of "Killed" and exit code 137.

This is caused by:
1. After calling exec() in multithreaded linux program threads are not
destroyed and continue running. They get killed after program being
executed finishes.

2. linux_exit_group doesn't return correct exit code when called not
from group leader. Which happens regularly using sun jvm.

The submitters fix this in a similar way to how NetBSD handles this.

I took the PRs away from dchagin, who seems to be out of touch of
this since a while (no response from him).

The patches committed here are from [2], with some little modifications
from me to the style.

PR: 141439 [1], 144194 [2]
Submitted by: Stefan Schmidt <stefan.schmidt@stadtbuch.de>, gk
Reviewed by: rdivacky (in april 2010)
MFC after: 5 days
H A Dlinux_emul.cdiff 215664 Mon Nov 22 07:21:48 MST 2010 netchild By using the 32-bit Linux version of Sun's Java Development Kit 1.6
on FreeBSD (amd64), invocations of "javac" (or "java") eventually
end with the output of "Killed" and exit code 137.

This is caused by:
1. After calling exec() in multithreaded linux program threads are not
destroyed and continue running. They get killed after program being
executed finishes.

2. linux_exit_group doesn't return correct exit code when called not
from group leader. Which happens regularly using sun jvm.

The submitters fix this in a similar way to how NetBSD handles this.

I took the PRs away from dchagin, who seems to be out of touch of
this since a while (no response from him).

The patches committed here are from [2], with some little modifications
from me to the style.

PR: 141439 [1], 144194 [2]
Submitted by: Stefan Schmidt <stefan.schmidt@stadtbuch.de>, gk
Reviewed by: rdivacky (in april 2010)
MFC after: 5 days
H A Dlinux_misc.cdiff 215664 Mon Nov 22 07:21:48 MST 2010 netchild By using the 32-bit Linux version of Sun's Java Development Kit 1.6
on FreeBSD (amd64), invocations of "javac" (or "java") eventually
end with the output of "Killed" and exit code 137.

This is caused by:
1. After calling exec() in multithreaded linux program threads are not
destroyed and continue running. They get killed after program being
executed finishes.

2. linux_exit_group doesn't return correct exit code when called not
from group leader. Which happens regularly using sun jvm.

The submitters fix this in a similar way to how NetBSD handles this.

I took the PRs away from dchagin, who seems to be out of touch of
this since a while (no response from him).

The patches committed here are from [2], with some little modifications
from me to the style.

PR: 141439 [1], 144194 [2]
Submitted by: Stefan Schmidt <stefan.schmidt@stadtbuch.de>, gk
Reviewed by: rdivacky (in april 2010)
MFC after: 5 days
/freebsd-10.0-release/sys/kern/
H A Dkern_exit.cdiff 215664 Mon Nov 22 07:21:48 MST 2010 netchild By using the 32-bit Linux version of Sun's Java Development Kit 1.6
on FreeBSD (amd64), invocations of "javac" (or "java") eventually
end with the output of "Killed" and exit code 137.

This is caused by:
1. After calling exec() in multithreaded linux program threads are not
destroyed and continue running. They get killed after program being
executed finishes.

2. linux_exit_group doesn't return correct exit code when called not
from group leader. Which happens regularly using sun jvm.

The submitters fix this in a similar way to how NetBSD handles this.

I took the PRs away from dchagin, who seems to be out of touch of
this since a while (no response from him).

The patches committed here are from [2], with some little modifications
from me to the style.

PR: 141439 [1], 144194 [2]
Submitted by: Stefan Schmidt <stefan.schmidt@stadtbuch.de>, gk
Reviewed by: rdivacky (in april 2010)
MFC after: 5 days

Completed in 270 milliseconds