Re: Synaptics touchpad support
Mikko Työläjärvi wrote: Probably the best thing to do would be to disassemble the BIOS on your box, knowing the difference between the older driver's interface, and use the same techniques that were hidden from the older driver (and just built in instead). I doubt that would help. The mousepad can operate in two different modes, in the basic mode you get built-in tapping, but only two buttons, in the other mode you get more information (e.g. all buttons), but have to figure out the tap action yourself from the pressure delta over time. Live and learn; I thought it was in the BIOS. The behavior is documented by the manufacturer (synaptics.com.tw), who actually provides specs on-line (whee!). Do they document their algorithms, or do you have to invent your own? The disassembly idea was just to get the algorithm documented, not to steal the code, so if they document, then the problem is just as solved by that... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
On Mon, 10 Feb 2003 13:31:48 +1100 Tim Robbins [EMAIL PROTECTED] wrote: hashinit() can sleep, and I don't think it's safe to sleep here (msdosfs_hashget() and msdosfs_hashins()) with dehash_mtx and sometimes a vnode lock held. Doh! I should have noticed that. It might be better to initialise the table the first time an msdosfs filesystem is mounted. Sounds reasonable enough. So, maybe allocate it in msdosfs_mount or mountmsdosfs and deallocate it in msdosfs_unmount? If there isn't an easy way to tell if you're on the last mounted msdos filesystem, it might be better to just leave the deallocation in msdosfs_uninit. Is that basically what you're saying? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Best method to produce patches?
On Sun, Feb 09, 2003 at 04:33:41PM -0600, David Leimbach wrote the words in effect of: I am about to try to make some changes to FreeBSD current... Should I begin to use read-only CVS instead of CVSup for this work or is it possible to generate diffs based on CVSup'd sources? What is the recommend method to use for playing with the source? I already found a small change in libc that should probably get committed but I want to generate the patch properly for everyone's approval. Checkout the development(7) manual page, written by Matt Dillon. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ 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, 10 Feb 2003 22:48:31 -0500 Rahul Siddharthan [EMAIL PROTECTED] wrote: To the OP -- any speed improvement from gcc 3.2.1 to 3.2.2 would probably be marginal. If some particular port really bothers you with its slow performance, try recompiling (though it's unlikely to help), otherwise don't bother. If you really have a CPU intensive application you want to run on a P4 I suggest to use icc instead of gcc, as gcc does some things on a P4 which Intel has on the don't do that on a P4 list. Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2.2 import -- questions
Hmmm, fails to build for me: FreeBSD asus 5.0-RELEASE-p1 FreeBSD 5.0-RELEASE-p1 #3: Mon Feb 10 10:39:34 CET 2003 root@asus:/usr/obj/usr/src/sys/ASUS i386 gmake[3]: Entering directory `/usr/ports/lang/gcc32/work/build/gcc' for d in libgcc; do \ if [ -d $d ]; then true; else /bin/sh .././..//gcc-3.2.2/gcc/mkinstalldirs $d; fi; \ done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi gmake[3]: Leaving directory `/usr/ports/lang/gcc32/work/build/gcc' gmake[2]: Leaving directory `/usr/ports/lang/gcc32/work/build/gcc' gmake[1]: *** [configure-target-libstdc++-v3] Illegal instruction (core dumped) gmake[1]: Leaving directory `/usr/ports/lang/gcc32/work/build' gmake: *** [bootstrap] Error 2 *** Error code 2 Stop in /usr/ports/lang/gcc32. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade97111.0 make ** Fix the problem and try again. ** The following packages were not installed or upgraded (*:skipped / !:failed) ! lang/gcc32(missing header) Any ideas? /Paul Wesley Morgan wrote: The import of gcc 3.2.2 brings a question to mind... Many people have mentioned problems with SSE / SSE2 instructions, optimizer problems etc 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic with heavy io
While doing heavy IO (updating my p4 repo) on my laptop I got the following
panic. (I was running in X so both backtrace and dmesg are from the core
dump after reboot)
I'm wondering whether the ENOMEM's reported by GEOM point out that GEOM
has a problem or just tell us that the machine was out of memory and some
other subsystem failed.
By looking at the stack it seems that the NULL-pointer dereference is
going down pretty far.
The arguments in the lstat(frame #28) already seem bogus.
I've only seen this panic once, but it seems pretty serious.
Core dump still available to do post mortem.
Mark
--
ENOMEM 0xc3724300 on 0xc2412c80(ad0s1)
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x14
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01ef7f9
stack pointer = 0x10:0xce5c1740
frame pointer = 0x10:0xce5c1774
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 97588 (p4)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 4h11m54s
Dumping 255 MB
ata0: resetting devices ..
ENOMEM 0xc2422d80 on 0xc2412c80(ad0s1)
done
[CTRL-C to abort] 16[CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48 64 80 96 112 128
144 160 176 192 208 224 240
--
backtrace:
--
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc0233409 in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc0233663 in panic () at ../../../kern/kern_shutdown.c:531
#3 0xc0277892 in bwrite (bp=0xc7535a78) at ../../../kern/vfs_bio.c:798
#4 0xc0305643 in ffs_update (vp=0xc27ed11c, waitfor=0) at
../../../ufs/ffs/ffs_inode.c:121
#5 0xc031a0ff in ffs_fsync (ap=0xce5c1548) at ../../../ufs/ffs/ffs_vnops.c:315
#6 0xc03190c7 in ffs_sync (mp=0xc24c4000, waitfor=2, cred=0xc0c13e80, td=0xc0402be0)
at vnode_if.h:612
#7 0xc028d67b in sync (td=0xc0402be0, uap=0x0) at ../../../kern/vfs_syscalls.c:138
#8 0xc0232fec in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#9 0xc0233663 in panic () at ../../../kern/kern_shutdown.c:531
#10 0xc0381d12 in trap_fatal (frame=0xce5c1700, eva=0) at ../../../i386/i386/trap.c:844
#11 0xc03819f2 in trap_pfault (frame=0xce5c1700, usermode=0, eva=20) at
../../../i386/i386/trap.c:758
#12 0xc03814e0 in trap (frame=
{tf_fs = -832831464, tf_es = -1071710192, tf_ds = -951058416, tf_edi =
-1037023552, tf_esi = -951046744, tf_ebp = -832825484, tf_isp = -832825556, tf_ebx =
0, tf_edx = 5, tf_ecx = 0, tf_eax = -1740064768, tf_trapno = 12, tf_err = 2, tf_eip =
-1071712263, tf_cs = 8, tf_eflags = 66183, tf_esp = -951046744, tf_ss = -951046572})
at ../../../i386/i386/trap.c:445
#13 0xc0371bf8 in calltrap () at {standard input}:96
#14 0xc01edc00 in spec_xstrategy (vp=0xc23046c0, bp=0xc7502da8) at
../../../fs/specfs/spec_vnops.c:596
#15 0xc01edc7b in spec_specstrategy (ap=0x0) at ../../../fs/specfs/spec_vnops.c:633
#16 0xc01eca98 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:123
#17 0xc0326d2d in ufs_strategy (ap=0x0) at vnode_if.h:1114
#18 0xc0327908 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#19 0xc02775c6 in breadn (vp=0xc276211c, blkno=0, size=0, rablkno=0xc24bc7c4,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at vnode_if.h:1089
#20 0xc027749c in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0) at
../../../kern/vfs_bio.c:668
#21 0xc031666f in ffs_blkatoff (vp=0xc276211c, offset=1024, res=0x0, bpp=0xce5c1974)
at ../../../ufs/ffs/ffs_subr.c:92
#22 0xc03204b4 in ufs_lookup (ap=0xce5c1aa4) at ../../../ufs/ufs/ufs_lookup.c:248
#23 0xc0327908 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#24 0xc027d39c in vfs_cache_lookup (ap=0x0) at vnode_if.h:82
#25 0xc0327908 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2787
#26 0xc0281bb2 in lookup (ndp=0xce5c1c18) at vnode_if.h:52
#27 0xc02815bb in namei (ndp=0xce5c1c18) at ../../../kern/vfs_lookup.c:181
#28 0xc02906b2 in lstat (td=0xc278de00, uap=0xce5c1d10) at
../../../kern/vfs_syscalls.c:1700
#29 0xc038203a in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135254016, tf_esi = -1077940504,
tf_ebp = -1077940408, tf_isp = -832823948, tf_ebx = 0, tf_edx = 135149504, tf_ecx = 0,
tf_eax = 190, tf_trapno = 0, tf_err = 2, tf_eip = 134713404, tf_cs = 31, tf_eflags =
643, tf_esp = -1077940548, tf_ss = 47}) at ../../../i386/i386/trap.c:1033
#30 0xc0371c4d in Xint0x80_syscall () at {standard input}:138
-
--
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Re: panic with heavy io
In message [EMAIL PROTECTED], Mark Santcroos writes:
While doing heavy IO (updating my p4 repo) on my laptop I got the following
panic. (I was running in X so both backtrace and dmesg are from the core
dump after reboot)
I'm wondering whether the ENOMEM's reported by GEOM point out that GEOM
has a problem or just tell us that the machine was out of memory and some
other subsystem failed.
ENOMEM 0xc3724300 on 0xc2412c80(ad0s1)
The ENOMEM from GEOM is just a notification that an I/O request failed
due to lack of memory.
GEOM reacts to this by rescheduling the I/O request and entering a
rudimentary back-off mode where further I/O requests are paced so
that some of the outstanding ones get a chance to complete. The
current pacing is inspired a little bit by tcp slowstart btw.
By looking at the stack it seems that the NULL-pointer dereference is
going down pretty far.
The arguments in the lstat(frame #28) already seem bogus.
#10 0xc0381d12 in trap_fatal (frame=0xce5c1700, eva=0) at
../../../i386/i386/trap.c:844
This is the interesting trap I think, all the stuff above is noise.
#11 0xc03819f2 in trap_pfault (frame=0xce5c1700, usermode=0, eva=20) at
../../../i386/i386/trap.c:758
#12 0xc03814e0 in trap (frame=
{tf_fs = -832831464, tf_es = -1071710192, tf_ds = -951058416, tf_edi =
-1037023552, tf_esi = -951046744, tf_ebp = -832825484, tf_isp = -832825556, tf_ebx =
0, tf_edx = 5, tf_ecx = 0, tf_eax = -1740064768, tf_trapno = 12, tf_err = 2, tf_eip =
-1071712263, tf_cs = 8, tf_eflags = 66183, tf_esp
= -951046744, tf_ss = -951046572})
at ../../../i386/i386/trap.c:445
#13 0xc0371bf8 in calltrap () at {standard input}:96
#14 0xc01edc00 in spec_xstrategy (vp=0xc23046c0, bp=0xc7502da8) at
../../../fs/specfs/spec_vnops.c:596
This doesn't correspond to my sourcefile, but you should examine this one.
#15 0xc01edc7b in spec_specstrategy (ap=0x0) at ../../../fs/specfs/spec_vnops.c:633
This, I think is impossible, so I think we should assume that something
overwrite some memory and cleared out some bits which should have
survived.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic with heavy io
On Tue, Feb 11, 2003 at 12:21:19PM +0100, [EMAIL PROTECTED] wrote: #14 0xc01edc00 in spec_xstrategy (vp=0xc23046c0, bp=0xc7502da8) at ../../../fs/specfs/spec_vnops.c:596 This doesn't correspond to my sourcefile, but you should examine this one. Sorry, I should have do the backtrace on the source with the date of the kernel. It was running spec_vnops.c:1.194 596: DEV_STRATEGY(bp); I don't understand what you want me to examine there as the arguments are not usefull anymore (or are they?). #15 0xc01edc7b in spec_specstrategy (ap=0x0) at ../../../fs/specfs/spec_vnops.c:633 This, I think is impossible, so I think we should assume that something overwrite some memory and cleared out some bits which should have survived. That was my feeling too, it wouldn't have gotten so deep with NULL arguments. Haven't checked the code so it is only an assumption. Any idea's what to do now or what to do when I am able to reproduce it? Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Feb 11 03:11:14 PST 2003 -- Kernel build for GENERIC completed on Tue Feb 11 03:42:09 PST 2003 -- Kernel build for LINT started on Tue Feb 11 03:42:09 PST 2003 -- === vinum Makefile, line 4458: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with heavy io
In message [EMAIL PROTECTED], Mark Santcroos writes: 596: DEV_STRATEGY(bp); I don't understand what you want me to examine there as the arguments are not usefull anymore (or are they?). Well that line in my copy was not code, so I just wanted to see what your sources said. #15 0xc01edc7b in spec_specstrategy (ap=0x0) at ../../../fs/specfs/spec_vnops.c:633 This, I think is impossible, so I think we should assume that something overwrite some memory and cleared out some bits which should have survived. That was my feeling too, it wouldn't have gotten so deep with NULL arguments. Haven't checked the code so it is only an assumption. Any idea's what to do now or what to do when I am able to reproduce it? No idea at the moment. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sysinstall disk mess
Hi all, I have a ar0 mirror with 120GB diskspace. I don't know if this is a known problem yet, but I had done the following steps which lead to a failure situation: 1.) Created a partition 2.) Created some slices 3.) Started a installation, abouted it because no net-device was found. 4.) Restarted sysinstall 5.) Reinit of slices 6.) Install fails with cannot write to ar0 ... 7.) Writeing disklabel, or anything fails on the disk. Only reboot solves the problem. Is this a known problem ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Does bg fsck have problems with large filesystems?
Hello, He also has a login on the machine for testing but it's turned off at the moment I'll turn it on again if he asks. I've already sent him a mail. BTW, is a simple login (I mean, for example ssh) enough for this task? I would think at least a serial console access is needed... --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD 5.0 as SOHO firewall, gateway -- STABLE?
I have been watching this list and I have not seen much talk about the stability of FreeBSD 5.0 (RELENG_5_0) or of its use as a server? I did see that some people have upgraded their 4.7 servers to 5.0. Can anybody relate their experience with the OS release? I am looking for cases in particular for SOHO firewall/gateway environments. I have been waiting for Java and it looks as if this release just might offer the features I need. Thanks in advance, Tom Veldhouse To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: FreeBSD 5.0 as SOHO firewall, gateway -- STABLE?
Im running a CURRENT gateway at home with an iSDN line and a wireless card in hostap mode. Hasn't missed a beat since I replaced the previous (4.7) with DP2. Lawrence Farr EPC Direct Limited -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Thomas T. Veldhouse Sent: 11 February 2003 16:27 To: [EMAIL PROTECTED] Subject: FreeBSD 5.0 as SOHO firewall, gateway -- STABLE? I have been watching this list and I have not seen much talk about the stability of FreeBSD 5.0 (RELENG_5_0) or of its use as a server? I did see that some people have upgraded their 4.7 servers to 5.0. Can anybody relate their experience with the OS release? I am looking for cases in particular for SOHO firewall/gateway environments. I have been waiting for Java and it looks as if this release just might offer the features I need. Thanks in advance, Tom Veldhouse To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Link problems with BCM5703X Gigabit Ethernet on IBM X-Series 305
Hi all, I experience strange problems with this Gigabit card. It attaches correctly, but there is no activity until I set one time the promiscous mode, after that it works. So I wonder why this happens. Is something wrong with the filter ? Maybe we just have to turn on/off promiscous mode in bge_init(), so the card works as it should. Funny thing is that the link led doesn't work either ;) I guess we have to turn on some strange bit ;) I'll read the specs. If someone has a idea, I'd be happy. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
named chroot rcNG devfs
Hi, /etc/rc.d/named copies /dev with pax to the named chroot directory. This is obviously wrong with devfs, isn't it? Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Does bg fsck have problems with large filesystems?
On Tue, 11 Feb 2003, Attila Nagy wrote: Hello, He also has a login on the machine for testing but it's turned off at the moment I'll turn it on again if he asks. I've already sent him a mail. BTW, is a simple login (I mean, for example ssh) enough for this task? I would think at least a serial console access is needed... It's 10 minutes drive away from his place :-) --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 as SOHO firewall, gateway -- STABLE?
Thomas T. Veldhouse wrote: I have been watching this list and I have not seen much talk about the stability of FreeBSD 5.0 (RELENG_5_0) or of its use as a server? I did see that some people have upgraded their 4.7 servers to 5.0. Can anybody relate their experience with the OS release? I am looking for cases in particular for SOHO firewall/gateway environments. I have been waiting for Java and it looks as if this release just might offer the features I need. For various reasons, 5.0 is not recommended if you are not willing to put up with downtime and possible loss of data (as in, much more than usual). On the other hand, if you _are_ willing to reinstall everything now and then, you might use it. I have it installed on a firewall on a cluster, and I'm now trying to use it for bastion host, where it's mac features can be put to good use. A question you must ask yourself, though, is if 5.0 offers any feature you need that 4.7 doesn't. As far as I know, Java doesn't have any special benefits on 5.0, because the multithread library is still the same. I might be wrong, but... shrug As for firewalls, I don't really see a need. I can't think of any feature of use to a firewall that is present on 5.0 but not on 4.7. The reason I run 5.0 on one of my firewalls is so I can help catch bugs. Anything untowards happens and I can just turn it off. Moreover, I can reboot it with 4.7 if I really need (a separate disk). -- Daniel C. Sobral Gerência de Operações Divisão de Comunicação de Dados Coordenação de Segurança TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named chroot rcNG devfs
On Tue, Feb 11, 2003 at 06:59:31PM +0100, Alexander Leidinger wrote: Hi, /etc/rc.d/named copies /dev with pax to the named chroot directory. This is obviously wrong with devfs, isn't it? /etc/rc.d/named is quite bogus, especially when it comes to running bind chrooted. E.g. /dev/null isn't needed by bind8 at all (also checked with ktrace), not sure about bind9 though as it uses daemon(3) which tries to open it. On the other hand shared libraries are needed (or a port that supports linking bind statically...) and a copy of named itself if `ndc restart` shall work. Moreover, due to the hardcoded patch for copy- ing named-xfer it also doesn't work with the bind[8,9] ports, tweaking rc-scripts to run with ports is NetBSD-style but not as FreeBSD used to be... A designated option to make syslogd(8) pick up an additional /etc/namedb/var/run/log would also be nice. Mike Makonnen is aware of the brokenness at least I mailed him about it quite some time ago, before rcNG was turned on by default. FYI, a working bind8-chroot I use on 4-stable boxes looks like this: quad# ls -R /etc/namedb/ PROTO.localhost-v6.rev PROTO.localhost.rev etc localhost-v6.rev localhost.rev make-localhost master.conf named.conf named.conf.orig named.root slave slave.conf slave_xws.conf usr var /etc/namedb/etc: localtime /etc/namedb/slave: ... /etc/namedb/usr: lib libexec local /etc/namedb/usr/lib: libc.so.4 libm.so.2 libutil.so.3 /etc/namedb/usr/libexec: ld-elf.so.1 /etc/namedb/usr/local: libexec sbin /etc/namedb/usr/local/libexec: named-xfer /etc/namedb/usr/local/sbin: named /etc/namedb/var: db run /etc/namedb/var/db: named_dump.db /etc/namedb/var/run: log named.pid ndc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named chroot rcNG devfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-02-11 at 20:29:17 [EMAIL PROTECTED] wrote: mafd E.g. /dev/null isn't needed by bind8 at all (also checked with mafd ktrace), not sure about bind9 though as it uses daemon(3) which mafd tries to open it. On my 4.7-STABLE box, bind9 uses /dev/null and /dev/random. It probably dups stdin, stdout and stderr to /dev/null at startup, and it obviously uses /dev/random for random data. :) I presume this behaviour will be exactly the same on -CURRENT. Cheers, - -- Dimitry Andric [EMAIL PROTECTED] PGP Key: http://www.xs4all.nl/~dim/dim.asc Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3 Lbh whfg ivbyngrq gur QZPN naq jvyy or cebfrphgrq -BEGIN PGP SIGNATURE- Version: 6.5.8ckt http://www.ipgpp.com/ Comment: http://duncan.gn.apc.org/stoa_cover.htm iQA/AwUBPklGK7BeowouIJajEQLoZgCgh3/Pdz7cpQ2C0uWXSZJuVjObIO0AnjKB pJMDUoSn/QuzG+87MhgarKQg =4qh8 -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: appending files on smbfs
hello, tim. the patch you sent me did fix the problem stated, but now I've
noticed some interesting characteristics of the files that are created by a
unix machine on a share mounted by mount_smbfs, which itself resides on a
windows 200 machine.
I haven't looked into the details, but I'm using kdevelop to create a blank
c++ project with no lsm/GNU files, on that share. the problems come up in
configure with conftest and its corresponsing files. the configure script
fails with permission problems in deleteing the file. that unix machine
thinks conftest is a file, and the windows machine thinks it's a directory.
the windows machine can delete the directory, the unix machine can't delete
the file. hmm. There are also several similar errors with conftest.cc, etc.
Also, the configure script complains about not being able to find
Makefile.in, which is actually there. This could have something to do with
the conftest thing.
Copying files works fine from both directions, and I haven't seen any other
problems but this one. it probably has something to do with the way the
files are created, don't know. The symptoms are slightly worse with windows
98 machines.
The box is still a relatively clean 5.0-release, with only the patch below
applied to the smbfs source.
hope that helps, thanks!
-P
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Robbins
Sent: Monday, February 03, 2003 5:59 AM
To: Patrick Stinson
Cc: freebsd-current
Subject: Re: appending files on smbfs
On Thu, Jan 30, 2003 at 07:37:04PM -, Patrick Stinson wrote:
has anyone every had problems with appending existing files on volumes
mounted by smbfs or shlight?
$ echo sdsad hey
$ echo sdsad hey
cannot create hey: Permission denied
Please try this patch and let me know whether it solves the problem.
Index: src/sys/fs/smbfs/smbfs_vnops.c
===
RCS file: /x/freebsd/src/sys/fs/smbfs/smbfs_vnops.c,v
retrieving revision 1.28
diff -u -r1.28 smbfs_vnops.c
--- src/sys/fs/smbfs/smbfs_vnops.c 29 Jan 2003 13:41:52 - 1.28
+++ src/sys/fs/smbfs/smbfs_vnops.c 3 Feb 2003 05:51:45 -
@@ -139,10 +139,9 @@
} */ *ap;
{
struct vnode *vp = ap-a_vp;
- struct ucred *cred = ap-a_cred;
- u_int mode = ap-a_mode;
+ mode_t mode = ap-a_mode;
+ mode_t smbmode;
struct smbmount *smp = VTOSMBFS(vp);
- int error = 0;
SMBVDEBUG(\n);
if ((mode VWRITE) (vp-v_mount-mnt_flag MNT_RDONLY)) {
@@ -153,15 +152,10 @@
break;
}
}
- if (cred-cr_uid == 0)
- return 0;
- if (cred-cr_uid != smp-sm_args.uid) {
- mode = 3;
- if (!groupmember(smp-sm_args.gid, cred))
- mode = 3;
- }
- error = (((vp-v_type == VREG) ? smp-sm_args.file_mode :
smp-sm_args.dir_mode) mode) == mode ? 0 : EACCES;
- return error;
+ smbmode = vp-v_type == VREG ? smp-sm_args.file_mode :
+ smp-sm_args.dir_mode;
+ return (vaccess(vp-v_type, smbmode, smp-sm_args.uid,
+ smp-sm_args.gid, ap-a_mode, ap-a_cred, NULL));
}
/* ARGSUSED */
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Random System Lockups
Hi, Having recently cvsupped to the latest current I have been experiencing complete system freezes - by that I mean the system disappears, cannot be pinged, nothing can be done on the console etc. The are no error messages relatin to the crash in /var/log/messages and no weird application activity happens when it crashes - I am currently compiling the latest kernel to see if this resolves things. Any ideas/help much appreciated, Thanks Simon 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 Tue, Feb 11, 2003 at 10:14:58AM +0800, leafy wrote: lcms post-build tests now finishes correctly with pentium4 optimizations. And I have world with the p4 optimization with no ill-effact so far. No, it still fails. This is on a new world built with CPUTYPE?=p4 and then: 'portupgrade -f lcms' [snip] ranlib liblcms.a cd /usr/ports/graphics/lcms/work/lcms-1.09/src/../testbed /usr/bin/env CFLAGS=-O -pipe -march=pentium4 -I../include make -E CFLAGS test cc -O -pipe -march=pentium4 -I../include -c testcms.c cc -O -pipe -march=pentium4 -I../include testcms.o ../src/liblcms.a -o testcms - lm ./testcms little cms testbed. Ver 1.09 [build Feb 11 2003 23:06:14] Testing fixed point: 2.8848960205 = 2.8848 0.437499269828536 = 0.4374 Testing fixed scaling...pass. Testing curves join ...failed! *** Error code 1 Stop in /usr/ports/graphics/lcms/work/lcms-1.09/testbed. *** Error code 1 So, the lcms port still fails with CPUTYPE=p4 and there seems to be other issues still with CPUTYPE=p4 / SSE optimizations. Anders -- Anders Andersson anders at hack.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 as SOHO firewall, gateway -- STABLE?
I have been watching this list and I have not seen much talk about the stability of FreeBSD 5.0 (RELENG_5_0) or of its use as a server? I did see that some people have upgraded their 4.7 servers to 5.0. Can anybody relate their experience with the OS release? I am looking for cases in particular for SOHO firewall/gateway environments. I have been waiting for Java and it looks as if this release just might offer the features I need. http://www.freebsd.org/ says: New Technology Release: 5.0 Production Release: 4.7 If this isn't enough to convince you one way or other, ask yourself: What feature do your servers really need that only 5.0 has? Atte Peltomäki http://kameli.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Feb 11 13:10:27 PST 2003 -- Kernel build for GENERIC completed on Tue Feb 11 14:28:30 PST 2003 -- Kernel build for LINT started on Tue Feb 11 14:28:31 PST 2003 -- === vesa Makefile, line 5420: warning: duplicate script for target geom_bsd.o ignored Makefile, line 5423: warning: duplicate script for target geom_mbr.o ignored /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach': /local0/scratch/des/src/sys/dev/ie/if_ie.c:778: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type
Re: i386 tinderbox failure
/local0/scratch/des/src/sys/geom/bde/g_bde.c: In function `g_bde_config': /local0/scratch/des/src/sys/geom/bde/g_bde.c:251: structure has no member named `slicesize' /local0/scratch/des/src/sys/geom/bde/g_bde.c:252: structure has no member named `sliceoffset' My fault, already fixed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Fwd: panic: don't do that ?]
Hi!
I've sent this post to comp.unix.bsd.freebsd, and I've been told that I
should report the problem to this list, so...
Original Message
Hi folks!
I was trying to modularize the sound in my 5.0R machine, which has two
sound cards:
$ dmesg | grep pcm.:
pcm0: VIA VT82C686A port 0xb000-0xb003,0xb400-0xb403,0xb800-0xb8ff irq
9 at device 4.5 on pci0
pcm1: AudioPCI ES1373-B port 0xa000-0xa03f irq 9 at device 10.0 on pci0
In order for them to work properly as modules, the files
snd_{pcm,via82c686,es137x}.ko have to be loaded in the beginning AFAIK.
Or else they won't be recognized and will be given as PCI devices with
no driver attached.
Well, two issues:
1)
If they aren't loaded (I forgot them on the 1st try by mistake), the
kernel panics if I try to change hw.snd.maxautovchans (that odd bwrite:
buffer is not busy??? message again!). That shouldn't happen: if I
don't have any soundcards, this oid shouldn't _exist_ either!
2)
If they're loaded, an attempt to unload snd_via82c686.ko results in a
panic with the funny message in the subject. But: Aren't modules
supposed to be unloadable? What's the fun with modules then?
Any hints on solving this?
My attempt to load modules instead of the monolithic solution (which
always works) comes due to an odd behaviour of pcm0 (multiplexed with
hw.snd.pcm0.vchans=8) telling that some /dev/dsp{W,}0.[0-7] devices are
busy after their first usage. I wanted to address it by unloading the
affected module and loading it again, but... that'll panic the system.
Has someone had something similar?
Thanks in advance,
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
C conformance.
On Sun, 09 Feb 2003 19:43:38 +0100, Marcin Dalecki [EMAIL PROTECTED] said: Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. It should probably be a #error instead. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Feb 11 15:14:58 PST 2003 -- Kernel build for GENERIC completed on Tue Feb 11 15:49:44 PST 2003 -- Kernel build for LINT started on Tue Feb 11 15:49:45 PST 2003 -- === vinum Makefile, line 4458: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sio issue
Hi, lately, I end up in ddb when I connect my (unconnected) serial console cable to another machine. It's not critical, since c will continue fine, but it's annoying. Here's a trace: db trace siointr1(c635a,0,c0361fb6,671,df101ce8) at siointr1+0x3c4 siointr(c635a000) at siointr+0x35 Xfastintr4() at Xfastintr4+0xba --- interrupt, eip = 0xc0301942, esp = 0xdf101ce8, ebp = 0xdf101ce8 --- cpu_idle(c037a9a0,2,c0346fa9,59,0) at cpu_idle+0x22 idle_proc(0,df101d48,c0346e65,361,0) at idle_proc+0x4e fork_exit(c01a6440,0,df101d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf101d7c, ebp = 0 --- db c Could this commit be related at all? phk 2003/02/02 13:25:22 PST Modified files: sys/dev/sio sio.c Log: Set si_drv1 to our softc for all the six dev_t's we create for a serial port. Revision ChangesPath 1.383 +2 -0 src/sys/dev/sio/sio.c Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: C conformance.
* De: Garrett Wollman [EMAIL PROTECTED] [ Data: 2003-02-11 ] [ Subjecte: C conformance. ] On Sun, 09 Feb 2003 19:43:38 +0100, Marcin Dalecki [EMAIL PROTECTED] said: Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. It should probably be a #error instead. Yes, I discussed this with BDE shortly before the RELEASE freeze, and intended to investigate it afterwards, but lost my stomach for doing such stuff for quite some time. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: C conformance.
At 7:01 PM -0500 2/11/03, Garrett Wollman wrote: On Sun, 09 Feb 2003, Marcin Dalecki [EMAIL PROTECTED] said: Trying to use a compiler different from GCC I have found the folowing error: /usr/include/sys/syslimits.h, line 42: Error: [ISO 6.8]: Unknown preprocessing directive, '#warning'. It should probably be a #error instead. I remember running into this on some cross-platform program I dabble with. As near as I can tell, some compilers recognize '#warn', and others want '#warning'. And one of them would always complain about whichever one it did not like, even if you tried to hide it within a #if/#endif. This is annoying when you have something that you want to be a compile-time WARNING and not a compile-time error... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
WITNESS questions
Dear Hackers, Does WITNESS keeps track of particular mutex instance or just places where particular mutex type was acquired and released? Is it even possible to keep track of individual instance of the particular mutex type? Here is my problem. In my code (Bluetooth sockets layers) each socket/PCB has a mutex. The mutex type is the same. Also there are few global mutexes that used to protect sockets/PCBs list etc. Now when i do testing and both client and server reside on the same machine, i, sometimes, get lock order reversal messages. All messages can be put into two groups: : 1) Both mutexes are particular instances of the two different types. 2) One mutex is global and another is particular instance of the particular type. These messages are bugging me and i want to get to the bottom of this. How i can verify/convince myself that these messages are not problems? How should i deal with multiple mutex instances? Will WITNESS be able to help me here? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
error in nsdispatch.c
There is a potential bug in src/lib/libc/net/nsdispatch.c in the function const ns_dbt * _nsdbtget(const char * name). The static variable static time_t confmod; is not initialized to anything. It may have some random value the first time this function is called and if you look at the program logic its the first value tested as well and it controls a lot of deallocation via free. Bug? I have been having trouble writing to standards... sending to current. Dave 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 Tue, Feb 11, 2003 at 11:11:39PM +0100, Anders Andersson wrote: Testing curves join ...failed! *** Error code 1 Stop in /usr/ports/graphics/lcms/work/lcms-1.09/testbed. *** Error code 1 So, the lcms port still fails with CPUTYPE=p4 and there seems to be other issues still with CPUTYPE=p4 / SSE optimizations. Anders Yes I noticed it this morning too. The funny thing is that. If you use a non-P4 optmized GCC to compile lcms with P4 opt, then it passes the test. But with a P4 opted GCC, it borks. Looks like P4 opted GCC itself is bogus. Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: error in nsdispatch.c
hi, there! On Tue, Feb 11, 2003 at 07:37:31PM -0600, David Leimbach wrote: There is a potential bug in src/lib/libc/net/nsdispatch.c in the function const ns_dbt * _nsdbtget(const char * name). The static variable static time_t confmod; is not initialized to anything. It may have some random value the first time this function is called and if you look at the program logic its the first value tested as well and it controls a lot of deallocation via free. Bug? no. static variables are initialized with all-zeroes. /fjoe 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 Wed, 12 Feb 2003, leafy wrote: Anders Yes I noticed it this morning too. The funny thing is that. If you use a non-P4 optmized GCC to compile lcms with P4 opt, then it passes the test. But with a P4 opted GCC, it borks. Looks like P4 opted GCC itself is bogus. That's odd. Does the FreeBSD build skill the stage2 compiler rebuild? I thought the gcc build process tested itself against itself. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: error in nsdispatch.c
Bug? no. static variables are initialized with all-zeroes. Groovy... /me goes to buy electronic ANSI C standard :P Dave /fjoe 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 Tue, Feb 11, 2003 at 09:03:28PM -0500, Wesley Morgan wrote: The funny thing is that. If you use a non-P4 optmized GCC to compile lcms with P4 opt, then it passes the test. But with a P4 opted GCC, it borks. Looks like P4 opted GCC itself is bogus. That's odd. Does the FreeBSD build skill the stage2 compiler rebuild? I thought the gcc build process tested itself against itself. Perhaps it missed some floating point test? which could be utilized by lcms. Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2.2 import -- questions
On Tue, Feb 11, 2003 at 09:03:28PM -0500, Wesley Morgan wrote: On Wed, 12 Feb 2003, leafy wrote: Anders Yes I noticed it this morning too. The funny thing is that. If you use a non-P4 optmized GCC to compile lcms with P4 opt, then it passes the test. But with a P4 opted GCC, it borks. Looks like P4 opted GCC itself is bogus. That's odd. Does the FreeBSD build skill the stage2 compiler rebuild? I thought the gcc build process tested itself against itself. From personal observations, I would not use -march=p4 with gcc 3.2.x on my FreeBSD system. You're just asking for trouble. -- Steve 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 Tue, Feb 11, 2003 at 09:03:28PM -0500, Wesley Morgan wrote: On Wed, 12 Feb 2003, leafy wrote: Anders Yes I noticed it this morning too. The funny thing is that. If you use a non-P4 optmized GCC to compile lcms with P4 opt, then it passes the test. But with a P4 opted GCC, it borks. Looks like P4 opted GCC itself is bogus. That's odd. Does the FreeBSD build skill the stage2 compiler rebuild? I thought the gcc build process tested itself against itself. FreeBSD doesn't use the gcc build process.. Kris msg52242/pgp0.pgp Description: PGP signature
gbde
I keep ketting errors when trying to make my root filesystem encrypted: bash-2.05b# gbde init /dev/ad0s2a gbde: /dev/ad0s2a: No such file or directory bash-2.05b# bash-2.05b# ls /dev/ad0* /dev/ad0/dev/ad0s2 /dev/ad0s2b /dev/ad0s2d /dev/ad0s2f /dev/ad0s1 /dev/ad0s2a /dev/ad0s2c /dev/ad0s2e bash-2.05b# What am I doing wrong? I followed the man pages (gbde(4) and gbde(8)) exactly... bash-2.05b# uname -a FreeBSD shawns.lan 5.0-RELEASE FreeBSD 5.0-RELEASE #1: Tue Feb 11 18:17:04 MST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LATERALUS i386 bash-2.05b# To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
