Getting an OpenPAM module to work on 5.0-RELEASE
Hi,
I'm trying to write a MySQL authentication PAM module to be used with
Cyrus-imapd2 and salsauthd, since pam-mysql is broken wrt OpenPAM.
I started from the base modules source and added mysql code in it. The problem
is to get the compiled shared library to work.
The authentication always fail, not even loading the module with this error :
saslauthd[94536]: in openpam_load_module(): no pam_sql.so found
saslauthd[94536]: DEBUG: auth_pam: pam_start failed: failed to load module
saslauthd[94536]: AUTHFAIL: user=oli service=imap realm= [PAM start error]
I kept the structure of the pam_unix OpenPAM module and am using the following
Makefile :
LIB = pam_sql
SHLIB_NAME = pam_sql.so
SRCS= pam_sql.c
CFLAGS += -I/usr/local/include
DPADD = ${LIBCRYPT}
LDADD = -lcrypt
.include bsd.lib.mk
'make' and make 'install' work fine, and put a pam_sql.so and a 'libpam_sql.a'
file in /usr/lib.
I tried every variation of this line in my /etc/pam.d/imap file to no avail :
auth requiredpam_sql.so no_warn
I always get the same kind of error, even when specifying the full path to the
module in the /etc/pam.d/imap file. Looking at the source code for the
openpam_load_module() and openpam_dynamic() functions revealed nothing weird.
What is it I am doing wrong? I will be glad to provide more info if needed.
Thanks a lot in advance for any ideas.
(Please Cc: to me since I am not currently subscribed to -current)
Olivier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
BuildKernel Error
Hi, I'm having some problems with buildkernel on the latest current from CVS: (Apolgies if the formatting comes out slightly munged) === lib/libgeom cc -O -pipe -mcpu=pentiumpro -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libgeom/geom_stats.c -o geom_stats.o In file included from /usr/obj/usr/src/i386/usr/include/libgeom.h:34, from /usr/src/lib/libgeom/geom_stats.c:38: /usr/obj/usr/src/i386/usr/include/geom/geom_stats.h:44:field `it' has incomplete type /usr/obj/usr/src/i386/usr/include/geom/geom_stats.h:45:field `wentidle' has incomplete type /usr/obj/usr/src/i386/usr/include/geom/geom_stats.h:51:field `dt' has incomplete type *** Error code 1 Stop in /usr/src/lib/libgeom. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any ideas what is the cause of this? Thanks Simon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __semctl() prototype
On Sat, 8 Feb 2003, Kris Kennaway wrote: Can someone take a look at lib/libc/gen/semctl.c and tell me where the __semctl() sysctl should be prototyped? In sys/sem.h, line __sysctl() is in sys/sysctl.h. Similarly for any other unprototyped implementation-detail syscalls. __sysctl() seems to be another. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _fpathconf() and __semctl() prototypes
On Sat, 8 Feb 2003, Kris Kennaway wrote: On Sat, Feb 08, 2003 at 02:59:30PM -0800, Kris Kennaway wrote: Can someone take a look at lib/libc/gen/semctl.c and tell me where the __semctl() sysctl should be prototyped? Also _fpathconf() in lib/libc/gen/statvfs.c _fpathconf() is quite different from __semctl. It is not a syscall. It is a weak alias for fpathconf() which is prototyped normally in unistd.h. The prototype for fpathconf() should be turned into a prototype for _fpathconf() by namespace.h, but statvfs.c is missing theinclude of unistd.h so this doesn't happen. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- 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/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Feb 9 03:15:19 PST 2003 -- Kernel build for GENERIC completed on Sun Feb 9 03:46:56 PST 2003 -- Kernel build for LINT started on Sun Feb 9 03:46:56 PST 2003 -- === vinum Makefile, line 4458: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic in fork()
On Sun, 2003/02/09 at 14:39:36 +1100, Tim Robbins wrote:
On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote:
On Sat, Feb 08, 2003 at 04:12:26PM +0100, Thomas Moestl wrote:
addr2line will usually point to the first line of a statement if it
spans multiple lines; in this case, the full guard is:
while (p2-p_pid == trypid ||
p2-p_pgrp-pg_id == trypid ||
p2-p_session-s_sid == trypid) {
OK, I suspected that.
tjr was looking into this last night and proposed the following patch:
Alfred was the one who pointed out that holding proctree was probably
necessary, though :-)
I don't really get why this is required - the pg_session pointer in
struct pgrp is constant over the pgrp's lifetime, so for it to be
invalid the wrong struct pgrp must be referenced; the p_pgrp pointer
is protected by the process lock however, which is held for this check.
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
The cbus driver for pc98
I have made the cbus driver for pc98 based on i386 isa driver. This completely removes that PC98 depends on isa driver and also corrects directory layouts (pc98/i386 - pc98/pc98 and pc98/pc98 - pc98/cbus). The full patch can get from http://home.jp.FreeBSD.org/~nyan/patches/cbus.diff.gz Soeren, please review the ata part. http://home.jp.FreeBSD.org/~nyan/patches/cbus-ata.diff.gz Warner, please review the oldcard part. http://home.jp.FreeBSD.org/~nyan/patches/cbus-pccard.diff.gz If it has no problem, I'll commit after required repository copy. --- TAKAHASHI Yoshihiro [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The cbus driver for pc98
It seems Takahashi Yoshihiro wrote: I have made the cbus driver for pc98 based on i386 isa driver. This completely removes that PC98 depends on isa driver and also corrects directory layouts (pc98/i386 - pc98/pc98 and pc98/pc98 - pc98/cbus). Soeren, please review the ata part. http://home.jp.FreeBSD.org/~nyan/patches/cbus-ata.diff.gz That looks good to me, it does conflict with my current ATA version soon to be released but I'll try to integrate it there as well. It would be nice if we could get rid of the old wd* crap at the same time, forcing user to the new system seems to be the only way to get me proper error reports :/ -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote: The compiler didn't complain when he checked it before committing it because optimization was off by default; it should have complained, e.g.: Is that really what you meant? I don't believe it has anything to do with optimization; rather, it is to do with lack of `warning' flags. For example, if you build libc with WARNS=5 (so as to get the `-Wuninitialized' flag), then you get this warning. x.c:9:warning: `foo' might be used uninitialized in this function Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any chance of getting these OpenSSL warnings quieted?
On Sat, Feb 08, 2003 at 04:39:13PM -0800, David O'Brien wrote: cc -pipe -O -march=athlon -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c /FBSD/src/lib/msun/src/e_gammaf_r.c -o e_gammaf_r.o In file included from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/e_os2.h:56, from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/symhacks.h:58, from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/crypto.h:78, from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/bio.h:67, from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/err.h:68, from /FBSD/src/crypto/openssl/crypto/cpt_err.c:62: /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/opensslconf.h:177:1: warning: OPENSSL_NO_KRB5 redefined /FBSD/src/crypto/openssl/crypto/cpt_err.c:1:1: warning: this is the location of the previous definition Yes, I'll eliminate these today. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sat, Feb 08, 2003, David Schultz wrote: Yes, the possibility of being bitten by compiler bugs is certainly higher with higher optimization levels. Alpha with -O2 seems to have been broken for years, and I have seen strange things happen on IA64 as well. But the i386 code generators have received much wider testing and debugging, so there is somewhat less danger there. Yet squid under i386 freebsd is .. well, finds -O bugs in gcc. We gave up trying -O under FreeBSD a long time ago. :-) (note: I've seen better performance gains by telling gcc exactly what CPU you have over -O65536 ..) Adrian -- Adrian Chaddangryskul learning is bad [EMAIL PROTECTED] angryskul it just makes the people around you dumber (angryskul == alfred@irc) angryskul :( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sun, Feb 09, 2003 at 08:03:57AM -0600, Jacques A. Vidrine wrote:
On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote:
The compiler
didn't complain when he checked it before committing it because
optimization was off by default; it should have complained, e.g.:
Is that really what you meant? I don't believe it has anything to
do with optimization; rather, it is to do with lack of `warning'
flags. For example, if you build libc with WARNS=5 (so as to get the
`-Wuninitialized' flag), then you get this warning.
x.c:9:warning: `foo' might be used uninitialized in this function
Some warnings are not generated unless you compile with optimization
on. The reason for this is that to generate some of the warnings (for
example about uninitialized variables) you need to do some dataflow
analysis and gcc only does this when optimizing.
Take for example this little program:
#include stdio.h
int main(void)
{
int a;
printf(%d\n,a);
return 0;
}
When compiled using 'gcc -O0 -Wall' no warnings are generated. When
compiled with 'gcc -O1 -Wall' you get a warning that 'a' might be used
uninitalized. (This is the case for gcc 2.95.x at least. I believe the
situation is the same with gcc 3.x)
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sun, Feb 09, 2003 at 03:17:12PM +0100, Erik Trulsson wrote:
On Sun, Feb 09, 2003 at 08:03:57AM -0600, Jacques A. Vidrine wrote:
On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote:
The compiler
didn't complain when he checked it before committing it because
optimization was off by default; it should have complained, e.g.:
Is that really what you meant? I don't believe it has anything to
do with optimization; rather, it is to do with lack of `warning'
flags. For example, if you build libc with WARNS=5 (so as to get the
`-Wuninitialized' flag), then you get this warning.
x.c:9:warning: `foo' might be used uninitialized in this function
Some warnings are not generated unless you compile with optimization
on. The reason for this is that to generate some of the warnings (for
example about uninitialized variables) you need to do some dataflow
analysis and gcc only does this when optimizing.
Take for example this little program:
#include stdio.h
int main(void)
{
int a;
printf(%d\n,a);
return 0;
}
When compiled using 'gcc -O0 -Wall' no warnings are generated. When
compiled with 'gcc -O1 -Wall' you get a warning that 'a' might be used
uninitalized. (This is the case for gcc 2.95.x at least. I believe the
situation is the same with gcc 3.x)
Ah, I see. Yes, it is the case with gcc 3.x.
cc1: warning: -Wuninitialized is not supported without -O
I don't think I ever knew that.
I should have tried it before posting, but the comment that the
problem was that `optimization was off by default' threw me --- it is
ON by default.
Cheers,
--
Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: printf....!
Auge Mike [EMAIL PROTECTED]: I was trying to know how printf works in FreeBSD... I hvae reached to this point : #define _write(fd, s, n) \ __syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n)) if your program runs in user-space, try strace(1) or ktrace(1). clemens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Jacques A. Vidrine wrote: On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote: The compiler didn't complain when he checked it before committing it because optimization was off by default; it should have complained, e.g.: Is that really what you meant? I don't believe it has anything to do with optimization; rather, it is to do with lack of `warning' flags. For example, if you build libc with WARNS=5 (so as to get the `-Wuninitialized' flag), then you get this warning. x.c:9:warning: `foo' might be used uninitialized in this function Uh... cc -Wall -Wuninitialized -O0 x.c cc1: warning: -Wuninitialized is not supported without -O 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Thus spake Adrian Chadd [EMAIL PROTECTED]: On Sat, Feb 08, 2003, David Schultz wrote: Yes, the possibility of being bitten by compiler bugs is certainly higher with higher optimization levels. Alpha with -O2 seems to have been broken for years, and I have seen strange things happen on IA64 as well. But the i386 code generators have received much wider testing and debugging, so there is somewhat less danger there. Yet squid under i386 freebsd is .. well, finds -O bugs in gcc. We gave up trying -O under FreeBSD a long time ago. :-) The last time someone told me, ``gcc -O is broken'', it turned out that they were doing some stack fiddling, and gcc's optimizations broke their faulty assumptions. On the other hand, I'm sure gcc -O does have bugs. Do you have an example snippet that gets miscompiled? (note: I've seen better performance gains by telling gcc exactly what CPU you have over -O65536 ..) Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
David Schultz wrote: Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. The reason is that the optimization done by GCC are ill balanced. All the scheduling of instractions and what a not - which would be fine on a micro scope level is causing so much higher pressure on the CPUs caches that the code is actually loosing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Thus spake Marcin Dalecki [EMAIL PROTECTED]: David Schultz wrote: Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. The reason is that the optimization done by GCC are ill balanced. All the scheduling of instractions and what a not - which would be fine on a micro scope level is causing so much higher pressure on the CPUs caches that the code is actually loosing. Interesting. So they redid the code generation for gcc 3 and their new tricks backfired. But at least they fixed the completely braindead things gcc 2.9x was doing with alignment, floating point, and combinations thereof, and they got the compiler to do more reasonable things on ia64. Any idea when they will have fixed the i386 anti-optimizations? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
Warner-san, I confirmed that the following problem occurs not only for fwochi but also for if_rl, if_xl, if_dc and ahc_pci. After kldload if_rl, I got wi0 timeout. (I don't even have those hardware.) All drivers above supports both pci and cardbus... Do you have any idea? /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Thu, 30 Jan 2003 01:25:19 +0900, Hidetoshi Shimokawa wrote: At Wed, 29 Jan 2003 12:49:51 +0100, Andrea Campi wrote: On Sat, Jan 25, 2003 at 11:55:01AM -0700, M. Warner Losh wrote: This sounds like it might be an interrupt storm. I'm not sure if the fwohci driver is failing to clear an interrupt source, or if the cardbus bridge is failing. Have you connected a fw device to the firewire card? I've been able to run a few more tests, even though I've not done abused it in every way I have in my mind yet... The evidence I currently have is: - if I load the modules at loader time everything is fine, with or without a device attached - if I load the modules later on, the kldload doesn't return and the system stops responding; I can still enter DDB. The only way to recover from that is to eject the card; at that point, the system is usable BUT as soon as there is network activity, the system freezes hard (can't get to DDB). IMHO this is 100% an interrupt problem. Does this ring a bell with one of you, or should I provide more info? I have another strange firewire and cardbus/pccard interaction. If I load firewire module while I'm using wi0 in cardbus slot, the wi0 stop its work and output following messages. (In my laptop, fwohci is on PCI.) wi0: xmit failed wi0: timeout in wi_cmd 0x010b; event status 0x ... Even if I replace fwochi_pci_attach() with one line 'return EIO' (i.e. the doesn't anything), the problem still happens. I think this is not a problem of fwohci. Maybe PCI or Cardbus/PCcard or kldload problem? /\ Hidetoshi Shimokawa \/ [EMAIL PROTECTED] PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xunpcb size mismatch
On Fri, 7 Feb 2003, Cyril Niklaus wrote: I've just cvsup'd and when booting I have this warning that I do not understand uname -a FreeBSD princess.wokonet.jp 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Fri Feb 7 14:40:51 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL2 i386 and the message is : sockstat: struct xunpcb size mismatch. What causes this? Google comes with nothing really. Thanks Cyril Cyril, It appears that your userland binaries are out of sync with your kernel. Rebuild world (and possibly your kernel) to fix the issue. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Do we still have a FIFO / named pipe problem?
Hi, ports/mail/gensig has a problem. It is supposed to create a named pipe (~/.signature) and wait for an application to read from the pipe. It allows to have a random signature on every mail. On 4.x and on 5-current from last year it works as expected. But since the end of the last year or the begin of this year it doesn't anymore. gensig daemonizes itself fills the named pipe and then terminates. The content of the named pipe stays the same for every mail (no wonder, gensig is gone). Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still have a FIFO / named pipe problem?
Hi, ports/mail/gensig has a problem. It is supposed to create a named pipe (~/.signature) and wait for an application to read from the pipe. It allows to have a random signature on every mail. On 4.x and on 5-current from last year it works as expected. But since the end of the last year or the begin of this year it doesn't anymore. gensig daemonizes itself fills the named pipe and then terminates. The content of the named pipe stays the same for every mail (no wonder, gensig is gone). I had the same problem with signify (which is not on ports). My fix for it was to force open() to open the file for both read and write (signify is a Perl script). I can send the patch if you need to see what I actually did. Fred -- Death is only a state of mind. Only it doesn't leave you much time to think about anything else. msg52064/pgp0.pgp Description: PGP signature
Re: Do we still have a FIFO / named pipe problem?
Yes, we do have FIFO/named pipe problems in -current. I committed a workaround to prevent one particular condition under which my diskless box would hang forever in sendmail processing in /etc/rc by setting a 1 sec timeout on the sleep it hung in. This is nowhere near correct as pointed out by Bruce, but at least my machine boots. I don't know what the bug is, Alfred looked at it some, but the patch he came up with did not work on my machine. I belive the issue rests there. Poul-Henning In message [EMAIL PROTECTED], Fred Souza writes: --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, =20 ports/mail/gensig has a problem. It is supposed to create a named pipe (~/.signature) and wait for an application to read from the pipe. It allows to have a random signature on every mail. On 4.x and on 5-current from last year it works as expected. But since the end of the last year or the begin of this year it doesn't anymore. gensig daemonizes itself fills the named pipe and then terminates. The content of the named pipe stays the same for every mail (no wonder, gensig is gone). I had the same problem with signify (which is not on ports). My fix for it was to force open() to open the file for both read and write (signify is a Perl script). I can send the patch if you need to see what I actually did. Fred --=20 Death is only a state of mind. Only it doesn't leave you much time to think about anything else. --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+RoC4KbRS1GgW4fYRAp3xAJ4lA9doM8Dty7aVgvZMePJBgGMT1ACgga17 6lX0Oy0b4KW8MheO7wZzopI= =3Ya0 -END PGP SIGNATURE- --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
P.S. With full debugs
hw.cbb.debug: 1
hw.cardbus.debug: 1
hw.cardbus.cis_debug: 1
hw.pccard.debug: 1
hw.pccard.cis_debug: 1
I see the following sequence of events in my /var/log/messages:
Feb 9 09:52:35 hammer sudo: imp : TTY=ttyp1 ; PWD=/dell/imp ; USER=root ;
COMMAND=/sbin/kldload if_rl
Feb 9 09:52:40 hammer kernel: cbb_pcic_socket_enable:
Feb 9 09:52:40 hammer kernel: cbb1: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44]
Feb 9 09:52:40 hammer kernel: cbb1: cbb_power: CARD_VCC_5V and CARD_VPP_VCC [15
]
Feb 9 09:52:40 hammer kernel: an0: RID access failed
Most cards do *NOT* like being turned off.
This suggests that the following code may be wrong:
static void
cardbus_driver_added(device_t cbdev, driver_t *driver)
{
...
device_get_children(cbdev, devlist, numdevs);
DEVICE_IDENTIFY(driver, cbdev);
-- POWER_ENABLE_SOCKET(device_get_parent(cbdev), cbdev);
for (tmp = 0; tmp numdevs; tmp++) {
if (device_get_state(devlist[tmp]) == DS_NOTPRESENT) {
dinfo = device_get_ivars(devlist[tmp]);
...
}
At a guess, the POWER_ENABLE_SOCKET should be done later. Or maybe
not even at all (the pccard code that does this works :-). In fact,
I'm positive that this is what's causing the breakage.
Maybe something more like the following would be closer to correct:
static void
cardbus_driver_added(device_t cbdev, driver_t *driver)
{
int numdevs;
device_t *devlist;
int tmp;
struct cardbus_devinfo *dinfo;
DEVICE_IDENTIFY(driver, cbdev);
device_get_children(cbdev, devlist, numdevs);
for (tmp = 0; tmp numdevs; tmp++) {
if (device_get_state(devlist[tmp]) != DS_NOTPRESENT)
continue;
dinfo = device_get_ivars(devlist[tmp]);
cardbus_print_verbose(dinfo);
resource_list_init(dinfo-pci.resources);
cardbus_do_cis(cbdev, dinfo-pci.cfg.dev);
if (device_probe_and_attach(dinfo-pci.cfg.dev) != 0)
cardbus_release_all_resources(cbdev, dinfo);
}
free(devlist, M_TEMP);
}
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
shimokawa-san, This sounds like an interrupt storm of some sort. There are indications from other sources that there may be an interrupt in the cardbus bridge that isn't being properly cleared for reasons as yet unknown. It doesn't seem to happen on all the machines, since my laptop is unaffected. I'm rather busy with work for the next few days, but I will try to investigate it when things settle down. H, actually I'm a bit hasty in my assessment. With my an card, if I kldload if_rl, bad things happen. I'll look into that when I get a chance. This is with a three week old kernel, but I have no reason to believe that its been fixed in the interrum. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still have a FIFO / named pipe problem?
On Sun, 9 Feb 2003, Alexander Leidinger wrote:
ports/mail/gensig has a problem. It is supposed to create a named pipe
(~/.signature) and wait for an application to read from the pipe. It
allows to have a random signature on every mail. On 4.x and on 5-current
from last year it works as expected. But since the end of the last year
or the begin of this year it doesn't anymore. gensig daemonizes itself
fills the named pipe and then terminates. The content of the named pipe
stays the same for every mail (no wonder, gensig is gone).
Blocking opens of named pipes for writing were broken in:
% RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
% Working file: fifo_vnops.c
% head: 1.81
% ...
%
% revision 1.79
% date: 2002/12/29 10:32:16; author: phk; state: Exp; lines: +6 -1
% There is some sort of race/deadlock which I have not identified
% here. It manifests itself by sendmail hanging in fifoow during
% boot on a diskless machine with sendmail disabled.
%
% Giving the sleep a 1sec timout breaks the deadlock, but does not solve
% the underlying problem.
%
% XXX comment applied.
%
This change makes such opens bogusly time out after 1 second (unless
there is already a writer).
There seems to be a race in fifo_open(): opens for read don't terminate
the wait if the reader goes away before the opener looks. It is not
clear if sendmail is affected by this race or one of its own.
Untested fix for this and rev.1.79, and for a similar race in blocking
opens of named pipes for reading:
%%%
Index: fifo_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
retrieving revision 1.81
diff -u -2 -r1.81 fifo_vnops.c
--- fifo_vnops.c13 Jan 2003 00:28:57 - 1.81
+++ fifo_vnops.c9 Feb 2003 17:32:16 -
@@ -227,5 +227,5 @@
}
if ((ap-a_mode FREAD) (ap-a_mode O_NONBLOCK) == 0) {
- while (fip-fi_writers == 0) {
+ if (fip-fi_writers == 0) {
VOP_UNLOCK(vp, 0, td);
error = tsleep((caddr_t)fip-fi_readers,
@@ -234,4 +234,9 @@
if (error)
goto bad;
+ /*
+* We must have got woken up because we had a writer.
+* That (and not still having one) is the condition
+* that we must wait for.
+*/
}
}
@@ -243,16 +248,16 @@
}
} else {
- while (fip-fi_readers == 0) {
+ if (fip-fi_readers == 0) {
VOP_UNLOCK(vp, 0, td);
- /*
-* XXX: Some race I havn't located is solved
-* by timing out after a sec. Race seen when
-* sendmail hangs here during boot /phk
-*/
error = tsleep((caddr_t)fip-fi_writers,
- PCATCH | PSOCK, fifoow, hz);
+ PCATCH | PSOCK, fifoow, 0);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (error)
goto bad;
+ /*
+* We must have got woken up because we had
+* a reader. That (and not still having one)
+* is the condition that we must wait for.
+*/
}
}
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sat, Feb 08, 2003 at 04:25:42PM -0800, David Schultz wrote: Yes, the possibility of being bitten by compiler bugs is certainly higher with higher optimization levels. Alpha with -O2 seems to have been broken for years, and I have seen strange things happen on IA64 as well. But the i386 code generators have received much wider testing and debugging, so there is somewhat less danger there. I'm always compiling -current on alpha and i386 with -O2 since months. I havn't noticed any compiler related problems lately. But I never used CPUTYPE over 586/mmx and ev56 as my -current machines end here. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Does bg fsck have problems with large filesystems?
On Tue, Jan 28, 2003 at 06:31:42PM +0100, Gerrit Kühn wrote: I've been trying to reproduce this bug on my desktop. This machine has 2 80gb disks, one of which is dedicated with one slice. So far, after 8 hard resets, I haven't had any problem with either the machine or bgfsck hanging. I'll try to reproduce the thing on my machine as soon as possible. Perhaps it was just because it was Monday, who knows... Meanwhile I found out that my problem is 100% reproducible. My file systems look like this: Filesystem 1K-blocksUsedAvail Capacity Mounted on /dev/ad0s1a257838 67338 16987428%/ devfs 1 10 100%/dev /dev/ad0s1g 57467672 2 52870258 0%/export /dev/ad0s1f 4125838 4 3795768 0%/tmp /dev/ad0s1e 12383502 1336152 1005667012%/usr /dev/ad0s1d 41258383458 3792314 0%/var When booting with non-clean filesystems, bgfsck runs quickly over a, d, e and f. However, on g it keeps running forever. I can't kill the fsck processes and I can't access g, though the rest of the system seems to be usable as usual. Here is the output of ps axl: UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -16 0 0 12 sched DLs ??0:00.00 (swapper) 0 1 0 0 8 0 712 392 wait ILs ??0:00.01 /sbin/init - 0 2 0 0 -8 0 0 12 g_even DL??0:00.02 (g_event) 0 3 0 0 -8 0 0 12 g_up DL??0:00.09 (g_up) 0 4 0 0 -8 0 0 12 g_down DL??0:00.19 (g_down) 0 5 0 0 -84 0 0 12 actask IL??0:00.00 (acpi_task0 0 6 0 0 -84 0 0 12 actask IL??0:00.00 (acpi_task1 0 7 0 0 -84 0 0 12 actask IL??0:00.00 (acpi_task2 0 8 0 0 -16 0 0 12 psleep DL??0:00.00 (pagedaemon 0 9 0 0 20 0 0 12 psleep DL??0:00.00 (vmdaemon) 010 0 0 -16 0 0 12 ktrace DL??0:00.00 (ktrace) 011 0 110 -16 0 0 12 - RL??2:20.07 (idle) 012 0 0 -48 0 0 12 - WL??0:00.12 (swi6: tty: 014 0 0 -44 0 0 12 - WL??0:00.00 (swi1: net) 015 0 0 76 0 0 12 sleep DL??0:00.05 (random) 019 0 0 -28 0 0 12 - WL??0:00.00 (swi5: acpi 022 0 0 -64 0 0 12 - WL??0:00.28 (irq14: ata 024 0 0 -68 0 0 12 - WL??0:00.00 (irq11: rl0 025 0 0 8 0 0 12 usbevt DL??0:00.00 (usb0) 026 0 0 8 0 0 12 usbtsk DL??0:00.00 (usbtask) 027 0 0 8 0 0 12 usbevt DL??0:00.00 (usb1) 028 0 5 -68 0 0 12 - WL??0:00.00 (irq12: fwo 029 0 0 -64 0 0 12 - WL??0:00.00 (irq6: fdc0 032 0 0 -60 0 0 12 - WL??0:00.00 (irq7: ppc0 033 0 0 -60 0 0 12 - WL??0:00.02 (irq1: atkb 036 0 34 171 0 0 12 pgzero DL??0:00.47 (pagezero) 037 0 2 -4 0 0 12 snaplk DL??0:00.24 (bufdaemon) 038 0 0 20 0 0 12 syncer DL??0:00.01 (syncer) 039 0 0 -4 0 0 12 vlruwt DL??0:00.00 (vnlru) 040 0 0 8 0 0 12 nfsidl IL??0:00.00 (nfsiod 0) 041 0 0 8 0 0 12 nfsidl IL??0:00.00 (nfsiod 1) 042 0 0 8 0 0 12 nfsidl IL??0:00.00 (nfsiod 2) 043 0 0 8 0 0 12 nfsidl IL??0:00.00 (nfsiod 3) 0 246 1 0 96 0 1172 736 select Ss??0:00.03 /usr/sbin/sy 0 267 1 0 96 0 1372 1016 select Ss??0:00.03 /usr/sbin/rp 0 350 1 155 115 0 1220 992 select Is??0:00.01 /usr/sbin/mo 0 353 1 112 110 0 1168 876 select Is??0:00.13 nfsd: master 0 355 353 155 4 0 1128 748 nfsd I ??0:00.00 nfsd: server 0 356 353 155 4 0 1128 748 nfsd I ??0:00.00 nfsd: server 0 357 353 155 4 0 1128 748 nfsd I ??0:00.00 nfsd: server 0 358 353 155 4 0 1128 748 nfsd I ??0:00.00 nfsd: server 0 374 1 0 96 0 1144 680 select Ss??0:00.00 /usr/sbin/us 0 394 1 154 115 0 1196 808 select Is??0:00.01 /usr/sbin/lp 0 454 1 153 115 0 3092 2200 select Is??0:00.63 /usr/sbin/ss 0 460 1 0 96 0 3092 2544 select Ss??0:00.01 sendmail: ac 25 463 1 153 20 0 2992 2500 pause Is??0:00.00 sendmail: Qu 0 512 1 0 8 0 1236 956 nanslp Ss??0:00.01 /usr/sbin/cr 0 522 1 0 8 0 1532 1236
Re: firewire hangs on Thinkpad
At Sun, 09 Feb 2003 10:06:54 -0700 (MST),
M. Warner Losh wrote:
Feb 9 09:52:40 hammer kernel: cbb_pcic_socket_enable:
Feb 9 09:52:40 hammer kernel: cbb1: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44]
Feb 9 09:52:40 hammer kernel: cbb1: cbb_power: CARD_VCC_5V and CARD_VPP_VCC [15
]
Feb 9 09:52:40 hammer kernel: an0: RID access failed
Most cards do *NOT* like being turned off.
Aha, that explains why my card's LED turns off when I load modules.
Maybe something more like the following would be closer to correct:
static void
cardbus_driver_added(device_t cbdev, driver_t *driver)
{
int numdevs;
device_t *devlist;
int tmp;
struct cardbus_devinfo *dinfo;
DEVICE_IDENTIFY(driver, cbdev);
device_get_children(cbdev, devlist, numdevs);
for (tmp = 0; tmp numdevs; tmp++) {
if (device_get_state(devlist[tmp]) != DS_NOTPRESENT)
continue;
dinfo = device_get_ivars(devlist[tmp]);
cardbus_print_verbose(dinfo);
resource_list_init(dinfo-pci.resources);
cardbus_do_cis(cbdev, dinfo-pci.cfg.dev);
if (device_probe_and_attach(dinfo-pci.cfg.dev) != 0)
cardbus_release_all_resources(cbdev, dinfo);
}
free(devlist, M_TEMP);
}
Warner
Thanks, this fixed my problem.
/\ Hidetoshi Shimokawa
\/ [EMAIL PROTECTED]
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
At Sun, 09 Feb 2003 10:06:54 -0700 (MST),
M. Warner Losh wrote:
Feb 9 09:52:40 hammer kernel: cbb_pcic_socket_enable:
Feb 9 09:52:40 hammer kernel: cbb1: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44]
Feb 9 09:52:40 hammer kernel: cbb1: cbb_power: CARD_VCC_5V and CARD_VPP_VCC [15
]
Feb 9 09:52:40 hammer kernel: an0: RID access failed
Most cards do *NOT* like being turned off.
Aha, that explains why my card's LED turns off when I load modules.
Maybe something more like the following would be closer to correct:
static void
cardbus_driver_added(device_t cbdev, driver_t *driver)
{
int numdevs;
device_t *devlist;
int tmp;
struct cardbus_devinfo *dinfo;
DEVICE_IDENTIFY(driver, cbdev);
device_get_children(cbdev, devlist, numdevs);
for (tmp = 0; tmp numdevs; tmp++) {
if (device_get_state(devlist[tmp]) != DS_NOTPRESENT)
continue;
dinfo = device_get_ivars(devlist[tmp]);
cardbus_print_verbose(dinfo);
resource_list_init(dinfo-pci.resources);
cardbus_do_cis(cbdev, dinfo-pci.cfg.dev);
if (device_probe_and_attach(dinfo-pci.cfg.dev) != 0)
cardbus_release_all_resources(cbdev, dinfo);
}
free(devlist, M_TEMP);
}
Warner
Thanks, this fixed my problem.
/\ Hidetoshi Shimokawa
\/ [EMAIL PROTECTED]
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Does bg fsck have problems with large filesystems?
In message [EMAIL PROTECTED], Gerrit =?iso-8859-1?Q? K=FChn?= writes: On Tue, Jan 28, 2003 at 06:31:42PM +0100, Gerrit Kühn wrote: I've been trying to reproduce this bug on my desktop. This machine has 2 80gb disks, one of which is dedicated with one slice. So far, after 8 hard resets, I haven't had any problem with either the machine or bgfsck hanging. I'll try to reproduce the thing on my machine as soon as possible. Perhaps it was just because it was Monday, who knows... Meanwhile I found out that my problem is 100% reproducible. Sounds like bgfsck gets stuck in the snapshot creation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: syslog bug
* M. Warner Losh [EMAIL PROTECTED] [030209 08:39] wrote: In message: [EMAIL PROTECTED] Alfred Perlstein [EMAIL PROTECTED] writes: : syslog(3) botches things if you pass it a string that has %%m in it. : this should fix it, any comments? : With the above fix, fred %%m will produce 'fred %%ERRNO-ERROR-MESSAGE' would it not? Isn't there one too many fputc(ch, fmt_fp) in the case where you detect %%? + ++fmt; + fputc(ch, fmt_fp); instead in the '%%' if statement. This would print only one '%' ala printf. Heh, the format string is passed through printf later, we don't want to eat the extra % otherwise it will cause problems for us. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
David Schultz wrote: Thus spake Marcin Dalecki [EMAIL PROTECTED]: David Schultz wrote: Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. The reason is that the optimization done by GCC are ill balanced. All the scheduling of instractions and what a not - which would be fine on a micro scope level is causing so much higher pressure on the CPUs caches that the code is actually loosing. Interesting. So they redid the code generation for gcc 3 and their new tricks backfired. But at least they fixed the completely braindead things gcc 2.9x was doing with alignment, floating point, and combinations thereof, and they got the compiler to do more reasonable things on ia64. Any idea when they will have fixed the i386 anti-optimizations? Well one of the aims seems currently to fix the most hideous design idiocy inside GCC. Namely: optimizing on the code generation level only instead of the parse tree. However at the current speed of things they will maybe only in about 10 years there. It would make much more sense to support efforts like www.tendra.org or www.openwatcom.org instead of giving any kind of hope to GCC. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: syslog bug
On Sun, Feb 09, 2003 at 10:00:02AM -0800, Alfred Perlstein wrote: Heh, the format string is passed through printf later, we don't want to eat the extra % otherwise it will cause problems for us. I had exactly the same thought as Warner last night, but then realised that we were about to call printf on the string. Could it be worth adding a comment, to indicate it is not a dittographic error? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- 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/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === gnu/usr.bin/binutils/objdump ../libbinutils/libbinutils.a(bucomm.o): In function `make_tempname': bucomm.o(.text+0x4c0): warning: mktemp() possibly used unsafely; consider using mkstemp() /bin/sh:Permission denied *** Error code 1 Stop in /local0/scratch/des/src/gnu/usr.bin/binutils/objdump. *** Error code 1 Stop in /local0/scratch/des/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /local0/scratch/des/src/gnu/usr.bin. *** Error code 1 Stop in /local0/scratch/des/src/gnu. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
C conformance.
Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. I think that somthing like to above should not appear in system headers. -- Marcin Dalecki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
C conformance
The following ain't pretty as well: /usr/include/machine/signal.h, line 130: Error: [Syntax]: Parse error before '__aligned'. [Syntax]: Can't recover from this error. -- Marcin Dalecki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
TR : IPFilter
Hello all, I was just wondering something regarding IPFilter and new FreeBSD 5.0 First, I was looking for IPF related functions in new Kernel building, didn't found them anywhere.maybe I did something wrong but not likely. Is it now a non kernel related application ? Btw, I was looking for some docs on the FreeBSD website and didn't found anything interesting, only firewall that FreeBSD seems to support nowadays is the old IPFW, which is quite obsolete now imo. Why are documentation pages not dealing with IPF at all ? is there any reason ? Thanx. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: TR : IPFilter
Btw, I was looking for some docs on the FreeBSD website and didn't found anything interesting, only firewall that FreeBSD seems to support nowadays is the old IPFW, which is quite obsolete now imo. Why are documentation pages not dealing with IPF at all ? is there any reason ? Try ipfw2 -Don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
devel/stlport compile broken in -current
looks like nobody has fixed stlport since the last time gcc was upgraded... (i don't know C++ very well, so wasn't able to fix it myself...) make === Extracting for stlport-gcc-4.5.3_1 Checksum OK for STLport-4.5.3.tar.gz. === stlport-gcc-4.5.3_1 depends on executable: gmake - found === Patching for stlport-gcc-4.5.3_1 === Applying FreeBSD patches for stlport-gcc-4.5.3_1 === Configuring for stlport-gcc-4.5.3_1 === Building for stlport-gcc-4.5.3_1 echo Note : this makefile requires gmake on FreeBSD Note : this makefile requires gmake on FreeBSD mkdir -p ../lib/obj/GCC-FREEBSD/ReleaseD g++ -D_THREAD_SAFE -D_REENTRANT -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O -pipe -march=athlon-mp -fPIC dll_main.cpp -c -o ../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o In file included from ../stlport/stl/_alloc.h:60, from ../stlport/memory:28, from dll_main.cpp:38: ../stlport/new:36:49: ../g++/new: No such file or directory In file included from ../stlport/stl/_alloc.h:60, from ../stlport/memory:28, from dll_main.cpp:38: ../stlport/new:45: `nothrow_t' not declared ../stlport/new:46: `nothrow' not declared ../stlport/new:52: `new_handler' not declared ../stlport/new:53: `set_new_handler' not declared ../stlport/stl/_pthread_alloc.c: In static member function `static _STL::_Pthread_alloc_per_thread_state_Max_size* _STL::_Pthread_alloc_Max_size::_S_get_per_thread_state() [with unsigned int _Max_size = 128]': dll_main.cpp:160: instantiated from here ../stlport/stl/_pthread_alloc.c:81: invalid use of undefined type `struct std::bad_alloc' internal:81: forward declaration of `struct std::bad_alloc' dll_main.cpp:160: instantiated from here ../stlport/stl/_pthread_alloc.c:90: invalid use of undefined type `struct std::bad_alloc' internal:90: forward declaration of `struct std::bad_alloc' ../stlport/stl/_alloc.c: In static member function `static void* _STL::__malloc_alloc__inst::_S_oom_malloc(unsigned int) [with int __inst = 0]': dll_main.cpp:163: instantiated from here ../stlport/stl/_alloc.c:75: invalid use of undefined type `struct std::bad_alloc' internal:75: forward declaration of `struct std::bad_alloc' internal: In function `void _STL::_Construct(_T1*, const _T2) [with _T1 = void*, _T2 = void*]': ../stlport/stl/_alloc.h:365: instantiated from `void _STL::allocator_Tp::construct(_Tp*, const _Tp) const [with _Tp = void*]' dll_main.cpp:169: instantiated from here internal:85: too many arguments to function `void* operator new(unsigned int) ' ../stlport/stl/_construct.h:85: at this point in file internal: In function `void _STL::_Construct(_T1*, const _T2) [with _T1 = char, _T2 = char]': ../stlport/stl/_alloc.h:365: instantiated from `void _STL::allocator_Tp::construct(_Tp*, const _Tp) const [with _Tp = char]' dll_main.cpp:184: instantiated from here internal:85: too many arguments to function `void* operator new(unsigned int) ' ../stlport/stl/_construct.h:85: at this point in file internal: In function `void _STL::_Construct(_T1*) [with _T1 = char]': ../stlport/stl/_string.h:326: instantiated from `void _STL::basic_string_CharT, _Traits, _Alloc::_M_construct_null_aux(_CharT*, const _STL::__false_type) [with _CharT = char, _Traits = _STL::char_traitschar, _Alloc = _STL::allocatorchar]' dll_main.cpp:192: instantiated from here internal:93: too many arguments to function `void* operator new(unsigned int) ' ../stlport/stl/_construct.h:93: at this point in file gmake: *** [../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o] Error 1 *** Error code 2 Stop in /usr/ports/devel/stlport. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: C conformance.
Marcin Dalecki [EMAIL PROTECTED] writes: Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. I think that somthing like to above should not appear in system headers. This is a bug in TenDRA. It looks in conditionals that don't apply for syntax errors. I use the attached workaround on my system to support TenDRA. Best regards, Mike Barcroft Index: cdefs.h === RCS file: /work/repo/src/sys/sys/cdefs.h,v retrieving revision 1.68 diff -u -r1.68 cdefs.h --- cdefs.h 21 Oct 2002 20:50:30 - 1.68 +++ cdefs.h 14 Dec 2002 16:46:57 - @@ -113,27 +113,27 @@ * in a different (wrong) way). If we do not provide an implementation * for a given compiler, let the compile fail if it is told to use * a feature that we cannot live without. + * + * XXX the check for lint here is incorrect, since either your lint supports + * GNUC or it doesn't. Some kernel source code is very GNUC-centric, so we + * need this hack here until those GNUCisms are fixed. In reality, having + * hacks like this usually extend the life of bugs. */ -#ifdef lint +#if defined(lint) #define__dead2 #define__pure2 #define__unused #define__packed #define__aligned(x) #define__section(x) -#else -#if __GNUC__ 2 || __GNUC__ == 2 __GNUC_MINOR__ 5 -#define__dead2 -#define__pure2 -#define__unused -#endif -#if __GNUC__ == 2 __GNUC_MINOR__ = 5 __GNUC_MINOR__ 7 +/* Older GCC versions default to NOP for everything. */ +#elif __GNUC__ == 2 __GNUC_MINOR__ = 5 __GNUC_MINOR__ 7 #define__dead2 __attribute__((__noreturn__)) #define__pure2 __attribute__((__const__)) -#define__unused +/* XXX __aligned() is too critical to working code to safely be defined away. */ +#define__aligned(x) /* XXX Find out what to do for __packed, __aligned and __section */ -#endif -#if __GNUC__ == 2 __GNUC_MINOR__ = 7 || __GNUC__ == 3 +#elif __GNUC__ == 2 __GNUC_MINOR__ = 7 || __GNUC__ == 3 #define__dead2 __attribute__((__noreturn__)) #define__pure2 __attribute__((__const__)) #define__unused__attribute__((__unused__)) @@ -141,6 +141,25 @@ #define__aligned(x)__attribute__((__aligned__(x))) #define__section(x)__attribute__((__section__(x))) #endif + +/* + * Default to NOP for compiler-dependent extentions. + * XXX missing __aligned(), since we can't safely define it away. + */ +#ifndef __dead2 +#define__dead2 +#endif +#ifndef __packed +#define__packed +#endif +#ifndef __pure2 +#define__pure2 +#endif +#ifndef __section +#define__section(x) +#endif +#ifndef __unused +#define__unused #endif /* XXX: should use `#if __STDC_VERSION__ 199901'. */ @@ -226,6 +245,14 @@ * The alternative is: #define __IDSTRING(name,string) [nothing] */ #define__IDSTRING(name,string) static const char name[] __unused = string +#endif + +/* + * TenDRA looks inside conditionals that don't apply (ie. #if __GNUC__). + * #warning is the most likely cause of syntax errors, so work around this. + */ +#ifdef __TenDRA__ +#pragmaTenDRA directive warning (ignore) allow #endif /*
RE : IPFilter
Pardon my poor knowledge about IPFW 2 but if I remember well, IPFW wasn't a SPI Firewall, which is what I need. Btw, previous Kernel allows us to fine tune its building for IPF and now, it simply gone...was really wondering where those features are. Is there any web place where I can find stuff about IPFW2 by chance ? regards -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] De la part de Don Envoyé : dimanche 9 février 2003 19:47 À : Coercitas Temet'Nosce Cc : [EMAIL PROTECTED] Objet : Re: TR : IPFilter Btw, I was looking for some docs on the FreeBSD website and didn't found anything interesting, only firewall that FreeBSD seems to support nowadays is the old IPFW, which is quite obsolete now imo. Why are documentation pages not dealing with IPF at all ? is there any reason ? Try ipfw2 -Don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devel/stlport compile broken in -current
On Sun, Feb 09, 2003 at 10:54:27AM -0800, Lamont Granquist wrote: looks like nobody has fixed stlport since the last time gcc was upgraded... I don't get these error messages on -current. g++ -D_THREAD_SAFE -D_REENTRANT -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O -pipe -march=athlon-mp -fPIC dll_main.cpp -c -o ../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o In file included from ../stlport/stl/_alloc.h:60, from ../stlport/memory:28, from dll_main.cpp:38: ../stlport/new:36:49: ../g++/new: No such file or directory ^^^ This file should exist in /usr/include/g++/new. How did you install -current? Did you read all the entries in /usr/src/UPDATING, especially the entry dated 20020831? -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
MSDOSFS wastes 256k when nothing is mounted!
I don't have any msdos filesystems mounted, yet:
kern.malloc:
Type InUse MemUse HighUse Requests Size(s)
[...]
MSDOSFS mount 1 256K256K1
[...]
due to this:
/*ARGSUSED*/
int
msdosfs_init(vfsp)
struct vfsconf *vfsp;
{
dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);
mtx_init(dehash_mtx, msdosfs dehash, NULL, MTX_DEF);
return (0);
}
Somebody: please fix so this doesn't suck.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: TR : IPFilter
On Sun, Feb 09, 2003 at 07:42:42PM +0100, Coercitas Temet'Nosce wrote: Hello all, I was just wondering something regarding IPFilter and new FreeBSD 5.0 First, I was looking for IPF related functions in new Kernel building, didn't found them anywhere.maybe I did something wrong but not likely. Is it now a non kernel related application ? The kernel options have moved. Options that aren't platform specific are in /usr/src/sys/conf/NOTES, and the IPFILTER options are there. Btw, I was looking for some docs on the FreeBSD website and didn't found anything interesting, only firewall that FreeBSD seems to support nowadays is the old IPFW, which is quite obsolete now imo. Why are documentation pages not dealing with IPF at all ? is there any reason ? There's no real need for them. Just compile the kernel with the appropriate options and there's plenty of docs on IPF that can tell you the rest. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: syslog bug
* David Malone [EMAIL PROTECTED] [030209 10:04] wrote: On Sun, Feb 09, 2003 at 10:00:02AM -0800, Alfred Perlstein wrote: Heh, the format string is passed through printf later, we don't want to eat the extra % otherwise it will cause problems for us. I had exactly the same thought as Warner last night, but then realised that we were about to call printf on the string. Could it be worth adding a comment, to indicate it is not a dittographic error? Yes. I'll test and commit shortly. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kld problem ? (was: Re: MSDOSFS wastes 256k when nothing is mounted!)
hi,
On Sun, Feb 09, 2003 at 08:39:59PM +0100, Poul-Henning Kamp wrote:
/*ARGSUSED*/
int
msdosfs_init(vfsp)
struct vfsconf *vfsp;
{
dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);
mtx_init(dehash_mtx, msdosfs dehash, NULL, MTX_DEF);
return (0);
}
BTW, it reminds me a problem I found last month. If you've MSDOSFS
compiled in kernel and try to load msdosfs.ko with loader -- then
you're 100% will hit into 'mutex already initialized' (or something
like that) panic later in boot process. (i.e. msdosfs_init() is called
twice for some reason)
I not sure if it's applicable to KLDs at all or to msdosfs only.
Somebody: please fix so this doesn't suck.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
On Sun, 9 Feb 2003, Poul-Henning Kamp wrote:
I don't have any msdos filesystems mounted, yet:
kern.malloc:
Type InUse MemUse HighUse Requests Size(s)
[...]
MSDOSFS mount 1 256K256K1
[...]
due to this:
/*ARGSUSED*/
int
msdosfs_init(vfsp)
struct vfsconf *vfsp;
{
dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);
mtx_init(dehash_mtx, msdosfs dehash, NULL, MTX_DEF);
return (0);
}
Somebody: please fix so this doesn't suck.
msdosfs just cloned the bad example set by ufs:
%%%
int
ufs_init(vfsp)
struct vfsconf *vfsp;
{
ufs_ihashinit();
#ifdef QUOTA
dqinit();
#endif
#ifdef UFS_DIRHASH
ufsdirhash_init();
#endif
return (0);
}
void
ufs_ihashinit()
{
ihashtbl = hashinit(desiredvnodes, M_UFSIHASH, ihash);
mtx_init(ufs_ihash_mtx, ufs ihash, NULL, MTX_DEF);
}
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: printf....!
On Saturday 08 February 2003 22:12, Auge Mike wrote: Hi all, I was trying to know how printf works in FreeBSD... I hvae reached to this point : #define _write(fd, s, n) \ __syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n)) I'am not really familiar with the way FreeBSD handle interrupts. I like from any one of you to tell me what functions will be called next and in which files, till we get the string of the printf function argment displayed in the terminal. This is the syscall (kernel entry) that implements the write(2) kernel function. Then next function will be in kernel space, and will be the handler for SYS_write, the 'write' function in sys/kern/sys_generic.c. By handles interrupts I assume you meant the syscall interface, right? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: printf....!
On 2003-02-08 16:23, David Leimbach [EMAIL PROTECTED] wrote: Dave On Saturday, February 8, 2003, at 04:12 PM, Auge Mike wrote: Hi all, I was trying to know how printf works in FreeBSD... I hvae reached to this point : #define _write(fd, s, n) \ __syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n)) Isn't it ultimately interrupt 08 on the PC with an index in the EAX register for the write subroutine? Interrupt 0x80. I am pretty sure that's correct. I might have the interrupt value wrong though. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preview: GEOMs statistics code.
[EMAIL PROTECTED] wrote: I have played with the statistics collection in GEOM a bit, and need more feedback, but first: try to play with it a bit. Assuming you're running -current as of today, otherwise install include files and libgeom by hand first. Apply this patch in src/sys/geom and make a new kernel. http://phk.freebsd.dk/patch/geom_io.patch I get a Not Found from that URL. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preview: GEOMs statistics code.
In message [EMAIL PROTECTED], Mattias Pantzare writes: [EMAIL PROTECTED] wrote: I have played with the statistics collection in GEOM a bit, and need more feedback, but first: try to play with it a bit. Assuming you're running -current as of today, otherwise install include files and libgeom by hand first. Apply this patch in src/sys/geom and make a new kernel. http://phk.freebsd.dk/patch/geom_io.patch I get a Not Found from that URL. I've worked more on it since yesterday: Grab -current, update kernel, #includes and libgeom, then fetch this file: http://phk.freebsd.dk/patch/gstat.c and compile it with -lgeom -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preview: GEOMs statistics code.
On Sun, Feb 09, 2003 at 09:48:18PM +0100, Mattias Pantzare wrote: Apply this patch in src/sys/geom and make a new kernel. http://phk.freebsd.dk/patch/geom_io.patch I get a Not Found from that URL. There are many patches listed here: http://phk.freebsd.dk/patch/ Maybe the correct one is: http://phk.freebsd.dk/patch/geom_iostat.patch ? -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kld problem ? (was: Re: MSDOSFS wastes 256k when nothing ismounted!)
On Sun, 2003-02-09 at 12:16, Alexey Zelkin wrote:
hi,
On Sun, Feb 09, 2003 at 08:39:59PM +0100, Poul-Henning Kamp wrote:
/*ARGSUSED*/
int
msdosfs_init(vfsp)
struct vfsconf *vfsp;
{
dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);
mtx_init(dehash_mtx, msdosfs dehash, NULL, MTX_DEF);
return (0);
}
BTW, it reminds me a problem I found last month. If you've MSDOSFS
compiled in kernel and try to load msdosfs.ko with loader -- then
you're 100% will hit into 'mutex already initialized' (or something
like that) panic later in boot process. (i.e. msdosfs_init() is called
twice for some reason)
I not sure if it's applicable to KLDs at all or to msdosfs only.
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/34030
seems to be a similar problem.
We've seen this with the agp module when it's in the kernel and in
loader.conf. In the agp case, it appears to initialize, but then
doesn't function when other devices (DRM) try to use it. I would guess
it's being initialized twice, too.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic with hp psc 2210xi usb printer
My USB PCI hub is: ohci0: NEC uPD 9210 USB controller mem 0xec00-0xec000fff irq 5 at device 5.0 on pci2 usb0: OHCI version 1.0 usb0: NEC uPD 9210 USB controller on ohci0 usb0: USB revision 1.0 uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: NEC uPD 9210 USB controller mem 0xeb80-0xeb800fff irq 6 at device 5.1 on pci2 usb1: OHCI version 1.0 usb1: NEC uPD 9210 USB controller on ohci1 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci2: serial bus, USB at device 5.2 (no driver attached) Here's what happened when I plugged it the printer (all i did was plug it in): ulpt0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode umass0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2 umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 14, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT (da1:umass-sim0:0:0:0): got CAM status 0x4 (da1:umass-sim0:0:0:0): fatal error, failed to attach to device (da1:umass-sim0:0:0:0): lost device umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT (da1:umass-sim0:0:0:0): removing device entry Opened disk da1 - 5 Feb 9 13:08:45 coredump syslogd: kernel boot file is /boot/kernel/kernel Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x68 fault code = supervisor read, pawe not present instruction pointer= 0x8:0xc02f1d41 stack pointer (0x10:0xd7a37c0c frame pointer = 0x10:0xd7a37c2c 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= 502 (tcsh) This is from -current as of around: 5.0-CURRENT #2: Thu Feb 6 18:59:11 PST 2003 And I've deleted my kernel.debug (and sources, and object tree), so debugging the panic I got out of it is unfortunately not going to be too useful... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _fpathconf() and __semctl() prototypes
On Sun, Feb 09, 2003 at 10:47:47PM +1100, Bruce Evans wrote: On Sat, 8 Feb 2003, Kris Kennaway wrote: On Sat, Feb 08, 2003 at 02:59:30PM -0800, Kris Kennaway wrote: Can someone take a look at lib/libc/gen/semctl.c and tell me where the __semctl() sysctl should be prototyped? Also _fpathconf() in lib/libc/gen/statvfs.c _fpathconf() is quite different from __semctl. It is not a syscall. It is a weak alias for fpathconf() which is prototyped normally in unistd.h. The prototype for fpathconf() should be turned into a prototype for _fpathconf() by namespace.h, but statvfs.c is missing theinclude of unistd.h so this doesn't happen. Thanks for your help. Kris msg52099/pgp0.pgp Description: PGP signature
Synaptics touchpad support
Lest this disappear, like so much else, into the black hole that is GNATS, can some laptop user take a look at this? It works great for me, I can now scroll using the up and down touchpad buttons which were useless decorations earlier. Thanks to Marcin Dalecki. PR kern/48116 http://www.freebsd.org/cgi/query-pr.cgi?pr=48116 - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devel/stlport compile broken in -current
On Sun, 9 Feb 2003, Craig Rodrigues wrote: On Sun, Feb 09, 2003 at 10:54:27AM -0800, Lamont Granquist wrote: looks like nobody has fixed stlport since the last time gcc was upgraded... I don't get these error messages on -current. g++ -D_THREAD_SAFE -D_REENTRANT -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O -pipe -march=athlon-mp -fPIC dll_main.cpp -c -o ../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o In file included from ../stlport/stl/_alloc.h:60, from ../stlport/memory:28, from dll_main.cpp:38: ../stlport/new:36:49: ../g++/new: No such file or directory ^^^ This file should exist in /usr/include/g++/new. How did you install -current? its been updated frequently over the past 6 months - 1 year... i think there's been at least two compiler changes since i started tracking -current... Did you read all the entries in /usr/src/UPDATING, especially the entry dated 20020831? mmm i don't think i did that because it was phrased as being optional and only if you encountered problems... i'll try that, thanks for pointing it out... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Best method to produce patches?
I am about to try to make some changes to FreeBSD current... Should I begin to use read-only CVS instead of CVSup for this work or is it possible to generate diffs based on CVSup'd sources? What is the recommend method to use for playing with the source? I already found a small change in libc that should probably get committed but I want to generate the patch properly for everyone's approval. Thanks! Dave Leimbach To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Best method to produce patches?
David Leimbach [EMAIL PROTECTED] writes: I am about to try to make some changes to FreeBSD current... Should I begin to use read-only CVS instead of CVSup for this work or is it possible to generate diffs based on CVSup'd sources? What is the recommend method to use for playing with the source? I already found a small change in libc that should probably get committed but I want to generate the patch properly for everyone's approval. Most developers use CVSup to download the repo. I use the following supfile: *default host=cvsup10.freebsd.org *default base=/usr *default prefix=/work/repo *default release=cvs *default delete use-rel-suffix *default compress doc-all ports-all src-all www Then setup an alias for local operations: alias lcvscvs -d/work/repo -R Then: lcvs checkout src cd src [make changes to files] lcvs diff ~/my.diff Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
How about the attached?
It's only partially tested since it seems I can't mount any msdos floppies (both
on this _and_ my previous kernel).
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
Index: sys/fs/msdosfs/msdosfs_denode.c
===
RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v
retrieving revision 1.67
diff -u -r1.67 msdosfs_denode.c
--- sys/fs/msdosfs/msdosfs_denode.c 21 Jan 2003 08:55:46 - 1.67
+++ sys/fs/msdosfs/msdosfs_denode.c 9 Feb 2003 22:14:41 -
@@ -73,6 +73,12 @@
static u_long dehash; /* size of hash table - 1 */
#defineDEHASH(dev, dcl, doff) (dehashtbl[(minor(dev) + (dcl) + (doff) /
\ sizeof(struct direntry)) dehash])
+#define DEHASH_INIT do {\
+ if (dehashtbl == NULL) {\
+ dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);\
+ KASSERT(dehashtbl != NULL, msdosfs dehashtbl == NULL);\
+ }\
+ } while (0)
static struct mtx dehash_mtx;
union _qcvt {
@@ -102,8 +108,8 @@
msdosfs_init(vfsp)
struct vfsconf *vfsp;
{
- dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);
mtx_init(dehash_mtx, msdosfs dehash, NULL, MTX_DEF);
+ dehashtbl = NULL;
return (0);
}
@@ -112,8 +118,10 @@
struct vfsconf *vfsp;
{
- if (dehashtbl)
+ if (dehashtbl) {
free(dehashtbl, M_MSDOSFSMNT);
+ dehashtbl = NULL;
+ }
mtx_destroy(dehash_mtx);
return (0);
}
@@ -130,6 +138,7 @@
loop:
mtx_lock(dehash_mtx);
+ DEHASH_INIT;
for (dep = DEHASH(dev, dirclust, diroff); dep; dep = dep-de_next) {
if (dirclust == dep-de_dirclust
diroff == dep-de_diroffset
@@ -154,6 +163,7 @@
struct denode **depp, *deq;
mtx_lock(dehash_mtx);
+ DEHASH_INIT;
depp = DEHASH(dep-de_dev, dep-de_dirclust, dep-de_diroffset);
deq = *depp;
if (deq)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Getting an OpenPAM module to work on 5.0-RELEASE
Olivier [EMAIL PROTECTED] writes: I'm trying to write a MySQL authentication PAM module to be used with Cyrus-imapd2 and salsauthd, since pam-mysql is broken wrt OpenPAM. Wouldn't it be easier to fix the existing pam_mysql? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devel/stlport compile broken in -current
Thanks, that looks like that was the issue... On Sun, 9 Feb 2003, Lamont Granquist wrote: On Sun, 9 Feb 2003, Craig Rodrigues wrote: On Sun, Feb 09, 2003 at 10:54:27AM -0800, Lamont Granquist wrote: looks like nobody has fixed stlport since the last time gcc was upgraded... I don't get these error messages on -current. g++ -D_THREAD_SAFE -D_REENTRANT -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O -pipe -march=athlon-mp -fPIC dll_main.cpp -c -o ../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o In file included from ../stlport/stl/_alloc.h:60, from ../stlport/memory:28, from dll_main.cpp:38: ../stlport/new:36:49: ../g++/new: No such file or directory ^^^ This file should exist in /usr/include/g++/new. How did you install -current? its been updated frequently over the past 6 months - 1 year... i think there's been at least two compiler changes since i started tracking -current... Did you read all the entries in /usr/src/UPDATING, especially the entry dated 20020831? mmm i don't think i did that because it was phrased as being optional and only if you encountered problems... i'll try that, thanks for pointing it out... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Getting an OpenPAM module to work on 5.0-RELEASE
On Sun, Feb 09, 2003 at 08:03:54PM +0300, Sergey Mokryshev wrote: On Sun, 9 Feb 2003, Olivier wrote: Hi, I'm trying to write a MySQL authentication PAM module to be used with Cyrus-imapd2 and salsauthd, since pam-mysql is broken wrt OpenPAM. I started from the base modules source and added mysql code in it. The problem is to get the compiled shared library to work. Hi. Try to build native auxprop saslauthd mysql module. It removes the need of extra abstraction layer (PAM) and permits SASL special authentications (CRAM-MD5, DIGEST-MD5 etc). Ah yes, I thought about that too, but this stuff isn't documented at all it seems, and I need to be able to use blowfish for password encryption, because this has to be used with some other appplcations which are using crypt() and blowfish. From what I understand the saslauthd mysql module allows only to compare the given plaintext user whith another plaintext one stored in a DB. That won't work for me. But I don't understand much of this auxprop/mysql stuff, so I am probably mistaken, and would be most pleased to get explanations about how I can do this. Actually I had patched pam_mysql (on FreeBSD 4.x when pam_mysql was still working, to be able to use blowfish correctly with FreeBSD's crypt(), but my problem is really to get an OpenPAM module to work, I even tried to simply rename the pam_permit one, but have the same problem: openpam_load_module won't find/open it now matter what... Thanks a lot for your suggestions :-) Olivier To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- 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/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Feb 9 15:16:50 PST 2003 -- Kernel build for GENERIC completed on Sun Feb 9 15:51:53 PST 2003 -- Kernel build for LINT started on Sun Feb 9 15:51:54 PST 2003 -- === vinum Makefile, line 4458: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Grub 0.92 fails to recognise disks on FBSD5
David O'Brien [EMAIL PROTECTED] writes: On Sun, Feb 09, 2003 at 06:14:30PM +0100, Matthias Schuendehuette wrote: Nothing against 'booteasy', it does the job - but it looks ugly :-) If that is the only reason to use grub, try osbsbeta.exe that is in the tools directory of your CDROM or ftp.freebsd.org. I used to use OSBS quite a bit. Unfortunately, it is getting a bit long in the tooth; it does not boot partitions that start beyond some point. (It only knows about older BIOS functions, I suspect, which are incapable of handling very large disks.) Still seems to work very nicely if you have each OS on a separate drive. It's also somewhat annoying that the OS-BS installer runs under MSDOS. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Marcin Dalecki wrote: David Schultz wrote: Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. The reason is that the optimization done by GCC are ill balanced. All the scheduling of instractions and what a not - which would be fine on a micro scope level is causing so much higher pressure on the CPUs caches that the code is actually loosing. That's not actually it, though there *are* instruction scheduling issues that will impact the Pentium 4 code generation, and other Intel processor-specific code generation, mostly L1 caches have been, relative to the size of main memory, been getting much, much larger. Intel has written an article on How to generate optimized code for Pentium 4 processors. It has been posted to these lists a couple of times already, and you can search it out on Intel's site, if you care to. For the Pentium 4, the article identifies a shopping list of things that you are not supposed to do, which GCC does. Actually, cache pressure is the least of them. If FreeBSD would cache line align locks and mutexes, and not put them in the same cache lines (very hard to do, for some structures), most of the so-called cache pressure could be made to go away. IBM recently posted an article comparing performance numbers for Linux with and without this change. Realize, though, that FreeBSD and Linux have somewhat different philosophies when it comes to SMP, even if that's hard to tell from the lack of detailed implementation plans being published by either camp. If the ability to optimize code for the Pentium 4 concerns you, then you should become a contributor to the GCC project, which means you need to execute a notarized assignment of rights statement with the FSF before they will accept patches from you, and once that's done, you can start going down Intel's optimization laundry list, sending patches to the GCC folks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
On Sun, Feb 09, 2003 at 06:08:47PM -0500, Mike Makonnen wrote:
How about the attached?
It's only partially tested since it seems I can't mount any msdos floppies (both
on this _and_ my previous kernel).
Index: sys/fs/msdosfs/msdosfs_denode.c
===
RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v
retrieving revision 1.67
diff -u -r1.67 msdosfs_denode.c
--- sys/fs/msdosfs/msdosfs_denode.c 21 Jan 2003 08:55:46 - 1.67
+++ sys/fs/msdosfs/msdosfs_denode.c 9 Feb 2003 22:14:41 -
@@ -73,6 +73,12 @@
static u_long dehash;/* size of hash table - 1 */
#define DEHASH(dev, dcl, doff) (dehashtbl[(minor(dev) + (dcl) + (doff) /
\ sizeof(struct direntry)) dehash])
+#define DEHASH_INIT do {\
+ if (dehashtbl == NULL) {\
+ dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);\
+ KASSERT(dehashtbl != NULL, msdosfs dehashtbl == NULL);\
+ }\
+ } while (0)
static struct mtx dehash_mtx;
union _qcvt {
[...]
@@ -130,6 +138,7 @@
loop:
mtx_lock(dehash_mtx);
+ DEHASH_INIT;
for (dep = DEHASH(dev, dirclust, diroff); dep; dep = dep-de_next) {
if (dirclust == dep-de_dirclust
diroff == dep-de_diroffset
hashinit() can sleep, and I don't think it's safe to sleep here
(msdosfs_hashget() and msdosfs_hashins()) with dehash_mtx and
sometimes a vnode lock held.
It might be better to initialise the table the first time an
msdosfs filesystem is mounted.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Isn't it time to take care of those old traffic tickets?
Do you think that attorneys overcharge? http://rd.yahoo.com/^Random/075198/*http://198.170.236.87 And that is just the surface of what we offer! http://rd.yahoo.com/^Random/075198/*http://198.170.236.87 If you don't want to get anymore of these emails, click HERE: [EMAIL PROTECTED] and send us a blank email.
Re: TR : IPFilter
Coercitas Temet'Nosce wrote: I was just wondering something regarding IPFilter and new FreeBSD 5.0 First, I was looking for IPF related functions in new Kernel building, didn't found them anywhere.maybe I did something wrong but not likely. Files: /sys/netinet/ip_fil.c /sys/netinet/fil.c /sys/netinet/ip_nat.c /sys/netinet/ip_frag.c /sys/netinet/ip_state.c /sys/netinet/ip_auth.c /sys/netinet/ip_proxy.c /sys/netinet/ip_log.c /sys/netinet/mlfk_ipl.c /sys/i386/conf/LINT: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK Maybe you did something wrong. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Getting an OpenPAM module to work on 5.0-RELEASE
Olivier Dony [EMAIL PROTECTED] writes: Actually I had patched pam_mysql (on FreeBSD 4.x when pam_mysql was still working, to be able to use blowfish correctly with FreeBSD's crypt(), but my problem is really to get an OpenPAM module to work, I even tried to simply rename the pam_permit one, but have the same problem: openpam_load_module won't find/open it now matter what... In /usr/src/contrib/openpam/lib/openpam_dynamic.c, change at least the first two instances of PAM_LOG_DEBUG to PAM_LOG_ERROR, then rebuild libpam (cd /usr/src/lib/libpam make make install) and try again. OpenPAM will now log messages in /var/log/messages showing why it fails to load your module. My guess is that your module requires a library which you forgot to add to LDADD. BTW, the PAM module makefiles in the tree aren't standalone: they rely on variables set in Makefile.inc one and two levels up. Amongst other things, they add a version number to the dynamic module, and prevent the static version from being installed. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Getting an OpenPAM module to work on 5.0-RELEASE [SOLVED]
On Mon, Feb 10, 2003 at 12:34:32AM +0100, Dag-Erling Smorgrav wrote: Olivier [EMAIL PROTECTED] writes: I'm trying to write a MySQL authentication PAM module to be used with Cyrus-imapd2 and salsauthd, since pam-mysql is broken wrt OpenPAM. Wouldn't it be easier to fix the existing pam_mysql? Indeed, but that's what I'm doing, really (with some improvements), I took the framework of the example modules that come with the new OpenPAM and adapted the code from pam_mysql to work in it, thus following the new API. So basically I'm trying to fix pam_mysql, but the problem was to get OpenPAM to recognize and load the modules I build. It turned out that I missed a couple options for the linker in the Makefile, and thus the shared library probably couldn't be loaded. But the error message wasn't very helpful, and the linking was going fine. It's working now :-) I simply appended -L/usr/local/lib/mysql -lmysqlclient to my LDADD line in the Makefile. Oh and you were right, if I had simply modified the pam_mysql port those options would have been already in the Makefile, but some other needed to be removed too, so I avoided that trouble ;-) So I was being stupid again I guess, sorry for the trouble, this is my first time building shared libraries and such. Thanks again! Olivier To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Getting an OpenPAM module to work on 5.0-RELEASE
On Mon, Feb 10, 2003 at 01:38:13AM +0100, Dag-Erling Smorgrav wrote: Olivier Dony [EMAIL PROTECTED] writes: Actually I had patched pam_mysql (on FreeBSD 4.x when pam_mysql was still working, to be able to use blowfish correctly with FreeBSD's crypt(), but my problem is really to get an OpenPAM module to work, I even tried to simply rename the pam_permit one, but have the same problem: openpam_load_module won't find/open it now matter what... In /usr/src/contrib/openpam/lib/openpam_dynamic.c, change at least the first two instances of PAM_LOG_DEBUG to PAM_LOG_ERROR, then rebuild libpam (cd /usr/src/lib/libpam make make install) and try again. Ah, that's great, I will do that immediately, it sure will help anyway. Too bad I didn't see your second reply earlier, the openpam debug was part of the problem. OpenPAM will now log messages in /var/log/messages showing why it fails to load your module. My guess is that your module requires a library which you forgot to add to LDADD. Exactly, hehe, thank you ! :-) I definetly should have read your second mail, but I was busy playing with those funny PAM modules... Explanation in my previous reply with [SOLVED]. BTW, the PAM module makefiles in the tree aren't standalone: they rely on variables set in Makefile.inc one and two levels up. Amongst other things, they add a version number to the dynamic module, and prevent the static version from being installed. Ok, that's a good thing to know, I read most of those Makefiles but didn't pay much attention ;-) Thanks so much for your help again! Olivier To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: C conformance.
Marcin Dalecki wrote: Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. I think that somthing like to above should not appear in system headers. It is an ANSI compliant preprocessor directive. Please use an ANSI compliant compiler. Have you actually looked at the line? It's protected by #if __GNUC__, so your compiler shouldn't be trying to interpret any directives other than #else, #elif, or #endif (or the premature end of the file). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: C conformance
Marcin Dalecki wrote: The following ain't pretty as well: /usr/include/machine/signal.h, line 130: Error: [Syntax]: Parse error before '__aligned'. [Syntax]: Can't recover from this error. You need to add a compiler specific section to /sys/sys/cdefs.h, which defined cdefs attributes specific to your compiler. Probably, this should consist of moving the lint definitions to the bottom of the list, and instead of them being #ifdef lint, making them #ifndef __aligned or something similar, to provide a default case for tools other than GCC. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CepNews Þubat 2003
Title: CepNews TELSÝM'DEN TÜRKÝYE'YE BÝR ÝLK. Telsim, dünyanýn en büyük uydu telekomünikasyon operatörü Globalstar ile yaptýðý iþbirliði sonucunda, Türkiye'nin uydu destekli hizmet veren ilk GSM operatörü olmuþtur. Kýsaca, Telsim-Globalstar birlikteliði, dünyanýn her noktasýndaki dað, açýk deniz, ova, orman gibi yerleþim merkezlerinden uzak olan ve GSM, yani hücresel telekomünikasyon sistemlerinin kapsama alaný dýþýnda kalan bölgelerde dahi mobil iletiþim olanaðý sunmaktadýr. Ayrýntýlý bilgi için týklayýn... Cep telefonunu cep televizyonu yaptýk! Türkiye'de artýk cep telefonundan televizyon yayýnlarýný izleyebileceksiniz. Dünyada, Mobile Video Streaming (MVS) adý verilen cepte televizyon yayýný izleme imkânýný veren bu teknolojiyi, Türkiye'de, Türk bilgisayar mühendisleri yarattý. Telsim Teknolojisi'nin arkasýndaki, 150 bilgisayar mühendisi. Telsim'in Türkiye ve dünya üzerindeki rekabet gücünün ekonomik ve teknolojik boyutlarýný önemli ölçülerde artýran bu beyin gücü, Telsim'in üstünlüklerinden biri. Bu üstünlüðü sayesinde Telsim, dilediði zaman, dilediði teknolojik yenilikleri kendi yaratabiliyor. Kimseye baðýmlý olmadan devreye sokabiliyor. Ýþte bu ayrýcalýk, Telsim'le diðerleri arasýndaki farký yaratýyor. Telsim Teknolojisi, þimdi Türkiye'ye MVS, yani cepte televizyon yayýnýný sunuyor. MVS'ten yaralanarak, cep televizyonunuzdan pardon cep telefonunuzdan, 24 saat Star televizyonunu, haftanýn TOP 10 video kliplerini, futbolla ilgili haberleri, maç görüntülerini, Türkiye'den ve dünyadan önemli politik ve ekonomik haberleri, son dakika geliþmelerini, magazin haberlerini 1 Nisan 2003 tarihine kadar ücretsiz izleyebilirsiniz. Telsim'i diðerlerinden farklý kýlan mühendisler ordusunun, yani beyin gücünün Telsim'e ve Türkiye'ye getirdiði teknolojik yenilikler devam edecek. Bekleyin. Ayrýntýlý bilgi için týklayýn... Bu mesaj size Telsim Mobil Telekomünikasyon Hizmetleri A.Þ. tarafýndan gönderilmiþtir. Bu tür mesajlarý almak istemiyorsanýz lütfen týklayýnýz This message was sent to you by Telsim Mobile Telecommunications. To unsubscribe from this service, please click here To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: C conformance.
On 2003-02-09 19:13 +, Terry Lambert wrote: Marcin Dalecki wrote: Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. I think that somthing like to above should not appear in system headers. It is an ANSI compliant preprocessor directive. Please use an ANSI compliant compiler. Have you actually looked at the line? It's protected by #if __GNUC__, so your compiler shouldn't be trying to interpret any directives other than #else, #elif, or #endif (or the premature end of the file). This is a known problem with the overaggressive preprocessor. Things like this will get fixed as time permits, or new volunteers pop up :) -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: C conformance.
Terry Lambert wrote: Marcin Dalecki wrote: Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. I think that somthing like to above should not appear in system headers. It is an ANSI compliant preprocessor directive. Please use an ANSI compliant compiler. I'd also be curious to know in which version of the ANSI standard you have found #warning. I certainly doesn't appear in mine. -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: GCC 3.2.2 is coming
I plan to upgrade GCC to the version 3.2.2. Please hold your updates for a while. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sun, 9 Feb 2003, Bernd Walter wrote: I'm always compiling -current on alpha and i386 with -O2 since months. I havn't noticed any compiler related problems lately. How do you know? -- The last time France wanted more evidence, it rolled right through Paris with a German flag. - David Letterman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bus_setup_intr() vs. ether_ifattach() race
Which is the correct order to do these two functions? If the irq is enabled before the device is attached, it seems a response cannot be sent if a packet arrives before the attach. The right way seems to be to attach the device before setting up an irq but does this have side effects? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2.2 is coming
The import should be complete now. Please let us know if you see any problems introduced with this GCC version. On Sun, Feb 09, 2003 at 11:39:25PM -0500, Alexander Kabaev wrote: I plan to upgrade GCC to the version 3.2.2. Please hold your updates for a while. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RE : IPFilter
On Sun, 9 Feb 2003, Coercitas Temet'Nosce wrote: Pardon my poor knowledge about IPFW 2 but if I remember well, IPFW wasn't a SPI Firewall, which is what I need. Btw, previous Kernel allows us to fine tune its building for IPF and now, it simply gone...was really wondering where those features are. I think there is some confusion in this thread. Ipfilter is still part of -current, but the various kernel config options have been split into two files. /sys/conf/NOTES includes the various machine independent (MI) bits, including ipfilter. The NOTES file in /sys/i386/conf is restricted to things that are specific to the i386 platform, including pentium, amd, etc. We don't have a whole lot of ipfilter documentation in freebsd because ipfilter works the same way here as it does on other os'. See for example, http://www.obfuscation.org/ipf/ Hope this helps, Doug -- The last time France wanted more evidence, it rolled right through Paris with a German flag. - David Letterman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RE : IPFilter
On Sun, Feb 09, 2003 at 10:21:50PM -0800, Doug Barton wrote: We don't have a whole lot of ipfilter documentation in freebsd because ipfilter works the same way here as it does on other os'. See for example, http://www.obfuscation.org/ipf/ Hope this helps, Doug As a side note, is there any instruction on how to install the latest ipfilter on -current? Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sun, Feb 09, 2003 at 08:58:36PM -0800, Doug Barton wrote: On Sun, 9 Feb 2003, Bernd Walter wrote: I'm always compiling -current on alpha and i386 with -O2 since months. I havn't noticed any compiler related problems lately. How do you know? It's not that I don't know about things that I have noticed. Of course I don't know if there are unnoticed problems, but there will be much more than just compiler bugs. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bus_setup_intr() vs. ether_ifattach() race
Nate Lawson wrote: Which is the correct order to do these two functions? If the irq is enabled before the device is attached, it seems a response cannot be sent if a packet arrives before the attach. The right way seems to be to attach the device before setting up an irq but does this have side effects? The main side effect is that probes that require IRQs in order to determine if the device is there (e.g. AMD Lance, etc.) will never be able to probe true, unless the interrupt is routed to an IRQ handler. On the other hand, it should probably not be the standard IRQ handler that gets invoked, as a result of the probe, but one that is specific to probing. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RE : IPFilter
leafy wrote: On Sun, Feb 09, 2003 at 10:21:50PM -0800, Doug Barton wrote: We don't have a whole lot of ipfilter documentation in freebsd because ipfilter works the same way here as it does on other os'. See for example, http://www.obfuscation.org/ipf/ As a side note, is there any instruction on how to install the latest ipfilter on -current? Do you mean How do I get the latest FreeBSD supported version of ipfilter to run on FreeBSD-current?? If so, the answer is The version that's in the source tree is the latest ipfilter supported by FreeBSD-current. Do you mean How do I get the latest *vendor* supported version of ipfilter to run on FreeBSD-current?? If so, the answer is Replace the FreeBSD-current supplied source files with the vendor supplied source files, and recompile; if that doesn't work for you, contact the *vendor* for support of the vendor-supported code. You should probably contact the listed maintainer, if your question meant something other than one of those two. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: C conformance.
Munish Chopra wrote: It is an ANSI compliant preprocessor directive. Please use an ANSI compliant compiler. I'd also be curious to know in which version of the ANSI standard you have found #warning. I certainly doesn't appear in mine. I said that the use of the directive was compliant, not that the directive was standardized. As to the version of the standard, try ANSI X3J11, unless you have a different online version of the standards document available for public use that you want to point me at to language-lawyer to prove that the preprocessor should not be doing syntax checking on statements that are indicated by preprocessor statements to not be compiled. What does the compiler you are using do when I say: #ifdef absurd_token absurd_token #endif or #ifdef absurd_token #absurd_token #endif Neither one of these should cause a warning with an ANSI X3J11 compliant compiler or preprocessor, or an ISO C-99 compliant compiler or preprocessor, for that matter. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Grub 0.92 fails to recognise disks on FBSD5
Hi all, I'm fighting with the same problem and found that grub *does* recognize the disks if started with '--read-only'... That fits perfectly to the following paragraph found in the 5.0-RELEASE Errata: The geom(4)-based disk partitioning code in the kernel will not allow an open partition to be overwritten. This usually prevents the use of disklabel -B to update the boot blocks on a disk because the a partition overlaps the space where the boot blocks are stored. A suggested workaround is to boot from an alternate disk, a CDROM, or a fixit floppy. I can happily boot -current with grub - booting isn't the problem, installing it is the problem. And I installed grub from my 4.7-STABLE installation... (happy to have one :-) Grub seems to open disks/slices r/w and refuses to know them if that's not possible. I, personally, would say that's a bug of grub but that doesn't help here. It even doesn't help, if you run 5.0/-current on your base disk because you can't write the MBR anyway. My question to 'phk' is, if he (or anybody else) has or at least could imagine a solution for this problem. Nothing against 'booteasy', it does the job - but it looks ugly :-) And I can't imagine that the majority of FreeBSD-Users all have a bunch of disks in their systems - especially if I think of the giant sizes of HDs nowadays... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Grub 0.92 fails to recognise disks on FBSD5
On Sun, Feb 09, 2003 at 06:14:30PM +0100, Matthias Schuendehuette wrote: Nothing against 'booteasy', it does the job - but it looks ugly :-) If that is the only reason to use grub, try osbsbeta.exe that is in the tools directory of your CDROM or ftp.freebsd.org. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
