Re: sporadic disk syncing failures when shutting down
On 13 Jul, Jeff Walters wrote: On Saturday 12 July 2003 11:24 pm, Sean Kelly wrote: syncing disks, buffers remaining... 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 giving up on 54 buffers Uptime: 6m42s Terminate ACPI Rebooting... Each time this has happened, fsck finds and nukes a bunch of empty directories. The last time this happened, the /etc/rc.d/yp* files that mergmaster updated were missing after the reboot and fsck had done its work. Nothing has ever shown up in lost+found. Has anyone else seen this? I have seen this a lot, but not as much lately. Sadly, I don't have any more data than you on why it happens. I've seen it give up on a rather frighteningly large number of buffers before, though... I hate to even mentioned such an unscientific observation where I made multiple changes at once, but I'll provide a data point. I also saw this problem crop up at the same time as I tried the SCHED_ULE scheduler a couple of months ago. I re-cvsup'ed CURRENT and switched back to SCHED_4BSD and it went away. I haven't gotten around to trying anything other than SCHED_4BSD. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia driver stability?
On 2003-07-12 21:22 +, Will Saxon wrote: Well I have to say that about 30min after I wrote in originally, I started having problems. X locked up, but I could switch around to different vty's and also ctrl-alt-bksp out of X. However, when I tried to restart X my machine locked up entirely. I am wondering though if it is all the nvidia driver's fault - while my machine has been stable through installation of the nvidia driver it is now being screwy even after removal of the driver. It's basically locking hard after about 5-10 minutes every time I use it, and sometimes I cannot even log in. I guess I don't know what to think. -Will If you have a kernel.good around boot that, and try fiddling around. There are a few sysctls you can play with (trying to use the NVIDIA AGP driver may be a good idea too). I have had a few really odd bug reports, but none that match this type of behaviour. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-07-13 07:14:14 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-07-13 07:14:14 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-13 07:19:12 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Building an up-to-date make(1) Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] objcopy -S -O binary boot0.5.out boot0.5.bin cat boot0.5.bin /dev/zero | dd of=boot0.5 bs=1 count=7168 7168+0 records in 7168+0 records out 7168 bytes transferred in 0.222433 secs (32225 bytes/sec) === sys/boot/pc98/boot2 cc -elf -Os -mrtd -ffreestanding -fno-builtin -fno-guess-branch-probability -D_KERNEL -DPC98 -DBOOTWAIT=5000 -DTIMEOUT= -DBOOTSEG=0x1000 -DBOOTSTACK=0xFFF0 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2/../../.. -I. -DCOMCONSOLE=0x238 -DCOMCONSOLE_CLK=16 -DCOMCONSOLE_MODE=0x0c -DCOMSPEED=9600 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -ffreestanding -mpreferred-stack-boundary=2-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2/start.S /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2/start.S:474:16: pasting disklabel and : does not give a valid preprocessing token *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/boot. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-07-13 08:13:06 - /usr/bin/make returned exit code 1 TB --- 2003-07-13 08:13:06 - ERROR: failed to build world TB --- 2003-07-13 08:13:06 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenPAM dynamic module loading not working ?
On Thu, Jul 10, 2003 at 09:26:42AM +0100, Dominic Marks wrote: On 10/07/2003 08:46, Dag-Erling Sm?rgrav wrote: Dominic Marks [EMAIL PROTECTED] writes: Jul 7 22:10:40 bacon dovecot-auth: in openpam_load_module(): no pam_pgsql.so found Jul 7 22:10:40 bacon dovecot-auth: PAM: pam_start(example) failed: failed to load module The module probably lacks dependency information. I'll try to figure it out later today. I rebuilt OpenPAM with debugging info and looked at what was happening. It turned out that it was not able to resolve pam_get_pass from the module pam_get_pass() doesn't exist in -CURRENT, it should use pam_get_authtok() instead. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia driver stability?
That may have done it. Now that I recompiled nvidia-driver only WITH_NVIDIA_HACKS, doing glxinfo several times no longer wreaks havoc. Since something seems to be screwy with my network driver (rtl8139) when the kernel is compiled without optimizations, I recompiled with them and so far all is well. At the moment, I have my AGP rate knocked down from 4x to 2x in BIOS. If all continues to go well, I'll bump it back up and report what I find. E From: Munish Chopra [EMAIL PROTECTED] On 2003-07-12 14:46 +, Evan Dower wrote: After following all the instructions at http://www.soulwax.net/nvidia/faq.shtml _very_ carefully and compiling nvidia-driver WITH_FREEBSD_AGP, WITH_NVIDIA_HACKS, and with FORCE_AGP_RATE, my system was dramatically slower and substantially _less_ stable. (I had to switch to another computer to write this email). Interestingly, whenever I compile the kernel without optimizations, network activity becomes _very_ slow. E aka Evan Dower Undergraduate, Computer Science University of Washington Did you try using the NVIDIA AGP interface? The majority of mail I get indicates that the NVIDIA AGP stuff works better than the FreeBSD one. I'm not sure about your network problems, perhaps you should look at the driver for clues. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia driver stability?
On 2003-07-13 01:47 +, Evan Dower wrote: That may have done it. Now that I recompiled nvidia-driver only WITH_NVIDIA_HACKS, doing glxinfo several times no longer wreaks havoc. Since something seems to be screwy with my network driver (rtl8139) when the kernel is compiled without optimizations, I recompiled with them and so far all is well. At the moment, I have my AGP rate knocked down from 4x to 2x in BIOS. If all continues to go well, I'll bump it back up and report what I find. E Bill Paul recently checked in some changes to the rtl8139 code, you might want to check the CVS logs for that. Bumping up the AGP rate should be safe in 99% of cases. Good luck. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenPAM dynamic module loading not working ?
On 13/07/2003 10:43, Dag-Erling Smorgrav wrote: On Thu, Jul 10, 2003 at 09:26:42AM +0100, Dominic Marks wrote: On 10/07/2003 08:46, Dag-Erling Sm?rgrav wrote: Dominic Marks [EMAIL PROTECTED] writes: Jul 7 22:10:40 bacon dovecot-auth: in openpam_load_module(): no pam_pgsql.so found Jul 7 22:10:40 bacon dovecot-auth: PAM: pam_start(example) failed: failed to load module The module probably lacks dependency information. I'll try to figure it out later today. I rebuilt OpenPAM with debugging info and looked at what was happening. It turned out that it was not able to resolve pam_get_pass from the module pam_get_pass() doesn't exist in -CURRENT, it should use pam_get_authtok() instead. Ok, can you explain why it was trying to find the pam_get_pass symbol which was removed from the module (by a port patch) and not mentioned in OpenPAM? I assume OpenPAM is looking in the module, catching a stray reference to it and then slipping up from here? DES -- Dag-Erling Sm?rgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Thanks, -- Dominic dom at cus.org.uk dominic.marks at npl.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2412] PATCH - acpi 0619
On Fri, 11 Jul 2003 23:07:08 -0700, Nate Lawson wrote: | I've prepared a new diff of the 0619 drop of acpica along with the | appropriate changes to support code: | | * Use ACPI_BUFFER as the type for AcpiGetObjectInfo | * Remove AcpiEnableEvent/AcpiClearEvent for ACPI_EVENT_FIXED (power/sleep | buttons) as they are no longer needed | * Change calls to use the new GPE functions | * Add AcpiOs*Lock functions | * Import 0619 + local FreeBSD changes + dsmthdat.c patch (from | [EMAIL PROTECTED]) | | Please test and let me know how this works for you. It works fine on my | IBM T23. | | http://www.root.org/~nate/freebsd/acpi-0619.diff.gz I tested this patch on IBM ThinkPad A22e, but repeated messages ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER appeared again (like as 2-3 weeks ago). It seems that the change of from version 1.1.1.16 to 1.1.1.17 in src/sys/contrib/dev/acpica/hwregs.c is overwritten by this patch (so partially back to the status of 1.1.1.16). -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1 RELEASE bugs?
Hi! I was installing 5.1 yesterday, i and think i discoverd some small bugs. COPTFLAGS is not respected when buling modules, just the kernel. when builings modules it seems to like CFLAGS better. With 'CPUTYPE=p4' and '-march=pentium4' in make.conf, when compiling something it seems to use 'cc -march=pentium3 -march=pentium4 blahblah ls.c' the word 'pentium3' dont exist in make.conf. (yes, the machine is a Pentium4) -- Med vennlig hilsen / Best regards Christer Gundersen / dizzy tun3Z http://dtz.cjb.net - http://carebears.mine.nu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 RELEASE bugs?
Subject: 5.1 RELEASE bugs?, On Sun, 13 Jul 2003 12:05:20 +0200 (CEST), Christer Gundersen wrote: the word 'pentium3' dont exist in make.conf. see /usr/src/share/mk/bsd.cpu.mk -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenPAM dynamic module loading not working ?
On Sun, Jul 13, 2003 at 10:11:09AM +0100, Dominic Marks wrote: Ok, can you explain why it was trying to find the pam_get_pass symbol which was removed from the module (by a port patch) and not mentioned in OpenPAM? I assume OpenPAM is looking in the module, catching a stray reference to it and then slipping up from here? The patch doesn't remove references to pam_get_pass(); it removes the port's own implementation of pam_get_pass() under the assumption that libpam provides one (which it no longer does). I'm afraid it's simply not going to work on -CURRENT without heavy modification... It relies too heavily on old glue code which has been removed. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFW and/or rc rule parsing not working since today's cvsup
I normally sync to current once a week and have just done it today: FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Jul 13 12:24:40 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO i386 The problem is though that it looks like IPFW or RC has changed how it works. I'm not sure if this is intentional or not though. If it is intentional then I think it is a violation of POLA. The problem I have is this. In rc.conf I have the following: firewall_enable=YES firewall_script=/etc/rc.firewall firewall_type=/etc/ipfw.conf And in /etc/ipfw.conf I have sets of rules one line at a time like: add 00010 divert natd all from any to any via xl0 add 00120 allow tcp from any to any 80 via xl0 etc. This has always worked for me ever since I first started using ipfw on fbsd 4.1 and has always worked on current until today's cvsup. Now though no rules get loaded. If I try what I have always done in the past which is ipfw -q flush ipfw /etc/ipfw.conf then it tells me: usage: ipfw [options] do ipfw -h or see ipfw manpage for details Whereas before this week this worked perfectly. The /etc/rc.firewall still says that you can set a filename for the firewall_type so I assume this should still work as in fact just broken rather than a POLA. I definatly mergemaster'd everything that had changed properly. In fact I have even just run it again in case I missed something and everything is up to date. Any comments? Regards, Matt. -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW and/or rc rule parsing not working since today's cvsup
Matt said: I normally sync to current once a week and have just done it today: FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Jul 13 12:24:40 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO i386 The problem is though that it looks like IPFW or RC has changed how it works. I'm not sure if this is intentional or not though. If it is intentional then I think it is a violation of POLA. The problem I have is this. In rc.conf I have the following: firewall_enable=YES firewall_script=/etc/rc.firewall firewall_type=/etc/ipfw.conf And in /etc/ipfw.conf I have sets of rules one line at a time like: add 00010 divert natd all from any to any via xl0 add 00120 allow tcp from any to any 80 via xl0 etc. This has always worked for me ever since I first started using ipfw on fbsd 4.1 and has always worked on current until today's cvsup. Now though no rules get loaded. If I try what I have always done in the past which is ipfw -q flush ipfw /etc/ipfw.conf then it tells me: usage: ipfw [options] do ipfw -h or see ipfw manpage for details Whereas before this week this worked perfectly. The /etc/rc.firewall still says that you can set a filename for the firewall_type so I assume this should still work as in fact just broken rather than a POLA. I definatly mergemaster'd everything that had changed properly. In fact I have even just run it again in case I missed something and everything is up to date. Any comments? Regards, Matt. -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. I have noticed that there have been a large number of ipfw commits this week in the cvs logs and so I believe this could be related. I am therefore emailing this direct to luigi as hopefully he can help :) -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LDT entries and WINE and Threads..
On Tue, 8 Jul 2003, Julian Elischer wrote: I'm looking at this and I think that my interpretation is that WINE, under FreeBSD, blindly allocates LDT entries starting at location 17, without looking to see if they are in use already.. Do you think that's a bug in Wine, or just a Linuxism? In both cases, I suggest you contact the Wine developers at [EMAIL PROTECTED] who have been relatively responsive wrt. portability improvements (and dozens of patches I submitted to them to keep Wine building and running on FreeBSD). It seems to me that we could better serve the applications by having a differnt API for setting LDTs, and that the kernel should keep track of which is free and which is not. I agree that, even if there is a bug/Linuxism in Wine, we are better off by remaining as closely to the behavior of Linux in cases like this, for in the end, if something breaks on FreeBSD while it works on GNU/Linux, it makes little difference to the user _why_ it broke. comments? Thanks for your efforts in this area! ;-) As emulators/wine maintainer and regular upstream contributor, I'd appreciate being Cc:ed on relevant messages on this (not the least because user support requests often arrive in my inbox). Gerald (@FreeBSD.org) -- Gerald Jerry [EMAIL PROTECTED] http://www.pfeifer.com/gerald/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW and/or rc rule parsing not working since today's cvsup
On Sun, 13 Jul 2003 13:17:36 +0100 (BST), Matt wrote:
| The problem I have is this. In rc.conf I have the following:
|
| firewall_enable=YES
| firewall_script=/etc/rc.firewall
| firewall_type=/etc/ipfw.conf
|
| And in /etc/ipfw.conf I have sets of rules one line at a time like:
|
| add 00010 divert natd all from any to any via xl0
| add 00120 allow tcp from any to any 80 via xl0
|
| etc.
|
| This has always worked for me ever since I first started using ipfw on
| fbsd 4.1 and has always worked on current until today's cvsup. Now though
| no rules get loaded.
|
| If I try what I have always done in the past which is ipfw -q flush
| ipfw /etc/ipfw.conf then it tells me:
|
| usage: ipfw [options]
| do ipfw -h or see ipfw manpage for details
If your /etc/ipfw.conf has blank line(s),
then you maybe met the same situation as me.
The mail that I posted to [EMAIL PROTECTED] is:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=65503+0+archive/2003/freebsd-ipfw/20030713.freebsd-ipfw
There are 3 cases for calling show_usage() in ipfw2.c.
My case is caught by if (l == 0) in ipfw_main().
The other cases are caught by if (ac == 0)
and by while ((ch = getopt(ac, av, acdefhnNqs:STtv)) != -1)
switch (ch) {
...
default:.
--
[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
In message: [EMAIL PROTECTED] Craig Rodrigues [EMAIL PROTECTED] writes: : 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. keep in mind that on linux the -wno-system-headers is default, while it isn't default on freebsd, which is why we see it and you don't there... Warner ___ [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
In message: [EMAIL PROTECTED] Alexander Kabaev [EMAIL PROTECTED] writes: : Short of fixing offending files in FSF libstdc++ or turning warning : suppression back on for standard C++ include files selectively, I have : no suggestion. In the past I know that FSF has accepted patches back, so maybe the right thing to do is: o figure out the fix(es) that we need. o submit them to fsf o if they accpet them, then we can import them on the vendor branch or disable warnings in the system headers if not The warnings are quite annoying, and we'll get a lot of grief from the growing number of large c++ ports. I'd be happy to come up with a patch. Warner ___ [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 Saturday, July 12, 2003, at 11:05PM, 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.
This is a good policy in general, however, one could easily argue that
what
is trying to be determined with signedness and such being
less-than-compared
to 0 isn't really a big deal and possibly the only way to implement this
numeric_limitsT::digits thing without any type introspection which
C++ currently
lacks.
The following would work for example in a template function:
template typname T
void foo(T const f)
{
if (numeric_limitsT::digits % 2)
//type is signed
else
//type is unsigned
}
However to implement digits we have that nasty macro that makes the
comparison
which is meaningless for unsigned types of 0.
This is probably a perfect example of where the C++ standards committee
folks should
be queried about the best way to implement numeric_limitsT::digits.
Some of them
have had no trouble pointing out that C99's tgmath.h header cannot be
implemented in
pure standard C99. This may also be true of numeric_limitsT::digits.
I am going to the newsgroups... My old college advisor is/was a
moderator on
comp.lang.c++.moderated and he may just know the answer :).
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.
I'd rather we fix the problem in gcc but this extra verbosity when
there is nothing
wrong with user code also seems incorrect. I think the gcc developers
should have a
separate command line option for internal headers don't you?
--
Alexander Kabaev
___
[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 Sunday, July 13, 2003, at 8:13AM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Craig Rodrigues [EMAIL PROTECTED] writes: : 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. keep in mind that on linux the -wno-system-headers is default, while it isn't default on freebsd, which is why we see it and you don't there... Ah, excellent... this is exactly what I was looking for. :) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
4.8 Kernel Compiling Error
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include -I/ usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/iir/../../dev/iir/iir.c /usr/src/sys/modules/iir/../../dev/iir/iir_ctrl.c /usr/src/sys/modules/iir/../../dev/iir/iir_pci.c /usr/src/sys/modules/iir/../../dev/iir/iir.c:56: stddef.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/iir. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/MYKERNEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I have used src from the cdrom and from FTP1, regardless I am unable to compile the kernel. Any assistance would be appreciated Thank you. ___ [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:43:31AM -0400, Craig Rodrigues wrote: 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); Perhaps this would work: #define __glibcpp_signed(T) (!((T)(-1) 0)) I have tried this with GCC 3.2 (5.1-BETA i386, -W -Wall), and a plain C program (not C++). cc and c++ do the same. The old macro gives the warning about comparing signed types, but the new one does not. They both work for int, u_int, unsigned int and char. The compiler moans about (T)(-1) = 0 as well. Is the assumption that (unsigned type)(-1) is never zero valid? If it's not, try (!((T)(-1) 0 || (T)(-1) == 0)). GCC does not seem to moan about that, even though it's exactly the same as using =. Jilles Tjoelker ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release of CURRENT on 4.7 box
Bruce Evans wrote:
On Sat, 12 Jul 2003, Tim Kientzle wrote:
In particular, newvers.sh is being run with the
current directory being ${.OBJDIR}, and ${.OBJDIR}
doesn't contain a Makefile, ...
... `make -V FOO' doesn't require a Makefile in -current. ...
A-HA!
I don't know the right way to fix this ...
I think splitting it or making it exit after just setting variables
in the userland case is the right fix. ...
I think you're right, but don't see a very simple way to make that
work, especially given the surprising number of places
that newvers.sh is used.
However, the following one-line patch does work; it
simply creates enough of a Makefile to silence make's
warnings. Needs testing under -CURRENT, but I'm
pretty confident it will work there as well.
If someone could test this under -CURRENT and commit
it, those of us doing 4.x-CURRENT cross-builds would
greatly appreciate it.
Tim
Index: include/Makefile
===
RCS file: /usr/cvs/FreeBSD-CVS/src/include/Makefile,v
retrieving revision 1.204
diff -u -r1.204 Makefile
--- include/Makefile4 Jul 2003 19:54:06 - 1.204
+++ include/Makefile13 Jul 2003 05:43:33 -
@@ -51,11 +51,17 @@
INCS+= osreldate.h
+# The use of 'newvers.sh' here is kind of bogus, because
+# it creates some additional files and does a few other odd
+# things. The 'touch Makefile' here allows newvers.sh to
+# run on 4.x, whose 'make' requires a Makefile for '-V KERN_IDENT'
+#
osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh \
${.CURDIR}/../sys/sys/param.h \
${.CURDIR}/Makefile
@${ECHO} creating osreldate.h from newvers.sh
@setvar PARAMFILE ${.CURDIR}/../sys/sys/param.h; \
+ echo default: Makefile; \
. ${.CURDIR}/../sys/conf/newvers.sh;\
echo $$COPYRIGHT osreldate.h; \
echo #ifdef _KERNEL osreldate.h; \
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build error building cvs doc?
John Reynolds wrote: [ On Sunday, July 13, Barney Wolff wrote: ] Me too. I'm about to try re-cvsupping, in case I caught some update in the middle. Somebody else asked if I was doing a make -jN buildworld where N 1 and I was. So, I just now did a buildworld with one process and it finished just fine. Strange. The only other thing in the original logfile shows: make: don't know how to make /usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse.o. Stop *** Error code 2 1 error So, perhaps something related to the above is not -jN safe. Yes, /rescue is known to be not -jN safe I've been trying to puzzle out exactly why and how to fix, but have yet to come up with anything. Suggestions/comments/advice welcome. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
Date: Sat, 12 Jul 2003 13:39:30 -0700 From: Marcel Moolenaar [EMAIL PROTECTED] On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: o We still have the Alpha gdb -k bug moved over from the 5.1 todo list to the 5.2 todo list. I think this is just a bug fix. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? This would involve a copyright assignment, which could prove to be a major obstacle. The copyright of our kgdb support is already the FSF. See /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c I'll have to find out whether the paperwork is actually there. The current support for debuggung libc_r-based threading is also not present in the FSF tree. So the question raised above applies here too. It looks to me that it can be contributed back. That would be great. I'm not really familiar with KSE, but AFAIK the kernel interfaces for debugging KSE's aren't there yet. I think that's mostly due to a knowledge gap. We just need people who can bridge between gdb and FreeBSD. Someone like you :-) o gdb(1) has created a 6.x branch, so it's likely that a new release is in the pipeline (within 6 months?). Upgrading to 5.3 may make a future upgrade easier due to smaller diffs and refreshed know-how. GDB 6.0 will defenitely be released before the end of the year :-). We're aiming at the end of August, but it will probably be somewhere in September. Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2 scheduling wise. Do we need a binutils update? We now have 2.13.2. Probably, yes. FSF GDB releases use a libbfd that's basically a snapshot taken at the point where the release branch was cut. You folks seem to try to get away with using libbfd from binutils. This usually works as long as the GDB and binutils releases used are not too far apart, so it's more likely that this works if binutils is updated. Actually, I think you'll need binutils 2.14 anyway for TLS. A1 If having support for amd64 is a major reason for doing a new import of GDB, importing the upcoming GDB 6.0 would make more sense to me. No ia64 is the major reason :-) Hmm. I think I just crashed pluto1 trying to get it to run the GDB testsuite on a not-yet-fully-functional GDB port. Currently RSE is giving me some headaches. A2 I'm volunteering to help out here. Cool, thanks. Shall we just create a p4 branch and start hacking? Oh dear, do I need to learn another version control system? Anyway, this can probably wait. I'll be on vacation from next tuesday until August 10, and I still have to do some work on the upstream GDB sources before I can start thinking about integrating things in the FreeBSD source tree. The GDB sparc target has suffered some bit rot, up to the point where it is hardly usable. better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. We probably need to talk then, because the ptrace interface needs to be fleshed out and I planned to do that while porting gdb. Probably. The current layout of `struct reg' and `struct fpreg' is a bit ... messy. Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release of CURRENT on 4.7 box
On Sun, 13 Jul 2003, Tim Kientzle wrote:
Bruce Evans wrote:
I think splitting it or making it exit after just setting variables
in the userland case is the right fix. ...
[it == newvers.sh]
I think you're right, but don't see a very simple way to make that
work, especially given the surprising number of places
that newvers.sh is used.
I think there aren't so many -- only kernel Makefiles and
src/include/Makefile.
There seems to be a simple way due to bitrot. $1 in newvers.sh is
not set when newvers.sh is invoked from src/include/Makefile, but
it seems to always be set when newvers.sh is invoked from kernel
Makefiles, due to garbage in the latter. The garbage is now
centralized in sys/conf/kern.post.mk:
sh $S/conf/newvers.sh ${KERN_IDENT}
^
This passes an unused variable to newvers.sh. Passing and use of
this variable was removed in 4.4BSD-Lite1, but FreeBSD's kernel
Makefiles are based on Net/2 and haven't caught up with this change
yet, while FreeBSD's newvers.sh is based on the Lite1 so it has
the change. This variable became needed again in newvers.sh last
month, but it wasn't used; the make -V hack was used instead.
Some relevant uses and non-uses of $1 in newvers.sh:
%%%
FreeBSD rev.1.1 (same as Net/2?)
echo char version[] = \version: ${v} ($1) ${t}\;
FreeBSD-1.1.5:
echo const char version[] = \${kernvers} ($1) #${v}: ${t}\\n [EMAIL
PROTECTED]:${dir}\\n\;
4.4BSD-Lite1:
echo char version[] = \4.4BSD-Lite #${v}: ${t}\\n[EMAIL PROTECTED]:${d}\\n\;
vers.c
[No $1's here or elsewhere in newvers.sh]
-current:
i=`make -V KERN_IDENT`
...
char version[] = ${VERSION} #${v}: ${t}\\n[EMAIL PROTECTED]:${d}\\n;
...
char kern_ident[] = ${i};
[No $1's here or elsewhere in newvers.sh, but I think $i is always the
same as $1.]
%%%
So removing the make -V line and just using $1 should fix the main problem
and the bitrot.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sun, Jul 13, 2003 at 05:57:34PM +0200, Mark Kettenis wrote: A1 If having support for amd64 is a major reason for doing a new import of GDB, importing the upcoming GDB 6.0 would make more sense to me. No ia64 is the major reason :-) Hmm. I think I just crashed pluto1 trying to get it to run the GDB testsuite on a not-yet-fully-functional GDB port. Currently RSE is giving me some headaches. Yeah, this is known (both the crashes and the headache :-) I was working on that (the crashes), but now need to make ia64 functional again. The gcc import left us dead in the water. Our crt1.c is broken. A2 I'm volunteering to help out here. Cool, thanks. Shall we just create a p4 branch and start hacking? Oh dear, do I need to learn another version control system? Yes, preferrably. Using a p4 branch allows us to track the gdb 6 branch while we prepare for the import. It's a convenient place for people to grab the WIP. better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. We probably need to talk then, because the ptrace interface needs to be fleshed out and I planned to do that while porting gdb. Probably. The current layout of `struct reg' and `struct fpreg' is a bit ... messy. It is not. It is actually pretty neat. Incomplete maybe, but neat. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Movie
MY ADDRESS HAS CHANGED. PLEASE RE-SEND YOUR EMAIL AS SET FORTH BELOW: CHANGE OF ADDRESS: Due to the Receipt of a tremendous amount of SPAM, I have changed my email address. My new email address is my first name @ my web site domain name. You should know what my first name and domain name are. My first name is available at my web site. You can also call me at 856-874-9651. Sorry for the inconvenience. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fw: 4.8 Kernel Compiling Error
the error that I was receiving was due the default directory of config was ../../ and it was incorrect you must specify the FQP of the kernel you are building and then make depend will work fine.. Thanks - Original Message - From: Travis Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 13, 2003 11:15 AM Subject: 4.8 Kernel Compiling Error mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include -I/ usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/iir/../../dev/iir/iir.c /usr/src/sys/modules/iir/../../dev/iir/iir_ctrl.c /usr/src/sys/modules/iir/../../dev/iir/iir_pci.c /usr/src/sys/modules/iir/../../dev/iir/iir.c:56: stddef.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/iir. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/MYKERNEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I have used src from the cdrom and from FTP1, regardless I am unable to compile the kernel. Any assistance would be appreciated Thank you. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
linuxthreads not compiling
Hi,
- I have a 5.1-CURRENT system from 2003-July-10.
- I tried to compile the linuxthreads package, but it failed.
- From current.freebsd.org i downloaded the ports.tgz from 2003-July-11
- still linuxthreads isnt compiling
error looks like :
cc -O -pipe -mcpu=pentiumpro -mcpu=pentiumpro -g -O2 -Wall
-DCOMPILING_LINUXTHREADS
-I/usr/ports/devel/linuxthreads/work/linuxthreads-2.2.3_12
-I/usr/ports/devel/linuxthreads/work/linuxthreads-2.2.3_12/sysdeps/i386
-I/usr/ports/devel/linuxthreads/work/linuxthreads-2.2.3_12/sysdeps/pthre
ad
-I/usr/ports/devel/linuxthreads/work/linuxthreads-2.2.3_12/sysdeps/unix/
sysv/linux -I/usr/src/lib/libc/stdtime -DLIBC_RCS -DLINUXTHREADS
-D__USE_UNIX98 -D__USE_XOPEN2K -D_STACK_GROWS_DOWN -DNEWLIBC
-D_THREAD_SAFE -c clone.S
clone.S:8:17: SYS.h: No such file or directory
{standard input}: Assembler messages:
{standard input}:55: Error: no such instruction: `kerncall'
*** Error code 1
Stop in /usr/ports/devel/linuxthreads/work/linuxthreads-2.2.3_12.
*** Error code 1
Stop in /usr/ports/devel/linuxthreads.
Any ideas ?
Regards kai
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW and/or rc rule parsing not working since today's cvsup
thanks for pointing out -- it turns out that by mistake i have changed the handling of blank lines in ipfw configs. I will restore the old behaviour ASAP (it's a trivial 1-2 line change). cheers luigi On Sun, Jul 13, 2003 at 01:31:07PM +0100, Matt wrote: Matt said: I normally sync to current once a week and have just done it today: FreeBSD tao.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Jul 13 12:24:40 BST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAO i386 The problem is though that it looks like IPFW or RC has changed how it works. I'm not sure if this is intentional or not though. If it is intentional then I think it is a violation of POLA. The problem I have is this. In rc.conf I have the following: firewall_enable=YES firewall_script=/etc/rc.firewall firewall_type=/etc/ipfw.conf And in /etc/ipfw.conf I have sets of rules one line at a time like: add 00010 divert natd all from any to any via xl0 add 00120 allow tcp from any to any 80 via xl0 etc. This has always worked for me ever since I first started using ipfw on fbsd 4.1 and has always worked on current until today's cvsup. Now though no rules get loaded. If I try what I have always done in the past which is ipfw -q flush ipfw /etc/ipfw.conf then it tells me: usage: ipfw [options] do ipfw -h or see ipfw manpage for details Whereas before this week this worked perfectly. The /etc/rc.firewall still says that you can set a filename for the firewall_type so I assume this should still work as in fact just broken rather than a POLA. I definatly mergemaster'd everything that had changed properly. In fact I have even just run it again in case I missed something and everything is up to date. Any comments? Regards, Matt. -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. I have noticed that there have been a large number of ipfw commits this week in the cvs logs and so I believe this could be related. I am therefore emailing this direct to luigi as hopefully he can help :) -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. ___ [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
In message: [EMAIL PROTECTED] Jilles Tjoelker [EMAIL PROTECTED] writes: : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : (unsigned type)(-1) is never zero valid? yes. There are no known machines where -1 == 0 for types of different signs. Further, the C standard says that it must behave as if it is a two's complement machine, and I think that C++ says so too. Warner ___ [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
: 134 #define __glibcpp_signed(T) ((T)(-1) 0) : #define __glibcpp_signed(T) (!((T)(-1) 0)) Why not the simpler: #define __glibcpp_signed(T) ((T)(-1) = 0) that way we have an overlap on the range of the two types, so we won't get a warning. We know for a fact that -1 != 0 for all known machine types (all machines are two's complement, or are required to behave as if they are two's complement, per the standard). (unsigned int) -1 == 0x (assuming 32-bit int). even on a one's complement's machine, without the standard conversion, the 'type punning' conversion of -1 would yield 0xfffe, which is still 0. Warner ___ [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 Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Jilles Tjoelker [EMAIL PROTECTED] writes: : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : (unsigned type)(-1) is never zero valid? yes. There are no known machines where -1 == 0 for types of different signs. Further, the C standard says that it must behave as if it is a two's complement machine, and I think that C++ says so too. I am pretty certain you can do one's compliment in the C99 standard, and that some of that is implementation/platform dependant. See section 6.2.6.2 of the C99 standard which enumerates the following 3 negative number representations: ¡Xthe corresponding value with sign bit 0 is negated (sign and magnitude); ¡Xthe sign bit has the value-(2^N )(two¡¦s complement); ¡Xthe sign bit has the value-(2^N -1) (one¡¦s complement). further: Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one¡¦s complement), is a trap representation or a normal value. Inthe case of sign and magnitude and one¡¦scomplement, if this representation is a normal value it is called a negative zero. Yes... a negative 0. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 08:23:54AM -0500, David Leimbach wrote: This is a good policy in general, however, one could easily argue that what is trying to be determined with signedness and such being less-than-compared to 0 isn't really a big deal and possibly the only way to implement this numeric_limitsT::digits thing without any type introspection which C++ currently lacks. What about? #define issigned(T) (((T)(0)(T)(~0)) ? 1 : 0) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2415] Re: PATCH - acpi 0619
On Sun, 13 Jul 2003, MATOBA Hirozumi wrote: On Fri, 11 Jul 2003 23:07:08 -0700, Nate Lawson wrote: | I've prepared a new diff of the 0619 drop of acpica along with the | appropriate changes to support code: | | * Use ACPI_BUFFER as the type for AcpiGetObjectInfo | * Remove AcpiEnableEvent/AcpiClearEvent for ACPI_EVENT_FIXED (power/sleep | buttons) as they are no longer needed | * Change calls to use the new GPE functions | * Add AcpiOs*Lock functions | * Import 0619 + local FreeBSD changes + dsmthdat.c patch (from | [EMAIL PROTECTED]) | | Please test and let me know how this works for you. It works fine on my | IBM T23. | | http://www.root.org/~nate/freebsd/acpi-0619.diff.gz I tested this patch on IBM ThinkPad A22e, but repeated messages ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER appeared again (like as 2-3 weeks ago). It seems that the change of from version 1.1.1.16 to 1.1.1.17 in src/sys/contrib/dev/acpica/hwregs.c is overwritten by this patch (so partially back to the status of 1.1.1.16). I included all of our local changes but it looks like I didn't catch changes I had made on the vendor branch previously. I'll make sure I've got all those also. I expected the vendor would have made this change but I guess not. I still expect them to do so soon. -Nate ___ [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 Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote: : 134 #define __glibcpp_signed(T) ((T)(-1) 0) : #define __glibcpp_signed(T) (!((T)(-1) 0)) Why not the simpler: #define __glibcpp_signed(T) ((T)(-1) = 0) that way we have an overlap on the range of the two types, so we won't get a warning. We know for a fact that -1 != 0 for all known machine types (all machines are two's complement, or are required to behave as if they are two's complement, per the standard). You keep saying this... where is this must behave as two's compliment stated? (unsigned int) -1 == 0x (assuming 32-bit int). or with a valid one's compliment C99 compliant system (unsigned int) -1 = 0xfffe; even on a one's complement's machine, without the standard conversion, the 'type punning' conversion of -1 would yield 0xfffe, which is still 0. Correct :). I still don't think C enforces two's compliment. Dave Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 01:25:45PM -0500, David Leimbach wrote: On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Jilles Tjoelker [EMAIL PROTECTED] writes: : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : (unsigned type)(-1) is never zero valid? yes. There are no known machines where -1 == 0 for types of different signs. Further, the C standard says that it must behave as if it is a two's complement machine, and I think that C++ says so too. I am pretty certain you can do one's compliment in the C99 standard, and that some of that is implementation/platform dependant. snip You seem to be confused. While signed integers certainly can use the one's complement representation, the conversion of an negative value to an unsigned type is a different matter. The relevant quote from C99 is: 6.3.1.3 Signed and unsigned integers 2 Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.49) Regards, Stefan Farfeleder ___ [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 01:37:32PM -0500, David Leimbach wrote: On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote: : 134 #define __glibcpp_signed(T) ((T)(-1) 0) : #define __glibcpp_signed(T) (!((T)(-1) 0)) Why not the simpler: #define __glibcpp_signed(T) ((T)(-1) = 0) that way we have an overlap on the range of the two types, so we won't get a warning. We know for a fact that -1 != 0 for all known machine types (all machines are two's complement, or are required to behave as if they are two's complement, per the standard). You keep saying this... where is this must behave as two's compliment stated? (unsigned int) -1 == 0x(assuming 32-bit int). or with a valid one's compliment C99 compliant system (unsigned int) -1 = 0xfffe; Only if UINT_MAX happens to be0xfffe, which it probablky won't be. For all C99 compliant systems you have that: (unsigned int) -1 == UINT_MAX even on a one's complement's machine, without the standard conversion, the 'type punning' conversion of -1 would yield 0xfffe, which is still 0. Correct :). I still don't think C enforces two's compliment. C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
FSF GDB releases use a libbfd that's basically a snapshot taken at the point where the release branch was cut. Hmm, seems like a motivation for a libbfd port that tracks the snapshot, for this very reason. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH - acpi 0619
Date: Fri, 11 Jul 2003 23:07:08 -0700 (PDT) From: Nate Lawson [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I've prepared a new diff of the 0619 drop of acpica along with the appropriate changes to support code: * Use ACPI_BUFFER as the type for AcpiGetObjectInfo * Remove AcpiEnableEvent/AcpiClearEvent for ACPI_EVENT_FIXED (power/sleep buttons) as they are no longer needed * Change calls to use the new GPE functions * Add AcpiOs*Lock functions * Import 0619 + local FreeBSD changes + dsmthdat.c patch (from [EMAIL PROTECTED]) Please test and let me know how this works for you. It works fine on my IBM T23. http://www.root.org/~nate/freebsd/acpi-0619.diff.gz OK. I installed the patches on my T30 and saw no clear regressions, although I'd like to do more testing. I did get many more errors at boot time, all early in the operation. messages attached. Also, after patching, I tried building world and it would not work due to undefined symbols in the boot/i386/libi386 build. I have put the errors into the attachment at the top. Observed problems: USB does not recover from suspend. Display back-light say on after suspend. (Neither of these is different from the CURRENT code. Another issue that I recently noted after a complaint that battery life was worse with FreeBSD than with Linux or Windows. I have noted that the CPU does not seem to slow even though the system claims that it is reduced to 50% in economy mode. Instead, the CPU always seems to run at 1.8 GHz if it was on AC at power-up and 1.2 GHz if the system was on battery at power-up. THIS IS EXACTLY THE SAME THING I SEE WITH APM! So it's not a regression, but somehow something is simply not right here. And it now appears that the problem is not specific to T30s or even IBMs as the other report was not an IBM, but a Compaq. I plan to do further testing of this to confirm some details. Since I could not build a new world with the patch in place, I have backed it out for now. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 === sys/boot/i386/libi386 cc -O -pipe -mcpu=pentiumpro -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600 -DTERM_EMU -I/usr/src/sys/boot/i386/libi386/../../common -I/usr/src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica -I/usr/src/sys/boot/i386/libi386/../../.. -I. -I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/ -ffreestanding -mpreferred-stack-boundary=2 -c /usr/src/sys/boot/i386/libi386/biosacpi.c In file included from /usr/src/sys/boot/i386/libi386/biosacpi.c:35: /usr/src/sys/contrib/dev/acpica/actypes.h:922: error: `ACPI_DEVICE_ID_LENGTH' undeclared here (not in a function) /usr/src/sys/contrib/dev/acpica/actypes.h:930: error: `ACPI_MAX_CID_LENGTH' undeclared here (not in a function) *** Error code 1 Jul 13 05:31:24 puppeteer syslogd: kernel boot file is /boot/kernel/kernel Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #6: Sat Jul 12 22:02:26 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBM-T30-D Preloaded elf kernel /boot/kernel/kernel at 0xc054c000. Preloaded userconfig_script /boot/kernel.conf at 0xc054c26c. Preloaded elf module /boot/kernel/acpi.ko at 0xc054c2bc. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1798479836 Hz CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz (1798.48-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536281088 (511 MB) avail memory = 515014656 (491 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: IBMTP-1Ion motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00fdeb0 ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.LPC_.FDC_._INI] (Node 0xc405d3e0), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__._INI] (Node 0xc4056860), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._STA] (Node 0xc405a0c0), AE_NOT_EXIST ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._STA] (Node 0xc405a0c0), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT1._STA] (Node 0xc4059ea0), AE_NOT_EXIST ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BAT1._STA] (Node 0xc4059ea0), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BGID] (Node 0xc405d520), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.LPC_.EC__.BINI] (Node 0xc405d540), AE_NOT_EXIST ACPI-1287:
Re: GCC 3.3.1, new warnings with limits
C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. So for the one way conversion of signed to unsigned it will behave like 2's compliment all the time. What about back to signed? I assume that it defaults back to the platform's implementation of the signed type which due to the conversion to unsigned would also, logically, be encouraged to behave as a 2's compliment signed number. Cute way to make the standard seem flexible. The overhead of type conversion is often overlooked in coding it seems... On some platforms like the PPC going from int to float takes a lot longer than one might think... but that is another story :). [no need to answer this... unless we take it out of this thread] And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. No arguments here. :) Sorry if we wandered off too far. It was at least enlightening for me and hopefully others. Dave -- Insert your favourite quote here. Erik Trulsson [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
In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : You keep saying this... where is this must behave as two's compliment : stated? Read the fine print on the signed to unsigned conversion and you find that it must be done modulo 2^N. Also, I never stated that the standard requires the machine use two's complement representation, but it has to behave as if that were the case. From the standard: 6.3.1.3 Signed and unsigned integers [#1] When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged. [#2] Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type. The argument runs like this: o assume int is 32 bits, but the argument can be run for other word sizes. o the largest value is 0x. largest plus 1 is 0x1. o -1 increased by 'one more than the maximum value' is 0x. That's behaving as if the type was two's complement. : (unsigned int) -1 == 0x (assuming 32-bit int). : : or with a valid one's compliment C99 compliant system : (unsigned int) -1 = 0xfffe; That's an invlaid conversion. While -1 might be represented by the bit pattern 0xfffe, (unsigned int) -1 must evaluate to 0x. : even on a one's complement's machine, without the standard conversion, : the 'type punning' conversion of -1 would yield 0xfffe, which is : still 0. : : Correct :). I still don't think C enforces two's compliment. You are partially right. An 'int' containing '-1' might have a bit pattern of 0xfffe or even 0x80001, but converting it to 'unsigned' must result in 0x. Warner ___ [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
In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : : On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Jilles Tjoelker [EMAIL PROTECTED] writes: : : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : : (unsigned type)(-1) is never zero valid? : : yes. There are no known machines where -1 == 0 for types of different : signs. Further, the C standard says that it must behave as if it is a : two's complement machine, and I think that C++ says so too. : : : I am pretty certain you can do one's compliment in the C99 standard, : and that : some of that is implementation/platform dependant. : : See section 6.2.6.2 of the C99 standard which enumerates the following 3 : negative number representations: : : ¡Xthe corresponding value with sign bit 0 is negated (sign and : magnitude); : ¡Xthe sign bit has the value-(2^N )(two¡¦s complement); : ¡Xthe sign bit has the value-(2^N -1) (one¡¦s complement). : I'm aware of that. However, the section that I quoted in my other mail (assuming it went out) says that when converting from signed to unsigned must be done in a way as if it was two's complement. : further: : Which of these applies is implementation-defined, as is whether the : value with sign bit 1 and all value bits zero (for the first two), or : with sign bit and all value bits 1 (for one¡¦s complement), is a trap : representation or a normal value. Inthe case of sign and magnitude and : one¡¦scomplement, if this representation is a normal value it is called : a negative zero. : : Yes... a negative 0. Yes. that's true, but never with unsigned types. Again, the standard specifies math such that you must make things behave as if it is two's complement, even if it isn't represented like that in the underlying bits. Warner ___ [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
In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : So for the one way conversion of signed to unsigned it will behave like : 2's compliment : all the time. What about back to signed? Same way. It will be reduced by the maximum value of the range plus one to do the conversion. See section for 6.3.1.3 for the details. That's why I said 'as if' in my other mail. Warner ___ [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 02:28:38PM -0500, David Leimbach wrote: C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. So for the one way conversion of signed to unsigned it will behave like 2's compliment Signed to unsigned will always give the same result, regardless of how negative numbers are represented, yes. (And for two's complement this is the same as the natural way of doing it, while for other representations some extra work might be needed.) all the time. What about back to signed? I assume that it defaults back to the If you have try to convert a value to a signed type and the type in question cannot that value, then the result is implementation-defined. Implementation-defined means the implementation is free to do whatever it wants, but it must document what it will do. Typically implementations won't do anything special but will just keep the same representation, but this is not something that portable programs can depend on. So, on a one's complement machine one would probably have that: (int)UINT_MAX == 0 (Since UINT_MAX would have the same representation as a negative zero on such a machine.) On a sign-magnitude machine it would probably be (int)UINT_MAX == INT_MIN and on a two's complement machine one would probably have (int)UINT_MAX == -1 but an implementation is also free to trap on integer overflow, just as it usually does with division by zero. (Or it might do something else.) Unsigned arithmetic is well-defined in C. Signed arithmetic less so. platform's implementation of the signed type which due to the conversion to unsigned would also, logically, be encouraged to behave as a 2's compliment signed number. Cute way to make the standard seem flexible. The overhead of type conversion is often overlooked in coding it seems... On some platforms like the PPC going from int to float takes a lot longer than one might think... That depends on how long one thinks it should take, doesn't it? :-) but that is another story :). [no need to answer this... unless we take it out of this thread] And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. No arguments here. :) Sorry if we wandered off too far. It was at least enlightening for me and hopefully others. -- Insert your favourite quote here. Erik Trulsson [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 01:48:38PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : So for the one way conversion of signed to unsigned it will behave like : 2's compliment : all the time. What about back to signed? Same way. It will be reduced by the maximum value of the range plus one to do the conversion. No, this case is implementation-defined if the value cannot be represented by the signed type it is converted to. (If it can be represented then the value will be preserved.) See section for 6.3.1.3 for the details. Yes, please do. That's why I said 'as if' in my other mail. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Call for testers: Broadcom 5705 gigabit ethernet
While I still don't have any documentation for the BCM5705, I recently obtained a Broadcom driver with 5705 support. After scrutinizing it carefully, it looks like the differences between it and its predecessors are: - No jumbo frame support - RX return ring is limited in size to 512 entries - No support for DMA'ed statistics block (stats must be read from registers instead) - Initialization of certain on-chip blocks and parameters are skipped - 5705 rev A0 has a bug that requires a workaround: the driver has to poll the NIC's memory after setting up the RX descriptor ring to verify the chip has actually loaded it. I have merged all these changes into a copy of the bge(4) driver from -current (should also work with 5.1-RELEASE). You can get it from: http://www.freebsd.org/~wpaul/Broadcom/5705 To use it, just drop the supplied if_bge.c and if_bgereg.h files into /sys/dev/bge and recompile your kernel and/or if_bge.ko module. Unfortunately, I don't have a machine with a 5705 chip in it, so I need other people to help me test these changes. If you have avilable right now: - a laptop or other box with a 5705 gigE chip - FreeBSD 5.1-RELEASE or -CURRENT - another network interface that you can use to load this driver Then please test this updated driver for me and report back. Information that I would like to see: - Describe the system with the 5705 chip in it (I'm under the impression the 5705 is being used in embedded configurations only) - A copy of dmesg output showing the ASIC revision of your chip (doesn't have to be a verbose boot, though I won't mind if it is) - A detailed description of any problems you may observe while testing the driver Information I don't want to see: - Requests for help with other totally unrelated drivers - Requests for help transfering large sums of money out of Nigeria - Information about septic tank clealing - Pictures of people getting it on with barnyard animals - Bikeshed arguments Thanks in advance for any help anyone is able to provide. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [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, 13 Jul 2003, Marcel Moolenaar wrote: On Sun, Jul 13, 2003 at 08:23:54AM -0500, David Leimbach wrote: This is a good policy in general, however, one could easily argue that what is trying to be determined with signedness and such being less-than-compared to 0 isn't really a big deal and possibly the only way to implement this numeric_limitsT::digits thing without any type introspection which C++ currently lacks. What about? #define issigned(T) (((T)(0)(T)(~0)) ? 1 : 0) This is worse than any version that uses -1 instead of ~0, since ~0 gives implementation-defined behaviour. I think it can set trap bits. Anyway, the value of ~0 is unclear. I think it is -0 == 0 on 1's complement machines. Since its value is unclear, the result of converting this value to even an unsigned type T is also unclear. I think the above actually does work for the 3 representations in C99 iff ~0 has no trap bits, but this is unclear. These problems are avoided by using plain -1. Bruce ___ [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, 13 Jul 2003, Erik Trulsson wrote:
On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote:
You keep saying this... where is this must behave as two's compliment
stated?
(unsigned int) -1 == 0x (assuming 32-bit int).
or with a valid one's compliment C99 compliant system
(unsigned int) -1 = 0xfffe;
Only if UINT_MAX happens to be0xfffe, which it probablky won't be.
Probabilty zero on C99 conformant systems :-). UFOO_MAX is (2^N - 1)
where N is the number of value bits in the representation of type FOO.
See 6.2.6.2. (UFOO_MAX may still be represented differently in memory
than as N lower bits all set.)
[Someone wrote]
even on a one's complement's machine, without the standard conversion,
the 'type punning' conversion of -1 would yield 0xfffe, which is
still 0.
Correct :). I still don't think C enforces two's compliment.
I don't think there is any requirement that the layout of the bits in
representations of unsigned types has anything to do with the layout
for signed types, so type punning might set implementation-specific wrong
{value, trap, padding} bits.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
DDNS strangeness
Hi. I'm not sure if this belongs somewhere else but I'm starting here since these are 5.x systems. Please CC me on any replies. I subscribe to the digest format (makes replying difficult.) TIA. I have DDNS running between my house server and what will become an X desktop. They are both 5.x at different maintenance levels. I have it updating the DNS server as I expect when I boot the X desktop. If I have to boot the server, e.g. my town's unpredictable power, the X desktop machine cannot re-add itself to my DNS. (DNS and DHCP run on the home server. In this case, there is no third machine involved.) I found a predictable way to get the X desktop to readd itself (by changing the hostname to something else then changing it back) but it did not feel right to me so I started rereading some of the man pages. I found the following at the end of the The Interim DNS Update Scheme section of the dhcpd.conf man page: ...So the DHCP server tracks whether or not it has updated the record in the past (this information is stored in the lease) and does not attempt to update records that it thinks it has already updated. This can lead to cases where the DHCP server adds a record, and then the record is deleted through some other mechanism, but the server never again updates the DNS because it thinks the data is already there. In this case the data can be removed from the lease through operator intervention, and once this has been done, the DNS will be updated the next time the cliend renews. OK. This description fits my scenario. I understand it but I do not have to like it. The statement ...the data can be removed from the lease through operator intervention... is where I'm looking for some insights. I reread the dhcpd man page looking for a manual way to alter the lease (to remove the DNS information.) The only thing I picked up on that MIGHT talk to this is OMAPI and the Lease Object. The description if the Lease Object did not really help. I understand that DDNS is not a standard (yet.) I also know I'm sorta on my own here. I was hoping someone had a workaround for this behaviour. Thanks... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH - acpi 0619
On Sun, 13 Jul 2003, Kevin Oberman wrote: OK. I installed the patches on my T30 and saw no clear regressions, although I'd like to do more testing. I did get many more errors at boot time, all early in the operation. messages attached. These are due to lack of ECDT support which newer acpica dists now expect. They are harmless. I will be adding ECDT support soon. Also, after patching, I tried building world and it would not work due to undefined symbols in the boot/i386/libi386 build. I have put the errors into the attachment at the top. Thanks, I'll make sure I take care of those. Observed problems: USB does not recover from suspend. Display back-light say on after suspend. (Neither of these is different from the CURRENT code. The USB issue is a problem in general with the USB driver and is being worked on. Another issue that I recently noted after a complaint that battery life was worse with FreeBSD than with Linux or Windows. I have noted that the CPU does not seem to slow even though the system claims that it is reduced to 50% in economy mode. Instead, the CPU always seems to run at 1.8 GHz if it was on AC at power-up and 1.2 GHz if the system was on battery at power-up. THIS IS EXACTLY THE SAME THING I SEE WITH APM! So it's not a regression, but somehow something is simply not right here. And it now appears that the problem is not specific to T30s or even IBMs as the other report was not an IBM, but a Compaq. I plan to do further testing of this to confirm some details. Noted. I haven't looked at our cpu stuff yet but will get to it eventually. The main things I was looking for with the import were regressions. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Broadcom 5705, addendum
Almost forgot: The BCM5705 also has a new PHY ID, which means an update to brgphy.c and miidevs is required. So, to test the 5705 driver update, do the following: - Download the files from http://www.freebsd.org/~wpaul/Broadcom/5705 - Put if_bge.c and if_bgereg.h into /sys/dev/bge - Put brgphy.c and miidevs into /sys/dev/mii - Recompile your kernel and/or if_bge.ko and miibus.ko modules. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Bug filing broken?
I tried to file a bug for one of my -CURRENT machines using send-pr and got the following result back: - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 450 taz.allcaps.org.: Helo command rejected: Host not found) Presumably this means that the mailer is trying to reverse lookup my hostname, and it doesn't exist. That's true, as I have been experimenting with this stuff behind my firewall on my private net. Fine. I'll file a bug via the web interface. Go to: http://www.freebsd.org/send-pr.html The web-based bug interface is currently disabled. This is annoying. A user is already peeved that FreeBSD has a bug, and now the bug sending mechanism has a bug. In addition, the web bug submission is offline. The send to [EMAIL PROTECTED] should not have failed in the first place. Even if [EMAIL PROTECTED] needs spam protection, all of the emails coming into it have a signature which makes spam analysis incredibly easy. Please reopen FreeBSD-gnats-submit so that it accepts all input and rejects based upon content. Another idea is to rewrite send-pr so that it submits bug reports directly to a port on a server somewhere. Using port 80 and a dedicated receive server would get around firewalling issues. The alternative is to reopen the web form. However, I find send-pr much more useful (less cutting and pasting). Submitting a bug report should be the easiest, most robust and error free task the system carries out. Thanks, -a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: acpica 0619 in the tree
I have imported acpica 0619. I will be gone for a few hours but will be
checking again tonight in case there are any problems. In particular, I
am no longer sure if this patch is needed. If you do have problems, give
it a try.
Thanks,
Nate
--- nsalloc.c.old Wed May 28 10:32:31 2003
+++ nsalloc.c Thu Jun 19 17:30:48 2003
@@ -321,7 +321,7 @@
ACPI_NAMESPACE_NODE *Node, /* New Child*/
ACPI_OBJECT_TYPEType)
{
-UINT16 OwnerId = TABLE_ID_DSDT;
+UINT16 OwnerId = 0;
ACPI_NAMESPACE_NODE *ChildNode;
#ifdef ACPI_ALPHABETIC_NAMESPACE
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: Date: Fri, 11 Jul 2003 15:50:02 -0700 From: Marcel Moolenaar [EMAIL PROTECTED] Gang, With the gcc(1) dust not even settled yet, I like to get some feedback on gdb(1). AFAICT, this is the deal: o Both ia64 and amd64 need gdb(1) support before they can become a tier 1 platform. I think this implies upgrading to 5.3 the least. Upgrading to 5.3 for amd64 won't really help. While 5.3 included support for amd64, I'm told it is seriously broken. Since then, I've almost completely reworked GDB's amd64 target, to bring it in line with the i386 target, and adapt it to some major architectural changes in GDB. Based on that work, I've finished a FreeBSD/amd64 port yesterday. I'll try to get it on GDB's 6.0 release branch. However, backporting it to 5.3 would be a major PITA and IMHO a tremendous waste of effort. Not sure about that. I wish you would touch base with SuSE. AMD has had SuSE do quite a lot of work to make GDB 5.3 very usable on AMD64. I know there are parts of the work SuSE has yet to send to the GDB lists. I am worried that FreeBSD's AMD64 bits will be too different from the Linux ones and FreeBSD won't be able to leverage the work AMD is paying SuSE to do. That said, giving the amount of work it takes to import a GDB release(snapshot) and get it working in our tree -- we really should import a 6.0 snapshot. However, FreeBSD/sparc64 isn't properly supported in FSF GDB either. When Jason Thorpe added NetBSD/sparc64 support he did it very NetBSD specific rather than do it in a more general BSD/sparc64 way that all the BSD's could leverage. Generalizing his bits is needed in the FSF GDB bits. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? Probably not, but I'd love it if you would take a look at it -- the times I've talked about to GDB guys hasn't been encouraging. How can we work to get the bits in /usr/src/gnu/usr.bin/binutils/gdb made part of stock FSF GDB (along with our diffs from the FSF vendor branch in /usr/src/contrib/gdb)? This would involve a copyright assignment, which could prove to be a major obstacle. We (I) can work to address this issue. A2 I'm volunteering to help out here. As the i386 target maintainer and FreeBSD host/native maintainer, I seem to have sufficient background in GDB I guess ;-). For almost two years now, I've been using FreeBSD/i386 as my primary (development) platform, and I hope at least some people have noticed that the upstream GDB works much better on FreeBSD/i386 and FreeBSD/Alpha now. Now that I've got it working on FreeBSD/amd64, I'll give FreeBSD/ia64 a shot. Others may hate me for this, but getting stock GDB working on sparc64 is of higher priority as it is a Tier-1 platform and we have more sparc64 users than ia64. Or maybe, you can help back me on the gdb-patches mailing list and I can revive Jake's and my patches for sparc64. releases, I'm dedicated to FreeBSD, and I'm certainly willing to do work on integrating new versions of GDB into the FreeBSD tree. I'm more than willing to mentor you what it takes to do a GDB import into FreeBSD. Enjoy! -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sun, Jul 13, 2003 at 05:57:34PM +0200, Mark Kettenis wrote: Date: Sat, 12 Jul 2003 13:39:30 -0700 From: Marcel Moolenaar [EMAIL PROTECTED] On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote: o We still have the Alpha gdb -k bug moved over from the 5.1 todo list to the 5.2 todo list. I think this is just a bug fix. I'm not really familliar with the support for debugging FreeBSD kernels in GDB since that support is not in the FSF tree. Is there any chance that this code will be contributed back? This would involve a copyright assignment, which could prove to be a major obstacle. The copyright of our kgdb support is already the FSF. See /usr/src/gnu/usr.bin/binutils/gdb/kvm-fbsd.c I'll have to find out whether the paperwork is actually there. As you know I do have paperwork on file, which covers some of the work. The bigger question is will the fuctionality get resistance to being part of the FSF GDB? Can you evaluate the FreeBSD additions from that point of view? Interesting. It may even be possible to make gdb 6.0 part of FreeBSD 5.2 scheduling wise. Do we need a binutils update? We now have 2.13.2. Please, don't even worry about that. You'll get lost in a non-issue. The real issue is getting a patch that would update our bits to GDB 6.0 -- not the actual integration. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GDB - do we dare?
On Sun, Jul 13, 2003 at 02:28:08PM -0500, Mark Linimon wrote: FSF GDB releases use a libbfd that's basically a snapshot taken at the point where the release branch was cut. Hmm, seems like a motivation for a libbfd port that tracks the snapshot, for this very reason. NO! -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug filing broken?
You might try to investigate the issue first. Try http://www.dnsreport.com;, and see if any red flags appear in the MX record section, or in another area that might affect mail. Its a common technique to reject mail from domains that do not follow the RFC specs. Also, you might try to send word about this to the postmaster of freebsd.org. Best, -Jon Andrew P. Lentvorski, Jr. wrote: I tried to file a bug for one of my -CURRENT machines using send-pr and got the following result back: - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 450 taz.allcaps.org.: Helo command rejected: Host not found) Presumably this means that the mailer is trying to reverse lookup my hostname, and it doesn't exist. That's true, as I have been experimenting with this stuff behind my firewall on my private net. Fine. I'll file a bug via the web interface. Go to: http://www.freebsd.org/send-pr.html The web-based bug interface is currently disabled. This is annoying. A user is already peeved that FreeBSD has a bug, and now the bug sending mechanism has a bug. In addition, the web bug submission is offline. The send to [EMAIL PROTECTED] should not have failed in the first place. Even if [EMAIL PROTECTED] needs spam protection, all of the emails coming into it have a signature which makes spam analysis incredibly easy. Please reopen FreeBSD-gnats-submit so that it accepts all input and rejects based upon content. Another idea is to rewrite send-pr so that it submits bug reports directly to a port on a server somewhere. Using port 80 and a dedicated receive server would get around firewalling issues. The alternative is to reopen the web form. However, I find send-pr much more useful (less cutting and pasting). Submitting a bug report should be the easiest, most robust and error free task the system carries out. Thanks, -a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
geteuid hangs in sigsuspend
Hi,
when i update from 5.0-REL to 5.1-REL / 5.1-CURRENT, using a program
compiled against linuxthreads, might there be a different behaviour in
the geteuid function of libc ?
on my sapdb port the database manager called dbmcli starts fine on
5.0-REL,
on 5.1-REL/CURRENT it hangs on a sigsuspend.
When i use the FreeBSD 5.0 libs on my FreeBSD 5.1 system, the program
runs fine !
Could someone help ?
5.1-CURRENT is from 2003-July-10
Best regards Kai
--
The program output looks like this :
[EMAIL PROTECTED]:/usr/sapdb/src/FreeBSD/sys/src] # dbmcli
HERE 1
HERE 3
canceladdr 0x component 'dbmcli'
DBLANG=(null)
SERVERDB=(null)
HERE 3
here it hangs
The code looks like this :
#ifdef FREEBSD_DEBUG
printf(HERE 3\n); // 1st one
#endif
en01assignStdFiledescriptors();
en01CheckForDBUmask ();
eo46PtoC ( sql01_component , component , COMPSIZ );
DBG1 (( MF__,canceladdr 0x%08lx component '%s' \n,
(long) canceladdr , sql01_component ))
sql01_dblang = getenv ( DBLOCALE );
if ( sql01_dblang == NULL )
sql01_dblang = getenv ( DBLANG );
DBG1 (( MF__,DBLANG=%s\n, sql01_dblang ))
sql01_dbname = getenv ( SERVERDB );
DBG1 (( MF__,SERVERDB=%s\n, sql01_dbname ))
#ifdef FREEBSD_DEBUG
printf(HERE 3\n); // 2nd one
#endif
uid = geteuid ();
pwdp = getpwuid ( uid );
#ifdef FREEBSD_DEBUG
printf(HERE 3\n); // 3rd one (not appearing)
#endif
--
strace looks like this :
[EMAIL PROTECTED]:/usr/sapdb/src/FreeBSD/sys/src] # strace dbmcli
execve(0xbfbff108, [0xbfbff5cc], [/* 0 vars */]) = 0
mmap(0, 3392, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x281a6000
munmap(0x281a6000, 3392)= 0
__sysctl([...], 0x281a3e68, 0xbfbff39c, NULL, 0) = 0
mmap(0, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0x281a6000
issetugid(0x28185000) = 0
access(/usr/sapdb/depend/lib/libcrypt.so.2, F_OK) = -1 ENOENT (No such
file or directory)
open(/var/run/ld-elf.so.hints, O_RDONLY) = 3
read(3, \305q\376\377\271q\376\377.p\376\377p\376\377Gp\376\377...,
128) = 128
lseek(3, 128, SEEK_SET) = 128
read(3, /usr/lib:/usr/local/lib:/usr/X11..., 61) = 61
close(3)= 0
access(/usr/lib/libcrypt.so.2, F_OK) = 0
open(/usr/lib/libcrypt.so.2, O_RDONLY) = 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\16...,
4096) = 4096
mmap(0, 102400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_NOCORE, 3, 0) =
0x281ae000
mprotect(0x281b4000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x281b4000, 4096, PROT_READ|PROT_EXEC) = 0
mmap(0x281b5000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x7000) = 0x281b5000
mmap(0x281b6000, 69632, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0x281b6000
close(3)= 0
access(/usr/sapdb/depend/lib/liblthread.so.3, F_OK) = -1 ENOENT (No
such file or directory)
access(/usr/lib/liblthread.so.3, F_OK) = -1 ENOENT (No such file or
directory)
access(/usr/local/lib/liblthread.so.3, F_OK) = 0
open(/usr/local/lib/liblthread.so.3, O_RDONLY) = 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0Ps\0\000...,
4096) = 4096
mmap(0, 151552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_NOCORE, 3, 0) =
0x281c7000
mprotect(0x281df000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x281df000, 4096, PROT_READ|PROT_EXEC) = 0
mmap(0x281e, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x19000) = 0x281e
mmap(0x281e8000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0x281e8000
close(3)= 0
access(/usr/sapdb/depend/lib/libstdc++.so.4, F_OK) = -1 ENOENT (No
such file or directory)
access(/usr/lib/libstdc++.so.4, F_OK) = 0
open(/usr/lib/libstdc++.so.4, O_RDONLY) = 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\332\3...,
4096) = 4096
mmap(0, 737280, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_NOCORE, 3, 0) =
0x281ec000
mprotect(0x28285000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x28285000, 4096, PROT_READ|PROT_EXEC) = 0
mmap(0x28286000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x9a000) = 0x28286000
mmap(0x2829b000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0x2829b000
close(3)= 0
access(/usr/sapdb/depend/lib/libm.so.2, F_OK) = -1 ENOENT (No such
file or directory)
access(/usr/lib/libm.so.2, F_OK) = 0
open(/usr/lib/libm.so.2, O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`2\0\000...,
4096) = 4096
mmap(0, 118784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_NOCORE, 3, 0) =
0x282a
mprotect(0x282b7000, 4096,
fla.ko
I'm wondering what needs to be done to make the fla device into a kernel module.
I made modules/fla/Makefile, but I am not sure what else needs to be done.
It looks like you can't kldunload it after you kldload it...
.PATH: ${.CURDIR}/../../contrib/dev/fla
KMOD= fla
SRCS= fla.c \
device_if.h bus_if.h
OBJS+= msysosak.o
msysosak.o:
uudecode ${.CURDIR}/../../contrib/dev/fla/i386/msysosak.o.uu
.include bsd.kmod.mk
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Overdone rescue cleaning as part of buildworld?
It appears /rescue is cleaning for way too much as part of buildworld. For instance, groff is NOT part of /rescue (or we have other things to discuss. :) This adds a bit of time to buildworld, can it be removed? -Nate === rescue/rescue/texinfo/texindex rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/texinfo/doc === rescue/rescue/groff === rescue/rescue/groff/contrib === rescue/rescue/groff/contrib/mm === rescue/rescue/groff/doc === rescue/rescue/groff/font === rescue/rescue/groff/font/devX100 === rescue/rescue/groff/font/devX100-12 === rescue/rescue/groff/font/devX75 === rescue/rescue/groff/font/devX75-12 === rescue/rescue/groff/font/devascii === rescue/rescue/groff/font/devcp1047 === rescue/rescue/groff/font/devdvi === rescue/rescue/groff/font/devhtml === rescue/rescue/groff/font/devkoi8-r === rescue/rescue/groff/font/devlatin1 === rescue/rescue/groff/font/devlbp === rescue/rescue/groff/font/devlj4 === rescue/rescue/groff/font/devps === rescue/rescue/groff/font/devutf8 === rescue/rescue/groff/man === rescue/rescue/groff/src === rescue/rescue/groff/src/libs === rescue/rescue/groff/src/libs/libgroff rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/groff/src/libs/libdriver rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/groff/src/libs/libbib rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/groff/src/devices === rescue/rescue/groff/src/devices/grodvi rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/groff/src/devices/grohtml rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/groff/src/devices/grolbp rm -f .depend GPATH GRTAGS GSYMS GTAGS [...] = rescue/rescue/atm/ilmid rm -f ilmid ilmid.o ilmid.8.gz ilmid.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/badsect rm -f badsect badsect.o badsect.8.gz badsect.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/bsdlabel rm -f bsdlabel bsdlabel.o geom_bsd_enc.o bsdlabel.8.gz bsdlabel.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/camcontrol rm -f camcontrol camcontrol.o util.o modeedit.o camcontrol.8.gz camcontrol.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/ccdconfig rm -f ccdconfig ccdconfig.o ccdconfig.8.gz ccdconfig.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/clri rm -f clri clri.o clri.8.gz clri.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/comcontrol rm -f comcontrol comcontrol.o comcontrol.8.gz comcontrol.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/conscontrol rm -f conscontrol conscontrol.o conscontrol.8.gz conscontrol.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/devfs rm -f devfs devfs.o rule.o devfs.8.gz devfs.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/dhclient === rescue/rescue/dhclient/common rm -f dhcp-eval.5.gz dhcp-options.5.gz dhcp-eval.5.cat.gz dhcp-options.5.cat.gz rm -f a.out alloc.o bpf.o comapi.o conflex.o ctrace.o discover.o dispatch.o dlpi.o dns.o ethernet.o execute.o fddi.o icmp.o inet.o lpf.o memory.o nit.o options.o packet.o parse.o print.o raw.o resolv.o socket.o tables.o tr.o tree.o upf.o alloc.o.tmp bpf.o.tmp comapi.o.tmp conflex.o.tmp ctrace.o.tmp discover.o.tmp dispatch.o.tmp dlpi.o.tmp dns.o.tmp ethernet.o.tmp execute.o.tmp fddi.o.tmp icmp.o.tmp inet.o.tmp lpf.o.tmp memory.o.tmp nit.o.tmp options.o.tmp packet.o.tmp parse.o.tmp print.o.tmp raw.o.tmp resolv.o.tmp socket.o.tmp tables.o.tmp tr.o.tmp tree.o.tmp upf.o.tmp rm -f libdhcp.a rm -f .depend GPATH GRTAGS GSYMS GTAGS === rescue/rescue/dhclient/dst rm -f a.out base64.o dst_api.o dst_support.o hmac_link.o md5_dgst.o prandom.o base64.o.tmp dst_api.o.tmp dst_support.o.tmp hmac_link.o.tmp md5_dgst.o.tmp prandom.o.tmp rm -f libdst.a rm -f .depend GPATH GRTAGS GSYMS GTAGS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug filing broken?
On Sun, Jul 13, 2003 at 03:40:21PM -0700, Andrew P. Lentvorski, Jr. wrote: I tried to file a bug for one of my -CURRENT machines using send-pr and got the following result back: - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 450 taz.allcaps.org.: Helo command rejected: Host not found) Presumably this means that the mailer is trying to reverse lookup my hostname, and it doesn't exist. That's true, as I have been experimenting with this stuff behind my firewall on my private net. Fine. I'll file a bug via the web interface. Go to: http://www.freebsd.org/send-pr.html The web-based bug interface is currently disabled. This is annoying. A user is already peeved that FreeBSD has a bug, and now the bug sending mechanism has a bug. In addition, the web bug submission is offline. The send to [EMAIL PROTECTED] should not have failed in the first place. Even if [EMAIL PROTECTED] needs spam protection, all of the emails coming into it have a signature which makes spam analysis incredibly easy. Please reopen FreeBSD-gnats-submit so that it accepts all input and rejects based upon content. Another idea is to rewrite send-pr so that it submits bug reports directly to a port on a server somewhere. Using port 80 and a dedicated receive server would get around firewalling issues. The alternative is to reopen the web form. However, I find send-pr much more useful (less cutting and pasting). Submitting a bug report should be the easiest, most robust and error free task the system carries out. We await your patches :) Kris pgp0.pgp Description: PGP signature
