Re: disklabel/bsdlabel and md(4) devices
On Wed, May 28, 2003 at 09:54:37PM +1000, Tim Robbins wrote: [...] # disklabel -r -w md0 auto disklabel: Geom not specified Hmm. Ignore this, rebuilding bsdlabel seems to fix the problem. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
David Leimbach wrote: I have the GPLd source to the nforce drivers for Linux to support the nVidia nforce and nforce2 drivers in the kernel. To port these to FreeBSD would be an interesting task [if it hasn't already been done] and I have been looking for an excuse to get down and dirty with FBSD. [Yes... talk is cheap... just do it... Nike-a-go-go etc etc... :)] What is the policy on drivers that are clearly going to have to be GPLd by the viral clause since I am referencing a GPL driver to do the porting work myself? Are these allowed in the kernel? Well, you can't have a GPL driver in the kernel. But, alas, what in the kernel means is a bit fuzzy. Basically, no GPL code will go in GENERIC, because GENERIC is what we distribute, and having any GPL code in it would automatically taint the rest of the kernel. Also, there's some dispute on whether something that is linkable to the kernel, like a kernel module, would taint the kernel too. LGPL is preferred because there's no such doubts in this case. But I think the general consensus is that a kernel module can't taint the kernel. This would cause trouble mostly for installation. A user, of course, is free to compile a kernel with all the GPL code he wants. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The one you want is never the one on sale. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
mb alloc and: panic: mutex Giant not owned at../../../vm/vm_kern.c:315
Got this panic recently on a MAC development box. The MAC development
branch hasn't been integrated in a few weeks, so this might well be fixed
in the main tree. The versions of various files are:
$FreeBSD: src/sys/vm/vm_kern.c,v 1.97 2003/04/15 01:16:05 alc Exp $
$FreeBSD: src/sys/kern/subr_mbuf.c,v 1.47 2003/05/02 03:43:40 silby Exp $
I haven't seen this panic previously; a lack of Giant coming out of the
socket code is a bit surprising to me, but I think is unlikely to be a
result of our local MAC tweaks.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
118a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout
/usr/X11R6/lib/aout
118/etc/rc: INFO: nfsd depends on mountd, which will be forced to start.
118Starting mountd.
118Starting nfsd.
panic: mutex Giant not owned at ../../../vm/vm_kern.c:315
P
Debugger(c04ec67c,c0586b60,c04ebdc3,c8cddb2c,1) at Debugger+0x54
db trace
Debugger(c04ec67c,c0586b60,c04ebdc3,c8cddb2c,1) at Debugger+0x54
panic(c04ebdc3,c04ebefc,c050050a,13b,c04eaf98) at panic+0xab
_mtx_assert(c0584ee0,1,c050050a,13b,4) at _mtx_assert+0xec
kmem_malloc(c0b7f000,2000,2,230,163) at kmem_malloc+0x39
mb_pop_cont(c0587c20,8,c0b6cac0,2c7,c0b7d700) at mb_pop_cont+0xa0
mb_alloc(c0587c20,8,e,0,0) at mb_alloc+0x217
m_get(8,e,5f7,c04eef16,0) at m_get+0x34
sockargs(c8cddc4c,bfbfd550,60,e,c8cddc68) at sockargs+0x4a
sendit(c192b4c0,c,c8cddcb4,0,806b000) at sendit+0x91
sendmsg(c192b4c0,c8cddd10,c050602b,3fb,3) at sendmsg+0xc2
syscall(2f,2f,2f,bfbfd5b0,20) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x280d24b3, esp =
0xbfbfd52c, ebp = 0xbfbfd5d8 ---
db show pcpu
cpuid= 0
curthread= 0xc192b4c0: pid 275 rpcbind
curpcb = 0xc8cddda0
fpcurthread = none
idlethread = 0xc0b88850: pid 11 idle
currentldt = 0x28
spin locks held:
(kgdb) l *kmem_malloc+0x39
0xc043eea9 is in kmem_malloc (../../../vm/vm_kern.c:317).
312 int pflags;
313
314 if ((flags M_NOWAIT) == 0)
315 GIANT_REQUIRED;
316
317 size = round_page(size);
318 addr = vm_map_min(map);
319
320 /*
321 * Locate sufficient space in the map. This will give us
the final
(kgdb) l *mb_pop_cont+0xa0
0xc0334e10 is in mb_pop_cont (../../../kern/subr_mbuf.c:573).
568 bucket = malloc(sizeof(struct mb_bucket) +
569 mb_list-ml_objbucks * sizeof(void *), M_MBUF,
MBTOM(how));
570 if (bucket == NULL)
571 return (NULL);
572
573 p = (caddr_t)kmem_malloc(mb_list-ml_map,
mb_list-ml_objsize *
574 mb_list-ml_objbucks, MBTOM(how));
575 if (p == NULL) {
576 free(bucket, M_MBUF);
577 if (how == M_TRYWAIT)
(kgdb) l *mb_alloc+0x217
0xc0336057 is in mb_alloc (../../../kern/subr_mbuf.c:712).
707 } else {
708 /*
709 * We'll have to allocate a new page.
710 */
711 MB_UNLOCK_CONT(gen_list);
712 bucket = mb_pop_cont(mb_list, how,
cnt_lst);
713 if (bucket != NULL) {
714 MB_GET_OBJECT(m, bucket, cnt_lst);
715 MB_MBTYPES_INC(cnt_lst, type, 1);
716
(kgdb) l *m_get+0x34
0xc0335354 is in m_get (../../../kern/subr_mbuf.c:1186).
1181struct mbuf *
1182m_get(int how, short type)
1183{
1184struct mbuf *mb;
1185
1186mb = (struct mbuf *)mb_alloc(mb_list_mbuf, how, type, 0,
NULL);
1187if (mb != NULL)
1188_mb_setup(mb, type);
1189return (mb);
1190}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BCM5703 GigE ifs on Supermicro X5DL8-GG m/b not detectedon5.1-BETA2 or 4.8 (resolved)
Just to bring the list up to date, I went onsite, popped the case open, and guess what I saw.. SUPER X5DP8-G2 REV 1.2 rather than X5DL8-GG, so it looks like the vendor pulled a fast one. spec sheet on that lists onboard Intel 82546EB dual port GigE, but note that I've already got one single port Pro/1000XT and one dual port Pro/1000MT in there, so I should've been seeing 5 em rather than 3. Turned out the MT was the one that was hiding, but after a bit more testing, I managed to get everything to appear by turning down the first 3 PCI slots to 33mhz from 133, 100, 100. I then set speed back to auto, it autosensed 133, 100, 100, and everything showed up again. Did a few more reboots, and it seems to be OK. big thanks to everyone, especially mark for making me verify whether reality actually matched documentation :) John On Wed, 28 May 2003, Doug White wrote: On Fri, 23 May 2003, Tom Samplonius wrote: I don't know about Supermicro, but ASUS uses Broadcom chips with an Intel chipset on at least one workstation board: http://usa.asus.com/prog/spec.asp?langs=09m=P4G8X%20Deluxe Okay so the crack pipe is being passed around :) And what happened to my pciconf -lv output? :) Also, 'pciconf -lv' output is more useful, it'll print the text strings and make identifying the proper ID much easier. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, May 28, 2003 at 06:40:46PM +0930, Daniel O'Connor wrote: On Wed, 28 May 2003 18:39, M. Warner Losh wrote: : : Maybe the kernel build stuff can look in /usr/local/src/sys/modules : : for things to build or something.. : : YUCK! : : *WHY?* : : I have asked this before BTW, and I haven't been told why it sucks. Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. If there are more elegant solutions I would like to know what they are. I agree it isn't a great solution, but I can't see what is better. For GPL modules, put them in src/sys/gnu. If you don't want bloat, then use cvsup and a refuse file to not retrieve the sys/gnu. See the discussion that occurred many years ago when maestro3 support was committed to the tree. For non-viral licensed code, put it in its proper place in the sys/ hierarchy. Then use a WANT_XXX=yes knob in the /etc/make.conf to cause XXX to be built. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
Steve Kargl wrote: On Wed, May 28, 2003 at 06:40:46PM +0930, Daniel O'Connor wrote: On Wed, 28 May 2003 18:39, M. Warner Losh wrote: : : Maybe the kernel build stuff can look in /usr/local/src/sys/modules : : for things to build or something.. : : YUCK! : : *WHY?* : : I have asked this before BTW, and I haven't been told why it sucks. Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. If there are more elegant solutions I would like to know what they are. I agree it isn't a great solution, but I can't see what is better. For GPL modules, put them in src/sys/gnu. If you don't want bloat, then use cvsup and a refuse file to not retrieve the sys/gnu. See the discussion that occurred many years ago when maestro3 support was committed to the tree. For non-viral licensed code, put it in its proper place in the sys/ hierarchy. Then use a WANT_XXX=yes knob in the /etc/make.conf to cause XXX to be built. It should be noted that the maestro3 case only involved the firmware being GPL, not the whole driver (I and the other author had explicit permission to license the kernel portion as BSDL). I still wonder about the validity of GPLing hexidecimal digits that represent binary machine code. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/contrib/dev/acpica - Imported sources
--On Wednesday, May 28, 2003 03:59:24 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: Ok, with today's sources, I still get a page not present panic for address (0x7) on transistion to battery. as a followup, with this code, I no longer get the panic at ACPI shutdown, just some messages about references. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mb alloc and: panic: mutex Giant not owned at../../../vm/vm_kern.c:315
On Wed, May 28, 2003 at 10:06:14AM -0400, Robert Watson wrote: I haven't seen this panic previously; a lack of Giant coming out of the socket code is a bit surprising to me, but I think is unlikely to be a result of our local MAC tweaks. This may be my fault, as I made some changes recently that assumed that the mbuf allocator grabbed giant when needed. I'll check the code path you've mentioned to see if it grabs giant now, but I suspect that I just need to move the giant grabbing back where it was before. David. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mb alloc and: panic: mutex Giant not owned at../../../vm/vm_kern.c:315
On Wed, 28 May 2003, David Malone wrote: On Wed, May 28, 2003 at 10:06:14AM -0400, Robert Watson wrote: I haven't seen this panic previously; a lack of Giant coming out of the socket code is a bit surprising to me, but I think is unlikely to be a result of our local MAC tweaks. This may be my fault, as I made some changes recently that assumed that the mbuf allocator grabbed giant when needed. I'll check the code path you've mentioned to see if it grabs giant now, but I suspect that I just need to move the giant grabbing back where it was before. This doesn't seem to be a reproduceable problem for me, FWIW, (presumably a property of bucket sizes, etc) so you have all the information I have :-). If possible, we should get this fix in for 5.1? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mb alloc and: panic: mutex Giant not owned at../../../vm/vm_kern.c:315
On Wed, May 28, 2003 at 10:06:14AM -0400, Robert Watson wrote: Got this panic recently on a MAC development box. The MAC development branch hasn't been integrated in a few weeks, so this might well be fixed in the main tree. The versions of various files are: $FreeBSD: src/sys/vm/vm_kern.c,v 1.97 2003/04/15 01:16:05 alc Exp $ $FreeBSD: src/sys/kern/subr_mbuf.c,v 1.47 2003/05/02 03:43:40 silby Exp $ I haven't seen this panic previously; a lack of Giant coming out of the socket code is a bit surprising to me, but I think is unlikely to be a result of our local MAC tweaks. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories 118a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout 118/etc/rc: INFO: nfsd depends on mountd, which will be forced to start. 118Starting mountd. 118Starting nfsd. panic: mutex Giant not owned at ../../../vm/vm_kern.c:315 P Debugger(c04ec67c,c0586b60,c04ebdc3,c8cddb2c,1) at Debugger+0x54 db trace Debugger(c04ec67c,c0586b60,c04ebdc3,c8cddb2c,1) at Debugger+0x54 panic(c04ebdc3,c04ebefc,c050050a,13b,c04eaf98) at panic+0xab _mtx_assert(c0584ee0,1,c050050a,13b,4) at _mtx_assert+0xec kmem_malloc(c0b7f000,2000,2,230,163) at kmem_malloc+0x39 mb_pop_cont(c0587c20,8,c0b6cac0,2c7,c0b7d700) at mb_pop_cont+0xa0 mb_alloc(c0587c20,8,e,0,0) at mb_alloc+0x217 m_get(8,e,5f7,c04eef16,0) at m_get+0x34 sockargs(c8cddc4c,bfbfd550,60,e,c8cddc68) at sockargs+0x4a sendit(c192b4c0,c,c8cddcb4,0,806b000) at sendit+0x91 sendmsg(c192b4c0,c8cddd10,c050602b,3fb,3) at sendmsg+0xc2 syscall(2f,2f,2f,bfbfd5b0,20) at syscall+0x26e Xint0x80_syscall() at Xint0x80_syscall+0x1d The change that seems to have done this is: Revision 1.146, Mon May 5 20:33:37 2003 UTC (3 weeks, 1 day ago) by dwmalone Branch: MAIN CVS Tags: HEAD Changes since 1.145: +65 -50 lines Split sendit into two parts. The first part, still called sendit, that does the copyin stuff and then calls the second part kern_sendit to do the hard work. Don't bother holding Giant during the copyin phase. The intent of this is to allow the Linux emulator to impliment send* syscalls without using the stackgap. The problem is that Giant is no longer held in the early parts of sendit which may include the sockargs() call which may end up allocating an mbuf which may end up occasionally calling the VM if the cache is empty. The panic gets triggered in the VM because the call is being made with WAITOK or TRYWAIT. Moving the Giant acquisition from kern_sendit() back to the top of sendit() should fix it, but I'm CCing dwmalone on this to see what he thinks is the best approach. Regards, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mb alloc and: panic: mutex Giant not owned at../../../vm/vm_kern.c:315
This may be my fault, as I made some changes recently that assumed that the mbuf allocator grabbed giant when needed. I'll check the code path you've mentioned to see if it grabs giant now, but I suspect that I just need to move the giant grabbing back where it was before. This doesn't seem to be a reproduceable problem for me, FWIW, (presumably a property of bucket sizes, etc) so you have all the information I have :-). You'd have to be quite unlucky to trigger it (calling sendit at a time when a per-cpu mbuf pool was empty). I have a vague feeling that my sendit change isn't the only place that does this. If possible, we should get this fix in for 5.1? Yep - from what Bosko says, my change shouldn't have been safe. I'll produce a patch and run it by him, and then talk to [EMAIL PROTECTED] David. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc/libm floating-point bug?
On Tue, 27 May 2003, Terry Lambert wrote: BTW: signal stacks are irrelevent; technically, you are not allowed to do floating point in signal handlers anyway. 8-). Not true. Signal handlers can do almost anything with local variables. The main relevant restrictions on them is that they must not access any static or global variables (other than write-only accesses to objects whose type is volatile sig_atomic_t) or call any functions that might make such accesses (which rules out calling most functions including everything in libm). These restrictions (and bugs) just make doing floating in signal handlers not very useful. Doing significant floating point calculations in signal handlers might involve duplicating functions from libm inline or as signal-safe private functions. Outputting the results or otherwise influencing the world might involve converting the results to arrays of bits and assigning the bits to sig_atomic_t objects for later interpretation. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
3dmd broken
Hi, I installed 3dmd the webtool for 3ware Raid controllers, I left the config untouched or set whatever port, the prog starts but doesnt bind any port, thus no connection possible, is it broken ? im on 5.1b id be interested if anyone running it with 5.1b thx alot Christophe -- Christophe Zwecker mail: [EMAIL PROTECTED] Hamburg, Germanyfon: +49 179 3994867 http://www.zwecker.de Who is General Failure ? And why is he reading my disk ?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc/libm floating-point bug?
In article [EMAIL PROTECTED], Bruce Evans [EMAIL PROTECTED] wrote: On Tue, 27 May 2003, Terry Lambert wrote: BTW: signal stacks are irrelevent; technically, you are not allowed to do floating point in signal handlers anyway. 8-). Not true. Signal handlers can do almost anything with local variables. The main relevant restrictions on them is that they must not access any static or global variables (other than write-only accesses to objects whose type is volatile sig_atomic_t) or call any functions that might make such accesses (which rules out calling most functions including everything in libm). Those are the rules set forth by the C standard, but POSIX.1 demands much more from the implementation. There's a whole list of functions that POSIX says must be safely callable from signal handlers. Almost all of the I/O calls are included. Even fork and exec[lv]e must be callable from signal handlers. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Two buttocks cannot avoid friction. -- Malawi saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3dmd broken
Hi,
I installed 3dmd the webtool for 3ware Raid controllers, I left the
config untouched or set whatever port, the prog starts but doesnt bind
any port, thus no connection possible, is it broken ?
im on 5.1b
id be interested if anyone running it with 5.1b
If you unpack the following snippet
---
begin 644 3dmd.bpatch.144284
6#[IL)`0-N/L```#-@'+KA=)T`C'`PP``
`
end
---
using uudecode, you should get the following checksum:
MD5 (3dmd.bpatch.144284) = b1116c4846262ee3d523db05b82717c3
To apply:
cp -p 3dmd 3dmd.FCS
dd if=3dmd.bpatch.144284 of=3dmd seek=144284 bs=1 conv=notrunc
After which you should have the following checksums:
MD5 (3dmd.FCS) = e6b0212a2b7ce6f4892fea7751c8d711
MD5 (3dmd) = 8e2254774524dcc88d31acb8c4882779
The above patch changes 3dmd to supply the RFTRHEAD argument to rfork().
An alternative fix is to apply the enclosed patch, which adds tracking
of (process leader, file descriptor table) tuples.
- Tor Egge
Index: sys/kern/kern_fork.c
===
RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.198
diff -u -r1.198 kern_fork.c
--- sys/kern/kern_fork.c13 May 2003 20:35:59 - 1.198
+++ sys/kern/kern_fork.c18 May 2003 15:01:14 -
@@ -139,13 +139,6 @@
/* Don't allow kernel only flags. */
if ((uap-flags RFKERNELONLY) != 0)
return (EINVAL);
- /*
-* Don't allow sharing of file descriptor table unless
-* RFTHREAD flag is supplied
-*/
- if ((uap-flags (RFPROC | RFTHREAD | RFFDG | RFCFDG)) ==
- RFPROC)
- return(EINVAL);
error = fork1(td, uap-flags, 0, p2);
if (error == 0) {
td-td_retval[0] = p2 ? p2-p_pid : 0;
@@ -209,6 +202,7 @@
int ok;
static int pidchecked = 0;
struct filedesc *fd;
+ struct filedesc_to_leader *fdtol;
struct proc *p1 = td-td_proc;
struct thread *td2;
struct kse *ke2;
@@ -419,15 +413,40 @@
/*
* Copy filedesc.
*/
- if (flags RFCFDG)
+ if (flags RFCFDG) {
fd = fdinit(td-td_proc-p_fd);
- else if (flags RFFDG) {
+ fdtol = NULL;
+ } else if (flags RFFDG) {
FILEDESC_LOCK(p1-p_fd);
fd = fdcopy(td-td_proc-p_fd);
FILEDESC_UNLOCK(p1-p_fd);
- } else
+ fdtol = NULL;
+ } else {
fd = fdshare(p1-p_fd);
-
+ if (p1-p_fdtol == NULL)
+ p1-p_fdtol =
+ filedesc_to_leader_alloc(NULL,
+NULL,
+p1-p_leader);
+ if ((flags RFTHREAD) != 0) {
+ /*
+* Shared file descriptor table and
+* shared process leaders.
+*/
+ fdtol = p1-p_fdtol;
+ FILEDESC_LOCK(p1-p_fd);
+ fdtol-fdl_refcount++;
+ FILEDESC_UNLOCK(p1-p_fd);
+ } else {
+ /*
+* Shared file descriptor table, and
+* different process leaders
+*/
+ fdtol = filedesc_to_leader_alloc(p1-p_fdtol,
+p1-p_fd,
+p2);
+ }
+ }
/*
* Make a proc table entry for the new process.
* Start by zeroing the section of proc that is zero-initialized,
@@ -506,6 +525,7 @@
if (p2-p_textvp)
VREF(p2-p_textvp);
p2-p_fd = fd;
+ p2-p_fdtol = fdtol;
PROC_UNLOCK(p1);
PROC_UNLOCK(p2);
Index: sys/kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.196
diff -u -r1.196 kern_descrip.c
--- sys/kern/kern_descrip.c 15 May 2003 21:13:08 - 1.196
+++ sys/kern/kern_descrip.c 20 May 2003 13:42:01 -
@@ -73,6 +73,8 @@
#include vm/uma.h
static MALLOC_DEFINE(M_FILEDESC, file desc, Open file descriptor table);
+static MALLOC_DEFINE(M_FILEDESC_TO_LEADER, file desc to leader,
+file desc to leader structures);
static MALLOC_DEFINE(M_SIGIO, sigio, sigio structures);
static uma_zone_t file_zone;
@@ -456,6 +458,7 @@
struct file *fp;
struct file *delfp;
int error, newfd;
+ int holdleaders;
p = td-td_proc;
fdp = p-p_fd;
@@ -520,6 +523,15 @@
* introducing an ownership race for the slot.
*/
delfp = fdp-fd_ofiles[new];
+ if (delfp != NULL p-p_fdtol != NULL) {
+ /*
+*
[Build Current Faild] fix
The 5-current cvs faild to build, bucouse it need a prototype.. with this very small patch it builds ok.. :) Start--// --- /usr/src/sys/contrib/dev/acpica/acnamesp.h.ori Tue Apr 29 18:36:00 2003 +++ /usr/src/sys/contrib/dev/acpica/acnamesp.h Wed May 28 18:05:16 2003 @@ -262,6 +262,10 @@ ACPI_NAMESPACE_NODE *ParentHandle); void +AcpiNsRemoveReference ( +ACPI_NAMESPACE_NODE *Node); + +void AcpiNsDetachObject ( ACPI_NAMESPACE_NODE *Node); End--// -- /* FingerPrint: 5BF1 58B1 DE75 CBE3 6044 7098 1246 1EF6 9E78 041C @@@ @@ @@@ @@! @@@ !@@ @@! @@@ @[EMAIL PROTECTED]@!@ !@@!! @!@ [EMAIL PROTECTED] !!: !!! !:! !!: !!! :: : :: ::.: : :: : : The Power To Kill LinuX */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree
Hi,
From: Nate Lawson [EMAIL PROTECTED]
Subject: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree
Date: Tue, 27 May 2003 16:58:59 -0700
On Wed, 28 May 2003, Shin-ichi YOSHIMOTO wrote:
After this update, I found some error messages like this:
acpi0: IntelR AWRDACPI on motherboard
ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._INI] (Node
0xc21b73e0), AE_NOT_FOUND
Please try the attached patch and see if it changes things for you.
I'm still studying the reason why the TABLE_ID_DSDT is removed
in recent ACPI CA, but at least you should remove all TABLE_ID_DSDT's,
I think.
Also, ACPI_FIRST_METHOD_ID should be larger than 0,
otherwise 0 may be allocated to running method and make a conflict.
I've made a diff against NetBSD-current and just booted the kernel,
but haven't tested much (and still trying to make out what the
changes are intended).
Attached is the patch and should apply to the FreeBSD tree with
some appropriate option.
---
Takayoshi Kochi
Index: aclocal.h
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/aclocal.h,v
retrieving revision 1.5
diff -u -r1.5 aclocal.h
--- aclocal.h 2003/03/04 17:25:10 1.5
+++ aclocal.h 2003/05/28 07:24:46
@@ -214,12 +214,8 @@
typedef UINT16 ACPI_OWNER_ID;
#define ACPI_OWNER_TYPE_TABLE 0x0
#define ACPI_OWNER_TYPE_METHOD 0x1
-#define ACPI_FIRST_METHOD_ID0x
-#define ACPI_FIRST_TABLE_ID 0x8000
-
-/* TBD: [Restructure] get rid of the need for this! */
-
-#define TABLE_ID_DSDT (ACPI_OWNER_ID) 0x8000
+#define ACPI_FIRST_METHOD_ID0x0001
+#define ACPI_FIRST_TABLE_ID 0xF000
/* Field access granularities */
Index: dbutils.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/dbutils.c,v
retrieving revision 1.6
diff -u -r1.6 dbutils.c
--- dbutils.c 2003/03/04 17:25:12 1.6
+++ dbutils.c 2003/05/28 07:24:51
@@ -429,7 +429,7 @@
/* Create a new walk state for the parse */
-WalkState = AcpiDsCreateWalkState (TABLE_ID_DSDT,
+WalkState = AcpiDsCreateWalkState (0,
NULL, NULL, NULL);
if (!WalkState)
{
Index: dsmethod.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/dsmethod.c,v
retrieving revision 1.7
diff -u -r1.7 dsmethod.c
--- dsmethod.c 2003/05/25 10:08:24 1.7
+++ dsmethod.c 2003/05/28 07:24:52
@@ -381,7 +381,9 @@
return_ACPI_STATUS (AE_NULL_OBJECT);
}
+printf(OwningId(before) = %d\n, ObjDesc-Method.OwningId);
ObjDesc-Method.OwningId = AcpiUtAllocateOwnerId (ACPI_OWNER_TYPE_METHOD);
+printf(OwningId(after ) = %d\n, ObjDesc-Method.OwningId);
/* Init for new method, wait on concurrency semaphore */
Index: dsopcode.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/dsopcode.c,v
retrieving revision 1.6
diff -u -r1.6 dsopcode.c
--- dsopcode.c 2003/03/04 17:25:13 1.6
+++ dsopcode.c 2003/05/28 07:24:54
@@ -177,7 +177,7 @@
/* Create and initialize a new parser state */
-WalkState = AcpiDsCreateWalkState (TABLE_ID_DSDT, NULL, NULL, NULL);
+WalkState = AcpiDsCreateWalkState (0, NULL, NULL, NULL);
if (!WalkState)
{
return_ACPI_STATUS (AE_NO_MEMORY);
@@ -221,7 +221,7 @@
/* Create and initialize a new parser state */
-WalkState = AcpiDsCreateWalkState (TABLE_ID_DSDT, NULL, NULL, NULL);
+WalkState = AcpiDsCreateWalkState (0, NULL, NULL, NULL);
if (!WalkState)
{
return_ACPI_STATUS (AE_NO_MEMORY);
Index: nsalloc.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/nsalloc.c,v
retrieving revision 1.8
diff -u -r1.8 nsalloc.c
--- nsalloc.c 2003/05/13 13:29:00 1.8
+++ nsalloc.c 2003/05/28 07:24:56
@@ -314,7 +314,7 @@
ACPI_NAMESPACE_NODE *Node, /* New Child*/
ACPI_OBJECT_TYPEType)
{
-UINT16 OwnerId = TABLE_ID_DSDT;
+UINT16 OwnerId = 0;
ACPI_NAMESPACE_NODE *ChildNode;
#ifdef ACPI_ALPHABETIC_NAMESPACE
Index: nsload.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/nsload.c,v
retrieving revision 1.6
diff -u -r1.6 nsload.c
--- nsload.c2003/03/04 17:25:22 1.6
+++ nsload.c2003/05/28 07:24:57
@@ -275,7 +275,7 @@
goto UnlockAndExit;
}
-TableDesc-TableId = TABLE_ID_DSDT;
+TableDesc-TableId = 0;
/* Now load the single DSDT */
Index: nsparse.c
Re: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree
From: Takayoshi Kochi [EMAIL PROTECTED]
Subject: Re: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree
Date: Thu, 29 May 2003 01:23:49 +0900 (JST)
Attached is the patch and should apply to the FreeBSD tree with
some appropriate option.
Oops, I attached a wrong one. Please ignore the last posting.
---
Takayoshi Kochi
Index: aclocal.h
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/aclocal.h,v
retrieving revision 1.5
diff -u -r1.5 aclocal.h
--- aclocal.h 2003/03/04 17:25:10 1.5
+++ aclocal.h 2003/05/28 07:24:46
@@ -214,12 +214,8 @@
typedef UINT16 ACPI_OWNER_ID;
#define ACPI_OWNER_TYPE_TABLE 0x0
#define ACPI_OWNER_TYPE_METHOD 0x1
-#define ACPI_FIRST_METHOD_ID0x
-#define ACPI_FIRST_TABLE_ID 0x8000
-
-/* TBD: [Restructure] get rid of the need for this! */
-
-#define TABLE_ID_DSDT (ACPI_OWNER_ID) 0x8000
+#define ACPI_FIRST_METHOD_ID0x0001
+#define ACPI_FIRST_TABLE_ID 0xF000
/* Field access granularities */
Index: dbutils.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/dbutils.c,v
retrieving revision 1.6
diff -u -r1.6 dbutils.c
--- dbutils.c 2003/03/04 17:25:12 1.6
+++ dbutils.c 2003/05/28 07:24:51
@@ -429,7 +429,7 @@
/* Create a new walk state for the parse */
-WalkState = AcpiDsCreateWalkState (TABLE_ID_DSDT,
+WalkState = AcpiDsCreateWalkState (0,
NULL, NULL, NULL);
if (!WalkState)
{
Index: dsopcode.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/dsopcode.c,v
retrieving revision 1.6
diff -u -r1.6 dsopcode.c
--- dsopcode.c 2003/03/04 17:25:13 1.6
+++ dsopcode.c 2003/05/28 07:24:54
@@ -177,7 +177,7 @@
/* Create and initialize a new parser state */
-WalkState = AcpiDsCreateWalkState (TABLE_ID_DSDT, NULL, NULL, NULL);
+WalkState = AcpiDsCreateWalkState (0, NULL, NULL, NULL);
if (!WalkState)
{
return_ACPI_STATUS (AE_NO_MEMORY);
@@ -221,7 +221,7 @@
/* Create and initialize a new parser state */
-WalkState = AcpiDsCreateWalkState (TABLE_ID_DSDT, NULL, NULL, NULL);
+WalkState = AcpiDsCreateWalkState (0, NULL, NULL, NULL);
if (!WalkState)
{
return_ACPI_STATUS (AE_NO_MEMORY);
Index: nsalloc.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/nsalloc.c,v
retrieving revision 1.8
diff -u -r1.8 nsalloc.c
--- nsalloc.c 2003/05/13 13:29:00 1.8
+++ nsalloc.c 2003/05/28 07:24:56
@@ -314,7 +314,7 @@
ACPI_NAMESPACE_NODE *Node, /* New Child*/
ACPI_OBJECT_TYPEType)
{
-UINT16 OwnerId = TABLE_ID_DSDT;
+UINT16 OwnerId = 0;
ACPI_NAMESPACE_NODE *ChildNode;
#ifdef ACPI_ALPHABETIC_NAMESPACE
Index: nsload.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/nsload.c,v
retrieving revision 1.6
diff -u -r1.6 nsload.c
--- nsload.c2003/03/04 17:25:22 1.6
+++ nsload.c2003/05/28 07:24:57
@@ -275,7 +275,7 @@
goto UnlockAndExit;
}
-TableDesc-TableId = TABLE_ID_DSDT;
+TableDesc-TableId = 0;
/* Now load the single DSDT */
Index: nsparse.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/nsparse.c,v
retrieving revision 1.2
diff -u -r1.2 nsparse.c
--- nsparse.c 2003/02/13 14:16:23 1.2
+++ nsparse.c 2003/05/28 07:24:58
@@ -166,7 +166,7 @@
/* Create and initialize a new walk state */
-WalkState = AcpiDsCreateWalkState (TABLE_ID_DSDT,
+WalkState = AcpiDsCreateWalkState (0,
NULL, NULL, NULL);
if (!WalkState)
{
Index: pswalk.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/pswalk.c,v
retrieving revision 1.6
diff -u -r1.6 pswalk.c
--- pswalk.c2003/03/04 17:25:25 1.6
+++ pswalk.c2003/05/28 07:24:59
@@ -355,7 +355,7 @@
return_VOID;
}
-WalkState = AcpiDsCreateWalkState (TABLE_ID_DSDT, NULL, NULL, Thread);
+WalkState = AcpiDsCreateWalkState (0, NULL, NULL, Thread);
if (!WalkState)
{
return_VOID;
Index: psxface.c
===
RCS file: /cvsroot/src/sys/dev/acpi/acpica/Subsystem/psxface.c,v
retrieving revision 1.6
diff -u -r1.6 psxface.c
--- psxface.c 2003/03/04 17:25:25 1.6
+++ psxface.c 2003/05/28 07:24:59
@@ -264,7 +264,7 @@
/* Create and initialize a new walk state */
-
RE: [acpi-jp 2274] Re: HEADSUP: acpi patches in the tree
TABLE_ID_DSDT was removed because the table ID should be dynamically allocated. There was a longstanding TBD to remove it. It appears that there is some issue with this change, and of course we would like to get to the root of this problem. Bob -Original Message- From: Takayoshi Kochi [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:24 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [acpi-jp 2274] Re: HEADSUP: acpi patches in the tree Hi, From: Nate Lawson [EMAIL PROTECTED] Subject: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree Date: Tue, 27 May 2003 16:58:59 -0700 On Wed, 28 May 2003, Shin-ichi YOSHIMOTO wrote: After this update, I found some error messages like this: acpi0: IntelR AWRDACPI on motherboard ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._INI] (Node 0xc21b73e0), AE_NOT_FOUND Please try the attached patch and see if it changes things for you. I'm still studying the reason why the TABLE_ID_DSDT is removed in recent ACPI CA, but at least you should remove all TABLE_ID_DSDT's, I think. Also, ACPI_FIRST_METHOD_ID should be larger than 0, otherwise 0 may be allocated to running method and make a conflict. I've made a diff against NetBSD-current and just booted the kernel, but haven't tested much (and still trying to make out what the changes are intended). Attached is the patch and should apply to the FreeBSD tree with some appropriate option. --- Takayoshi Kochi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, May 28, 2003 at 12:04:17PM +0200, Marcin Dalecki wrote: Harti Brandt wrote: MDNO no and again no. This would repeat the same design mistake MDthat is already in Linux. On API level you DO NOT WANT versioning. MDWhat you really want is: type signature cheking. Like for example MDdone through C++ symbol mangling rules. If you can't do it like that MDthen better leave it off as it is. Versioning in itself Type signature checking doesn't help you if the semantics of an API change without type changes. APIs should be semantically and syntactically stable in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party driver for current is a nightmare, but may no be necessary once we have a -STABLE based on FreeBSD5. Sure sure. Perhaps I wasn't clear enough. Versioning doesn't help you *anything* at all, but it is introducing new problems instead. Tons of them in fact, if one looks at the Linux pain in this area. I suggested type signature cheking in C++ style just to show how fundamentally flawed the idea of version cheking is, but I can perfectly life with the situation as it is. Symbol versioning is good to implement multi-flavoured single binary I don't think anyone is talking about symbol versioning. The issue is stamping the API at a particular point in time that shows it behaves in a specified guaranteed way. The module system has all the hooks to deal with versioning. What's missing is not the mechanism but the knowledge, i.e. we don't know that module X won't work with kernel Y becuase we don't know what APIs module X may invoke and whether kernel Y supports them. Some of the suggestions, such as using an MD5 hash, will prevent panics by refusing to load kernels that haven't been rebuilt since the kernel was, but it's a bit of a sledgehammer, since you don't want to have to rebuild all your modules every time you rebuild the kernel and in some cases (third party modules) you won't be able to, so such a mechanism won't work in practice. The only true solution to this is to version the APIs in the kernel and use the module versioning hooks to not load modules if the version isn't the right one. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
I don't think anyone is talking about symbol versioning. The issue is stamping the API at a particular point in time that shows it behaves in a specified guaranteed way. The module system has all the hooks to deal with versioning. What's missing is not the mechanism but the knowledge, i.e. we don't know that module X won't work with kernel Y becuase we don't know what APIs module X may invoke and whether kernel Y supports them. snip The only true solution to this is to version the APIs in the kernel and use the module versioning hooks to not load modules if the version isn't the right one. Will this require *any* new infrastructure to implement properly? Or is it simply a matter of maintaining API metadata regarding versions. I should probably try to understand the existing stuff more before asking too many more questions. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
/etc/hosts completely ignored
Hello. Sorry to post again even though I've been told I should post to -questions.. but I believe this is a bug. Here is some more info on my configuration: (I rebuilt the kernel but this behaviour was present in GENERIC, too) -bash-2.05b# uname -a FreeBSD jupiter.noonlights.net 5.0-RELEASE FreeBSD 5.0-RELEASE #0: Wed May 28 11:50:07 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/JUPITER01 i386 -bash-2.05b# cat /etc/rc.conf keymap=swissgerman.iso.acc moused_enable=YES saver=warp defaultrouter=192.168.1.1 hostname=jupiter.noonlights.net ifconfig_rl0=inet 192.168.1.5 netmask 255.255.255.0 sendmail_enable=YES sshd_enable=YES linux_enable=YES -bash-2.05b# cat /etc/hosts 127.0.0.1 localhost.noonlights.net localhost 192.168.1.5 jupiter.noonlights.net jupiter 192.168.1.5 jupiter.noonlights.net. 193.5.56.6 www.freebsd.org myfreebsd note the wrong IP for www.freebsd.org!! just for testing purposes! -bash-2.05b# cat /etc/nsswitch.conf hosts: files dns -bash-2.05b# cat /etc/host.conf hosts bind -bash-2.05b# cat /etc/resolv.conf domain noonlights.net nameserver 195.190.166.166 nameserver 195.190.166.167 -bash-2.05b# host localhost Host not found. -bash-2.05b# host localhost.noonlights.net Host not found. -bash-2.05b# nslookup localhost Server: ns1.ticino.com Address: 195.190.166.166 Non-authoritative answer: Name:localhost Address: 127.0.0.1 -bash-2.05b# host jupiter.noonlights.net Host not found. -bash-2.05b# hostname jupiter.noonlights.net -bash-2.05b# host www.freebsd.org www.freebsd.org has address 216.136.204.117 www.freebsd.org mail is handled (pri=10) by mx1.freebsd.org See? /etc/hosts is completely ignored.. If I missed something, I'd be grateful if somebody could let me know... for I'm new to /etc/nsswitch.conf.. but after reading the manpage I have no clue left.. just an idea that is a bug.. Thank you. -- Roberto Nunnari -software engineer- mailto:[EMAIL PROTECTED] Scuola Universitaria Professionale della Svizzera Italiana Dipartimento di Informatica e Elettronica http://www.die.supsi.ch SUPSI-DIE Via Cantonaletel: +41-91-6108561 6928 Mannofax: +41-91-6108570 Switzerland (o o) ===oOO==(_)==OOo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/hosts completely ignored
[snip] -bash-2.05b# cat /etc/hosts 127.0.0.1 localhost.noonlights.net localhost 192.168.1.5 jupiter.noonlights.net jupiter 192.168.1.5 jupiter.noonlights.net. 193.5.56.6 www.freebsd.org myfreebsd [snip] -bash-2.05b# cat /etc/nsswitch.conf hosts: files dns -bash-2.05b# cat /etc/host.conf hosts bind -bash-2.05b# cat /etc/resolv.conf domain noonlights.net nameserver 195.190.166.166 nameserver 195.190.166.167 -bash-2.05b# host localhost Host not found. -bash-2.05b# host localhost.noonlights.net Host not found. I think it's host-related. I have a similar setup muself, although I'm currently running 5.1-BETA (sources as of around midnight 28/05/03 GMT-3). If I try `host localhost`, I get Host not found, too. But if I try `host localhost.`, it finds that host fine. Have you tried `host localhost.noonlights.net.` or even `host localhost.`? I think it might be because host forces the inclusion of its domainname at the end of the argument if it's not dot-ended. The rest of the output you pasted suggests that I'm right about this, and thus it _is_ a host's fault. I agree that we should fix our base code, but I support the idea of reporting that to ISC, so they can merge the changes to their codebase instead. Fred -- idiot box, n: The part of the envelope that tells a person where to place the stamp when they can't quite figure it out for themselves. -- Sniglets, Rich Hall Friends pgp0.pgp Description: PGP signature
Re: policy on GPL'd drivers?
On 28 May, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : 2) You can't control where the module gets put - arguably this isn't a : calamity, but I think it makes more sense for the modules to end up in : /boot/modules, or some analog to it that is in $PREFIX. It should go in /boot/kernel, and not into $PREFIX, but that's a philisophical problem I have with ports. ALL modules should be in /, imho, since you don't know if the module is required to mount /. Another really good reason is that this is more likely to do the correct thing if you do a major system upgrade, like jumping from 4.x to 5.x, which are very likely to require different versions of the module, and discover some sort of problem when you boot the new kernel to test it before proceeding to the installworld step. The right thing should happen when you fall back to /boot/kernel.old, or /boot/kernel.itusedtowork, etc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 2003-05-28 at 17:48, dave wrote: I don't think anyone is talking about symbol versioning. The issue is stamping the API at a particular point in time that shows it behaves in a specified guaranteed way. The module system has all the hooks to deal with versioning. What's missing is not the mechanism but the knowledge, i.e. we don't know that module X won't work with kernel Y becuase we don't know what APIs module X may invoke and whether kernel Y supports them. snip The only true solution to this is to version the APIs in the kernel and use the module versioning hooks to not load modules if the version isn't the right one. Will this require *any* new infrastructure to implement properly? Or is it simply a matter of maintaining API metadata regarding versions. I think it'd just be a question of maintaining the metadata. There may be a little code missing but I don't think it would take a lot of work to complete the versioning mechanism. Creating all the metadata to actually define and version the APIs is another issue entirely though. Each module can maintain dependency data, stating which versions of other modules it can work with. The kernel would need to create virtual modules that held the faked module version for that API component. That wouldn't be very hard, just a linker set to record the API version in a module version structure. Ideally, whenever possible each API component should be grouped into a module anyway, but when that isn't possible just defining a faked module version should work. The kernel wouldn't then load a module if the kernel didn't support the APIs that the module depended upon. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/hosts completely ignored
On Wed, May 28, 2003 at 02:08:04PM -0300, Fred Souza wrote: [snip] -bash-2.05b# cat /etc/hosts 193.5.56.6 www.freebsd.org myfreebsd [snip] -bash-2.05b# cat /etc/nsswitch.conf hosts: files dns -bash-2.05b# cat /etc/host.conf hosts bind -bash-2.05b# cat /etc/resolv.conf domain noonlights.net nameserver 195.190.166.166 nameserver 195.190.166.167 -bash-2.05b# host localhost Host not found. -bash-2.05b# host localhost.noonlights.net Host not found. I think it's host-related. I have a similar setup muself, although I'm currently running 5.1-BETA (sources as of around midnight 28/05/03 GMT-3). If I try `host localhost`, I get Host not found, too. But if I try `host localhost.`, it finds that host fine. Have you tried `host localhost.noonlights.net.` or even `host localhost.`? I think it might be because host forces the inclusion of its domainname at the end of the argument if it's not dot-ended. Umm, host(1) looks in the DNS for hostnames, as per the manpage: DESCRIPTION Host looks for information about Internet hosts. It gets this informa- tion from a set of interconnected servers that are spread across the world. It doesn't use /etc/hosts, just DNS. That's by design. Ceri -- User: DO YOU ACCEPT JESUS CHRIST AS YOUR PERSONAL LORD AND SAVIOR? Iniaes: Sure, I can accept all forms of payment. -- www.chatterboxchallenge.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/hosts completely ignored
From: Roberto Nunnari [EMAIL PROTECTED] -bash-2.05b# cat /etc/hosts 127.0.0.1 localhost.noonlights.net localhost 192.168.1.5 jupiter.noonlights.net jupiter 192.168.1.5 jupiter.noonlights.net. 193.5.56.6 www.freebsd.org myfreebsd note the wrong IP for www.freebsd.org!! just for testing purposes! -bash-2.05b# cat /etc/host.conf hosts bind -bash-2.05b# host localhost Host not found. -bash-2.05b# host localhost.noonlights.net Host not found. See? /etc/hosts is completely ignored.. If I missed something, I'd be grateful if somebody could let me know... for I'm new to /etc/nsswitch.conf.. but after reading the manpage I have no clue left.. just an idea that is a bug.. I get the same results on 4-STABLE with the host command. Looking at the host man pages, it states host does the lookups using domain servers. host - look up host names using domain server Try ping, telnet, ftp, or ssh, as they should consult the hosts table before checking with a domain servers. Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/hosts completely ignored
Dear Fred, if I call -bash-2.05b# host localhost. localhost has address 127.0.0.1 but that's only because the dns specified in resolv.conf answers the query with its own 'localhost' entry. Look: -bash-2.05b# host -d -t A localhost. ;; res_nmkquery(QUERY, localhost, IN, A) ;; res_send() ;; -HEADER- opcode: QUERY, status: NOERROR, id: 64429 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; localhost, type = A, class = IN ;; Querying server (# 1) address = 195.190.166.166 ;; new DG socket ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 64429 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; localhost, type = A, class = IN localhost. 1D IN A 127.0.0.1 rcode = 0 (Success), ancount=1 localhost has address 127.0.0.1 its a remote dns that answers the query.. but naturally it doesn't know about localhost in a not existant domain as localhost.noonlights.net that I use for my private network -bash-2.05b# host -d -t A localhost.noonlights.net. ;; res_nmkquery(QUERY, localhost.noonlights.net, IN, A) ;; res_send() ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20386 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; localhost.noonlights.net, type = A, class = IN ;; Querying server (# 1) address = 195.190.166.166 ;; new DG socket ;; got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 20386 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; localhost.noonlights.net, type = A, class = IN net.2D IN SOA a.gtld-servers.net. nstld.verisign-grs.com. ( 2003052800 ; serial 30M ; refresh 15M ; retry 1W ; expiry 1D ); minimum rcode = 3 (Non-existent domain), ancount=0 Host not found. Best regards. -- Roberto Nunnari -software engineer- mailto:[EMAIL PROTECTED] Scuola Universitaria Professionale della Svizzera Italiana Dipartimento di Informatica e Elettronica http://www.die.supsi.ch SUPSI-DIE Via Cantonaletel: +41-91-6108561 6928 Mannofax: +41-91-6108570 Switzerland (o o) ===oOO==(_)==OOo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/hosts completely ignored
I see... you're completely right.. ping looks up /etc/hosts while host and nslookup don't. Sorry for the noise. Thank you very much for your quick answers. Best regards. -- Roberto Nunnari -software engineer- mailto:[EMAIL PROTECTED] Scuola Universitaria Professionale della Svizzera Italiana Dipartimento di Informatica e Elettronica http://www.die.supsi.ch SUPSI-DIE Via Cantonaletel: +41-91-6108561 6928 Mannofax: +41-91-6108570 Switzerland (o o) ===oOO==(_)==OOo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/hosts completely ignored
Umm, host(1) looks in the DNS for hostnames, as per the manpage: DESCRIPTION Host looks for information about Internet hosts. It gets this informa- tion from a set of interconnected servers that are spread across the world. It doesn't use /etc/hosts, just DNS. That's by design. I'm not sure about that. If you read all the way to end of the manpage, you'll see this part too: ENVIRONMENT HOSTALIASES Name of file containing (host alias, full hostname) pairs. FILES /etc/resolv.confSee resolver(5). It could mean, then, that if the environment variable HOSTALIASES is NOT set, it'll use only DNS. But then again, you must use a dot at the end of the host if you don't want it to include that by itself. It's weird, however, that src/contrib/bind/bin/host/host.c does not match HOSTALIASES on a grep. Could it mean that (as usual) ISC's documentation makes little sense according to its source, and that you're right and host does not use non-DNS mechanisms at all for name resolution? Fred -- Chemistry professors never die, they just fail to react. pgp0.pgp Description: PGP signature
Re: /etc/hosts completely ignored
AFAIK, hosts is a DNS tool, exclusively. Roberto Nunnari wrote: Hello. Sorry to post again even though I've been told I should post to -questions.. but I believe this is a bug. Here is some more info on my configuration: (I rebuilt the kernel but this behaviour was present in GENERIC, too) -bash-2.05b# uname -a FreeBSD jupiter.noonlights.net 5.0-RELEASE FreeBSD 5.0-RELEASE #0: Wed May 28 11:50:07 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/JUPITER01 i386 -bash-2.05b# cat /etc/rc.conf keymap=swissgerman.iso.acc moused_enable=YES saver=warp defaultrouter=192.168.1.1 hostname=jupiter.noonlights.net ifconfig_rl0=inet 192.168.1.5 netmask 255.255.255.0 sendmail_enable=YES sshd_enable=YES linux_enable=YES -bash-2.05b# cat /etc/hosts 127.0.0.1 localhost.noonlights.net localhost 192.168.1.5 jupiter.noonlights.net jupiter 192.168.1.5 jupiter.noonlights.net. 193.5.56.6 www.freebsd.org myfreebsd note the wrong IP for www.freebsd.org!! just for testing purposes! -bash-2.05b# cat /etc/nsswitch.conf hosts: files dns -bash-2.05b# cat /etc/host.conf hosts bind -bash-2.05b# cat /etc/resolv.conf domain noonlights.net nameserver 195.190.166.166 nameserver 195.190.166.167 -bash-2.05b# host localhost Host not found. -bash-2.05b# host localhost.noonlights.net Host not found. -bash-2.05b# nslookup localhost Server: ns1.ticino.com Address: 195.190.166.166 Non-authoritative answer: Name:localhost Address: 127.0.0.1 -bash-2.05b# host jupiter.noonlights.net Host not found. -bash-2.05b# hostname jupiter.noonlights.net -bash-2.05b# host www.freebsd.org www.freebsd.org has address 216.136.204.117 www.freebsd.org mail is handled (pri=10) by mx1.freebsd.org See? /etc/hosts is completely ignored.. If I missed something, I'd be grateful if somebody could let me know... for I'm new to /etc/nsswitch.conf.. but after reading the manpage I have no clue left.. just an idea that is a bug.. Thank you. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] He who hates vices hates mankind. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
The only true solution to this is to version the APIs in the kernel and use the module versioning hooks to not load modules if the version isn't the right one. Will this require *any* new infrastructure to implement properly? Or is it simply a matter of maintaining API metadata regarding versions. I think it'd just be a question of maintaining the metadata. There may be a little code missing but I don't think it would take a lot of work to complete the versioning mechanism. Creating all the metadata to actually define and version the APIs is another issue entirely though. Each module can maintain dependency data, stating which versions of other modules it can work with. The kernel would need to create virtual modules that held the faked module version for that API component. That wouldn't be very hard, just a linker set to record the API version in a module version structure. Ideally, whenever possible each API component should be grouped into a module anyway, but when that isn't possible just defining a faked module version should work. So the module dependency graph would have nodes that are either real or virtual modules. Virtual modules are provided by the kernel proper only which only uses them to satisfy a module dependency? Interesting [hope I got that correct :)] Sounds like a neat way to create a module framework, guide for 3rd party and commercial drivers to get support from FreeBSD itself. dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree
On Thu, 29 May 2003, Takayoshi Kochi wrote: I'm still studying the reason why the TABLE_ID_DSDT is removed in recent ACPI CA, but at least you should remove all TABLE_ID_DSDT's, I think. Also, ACPI_FIRST_METHOD_ID should be larger than 0, otherwise 0 may be allocated to running method and make a conflict. I've made a diff against NetBSD-current and just booted the kernel, but haven't tested much (and still trying to make out what the changes are intended). Attached is the patch and should apply to the FreeBSD tree with some appropriate option. Thank you for the patch. Since we are only days away from a release, I would like to avoid using the new dynamic ID allocation code and instead stick to hard-coding the defaults. This is the safer way for 5.1R. We will do a new import and more fixes after the release. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2272] Re: HEADSUP: acpi patches in the tree
On Wed, 28 May 2003, Anish Mistry wrote: On Tuesday 27 May 2003 07:58 pm, Nate Lawson wrote: On Wed, 28 May 2003, Shin-ichi YOSHIMOTO wrote: After this update, I found some error messages like this: acpi0: IntelR AWRDACPI on motherboard ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._INI] (Node 0xc21b73e0), AE_NOT_FOUND Please try the attached patch and see if it changes things for you. -Nate I was having freezing on S3 problems (same as above), but this patch fixed it. The patch has been committed plus a fix for buildkernel. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-05-28 17:25:45 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-05-28 17:25:45 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-05-28 17:27:47 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-05-28 18:20:15 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed May 28 18:20:15 GMT 2003 Kernel build for GENERIC completed on Wed May 28 18:34:11 GMT 2003 TB --- 2003-05-28 18:34:11 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-05-28 18:34:11 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed May 28 18:34:12 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/hwregs.c:245: warning: cast discards qualifiers from pointer target type cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/hwsleep.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/hwtimer.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/nsaccess.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica/nsalloc.c cc1: warnings being treated as errors
Re: mb alloc and: panic: mutex Giant not owned at../../../vm/vm_kern.c:315
David Malone writes: This may be my fault, as I made some changes recently that assumed that the mbuf allocator grabbed giant when needed. I'll check the code path you've mentioned to see if it grabs giant now, but I suspect that I just need to move the giant grabbing back where it was before. This doesn't seem to be a reproduceable problem for me, FWIW, (presumably a property of bucket sizes, etc) so you have all the information I have :-). You'd have to be quite unlucky to trigger it (calling sendit at a time when a per-cpu mbuf pool was empty). I have a vague feeling that my sendit change isn't the only place that does this. FWIW, calling kmem_malloc() w/o Giant is safe if you call with NOWAIT. But if you wait, you must hold Giant. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
first time that my floppy was recognized with acpi
with todays kernel i recognized that my floppy was back again, then after cvsup this afternoon came /usr/src/sys/contrib/dev/acpica/nsalloc.c and the floppy controller went away again. -- Mit freundlichen Grüßen Fritz Heinrichmeyer FernUniversitaet, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gbde Performance - 35Mb/s vs 5.2 MB/s
On Wed, 28 May 2003 11:40:27 +0100 Paul Richards [EMAIL PROTECTED] wrote: On Wed, May 28, 2003 at 10:11:19AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Guido van Rooij writes: On Mon, May 26, 2003 at 02:25:08PM +0200, Heiko Schaefer wrote: Poul gave me the following tip on this list in a mail on Tue, 29 Apr 2003: Remember to set the sectorsize in gbde (gbde init -i) to the fragment size of your filesystem (typically 2048 for ufs), this is critical for performance. If this is so important, why isn't this the default? Because I have no way of knowing that peple will in fact be using UFS/FFS on the GBDE encrypted partition, and even if they do, I have no way of knowing the fragment size they will use. I considered making the sectorsize a mandatory argument, but decided against it. Maybe I was wrong. It might make more sense to mandate an argument that indicates what filesystem they intend to put on top of it and then base the defaults from that. It would be more user friendly. Yes, but that would unnecessarily limit the program. A new file system would wind up being unsupported, of course that would not matter if it wasn't mandatory or there was some sort of other designation.. but that would begin to kill the point of the additional argument in the first place. Seems to me the program would be better served with more documentation then a user-friendly interface considering its age and experimental nature. TTYL, James -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc/libm floating-point bug?
On Wed, 28 May 2003, John Polstra wrote: In article [EMAIL PROTECTED], Bruce Evans [EMAIL PROTECTED] wrote: On Tue, 27 May 2003, Terry Lambert wrote: BTW: signal stacks are irrelevent; technically, you are not allowed to do floating point in signal handlers anyway. 8-). Not true. Signal handlers can do almost anything with local variables. The main relevant restrictions on them is that they must not access any static or global variables (other than write-only accesses to objects whose type is volatile sig_atomic_t) or call any functions that might make such accesses (which rules out calling most functions including everything in libm). Those are the rules set forth by the C standard, but POSIX.1 demands much more from the implementation. There's a whole list of functions that POSIX says must be safely callable from signal handlers. Almost all of the I/O calls are included. Even fork and exec[lv]e must be callable from signal handlers. Not much more. The list of signal-safe functions is relatively small and doesn't contain much more than things that are usually implemented as syscalls. Syscalls don't access any static or global objects except errno (*) unless they take a pointer arg and you point at a static or global. Obviously, you must not do that. But POSIX seems to be a little broken here. From draft7: %%% 1327 The following table defines a set of functions that shall be either reentrant or non- 1328 interruptible by signals and shall be async-signal-safe. Therefore applications may 1329 invoke them, without restriction, from signal-catching functions: | !!! 1330 _Exit( ) fpathconf( ) raise( ) sigprocmask( ) ||| 1331 _exit( ) fstat( ) read( ) sigqueue( ) %%% Unless there is some special wording elswhere, a literal reading of this says that clobbering of static and global objects, e.g. by read()ing into them, is harmless in signal handlers. (*) POSIX seems to require the implementation to preserve errno in signal handlers, since most of the signal-safe functions can set errno and the without restriction clause says that the application code for signal handlers doesn't need to preserve it (and signal handlers obviously must preserve errno if they return). I've never seen an implementation that preserves it. I've seen 0% of implementations and epsilon% of application signal handlers preserving it. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [acpi-jp 2279] Re: HEADSUP: acpi patches in the tree
Here's what we released: #define ACPI_FIRST_METHOD_ID0x0001 #define ACPI_FIRST_TABLE_ID 0xF000 -Original Message- From: Nate Lawson [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 11:00 AM To: Takayoshi Kochi Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [acpi-jp 2279] Re: HEADSUP: acpi patches in the tree On Thu, 29 May 2003, Takayoshi Kochi wrote: I'm still studying the reason why the TABLE_ID_DSDT is removed in recent ACPI CA, but at least you should remove all TABLE_ID_DSDT's, I think. Also, ACPI_FIRST_METHOD_ID should be larger than 0, otherwise 0 may be allocated to running method and make a conflict. I've made a diff against NetBSD-current and just booted the kernel, but haven't tested much (and still trying to make out what the changes are intended). Attached is the patch and should apply to the FreeBSD tree with some appropriate option. Thank you for the patch. Since we are only days away from a release, I would like to avoid using the new dynamic ID allocation code and instead stick to hard-coding the defaults. This is the safer way for 5.1R. We will do a new import and more fixes after the release. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
pam_unix.c [PATCH].
Hello.
I think there is no need to open a PR for this.
Argument 'flags' marked as unused is used in those functions:
--- pam_unix.c.orig Wed May 28 23:31:54 2003
+++ pam_unix.c Wed May 28 23:32:40 2003
@@ -95,8 +95,7 @@
* authentication management
*/
PAM_EXTERN int
-pam_sm_authenticate(pam_handle_t *pamh, int flags __unused,
-int argc, const char *argv[])
+pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char *argv[])
{
login_cap_t *lc;
struct options options;
@@ -159,8 +158,7 @@
* account management
*/
PAM_EXTERN int
-pam_sm_acct_mgmt(pam_handle_t *pamh, int flags __unused,
-int argc, const char *argv[])
+pam_sm_acct_mgmt(pam_handle_t *pamh, int flags, int argc, const char *argv[])
{
struct addrinfo hints, *res;
struct options options;
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp0.pgp
Description: PGP signature
Re: cvs commit: src/sys/contrib/dev/acpica - Imported sources
--On Wednesday, May 28, 2003 10:02:19 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Wednesday, May 28, 2003 03:59:24 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: Ok, with today's sources, I still get a page not present panic for address (0x7) on transistion to battery. as a followup, with this code, I no longer get the panic at ACPI shutdown, just some messages about references. As a further followup, today's update of the ACPI sources get's rid of the ACPI errors in the dmesg, but I STILL have the panic at 0x7 on transition to battery. Is this going to be released like this? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/contrib/dev/acpica - Imported sources
On Wed, 28 May 2003, Larry Rosenman wrote: --On Wednesday, May 28, 2003 03:59:24 -0500 Larry Rosenman Ok, with today's sources, I still get a page not present panic for address (0x7) on transistion to battery. as a followup, with this code, I no longer get the panic at ACPI shutdown, just some messages about references. As a further followup, today's update of the ACPI sources get's rid of the ACPI errors in the dmesg, but I STILL have the panic at 0x7 on transition to battery. There's something wrong with your DSDT and/or the Intel acpica interpreter such that reference counting on ns objects is incorrect. Is this going to be released like this? I'm doing my best as a volunteer. If none of us finds the problem before release, the answer is yes. In that case, you should disable acpi or use apm. Or feel free to hunt down the problem yourself. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/contrib/dev/acpica - Imported sources
--On Wednesday, May 28, 2003 15:39:44 -0700 Nate Lawson [EMAIL PROTECTED] wrote: On Wed, 28 May 2003, Larry Rosenman wrote: --On Wednesday, May 28, 2003 03:59:24 -0500 Larry Rosenman Ok, with today's sources, I still get a page not present panic for address (0x7) on transistion to battery. as a followup, with this code, I no longer get the panic at ACPI shutdown, just some messages about references. As a further followup, today's update of the ACPI sources get's rid of the ACPI errors in the dmesg, but I STILL have the panic at 0x7 on transition to battery. There's something wrong with your DSDT and/or the Intel acpica interpreter such that reference counting on ns objects is incorrect. dsdt/aml: http://www.lerctr.org/~ler/ler.aml.dsdt.tar.gz Is this going to be released like this? I'm doing my best as a volunteer. If none of us finds the problem before release, the answer is yes. In that case, you should disable acpi or use apm. Or feel free to hunt down the problem yourself. I know. I'm trying to help. -Nate -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 18:41, M. Warner Losh wrote: : the machine that built it, and not potentially somewhere else? What : about sysinstall upgrades that don't require src? : : Well, I am not 100% sure how the module building process works, but some : analog of how it happens for things in sys/modules would be nice.. That is what is happening for the ports (or was last time I looked). In general yes, the ports are written like that, but I think rebuilding it directly from installed sources makes more sense. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 18:44, M. Warner Losh wrote: : 1) If the port is updated between builds you end up with two version of : the port installed. True. That's a weakness in the ports system, which is why we have portupgrade. However, I didn't want to require portupgrade for something so 'simple'. To a degree, but IMHO it isn't correct - I don't want to update the version of the port I am using without good reason. ie it should just recompile the code for the port you've already installed which is usually sufficient to get things working again. : 2) You can't control where the module gets put - arguably this isn't a : calamity, but I think it makes more sense for the modules to end up in : /boot/modules, or some analog to it that is in $PREFIX. It should go in /boot/kernel, and not into $PREFIX, but that's a philisophical problem I have with ports. ALL modules should be in /, imho, since you don't know if the module is required to mount /. Yes, I agree. : I guess the problem with mandating somewhere in $PREFIX is that the : loader can't load it, so that's no good. I guess the only choice left is : /boot/modules. /boot/kernel : Any comments? Well, the patch was mostly a strawman to promote discussions about the issues. Fair enough. I think the port should install the source for the module in $PREFIX somewhere (well known) and the module should live in /boot/kernel. When things need rebuilding it uses the installed source to do so.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 23:58, Steve Kargl wrote: Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. If there are more elegant solutions I would like to know what they are. I agree it isn't a great solution, but I can't see what is better. For GPL modules, put them in src/sys/gnu. If you don't want bloat, then use cvsup and a refuse file to not retrieve the sys/gnu. See the discussion that occurred many years ago when maestro3 support was committed to the tree. For non-viral licensed code, put it in its proper place in the sys/ hierarchy. Then use a WANT_XXX=yes knob in the /etc/make.conf to cause XXX to be built. You are describing how it happens now, not WHY it happens like that. I think the existing solution has problems, and would prefer some external hooks for 3rd party modules. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
* Daniel O'Connor [EMAIL PROTECTED] [ Date: 2003-05-28 ] [ w.r.t. Re: policy on GPL'd drivers? ] : I guess the problem with mandating somewhere in $PREFIX is that the : loader can't load it, so that's no good. I guess the only choice left is : /boot/modules. /boot/kernel : Any comments? Well, the patch was mostly a strawman to promote discussions about the issues. Fair enough. I think the port should install the source for the module in $PREFIX somewhere (well known) and the module should live in /boot/kernel. When things need rebuilding it uses the installed source to do so.. Jumping in a bit late as I thought someone would point this out, but I thought that 3rd-party modules would live in /boot/modules? Also, as for them being tied to kernel configs at minimum, definitely, and I'd say that maybe /boot/modules should have e.g. foobar-IDENT.ko and a symlink to it from /boot/kernel.IDENT/foobar.ko or something, where IDENT is the kernel IDENT, that way multiple copies of a given 3rd-party module could exist, and probably we'd want to do something similar to the .old shuffling we do with kernels, anyway. Just a thought. Just putting them *with* each kernel does seeem a lot more direct, for sure, but I'd feel less gross adding a new symlink than copying one from an existing directory, which could be crudded up with $DEITY knows what. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
In message: [EMAIL PROTECTED] Juli Mallett [EMAIL PROTECTED] writes: : Jumping in a bit late as I thought someone would point this out, but : I thought that 3rd-party modules would live in /boot/modules? third party binary only modules. If you have source, for some definition of having source, to rebuild from, then it makes the most sense to keep it directly with the kernel. I'd not bother with symlinks as that just makes things more complicated and I'm not sure what gain you get from it. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
* M. Warner Losh [EMAIL PROTECTED] [ Date: 2003-05-28 ] [ w.r.t. Re: policy on GPL'd drivers? ] In message: [EMAIL PROTECTED] Juli Mallett [EMAIL PROTECTED] writes: : Jumping in a bit late as I thought someone would point this out, but : I thought that 3rd-party modules would live in /boot/modules? third party binary only modules. If you have source, for some definition of having source, to rebuild from, then it makes the most sense to keep it directly with the kernel. I'd not bother with symlinks as that just makes things more complicated and I'm not sure what gain you get from it. I'm just curious how the third-party modules are kept around properly across installkernel/buildkernel. Did you get MAKEOBJDIR/MAKEOBJDIRPREFIX stuff working in the kernel build dir with ports modules? I'm glad we aren't doing the realpath(3) thing in Make anymore, if so, as I doubt I'm the only one with one hell of a convoluted setup in that sort of thing. And thanks for clearing up that that was binary-only ones, that makes a bit more sense I suppose, assuming we're handling the module installs all properly. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ccd(4): Fatal trap 18: integer divide fault while in kernel mode
Caught a panic in ccd under 5.1-BETA-20030526-JPSNAP (GENERIC with unused devices disabled, zero_copy(9) and polling(4)) while rsyncing a number of ~50MB files onto a 2-disk ccd stripe (ccd0 1152 none /dev/ad4s1d /dev/ad7s1d; ...; newfs -U /dev/ccd0d). Irritatingly, the panic was only repeatable under a kernel with INVARIANTS/WITNESS disabled, and no dump device defined, but when I recompiled with them enabled, and created a large enough dump partition, it disappeared. I've been unable to repeat the panic since (in either state). Anyway, this is what we have, in case it means anything to anyone: Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x8:0xc2e4b9e2 stack pointer = 0x10:0xdf11cbac frame pointer = 0x10:0xdf11cbec code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 4 (g_down) kernel: type 18 trap, code=0 Stopped at ccdbuffer+0x162:idivl 0(%esi),%eax db trace ccdbuffer(df11cc28,c63d2800,c6ae1870,0,ffd51458) at ccdbuffer+0x162 ccdstart(c63d2800,c6ae1870,1,0,aa28b000) at ccdstart+0x75 ccdstrategy(c6ae1870,0,c0392637,53,0) at ccdstrategy+0xa6 g_disk_start(c673a990,0,c0392a89,159,64) at g_disk_start+0x19e g_io_schedule_down(c21ae000,c21ae000,df11cd34,c0200d2e,0) at g_io_schedule_down+0x19c g_down_procbody(0,df11cd48,c03943dd,2f8,0) at g_down_procbody+0x28 fork_exit(c01e32f0,0,df11cd48) at fork_exit+0xae fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf11cd7c, ebp = 0 --- db Is there anything more useful I can provide with what I have? (debug kernel compiled, but no dump to get specifics from... I'm not a gdb expert). I'll continue to try and replicate the initial panic, and get some more helpful data. - Robin -- _ [ Robin Breathe | robin at isometry dot net | +44 1865 741800 ] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-BETA2 FAILURE on IBM A30p Thinkpad
From: Jesse D. Guardiani [EMAIL PROTECTED] Date: Wed, 28 May 2003 00:33:32 -0400 Sender: [EMAIL PROTECTED] Kevin Oberman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] From: Jesse D. Guardiani [EMAIL PROTECTED] Date: Sat, 24 May 2003 02:12:32 -0400 Sender: [EMAIL PROTECTED] Andre Guibert de Bruet [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] Does you r kernel configuration have: options DISABLE_PSE options DISABLE_PG_G I don't know. Does it? I was using the kernel that comes on the CDROM that I burned from an ISO image. I have no clue what options it is compiled with. That's part of what I find so frustrating. :) It does not, but it lacks apm, as well. the GENERIC kernel (on the CDROM) is built using the configuration file /sys/i386/conf/GENERIC. You probably want to modify it to better match your system. I suspect that you will at least want 'device pcm', 'device smb', and 'device ichsmb'. If you want to use APM, add it to the configuration file. If this is not clear to you, read the Handbook section on customizing the kernel. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Mon, May 26, 2003 at 06:51:10PM -0400, Mike Makonnen wrote: Hello folks, Most major locking work in libthr is finished. I believe it is stable enough now that it can be used for most applications[1]. I would appreciate it if people would try it out and report any bugs. [1] - I haven't had a chance to test it on an SMP machine. The machine I was going to use crashed for unrelated reasons, but it should be back up soon. Never the less I would be interested to hear from people who have real world threaded applications on SMP systems. It seems to be working fine on a UP machine but it locks up my SMP machine just trying to load a gnome session. It leaves an image on the screen but the keyboard and mouse stop responding and I can not ssh into the box. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3dmd broken
Hello, At Wed, 28 May 2003 16:23:25 GMT, [EMAIL PROTECTED] wrote: [1 text/plain; us-ascii (7bit)] Hi, I installed 3dmd the webtool for 3ware Raid controllers, I left the config untouched or set whatever port, the prog starts but doesnt bind any port, thus no connection possible, is it broken ? im on 5.1b id be interested if anyone running it with 5.1b I had same problem with FreeBSD 4.8-STABLE (from cvsup 2003/05/23) and 3ware 3W-7450 controller. If you unpack the following snippet --- begin 644 3dmd.bpatch.144284 6#[IL)`0-N/L```#-@'+KA=)T`C'`PP`` ` end --- using uudecode, you should get the following checksum: MD5 (3dmd.bpatch.144284) = b1116c4846262ee3d523db05b82717c3 To apply: cp -p 3dmd 3dmd.FCS dd if=3dmd.bpatch.144284 of=3dmd seek=144284 bs=1 conv=notrunc After which you should have the following checksums: MD5 (3dmd.FCS) = e6b0212a2b7ce6f4892fea7751c8d711 MD5 (3dmd) = 8e2254774524dcc88d31acb8c4882779 The above patch changes 3dmd to supply the RFTRHEAD argument to rfork(). The problem was fixed bye the above patch, the 3dmd works well. Thanks!! I think it should be included in the ports/sysutils/3dm, how do you think? regards. --- Shingo WATANABE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Thu, May 29, 2003 at 09:20:23AM +0930, Daniel O'Connor wrote: On Wed, 28 May 2003 23:58, Steve Kargl wrote: Because there are other, more elegant ways of dealing with these things. I don't like /usr/local/src anything, which was the main complaint. If there are more elegant solutions I would like to know what they are. I agree it isn't a great solution, but I can't see what is better. For GPL modules, put them in src/sys/gnu. If you don't want bloat, then use cvsup and a refuse file to not retrieve the sys/gnu. See the discussion that occurred many years ago when maestro3 support was committed to the tree. For non-viral licensed code, put it in its proper place in the sys/ hierarchy. Then use a WANT_XXX=yes knob in the /etc/make.conf to cause XXX to be built. You are describing how it happens now, not WHY it happens like that. The WHY is obvious. The modules (1) get rebuilt with the kernel. (2) get installed with the kernel. (3) get moved to /boot/kernel.old when a new kernel is installed. (4) *Ideally*, if an API changes, the modules will be updated by the developer/committer who breaks the modules; otherwise, a person experiencing the breakage can ask for the commit to be backed out. (Note, the *ideally* acknowledges that 64-bit platforms seem to suffer API breakage more than ia32). I think the existing solution has problems, and would prefer some external hooks for 3rd party modules. If you mean third party modules without available sources, then (1) The module should work for whatever -RELEASE i for which it was built. (2) If you upgrade the OS, the module may or may not work. (a) If it works, well aren't you lucky. (b) If it doesn't work, then (i) Ask the vendor for an update. (ii) Hack around the breakage. (iii) Downgrade to the *PROPER* -RELEASE. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
DELL CERC amr RAID card beeping, dead drive? how to diagnose/fix?
I have a DELL 600SC which came with a DELL CERC RAID controller. It's recognized by FreeBSD-CURRENT as an amr device even though it's got four ATA disk channels on it instead of the documented SCSI drives for the PERC controller. I have 4x WD1200JB ATA 120GB disks on it which have been running fine for a few months as a set of RAID-5 volumes. From dmesg: amrd0: LSILogic MegaRAID logical drive on amr0 amrd0: MB (20477952 sectors) RAID 5 (optimal) amrd1: LSILogic MegaRAID logical drive on amr0 amrd1: 111093MB (227518464 sectors) RAID 5 (optimal) amrd2: LSILogic MegaRAID logical drive on amr0 amrd2: 111093MB (227518464 sectors) RAID 5 (optimal) amrd3: LSILogic MegaRAID logical drive on amr0 amrd3: 111099MB (227530752 sectors) RAID 5 (optimal) An hour ago, it started beeping at me. I suspect this is the CERC card warning me that one of the disk drives has failed and that I'd better do something about it. :-( Is there a way to diagnose it from a live system, to query which of the four ATA drives it thinks is dead, so I can replace it? (Seems to me that a WD1200JB drive should last a lot longer than a few months it's been running, in a properly ventilated DELL box; any ideas?) Anyone have experience with this CERC controller and replacing a drive? My biggest fear is that I haven't tested the RAID rebuild and that even when I do replace the failed (?) drive it won't do the automatic rebuild and save my data. Other suggestions? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Wed, 28 May 2003 21:57:35 -0500 Glenn Johnson [EMAIL PROTECTED] wrote: It seems to be working fine on a UP machine but it locks up my SMP machine just trying to load a gnome session. It leaves an image on the screen but the keyboard and mouse stop responding and I can not ssh into the box. Please try the attached patch and let me know how it works. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve Index: lib/libthr/thread/thr_create.c === RCS file: /home/ncvs/src/lib/libthr/thread/thr_create.c,v retrieving revision 1.9 diff -u -r1.9 thr_create.c --- lib/libthr/thread/thr_create.c 26 May 2003 00:37:07 - 1.9 +++ lib/libthr/thread/thr_create.c 29 May 2003 03:58:47 - @@ -171,7 +171,6 @@ new_thread-uniqueid = next_uniqueid++; THREAD_LIST_LOCK; - _thread_critical_enter(new_thread); /* * Check if the garbage collector thread @@ -202,8 +201,6 @@ /* Return a pointer to the thread structure: */ (*thread) = new_thread; - - _thread_critical_exit(new_thread); /* * Start a garbage collector thread ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Thu, 29 May 2003 12:48, Steve Kargl wrote: You are describing how it happens now, not WHY it happens like that. The WHY is obvious. The modules (1) get rebuilt with the kernel. (2) get installed with the kernel. (3) get moved to /boot/kernel.old when a new kernel is installed. (4) *Ideally*, if an API changes, the modules will be updated by the developer/committer who breaks the modules; otherwise, a person experiencing the breakage can ask for the commit to be backed out. (Note, the *ideally* acknowledges that 64-bit platforms seem to suffer API breakage more than ia32). I think the existing solution has problems, and would prefer some external hooks for 3rd party modules. If you mean third party modules without available sources, then (1) The module should work for whatever -RELEASE i for which it was built. (2) If you upgrade the OS, the module may or may not work. (a) If it works, well aren't you lucky. (b) If it doesn't work, then (i) Ask the vendor for an update. (ii) Hack around the breakage. (iii) Downgrade to the *PROPER* -RELEASE. No, I mean third party modules with available sources, but not necessarily up to scratch code wise, or license wise. I think if the code is committed there is a much greater onus to make sure it doesn't break, and it incrases the load on everyone testing things. My basic point is that people want to use 3rd party modules - they aren't committers so it's not like they can just wack some code into the repo. The alternative for them is manual patching or using the ports framework - this is OK but suffers integration problems. I just want some way of rebuilding my 3rd party modules with my kernel that doesn't involve me having to jump through hoops :( I don't see what the down side of rebuilding 3rd party modules with a buildkernel and friends is. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-BETA2 pkg_info wierdness
Instead of simple text lines, pkg_info is returning what looks like escaped words after clean install of 5.1-BETA2: pkg_info|more Hermes-1.3.2Fast\ pixel\ formats\ conversion\ libraryMesa-3.4.2_2 A\ graphics\ library\ similar\ to\ SGI\'s\ OpenGLORBit-0.5.17 High-performance\ CORBA\ ORB\ with\ support\ for\ the\ C\ l ORBit2-2.6.1_1 High-performance\ CORBA\ ORB\ with\ support\ for\ the\ C\ l XFree86-FontServer-4.3.0_1 XFree86-4\ font\ serverXFree86-NestServer-4.3.0_1 XFree86-4\ nested\ X\ serverXFree86-PrintServer-4.3.0 XFree86-4\ print\ serverXFree86-Server-4.3.0_8 XFree86-4\ X\ server\ and\ related\ programsXFree86-VirtualFramebufferServer-4.3.0_1 XFree86-4\ virtual\ framebuffer\ serverXFree86-clients-4.3.0_2 XFree86-4\ client\ programs\ and\ related\ filesXFree86-documents-4.3.0 XFree86-4\ documentationXFree86-font100dpi-4.3.0 XFree86-4\ bitmap\ 100\ dpi\ fontsXFree86-font75dpi-4.3.0 XFree86-4\ bitmap\ 75\ dpi\ fontsXFree86-fontCyrillic-4.3.0 XFree86-4\ Cyrillic\ fontsXFree86-fontDefaultBitmaps-4.3.0 XFree86-4\ default\ bitmap\ fontsXFree86-fontEncodings-4.3.0 XFree86-4\ font\ encoding\ filesXFree86-fontScalable-4.3.0 XFree86-4\ scalable\ fontsXFree86-libraries-4.3.0_4 XFree86-4\ libraries\ and\ headersXFree86-manuals-4.3.0 XFree86-4\ man\ pagesXft-2.1.2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
Mike Makonnen wrote: Most major locking work in libthr is finished. I believe it is stable enough now that it can be used for most applications[1]. I would appreciate it if people would try it out and report any bugs. I had been running with libc_r symlinked to libthr for a few days with no problems, and rebuilt some ports during that time. The machine (SMP) would sometimes freeze solid (no panic). I symlinked libc_r back to the original library, and from then on, starting gnomepanel and some other gnome pieces would fail due to errors about libthr. I couldn't find them in any log file right now, but I think I remember one was about getpwuid_r not being found. (The ports that caused problems were gnome 2.3 beta ports from the marcuscom CVS tree.) From what I understand, libthr should be a drop-in replacement for libc_r, so I was surprised to see this, but maybe I misunderstood? The problem was fixed by building/reinstalling the problematic ports without libthr symlinked into place. I'll try to get a dump of the exact error messages when I have access to the box again in a few days. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Libthr stable enough for testing
Hi Lars. On Wed, 28 May 2003 22:20:19 -0700 Lars Eggert [EMAIL PROTECTED] wrote: The problem was fixed by building/reinstalling the problematic ports without libthr symlinked into place. Can you try to use WITH_LIBMAP=YES feature in /usr/src/libexec/ rtld-elf/Makefile(SEE ALSO: libmap.conf(5)). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
In the last episode (May 29), Mike Makonnen said: On Wed, 28 May 2003 21:57:35 -0500 Glenn Johnson [EMAIL PROTECTED] wrote: It seems to be working fine on a UP machine but it locks up my SMP machine just trying to load a gnome session. It leaves an image on the screen but the keyboard and mouse stop responding and I can not ssh into the box. Please try the attached patch and let me know how it works. Index: lib/libthr/thread/thr_create.c The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-BETA2 Syslog/Named problems
5.1-BETA2 (05/24) install (cvsup 05/28 updated) is experiencing syslog/named problems not encountered under 5.1-BETA1. Named is running as it was in 5.1-BETA1 and BETA2 before 05/28 cvsup. An NSSWITCH.CONF file was added to see if that would make any difference, but it did not. Snippet from boot messages: Starting syslogd. May 29 00:33:40 kern.emerg syslogd: bind: Can't assign requested address syslogd: child pid 140 exited with return code 1 Starting named. opensocket_f: bind([0.0.0.0].0): Can't assign requested address ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-BETA2 pkg_info wierdness
On Thu, May 29, 2003 at 12:15:20AM +, [EMAIL PROTECTED] wrote: Instead of simple text lines, pkg_info is returning what looks like escaped words after clean install of 5.1-BETA2: Already fixed, thanks. Kris pgp0.pgp Description: PGP signature
Re: Libthr stable enough for testing
On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_unix.c [PATCH].
Pawel Jakub Dawidek [EMAIL PROTECTED] writes: I think there is no need to open a PR for this. Argument 'flags' marked as unused is used in those functions: Yeah. It shouldn't be, though, pretty much everyone (including the Sun engineers in charge of PAM) agrees that PAM_DISALLOW_NULL_AUTHTOK is evil and should go away. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 28 May 2003, Marcin Dalecki wrote: Harti Brandt wrote: MDNO no and again no. This would repeat the same design mistake MDthat is already in Linux. On API level you DO NOT WANT versioning. MDWhat you really want is: type signature cheking. Like for example MDdone through C++ symbol mangling rules. If you can't do it like that MDthen better leave it off as it is. Versioning in itself Type signature checking doesn't help you if the semantics of an API change without type changes. APIs should be semantically and syntactically stable in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party driver for current is a nightmare, but may no be necessary once we have a -STABLE based on FreeBSD5. Sure sure. Perhaps I wasn't clear enough. Versioning doesn't help you *anything* at all, but it is introducing new problems instead. Tons of them in fact, if one looks at the Linux pain in this area. I suggested type signature cheking in C++ style just to show how fundamentally flawed the idea of version cheking is, but I can perfectly life with the situation as it is. Uhh... it is not true that versioning does not help anything at all. i'm not sure what type signatures would help you with - knowing that foo(int, void *) still has teh same siganture doesn't tell you anything about what must be passed in as values what assumptions about call order with bar(void *) exist or anything else. Symbol versioning is good to implement multi-flavoured single binary objects (glibc uses it this way) and *not* for interface cheking. Again my main point is versioning on the symbol level simply makes no sense and worsens the situation. It's the fundamentally wrong approach to the actual problem. The fact that Linux does something like this is only showing that Alan Cox and Keith Owens didn't get it either and one shouldn't repeat the mistake. uhhh... symbol versioning != library versioning and really, in case of glibc is pretty useless, very few if any glibc 2.2 progarms woiuld actually run on a 2.1 system, making it all pretty pointless No more no less. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
