Re: -current buildworld breakage
On Sat, Oct 26, 2002 at 10:13:02PM +0900, Yamada Ken Takeshi wrote:
# cat rijndael/rijndael-api-fst.c
::::
switch (cipher-mode) {
case MODE_ECB:
for (i = numBlocks; i 0; i--) {
rijndaelEncrypt(input, outBuffer, key-keySched, key-RO
UNDS);
input += 16;
outBuffer += 16;
}
padLen = 16 - (inputOctets - 16*numBlocks);
if (padLen 0 padLen = 16)
panic(rijndael_padEncrypt(ECB));
^^
bcopy(input, block, 16 - padLen);
for (cp = block + 16 - padLen; cp block + 16; cp++)
*cp = padLen;
rijndaelEncrypt(block, outBuffer, key-keySched, key-ROUNDS);
break;
You don't have the latest sources. Did you use cvsup it
update your sources? If you used cvsup, then you
need to add src-sys-crypto to your cvsup file.
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Installworld fails building Current from 4.7-R
Hi, Did you see the instructions in /usr/src/Makefile and /usr/src/UPDATING? This is from /usr/src/Makefile: # For individuals wanting to upgrade their sources (even if only a # delta of a few days): # # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `mergemaster' # 9. `reboot' # # See src/UPDATING `COMMON ITEMS' for more complete information. # -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest fetch on current broken
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote: I noticed it when doing a portupgrade cdrtools So yes anything that uses fetch is not going to work OK, I started tracing this down. Here's how to get debugging versions: cd /usr/src/lib/libfetch make clean make DEBUG_FLAGS=-g make DEBUG_FLAGS=-g install cd /usr/src/usr.bin/fetch make clean make DEBUG_FLAGS=-g NOSHARED=yes make DEBUG_FLAGS=-g NOSHARED=yes install I traced down the broken pipe. It is happening somewhere in /usr/src/lib/libfetch/ftp.c in the _ftp_authenticate() function. I did an Ethereal capture of my ftp session, and here are the ftp protocol messages: 220 ftp.beastie.tdk.net FTP server (Version 6.00LS) ready. USER anonymous 331 Guest login ok, send your email address as password. 221 You could at least say goodbye. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest fetch on current broken
On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
I noticed it when doing a portupgrade cdrtools
So yes anything that uses fetch is not going to work
OK, I started tracing this down.
Here's how to get debugging versions:
cd /usr/src/lib/libfetch
make clean
make DEBUG_FLAGS=-g
make DEBUG_FLAGS=-g install
cd /usr/src/usr.bin/fetch
make clean
make DEBUG_FLAGS=-g NOSHARED=yes
make DEBUG_FLAGS=-g NOSHARED=yes install
I tracked this down further to the _fetch_writev() function
in libfetch/common.c. Try this patch:
--- lib/libfetch/common.c.orig Sun Oct 27 22:38:16 2002
+++ lib/libfetch/common.c Sun Oct 27 22:40:12 2002
@@ -525,7 +525,7 @@
return (-1);
}
total += wlen;
- while (iovcnt 0 wlen iov-iov_len) {
+ while (iovcnt 0 wlen = iov-iov_len) {
wlen -= iov-iov_len;
iov++;
iovcnt--;
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Objective-C threads
Hi, I don't think many people in the FreeBSD community use Objective-C, hence the apparent lack of a maintainer. The proper way to submit patches to the [EMAIL PROTECTED] mailing list at the FSF GCC project is to follow the procedures documented at: http://gcc.gnu.org/contribute.html If you are used to how patches are submitted in FreeBSD, it's no big deal. In the source code for gcc, you will see a file called MAINTAINERS. The MAINTAINERS file lists a few names under Objective-C: objective-c Stan Shebs [EMAIL PROTECTED] objective-c Ovidiu Predescu [EMAIL PROTECTED] The most active maintenance of objective-c is going on at Apple, because of all the old NeXT stuff that they have in MacOS X. Keeping in touch with the darwin-development mailing list at Apple would probably not be a bad idea, since a lot of the Apple compiler developers read that list. http://lists.apple.com/mailman/listinfo/darwin-development -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GENERIC bórken...
On Thu, Oct 31, 2002 at 01:21:38PM +0100, Poul-Henning Kamp wrote: ffreestanding -Werror /usr/src/sys/dev/amr/amr.c cc1: warnings being treated as errors /usr/src/sys/dev/amr/amr.c: In function `amr_setup_ccbmap': /usr/src/sys/dev/amr/amr.c:1055: warning: initialization from incompatible point er type *** Error code 1 It's a good practice to compile things before checking them in. --- amr.c.orig Thu Oct 31 18:19:32 2002 +++ amr.c Thu Oct 31 18:19:59 2002 @@ -1052,7 +1052,7 @@ struct amr_softc*sc = ac-ac_sc; struct amr_sgentry *sg; struct amr_passthrough *ap = (struct amr_passthrough *)ac-ac_data; -struct amr_ext_passthrough *aep = (struct amr_passthrough *)ac-ac_data; +struct amr_ext_passthrough *aep = (struct amr_ext_passthrough *)ac-ac_data; int i; /* get base address of s/g table */ -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cannot find my Linux partition
Hi, I have in my kernel config: options EXT2FS On -STABLE, and on -CURRENT from a week ago, one my SCSI drives looked like this: = /dev/da1s1 standard input: x86 boot sector /dev/da1s2 standard input: x86 boot sector, extended partition table /dev/da1s3 standard input: empty /dev/da1s4 standard input: empty /dev/da1s5 standard input: x86 boot sector /dev/da1s6 standard input: Linux rev 0.0 ext2 filesystem data /dev/da1s7 standard input: x86 boot sector = I used to be able to mount my Linux partition with: mount -r -t ext2fs /dev/da1s7 /linuxmount I just cvsup'd and rebuilt kernel/world on -CURRENT today, and now the same SCSI disk looks like: = for i in $(/bin/ls -1 /dev/da1*); do printf $i $(file - $i)\n; done /dev/da1 standard input: x86 boot sector /dev/da1s1 standard input: x86 boot sector /dev/da1s2 standard input: x86 boot sector, extended partition table /dev/da1s5 standard input: x86 boot sector = da1s7 is no longer there, and I can't figure out how to mount my Linux partition. None of the combinations of: mount -r -t ext2fs /dev/da1s[125] /linuxmount works. Any help appreciated. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cannot find my Linux partition
On Thu, Oct 31, 2002 at 04:56:49PM +0100, Poul-Henning Kamp wrote: Can you please email me: boot -v console output (use serial console if you can) sysctl -n kern.geom.confxml Thanks in advance! I am not physically at the machine in question right now, and am leaving in a few hours for a week of vacation (out of FreeBSD range :). I am attaching the kern.geom.confxml and dmesg.boot. I will try to get the boot -v output, if I have time, otherwise it will have to wait. :( -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] kern.geom.confxml.gz Description: application/gunzip dmesg.boot.gz Description: application/gunzip
Question about boot(8) man page
Hi, I just read the boot(8) man page on my system. Is the FILES section still correct for -CURRENT? FILES /boot.config parameters for the boot blocks (optional) /boot/boot1 first stage bootstrap file /boot/boot2 second stage bootstrap file /boot/loader third stage bootstrap /kernel default kernel /kernel.old typical non-default kernel (optional) On my system, the default kernel is /boot/kernel/kernel and the old kernel is /boot/kernel.old/kernel . -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cannot find my Linux partition
On Thu, Oct 31, 2002 at 04:56:49PM +0100, Poul-Henning Kamp wrote: Can you please email me: boot -v console output (use serial console if you can) sysctl -n kern.geom.confxml OK, I edited /boot/default/loader.conf, and added set boot_verbose=YES and rebooted. (I'm still not at the machine physically :). dmesg.boot has more stuff now, hopefully it helps. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] dmesg.boot.2.gz Description: application/gunzip
Re: Cannot find my Linux partition
On Thu, Oct 31, 2002 at 06:33:13PM +0100, Poul-Henning Kamp wrote: Please try this patch: Hi, I tried your patch. This is what I get now: = for i in `/bin/ls /dev/da1*`; do printf $i $(file - $i)\n; done /dev/da1 standard input: x86 boot sector /dev/da1s1 standard input: x86 boot sector /dev/da1s2 standard input: x86 boot sector, extended partition table /dev/da1s5 standard input: x86 boot sector /dev/da1s6 standard input: Linux rev 0.0 ext2 filesystem data /dev/da1s7 standard input: x86 boot sector /dev/da1s8 standard input: Linux/i386 swap file = I am also attaching the dmesg.boot file. I can now mount my Linux partition with: mount -r -t ext2fs /dev/da1s7 /linuxmount You rule, man! Now I can go on vacation. :) -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] dmesg.boot.3.gz Description: application/gunzip
Clock runs too fast
Hi, I have a problem with my ASUS P5A-B motherboard, where the timer runs too fast. This is with -CURRENT, cvsup'd from 1.5 weeks ago. I encountered this problem before, and found a fix which worke;: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=145760+0+archive/2002/freebsd-current/20020915.freebsd-current However, this fix (adding kern.timecounter.hardware=i8254 to /etc/sysctl.conf) does not seem to work anymore. The clock still runs too fast. Here are my sysctl values for kern.timecounter kern.timecounter.nbinuptime: 450054 kern.timecounter.nnanouptime: 3 kern.timecounter.nmicrouptime: 0 kern.timecounter.nbintime: 21313 kern.timecounter.nnanotime: 15 kern.timecounter.nmicrotime: 21298 kern.timecounter.ngetbinuptime: 0 kern.timecounter.ngetnanouptime: 95 kern.timecounter.ngetmicrouptime: 60405 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetnanotime: 0 kern.timecounter.ngetmicrotime: 142134 kern.timecounter.hardware: i8254 kern.timecounter.tick: 1 Any ideas? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock runs too fast
On Tue, Nov 12, 2002 at 05:18:13PM +0100, Poul-Henning Kamp wrote: Are you saying that the i8254 also runs twice as fast as it should ? It looks like it. Here is some additional output from dmesg. Does it give a clue? Calibrating clock(s) ... TSC clock: 400911902 Hz, i8254 clock: 1193190 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method [snip] ACPI timer looks BAD min = 0, max = 5, width = 6 ACPI timer looks BAD min = 0, max = 16777210, width = 16777211 ACPI timer looks BAD min = 1, max = 16777215, width = 16777215 ACPI timer looks BAD min = 2, max = 16777204, width = 16777203 ACPI timer looks BAD min = 0, max = 16777215, width = 16777216 ACPI timer looks BAD min = 0, max = 16777215, width = 16777216 ACPI timer looks BAD min = 2, max = 16777210, width = 16777209 ACPI timer looks BAD min = 2, max = 16777208, width = 16777207 ACPI timer looks BAD min = 0, max = 16777208, width = 16777209 ACPI timer looks BAD min = 2, max = 16777215, width = 16777214 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xec08-0xec0b on acpi0 acpi_cpu0: CPU on acpi0 [snip] Timecounters tick every 10.000 msec -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock runs too fast
On Tue, Nov 12, 2002 at 05:44:36PM +, David Malone wrote: On Tue, Nov 12, 2002 at 10:20:00AM -0500, Craig Rodrigues wrote: However, this fix (adding kern.timecounter.hardware=i8254 to /etc/sysctl.conf) does not seem to work anymore. The clock still runs too fast. Could you try kern.timecounter.hardware=TSC - this worked for someone else sometime last week. If the TSC works and the i8254 doesn't it may give phk some better idea about what is going on. I just tried this, and it seems to work fine. So TSC seems to work, and i8254 does not seem to work. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clock runs too fast
On Tue, Nov 12, 2002 at 07:23:51PM +0100, Poul-Henning Kamp wrote: I just tried this, and it seems to work fine. So TSC seems to work, and i8254 does not seem to work. And ACPI doesn't work either, right ? That's right, doing: sysctl -w kern.timecounter.hardware=ACPI-safe does not work either, ie. clock is too fast. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: blimitd fixes (was: ports broken by KSE changes)
Hi, Could you use diff -urN and send-pr to send an update to the port as outlined in the Porters Handbook? http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/port-upgrading.html Note: This only applies to -current. blimitd users: http://www.unixdaemons.com/~hiten/work/ports/blimitd-patches -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Question about POSIX AIO
Hi,
I am running a -CURRENT system.
I had some code that was calling aio_suspend(), and
was setting errno to EINVAL. From the man page for aio_suspend:
[EINVAL] iocbs contains more than AIO_LISTIO_MAX asynchronous
I/O requests, or at least one of the requests is not
valid.
I reduced my list of I/O requests to AIO_LISTIO_MAX -1, and I did not
got EINVAL any more.
My question is, why are the following values different?
The following program:
#include aio.h
#include unistd.h
#include stdio.h
int
main(int argc, char *argv)
{
printf(%d\n, AIO_LISTIO_MAX);
printf(%d\n, sysconf(_SC_AIO_LISTIO_MAX));
}
will print:
16
-1
sysctl -a | grep aio will return:
vfs.aio.max_aio_procs: 32
vfs.aio.num_aio_procs: 4
vfs.aio.target_aio_procs: 4
vfs.aio.max_aio_queue: 1024
vfs.aio.num_queue_count: 0
vfs.aio.num_buf_aio: 0
vfs.aio.aiod_timeout: 1000
vfs.aio.aiod_lifetime: 3000
vfs.aio.unloadable: 0
vfs.aio.max_aio_per_proc: 32
vfs.aio.max_aio_queue_per_proc: 256
vfs.aio.max_buf_aio: 16
p1003_1b.aio_listio_max: 0
p1003_1b.aio_max: 0
p1003_1b.aio_prio_delta_max: 0
How can I get sysconf(_SC_AIO_LISTIO_MAX) to return something sensible,
ie. where would I need to look in order to patch the system?
Thanks.
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bad ACPI
On Sat, Nov 16, 2002 at 05:44:01PM +0100, Anders Andersson wrote:
On Sat, Nov 16, 2002 at 11:35:49AM -0500, Craig Rodrigues wrote:
Could you try the following?
At the boot prompt, before the kernel boots up:
unset acpi_load
set boot_verbose=YES
boot -v
OK, now I feel stupid since I could swear that I already did try to
disable ACPI.
But with ACPI disabled it boots fine.
phk, sorry to confuse you :-)
I had a very similar problem. I had a system here which would crash upon
bootup when acpi was loaded. Since I couldn't boot into the system to
read the man pages, I didn't know what to do.
At the boot prompt, I typed show. It clearly listed:
acpi_load=YES
I then typed:
set acpi_load=NO
boot
Of course, the system still tried to load acpi, and crashed.
The correct thing to do would have been to read loader(8), and deduce
that it would be necessary to unset acpi_load in order to not load
acpi. This tripped me up, and might trip other new users who try 5.0.
Would a patch of this sort be something to consider?
--- sys/boot/i386/libi386/i386_module.c.origSat Nov 16 15:01:07 2002
+++ sys/boot/i386/libi386/i386_module.c Sat Nov 16 15:20:04 2002
@@ -57,7 +57,8 @@
disabled = 1;
}
-if (getenv(acpi_load) (!disabled)) {
+rv = getenv(acpi_load);
+if (rv != NULL (!disabled) (strcasecmp(rv,NO) != 0)) {
error = mod_load(acpi, NULL, 0, NULL);
if (error != 0)
printf(ACPI autoload failed - %s\n, strerror(error));
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Debugging kernel panic, routetbl
Hi,
Can someone give me some ideas for how to debug a kernel
panic and isolate where the problem could be?
I've been trying out the Netgraph ATM stuff for a while,
and things have been working fine for a number of weeks.
However, when I cvsup'd -CURRENT from a few days ago,
I have one of my machines crashing after
route add is called on my ATM card.
The crash I am getting is soon after the ATM card is initialized
with ifconfig, and route add is called. This did not happen before,
and the ATM driver source that I am using has worked fine for weeks.
ddb gives me this message:
Memory modified after free 0x1383600(252)
panic: Most recently used by routetbl
And gdb over a serial port gives me this:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you ar=
e
welcome to change it and/or distribute copies of it under certain condition=
s.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.=
This GDB was configured as i386-undermydesk-freebsd...
(kgdb) target /dev remote /dev/cuaa0
Remote debugging using /dev/cuaa0
Debugger (msg0x12 Address 0x12 out of bounds)
at /usr/src/sys/i386/i386/db_interface.c:323
323 }
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint
(kgdb) where
#0 Debugger (msg0x12 Address 0x12 out of bounds)
at /usr/src/sys/i386/i386/db_interface.c:323
#1 0xc031892b in panic (fmt0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:503
#2 0xc035b4b7 in bremfree (bp0xc2426868) at /usr/src/sys/kern/vfs_bio.c=
:632
#3 0xc035deb0 in getblk (vp0xc1368000, blkno196864, size16384, sl=
pflag0,
slptimeo0) at /usr/src/sys/kern/vfs_bio.c:2344
#4 0xc035b5ea in breadn (vp0xc1368000, blkno137438953490, size18,=
rablkno0x0, rabsize0x0, cnt0, cred0x0, bpp0x12)
at /usr/src/sys/kern/vfs_bio.c:690
#5 0xc035b59c in bread (vp0x12, blkno137438953490, size18, cred=
0x12,
bpp0x12) at /usr/src/sys/kern/vfs_bio.c:672
#6 0xc043a256 in ffs_update (vp0xc1367000, waitfor0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:102
#7 0xc044dc5f in ffs_fsync (ap0xc5bbdb10)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:315
#8 0xc044cece in ffs_sync (mp0xc135e000, waitfor2, cred0xc09f6e00=
,
td0xc0577100) at vnode_if.h:612
#9 0xc036f308 in sync (td0xc0577100, uap0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#10 0xc031830c in boot (howto256) at /usr/src/sys/kern/kern_shutdown.c:2=
73
#11 0xc0318943 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#12 0xc04738bd in mtrash_ctor (mem0xc13e2d00, size32, arg0x0)
at /usr/src/sys/vm/uma_dbg.c:138
#13 0xc04722d7 in uma_zalloc_arg (zone0xc09d0140, udata0x0, flags0=
)
at /usr/src/sys/vm/uma_core.c:1358
#14 0xc030d0c6 in malloc (size4, type0xc05783e0, flags0)
at /usr/src/sys/kern/kern_malloc.c:182
#15 0xc02fbd35 in fdcopy (td0x12) at /usr/src/sys/kern/kern_descrip.c:12=
65
#16 0xc0304140 in fork1 (td0xc0a0c540, flags20, pages0, procp0x=
c5bbdcd4)
at /usr/src/sys/kern/kern_fork.c:446
#17 0xc0303872 in fork (td0xc0a0c540, uap0xc5bbdd10)
at /usr/src/sys/kern/kern_fork.c:122
#18 0xc04a763e in syscall (frame
{tf_fs 47, tf_es 47, tf_ds 47, tf_edi 0, tf_esi 1=
35254016, tf_ebp -1077937816, tf_isp -977543820, tf_ebx 0, tf_e=
dx 672047128, tf_ecx 3, tf_eax 2, tf_trapno 12, tf_err =
2, tf_eip 134723747, tf_cs 31, tf_eflags 514, tf_esp -10779=
37860, tf_ss 47})
at /usr/src/sys/i386/i386/trap.c:1033
#19 0xc049704d in Xint0x80_syscall () at {standard input}:140
#20 0x0804b326 in ?? ()
#21 0x0804ae8f in ?? ()
#22 0x0804aed7 in ?? ()
#23 0x0804aed7 in ?? ()
#24 0x0804b2a1 in ?? ()
#25 0x0804aeff in ?? ()
#26 0x0804aed7 in ?? ()
#27 0x0804bf6e in ?? ()
#28 0x0804af71 in ?? ()
#29 0x0804add9 in ?? ()
#30 0x0804b18d in ?? ()
#31 0x0804aef1 in ?? ()
#32 0x0804aed7 in ?? ()
#33 0x0804add9 in ?? ()
#34 0x0804add9 in ?? ()
#35 0x0804add9 in ?? ()
#36 0x0804b2a1 in ?? ()
#37 0x0804aeff in ?? ()
#38 0x08053767 in ?? ()
#39 0x0805364b in ?? ()
#40 0x0804814c in ?? ()
(kgdb) detach
Ending remote debugging.
(kgdb) quit
Script done on Wed Nov 20 04:13:05 2002
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Kernel panic: vfs_alloc()
Hi,
One of my FreeBSD-current test machines panicked upon
bootup. The message which appeared before the panic was:
imode = 041777, inum = 61, fs = /var
panic: ffs_valloc: dup alloc
I am attaching the ddb trace, the gdb trace,
and some Fault trap 12 messages that appeared in the console.
Any ideas?
Thanks.
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
imode = 041777, inum = 61, fs = /var
panic: ffs_valloc: dup alloc
panic()
ffs_valloc()
ufs_makeinode()
ufs_create()
ufs_vnoperate()
vn_open_cred()
vn_open()
kern_open()
open()
syscall()
Xint0x80_syscall()
#0 Debugger (msg=0x12 Address 0x12 out of bounds)
at /usr/src/sys/i386/i386/db_interface.c:323
#1 0xc0318afb in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:503
#2 0xc0434225 in ffs_valloc (pvp=0xc13b9378, mode=33188, cred=0xc0a09180,
vpp=0xc6028894) at /usr/src/sys/ufs/ffs/ffs_alloc.c:871
#3 0xc045a789 in ufs_makeinode (mode=33188, dvp=0xc13b9378, vpp=0xc6028bec,
cnp=0xc6028c00) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2356
#4 0xc0457489 in ufs_create (ap=0xc6028a2c)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:197
#5 0xc045ac88 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2796
#6 0xc037691f in vn_open_cred (ndp=0xc6028bd8, flagp=0xc6028cd8, cmode=420,
cred=0xc0a09180) at vnode_if.h:114
#7 0xc0376779 in vn_open (ndp=0x12, flagp=0x12, cmode=18)
at /usr/src/sys/kern/vfs_vnops.c:91
#8 0xc0370223 in kern_open (td=0xc1201ee0,
path=0x12 Address 0x12 out of bounds, pathseg=18, flags=1538, mode=438)
at /usr/src/sys/kern/vfs_sscalls.c:664
#9 0xc0370090 in open (td=0x12, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:627
#10 0xc04a786e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135291256, tf_esi = 1, tf_eb
p = -1077938600, tf_isp = -972911244, tf_ebx = 135291160, tf_edx = -1077938560,
#11 0xc049727d in Xint0x80_syscall () at {standard input}:140
#12 0x080582af in ?? ()
#13 0x0804c08d in ?? ()
#14 0x0804af71 in ?? ()
#15 0x0804aed7 in ?? ()
#16 0x0804aed7 in ?? ()
#17 0x08053767 in ?? ()
#18 0x080539e9 in ?? ()
#19 0x0804c12b in ?? ()
#20 0x0804af71 in ?? ()
#21 0x0804aed7 in ?? ()
#22 0x0804b358 in ?? ()
#23 0x0804ae8f in ?? ()
#24 0x0804aed7 in ?? ()
#25 0x0804aed7 in ?? ()
#26 0x0804b2a1 in ?? ()
#27 0x0804aeff in ?? ()
#28 0x0804aed7 in ?? ()
#29 0x0804bf6e in ?? ()
#30 0x0804af71 in ?? ()
#31 0x0804add9 in ?? ()
#32 0x0804b18d in ?? ()
#33 0x0804aef1 in ?? ()
#34 0x0804aed7 in ?? ()
#35 0x0804add9 in ?? ()
#36 0x0804add9 in ?? ()
#37 0x0804add9 in ?? ()
#38 0x0804b2a1 in ?? ()
#39 0x0804aeff in ?? ()
#40 0x08053767 in ?? ()
#41 0x0805364b in ?? ()
#42 0x0804814c in ?? ()
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x12
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc0495b50
stack pointer = 0x10:0xc6028698
frame pointer = 0x10:0xc602869c
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 142 (sh)
Re: installworld of 5.0 broken on 4.x?
On Sat, Nov 30, 2002 at 02:35:32PM -0800, Kris Kennaway wrote: I get this when building 5.0 under 4.x, for the purposes of installing into a temporary directory. Any ideas? Kris === etc/sendmail rm -f freefall.cf (cd /local0/src-5.x/etc/sendmail m4 -D_CF_DIR_=/local0/src-5.x/etc/sendmail/../../contrib/sendmail/cf/ /local0/src-5.x/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 freefall.mc) freefall.cf m4: not found *** Error code 127 Is this related? http://www.freebsd.org/cgi/getmsg.cgi?fetch=30158+0+/usr/local/www/db/text/2002/freebsd-current/20020915.freebsd-current -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: C++ Issue On -CURRENT
On Sat, Nov 30, 2002 at 03:48:00PM -0800, Cy Schubert - CITS Open Systems Group wrote:
I've been working on getting the tripwire port to build on -CURRENT.
Through this process I've stumbled across an issue. Searching through
the mailing lists, I haven't found a solution to this.
The following program builds and runs under 4.7-STABLE:
#include iostream
int main()
{
coutHello World\n;
}
Should be:
std::coutHello World\n;
Pick up a good C++ book like Stroustrup's C++ Programming Language
( http://www.research.att.com/~bs/3rd.html ), and learn about
the std namespace.
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Posix Semaphores in -CURRENT
On Fri, Dec 13, 2002 at 08:41:16AM -0800, Joe Kelsey wrote: portabliity issue as TRU64 (at least) allows arbitrary pathnames as sempahores, probably storing some sort of marker in the directories (I get this only from examining the TRU64 online manual pages at http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/HTML/APS33DTE_html/DOCU_010.HTM If you are going to argue about what FreeBSD should do, then in addition to checking with the TRU64 manual (TRU64 is probably in its sunset stage: http://news.com.com/2100-1001-976211.html), you should also refer to the POSIX standard: http://www.opengroup.org/onlinepubs/007904975/ For the man page for sem_open(), there is this: sem_t *sem_open(const char *name, int oflag, ...); The name argument points to a string naming a semaphore object. It is unspecified whether the name appears in the file system and is visible to functions that take pathnames as arguments. The name argument conforms to the construction rules for a pathname. If name begins with the slash character, then processes calling sem_open() with the same value of name shall refer to the same semaphore object, as long as that name has not been removed. If name does not begin with the slash character, the effect is implementation-defined. The interpretation of slash characters other than the leading slash character in name is implementation-defined. So apart from the leading slash character, nothing is mentioned about embedded slashes in the semaphore name. What's the right behavior for FreeBSD then? -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM panic
Hi, I just did a cvsup and rebuilt my kernel, and now my kernel panics upon bootup. I don't have a serial console, so I wrote down the error messages that I saw: I saw this one in the middle of some GEOM debug statements: ar: FreeBSD check1 failed Further along I saw: Lock GEOM topology not exclusively locked @ /usr/src/sys/geom/geom_slice.c:303 Lock GEOM topology not exclusively locked @ /usr/src/sys/geom/geom_subr.c:176 Lock GEOM topology not exclusively locked @ /usr/src/sys/geom/geom_event.c:279 GEOM: configure da0s5, start 31744 length 63107072 end 6318815 Lock GEOM topology not exclusively locked @ /usr/src/sys/geom/geom_mbr.c:405 panic: Assertion sx-sx_cnt == -1 failed at /usr/src/sys/kern/kern_sx.c:242 A stacktrace in ddb shows: panic() _sx_unlock() gc_mbrext_taste g_do_event() one_event() g_run_events() g_event_procbody() fork_exit() fork_trampoline() The versions of some of the GEOM files in question: $FreeBSD: src/sys/geom/geom_slice.c,v 1.32 2002/12/17 21:31:58 phk Exp $ $FreeBSD: src/sys/geom/geom_subr.c,v 1.24 2002/12/16 22:33:27 phk Exp $ $FreeBSD: src/sys/geom/geom_event.c,v 1.15 2002/11/04 09:31:02 phk Exp $ $FreeBSD: src/sys/geom/geom_mbr.c,v 1.28 2002/12/17 09:44:10 phk Exp $ -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM panic
On Thu, Dec 19, 2002 at 07:22:45AM +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Craig Rodrigues writes: Hi, I just did a cvsup and rebuilt my kernel, and now my kernel panics upon bootup. I don't have a serial console, so I wrote down the error messages that I saw: I saw this one in the middle of some GEOM debug statements: ar: FreeBSD check1 failed Can you try this patch please ? That patch worked, and I no longer get a kernel panic. Do you know what the ar: FreeBSD check1 failed error message is caused by? I am attaching the GEOM dmesg messages. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] ad0: success setting PIO4 on Acer chip GEOM: new disk ad0 ar: FreeBSD check1 failed ad0: IC35L060AVER07-0/ER6OA44A ATA-5 disk at ata0-master ad0: 32253MB (66055248 sectors), 65531 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, PIO4 ad0: piomode=4 dmamode=2 udmamode=5 cblid=1 Waiting 15 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. sym0: enabling clock multiplier sym0: Downloading SCSI SCRIPTS. GEOM: Configure ad0s1, start 32256 length 7339885056 end 7339917311 GEOM: Configure ad0s2, start 7339917312 length 6291210240 end 13631127551 GEOM: Add ad0s1 hot[0] start 512 length 276 end 787 GEOM: Configure ad0s1a, start 0 length 209715200 end 209715199 GEOM: Configure ad0s1b, start 209715200 length 524288000 end 734003199 GEOM: Configure ad0s1c, start 0 length 7339885056 end 7339885055 GEOM: Configure ad0s1e, start 734003200 length 52428800 end 786431999 GEOM: Configure ad0s1f, start 786432000 length 6553453056 end 7339885055 GEOM: Add ad0s2 hot[0] start 512 length 276 end 787 GEOM: Configure ad0s2a, start 0 length 134217728 end 134217727 GEOM: Configure ad0s2c, start 0 length 6291210240 end 6291210239 GEOM: Configure ad0s2e, start 134217728 length 268435456 end 402653183 GEOM: Configure ad0s2f, start 402653184 length 268435456 end 671088639 GEOM: Configure ad0s2g, start 671088640 length 5620121600 end 6291210239 (probe5:sym0:0:5:0): error 22 (probe5:sym0:0:5:0): Unretryable Error (probe0:sym0:0:0:0): Retrying Command (probe1:sym0:0:1:0): Retrying Command (probe2:sym0:0:2:0): Retrying Command pass0 at sym0 bus 0 target 0 lun 0 pass0: SEAGATE ST5660N 0592 Fixed Direct Access SCSI-2 device pass0: Serial Number DP651202 pass0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass1 at sym0 bus 0 target 1 lun 0 pass1: IBM DORS-32160 WA0A Fixed Direct Access SCSI-2 device pass1: Serial Number 5U2V3566 pass1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass2 at sym0 bus 0 target 2 lun 0 pass2: IBM DDRS-34560D DC1B Fixed Direct Access SCSI-2 device pass2: Serial Number QD740138 pass2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled pass3 at sym0 bus 0 target 5 lun 0 pass3: SONY CD-ROM CDU-76S 1.1c Removable CD-ROM SCSI-2 device pass3: 5.681MB/s transfers (5.681MHz, offset 15) GEOM: new disk da0 da0 at sym0 bus 0 target 0 lun 0 da0: SEAGATE ST5660N 0592 Fixed Direct Access SCSI-2 device da0: Serial Number DP651202 da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 520MB (1065664 512 byte sectors: 64H 32S/T 520C) GEOM: new disk da1 GEOM: new disk da2 (cd0:sym0:0:5:0): Retrying Command cd0 at sym0 bus 0 target 5 lun 0 cd0: SONY CD-ROM CDU-76S 1.1c Removable CD-ROM SCSI-2 device cd0: 5.681MB/s transfers (5.681MHz, offset 15) cd0: cd present [273047 x 2048 byte records] GEOM: Configure da0s1, start 31744 length 1047552 end 1079295 GEOM: Configure da0s2, start 1079296 length 21046272 end 22125567 GEOM: Configure da0s3, start 22125568 length 523458560 end 545584127 da1 at sym0 bus 0 target 1 lun 0 da1: IBM DORS-32160 WA0A Fixed Direct Access SCSI-2 device da1: Serial Number 5U2V3566 da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da2 at sym0 bus 0 target 2 lun 0 da2: IBM DDRS-34560D DC1B Fixed Direct Access SCSI-2 device da2: Serial Number QD740138 da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) GEOM: Configure da1s1, start 31744 length 2095104 end 2126847 GEOM: Configure da1s2, start 2126848 length 2160877568 end 2163004415 GEOM: Configure da2s1, start 31744 length 4565390336 end 4565422079 MBREXT Slice 5 on da0s3: 80 01 01 29 06 10 3e 9d 3e 00 00 00 78 e1 01 00 |...)..x...| [0] f:80 typ:6 s(CHS):41/1/1 e(CHS):157/16/62 s:62 l:123256 00 00 01 9e 05 10 fe f2 b6 e1 01 00 f6 b7 0d 00 || [1] f:00 typ:5 s(CHS):158/0/1 e(CHS):242/16/254 s:123318 l:899062 GEOM: Configure da0s5, start 31744 length 63107072 end 63138815 MBREXT Slice 6 on da0s3: 00 01 01 9e 07 10 fe f2 3e 00 00 00 b8 b7 0d 00 |...| [0] f:00 typ:7 s(CHS):158/1/1 e(CHS):242/16/254 s:62 l:899000 00 00 00 00
Cannot open /dev/ad0 on -CURRENT
Hi,
I debugged some more, trying to figure out why I could not
add a new partition to my disk using /usr/sbin/sysinstall
on -CURRENT.
I tracked the problem down to these lines in libdisk's write_i386_disk.c:
98 strcpy(device, _PATH_DEV);
99 strcat(device, d1-name);
100
101 fd = open(device, O_RDWR);
102 if (fd 0)
103 return 1;
According to the debugger, device == /dev/ad0
I wrote the attached program to open /dev/ad0.
It consistently fails with:
fd: -1
Error: : Operation not permitted
If I change the program to open one of my SCSI disks, /dev/da0, it
does not fail:
fd: 3
Any ideas what the problem could be?
Thanks.
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
#include unistd.h
#include stdio.h
#include stdlib.h
#include fcntl.h
int
main(int argc, char *argv[])
{
int fd;
fd = open(/dev/da0, O_RDWR);
printf(fd: %d\n, fd);
if(fd 0 ) {
perror(Error: );
}
else {
close(fd);
}
return 0;
}
Re: Cannot open /dev/ad0 on -CURRENT
On Tue, Dec 24, 2002 at 12:34:15PM -0700, Geoffrey T. Falk wrote: On 24 Dec, Craig Rodrigues wrote: I wrote the attached program to open /dev/ad0. It consistently fails with: fd: -1 Error: : Operation not permitted At what securelevel are you running? % sysctl -n kern.securelevel kern.securelevel: -1 Well, this wouldn't explain why I could open /dev/da0 but not /dev/ad0. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cannot open /dev/ad0 on -CURRENT
On Wed, Dec 25, 2002 at 05:37:46AM -0800, Kris Kennaway wrote: On Tue, Dec 24, 2002 at 01:31:10PM -0500, Craig Rodrigues wrote: Any ideas what the problem could be? geom seems to have anti-foot-shooting measures in place to disallow access to the disk device when a partition on that disk is open. Are you referring to this in src/sys/geom/geom_bsd.c? 547 /* 548 * If the user tries to overwrite our disklabel through an open partition 549 * or via a magicwrite config call, we end up here and try to prevent 550 * footshooting as best we can. 551 */ 552 static void 553 g_bsd_hotwrite(void *arg) The result of this is that I booted off of a slice contained on the /dev/ad0 disk, then I cannot add new partitions to /dev/ad0 with sysinstall, even if I am root. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pthread.h: improved _POSIX_THREAD_PROCESS_SHARED check
Hi, I was looking at pthread.h and thought that this patch should be applied since _POSIX_THREAD_PROCESS_SHARED is defined as -1 in unistd.h. Is it OK? -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] Index: pthread.h === RCS file: /home/ncvs/src/include/pthread.h,v retrieving revision 1.25 diff -u -r1.25 pthread.h --- pthread.h 2002/03/23 17:24:53 1.25 +++ pthread.h 2002/12/25 21:47:43 @@ -204,7 +204,7 @@ intpthread_condattr_destroy(pthread_condattr_t *); intpthread_condattr_init(pthread_condattr_t *); -#if defined(_POSIX_THREAD_PROCESS_SHARED) +#if defined(_POSIX_THREAD_PROCESS_SHARED) _POSIX_THREAD_PROCESS_SHARED != -1 intpthread_condattr_getpshared(pthread_condattr_t *, int *); intpthread_condattr_setpshared(pthread_condattr_t *, int); #endif
Re: Cannot open /dev/ad0 on -CURRENT
On Wed, Dec 25, 2002 at 10:12:12PM +0100, [EMAIL PROTECTED] wrote: The result of this is that I booted off of a slice contained on the /dev/ad0 disk, then I cannot add new partitions to /dev/ad0 with sysinstall, even if I am root. Correct. Use disklabel -e ad0s1 What should I do if I want to add a new slice to /dev/ad0? I did not fully partition the disk when I installed FreeBSD on it, and there is lots of free space left on that disk. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread.h: improved _POSIX_THREAD_PROCESS_SHARED check
On Wed, Dec 25, 2002 at 04:50:44PM -0500, Craig Rodrigues wrote: Hi, I was looking at pthread.h and thought that this patch should be applied since _POSIX_THREAD_PROCESS_SHARED is defined as -1 in unistd.h. Is it OK? I missed one macro, here is an updated patch. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] Index: pthread.h === RCS file: /home/ncvs/src/include/pthread.h,v retrieving revision 1.25 diff -u -r1.25 pthread.h --- pthread.h 2002/03/23 17:24:53 1.25 +++ pthread.h 2002/12/25 22:13:06 @@ -204,7 +204,7 @@ intpthread_condattr_destroy(pthread_condattr_t *); intpthread_condattr_init(pthread_condattr_t *); -#if defined(_POSIX_THREAD_PROCESS_SHARED) +#if defined(_POSIX_THREAD_PROCESS_SHARED) _POSIX_THREAD_PROCESS_SHARED != -1 intpthread_condattr_getpshared(pthread_condattr_t *, int *); intpthread_condattr_setpshared(pthread_condattr_t *, int); #endif @@ -265,7 +265,7 @@ intpthread_setprio(pthread_t, int); void pthread_yield(void); -#if defined(_POSIX_THREAD_PROCESS_SHARED) +#if defined(_POSIX_THREAD_PROCESS_SHARED) _POSIX_THREAD_PROCESS_SHARED != -1 intpthread_mutexattr_getpshared(pthread_mutexattr_t *, int *pshared); intpthread_mutexattr_setpshared(pthread_mutexattr_t *,
Re: recent GENERIC kernel
On Thu, Dec 26, 2002 at 10:00:23PM +0200, D. Penev wrote: It's very stupid but anyway... Are anybody know from where I can download most recent GENERIC kernel(i386) for -current? I didn't know about ufs2 changes and now as a result I can't mount ufs2 fi- lesystems. http://current.freebsd.org -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
uthread_info.c typos patch
Hi,
There are a few typos in the comments for uthread_info.c
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
Index: uthread_info.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_info.c,v
retrieving revision 1.23
diff -u -r1.23 uthread_info.c
--- uthread_info.c 2002/10/20 22:49:06 1.23
+++ uthread_info.c 2002/12/27 17:11:11
@@ -103,9 +103,9 @@
continue;
/*
* We only need to continue in case of
-* EEXIT error. Most other error
+* EEXIST error. Most other error
* codes means that we will fail all
-* the times.
+* the time.
*/
return;
} else {
Re: sparc64 tinderbox failure
On Sun, Dec 29, 2002 at 09:17:05PM -0800, David Schultz wrote:
Thus spake Kris Kennaway [EMAIL PROTECTED]:
On Mon, Dec 30, 2002 at 03:21:22AM +, Mike Barcroft wrote:
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist':
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not
type int (arg 3)
Can someone please just fix this (by backing out the offending commit,
if necessary)?
Eek, given a 64-bit size_t, the present code leaves 32 bits of it
uninitialized in the usual case. The following patch ought to fix
the problem; I can't make sure right now because I'm out of town.
I'm not sure if your patch will solve the problem.
The offending code is here:
240 if (lflag) {
241 char buf[32];
242 snprintf(buf, sizeof(buf), %ld-blocks, blocksize);
243 printf(%-13s %*s %*s\n,
244 Device:,
245 hlen, buf,
246 hlen, Used:);
247 }
Doesn't the printf() statement in question have the wrong number of
arguments?
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sshd fails with: fatal: ssh_msg_send: write
Hi,
I've seen similar posts about this problem but with no
solution here:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=212876+0+archive/2002/freebsd-current/20021222.freebsd-current
I've recently cvsup'd and rebuilt the world, and now I cannot
access my machine with ssh. In the console, I am seeing these
messages when I try to login:
sshd[2168]: fatal: ssh_msg_send: write
sshd[2171]: fatal: ssh_msg_send: write
If I restart my server with:
sshd -d -d -d
I get the following output:
debug3: mm_pam_init_ctx
debug3: mm_request_send entering: type 42
debug3: monitor_read: checking request 42
debug3: mm_answer_pam_init_ctx
debug3: mm_pam_init_ctx: waiting for MONITOR_ANS_PAM_INIT_CTX
debug3: mm_request_receive_expect entering: type 43
debug3: mm_request_receive entering
debug3: ssh_msg_send: type 1
ssh_msg_send: write
debug1: Calling cleanup 0x8061180(0x0)
debug1: PAM: cleanup
debug3: mm_request_receive entering
debug3: monitor_read: checking request 44
debug3: mm_answer_pam_query
debug3: ssh_msg_recv entering
This is the same backtrace posted by Segey Osokin:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=248381+0+/usr/local/www/db/text/2002/freebsd-current/20021222.freebsd-current
The error messages are being printed here inside /usr/src/crypto/openssh/msg.c:
33 void
34 ssh_msg_send(int fd, u_char type, Buffer *m)
35 {
36 u_char buf[5];
37 u_int mlen = buffer_len(m);
38
39 debug3(ssh_msg_send: type %u, (unsigned int)type 0xff);
40
41 PUT_32BIT(buf, mlen + 1);
42 buf[4] = type; /* 1st byte of payload is mesg-type */
43 if (atomicio(write, fd, buf, sizeof(buf)) != sizeof(buf))
44 fatal(ssh_msg_send: write);
45 if (atomicio(write, fd, buffer_ptr(m), mlen) != mlen)
46 fatal(ssh_msg_send: write);
47 }
48
I really don't know what the problem is.is this a PAM problem?
Thanks.
--
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: getpwnam_r missing
On Mon, Jan 06, 2003 at 01:55:24PM -0500, Garrett Wollman wrote: (We really should figure out how to implement the _r functions, because a POSIX.1-2001 system with threads is supposed to have them.) How do these functions need to be implemented? Is it sufficient to re-implement the non-reentrant versions of these functions, but avoid using static data variables? Or does there need to be some use of thread mutexes within the function itself? -- 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
[PATCH] Fix man pages with iovec
Hi,
This patch fixes the read(2) and write(2) man pages
to accurately reflect the iovec structure defined
in sys/_iovec.h and sys/uio.h.
--
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]
Index: read.2
===
RCS file: /home/ncvs/src/lib/libc/sys/read.2,v
retrieving revision 1.18
diff -u -r1.18 read.2
--- read.2 2002/12/19 09:40:25 1.18
+++ read.2 2003/01/12 07:05:27
@@ -85,7 +85,7 @@
.Pp
.Bd -literal -offset indent -compact
struct iovec {
- char *iov_base; /* Base address. */
+ void *iov_base; /* Base address. */
size_t iov_len;/* Length. */
};
.Ed
Index: write.2
===
RCS file: /home/ncvs/src/lib/libc/sys/write.2,v
retrieving revision 1.23
diff -u -r1.23 write.2
--- write.2 2002/12/19 09:40:25 1.23
+++ write.2 2003/01/12 07:05:28
@@ -85,7 +85,7 @@
.Pp
.Bd -literal -offset indent -compact
struct iovec {
- char *iov_base; /* Base address. */
+ void *iov_base; /* Base address. */
size_t iov_len;/* Length. */
};
.Ed
[PATCH] minor spelling fix
Hi, A minor spelling correction for section 19.10 of the Handbook. -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] Index: chapter.sgml === RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml,v retrieving revision 1.194 diff -u -r1.194 chapter.sgml --- chapter.sgml2003/01/12 18:20:50 1.194 +++ chapter.sgml2003/01/12 19:05:09 @@ -4277,7 +4277,7 @@ itemizedlist listitem paraa local DNS server may cache and respond more quickly - then querying an outside name server./para + than querying an outside name server./para /listitem listitem paraa reduction in overall network traffic is desired (DNS
Re: make buildkernel hang with SCHED_ULE
On Thu, Aug 14, 2003 at 08:17:33PM -0400, Andrew Gallatin wrote: You have machdep.hlt_logical_cpus: 1 in your sysctl output. [BTW, lots of people read this mail via the web archives at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1073654+0+current/freebsd-current, where its impossible to view mime; it would be MUCH better for us if appended things like stack traces and sysctl output rather then scrambling them for no reason] You can also read the archives at: http://lists.freebsd.org/pipermail/freebsd-current That archive supports MIME. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
cdcontrol no longer needs 'c' partition?
Hi,
With GEOM in place, is the 'c' partition for a CD device no
longer necessary for cdcontrol? At least on my system,
the CD shows up as /dev/acd0, not as /dev/acd0c.
--- src/usr.sbin/cdcontrol/cdcontrol.c.orig Sun Aug 17 17:25:46 2003
+++ src/usr.sbin/cdcontrol/cdcontrol.c Sun Aug 17 17:27:49 2003
@@ -52,10 +52,6 @@
# define DEFAULT_CD_DRIVE /dev/cd0
#endif
-#ifndef DEFAULT_CD_PARTITION
-# define DEFAULT_CD_PARTITION c
-#endif
-
#define CMD_DEBUG 1
#define CMD_EJECT 2
#define CMD_HELP 3
@@ -1248,11 +1244,6 @@
}
fd = open (devbuf, O_RDONLY);
-
- if (fd 0 errno == ENOENT) {
- strcat (devbuf, DEFAULT_CD_PARTITION);
- fd = open (devbuf, O_RDONLY);
- }
if (fd 0) {
if (errno == ENXIO) {
--- src/usr.sbin/cdcontrol/cdcontrol.1.orig Sun Aug 17 17:25:39 2003
+++ src/usr.sbin/cdcontrol/cdcontrol.1 Sun Aug 17 17:26:27 2003
@@ -185,10 +185,10 @@
.Ev CDROM .
.El
.Sh FILES
-.Bl -tag -width .Pa /dev/mcd0c -compact
-.It Pa /dev/cd0c
-.It Pa /dev/mcd0c
-.It Pa /dev/acd0c
+.Bl -tag -width .Pa /dev/mcd0 -compact
+.It Pa /dev/cd0
+.It Pa /dev/mcd0
+.It Pa /dev/acd0
.El
.Sh AUTHORS
.An Jean-Marc Zucconi
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster b0rked?
On Mon, Aug 18, 2003 at 07:05:54PM +0200, Wilko Bulte wrote: for i in answer isdntel.sh record tell tell-record unknown_incoming ; do install -o -g -m 700 $i /var/tmp/temproot/etc/isdn ; done ; for i in ^^ Why doesn't the -g flag have a GID as an argument? install: -g: Invalid argument *** Error code 67 -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cdcontrol no longer needs 'c' partition?
On Sun, Aug 17, 2003 at 11:27:23PM +0200, Poul-Henning Kamp wrote:
Yes, the 'a' and 'c' partitions on CD drives are bogus, but this
has nothing directly to do with GEOM, it is only a sideeffect
of the semantic cleanups that went ahead of GEOM.
The patch looks good to me, but I'd like somebody to test it
before it gets committed. Any takers ?
Well, I tested it and it worked for me. :)
--- src/usr.sbin/cdcontrol/cdcontrol.c.orig Sun Aug 17 17:25:46 2003
+++ src/usr.sbin/cdcontrol/cdcontrol.c Sun Aug 17 17:27:49 2003
@@ -52,10 +52,6 @@
# define DEFAULT_CD_DRIVE /dev/cd0
#endif
-#ifndef DEFAULT_CD_PARTITION
-# define DEFAULT_CD_PARTITION c
-#endif
-
#define CMD_DEBUG 1
#define CMD_EJECT 2
#define CMD_HELP3
@@ -1248,11 +1244,6 @@
}
fd = open (devbuf, O_RDONLY);
-
-if (fd 0 errno == ENOENT) {
-strcat (devbuf, DEFAULT_CD_PARTITION);
-fd = open (devbuf, O_RDONLY);
-}
if (fd 0) {
if (errno == ENXIO) {
--- src/usr.sbin/cdcontrol/cdcontrol.1.orig Sun Aug 17 17:25:39 2003
+++ src/usr.sbin/cdcontrol/cdcontrol.1 Sun Aug 17 17:26:27 2003
@@ -185,10 +185,10 @@
.Ev CDROM .
.El
.Sh FILES
-.Bl -tag -width .Pa /dev/mcd0c -compact
-.It Pa /dev/cd0c
-.It Pa /dev/mcd0c
-.It Pa /dev/acd0c
+.Bl -tag -width .Pa /dev/mcd0 -compact
+.It Pa /dev/cd0
+.It Pa /dev/mcd0
+.It Pa /dev/acd0
.El
.Sh AUTHORS
.An Jean-Marc Zucconi
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
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.
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cdcontrol no longer needs 'c' partition?
On Fri, Aug 22, 2003 at 09:00:32AM +0400, Maxim Konovalov wrote: On Sun, 17 Aug 2003, 17:21-0400, Craig Rodrigues wrote: Hi, With GEOM in place, is the 'c' partition for a CD device no longer necessary for cdcontrol? At least on my system, the CD shows up as /dev/acd0, not as /dev/acd0c. What's about CDROM environment var defined in login.conf? I don't understand your question. If the CDROM environment variable is set to a device name, cdcontrol will try to open that device. This is documented in the cdcontrol man page. If the CDROM environment variable is not set, a default device name of of /dev/cd0c is used, unless you override this with the -f flag. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftpd on -CURRENT ?
On Thu, Aug 28, 2003 at 06:31:58PM +0200, Peter Ulrich Kruppa [EMAIL PROTECTED] wrote: But this looks as if my inetd.conf isn't read on bootup. Read this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/inetd.html -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ip_divert.c lock order reversal
Hi, I just cvsup'd and noticed the following: Starting sshd. lock order reversal 1st 0xc2ee3998 inp (inp) @ /usr/src/sys/netinet/udp_usrreq.c:1042 2nd 0xc094876c div (div) @ /usr/src/sys/netinet/ip_divert.c:225 Stack backtrace: backtrace(c08643de,c094876c,c087b2de,c087b2de,c086b1c6) at backtrace+0x17 witness_lock(c094876c,8,c086b1c6,e1,0) at witness_lock+0x672 _mtx_lock_flags(c094876c,0,c086b1c6,e1,c16db200) at _mtx_lock_flags+0xba divert_packet(c16db200,0,21dc,32,c06832f3) at divert_packet+0x133 ip_output(c16db200,0,c2ee3924,0,0) at ip_output+0x851 udp_output(c2ee38e8,c16db200,0,0,c16cc4c0) at udp_output+0x403 udp_send(c2f1c000,0,c16db200,0,0) at udp_send+0xb7 sosend(c2f1c000,0,cdd10c48,c16db200,0) at sosend+0x44d kern_sendit(c16cc4c0,4,cdd10cc0,0,0) at kern_sendit+0x17c sendit(c16cc4c0,4,cdd10cc0,0,bfbfd2f8) at sendit+0x16e sendto(c16cc4c0,cdd10d10,c087d03a,3ed,6) at sendto+0x5b syscall(2f,2f,2f,8106000,28) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (133), eip = 0x282a810f, esp = 0xbfbfcf9c, ebp = 0xbfbfcfc8 --- Initial i386 initialization:. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_divert.c lock order reversal
Hi,
I am seeing an occasional kernel panic. I think it
is related to natd and ip_divert
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc07e6c24
stack pointer = 0x10:0xce7026c4
frame pointer = 0x10:0xce7026d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 273 (natd)
Reading symbols from
/usr/obj/usr/src/sys/MYKERNEL1/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MYKERNEL1/modules/usr/src/sys/modules/acpi/acpi.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc065c29c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc065c627 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0467692 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc04675f2 in db_command (last_cmdp=0xc08f7d80, cmd_table=0x0,
aux_cmd_tablep=0xc0882788, aux_cmd_tablep_end=0xc08827a0)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0467735 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc046a735 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc07e696c in kdb_trap (type=12, code=0, regs=0xce702904)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc07f7d96 in trap_fatal (frame=0xce702904, eva=0)
at /usr/src/sys/i386/i386/trap.c:815
#9 0xc07f7a62 in trap_pfault (frame=0xce702904, usermode=0, eva=3735929054)
at /usr/src/sys/i386/i386/trap.c:734
#10 0xc07f761d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -831520752, tf_edi = -1064957451, tf_esi =
-559038242, tf_ebp = -831510204, tf_isp = -831510224, tf_ebx = -831509976, tf_edx =
-559038242, tf_ecx = 0, tf_eax = -559038242, tf_trapno = 12, tf_err = 0, tf_eip =
-1066647656, tf_cs = 8, tf_eflags = 66118, tf_esp = -831510004, tf_ss = -1066938255})
at /usr/src/sys/i386/i386/trap.c:419
#11 0xc07e8358 in calltrap () at {standard input}:102
#12 0xc067d071 in kvprintf (fmt=0xc08609f5 @ %s:%d,
func=0xc067ca10 snprintf_func, arg=0xce702a28, radix=10,
ap=0xce702a74 \004É\206À\n\001) at /usr/src/sys/kern/subr_prf.c:669
#13 0xc067c98e in vsnprintf (str=0xc09214e0 mtx_lock() of spin mutex ,
size=0, format=0x0, ap=0x0) at /usr/src/sys/kern/subr_prf.c:414
#14 0xc065c541 in panic (fmt=0xc08609da mtx_lock() of spin mutex %s @ %s:%d)
at /usr/src/sys/kern/kern_shutdown.c:511
#15 0xc0652646 in _mtx_lock_flags (m=0xc2f37d90, opts=0,
file=0xc086c904 /usr/src/sys/netinet/ip_output.c, line=266)
at /usr/src/sys/kern/kern_mutex.c:332
#16 0xc06f50c7 in ip_output (m0=0xc2f37d90, opt=0x10a, ro=0xc086c904,
flags=34, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:266
#17 0xc06e9021 in div_output (so=0xc2ee2000, m=0xc16e2f00, sin=0xc2ecb240,
control=0x0) at /usr/src/sys/netinet/ip_divert.c:320
#18 0xc06e94fd in div_send (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0,
td=0xc2d40720) at /usr/src/sys/netinet/ip_divert.c:476
#19 0xc0699ecd in sosend (so=0xc2ee2000, addr=0xc2ecb240, uio=0xce702c48,
top=0xc16e2f00, control=0x0, flags=0, td=0xc2d40720)
at /usr/src/sys/kern/uipc_socket.c:714
#20 0xc069e48c in kern_sendit (td=0xc2d40720, s=3, mp=0xce702cc0, flags=0,
control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:723
#21 0xc069e2de in sendit (td=0x0, s=0, mp=0xce702cc0, flags=0)
at /usr/src/sys/kern/uipc_syscalls.c:663
#22 0xc069e61b in sendto (td=0x0, uap=0x0)
at /usr/src/sys/kern/uipc_syscalls.c:784
#23 0xc07f8100 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = -1078002688, tf_esi = 2,
tf_ebp = -1077937128, tf_isp = -831509132, tf_ebx = 482, tf_edx = 26852, tf_ecx =
1148159575, tf_eax = 133, tf_trapno = 0, tf_err = 2, tf_eip = 134558627, tf_cs = 31,
tf_eflags = 582, tf_esp = -1078002836, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1009
#24 0xc07e83ad in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb) quit
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Sat, Nov 01, 2003 at 06:24:18PM -0500, Barney Wolff wrote: Er, how is it possible to send a UDP packet 65535? Last time I looked it was a 16-bit field. This is explained in section 4. of RFC 2675, IPv6 Jumbograms, http://www.ietf.org/rfc/rfc2675.txt -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB mass storage device oddness
On Sat, Jul 12, 2003 at 11:02:00AM +0100, Michael McGoldrick wrote: Unfortunately, when I remove a card, the whole umass0 device vanishes, never to reappear. Did you read the umass(4) and camcontrol(8) man pages? Did you try something like camcontrol rescan? -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current buildworld failure in libpam
On Sat, Jul 12, 2003 at 10:59:44AM +0200, Michael Reifenberger wrote:
=== lib/libpam/modules/pam_echo
cc -O2 -pipe
-I/usr/src/lib/libpam/modules/pam_echo/../../../../contrib/openpam/include
-I/usr/src/lib/libpam/modules/pam_echo/../../libpam -Wsystem-headers -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/libpam/modules/pam_echo/pam_echo.c
/usr/src/lib/libpam/modules/pam_echo/pam_echo.c: In function `_pam_echo':
/usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing
type-punned pointer will break strict-aliasing rules
*** Error code 1
What do you have in your /etc/make.conf? If you change optimization
from -O2 to -O, then this problem goes away.
I looked into this problem, and created a patch based on a workaround
for a similar problem that I saw here:
http://sources.redhat.com/ml/libc-hacker/2002-11/msg00048.html
Can you try this patch?
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
Index: pam_echo.c
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_echo/pam_echo.c,v
retrieving revision 1.3
diff -u -u -r1.3 pam_echo.c
--- pam_echo.c 6 Feb 2003 14:19:50 - 1.3
+++ pam_echo.c 12 Jul 2003 13:57:29 -
@@ -48,7 +48,11 @@
int argc, const char *argv[])
{
char msg[PAM_MAX_MSG_SIZE];
- const char *str, *p, *q;
+ const char *p, *q;
+ union {
+ const char *s;
+ const void *ptr;
+ } str;
int err, i, item;
size_t len;
@@ -89,12 +93,12 @@
}
if (item == -1)
continue;
- err = pam_get_item(pamh, item, (const void **)str);
+ err = pam_get_item(pamh, item, str.ptr);
if (err != PAM_SUCCESS)
return (err);
- if (str == NULL)
- str = (null);
- for (q = str; *q != '\0' len sizeof(msg) - 1; ++q)
+ if (str.s == NULL)
+ str.s = (null);
+ for (q = str.s; *q != '\0' len sizeof(msg) - 1; ++q)
msg[len++] = *q;
}
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
GCC 3.3.1, new warnings with limits
Hi,
If I compile the following program:
#include iostream
int main(int argc, char *argv[] { return 0; }
with the following flags:
g++ -W -Wall b.cc
I get lots of warnings that did not appear in GCC 3.2:
In file included from /usr/include/c++/3.3/bits/locale_facets.tcc:43,
from /usr/include/c++/3.3/locale:47,
from /usr/include/c++/3.3/bits/ostream.tcc:37,
from /usr/include/c++/3.3/ostream:535,
from /usr/include/c++/3.3/iostream:45,
from b.cc:1:
/usr/include/c++/3.3/limits:630: warning: comparison of unsigned expression 0
is always false
/usr/include/c++/3.3/limits:631: warning: comparison of unsigned expression 0
is always false
/usr/include/c++/3.3/limits:730: warning: comparison of unsigned expression 0
is always false
/usr/include/c++/3.3/limits:731: warning: comparison of unsigned expression 0
is always false
/usr/include/c++/3.3/limits:830: warning: comparison of unsigned expression 0
is always false
/usr/include/c++/3.3/limits:831: warning: comparison of unsigned expression 0
is always false
Is there a way to fix the limits header file?
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sat, Jul 12, 2003 at 09:50:21PM -0500, David Leimbach wrote: Heh that's because the offending macro __glibcpp_digits calls __glibcpp_signed (T) on an unsigned type which does a compareison. std::numeric_limits signed long::digits on a 32bit FBSD will yield 31 because its got 31 bits for magnitude. Unfortunately the way it seems to go about calculating that stuff at compile time seems to be invalid due to the fact that it does 0 compares on unsigned types. Is this a gcc issue or a FBSD issue? [is this the original gcc c++ header file or has it been tweaked?] Hi, I think that this is a FreeBSD issue. I compiled the same file under Linux, with a GCC 3.3.1 checked out on 7/11 and did not encounter this warning. I looked in the source code of gcc and found this: /usr/src/contrib/gcc/c-common.c 2597 case LT_EXPR: 2598 if (extra_warnings !in_system_header 2599! (TREE_CODE (primop0) == INTEGER_CST 2600 ! TREE_OVERFLOW (convert (c_common_signed_typ e (type), 2601 primop0 2602 warning (comparison of unsigned expression 0 is alway s false); 2603 value = boolean_false_node; 2604 break; I am guessing that the C preprocessor does not think that it is in a system header, and thus prints out the warning. If I take the following preprocessed source (test.ii) and compile it under FreeBSD with g++ -W -c test.ii: === # 1 test.cc # 1 built-in # 1 command line # 1 test.cc # 1 /usr/include/c++/3.3/iostream 1 3 # 43 /usr/include/c++/3.3/iostream 3 static const int digits = (sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)); === I get: In file included from test.cc:1: /usr/include/c++/3.3/iostream:44: warning: comparison of unsigned expression 0 is always false If I compile the same file on my Linux box, with a gcc checked out from the FSF CVS repository (gcc version 3.3.1 20030711 (prerelease)), I do not get the warning. I am not an expert on the GNU C preprocessor format, but I changed two of the lines in the above file to: # 1 /usr/include/c++/3.3/iostream 1 # 43 /usr/include/c++/3.3/iostream and when I recompiled it under Linux, I also got the warning: In file included from test.cc:1: /usr/include/c++/3.3/iostream:44: warning: comparison of unsigned expression 0 is always false Any GCC/FreeBSD expert care to comment? ;) -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 12:05:59AM -0400, Alexander Kabaev wrote: On Sat, 12 Jul 2003 23:13:12 -0400 Craig Rodrigues [EMAIL PROTECTED] wrote: I am guessing that the C preprocessor does not think that it is in a system header, and thus prints out the warning. We specifically disable automatic warning suppression for system headers, because we _want_ to know about them. Your Linux distribution apparently does not care. How do you disable/enable warning suppression for system headers? I am not familiar enough with how GCC works in this area. Any GCC/FreeBSD expert care to comment? ;) Short of fixing offending files in FSF libstdc++ or turning warning suppression back on for standard C++ include files selectively, I have no suggestion. Hmm, I'm not sure what to recommend here either. I'd like to see this fixed somewhere, because this increases the warning output for some large C++ projects that I work with (I like to see warnings also). The warnings seemed to be caused by this code in /usr/include/c++/3.3/limits: = 630 static const int digits = __glibcpp_digits (unsigned int); 631 static const int digits10 = __glibcpp_digits10 (unsigned int); = The macros are defined in the same file here: 134 #define __glibcpp_signed(T) ((T)(-1) 0) 142 #define __glibcpp_digits(T) \ 143 (sizeof(T) * __CHAR_BIT__ - __glibcpp_signed (T)) The expanded macros look like: static const int digits = (sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)); static const int digits10 = ((sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)) * 643 / 2136); I don't really know how to fix this. Maybe introduce a new macro? #define __glibcpp_unsigned_digits(T) \ (sizeof(T) * __CHAR_BIT__ and then use that macro only for unsigned quantities? Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Porting networking code from -STABLE to -CURRENT
Hi, I am interested in using the SCTP protocol implementation ( http://www.sctp.org ) on -CURRENT. Currently it works on -STABLE, and is integrated with the current KAME snapshots ( http://www.kame.net ). Has anyone ported networking code from -STABLE to -CURRENT? What is involved? Right now the code uses splnet() / splx() is there a guideline for how to migrate to the macros in mutex(9)? Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld problem in 5.1-CURRENT
On Fri, Jul 25, 2003 at 08:13:58AM -0700, Christopher Johnson wrote: I cvsup'ed this morning and buildworld failed: ... === lib/libpam/modules/pam_echo cc -O2 -pipe -march=pentiumpro What is in your /etc/make.conf? I do not think that -O2 is supported in the build right now, due to increased verbosity of warnings in gcc 3.3. /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 in world
On Mon, Aug 04, 2003 at 11:27:57AM -0700, Terry Lambert wrote: That's chicken/egg - IPv6 never will be widely used if everyone thinks that way. The problem, as I see it, is that it doesn't come enabled by default on Windows systems. Until it does, it's never going to get any traction. I wouldn't be surprised if the government has asked Microsoft to not deploy it, or to deploy it without encryption support, given world events. The government is pushing IPv6, but from a different direction: http://www.fcw.com/fcw/articles/2003/0609/web-dodip-06-13-03.asp http://www.defenselink.mil/transcripts/2003/tr20030613-0274.html In the U.S., this will probably push many vendors to become IPv6-compatible. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient problem with xl0
On Sat, Aug 09, 2003 at 12:28:45PM +0200, Martin Blapp wrote: Hi, Here is the output of dhclient -v -d xl0 I I checked. Dhclient still initializes the interface and brings it up itself. So there is only one possibility: You don't have a working link. Maybe it helps if you add a interface define in /etc/dhclient.conf wit the possible media. Hmmm, I am not sure about this, since if I use the old dhclient binary, it works fine without problems. Here is the output if 'ifconfig xl0': xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=8VLAN_MTU inet6 fe80::260:97ff:fe72:adf0%xl0 prefixlen 64 scopeid 0x2 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 ether 00:60:97:72:ad:f0 media: Ethernet 10baseT/UTP (10baseT/UTP half-duplex) -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
dhclient problem with xl0
Hi, I just did a cvsup of -CURRENT and rebuilt the world. dhclient doesn't seem to work for me any more. It looks like a problem with dhclient, and not the kernel, because an older version of dhclient works fine. Here is the output of dhclient -v -d xl0 == Script started on Sat Aug 9 03:11:38 2003 Internet Software Consortium DHCP Client V3.0.1rc11 Copyright 1995-2002 Internet Software Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP Listening on BPF/xl0/00:60:97:72:ad:f0 Sending on BPF/xl0/00:60:97:72:ad:f0 Sending on Socket/fallback xl0: Polling interface state xl0: client state of 2 xl0: link = 0 xl0: No Link on interface xl0: Polling interface state xl0: client state of 2 xl0: link = 0 xl0: No Link on interface xl0: Polling interface state xl0: client state of 2 xl0: link = 0 xl0: No Link on interface xl0: Polling interface state xl0: client state of 2 xl0: link = 0 xl0: No Link on interface xl0: Polling interface state xl0: client state of 2 xl0: link = 0 xl0: No Link on interface Script done on Sat Aug 9 03:12:04 2003 == -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adaptec AIC7902 Ultra320 Problems
On Mon, Aug 11, 2003 at 11:14:49AM -0600, Justin T. Gibbs wrote: I've got another drive now to mess about with: da0: IBM IC35L036UWDY10-0 S23C Fixed Direct Access SCSI-3 device And I get the same problems. I would have to see the driver messages to verify that. You are running down rev. firmware on this drive and early Daytona firmware revs had some serious problems. Have you contacted Hitachi (they bought the IBM drive division) for a firmware update? You can get firmware and drivers for these drives from Hitachi: http://www.hgst.com/support/ -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Porting 4.x code to 5.x: zfreei, zinit, struct vm_zone
Hi, I am trying to port Randall Stewart's SCTP implementation from -STABLE to -CURRENT. The code makes use of zfreei(), zinit(), etc. and struct vm_zone. How can I port this code to -CURRENT? Can I start by replacing these calls be directly replaced with the uma_* versions: zinit-uma_zcreate zfreei -uma_zfree How do I deal with the struct vm_zone? Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: M_NOTIFICATION in sys/mbuf.h?
On Wed, Aug 13, 2003 at 07:47:01PM -0400, Matthew Emmerton wrote: KAME guys have it here: http://orange.kame.net/dev/cvsweb.cgi/kame/freebsd5/sys/sys/mbuf.h?rev=1.5 The KAME snapshot of our source tree is 3 months out of date. The most recent version of mbuf.h is here: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/mbuf.h?rev=1.122content-type=text/plain We already have 0x8000 assigned, and the only free flags value is 0x4000 -- but it conflicts with other private usages in the kernel (as per the CVS comments.) Does SCTP-KAME really need a special flag value? OK, I am looking at the FreeBSD-4 source tree for KAME and found this: http://orange.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/sys/mbuf.h.diff?r1=1.18r2=1.19 CVS comment: sctp for freebsd4 - again, not ready for daily use yet It looks like M_NOTIFICATION was added specifically for SCTP. I'll try to find out more about this. Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Question about porting KAME IPv6 to CURRENT
Hi, Is anyone actively working on importing the latest IPv6 implementation from KAME to CURRENT? I am trying to port the sctp.org implementation of SCTP to -CURRENT, and am getting hung up on the mismatch between KAME's IPv6 implementation and -CURRENT's. I am giving a shot at importing some of the KAME sources, but am getting hung up in a few places. In src/sys/netinet6/scope6.c, KAME defines this macro: static struct scope_id sid_default; #define SID(ifp) \ ((struct in6_ifextra *)(ifp)-if_afdata[AF_INET6]-scope6_id) where ifp is supposed to be a struct ifnet. However, CURRENT's struct ifnet does not have an if_afdata member. Is there a way to rewrite this macro to give the same functionality under CURRENT? Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Porting 4.x code to 5.x: zfreei, zinit, struct vm_zone
On Mon, Aug 11, 2003 at 08:23:56PM +, Bosko Milekic wrote: Take a look at zone(9) in -current. It has been updated, more or less. Otherwise, glance at src/sys/vm/uma.h, which is decently documented for what concerns exported API. Thanks for this pointer. This API is not too difficult, but it will require some work to port things. Sam Leffler also pointed me to sys/opencrypto/crypto.c, which makes good use of this API. For the zone(9) man page, for the uma_zcreate() function, it is not clear what the valid values of flags are. The only place where flags is mentioned is with respect to uma_zalloc: the flags argument to selected flags as documented in malloc(9). However, the flags argument in uma_zcreate() does not take the flags as documented in malloc(9). Would it be useful to update zone(9) with either: - text that says, go see the flags in vm/uma.h - document the actual uma_zcreate flags The documentation in vm/uma.h is actually good enough, IMHO, but referencing it in the man page would be nice. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient problem with xl0
On Sat, Aug 09, 2003 at 06:21:43PM +0200, Martin Blapp wrote:
Hi,
Adapted to the newst source-version, the patch will look like
this. After I got home, I'll test it.
OK, this is weird. I did not use your change to dhclient.
However, I did use Matthew Dodd's change to if_xl.c.
I rebuilt the kernel, powered down, rebooted, and things seem
to work better.
Before Matthew's patch, ifconfig xl0 would never print out
status:
Now, ifconfig xl0, *always* prints out:
status: no carrier
even if I do have carrier.
If I run dhclient (without your patch, but with debugging), I get:
===
Internet Software Consortium DHCP Client V3.0.1rc1
Copyright 1995-2002 Internet Software Consortium
All rights reserved
For info, please visit http://www.isc.org/products/DHCP
Listening on BPF/xl0/00:60:97:72:ad:f0
Sending on BPF/xl0/00:60:97:72:ad:f0
Sending on Socket/fallback
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: No Link on interface
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: No Link on interface
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: No Link on interface
===
Now, if I add the following lines to /etc/dhclient.conf (I've never
had to modify this file before):
interface xl0 {
media autoselect;
}
I then get the following from dhclient:
===
Script started on Sat Aug 9 13:11:42 2003
Internet Software Consortium DHCP Client V3.0.1rc11
Copyright 1995-2002 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Listening on BPF/xl0/00:60:97:72:ad:f0
Sending on BPF/xl0/00:60:97:72:ad:f0
Sending on Socket/fallback
xl0: Polling interface state
xl0: client state of 2
xl0: link = 0
xl0: Trying media settings on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 156736 seconds.
xl0: Polling interface state
xl0: client state of 5
xl0: link = 1
xl0: Lost Link on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 149325 seconds.
xl0: Polling interface state
xl0: client state of 5
xl0: link = 1
xl0: Lost Link on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 158190 seconds.
xl0: Polling interface state
xl0: client state of 5
xl0: link = 1
xl0: Lost Link on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 144066 seconds.
xl0: Polling interface state
xl0: client state of 5
xl0: link = 1
xl0: Lost Link on interface
DHCPREQUEST on xl0 to 255.255.255.255 port 67
DHCPACK from 10.208.128.1
bound to 66.31.45.197 -- renewal in 156702 seconds.
===
Note, now that I am online, if I do ifconfig xl0, I get the following:
xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
inet6 fe80::260:97ff:fe72:adf0%xl0 prefixlen 64 scopeid 0x2
inet 66.31.45.197 netmask 0xf800 broadcast 255.255.255.255
ether 00:60:97:72:ad:f0
media: Ethernet 10baseT/UTP (10baseT/UTP half-duplex)
status: no carrier
So it looks like maybe there is a problem with the xl driver?
(Note I am running with Matthew Dodd's patch).
It would be nice to get this to work so that I don't have to
edit /etc/dhclient.conf, since I never had to do it before.
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
M_NOTIFICATION in sys/mbuf.h?
Hi, While trying to port the SCTP-KAME code to CURRENT, I noticed that M_NOTIFICATION is missing from sys/mbuf.h in CURRENT, but it is present in the KAME version of this file. Any reason not to apply this patch? --- sys/sys/mbuf.h.orig Sat Sep 13 19:34:07 2003 +++ sys/sys/mbuf.h Sat Sep 13 19:34:14 2003 @@ -164,6 +164,8 @@ #defineM_FIRSTFRAG 0x1000 /* packet is first fragment */ #defineM_LASTFRAG 0x2000 /* packet is last fragment */ +#define M_NOTIFICATION 0x8000 /* notification event */ + /* * External buffer types: identify ext_buf type. */ KAME guys have it here: http://orange.kame.net/dev/cvsweb.cgi/kame/freebsd5/sys/sys/mbuf.h?rev=1.5 Thanks. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VM_METER no longer defined?
On Fri, Jan 17, 2003 at 10:42:27AM -0700, Scott Long wrote: I've got to admit that this one slipped in under my radar. Would the committer and submitter please give an explanation of why VM_METER was changed? The commit which removed VM_METER is here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1995623+0+archive/2003/cvs-all/20030112.cvs-all -- 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: VM_METER no longer defined?
On Fri, Jan 17, 2003 at 10:26:10AM -0800, Will Andrews wrote:
Of course, these things can be fixed. But I consider this change
gratuitous and it breaks standard compatability rules: deprecate
for one major version and remove in the second. I haven't seen
any reason why this couldn't be added to vm/vm_param.h:
#define VM_METER VM_TOTAL
for compatability purposes. This change is way too sudden in an
external API (if it's supposed to be internal, then protect it
with an #ifdef _KERNEL already!).
How about this then:
Index: vm_param.h
===
RCS file: /home/ncvs/src/sys/vm/vm_param.h,v
retrieving revision 1.16
diff -u -r1.16 vm_param.h
--- vm_param.h 2003/01/11 07:29:46 1.16
+++ vm_param.h 2003/01/17 23:25:52
@@ -89,6 +89,8 @@
#define VM_SWAPPING_ENABLED11 /* swapping enabled */
#defineVM_MAXID12 /* number of valid vm ids */
+#define VM_METER VM_TOTAL /* backwards compatibility, struct vmmeter */
+
#define CTL_VM_NAMES { \
{ 0, 0 }, \
{ vmtotal, CTLTYPE_STRUCT }, \
The only place where VM_METER is used in this directory was in vm_meter.c:
240 SYSCTL_PROC(_vm, VM_METER, vmmeter, CTLTYPE_OPAQUE|CTLFLAG_RD,
241 0, sizeof(struct vmtotal), vmtotal, S,vmtotal,
242 System virtual memory statistics);
This changed to:
240 SYSCTL_PROC(_vm, VM_TOTAL, vmtotal, CTLTYPE_OPAQUE|CTLFLAG_RD,
241 0, sizeof(struct vmtotal), vmtotal, S,vmtotal,
242 System virtual memory statistics);
--
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: pw
On Fri, Jan 24, 2003 at 02:25:38AM +0600, Max Khon wrote: hi, there! Can we enable using '$' in usernames in pw? The patch is attached. The same patch was submitted here by David Chapman: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1059329+1062195+/usr/local/www/db/text/2002/freebsd-current/20021201.freebsd-current See the long discussion thread that followed. -- 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: 5.0-RELEASE failing on Thinkpad T30
On Sun, Jan 26, 2003 at 12:47:28AM -0500, stark wrote: I guess submitting a patch to ports/net/cvsupit that would include this selection would be a better way, eh? :) (i use cvsupit to make the cvsup file, so that's why i didn't even know i was missing something :) I submitted a patch to add src-sys-crypto to cvsupit to the freebsd-current mailing list in October, but forgot to file a PR: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=740939+0+archive/2002/freebsd-current/20021027.freebsd-current I have now filed a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=47513 -- 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: Kernel broken at sysv_msg.c
On Sun, Jan 26, 2003 at 01:58:52PM -0800, walt wrote: cc1: warnings being treated as errors /usr/src/sys/kern/sysv_msg.c: In function `msgsnd': /usr/src/sys/kern/sysv_msg.c:775: warning: cast discards qualifiers from pointer target type /usr/src/sys/kern/sysv_msg.c:818: warning: cast discards qualifiers from pointer target type *** Error code 1 Get version 1.47 of src/sys/kern/sysv_msg.c -- 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
Lock order reversal in if_ether.c
Hi, I am seeingthis from a kernel cvsup'd a few days ago: login: lock order reversal 1st 0xc060ad20 arp mutex (arp mutex) @ /usr/src/sys/netinet/if_ether.c:151 2nd 0xc339097c radix node head (radix node head) @ /usr/src/sys/net/route.c:549 Thanks. -- 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: Force 1 CPU on SMP kernel?
Hi, Does FreeBSD-SMP have anything equivalent to the processor_bind(2) call on Solaris, which binds a process to a specific processor? http://docs.sun.com/db/doc/816-0212/6m6nd4nci?a=view -- 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: Lock order reversal
On Tue, Jan 28, 2003 at 07:04:07PM -0600, Sean Kelly wrote: I just noticed this during bootup. It is repeatable. See: http://news.gw.com/freebsd.current/30547 -- 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: net-snmp errors
On Tue, Jan 28, 2003 at 04:30:47PM -0600, Nick H. -- Technical Support Engineer wrote: Sorry about emailing both lists, as Im not sure which one this falls under. It's a current machine (5.0-CURRENT) and it's a problem with a port (net-snmp). Below is what happens: `VM_METER' undeclared (first use in this function) Anyone know how to fix this or a way around it? You need to update and get version 1.17 of /usr/src/sys/vm/vm_param.h. See: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1718003+1720385+/usr/local/www/db/text/2003/freebsd-current/20030119.freebsd-current -- 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: sysinstall-Configure-Fdisk
On Tue, Feb 04, 2003 at 05:16:22PM +1000, Andy Farkas wrote: sysinstall's 'FDISK Partition Editor' won't let me create a second slice. After pressing 'w' it says: ERROR: Unable to write data to disk ad4! then Disk partition write returned an error status! Freshly cvsup'd a few hours ago. # sysctl -a | grep kern.version kern.version: FreeBSD 5.0-CURRENT #2: Tue Feb 4 11:04:44 EST 2003 This is a known problem due to GEOM. It doesn't matter if you are root, or if your securelevel is set properly. It just won't work. See the thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=295042+0+archive/2002/freebsd-current/20021229.freebsd-current Try to boot from another disk or a floppy, then you will be able to create a new partition with sysinstall. -- 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: New technologies in FreeBSD 5.x vs. 4.x
On Sat, Feb 08, 2003 at 01:23:58PM +0100, taxman wrote: Very detailed information for every commit can be found at: http://www.freebsd.org/cgi/cvsweb.cgi/ Adrian, For your FreeBSD news article, if you want to get in contact with developers who have added new things to FreeBSD, I recommend you look at the latest status reports in 2002: http://www.freebsd.org/news/status/status.html Those reports have nice summaries of new features, with contact e-mails for the developers who added those features. -- 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: printf....!
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. Look in /usr/src/sys/kern/syscalls.master. You will see that this write() is listed as a system call. If you run the script makesyscalls.sh which is in the same directory, it will create syscalls.c, syscalls.h, sysproto.h, and syscall.mk. If you look at /usr/src/sys/sys/syscall.h, you will see SYS_write defined in that file. You can see the man page for syscall() to see what it does when you do syscall(SYS_write, ...); Look in /usr/src/sys/kern/sys_generic.c, and look at the write() function there. I'm not familiar with DOS interrupts, but hopefully that will give you more clues:) You should also look at the Developer's Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ -- 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: 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
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: GCC 3.2.2 import -- questions
On Mon, Feb 10, 2003 at 08:44:33PM -0500, Wesley Morgan wrote: that are supposedly fixed with 3.2.2... My question is, should I consider rebuilding my ports with this new compiler because of stability and/or speed improvements? Or is this point release not worth the effort. Speed improvements? No. gcc 3.2.2 is definitely slower than gcc 2.95. There is a lot of arguing on the gcc mailing list right now about this, but no concrete action to improve the situation yet. Stability improvements? For a list of bug fixes see: http://gcc.gnu.org/gcc-3.2/changes.html and decide for yourself. -- 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: GCC 3.2.2 import -- questions
On Mon, Feb 10, 2003 at 08:06:19PM -0600, Juli Mallett wrote: I would assume the OP meant relative to the previous version of GCC in tree. Current hasn't been 2.95.x for some time. Many people are upgrading from 4.7.x to -current for the first time these days, so I thought I would mention that for reference. GCC 3.2.2 was an incremental bugfix over GCC 3.2.1, and there are no earth-shattering performance improvements. I have not done such benchmarking myself, so have no empirical evidence to support this, but I am basing this on the traffic I have been watching on the GCC mailing list, and by reading the release notes at http://gcc.gnu.org/gcc-3.2/changes.html . There is a long thread on the GCC mailing list right now complaining about compile-time speed regressions from 2.95.x, with many complaints coming from Apple: http://gcc.gnu.org/ml/gcc/2003-02/msg00558.html Whether these complaints lead to actual improvements is yet to be seen -- 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
Adding std::wstring and wchar_t support to GCC on -CURRENT
Hi, I posted to the GCC mailing list recently, mentioning that GCC under FreeBSD does not have std::wstring/wchar_t support. Alexander Kabaev posted a list of problems under FreeBSD, and some possible workarounds: http://gcc.gnu.org/ml/gcc/2003-02/msg01291.html Hopefully some of the FreeBSD header file problems will be resolved soon. For example, Mike Barcroft has mentioned an approach for adding WCHAR_MIN and WCHAR_MAX macros to wchar.h by creating a new machine/_limits.h private header file. I followed Alex's instructions for creating a workaround, to enable wchar_t support in libstdc++, so I am posting my patches for those who may be interested. I think the wchar.h patch will be unnecessary once the machine/_limits.h fix is integrated in FreeBSD. I just rebuilt the world, and don't seem to have any problems yet! --- src/include/wchar.h.origWed Feb 19 17:21:14 2003 +++ include/wchar.h Thu Feb 20 03:20:32 2003 @@ -100,6 +100,14 @@ #defineWEOF((wint_t)-1) #endif +#ifndef WCHAR_MIN +#define WCHAR_MIN (-2147483647l - 1l) +#endif + +#ifndef WCHAR_MAX +#define WCHAR_MAX (2147483647l) +#endif + struct __sFILE; struct tm; --- src/gnu/lib/libstdc++/c++config.h.orig Wed Feb 19 13:35:27 2003 +++ src/gnu/lib/libstdc++/c++config.h Wed Feb 19 13:36:25 2003 @@ -108,6 +108,7 @@ // Define if code specialized for wchar_t should be used. /* #undef _GLIBCPP_USE_WCHAR_T */ +#define _GLIBCPP_USE_WCHAR_T 1 // Define if using setrlimit to limit memory usage during 'make check'. /* #undef _GLIBCPP_MEM_LIMITS */ --- src/contrib/libstdc++/include/c_std/std_cwchar.h.orig Wed Feb 19 13:37:36 2003 +++ src/contrib/libstdc++/include/c_std/std_cwchar.hWed Feb 19 13:38:05 2003 @@ -173,7 +173,7 @@ using ::wcsrtombs; using ::wcsspn; using ::wcstod; - using ::wcstof; + //using ::wcstof; using ::wcstok; using ::wcstol; using ::wcstoul; -- 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
Problem with M_COPY_PACKET
Hi,
I did a cvsup today, and when I tried to compile the Netgraph ATM drivers,
I got this error:
~rodrigc/ngatm/ngatmbase-1.2b/fatm/if_fatm.c
cc1: warnings being treated as errors
/usr/home/rodrigc/ngatm/ngatmbase-1.2b/fatm/if_fatm.c: In function `copy_mbuf':
/usr/home/rodrigc/ngatm/ngatmbase-1.2b/fatm/if_fatm.c:1625: warning: implicit
declaration of function `M_COPY_PKTHDR'
The code in question looks like:
=
struct mbuf *
copy_mbuf(struct mbuf *m)
{
struct mbuf *new;
MGET(new, M_DONTWAIT, MT_DATA);
if(new == NULL)
return NULL;
if(m-m_flags M_PKTHDR)
M_COPY_PKTHDR(new, m);
if(m-m_flags M_EXT) {
MCLGET(new, M_DONTWAIT);
if(!(m-m_flags M_EXT)) {
m_free(new);
return NULL;
}
}
bcopy(m-m_data, new-m_data, m-m_len);
new-m_len = m-m_len;
new-m_flags = ~M_RDONLY;
=
I am not familiar with all the changes that have occurred to the M_*
macros. What should I do to correct this?
Thanks.
--
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
Implicit typename warnings in fstream
Hi,
I did a cvsup yesterday and rebuilt the world.
The compiler I am using now is:
gcc version 3.2.2 [FreeBSD] 20030205 (release)
My compiler has a few minor patches, to enable
wchar_t support in libstdc++:
http://news.gw.com/freebsd.current/32128
If I try to compile any file which includes
fstream, I get the following warnings:
/usr/include/g++/fstream:304: warning: `typename std::basic_filebuf_CharT,
_Traits::int_type' is implicitly a typename
/usr/include/g++/fstream:304: warning: implicit typename is deprecated, please
see the documentation for details
/usr/include/g++/fstream:309: warning: `typename std::basic_filebuf_CharT,
_Traits::int_type' is implicitly a typename
/usr/include/g++/fstream:309: warning: implicit typename is deprecated, please
see the documentation for details
The lines in question are:
300 // Generic definitions.
301 template typename _CharT, typename _Traits
302 basic_filebuf_CharT, _Traits::int_type
303 basic_filebuf_CharT, _Traits::underflow()
304 { return _M_underflow_common(false); }
305
306 template typename _CharT, typename _Traits
307 basic_filebuf_CharT, _Traits::int_type
308 basic_filebuf_CharT, _Traits::uflow()
309 { return _M_underflow_common(true); }
Does anyone have any ideas?
Thanks.
--
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
OpenSSL should define OPENSSL_THREADS?
Hi, I ran a cvsup of -CURRENT a few days ago. I have some code which assumes that OPENSSL_THREADS is defined if the OpenSSL version is greater than 0.9.7: #define OPENSSL_THREAD_DEFINES #include openssl/opensslconf.h #include openssl/opensslv.h #if OPENSSL_VERSION_NUMBER 0x0090700fL # if !defined(THREADS) # error Thread support not enabled # endif #else # if !defined(OPENSSL_THREADS) # error Thread support not enabled # endif #endif Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? Thanks. -- 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: OpenSSL should define OPENSSL_THREADS?
On Mon, Feb 24, 2003 at 09:58:21PM -0500, Craig Rodrigues wrote: Hi, I ran a cvsup of -CURRENT a few days ago. I have some code which assumes that OPENSSL_THREADS is defined if the OpenSSL version is greater than 0.9.7: I meant to say greater than or equal to 0.9.7. :) #define OPENSSL_THREAD_DEFINES #include openssl/opensslconf.h #include openssl/opensslv.h #if OPENSSL_VERSION_NUMBER 0x0090700fL # if !defined(THREADS) # error Thread support not enabled # endif #else # if !defined(OPENSSL_THREADS) # error Thread support not enabled # endif #endif Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? Thanks. -- 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 -- 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: OpenSSL should define OPENSSL_THREADS?
On Tue, Feb 25, 2003 at 07:22:09AM -0600, Jacques A. Vidrine wrote: On Mon, Feb 24, 2003 at 09:58:21PM -0500, Craig Rodrigues wrote: Hi, I ran a cvsup of -CURRENT a few days ago. I have some code which assumes that OPENSSL_THREADS is defined if the OpenSSL version is greater than 0.9.7: Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? I think you may be right. OpenSSL 0.9.7's out-of-the box configure creates an opensslconf.h that would define OPENSSL_THREADS on FreeBSD. Mark supplied the opensslconf.h's that are used in the FreeBSD build ... let's see if this is intentional or not. [cc'd] These kind of macro changes can break backwards compatibility (OpenSSL's fault). If the intent is to minimize breakage of ports and such, I would not be opposed to do something like: #define OPENSSL_THREADS 1 #define THREADS OPENSSL_THREADS/** deprecated */ Would this work? -- 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
OpenSSL question for id_function()
Hi, I have a question about OpenSSL 0.9.7. On the following web page: http://www.openssl.org/docs/crypto/threads.html void CRYPTO_set_id_callback(unsigned long (*id_function)(void)); id_function(void) is a function that returns a thread ID. It is not needed on Windows nor on platforms where getpid() returns a different ID for each thread (most notably Linux). I have some third party C++ code which tries to implement this id_function as: return static_castunsigned long(pthread_self()); pthread_self() returns something of type pthread_t. This code works under Linux, because pthread_t is mapped to an integer value. However, on FreeBSD, pthread_t is a pointer to struct pthread, so this code does not compile: OpenSSLPluginI.cpp: In function `long unsigned int IceSSL::idFunction()': OpenSSLPluginI.cpp:153: invalid static_cast from type `pthread*' to type `long unsigned int' Is there a way to implement the id_function() for OpenSSL so that it works portably across FreeBSD and Linux? Thanks. -- 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: OpenSSL question for id_function()
On Thu, Feb 27, 2003 at 08:40:22AM -0800, John Polstra wrote: FreeBSD violates POSIX in this respect. Doh! I just looked at: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libpthread/include/pthread.h and it looks like OpenBSD does the same thing. Just wondering, is the FreeBSD KSE project implementing a POSIX compliant pthread_t? thread-related types: pthread_attr_t pthread_mutex_t pthread_mutexattr_t pthread_cond_t pthread_condattr_t pthread_once_t We got it right for pthread_key_t, though. :-) Cool. Sometimes standards are a pain in the neck, but my main interest in FreeBSD's POSIX compliance for threads is to be more and more of a drop-in replacement for Linux. :) So is OpenSSL stuff which requires id_function() broken on FreeBSD then? The C++-style work-around for my code is to do: return reinterpret_castunsigned long(pthread_self()); which is similar to Lev Walkin's suggestion for a C style cast. This gets things to compile, but seems like trying to fit a square peg in a round hole Thanks. -- 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
#warning must be protected by #if __GNUC__ in headers?
Hi, In sys/syslimits.h, I see: #if __GNUC__ #warning No user-serviceable parts inside. #endif Does the use of #warning need to be protected by #if __GNUC__ in FreeBSD header files? I am working on something similar for machine/limits.h. Some other header files check for __GNUC__ before using #warning, such as sys/ioctl.h, but sys/dkstat.h does not. Thanks. -- 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: Clock running double time
On Sat, Mar 15, 2003 at 03:51:09PM +, David Malone wrote: On Fri, Mar 14, 2003 at 11:14:51PM -0800, [EMAIL PROTECTED] wrote: Has anyone ever seen this? My clock is running double time, that is, each second it advances two seconds. Needless to say, ntpd can't sync up with any servers. You almost certainly have a motherboard with bad ACPI (probably for with a K6 processor). Try adding: kern.timecounter.hardware: TSC The correct line to add to /etc/sysctl.conf is: kern.timecounter.hardware=TSC to /etc/sysctl.conf and rebooting. This has been reported several times now, I wonder if we should add it to the FAQ? David. -- 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
Apache Portable Runtime testcase hangs -current
Hi,
I am using a system which I cvsup'd a few weeks ago:
FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Mon Feb 24 06:06:47 EST 2003 [EMAIL
PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL1 i386
I tried to compile the latest beta version of the Apache Portable Runtime
library. As part of the configure process, the attached testcase
is run. When the testcase runs, my machine locks up *HARD*.
- keyboard is totally unresponsive
- network connectivity to machine is lost and I cannot telnet or ssh into
the box
Does anyone have any idea what the problem could be?
How stable is -current to work with if I cvsup and rebuild?
Thanks.
--
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]
#if 0
dnl
dnl see if TCP_NODELAY setting is inherited from listening sockets
dnl
AC_DEFUN(APR_CHECK_TCP_NODELAY_INHERITED,[
AC_CACHE_CHECK(if TCP_NODELAY setting is inherited from listening sockets,
ac_cv_tcp_nodelay_inherited,[
AC_TRY_RUN( [
#endif /* if 0 */
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_SOCKET_H 1
#define HAVE_NETINET_IN_H 1
#define HAVE_NETINET_TCP_H 1
#define HAVE_SOCKLEN_T 1
#include stdio.h
#ifdef HAVE_SYS_TYPES_H
#include sys/types.h
#endif
#ifdef HAVE_SYS_SOCKET_H
#include sys/socket.h
#endif
#ifdef HAVE_NETINET_IN_H
#include netinet/in.h
#endif
#ifdef HAVE_NETINET_TCP_H
#include netinet/tcp.h
#endif
#ifndef HAVE_SOCKLEN_T
typedef int socklen_t;
#endif
int main(void) {
int listen_s, connected_s, client_s;
int listen_port, rc;
struct sockaddr_in sa;
socklen_t sa_len;
socklen_t option_len;
int option;
listen_s = socket(AF_INET, SOCK_STREAM, 0);
if (listen_s 0) {
perror(socket);
exit(1);
}
option = 1;
rc = setsockopt(listen_s, IPPROTO_TCP, TCP_NODELAY, option, sizeof option);
if (rc 0) {
perror(setsockopt TCP_NODELAY);
exit(1);
}
memset(sa, 0, sizeof sa);
sa.sin_family = AF_INET;
#ifdef BEOS
sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
#endif
/* leave port 0 to get ephemeral */
rc = bind(listen_s, (struct sockaddr *)sa, sizeof sa);
if (rc 0) {
perror(bind for ephemeral port);
exit(1);
}
/* find ephemeral port */
sa_len = sizeof(sa);
rc = getsockname(listen_s, (struct sockaddr *)sa, sa_len);
if (rc 0) {
perror(getsockname);
exit(1);
}
listen_port = sa.sin_port;
rc = listen(listen_s, 5);
if (rc 0) {
perror(listen);
exit(1);
}
client_s = socket(AF_INET, SOCK_STREAM, 0);
if (client_s 0) {
perror(socket);
exit(1);
}
memset(sa, 0, sizeof sa);
sa.sin_family = AF_INET;
sa.sin_port = listen_port;
#ifdef BEOS
sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
#endif
/* leave sin_addr all zeros to use loopback */
rc = connect(client_s, (struct sockaddr *)sa, sizeof sa);
if (rc 0) {
perror(connect);
exit(1);
}
sa_len = sizeof sa;
connected_s = accept(listen_s, (struct sockaddr *)sa, sa_len);
if (connected_s 0) {
perror(accept);
exit(1);
}
option_len = sizeof option;
rc = getsockopt(connected_s, IPPROTO_TCP, TCP_NODELAY, option, option_len);
if (rc 0) {
perror(getsockopt);
exit(1);
}
if (!option) {
fprintf(stderr, TCP_NODELAY is not set in the child.\n);
exit(1);
}
return 0;
}
#if 0
],[
ac_cv_tcp_nodelay_inherited=yes
],[
ac_cv_tcp_nodelay_inherited=no
],[
ac_cv_tcp_nodelay_inherited=yes
])])
if test $ac_cv_tcp_nodelay_inherited = yes; then
tcp_nodelay_inherited=1
else
tcp_nodelay_inherited=0
fi
])
#endif
Re: Apache Portable Runtime testcase hangs -current
On Sat, Mar 22, 2003 at 02:06:45AM +0300, Sergey A. Osokin wrote: -CURRENT still isn't for production, but more bugs fixed and now it more stable, then one month ago. Please update your system and try to reproduce your bug. OK, my bug is gone when I update -CURRENT to: FreeBSD rincewind 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Sat Mar 22 12:29:32 EST 2 003 Thanks. -- 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: Posix semaphore problem
On Sun, Mar 23, 2003 at 01:55:03AM -0800, Hongbo Li wrote: I just run a example program from the book unp2v2 written W.Richard Stevens. The program includes a call to sem_open. The compilation was ok. But when I run it on FreeBSD 5-current(recent),the system print Bad system call (core dumped). The program code : I get the same problem. Read the man page for sem(4) which explains the kernel option or kernel module that needs to be used for POSIX semaphores to work. However, I am not sure that this man page is entirely correct, since if I do: kldload sem I get No such file or directory. -- 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
sem.ko and vfs_aio.ko modules not built by default
Hi, I notice that with a recent -current, that the vfs_aio.ko and sem.ko modules do not seem to be built by default. In the past, this was not the case. Is it mandatory now to specify the kernel options: options VFS_AIO options P1003_1B_SEMAPHORES in order for these modules to be built? I thought that the modules would be built if no options were specified, and if those options were specified, the modules would be built into the kernel. -- 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: sem.ko and vfs_aio.ko modules not built by default
On Sun, Mar 23, 2003 at 11:14:28AM -0500, Robert Watson wrote: Sometimes, kernel modules will not be built by default because they are unstable or experimental features that have not been adequately deployed or tested. I know our AIO implementation has improved in quality a great deal over the last couple of years, but last I checked the psem implementation had very little practical deployment experience or testing. Who owns this code? I see that for /usr/src/sys/modules/Makefile: Revision 1.267 / (download) - annotate - [select for diffs], Mon Oct 7 04:08:07 2002 UTC (5 months, 2 weeks ago) by alfred Branch: MAIN Changes since 1.266: +0 -1 lines Diff to previous 1.266 (colored) Disconnect sem module from the build. Alfred, did you have a particular reason for removing the sem module from the build? It would be nice to have this in the -CURRENT build, at least so that people can try it out, report bugs, etc. Also, the sem(4) man page documents that you can kldload sem in order to get this supported. Probably what it will take is someone owning the code for a bit to develop a proper test suite, chase down nasty interactions, etc. I know similar Depending on what you are looking for, the Open POSIX Test Suite tests for POSIX semaphores: http://posixtest.sourceforge.net/ It's not the best test suite, but it is a start. (although not identical) code exists in Darwin -- would be interesting to ask Apple if they have a test suite for their psem implementation. I have done work with MacOS X recently...I would not look to Apple as a beacon for POSIX conformance, since they lack a lot of things. FreeBSD CURRENT seems to be far better with respect to POSIX conformance. -- 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
atomic_dec_and_test() in FreeBSD?
Hi, I asked this question on freebsd-smp...I'm asking here in case anyone has any ideas. I am the port maintainer for the Apache Portable Runtime (APR) library. APR makes use of a function in Linux called atomic_dec_and_test which is described here: http://kernelnewbies.org/documents/kdoc/kernel-api/r287.html Is there a way that I can use the existing machine/atomic.h FreeBSD macros to achieve the equivalent of atomic_dec_and_test? I couldn't figure out a way to do it. Thanks. -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-smp in the body of the message - End forwarded message - -- 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
Does uplcom(4) support Bencole 08303?
Hi, The uplcom(4) driver which supports USB-to-serial converters lists support for the following devices which use the Prolific PL-2303 chipset. Man page for uplcom driver: http://www.freebsd.org/cgi/cvsweb.cgi/src/share/man/man4/uplcom.4 Supported cables: ATEN UC-232A http://www.aten.com.tw/USB/USB_1/UC_232A.html BAFO BF-800 http://bafo.com/proddetail.cfm?ID=394 BAFO BF-810 http://bafo.com/proddetail.cfm?ID=395 ELECOM UC-SGT http://www.iogear.com/products/product.php?Item=GUC232A IOGEAR UC-232A http://www.iogear.com/products/product.php?Item=GUC232A I/O DATA USB-RSAQ http://www.iodata.co.jp/products/usb/usbrsaq.htm I/O DATA USB-RSAQ2 http://www.iodata.co.jp/products/network/usbrsaq2.htm PLANEX USB-RS232 URS-03 http://www.planex.net/product/usb/urs-03.htm My local computer shop has the following cable which looks similar: Bencole 08303: http://www.bencole.com/singleproduct.asp?search=usbpartnum=08303 Would the Bencole 08303 cable be supported by the uplcom(4) driver? I can't tell on the manufacturer's web site, nor on the packaging for the cable itself if it is based on the Prolific PL-2303 chipset or not. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3COM 3c509 eeprom failed to come ready
On Sat, Aug 24, 2002 at 07:12:02PM -0800, Beech Rintoul wrote: I'm not sure about an earlier -current, but I can tell you I'm running one of those cards with yesterday's -current with no problems. You didn't say which kernel you're running, but if it's GENERIC it has device ep uncommented. The only way I could get rid of that eeprom error was to re-run the setup util. Mine however wasn't hanging the boot it would go on and define the card as ep1. One thing you might try is putting the card in another slot and see if it will boot. Anyone else have this problem with -current? Hi, I am indeed having this problem with the GENERIC kernel that is included with the 20020818 -current snapshot. Here is some more information: - instead of booting the GENERIC kernel that gets installed with 20020818, if I boot with the kernel from the floppy disk that comes with 20020818, and then from the command-prompt specify the root filesystem as ufs:ad0s2a (which is where I installed -current), then the system boots up fine, and I have no problem with ep0, and in fact I can use ep0 successfully. So, there is something different between the GENERIC kernel and the kernel on the bootdisk in 20020818. Any idea what it could be? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Question about device.hints man page
Hi, Running: 5.0-CURRENT-20020818-JPSNAP I am reading the man page for device.hints, and I think I see an inconsistency: = A device hint line looks like: hint.driver.unit.keyword=value where driver is the name of a device driver, unit is the unit number, keyword is the keyword of the hint. The keyword may be: ... ... disabled is set to 1 to disable the device. The following example disables the ACPI driver hint.acpi.0.disable=1 = The example does not match the previous description. Should the keyword be disabled or disable? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem with pkg_add and tbz files
Hi, Running: FreeBSD 5.0-CURRENT-20020818-JPSNAP If I do: pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/All/lynx-ssl-2.8.4.1b_1.tbz I get the following error: pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/All/lynx-ssl-2.8.4.1b_1.tbz Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/All/lynx-ssl-2.8.4.1b_1.tbz... gzip: stdin: not in gzip format tar: Child died with signal 13 tar: Error exit delayed from previous errors Broken pipe However, it works if I do: fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/All/lynx-ssl-2.8.4.1b_1.tbz pkg_add lynx-ssl-2.8.4.1b_1.tbz Any ideas? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
