Re: where's my pr gone? - supplemental
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/47512 this happens only with the above link, i.e. from the pr summary. searching for the bugid 47512 works (= not empty) works as well with the link 16.02.2003; 03:03:54 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
support for Tyan Thunder i7500 mobo?
Does FreeBSD work with the Tyan i7500 (S2720UGN) motherboard? I'm particularly interested in whether the on-board gigabit NIC (using the intel 82545GC chip) works with the em driver, and whether the on-board SCSI controller is properly recognized. Thanks, -Dan p.s. I posted this to the hardware mailing list a few days ago, but that list seems dead. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: where's my pr gone? - supplemental
indeed, it seems to work again On Sun, 16 Feb 2003 [EMAIL PROTECTED] wrote: Date: Sun, 16 Feb 2003 03:05:30 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: where's my pr gone? - supplemental http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/47512 this happens only with the above link, i.e. from the pr summary. searching for the bugid 47512 works (= not empty) works as well with the link 16.02.2003; 03:03:54 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ACPI: working ACPI vs broken ACPI
On Sat, Feb 15, 2003 at 08:27:45PM -0600, Mike Silbersack wrote the words in effect of: On Sat, 15 Feb 2003, Martin Blapp wrote: Feb 13 17:41:05 ibm-01 kernel: ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 Feb 13 17:41:05 ibm-01 kernel: ACPI-0625: *** Info: GPE Block1 defined as GPE32 to GPE63 I see similar errors on my Presario 2100US... Wild guess: Seem to result from this. If I'm looking at NetBSD's http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/acpi/acpi_ec.c they have a lot done since they took acpi from us. I'm sure it works for netbsd. Is anybody working on this ? Martin I've been trying to load that URL since yesterday, but it's not working from here. Can you elaborate on what it does? Try the following URL: - http://cvsweb.no.netbsd.org/bsdweb.cgi/src/sys/dev/acpi/acpi_ec.c Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ACPI throttle doesn't cool CPU
On Sat, Feb 15, 2003 at 11:18:31PM -0800, Sean Hamilton wrote: Greetings, After setting hw.acpi.cpu.performance_speed to 1, a dmesg of acpi_cpu0: set speed to 6.2% and a dog slow system, I am still finding my CPU pumping out heat. It's an AMD 1333 with an A7V board. Is this typical behaviour? If so, I'll just underclock the CPU in the bios. I was hoping to be able to run it at full speed during builds. I use ``fvcool'' and machdep.cpu_idle_hlt=1 to give a pretty impre- ssive cooling effect. When fvcool is running, the CPU temperature drops by about 10 degrees Celsius when idle. That said, I've just turned fvcool off to see if it's having some- thing to do with the ATA drive errors I'm experiencing. So far, no more drive errors, but that could mean just about anything. Trent. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Binary security updates
On Sunday 16 February 2003 02:39, Colin Percival wrote: On december 25th, I released a first draft of a binary security update tool aimed at allowing people to track the security branches without keeping a source tree or recompiling; the response was generally positive, but as I pointed out in my announcement, there were several problems which needed to be fixed. I'm just about finished fixing up all those details, and I intend to release a new version soon and start publishing the necessary updates for i386 4.8-RELEASE when it comes out (not that I expect 4.8-RELEASE to include any security holes, of course ;). These would, of course, be freely available (although I might ask for donations to cover bandwidth costs if I get lots of traffic). Would any FreeBSD developer(s) be willing to help me with this? I'd very much like to have at least one person look over my code and give it some sort of stamp of approval; both for my own peace of mind and to make people feel more happy about using it. If you are willing to do the work, I'm certain we can track down some mirror sites willing to bear the traffic for you. We'll bring the efforts of the Donations Liason Officer, Michael W. Lucas, to bear on this. All you need to do is let him know what resources you will need. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: where's my pr gone? - supplemental
At 12:05 AM +0100 2/16/03, Friedemann Becker wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/47512 this happens only with the above link, i.e. from the pr summary. searching for the bugid 47512 works (= not empty) someone want to look at this? The above link worked fine for me. I did not get a blank page. Also, doing an 'ls' in bash, after starting 'gdb bash', did not cause any kernel panic. But then it occurred to me that my login shell was bash (ie, I was already in bash when I typed the 'gdb bash' command). So, I logged into 'toor', which has /bin/sh as the login shell. If I logged in at the console, and did a 'gdb bash', then when I tried to do a 'run' I was told: Starting program: /usr/local/bin/bash Cannot exec : No such file or directory So, then I ssh'ed into 'toor', to make it easier to copypaste that error message into this email. Behold, it worked fine. Well, there was a complaint of: Starting program: /usr/local/bin/bash warning: shared library handler failed to enable breakpoint but other than that warning it worked fine (as did the 'ls'). Sooo, then I checked to see what the difference was between the two sessions. It turned out that when logging into the console, the SHELL environment variable was set to the null string. When I ssh'ed in, it was set to /bin/sh. If I set SHELL on the console session, then gdb could run bash OK. I'm not quite sure what all of that means... All of this was done an a FreeBSD 5.0-CURRENT system, built on Sat Feb 15 01:34:07 EST 2003 -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Need an expert's advise on WITNESS problem(?) (very long)
Dear Hackers,
I need an expert's advice on the small locking/WITNESS problem
(if this is a real problem of course). It basically boils down
to the following:
Consider three (3) MTX_DEF mutexes: A, B1 and B2. Mutex A has a
name mutex_A and type type_A. Mutex B1 has a name mutex_B1
and mutex B2 has name mutex_B2. Both mutex B1 and B2 have the
same type type_B. Please note that mutexes B1 and B2 are
completely independent from each other. They just have the same
mutex type (B1 and B2 are used for fine grained locking).
Now consider the code that has two (2) paths: P1 and P2.
On the path P1 the code first acquires mutex A and then mutex
B1. Then the code releases mutex B1 and then mutex A.
On the path P2 the code first acquires mutex B2 and then mutex
A. Then the code releases mutex B2 and then mutex A.
So the code's flow looks something like this
--\ /-- B1 -- Code path P1
A
--/ \-- B2 -- Code path P2
Now the problem (again if this is a problem) is that WITNESS
code builds relations between mutex types (or at least I think
it does). So when the code runs, WITNESS will build relations
between mutex types for the first path the code follows (lets
say P1). Later when the code follows the second path (in this
example P2), WITNESS will create lock order reversal message.
The questions are:
1) Is anything wrong with the such code and/or mutex use?
Since mutexes B1 and B2 are completely independent, there
is no deadlock danger, right? Please tell me if I'm wrong
and missing something here.
2) Is there any way to resolve the problem? I'm prepared to
change/re-design my code if needed.
3) Is WITNESS right in this case?
I have attached a small spherical cow that demonstrates
the example above. Just compile and load ng_cow.ko module
and then try
# ngctl msg cow: moo
Please advise.
thanks,
max
Makefile
CFLAGS+=-g
KMOD= ng_cow
SRCS= ng_cow.c
NOMAN=
.include bsd.kmod.mk
=== ng_cow.c ==
#include sys/param.h
#include sys/systm.h
#include sys/errno.h
#include sys/kernel.h
#include sys/lock.h
#include sys/malloc.h
#include sys/mbuf.h
#include sys/mutex.h
#include netgraph/ng_message.h
#include netgraph/netgraph.h
#include netgraph/ng_parse.h
#define NG_COW_NODE_TYPEcow
#define NGM_COW_COOKIE 1018303300
#define NGM_COW_MOO 1
#ifdef NG_SEPARATE_MALLOC
MALLOC_DEFINE(M_NETGRAPH_COW, cow, Netgraph spherical cow);
#else
#define M_NETGRAPH_COW M_NETGRAPH
#endif
static ng_constructor_t ng_cow_constructor;
static ng_rcvmsg_t ng_cow_rcvmsg;
static ng_shutdown_tng_cow_shutdown;
static ng_newhook_t ng_cow_newhook;
static ng_connect_t ng_cow_connect;
static ng_rcvdata_t ng_cow_rcvdata;
static ng_disconnect_t ng_cow_disconnect;
static int ng_cow_modevent (module_t, int, void *);
static const struct ng_cmdlist ng_cow_cmdlist[] = {
{
NGM_COW_COOKIE,
NGM_COW_MOO,
moo,
NULL,
NULL
},
{ 0, }
};
static struct ng_type typestruct = {
NG_ABI_VERSION,
NG_COW_NODE_TYPE, /* typename */
ng_cow_modevent,/* modevent */
ng_cow_constructor, /* constructor */
ng_cow_rcvmsg, /* control message */
ng_cow_shutdown,/* destructor */
ng_cow_newhook, /* new hook */
NULL, /* find hook */
ng_cow_connect, /* connect hook */
ng_cow_rcvdata, /* data */
ng_cow_disconnect, /* disconnect hook */
ng_cow_cmdlist /* node command list */
};
NETGRAPH_INIT(cow, typestruct);
MODULE_VERSION(ng_cow, 1);
static node_p the_node = NULL;
static struct mtx a, b1, b2;
static int
ng_cow_modevent(module_t mod, int event, void *data)
{
int error = 0;
switch (event) {
case MOD_LOAD:
error = ng_make_node_common(typestruct, the_node);
if (error != 0)
break;
error = ng_name_node(the_node, NG_COW_NODE_TYPE);
if (error != 0) {
NG_NODE_UNREF(the_node);
the_node = NULL;
break;
}
mtx_init(a, mutex_A, type_A, MTX_DEF);
mtx_init(b1, mutex_B1, type_B, MTX_DEF);
mtx_init(b2, mutex_B2, type_B, MTX_DEF);
break;
case MOD_UNLOAD:
mtx_destroy(a);
mtx_destroy(b1);
mtx_destroy(b2);
break;
default:
error = EOPNOTSUPP;
break;
}
return (error);
}
static int
ng_cow_constructor(node_p node)
{
return (EINVAL);
}
static int
ng_cow_newhook(node_p node, hook_p hook, char const *name)
{
return
Multi-level jailing.
Hello hackers. I have prepared patch for jail functionality against FreeBSD 5.0-CURRENT. It provides multi-level jailing and multiple ips for jails. Example of use: IPS on machine: tl0: 12.34.56.1 12.34.56.2 12.34.56.3 10.10.10.1 fxp0: 98.76.54.32 98.76.54.31 You can create jails inside of jails: # jail / jail-1 12.34.56.1,12.34.56.2,10.10.10.1,98.76.54.31 /bin/sh [ we are in jail-1 ] # jail / jail-2 12.34.56.1,10.10.10.1,98.76.54.31 /bin/sh [ we are in jail-2 ] # jail / jail-3 12.34.56.1,98.76.54.31 /bin/sh [ we are in jail-3 ] # jail / jail-4 12.34.56.1,10.10.10.1 /bin/sh [ EINVAL, because we are already jailed and want to take IP from outside the jail ] Only processes from jail-2, jail-3 and jail-4 and jail-1 are visable in jail-1. Only processes from jail-4 and jail-3 are visable in jail-3. Jail-2 is child of jail-1, jail-1 is parent of jail-2, jail-3 is child of jail-2, jail-2 is parent of jail-3. If Parent exits, parent of parent will be new parent - If last process of jail-2 exits jail-1 became parent of jail-3 and jail-3 became child of jail-1. Ifconfigs from jails: jail-1# ifconfig rl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet 12.34.56.1 netmask 0xff00 broadcast 12.34.56.255 inet 12.34.56.2 netmask 0x broadcast 12.34.56.2 inet 10.10.10.1 netmask 0x broadcast 10.10.255.255 ether 00:11:22:33:44:55 media: Ethernet autoselect (100baseTX full-duplex) status: active rl1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 98.76.54.31 netmask 0x broadcast 98.76.54.31 ether ff:ee:dd:cc:bb:aa media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 jail-2# ifconfig rl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet 12.34.56.1 netmask 0xff00 broadcast 12.34.56.255 inet 10.10.10.1 netmask 0x broadcast 10.10.255.255 ether 00:11:22:33:44:55 media: Ethernet autoselect (100baseTX full-duplex) status: active rl1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 98.76.54.31 netmask 0x broadcast 98.76.54.31 ether ff:ee:dd:cc:bb:aa media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 jail-3# ifconfig rl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet 12.34.56.1 netmask 0xff00 broadcast 12.34.56.255 ether 00:11:22:33:44:55 media: Ethernet autoselect (100baseTX full-duplex) status: active rl1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 98.76.54.31 netmask 0x broadcast 98.76.54.31 ether ff:ee:dd:cc:bb:aa media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 Patch is attached and also avaliable with README file here: http://garage.freebsd.pl/mljail.tbz -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg39976/pgp0.pgp Description: PGP signature
Re: Multi-level jailing.
Now patch is attached:)
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
diff -ru /usr/src/sys/kern/kern_jail.c ./sys/kern/kern_jail.c
--- /usr/src/sys/kern/kern_jail.c Tue Jan 21 09:55:54 2003
+++ ./sys/kern/kern_jail.c Mon Feb 17 07:11:42 2003
@@ -6,7 +6,7 @@
* this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
*
*
- * $FreeBSD: src/sys/kern/kern_jail.c,v 1.29 2003/01/21 08:55:54 alfred Exp $
+ * $FreeBSD$
*
*/
@@ -28,6 +28,14 @@
MALLOC_DEFINE(M_PRISON, prison, Prison structures);
+#ifndef OLDJAIL
+SLIST_HEAD(, prison_children) prison_head =
+SLIST_HEAD_INITIALIZER(prison_head);
+struct mtx prison_head_mtx;
+MTX_SYSINIT(prison_head_lock, prison_head_mtx, prison_head mutex lock,
+MTX_DEF);
+#endif
+
SYSCTL_DECL(_security);
SYSCTL_NODE(_security, OID_AUTO, jail, CTLFLAG_RW, 0,
Jail rules);
@@ -65,11 +73,18 @@
struct jail j;
struct chroot_args ca;
struct ucred *newcred = NULL, *oldcred;
+#ifndef OLDJAIL
+ u_int i;
+#endif
error = copyin(uap-jail, j, sizeof j);
if (error)
return (error);
+#ifdef OLDJAIL
if (j.version != 0)
+#else
+ if (j.version != 1)
+#endif
return (EINVAL);
MALLOC(pr, struct prison *, sizeof *pr , M_PRISON, M_ZERO);
@@ -85,12 +100,40 @@
if (error)
goto bail;
newcred = crget();
+#ifdef OLDJAIL
pr-pr_ip = j.ip_number;
+#else
+ MALLOC(pr-pr_ips, u_int32_t *, sizeof(u_int32_t) * j.nips, M_PRISON,
+ 0);
+ error = copyin(j.ips, pr-pr_ips, sizeof(u_int32_t) * j.nips);
+ if (error) {
+ FREE(pr-pr_ips, M_PRISON);
+ goto bail;
+ }
+ if (jailed(p-p_ucred)) {
+ for (i = 0; i j.nips; ++i) {
+ if (!prison_validip(p-p_ucred, pr-pr_ips[i])) {
+ error = EINVAL;
+ FREE(pr-pr_ips, M_PRISON);
+ goto bail;
+ }
+ }
+ }
+ pr-pr_nips = j.nips;
+#endif
+
+#ifdef OLDJAIL
PROC_LOCK(p);
/* Implicitly fail if already in jail. */
error = suser_cred(p-p_ucred, 0);
if (error)
goto badcred;
+#else
+ pr-pr_pprison = p-p_ucred-cr_prison;
+ SLIST_INIT(pr-pr_children);
+ prison_addchild(p-p_ucred-cr_prison, pr);
+ PROC_LOCK(p);
+#endif
oldcred = p-p_ucred;
crcopy(newcred, oldcred);
p-p_ucred = newcred;
@@ -99,7 +142,9 @@
PROC_UNLOCK(p);
crfree(oldcred);
return (0);
+#ifdef OLDJAIL
badcred:
+#endif
PROC_UNLOCK(p);
crfree(newcred);
bail:
@@ -111,14 +156,56 @@
void
prison_free(struct prison *pr)
{
+#ifndef OLDJAIL
+ struct prison_children *pc;
+ struct prison *ppr;
+#endif
mtx_lock(pr-pr_mtx);
pr-pr_ref--;
if (pr-pr_ref == 0) {
+#ifndef OLDJAIL
+ ppr = pr-pr_pprison;
+ pc = NULL;
+ if (ppr == NULL) {
+ mtx_lock(prison_head_mtx);
+ SLIST_FOREACH(pc, prison_head, pc_next) {
+ if (pc-pc_child == pr)
+ break;
+ }
+ SLIST_REMOVE(prison_head, pc, prison_children,
+ pc_next);
+ } else {
+ SLIST_FOREACH(pc, ppr-pr_children, pc_next) {
+ if (pc-pc_child == pr)
+ break;
+ }
+ SLIST_REMOVE(ppr-pr_children, pc, prison_children,
+ pc_next);
+ }
+ KASSERT(pc != NULL, (Child have to be on list.));
+ FREE(pc, M_PRISON);
+ SLIST_FOREACH(pc, pr-pr_children, pc_next) {
+ mtx_lock(pc-pc_child-pr_mtx);
+ pc-pc_child-pr_pprison = ppr;
+ mtx_unlock(pc-pc_child-pr_mtx);
+ if (ppr == NULL)
+ SLIST_INSERT_HEAD(prison_head, pc, pc_next);
+ else {
+ SLIST_INSERT_HEAD(ppr-pr_children, pc,
+ pc_next);
+ }
+ }
+ if (ppr == NULL)
+ mtx_unlock(prison_head_mtx);
+#endif /* !OLDJAIL */
mtx_unlock(pr-pr_mtx);
mtx_destroy(pr-pr_mtx);
if (pr-pr_linux != NULL)
FREE(pr-pr_linux, M_PRISON);
+#ifndef OLDJAIL
+ FREE(pr-pr_ips, M_PRISON);
+#endif
FREE(pr, M_PRISON);
return;
}
@@
