Re: ACPI problem?
On Thu, 17 Jul 2003, Danny Braniss wrote: Your asl seems bogus since there are a lot of unexpected values (i.e. for TZ and EC port values). Since it worked in 4.8R, follow the instructions for disabling ACPI. -Nate thanks, that did it, but now, is there anyway i can help fix this so acpi will work? i have several of this boxes and booting them diskless will be a problem. Try man acpi: To disable the acpi driver completely, set the kernel environment vari- able hint.acpi.0.disabled to 1. Some i386 machines totally fail to oper- ate with some or all of ACPI disabled. Other i386 machines fail with ACPI enabled. Non-i386 platforms do not support operating systems which do not use ACPI. Disabling all or part of ACPI on non-i386 platforms may result in a non-functional system. Hints can go in /boot/loader.conf. Later, after the system is working for you, you can go back and install a new BIOS and see if that fixes the problem with ACPI enabled. -Nate sorry, i guess i was not clear, i did 'unset acpi_load', and got the system up, i was offering to help in fixing the acpi (actually debugging, since my head hurts from reading the acpi stuff :-) thanks, danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: some ports are broken after upgrading GCC 3.3.1
Alexander Kabaev wrote: On Thu, 17 Jul 2003 14:02:20 -0700 Kris Kennaway [EMAIL PROTECTED] wrote: Sorry, I missed the patch in your email. I'm not certain about your approach...can someone who understands the issues comment on it? I'd rather see all varargs.h consumers be converted to stdarg.h. Old varargs GCC builtins were _removed_ altogether from the compiler sources and we should follow. I've posted cdefs.h patches several times that allow you to switch between implementations. Now that ANSI C is default in FreeBSD, they probably aren't necessary, but it's pretty obvious how to implement it, if you think you need it (the biggie is dealing with the ... in the prototype). If you need them for FreeBSD, and don't want to work it out, let me know. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HPT372 bug summary [was: RE: escalation stage 2]
Harald Schmalzbauer wrote: Please forget that. It was because for convinience reasons I had turned the 80-pin ATA cables upside down. So the black was at the controller and the blue at the drive. I can't imagine that this makes any technical difference (as long as no slave drive is connected and there's no open end) But it seems the single connectors are electrical coded (again I can't imagine how?!?) From the Computer Lore For What It's Worth department... In cables with free wires in them, it's very common to ground them on only one ends of the cable (usually, the end with the best chassis ground, which in this case would be the host), so that the free wires act to damp noise in the environment from effecting the other lines... basically, a Farraday cage. It's very common to see this in old RS-232C cables, as well as in SCSI cables, especially the long ones used in differential SCSI, if they don't have shielding. The reason you connect only one end is to avoid ground loops, which you can get if you use line voltage base reference: for example, on RS-232C, it was common to abuse the standard and send a digital ground of 12 volts on the digital ground as the zero voltage base reference, which gave you -11 (= +1) and +11 (= +23) for 24v telephone equipment, so that you didn't have to have a power supply capable of putting out -11v and regulate the +24 to +11. If the cable cared, it probably cared because it was grounded on the host side and not on the drive, and the drive probably didn't hook the pins up at all, to avoid ground loops when using cables that *did* connect the pins through. Best case, you were connected to digital instead of chassis ground on the drive side, and worst case, you were unconnected on the host end *and* the drive end, and so had a nice big linear capacitor/dipole antenna. 8-). In other words, if a cable says to connect it a specific way, there's probably a good reason. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HPT372 bug summary [was: RE: escalation stage 2]
It seems Harald Schmalzbauer wrote: I also think the RAID configuration is stored on the disks since when I create a non-DOS compatible slice (starting at 0 not 63) the RAID configuration vanishes. Yes the Highpoint BIOS uses sector 9 to hold the RAID config, so if you use that for other data storage you are lost.. (blaim Highpoint sufficiently here). Now I assume that there are two different RAID configurations, one stored on disk by the controllers BIOS and anotherone which FreeBSD stores elsewhere (e.g: with the sil0680 I can well create slices starting at 0). No, the info is *always* stored on disk, but when you make a FreeBSD native ATA RAID its put at the end of disk, and the disksize is reduced so you cannot overwrite it (so does Promise controllers) Now when one drive fails both configurations are marked degraded but in a different manner (because there is one array named RAID1_1 and a second which is named FreeBSD) And that's why FreeBSD panics until I delete the mirror relationship. Well Highpoints way of dealing with broken arrays and lost disks are less than optimal, I've tried to do my best in the ATA driver to fool the HPT system, but its not perfect... Since this is my most important server I can't help you the next weeks. On sunday I'll buy a SIL0680 based controller because I did the same test with it and it's working. Now I'm currently setting up FreeBSD and building a kernel with DDB. If you are not using 5.1-current the sil680 is dangerous until I get time to backport some critical fixes... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
On Thursday 17 July 2003 22:50, Mikhail Teterin wrote:
Here is how to reproduce the problem, Michael is talking about. Simply
try to build the kdelibs3 (or kdegraphic3, or kdenetwork3) port.
I've tried to come up with a less obscure testcase:
#include string
#include iostream
using namespace std;
int main ()
{
string astring=Hello World;
cout astring endl;
}
Now, if I compile this on 5.1-RELEASE with
c++ -Wnon-virtual-dtor -Wno-long-long -Wall -pedantic -W -Wpointer-arith
-Wmissing-prototypes -Wwrite-strings -DNDEBUG -DNO_DEBUG -O -pipe
-mcpu=pentiumpro -fno-check-new -L/usr/local/lib -I/usr/local/include
-I/usr/local/include -I/usr/X11R6/include -D_GETOPT_H -o helloworld
helloworld.cc
I get a plethora of warnings:
In file included from /usr/include/g++/memory:55,
from /usr/include/g++/string:48,
from helloworld.cc:1:
/usr/include/g++/bits/stl_alloc.h:979: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:980: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
[and many, many more]
but it will compile. If I omit -pedantic, none of these warnings occur. The
thing is, in -CURRENT with the new gcc, all these warnings for some reason
become errors. The other thing is, if I try this with with a ports-compiled
g++32 on 4-STABLE, I don't get warnings at all, no matter if -pedantic is
specified or not.
So here's the questions for the experts:
- Why errors instead of warnings?
- Why do gcc's own bits seem to not conform to some kind of standard that it
tries to adhere to in 5-CURRENT but not in 4-STABLE?
- Who's to blame?
--
Michael Nottebrock \KDE on FreeBSD\,ww
\--- \ ,wWWCybaWW_)
\ http://freebsd.kde.org \ `WSheepW'free
\II II node
pgp0.pgp
Description: signature
Re: Annoucning DragonFly BSD!
Julian Stacey [EMAIL PROTECTED] writes: Periodicaly someone masquerades as Matt Dilllon. Those targeted by trolls need to work extra hard to establish credibility of poster's address, to avoid suspicion of troll at work (phone number maybe?). Trolls of course need to work extra hard too, to also convince us. Maybe this time the poster is the real Matthew Dillon, but I doubt it. Idiot. $ whois dragonflybsd.org [...] Registrant: Matthew Dillon 41 Vicente Rd Berkeley, CA 94705 US Registrar: DOTSTER Domain Name: DRAGONFLYBSD.ORG Created on: 14-JUL-03 Expires on: 15-JUL-05 Last Updated on: 14-JUL-03 Administrative, Technical Contact: Dillon, Matthew [EMAIL PROTECTED] 41 Vicente Rd Berkeley, CA 94705 US 510 848 9745 Domain servers in listed order: APOLLO.BACKPLANE.COM NS.IDIOM.COM NS2.IDIOM.COM End of Whois Information 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: [kde-freebsd] Re: gcc-3.3 issues
On Friday 18 July 2003 10:32, I wrote: Now, if I compile this on 5.1-RELEASE with c++ -Wnon-virtual-dtor -Wno-long-long -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -DNDEBUG -DNO_DEBUG -O -pipe -mcpu=pentiumpro -fno-check-new -L/usr/local/lib -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include -D_GETOPT_H -o helloworld helloworld.cc This commandline is copy-paste from the failing configure checks, however, just 'c++ -pedantic -O -pipe -o helloworld helloworld.cc' should probably do the trick just as well. -- Michael Nottebrock \KDE on FreeBSD\,ww \--- \ ,wWWCybaWW_) \ http://freebsd.kde.org \ `WSheepW'free \II II node pgp0.pgp Description: signature
Re: gcc-3.3 issues
Michael Nottebrock [EMAIL PROTECTED] writes: There was one report of kdelibs' configure failing because of the weirdness of the new cc (3.3), that leads to errors instead of warnings with certain combinations of -W* and -pedantic options. gcc 3.3 is a lot stricter about some errors which earlier versions recovered from gracefully. Note that these are real errors, i.e. patently incorrect code which earlier versions of gcc happened to accept (sometimes by design, sometimes by mistake). 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: HPT372 bug summary [was: RE: escalation stage 2]
Harald Schmalzbauer wrote: Harald Schmalzbauer wrote: Ok, like I thought, the disk was not defect. There seems to be a bug in ata regarding HPT372 First: Wiht BIOS version 2.342 the secondary master disk id is incorrectly detected (something liek X X X X X X X X X X X X X X X instead of IC25N030ATCS04-0 Please forget that. It was because for convinience reasons I had turned the 80-pin ATA cables upside down. So the black was at the controller and the blue at the drive. I can't imagine that this makes any technical difference (as long as no slave drive is connected and there's no open end) But it seems the single connectors are electrical coded (again I can't imagine how?!?) The shielding wires are only grounded on one side of the connector. And then there is the cable select line. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with fxp0 on T30 with 5.1-RELEASE
On Thu, Jul 17, 2003 at 09:58:00AM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Tobias Roth [EMAIL PROTECTED] writes: this is caused by : an irq conflict. the bug was introduced some time between 5.0 and : 5.1. i have no idea how to solve this, maybe someone else can help : here. maybe the ibm ps2 tool offers some help. details? kevin oberman suggested the use of the ps2 utility for thinkpads. i did not have the chance to try it out myself. : another workaround is to free an irq. for me, disabling the pcmcia : stuff in the kernel config helped. others reported that disabling : the serial port helped for them. interesting. shortly after i discovered this problem, my TP started to have immense problems with the summer heat and started crashing during buildworlds. that's why i didn't look into the irq problem any further at this time. now, i just got my TP back from ibm, and while they did not really fix the heat problem (i will send it back to them next week), i got around to do some irq tests. irqs 0,1,8,12,13,14,15 are set and no subject of manual change. irq 2, i have no idea about. irq 3 and 4 are the infrared device and the serial port. irq 7 is the parallel port irq 6 can be freed by disabling legacy floppy support in the bios. however it does not seem be taken by a different device when freed. this leaves us with irqs 5,9,10,11 to distribute in the pci section of the bios. after some playing around, i set INT[A-H] PCI IRQ to 5,9,10,11,11,9,10,11. I do not know whether the order matters, but the distribution does. like this, every irq is assigned to two devices: 5-uhic0 and cbb0, 9-cbb1 and pcm0, 10-uhic2 and wi0, 11-uhic1 and fxp0. the only drawback i encountered with these settings was a short hang during boot when probing uhic2. it did not hang there before i started switching around irqs, but i do not know what is wrong here. other than that, everything works now. : this has to be fixed before 5.2, imho. it renders a default install : on thinkpads useless. note that this does NOT happen on all thinkpad : systems, i didn't figure out what makes up the difference. sounds like a bug that needs to be fixed, but the details are so vague as to make that impossible. chances are very good that someone with a clue (like me) will need a machine that fails to fix it. the only odd thing is that 5.0 did not have this bug, while 5.1 has it. if it needs fixing is up to you, i am now happy with the current solution. but then, the default bios settings are so stupid that it may not be feasable to do anything about it. hope that helps, t. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Compaq Evo N610c
Hello, I recently installed FreeBSD 5-1-Release onto a Compaq Evo N610c and upgraded to -Current. FreeBSD k9.home 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Wed Jul 16 08:26:32 EST 2003 [EMAIL PROTECTED]:/var/obj/space/usr/src/sys/GENERIC i386 There were problems when booting with ACPI (short term hanging), running sysctl -a (hanging) and getting pcmcia cards to be recognized. These have been described in emails from Robert ??? and Vaidas Damosevicius (who listed the hw.pci.allow_unsupported_io_range=1 fix). With the following in /boot/loader.conf these problem appear to to have been resolved. hw.pci.allow_unsupported_io_range=1 debug.acpi.disable=cmbat hw.acpi.verbose=1 (Well I dont think verbose helped, I just want to see more messages.) Without debug.acpi.disable=cmbat, the battery was seen but it complained about it being corrupted. How do you disable multiple drivers? Have multiple lines or a single disable with a delimited string? What delimiter? The man page for acpi could do with some examples I think. Testing card insertion/removal: aic1: Adaptec, Inc. APA-1460 SCSI Host Adapter at port 0x340-0x35f irq 11 function 0 config 9 on pccard0 aic1: AIC6360, dma, disconnection, parity check, fast SCSI aic1: detached I have only done insertion and removal, I havent actually tried to use device yet. Minor glitches: Switching to and from X can result in screen not being properly sync'd. Switching back and forth beween X and console or closing lid often fixes it but not always. From boot -v vga0: vga: WARNING: video mode switching is not fully supported on this adapter so this is a known problem. Any fixes? Suspending works - resumption does not :-( Any ideas? thanks -- tonym ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures
OK, here is one for graphics/svgalib:
--- src/vga.c.orig Fri Jul 18 13:27:40 2003
+++ src/vga.c Fri Jul 18 13:32:58 2003
@@ -3846,7 +3846,7 @@
#define ML_GETINT(x) \
ptr = strtok(NULL, ); if(!ptr) break; \
- mmt.##x = atoi(ptr);
+ mmt.x = atoi(ptr);
ML_GETINT(HDisplay);
ML_GETINT(HSyncStart);
Just abused concatenation...
But I'm pretty sure that the following is
what was intended, thusly the better patch:
--- src/vga.c.orig Fri Jul 18 13:27:40 2003
+++ src/vga.c Fri Jul 18 13:34:38 2003
@@ -3845,8 +3845,9 @@
mmt.pixelClock = atof(ptr) * 1000;
#define ML_GETINT(x) \
- ptr = strtok(NULL, ); if(!ptr) break; \
- mmt.##x = atoi(ptr);
+ do { ptr = strtok(NULL, ); if(!ptr) break; \
+ mmt.x = atoi(ptr); } \
+ while (0)
ML_GETINT(HDisplay);
ML_GETINT(HSyncStart);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Annoucning DragonFly BSD!
Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= wrote: To: Julian Stacey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Matthew Dillon [EMAIL PROTECTED] Date: Fri, 18 Jul 2003 10:48:17 +0200 Message-id: [EMAIL PROTECTED] Idiot. $ whois dragonflybsd.org [...] Registrant: Matthew Dillon Dag, Do not post personal abuse to the list ! I already covered whois, the day before: Date: Thu, 17 Jul 2003 17:14:05 +0200 (CEST) From: Julian Stacey [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] whois dragonflybsd.org Created on: 14-JUL-03 Whois Server:whois.dotster.com ... www.dotster.com/help/whois 1 page didnt respond, 1 wanted a login password ! Hmm, typing this command a second time I nopw see extra info: Registrant: Matthew Dillon 41 Vicente Rd ... I've a feeeling I didnt get that first time. ? whois didn't give me human traceable info first time, (maybe servers were reconfiguring, or there was a net problem, then I couldnt get any human info re. domain from other tools, just just the dotster block. Thanks to those who told me of `host` command (I'd only used `nslookup`, `whois` http://www.dnsreport.com, ( hadn't used `dig`)). Thanks to those who confirmed Matthew Dillon's announcement is real. Matthew, OK, you want a divergent kernel, EG src/sys/ , fair enough. - Are there any benefits to the BSD community in having a 4th BSD bin/ sbin/ usr.bin/ usr.sbin/ ? Can you not share co-operate with toolset maintainers of NetBSD or OpenBSD, even if you can't work with some FreeBSD CVS people ? - Do you intend your own ports/ collection too ? (or Free, Net or Open ?) - Julian Stacey Freelance Systems Engineer, Unix Net Consultant, Munich. Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Annoucning DragonFly BSD!
On Fri, Jul 18, 2003 at 02:47:48PM +0200, Julian Stacey wrote: - Are there any benefits to the BSD community in having a 4th BSD bin/ sbin/ usr.bin/ usr.sbin/ ? What does that have to do with anything? Matt is free to spend his time and resources as he sees fit. There is no BSD project fork approval board. 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: Keyboard not working with XFree86
Hi Again, Daniel Lang wrote on Wed, Jul 16, 2003 at 05:16:23PM +0200: [..] I've recently upgraded my Notebook to 5.1-CURRENT. One of the main problems I ran into, is, that the keyboard is not working when using X. [..] If I start up X, I cannot put in any key. The mouse works fine, though. I have to remote log into the box and kill xdm to get rid of the problem. The keyboard works perfectly on the console. [..] I could solve the problem. First to complete the symptoms: - Keyboard works on the console - Keyboard does not work using X (regardless of using 'xdm' oder 'startx') - ZapServer (Ctrl-Alt-Backspace) DOES work. This lead my investigation to a problem with the keymap, but the real cause turned out to be utterly obscure. The XKeysymDB file was missing! (And as I found out later, the XErrorDB file, as well). But, it was listed in the +CONTENTS file of the XFree86-libraries port. So apprently it has been installed? But maybe was removed by something else? I certainly did not remove these files. I could solve the problem easily by copying the files back into place, and I cannot rule out, that the files have been lost due to my fault. If any of the XFree port maintainers are aware of fiddling with XKeysymDB or the like, maybe there is indeed a problem. Best regards, Daniel -- IRCnet: Mr-Spock - In dieser Mail ist ein Geist, der Dich in den Hintern beisst - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ smime.p7s Description: S/MIME cryptographic signature
Re: Annoucning DragonFly BSD!
What does that have to do with anything? Matt is free to spend his time and resources as he sees fit. There is no BSD project fork approval board. I guess it was just a question don't flame him... -- Pierrick Brossin IT Employee - Quark Media House Switzerland Mail: pbrossin_AT_swissgeeks(dot)com Web: http://www.swissgeeks.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with fxp0 on T30 with 5.1-RELEASE
On Thu, Jul 17, 2003 at 09:58:00AM -0600, M. Warner Losh wrote: kevin oberman suggested the use of the ps2 utility for thinkpads. i did not have the chance to try it out myself. I also didn't have the time to look at it the last day and a half, but I have time this weekend so I'll definitely investigate. The part that I'm confused about is what's the 'ps2' utility? There's no mention of it in /usr/ports and the only things I can find with google are a DOS program by that name. Is that what you're referring to? If so, where do I get it? the only odd thing is that 5.0 did not have this bug, while 5.1 has it. if it needs fixing is up to you, i am now happy with the current solution. but then, the default bios settings are so stupid that it may not be feasable to do anything about it. This is the part that confuses me as well, but from 5.0 to 5.1 the fxp driver was completely re-written to use a different API so tracking down the specific problem is going to suck :( I also have XP on the laptop (for work stuff, honest! :) and it's working fine as well, so it's definitely a bug in 5.1. I'll also try getting -CURRENT /usr/src off another system and recompiling from scratch to see if that fixes the issue (not having net sucks! :) Dana Lacoste Ottawa, Canada PS: Someone had said that although they might be able to find the bug they'd need the affected hardware. Well, if you're between Toronto and Quebec City I could arrange a field trip for the weekend, but I'm not shipping my laptop to Europe :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld fails in 5.1
On Fri, 18 Jul 2003, Bruce Evans wrote: On Thu, 17 Jul 2003, Matt Loschert wrote: On Thu, 17 Jul 2003, Bruce Evans wrote: Try using make -P to unmix the output... I am not sure if this is useful or not, but I took your suggestion of using make -P, and now the build stops with the following output: ... Remaking `fdisk' Results of making fdisk: cc -O -pipe -mcpu=pentiumpro-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -static -o fdisk fdisk.o geom_mbr_enc.o 1 error *** Error code 2 Unfortunately, the critical error message still seems to be elsewhere. I think the error is not associated with fdisk (although it immediately follows the fdisk results) since cc would have printed a message if it (cc) failed. Bruce Bruce, Thanks for the information, it prompted me to look harder. I am not sure, but I may have found the problem. After grepping through the build log for error messages, I found the following output, which appears to be some sort of build loop gone wild: First this -- Results of making rescue.cache: MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue crunchgen -q -m rescue.mk -c rescue.c rescue.conf Then the following output repeated 363 times crunchgen: make error: Remaking `crunchgen_objs' crunchgen: make error: Results of making crunchgen_objs: crunchgen: make error: crunchgen: make error: Remaking `loop' crunchgen: make error: Results of making loop: crunchgen: make error: With the following output repeated 2 times within the above output -- Run make -f rescue.mk to build crunched binary. *** Error code 1 Results of making rescue.mk: MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue crunchgen -q -m rescue.mk -c rescue.c rescue.conf I suppose this means that there is a dependency missing for the rescue crunchgen target? - Matt -- Matt Loschert - Software Engineer | email: [EMAIL PROTECTED]| ServInt Internet Services | web: http://www.servint.net/ | McLean, Virginia USA| phone: (703) 847-1381 | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with fxp0 on T30 with 5.1-RELEASE
From: stark [EMAIL PROTECTED] Date: Fri, 18 Jul 2003 09:45:08 -0400 (EDT) On Thu, Jul 17, 2003 at 09:58:00AM -0600, M. Warner Losh wrote: kevin oberman suggested the use of the ps2 utility for thinkpads. i did not have the chance to try it out myself. I also didn't have the time to look at it the last day and a half, but I have time this weekend so I'll definitely investigate. The part that I'm confused about is what's the 'ps2' utility? There's no mention of it in /usr/ports and the only things I can find with google are a DOS program by that name. Is that what you're referring to? If so, where do I get it? It is available as a floppy image at the IBM download page. The Windows that came on the system will also have it. You need to either boot Windows or the DOS disk from IBM. ps2 is the IBM utility to adjust BIOS parameters. While these can also be adjusted under Windows, many are never written to CMOS and are lost on re-boot. (Windows re-loads them from the registry.) ps2 will change the values in CMOS memory. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
[cc: list trimmed]
On Fri, Jul 18, 2003 at 10:32:51AM +0200, Michael Nottebrock wrote:
I've tried to come up with a less obscure testcase:
#include string
#include iostream
using namespace std;
int main ()
{
string astring=Hello World;
cout astring endl;
}
Now, if I compile this on 5.1-RELEASE with
c++ -Wnon-virtual-dtor -Wno-long-long -Wall -pedantic -W -Wpointer-arith
-Wmissing-prototypes -Wwrite-strings -DNDEBUG -DNO_DEBUG -O -pipe
-mcpu=pentiumpro -fno-check-new -L/usr/local/lib -I/usr/local/include
-I/usr/local/include -I/usr/X11R6/include -D_GETOPT_H -o helloworld
helloworld.cc
I get a plethora of warnings:
In file included from /usr/include/g++/memory:55,
from /usr/include/g++/string:48,
from helloworld.cc:1:
/usr/include/g++/bits/stl_alloc.h:979: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:980: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
[and many, many more]
but it will compile. If I omit -pedantic, none of these warnings occur. The
thing is, in -CURRENT with the new gcc, all these warnings for some reason
become errors. The other thing is, if I try this with with a ports-compiled
g++32 on 4-STABLE, I don't get warnings at all, no matter if -pedantic is
specified or not.
So here's the questions for the experts:
- Why errors instead of warnings?
- Why do gcc's own bits seem to not conform to some kind of standard that it
tries to adhere to in 5-CURRENT but not in 4-STABLE?
- Who's to blame?
I haven't looked recently, but I seem to recall that the STL and other
C++ header bits that we install in /usr/include are from an older GCC
release than the compiler. On my pre-GCC 3.3 -CURRENT system:
System compiler:
% g++ -c -Wall -pedantic hello.cc
many warnings
GCC 3.2 from ports:
% g++32 -c -Wall -pedantic hello.cc
no warnings
GCC 3.3 from ports:
% g++33 -c -Wall -pedantic hello.cc
no warnings
I also recall lots of missing `typename's in the system headers that were
resolved in the actual GCC distribution.
Alexander, do the STL headers et. al. get updated with the rest of the
compiler chain?
Cheers,
--
Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
MSDOSFS patch of dirty flag (Darwin Import)
Hi All, I began to import some code from Darwin msdosfs. Here is my first patch about the dirty flag. I patched the msdosfs kernel module and fsck_msdos to enable the flag. Can someone test it and checked in? Must I submit a PR? From my own option, the new features of Darwin's msdosfs are dirty flag, adv_lock and unicode name. I will check them in the next week. Do these features have chance to commit? Jun Su __ 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]
Re: gcc-3.3 issues
On Friday 18 July 2003 17:37, Alexander Kabaev wrote: On Fri, 18 Jul 2003 10:33:58 -0500 Jacques A. Vidrine [EMAIL PROTECTED] wrote: I also recall lots of missing `typename's in the system headers that were resolved in the actual GCC distribution. Alexander, do the STL headers et. al. get updated with the rest of the compiler chain? Yes. But libstdc++ itself lags a bit behind GCC features. The reason why GCC ports are not reporting any errors is because by default GCC suppresses warnings from system headers, and C++ headers are considered system. We disable this suppression in imported compiler. I guess the next question is whether this is fixable, maybe even by enabling said supression, at least for a short while. It seems the better fix than to go and remove -pedantic from all the helloworlds that may linger in the ports-tree. -- Michael Nottebrock \KDE on FreeBSD\,ww \--- \ ,wWWCybaWW_) \ http://freebsd.kde.org \ `WSheepW'free \II II node pgp0.pgp Description: signature
Re: Fixing gcc 3.3 compile failures -- fix for audio/cmp3
[...]
If you are running 4.x, you can also help to develop fixes for these
ports by installing the gcc33 port and setting
CC=/usr/local/bin/gcc33
CXX=/usr/local/bin/g++33
[...]
Hi, since I have some spare time today, I fixed some of the broken
ports (I will start with those ports that are maintained by ports@).
I am running 4.8-STABLE with the g++33 (GCC) 3.3.1 20030707 port.
I will also check the fixed ports with the base systems gcc.
For clarity's sake I will one email per fixed port.
You will find the patches for audio/cmp3 attached to this email.
Regards,
Simon
--- cmp3listfiles.c.origFri Jul 18 17:55:33 2003
+++ cmp3listfiles.c Fri Jul 18 17:56:23 2003
@@ -270,13 +270,13 @@
/* XXX - alert person */
return;
fprintf(outfile,
-##
-# Dumped Cmp3 playlist ass file
-#
-# Addable features (on individual lines):
-# %%[command] - executes commands initially using system() call
-# @ - randomizes this playlist at load time
-# $ - turns on repeat mode at load time
+##\n\
+# Dumped Cmp3 playlist ass file\n\
+#\n\
+# Addable features (on individual lines):\n\
+# %%[command] - executes commands initially using system() call\n\
+# @ - randomizes this playlist at load time\n\
+# $ - turns on repeat mode at load time\n\
#\n\n);
filename = shmptr-plhead;
--- rnmp3.c.origFri Jul 18 18:00:43 2003
+++ rnmp3.c Fri Jul 18 18:02:36 2003
@@ -256,25 +256,21 @@
void usage()
{
-printf(rnmp3 %s:
-
-Usage - pipe names into rnmp3. (\find | rnmp3 args\)
-If first parameter starts with -, the following string will be removed
-from all names if they exist (enclose spaces with \\)
-If any other commands are entered, commands will not be executed,
-just printed
-
-rnmp3 Rename
-rnmp3 test Don't rename, just show changes
-rnmp3 -\string\ Rename after removing \string\
-rnmp3 -\string\ testDon't rename after removing \string\
-rnmp3 --test test Rename after removing \-test\
-
-Before - \1-This is my (file name) man.mp3\
-After - \01-ThisIsMy-FileName-Man.mp3\
-
-Suggested uses:
-find . | rnmp3
+printf(rnmp3 %s:\n\n\
+Usage - pipe names into rnmp3. (\find | rnmp3 args\)\n\
+If first parameter starts with -, the following string will be removed\n\
+from all names if they exist (enclose spaces with \\)\n\
+If any other commands are entered, commands will not be executed,\n\
+just printed\n\n\
+rnmp3 Rename\n\
+rnmp3 test Don't rename, just show changes\n\
+rnmp3 -\string\ Rename after removing \string\\n\
+rnmp3 -\string\ testDon't rename after removing \string\\n\
+rnmp3 --test test Rename after removing \-test\\n\n\
+Before - \1-This is my (file name) man.mp3\\n\
+After - \01-ThisIsMy-FileName-Man.mp3\\n\n\
+Suggested uses:\n\
+find . | rnmp3\n\
find . -type f | rnmp3\n, VERSION);
exit(0);
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for games/battleball
--- Makefile.orig Fri Jul 18 17:46:10 2003
+++ MakefileFri Jul 18 17:46:39 2003
@@ -21,11 +21,9 @@
MAKE_ENV= PTHREAD_LIBS=${PTHREAD_LIBS} \
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
-.include bsd.port.pre.mk
+CFLAGS += -Wno-deprecated
-.if ${OSVERSION} = 500113
-BROKEN= Does not compile (bad C++ code)
-.endif
+.include bsd.port.pre.mk
do-install:
@ ${INSTALL_PROGRAM} ${WRKSRC}/battleball ${PREFIX}/bin
--- lib3d/general.h.origFri Sep 3 04:25:19 1999
+++ lib3d/general.h Fri Jul 18 17:42:41 2003
@@ -25,9 +25,15 @@
typedef unsigned int uint;
typedef unsigned long ulong;
+#ifdef __GNUC__
+#if __GNUC__ 3
#define and
#define or ||
#define not !
+#endif
+
+// TODO - what about non-GNU C++ compilers?
+#endif
#define forii(limit) for (int i= 0; i limit; i++)
#define forij(limit) for (int j= 0; j limit; j++)
--- lib3d/xform.h.orig Fri Jul 18 17:28:08 2003
+++ lib3d/xform.h Fri Jul 18 17:26:11 2003
@@ -64,6 +64,7 @@
//===
class tmtrx {
+ friend struct player;
typedef double fourby3[4][3];
fourby3 m;
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for audio/cmp3
On Fri, Jul 18, 2003 at 06:23:32PM +0200, Simon Barner wrote: [...] If you are running 4.x, you can also help to develop fixes for these ports by installing the gcc33 port and setting CC=/usr/local/bin/gcc33 CXX=/usr/local/bin/g++33 [...] Hi, since I have some spare time today, I fixed some of the broken ports (I will start with those ports that are maintained by ports@). I am running 4.8-STABLE with the g++33 (GCC) 3.3.1 20030707 port. I will also check the fixed ports with the base systems gcc. For clarity's sake I will one email per fixed port. You will find the patches for audio/cmp3 attached to this email. [patches skipped] Committed, thanks! -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ pgp0.pgp Description: PGP signature
Re: Buildworld fails in 5.1
On Wed, Jul 16, 2003 at 02:24:18PM +, Bosko Milekic wrote: Same here, remove the -j N. Right now there seem to be some dependencies which you fail against with a parallel build. And it works here as well. Building with -j highlights a problem I'm seeing on a sparc64 though ... the stock Ultra 5 hard drive is abysmally slow. Bonnie++ reports: Version 1.93c --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP Caliban512M 8 95 1995 10 927 515 94 1893 6 54.9 17 Latency 1878ms 445ms2894ms1074ms 272ms5349ms Version 1.93c --Sequential Create-- Random Create Caliban -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 918 72 3008 82 2649 97 697 55 3112 89 2825 97 Latency 1665ms 51352us2797us1622ms 345ms2241us Compare this to a NFS mount (with options rw, intr, nfsv3, -w=32768, -r=32768) on the same box (an Ultra 5) from my vinum fileserver: Version 1.93c --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP Caliban512M4076 18 1764 174102 15 79.5 77 Latency 294ms 184ms 44630us1699ms This made the buildworld time /really/ slow: real1068m1.246s user904m49.768s sys 80m51.158s (buildkernel took about an additional ten hours). I'm hoping that replacing it with a more modern hard-drive should fix this, though I'll be poking through atacontrol and dmesg to see if it's a simple configuration problem. In the meantime it's actually faster for me to build off of an NFS mount. Heh. -T -- Page 461: Tools that are simple enough to use the first day are often a real pain after the first month. - Harley Hahn, _The Unix Companion_ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures -- fix for games/battleball
On Fri, Jul 18, 2003 at 06:36:31PM +0200, Simon Barner wrote: [patches skipped] Committed with some modifications, thanks! -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ pgp0.pgp Description: PGP signature
Re: gcc-3.3 issues
On Friday 18 July 2003 18:14, Alexander Kabaev wrote: Configure ailing due to warnings is a real bug. What do you mean now? Configure is not failing because of warnings, it is failing because of _ERRORS_, errors occur in gcc's libstdc++ bits. They _used to be warnings_ before the import. -- Michael Nottebrock \KDE on FreeBSD\,ww \--- \ ,wWWCybaWW_) \ http://freebsd.kde.org \ `WSheepW'free \II II node pgp0.pgp Description: signature
Re: MSDOSFS patch of dirty flag (Darwin Import)
On Fri, Jul 18, 2003 at 08:51:08AM -0700, Jun Su wrote: Hi All, I began to import some code from Darwin msdosfs. Here is my first patch about the dirty flag. I patched the msdosfs kernel module and fsck_msdos to enable the flag. Can someone test it and checked in? Must I submit a PR? From my own option, the new features of Darwin's msdosfs are dirty flag, adv_lock and unicode name. I will check them in the next week. Do these features have chance to commit? Jun Su Since we can't find an attached patch, just submit a PR and then post the PR number in reply to this thread. Thanks -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
[For some reason I haven't seen Alexander's post yet, so I'm mixing replies here.] On Fri, Jul 18, 2003 at 06:12:10PM +0200, Michael Nottebrock wrote: On Friday 18 July 2003 17:37, Alexander Kabaev wrote: On Fri, 18 Jul 2003 10:33:58 -0500 Jacques A. Vidrine [EMAIL PROTECTED] wrote: I also recall lots of missing `typename's in the system headers that were resolved in the actual GCC distribution. Alexander, do the STL headers et. al. get updated with the rest of the compiler chain? Yes. But libstdc++ itself lags a bit behind GCC features. The reason why GCC ports are not reporting any errors is because by default GCC suppresses warnings from system headers, and C++ headers are considered system. We disable this suppression in imported compiler. Ah, that didn't occur to me. Duh. I guess we shall just wait for libstdc++ to catch up --- it looks like at least some of these issues are already fixed in GCC CVS. I guess the next question is whether this is fixable, maybe even by enabling said supression, at least for a short while. It seems the better fix than to go and remove -pedantic from all the helloworlds that may linger in the ports-tree. Even when libstdc++ is updated, we'll still be left with warnings from C-derived headers, such as the `long long' stuff. That should be fixable in some other fashion, but such discussion probably belongs on [EMAIL PROTECTED] Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
fix print/gv (was: Re: Fixing gcc 3.3 compile failures)
On Thu, 17 Jul 2003, Kris Kennaway wrote: Most of the new compile failures are caused by 3 or 4 types of failure mode (all of which have to do with stricter standards compliance in the new compiler suite). I haven't yet looked at how to fix most of them: if you figure out a patch for a class of failures, please post it in response to this email so we can all see how to do it. http://bento.freebsd.org/errorlogs/i386-5-latest/gv-3.5.8_3.log In file included from Aaa.c:49: Aaa_intern.h:44:27: pasting / and Xlib does not give a valid preprocessing token Aaa_intern.h:44:27: pasting h and does not give a valid preprocessing token Aaa_intern.h:45:32: pasting / and Xresource does not give a valid preprocessing token Aaa_intern.h:45:32: pasting h and does not give a valid preprocessing token etc. etc. Put this patch as patch-source::paths.h into ports/print/gv/files: ---8--- --- source/paths.h.orig Sun Apr 6 00:00:00 1997 +++ source/paths.h Fri Jul 18 19:18:09 2003 @@ -34,9 +34,9 @@ # define INC_XMU(aaa) XMU_DIRECTORY/aaa # define INC_XAW(aaa) XAW_DIRECTORY/aaa #else -# define INC_X11(aaa) X11/##aaa## -# define INC_XMU(aaa) X11/Xmu/##aaa## -# define INC_XAW(aaa) X11/Xaw3d/##aaa## +# define INC_X11(aaa) X11/aaa +# define INC_XMU(aaa) X11/Xmu/aaa +# define INC_XAW(aaa) X11/Xaw3d/aaa #endif #endif /* _PATHS_H_ */ ---8--- regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universität Wien http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problem?
On Fri, 18 Jul 2003, Danny Braniss wrote: On Thu, 17 Jul 2003, Danny Braniss wrote: Your asl seems bogus since there are a lot of unexpected values (i.e. for TZ and EC port values). Since it worked in 4.8R, follow the instructions for disabling ACPI. -Nate thanks, that did it, but now, is there anyway i can help fix this so acpi will work? i have several of this boxes and booting them diskless will be a problem. Try man acpi: sorry, i guess i was not clear, i did 'unset acpi_load', and got the system up, i was offering to help in fixing the acpi (actually debugging, since my head hurts from reading the acpi stuff :-) Unfortunately your ASL appears to be the problem, not ACPI. The best thing you can do is try a BIOS update for your motherboard. If that doesn't help, use acpidump to get your DSDT and then start working on things according to: http://www.cpqlinux.com/acpi-howto.html This is not for the faint of heart so that's why I just suggested disabling acpi on your box. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
On Thursday 17 July 2003 08:14, David O'Brien wrote: I'm willing to commit it as such, but I'd like to hear more people's opinion. What I found so far: - gvim 6.2.21 works under 'twm' - gvim 6.2.21 works under 'kde 3.1' with SESSION_MANAGER unset - gvim 6.2.21 works under 'kde 3.1' if running on a remote machine tunneled through ssh's X11-redirection as reported by others: - gvim 6.2.21 works without patch 015 I looked at patch 015 but I'm not familiar with X11 SessionManagerProtocol - perhaps some others are able to analyze the correctness of that patch... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kldload(8) might panic
Hi,
on my 5.1R-box, I sometimes get the below panic message when loading a module into the
kernel with kldload(8).
It seems that some part of the linker reports a bogus value for the required memory.
Other times loading modules works fine.
Rene
Script started on Fri Jul 18 19:35:09 2003
[EMAIL PROTECTED]:/usr/home/rene$ uname -a
FreeBSD n188.dial.tue.nl 5.1-RELEASE FreeBSD 5.1-RELEASE #0: Thu Jul 17 15:34:28 CEST
2003 [EMAIL PROTECTED]:/usr/src-releng51/sys/i386/compile/RENE_2003-07-17 i386
[EMAIL PROTECTED]:/usr/home/rene$ cat /usr/tmp/gdbk.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: kmem_malloc(42766336): kmem_map too small: 55050240 total allocated
panic: from debugger
Uptime: 8h50m15s
Dumping 191 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176
---
Reading symbols from /boot/kernel/vesa.ko...done.
Loaded symbols for /boot/kernel/vesa.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/blank_saver.ko...done.
Loaded symbols for /boot/kernel/blank_saver.ko
Reading symbols from /boot/kernel/umodem.ko...done.
Loaded symbols for /boot/kernel/umodem.ko
#0 doadump () at ../../../kern/kern_shutdown.c:238
238 ../../../kern/kern_shutdown.c: No such file or directory.
in ../../../kern/kern_shutdown.c
(kgdb) bt full
#0 doadump () at ../../../kern/kern_shutdown.c:238
No locals.
#1 0xc024eafd in boot (howto=260) at ../../../kern/kern_shutdown.c:370
No locals.
#2 0xc024ef48 in panic () at ../../../kern/kern_shutdown.c:543
td = (struct thread *) 0xc226c000
bootopt = 260
newpanic = 0
buf = from debugger\0766336): kmem_map too small: 55050240 total allocated,
'\0' repeats 188 times
#3 0xc0130b75 in db_panic () at ../../../ddb/db_command.c:448
No locals.
#4 0xc0130ad2 in db_command (last_cmdp=0xc042b5e0, cmd_table=0x0,
aux_cmd_tablep=0xc0426f38, aux_cmd_tablep_end=0xc0426f3c)
at ../../../ddb/db_command.c:346
cmd = (struct command *) 0xc03eccb4
t = 0
modif =
\08ÌÏ\bâ9ÀÐß9ÀØÞ9À\200wJÀ`äHÀàeGÀ\b\217KÀP8ÌÏíÞ9À°Þ9À9ò(À`äHÀx\0\0\0àeGÀ\b\217KÀx8ÌÏ\a/\023À°.\023À\215#\023À\0\0\0\0\020\0\0\0\b\217KÀáì;À.$\023Àð\\023À\020'\023Àx\0\0\0\003\0\0\0¼9ÌÏ
addr = -1069890249
count = -1
have_addr = 0
result = 0
#5 0xc0130c16 in db_command_loop () at ../../../ddb/db_command.c:470
No locals.
#6 0xc013446b in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
bkpt = 0
#7 0xc03ac205 in kdb_trap (type=3, code=0, regs=0xcfcc3974)
at ../../../i386/i386/db_interface.c:170
ef = 70
ddb_mode = 1
#8 0xc03c082c in trap (frame=
{tf_fs = -1069875176, tf_es = 16, tf_ds = -1068826608, tf_edi = -1037647872,
tf_esi = 1, tf_ebp = -808699456, tf_isp = -808699488, tf_ebx = 0, tf_edx = 0, tf_ecx =
0, tf_eax = -1069890250, tf_trapno = 3, tf_err = 0, tf_eip = -1069890249, tf_cs = 8,
tf_eflags = 663, tf_esp = -1069413180, tf_ss = -1069477935})
at ../../../i386/i386/trap.c:593
td = (struct thread *) 0xc226c000
p = (struct proc *) 0xc226bd20
sticks = 1
i = 0
ucode = 0
type = 3
code = 0
eva = 0
#9 0xc03ae1ee in calltrap () at {standard input}:96
No locals.
#10 0xc024ee9b in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:527
td = (struct thread *) 0xc226c000
bootopt = 256
newpanic = 1
buf = from debugger\0766336): kmem_map too small: 55050240 total allocated,
'\0' repeats 188 times
#11 0xc035c6ea in kmem_malloc (map=0xc082f0b0, size=42766336, flags=2)
at ../../../vm/vm_kern.c:339
offset = 3224838192
i = 3257833656
entry = (struct vm_map_entry *) 0xc0372440
addr = 3234832384
m = (struct vm_page *) 0x0
pflags = -1070128770
#12 0xc0370e3d in page_alloc (zone=0x0, bytes=0, pflag=0x0, wait=0)
at ../../../vm/uma_core.c:803
p = (void *) 0x0
#13 0xc037327e in uma_large_malloc (size=42766336, wait=2)
at ../../../vm/uma_core.c:2034
mem = (void *) 0x0
slab = (struct uma_slab *) 0xc22e98b8
flags = 2 '\002'
#14 0xc02413c1 in malloc (size=42766336, type=0xc045cd20, flags=2)
at ../../../kern/kern_malloc.c:240
indx = 42766336
va = 0xc226c000 ½Â
zone = (struct uma_zone *) 0xcfcc3b44
ksp = (struct malloc_type *) 0xc045cd20
#15 0xc0275ffc in kmupetext (nhighpc=3289623160)
at
Re: gcc-3.3 issues
On Friday 18 July 2003 19:23, Jacques A. Vidrine wrote: Even when libstdc++ is updated, we'll still be left with warnings from C-derived headers, such as the `long long' stuff. Warnings are perfectly fine with me, since they don't break anything. Putting bandaid around ports to avoid _errors_ in libstdc++ on the other hand doesn't strike me as productive. -- Michael Nottebrock \KDE on FreeBSD\,ww \--- \ ,wWWCybaWW_) \ http://freebsd.kde.org \ `WSheepW'free \II II node pgp0.pgp Description: signature
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
On Fri, 18 Jul 2003 19:36:50 +0200, Matthias Schuendehuette [EMAIL PROTECTED] wrote: On Thursday 17 July 2003 08:14, David O'Brien wrote: I'm willing to commit it as such, but I'd like to hear more people's opinion. What I found so far: - gvim 6.2.21 works under 'twm' - gvim 6.2.21 works under 'kde 3.1' with SESSION_MANAGER unset - gvim 6.2.21 works under 'kde 3.1' if running on a remote machine tunneled through ssh's X11-redirection as reported by others: - gvim 6.2.21 works without patch 015 I looked at patch 015 but I'm not familiar with X11 SessionManagerProtocol - perhaps some others are able to analyze the correctness of that patch... I have sent to the vim-dev mailing list yesterday, because I got the same problem. I gave them with info of vim ran under gdb and explained about that 6.2.015 patch cause the crash. The author of VIM uses FreeBSD as well, so hope he will look into this problem. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld fails in 5.1
Matt Loschert wrote: After grepping through the build log for error messages, I found the following output, which appears to be some sort of build loop gone wild: First this -- Results of making rescue.cache: MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue crunchgen -q -m rescue.mk -c rescue.c rescue.conf Then the following output repeated 363 times crunchgen: make error: Remaking `crunchgen_objs' crunchgen: make error: Results of making crunchgen_objs: crunchgen: make error: crunchgen: make error: Remaking `loop' crunchgen: make error: Results of making loop: crunchgen: make error: With the following output repeated 2 times within the above output -- Run make -f rescue.mk to build crunched binary. *** Error code 1 Results of making rescue.mk: MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue crunchgen -q -m rescue.mk -c rescue.c rescue.conf I suppose this means that there is a dependency missing for the rescue crunchgen target? Good work, Matt. I wrote the /rescue stuff and a lot of people have reported that it breaks parallel builds, but I haven't yet come up with anything. (In part, because I haven't yet managed to reproduce it. sigh) A couple of things look odd about this: 1) You should not be building 'rescue.mk' twice. That could be the problem right there, if the rescue.mk makefile is getting rebuilt (overwritten) while another build thread is using it. The dependencies in rescue/rescue/Makefile look right to me, but I could be missing something. 2) I can't find the 'crunchgen_objs' or 'loop' targets offhand. I'm doing a more extensive find/grep search right now to see if I can figure out where those are coming from. Somewhere in here is the answer to this problem, I just don't see it yet. Tim Kientzle P.S. Could you email me the log from your build that failed? Could you try a lower -j value? If -j 2 fails, for instance, that might be easier to diagnose. Thanks for all your help. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures
Hi !
For games/inform just some escaped newlines:
[ I already sent that to the maintainer,
but then again to avoid double `work'... ]
CUT
--- veneer.c.orig Fri Jul 18 15:38:34 2003
+++ veneer.cFri Jul 18 15:39:44 2003
@@ -250,10 +250,10 @@
#ifdef INFIX;if (obj has infix__watching) n=1;#endif;\
#ifdef DEBUG;if (debug_flag 1 ~= 0) n=1;#endif;\
if (n==1) {\
- #ifdef DEBUG;n=debug_flag 1;
+ #ifdef DEBUG;n=debug_flag 1;\
debug_flag=debug_flag-n;#endif;\
print \[ ~\, (name) obj, \~.\, (property) id, \(\;\
- switch(y) { 1: print a; 2: print a,\,\,b; 3: print
+ switch(y) { 1: print a; 2: print a,\,\,b; 3: print \
a,\,\,b,\,\,c;\
4: print a,\,\,b,\,\,c,\,\,d;\
5: print a,\,\,b,\,\,c,\,\,d,\,\,e;\
CUT
Cheers
Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld fails in 5.1
Tim Kientzle wrote: Matt Loschert wrote: Then the following output repeated 363 times crunchgen: make error: Remaking `crunchgen_objs' crunchgen: make error: Results of making crunchgen_objs: crunchgen: make error: crunchgen: make error: Remaking `loop' crunchgen: make error: Results of making loop: crunchgen: make error: A little more information: The word 'error' here concerns me, but the repetition is expected. Crunchgen writes out and runs a short makefile in order to grab build information from a particular program. Since /rescue has about 120 components, you should see 'crunchgen_objs' and 'loop' targets getting built about 120 times. Ummm... by '363 times', did you mean 363 lines or 363 copies of this six-line block? If the latter, then something is definitely getting rebuilt needlessly. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
Jacques A. Vidrine [EMAIL PROTECTED] writes: [For some reason I haven't seen Alexander's post yet, so I'm mixing replies here.] On Fri, Jul 18, 2003 at 06:12:10PM +0200, Michael Nottebrock wrote: On Friday 18 July 2003 17:37, Alexander Kabaev wrote: On Fri, 18 Jul 2003 10:33:58 -0500 Jacques A. Vidrine [EMAIL PROTECTED] wrote: I also recall lots of missing `typename's in the system headers that were resolved in the actual GCC distribution. Alexander, do the STL headers et. al. get updated with the rest of the compiler chain? Yes. But libstdc++ itself lags a bit behind GCC features. The reason why GCC ports are not reporting any errors is because by default GCC suppresses warnings from system headers, and C++ headers are considered system. We disable this suppression in imported compiler. [snip] Curiosity: Why does this suppression get disabled in the imported compiler? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
[snip] Curiosity: Why does this suppression get disabled in the imported compiler? I guess justification was to see warnings about FreeBSD's own header files. We dont want to hide warnings in them, we want to fix issues warnings report. C++ headers just a side effect of that decision. -- 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 issues
On Fri, Jul 18, 2003 at 07:07:55PM +0200, Michael Nottebrock wrote: Content-Description: signed data On Friday 18 July 2003 18:14, Alexander Kabaev wrote: Configure ailing due to warnings is a real bug. What do you mean now? Configure is not failing because of warnings, it is failing because of _ERRORS_, errors occur in gcc's libstdc++ bits. They _used to be warnings_ before the import. Then configure runs gcc with wrong parameters. In GCC 3.3 -pedantic implies -pedantic-error, unless -fpermissive is specified too. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
warning: inlining failed
Warner mentioned this was due to the gcc import. Nearly every part of the kernel that uses newbus or buf.h prints out lots of warnings. Can someone see about fixing this, whether it's by fixing our headers or build flags or gcc itself? I've already wasted a few reboot cycles because valid warnings were lost in the crowd. cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -I/usr/include -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_vfsops.c /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `compute_sb_data': @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:496: warning: called from here /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `ext2_unmount': @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:774: warning: called from here @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:780: warning: called from here @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:784: warning: called from here -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with umount and fsid?
I get an error when umounting a FAT filesystem on a USB flash drive. It appears the device is properly unmounted. Is this a case that needs to be fixed in our fsid code? It happens every time I unmount this device. laptop# mount /dev/ad0s4a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s4e on /usr (ufs, local, soft-updates) /dev/ad0s4f on /home (ufs, local, soft-updates) /dev/ad0s1 on /dos (msdosfs, local) procfs on /proc (procfs, local) /dev/da0s1 on /thumb (msdosfs, local) /dev/ad0s5 on /linux (ext2fs, local) laptop# camcontrol inquiry da0 pass1: Trek ThumbDrive Smart 1.11 Removable Direct Access SCSI-2 device pass1: Serial Number pass1: 1.000MB/s transfers laptop# umount /thumb umount: unmount of /thumb failed: No such file or directory umount: retrying using path instead of file system ID laptop# mount | grep da0 laptop# Thanks, 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 issues
Hi ! Then configure runs gcc with wrong parameters. In GCC 3.3 -pedantic implies -pedantic-error, unless -fpermissive is specified too. ??? The info page doesn't say so. If one can't trust the GNU info pages - what a mess, considered that they refuse to maintain proper manpages either... Confused. Please enlighten me. Cheers Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: warning: inlining failed
On Fri, Jul 18, 2003 at 12:18:14PM -0700, Nate Lawson wrote: Warner mentioned this was due to the gcc import. Nearly every part of the kernel that uses newbus or buf.h prints out lots of warnings. Can someone see about fixing this, whether it's by fixing our headers or build flags or gcc itself? I've already wasted a few reboot cycles because valid warnings were lost in the crowd. cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -I/usr/include -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_vfsops.c /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `compute_sb_data': @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:496: warning: called from here /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `ext2_unmount': @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:774: warning: called from here @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:780: warning: called from here @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:784: warning: called from here Does `-finline-limit=1200' (or bigger) help? I think GCC 3.3 added a warning for when inline functions generated `a lot' of instructions. In such a case, the function is not inlined. I believe this also happened with GCC 3.2, but it just didn't normally tell you about it. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
On Friday 18 July 2003 21:16, Alexander Kabaev wrote: On Fri, Jul 18, 2003 at 07:07:55PM +0200, Michael Nottebrock wrote: Content-Description: signed data On Friday 18 July 2003 18:14, Alexander Kabaev wrote: Configure ailing due to warnings is a real bug. What do you mean now? Configure is not failing because of warnings, it is failing because of _ERRORS_, errors occur in gcc's libstdc++ bits. They _used to be warnings_ before the import. Then configure runs gcc with wrong parameters. In GCC 3.3 -pedantic implies -pedantic-error, unless -fpermissive is specified too. That's perfectly fine for configure to do, since it would work if gcc wouldn't shoot its own foot by failing in libstdc++. What's the rationale of changing around these commandline parameters anyway I'm asking myself. But that's offtopic. -- Michael Nottebrock \KDE on FreeBSD\,ww \--- \ ,wWWCybaWW_) \ http://freebsd.kde.org \ `WSheepW'free \II II node pgp0.pgp Description: signature
Re: gcc-3.3 issues
??? The info page doesn't say so. If one can't trust the GNU info pages - what a mess, considered that they refuse to maintain proper manpages either... Confused. Please enlighten me. What kind of enlightenment are you looking for? gcc mailing list address is not secret, I suggest you to take it there if you feel so inclined. GCC _do_ maintain man pages, but in the manner which makes them very inconvenient to import into FreeBSD repo. Since they are now auto-generated from texinfo sources, we now need to merge local FreeBSD changes into .texi files. Wading though merge conflicts in texi files after each import is hardly my idea of fun, but I will not stop you for trying :) -- 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 issues
Hi ! What kind of enlightenment are you looking for? 0.17 e.g. 8-)) Seriously, I didn't mean to piss off anyone. Just wanted to learn about the *reason* of this incoherence. I apologize if the irony was way too masked. gcc mailing list address is not secret, I suggest you to take it there if you feel so inclined. See above. Wading though merge conflicts in texi files after each import is hardly my idea of fun, but I will not stop you for trying :) Well, how much worse is that compared to a `mergemaster -i' orgy from a 4.2 to a 4.8 ? Ugh, don't, no, let me be, argh... Sidestep: I *love* to see that my CPUTYPE=p4 is not downgraded anymore. Cheers Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel panic when kldload'ing nvidia without WITNESS_SKIPSPIN
Hello - When I kldload nvidia, i receive a kernel panic. options INVARIANTS options INVARIANT_SUPPORT options DDB options WITNESS panic: spin lock ctl.mtx_rm not in order list panic messages: --- Reading symbols from /usr/src/sys/i386/compile/WIND/modules/usr/src/sys/modules/ linux/linux.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/WIND/modules/usr/src/sys/modules/li nux/linux.ko.debug Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko #0 0xc0212dab in doadump () (kgdb) where #0 0xc0212dab in doadump () #1 0xc02133dc in boot () #2 0xc0213767 in panic () #3 0xc012d502 in db_panic () #4 0xc012d482 in db_command () #5 0xc012d5a5 in db_command_loop () #6 0xc01304a5 in db_trap () #7 0xc035108c in kdb_trap () #8 0xc0361e0a in trap () #9 0xc0352a78 in calltrap () #10 0xc02136f5 in panic () #11 0xc0238f64 in enroll () #12 0xc0237bf5 in witness_init () #13 0xc020a33b in mtx_init () #14 0xc2a5949b in nvidia_ctl_attach () from /boot/kernel/nvidia.ko #15 0xc2a5a934 in nvidia_attach () from /boot/kernel/nvidia.ko #16 0xc2a5a4fd in nvidia_pci_attach () from /boot/kernel/nvidia.ko #17 0xc022cc88 in DEVICE_ATTACH () #18 0xc022b237 in device_probe_and_attach () #19 0xc022bc7e in bus_generic_driver_added () #20 0xc022cf8f in BUS_DRIVER_ADDED () #21 0xc0229ed8 in devclass_add_driver () #22 0xc022c715 in driver_module_handler () #23 0xc0208c31 in module_register_init () #24 0xc0203320 in linker_file_sysinit () #25 0xc0203671 in linker_load_file () #26 0xc0205bd7 in linker_load_module () #27 0xc0204153 in kldload () #28 0xc0362723 in syscall () #29 0xc0352acd in Xint0x80_syscall () I tried a new kernel in which i add WITNESS_SKIPSPIN to the kernel config. It loaded and worked just fine. - David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compaq Evo N610c
On Fri, Jul 18, 2003 at 08:59:56PM +1000, Tony Maher wrote: Hello, I recently installed FreeBSD 5-1-Release onto a Compaq Evo N610c and upgraded to -Current. FreeBSD k9.home 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Wed Jul 16 08:26:32 EST 2003 [EMAIL PROTECTED]:/var/obj/space/usr/src/sys/GENERIC i386 With the following in /boot/loader.conf these problem appear to to have been resolved. hw.pci.allow_unsupported_io_range=1 debug.acpi.disable=cmbat hw.acpi.verbose=1 I did this today, mmm seems something is working (work around). But battery stats an apm like monitoring of the battery is not working any more. So what happens if the battery is empty? just system shutdown without saving of the memory and so? Testing card insertion/removal: aic1: Adaptec, Inc. APA-1460 SCSI Host Adapter at port 0x340-0x35f irq 11 function 0 config 9 on pccard0 aic1: AIC6360, dma, disconnection, parity check, fast SCSI aic1: detached Again i can use any of the wireless cards and ata card i own. One is a Lucent Orinoco Gold card and the other is a ASUS wl100 card (prism2.5) and both seem to be enabled but fail init state. Even the ASUS is being detected as a Lucent chip which is of course false it's a Prism 2.5 chipset. I have only done insertion and removal, I havent actually tried to use device yet. Minor glitches: Switching to and from X can result in screen not being properly sync'd. Switching back and forth beween X and console or closing lid often fixes it but not always. Those glitches are known it seems older ComPaQ laptops had the same issues long time ago. From boot -v vga0: vga: WARNING: video mode switching is not fully supported on this adapter so this is a known problem. Any fixes? Suspending works - resumption does not :-( Any ideas? Under 4.8 all works with my setup. I have to use 4.8 at home because of wireless access thanks -- tonym Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: ASMTP setup on 4.8
On Fri, 2003-07-18 at 13:10, Hajimu UMEMOTO wrote: Hi, On Fri, 18 Jul 2003 12:14:08 -0700 Drew Tomlinson [EMAIL PROTECTED] said: drew I've been trying to get saslauthd working with PAM on my 4.8-RELEASE but drew have been unsuccessful. Umm, it's strange. Actually, I didn't change any PAM related settings, and it is working here. drew I installed saslauthd from the ports. One of the problems is drew that the man page is unreadable. Is there some way to fix it? Okay, I found the problem, and I've just committed the fix. Please re-cvsup and try it. drew It's been a few weeks since I looked at it but I recall having to create drew a /usr/local/lib/sasl2/smtpd.conf file. What should the correct drew contents be? Though I have no experience with postfix, I heared that /usr/local/lib/sasl2/smtpd.conf is for postfix. Are you using sendmail? If so, it should be /usr/local/lib/sasl2/Sendmail.conf. drew And what might I need to put in /etc/pam.conf to make it all work. The `other' entries which are provided as default sould be sufficient for saslauthd. I didn't make any change into my /etc/pam.conf. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED] the most common Misconception of ASMTP and Cyrus is that CRAM-MD5 and DIGEST-MD5 and such work with PAM. They do not, you need to make sure that you are using PLAINTEXT or otherwise you will have to add users into /usr/local/etc/sasldb2 which is not exactly fun. As far as sendmail i'm not much of help I can explain it with Postfix pretty easily but I don't use Sendmail anymore alas. If you have any questions feel free to comment. -- I think we ought to be out there doing what we do best - making large holes in other people's countries. - George Carlin signature.asc Description: This is a digitally signed message part ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing on IBM BladeCenter HS20 (usb keyboard)
On Thu, 17 Jul 2003, Geoff Buckingham wrote: HS 20 is IBMs Serverwork GC-LE dual Xeon blade, it managment chassis contains usb floppy, cdrom, and usb to PS2 adapter for keyboard and mouse, these are only ever avilable to one blade at a time. I had a quick try to install from 5.1 iso this fails as the BTX loader can not see the CD once loaded. Not sure what you mean by this. This may indicate a system that does not support CD native booting. It might work with an ElTorito CD. Installing from floppy or PXE boot fails as syscons detects an at keyboard (probably to keep windows happy) and does not use the usb keyboard. if you set flag 0x1 on atkbd0 it should get around this issue. If the BIOS has a Legacy USB Keyboard feature, try disabling that. Setting flags in 5.X involves tweaking hints which is slightly non-inutitive, but you should be able to change it in userconfig on 4.X. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: HPT372 bug summary [was: RE: escalation stage 2]
Soeren Schmidt wrote: which is named FreeBSD) And that's why FreeBSD panics until I delete the mirror relationship. Well Highpoints way of dealing with broken arrays and lost disks are less than optimal, I've tried to do my best in the ATA driver to fool the HPT system, but its not perfect... Hmm, I chose the Highpoint based controller because they are supporting FreeBSD.. Ok, let's accept that a failed drive cannot be replaced without setting up a new machine, but at least I can determine *when* I do the maintanence since one drive is still running. But please allow me a few questions: Why does the machine panic when rebooting with one drive failed? Why does the rebuild process work fine under DOS? Have you ever tested the original HighPoint kld? (I wanted but the 5.0 is not working with 5.1!) What do I have to do to get your SIL0680-current changes into 5.1-release? (I have another production machine running with the silicon image). Thanks a lot, -Harry Since this is my most important server I can't help you the next weeks. On sunday I'll buy a SIL0680 based controller because I did the same test with it and it's working. Now I'm currently setting up FreeBSD and building a kernel with DDB. If you are not using 5.1-current the sil680 is dangerous until I get time to backport some critical fixes... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with fxp0 on T30 with 5.1-RELEASE
ps2 is the IBM utility to adjust BIOS parameters. While these can also be adjusted under Windows, many are never written to CMOS and are lost on re-boot. (Windows re-loads them from the registry.) ps2 will change the values in CMOS memory. I couldn't get ps2 to tell me anything interesting, but I entered the BIOS and put 5,7,9,10,11 for the first 5 PCI IRQ ids and left the last three on auto and ta-da! everything seems to be working. I'm using the GENERIC 5.1-RELEASE kernel so it's using cbb already (someone had asked that) and I can't see that anything else is failing (I don't have wi-fi and I had already disabled serial, IR, and parallel, so USB is the only thing left :) Woo-Hoo! This is the first time I've had 5.x working completely on my laptop. I'm very very appreciative. Thanks everyone! (Now we should probably find out WHY we have to set the IRQ assignments manually, but seeing as it works I'm not in a rush to find out. Feel free to suggest code changes and I'll be a guinea pig though :) Dana Lacoste Ottawa, Canada ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cyclades isa card not recognized on 5-current ?
On Fri, 18 Jul 2003, Bruce Evans wrote:
Hi,
just to also ask here before opening a bug report. Anyone successfully
using a cyclades (Yo8) ISA on FreeBSD 5.x/Current ?
I am unable to get it regonized on bootup.
...
A similar configuration still works for me with a slightly old version
of -current.
I have further digged into this and from what I can see
--- cy.c:cy_units ---
/* wait for the CD1400 to initialize itself */
for (i = 0; i 200; i++) {
DELAY(50);
/* retrieve firmware version */
firmware_version = cd_inb(iobase, CD1400_GFRCR,
cy_align);
if ((firmware_version 0xf0) == 0x40) {
break;
}
}
--- cut ---
firmware_version always is 0xff.
If I give another maddr in hints file than dip switches are set to
kernel aborts somwhere in sioprobe(dev) and will reboot so I assume
maddr really is set correct (also verified with cyclades manual
y_30.pdf again).
There is a Rev 5 oder 5.0 on the card.
Any more ideas ? I am willing to test any ideas/patches etc.
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with fxp0 on T30 with 5.1-RELEASE
From: stark [EMAIL PROTECTED] Date: Fri, 18 Jul 2003 17:46:51 -0400 (EDT) ps2 is the IBM utility to adjust BIOS parameters. While these can also be adjusted under Windows, many are never written to CMOS and are lost on re-boot. (Windows re-loads them from the registry.) ps2 will change the values in CMOS memory. I couldn't get ps2 to tell me anything interesting, but I entered the BIOS and put 5,7,9,10,11 for the first 5 PCI IRQ ids and left the last three on auto and ta-da! everything seems to be working. I'm using the GENERIC 5.1-RELEASE kernel so it's using cbb already (someone had asked that) and I can't see that anything else is failing (I don't have wi-fi and I had already disabled serial, IR, and parallel, so USB is the only thing left :) Woo-Hoo! This is the first time I've had 5.x working completely on my laptop. I'm very very appreciative. Thanks everyone! (Now we should probably find out WHY we have to set the IRQ assignments manually, but seeing as it works I'm not in a rush to find out. Feel free to suggest code changes and I'll be a guinea pig though :) Great to hear that it's working. Now I just wonder why you had to do this. My T30 has standard IRQs (most everything shares 11) and I have not seen this. My fxp0 works fine with CURRENT and has worked for quite some time, maybe since pre-5.0-Release. I typically update the system about once a week. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with fxp0 on T30 with 5.1-RELEASE
Kevin Oberman [EMAIL PROTECTED] wrote: Great to hear that it's working. Now I just wonder why you had to do this. My T30 has standard IRQs (most everything shares 11) and I have not seen this. My fxp0 works fine with CURRENT and has worked for quite some time, maybe since pre-5.0-Release. I typically update the system about once a week. Has the OP used ``hw.pci.allow_unsupported_io_range=1''? I had to use this with my A31 to prevent nasty fxp-related crashes in 5.1-RELEASE. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard not working with XFree86
On Fri, Jul 18, 2003 at 03:28:05PM +0200, Daniel Lang wrote: The XKeysymDB file was missing! (And as I found out later, the XErrorDB file, as well). The open-motif port used to spam this file with its own version, which would then be removed when the port was deinstalled. I think this is now fixed, which could explain why it is no longer present on your system. This kind of trespassing by packages is difficult to recover from automatically (i.e. there's no way to indicate that the usual dependency ordering should be violated and XFree86-libraries should be reinstalled *after* open-motif (which depends on XFree86-libraries)). The solution is to reinstall by hand the package that had its files stomped on. Developing smarter tools to make sure that packages do not stomp existing registered files would also be a benefit. Kris pgp0.pgp Description: PGP signature
Re: Problem with umount and fsid?
In message [EMAIL PROTECTED], Nate Lawson writes: I get an error when umounting a FAT filesystem on a USB flash drive. It appears the device is properly unmounted. Is this a case that needs to be fixed in our fsid code? It happens every time I unmount this device. laptop# umount /thumb umount: unmount of /thumb failed: No such file or directory umount: retrying using path instead of file system ID laptop# mount | grep da0 laptop# Thanks for the report - in theory this should only occur if you have a kernel from before July 1st but a newer userland. Assuming that's not the case, I must have overlooked something. Could you update to the latest sbin/mount, and then post the output of: mount -v | grep /thumb truss umount /thumb Thanks, Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
debugging a lockup
Hello - cu -l /dev/cuaa0 completely locks up my machine... How can I debug this? Thanks David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures -- fix for multimedia/avinfo
--- messages.c.orig Fri Jul 18 17:14:00 2003 +++ messages.c Fri Jul 18 17:14:42 2003 @@ -43,7 +43,7 @@ Author: %Z, Site: %U\n\ Comment: %p\n\n\ Audio codec information:\n\ -Signatire: %w\t\tName: %P\n +Signatire: %w\t\tName: %P\n\ AVInfo 0.7.1 \n,, struct-report,Struct report\n\n\ signature.asc Description: Digital signature
Re: Problem with umount and fsid?
On Sat, 19 Jul 2003, Ian Dowse wrote: In message [EMAIL PROTECTED], Nate Lawson writes: I get an error when umounting a FAT filesystem on a USB flash drive. It appears the device is properly unmounted. Is this a case that needs to be fixed in our fsid code? It happens every time I unmount this device. laptop# umount /thumb umount: unmount of /thumb failed: No such file or directory umount: retrying using path instead of file system ID laptop# mount | grep da0 laptop# Thanks for the report - in theory this should only occur if you have a kernel from before July 1st but a newer userland. Assuming that's not the case, I must have overlooked something. Could you update to the latest sbin/mount, and then post the output of: mount -v | grep /thumb truss umount /thumb Will do but first I'll update my kernel to see if that fixes it. It looks like it was just under the wire: FreeBSD laptop.example.org 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Mon Jun 30 03:09:24 PDT 2003 [EMAIL PROTECTED]:/e/scratch/obj/e/data/FreeBSD/5-src/sys/LAPTOP i386 Sorry for what looks like a false report. I must have overlooked updating my kernel due to the past boot problems gcc 3.3 caused. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compaq Evo N610c
Robert, debug.acpi.disable=cmbat I did this today, mmm seems something is working (work around). But battery stats an apm like monitoring of the battery is not working any more. So what happens if the battery is empty? just system shutdown without saving of the memory and so? This is expected since we are disabling battery acpi subsystem. And yes there is a downside :-( I'll test to see exactly what happens. Minor glitches: Switching to and from X can result in screen not being properly sync'd. Switching back and forth beween X and console or closing lid often fixes it but not always. Those glitches are known it seems older ComPaQ laptops had the same issues long time ago.=20 Ok. Are they 'unfixable' or no-one with sufficent vga knowledge has one of these? Under 4.8 all works with my setup. I have to use 4.8 at home because of wireless access Ok, good to know. I think I'll try to stick with -Current for now. thanks -- tonym ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: warning: inlining failed
Nate Lawson [EMAIL PROTECTED] writes: Warner mentioned this was due to the gcc import. Nearly every part of the kernel that uses newbus or buf.h prints out lots of warnings. Can someone see about fixing this, whether it's by fixing our headers or build flags or gcc itself? I've already wasted a few reboot cycles because valid warnings were lost in the crowd. cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -I/usr/include -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c [snip] -Wno-inline will disable warnings about functions not getting inlined. If the inlining is necessary, consider -finline-limit as suggested by another poster. I haven't tried it myself, but it seems probably harmless and at least useful for seeing those other warnings you'd like to see. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
Alexander Kabaev [EMAIL PROTECTED] writes: [snip] Curiosity: Why does this suppression get disabled in the imported compiler? I guess justification was to see warnings about FreeBSD's own header files. We dont want to hide warnings in them, we want to fix issues warnings report. Ok. This makes sense. However, if these warnings are disguising more important warnings in some ports, may I suggest people looking to fix warnings in those ports try compiling with -Wno-system-headers, which I believe will disable the warnings from gcc's headers. Of course anyone looking to fix warnings in headers should leave -Wsystem-headers on. C++ headers just a side effect of that decision. I guess this is evidence that #pragma GCC system_header isn't quite enough. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
Peter Kadau [EMAIL PROTECTED] writes: Hi ! Then configure runs gcc with wrong parameters. In GCC 3.3 -pedantic implies -pedantic-error, unless -fpermissive is specified too. ??? The info page doesn't say so. If one can't trust the GNU info pages - what a mess, considered that they refuse to maintain proper manpages either... Confused. Please enlighten me. You can look at the online docs: http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Warning-Options.html#Warning%20Options and search for -pendantic for the general description, and: http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/C---Dialect-Options.html#C++%20Dialect%20Options and search for permissive, to see the condition Alexander speaks of. (I'm new to FreeBSD, but I get the impression the FreeBSD gcc33 port changes a few gcc behaviors. So those docs won't be perfect. But they aren't in the first place, and are better than nothing until some does the hard work merging in documentation files.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: MSDOSFS patch of dirty flag (Darwin Import)
I can not make my MTA work.
To: [EMAIL PROTECTED]
From: Jun Su [EMAIL PROTECTED]
Reply-To: Jun Su [EMAIL PROTECTED]
Cc:
X-send-pr-version: 3.113
X-GNATS-Notify:
Submitter-Id: current-users
Originator:Jun Su
Organization: none
Confidential: no FreeBSD PRs are public data
Synopsis: [PATCH] MSDOSFS dirty path (importing from
Darwin)
Severity: non-critical
Priority: medium
Category: kern
Class: change-request
Release: FreeBSD 5.1-CURRENT i386
Environment:
System: FreeBSD junsufr.gwbn.sh.cn 5.1-CURRENT FreeBSD
5.1-CURRENT #1: Thu Jul 17 18:01:10 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO i386
Description:
A TODO item in the 5.2 Release Must Resolve List.
How-To-Repeat:
Fix:
diff -u /usr/src/sys/fs/msdosfs.orig/fat.h
msdosfs/fat.h
--- /usr/src/sys/fs/msdosfs.orig/fat.h Tue Mar 19
22:20:10 2002
+++ msdosfs/fat.h Mon Jul 14 21:02:10 2003
@@ -99,5 +99,6 @@
int freeclusterchain(struct msdosfsmount *pmp, u_long
startchain);
int extendfile(struct denode *dep, u_long count,
struct buf **bpp, u_long *ncp, int flags);
void fc_purge(struct denode *dep, u_int frcn);
+int markvoldirty(struct msdosfsmount *pmp, int
dirty);
#endif /* _KERNEL */
Only in msdosfs: fat.h.orig
diff -u /usr/src/sys/fs/msdosfs.orig/msdosfs_fat.c
msdosfs/msdosfs_fat.c
--- /usr/src/sys/fs/msdosfs.orig/msdosfs_fat.c Tue Mar
4 00:04:42 2003
+++ msdosfs/msdosfs_fat.c Mon Jul 14 21:02:10 2003
@@ -1106,3 +1106,70 @@
return (0);
}
+
+/* [2753891]
+ * Routine to mark a FAT16 or FAT32 volume as clean
or dirty by manipulating the upper bit
+ * of the FAT entry for cluster 1. Note that this
bit is not defined for FAT12 volumes, which
+ * are always assumed to be dirty.
+ *
+ * The fatentry() routine only works on cluster
numbers that a file could occupy, so it won't
+ * manipulate the entry for cluster 1. So we have to
do it here. The code is ripped from
+ * fatentry(), and tailored for cluster 1.
+ *
+ * Inputs:
+ * pmp The MS-DOS volume to mark
+ * dirty Non-zero if the volume should be marked
dirty; zero if it should be marked clean.
+ *
+ * Result:
+ * 0 Success
+ * EROFS Volume is read-only
+ * ? (other errors from called routines)
+ */
+int markvoldirty(struct msdosfsmount *pmp, int dirty)
+{
+int error;
+u_long bn, bo, bsize, byteoffset;
+u_long fatval;
+struct buf *bp;
+
+/* FAT12 does not support a clean bit, so don't
do anything */
+if (FAT12(pmp))
+return 0;
+
+/* Can't change the bit on a read-only filesystem
*/
+if (pmp-pm_flags MSDOSFSMNT_RONLY)
+return EROFS;
+
+/* Fetch the block containing the FAT entry */
+byteoffset = FATOFS(pmp, 1); /* Find the location
of cluster 1 */
+fatblock(pmp, byteoffset, bn, bsize, bo);
+
+error = bread(pmp-pm_devvp, bn, bsize, NOCRED,
bp);
+if (error) {
+brelse(bp);
+return (error);
+}
+
+/* Get the current value of the FAT entry and
set/clear the high bit */
+if (FAT32(pmp)) {
+/* FAT32 uses bit 27 */
+fatval = getulong(bp-b_data[bo]);
+if (dirty)
+fatval = 0xF7FF; /* dirty means
clear the clean bit */
+else
+fatval |= 0x0800; /* clean means set
the clean bit */
+putulong(bp-b_data[bo], fatval);
+}
+else {
+/* Must be FAT16; use bit 15 */
+fatval = getushort(bp-b_data[bo]);
+if (dirty)
+fatval = 0x7FFF; /* dirty means clear
the clean bit */
+else
+fatval |= 0x8000; /* clean means set the
clean bit */
+putushort(bp-b_data[bo], fatval);
+}
+
+/* Write out the modified FAT block immediately
*/
+return bwrite(bp);
+}
Only in msdosfs: msdosfs_fat.c.orig
diff -u /usr/src/sys/fs/msdosfs.orig/msdosfs_vfsops.c
msdosfs/msdosfs_vfsops.c
--- /usr/src/sys/fs/msdosfs.orig/msdosfs_vfsops.c Sun
Jun 29 03:05:59 2003
+++ msdosfs/msdosfs_vfsops.cMon Jul 14 21:02:11 2003
@@ -203,6 +203,11 @@
VOP_UNLOCK(devvp, 0, td);
}
pmp-pm_flags = ~MSDOSFSMNT_RONLY;
+
+/* [2753891] Now that the
volume is modifiable, mark it dirty */
+error = markvoldirty(pmp, 1);
+if (error)
+return error;
}
if (args.fspec == 0) {
#ifdef __notyet__ /* doesn't work correctly with
current mountd XXX */
@@ -603,8 +608,13 @@
*/
if (ronly)
pmp-pm_flags |= MSDOSFSMNT_RONLY;
- else
+ else {
+/* [2753891] Mark the volume dirty
while it is mounted read/write */
+if ((error = markvoldirty(pmp, 1)) !=
0)
+goto error_exit;
+
pmp-pm_fmod = 1;
+ }
mp-mnt_data
Re: Fixing gcc 3.3 compile failures -- fix for devel/ecgi
--- html2h/html2h.c.origSat Jul 19 02:31:37 2003
+++ html2h/html2h.c Sat Jul 19 02:32:42 2003
@@ -6,15 +6,15 @@
void usage()
{
- printf(
-html2h v0.1
-usage:
- html2h input.html [output.h]
-
- if output is not set, input.h will be generated and overwritten!
-
- debug messages are written to stderr!
-
+ printf(\
+html2h v0.1\n\
+usage:\n\
+ html2h input.html [output.h]\n\
+\n\
+ if output is not set, input.h will be generated and overwritten!\n\
+\n\
+ debug messages are written to stderr!\n\
+\n\
);
exit(0);
@@ -415,4 +415,4 @@
{
fprintf(stderr, %s%s\n, msg, comment);
exit(1);
-}
\ No newline at end of file
+}
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for math/freefem
--- freefem/fem/femDisk.cpp.origSat Jul 19 04:09:32 2003
+++ freefem/fem/femDisk.cpp Sat Jul 19 04:13:43 2003
@@ -95,7 +95,7 @@
char *result = 0;
int dummy;
-ifstream fin( path );
+std::ifstream fin( path );
if ( fin.fail() )
{
@@ -198,7 +198,7 @@
int i;
char *result = NULL;
-ofstream fout( path );
+std::ofstream fout( path );
if ( fout.fail() )
{
@@ -210,11 +210,11 @@
*/
if ((result = strstr (path,.amdba)) != NULL) /* amdba format */
{
- fout t-getNumberOfPoints() t-getNumberOfCells() endl;
+ fout t-getNumberOfPoints() t-getNumberOfCells() std::endl;
for (i = 0; i t-getNumberOfPoints(); i++)
{
- fout i+1 t-rp[i][0] t-rp[i][1] t-ng[i]
endl;
+ fout i+1 t-rp[i][0] t-rp[i][1] t-ng[i]
std::endl;
}
@@ -224,13 +224,13 @@
t-tr[i][0]+1
t-tr[i][1]+1
t-tr[i][2]+1
-t-ngt[i] endl;
+t-ngt[i] std::endl;
}
}
else if ((result = strstr (path,.am_fmt)) != NULL)/* am_fmt format */
{
#if 0
- fout t-getNumberOfPoints() t-getNumberOfCells() endl;
+ fout t-getNumberOfPoints() t-getNumberOfCells() std::endl;
dummy = 0;
for (i = 0; i t-getNumberOfCells(); i++)
@@ -238,39 +238,39 @@
fout t-tr[i][0]+1
t-tr[i][1]+1
t-tr[i][2]+1
- endl;
+ std::endl;
END_OF_LINE(data, dummy, 1);
}
if (dummy) fprintf(data,\n);
dummy = 0;
for (i = 0; i t-getNumberOfPoints(); i++)
{
- fout t-rp[i][0] t-rp[i][1] endl;
+ fout t-rp[i][0] t-rp[i][1] std::endl;
END_OF_LINE (data, dummy, 1);
}
if (dummy) fprintf(data,\n);
dummy = 0;
for (i = 0; i t-getNumberOfCells(); i++)
{
- fout t-ngt[i] endl;
+ fout t-ngt[i] std::endl;
END_OF_LINE (data, dummy, 9);
}
if (dummy) fprintf(data,\n);
dummy = 0;
for (i = 0; i t-getNumberOfPoints(); i++)
{
- fout t-ng[i] endl;
+ fout t-ng[i] std::endl;
END_OF_LINE (data, dummy, 9);
}
#endif
}
else
{
- fout t-getNumberOfPoints() t-getNumberOfCells() endl;
+ fout t-getNumberOfPoints() t-getNumberOfCells() std::endl;
for (i = 0; i t-getNumberOfPoints(); i++)
{
- fout t-rp[i][0] t-rp[i][1] t-ng[i] endl;
+ fout t-rp[i][0] t-rp[i][1] t-ng[i] std::endl;
}
@@ -279,7 +279,7 @@
fout t-tr[i][0]+1
t-tr[i][1]+1
t-tr[i][2]+1
-t-ngt[i] endl;
+t-ngt[i] std::endl;
}
}
return 0;
@@ -317,9 +317,9 @@
saveparam (fcts * param, femMesh * t, char *path, int N)
{
int k, ns = t-getNumberOfPoints();
-ofstream file (path);
+std::ofstream file (path);
file.precision (8);
-file nsN endl;
+file nsN std::endl;
for (k = 0; k ns; k++)
{
if (N == 1)
@@ -373,7 +373,7 @@
file (param)-nuyy2[k] ;
file ;
}
- file endl;
+ file std::endl;
}
file.close ();
return 0;
@@ -383,9 +383,9 @@
int
saveconst (creal f, char *path)
{
-ofstream file (path, ios::out | ios::app);
-// file.seekoff(0,ios::end,0);
-file f endl;
+std::ofstream file (path, std::ios::out | std::ios::app);
+// file.seekoff(0,std::ios::end,0);
+file f std::endl;
file.close ();
return 0;
}
--- freefem/fem/femGibbs.cpp.orig Sat Jul 19 04:10:36 2003
+++ freefem/fem/femGibbs.cppSat Jul 19 04:19:02 2003
@@ -38,6 +38,7 @@
#include math.h
#include stdio.h
#include stdlib.h
+#include string.h
//
// Freefem includes
@@ -1173,9 +1174,9 @@
{
f = new femPoint[ns];
for (i = 0; i ns; ++i)
-f[i] = rp[i];
+memcpy (f[i], rp[i], sizeof (femPoint));
for (i = 0; i ns; ++i)
-rp[r[i] - 1] = f[i];
+memcpy (rp[r[i] - 1], f[i], sizeof (femPoint));
for (j = 0; j nt; ++j)
for (i = 0; i 3; i++)
--- freefem/fem/femGraphicX11.cpp.orig Sat Jul 19 04:10:02 2003
+++ freefem/fem/femGraphicX11.cpp Sat Jul 19 04:12:31 2003
@@ -118,7 +118,7 @@
void
out_of_memory ()
{
- cerr FreeFEM error: operator new failed; not enough memory endl;
+ std::cerr FreeFEM error: operator new failed; not enough memory std::endl;
exit (-1);
}
--- freefem/fem/femMisc.cpp.origSat Jul 19 04:09:41 2003
+++ freefem/fem/femMisc.cpp Sat Jul 19
Re: Fixing gcc 3.3 compile failures -- fix for science/euler
--- metaps.c.orig Sat Jul 19 02:38:38 2003
+++ metaps.cSat Jul 19 02:39:09 2003
@@ -209,7 +209,7 @@
// rectangle clipping
// x1 y1 x2 y2 setclip
static char setclipmacro[]= /setclip {\n\
-gsave
+gsave\
/y2 exch def\n\
/x2 exch def\n\
/y1 exch def\n\
signature.asc
Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for shells/flash
--- screens/nc_about.c.orig Mon Jan 17 11:57:20 2000
+++ screens/nc_about.c Sat Jul 19 03:21:09 2003
@@ -86,856 +86,855 @@
*/
struct anim A[]=
-{{\
-
-___ _ __ __
- / / / / | / ___// / / /
- / /_ / / / /| | \\__ \\/ /_/ /
- / __/ / /___/ ___ |___/ / __ /
-/_/ /_/_/ |_//_/ /_/
-
-,1500},{\
-
-
-
- /\\
- / \\/\\
- /`/ / \\
--
-,40},{\
-
-
-
- /\\
- / \\/\\
- ` _ '/`/ / \\
--
-,40},{\
-
-
-
- /\\
- ` _ ' / \\/\\
- - (_) - /`/ / \\
--
-,40},{\
-
-
-
- ` _ '/\\
- - (_) - / \\/\\
-' ` /`/ / \\
--
-,40},{\
-
-
- ` _ '
- - (_) - /\\
-' `/ \\/\\
- /`/ / \\
--
-,40},{\
-
- ` _ '
- - (_) -
-' ` /\\
- / \\/\\
- /`/ / \\
--
-,100},{\
-
- ` _ '
-) - (_) -
-_) ' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
-_ ` _ '
- )- (_) -
-__) ' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
-__ ` _ '
- ) - (_) -
-___)' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
-___` _ '
- ) - (_) -
-) ' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ___ ` _ '
-( ) - (_) -
-_) ' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ___ ` _ '
-_( )- (_) -
-__) ' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ___ ` _ '
-__( ) - (_) -
-___)' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
-___` _ '
- __( ) - (_) -
-(___) ' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ___ ` _ '
- __( ) - (_) -
- (___) ' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ___ ` _ '
- __( )- (_) -
- (___) ' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ___ ` _ '
-__( ) (_) -
- (___)' ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
-___` _ '
- __( ) (_) -
-(___) ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ___ _ '
- __( )(_) -
- (___) ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ___ _ '
- __( )_) -
- (___) ` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- '
-__( )) -
- (___)` /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- `___ '
- __( ) -
-(___) /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ` ___ '
- __( ) -
- (___)/\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ` ___'
- -__( )-
- (___) /\\
- / \\/\\
- /`/ / \\
--
-,20},{\
-
- ` ___
- - _(( )
- (___) /\\
-
Re: debugging a lockup
On Fri, 18 Jul 2003, David Hill wrote: cu -l /dev/cuaa0 completely locks up my machine... How can I debug this? David, As usual, update your sources, enable all of the debugging options in your kernel config file, including DDB. Compile a kernel and ensure that you have an up-to-date world (Just to make sure that the issue hasn't already been fixed). To find out exactly where it's hanging, truss and strace are your friends. What's the last line that's printed out? Can you break to the debugger when the machine locks up (CTRL+ALT+ESC)? If so, can you get a backtrace by means of a 'tr'? Regards Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures -- fix for graphics/giram
Is marked broken: BROKEN=Fails to patch but the patches do apply and the port does build. signature.asc Description: Digital signature
Re: warning: inlining failed
On Fri, 18 Jul 2003, Jacques A. Vidrine wrote:
On Fri, Jul 18, 2003 at 12:18:14PM -0700, Nate Lawson wrote:
Warner mentioned this was due to the gcc import. Nearly every part of the
kernel that uses newbus or buf.h prints out lots of warnings. Can someone
see about fixing this, whether it's by fixing our headers or build flags
or gcc itself? I've already wasted a few reboot cycles because valid
warnings were lost in the crowd.
cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev
-I@/../include -I/usr/include -fno-common -mno-align-long-strings
-mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -c
/home/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_vfsops.c
/home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `compute_sb_data':
@/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK'
/home/src/sys/gnu/ext2fs/ext2_vfsops.c:496: warning: called from here
...
Does `-finline-limit=1200' (or bigger) help?
Maybe. It allows larger declared-inline functions to actually be inlined
of course. This probably helps performance negatively in the case of
large functions like BUF_LOCK.
I think GCC 3.3 added a warning for when inline functions generated `a
lot' of instructions. In such a case, the function is not inlined. I
believe this also happened with GCC 3.2, but it just didn't normally
tell you about it.
A warning (-Winline) about gcc not inlining a function because the
function involves a lot of instructions has existed for ages, and
FreeBSD has used it since since I reenabled it in 1997 in rev.1.6 of
bsd.kern.mk, but it was apparently broken in at least gcc-3.[1-2].
The main differences between gcc-3.2 and gcc-3.3 in this area seem to
be just that the warning actually works in gcc-3.3, and gcc-3.3 has
more options for quantifying a lot than anyone would want to know
about.
Since gcc now warns when it should, and successful inlining of all
inline functions in FreeBSD was apparently broken in gcc-3.1, gcc-3.3
now emits hundreds or thousands of warnings about functions that it
can't inline. -Wunline was supposed to let us fix bogus inlining
incrementatally, but this was defeated by it not working in gcc-3.[1-2].
E.g., according to my kernel backups, non-inlining of BUF_LOCK started
with gcc-3.1. Some relevant history:
1996/06/26: BUF_LOCK implemented (as an inline) in buf.h rev.1.71
2002/05/09: kernel built on this date by gcc-2.95.4 (20020320) has no
static copies of BUF_LOCK
2002/06/29: kernel built on this date by gcc-3.1 (20020529) has 11
static copies of BUF_LOCK
The new options for controlling inlining are:
-finline-linit=value
--param max-inline-insns=value
--param max-inline-insns-single=value
--param max-inline-insns-auto=value
--param min-inline-insns=value
--param max-inline-insns-rtl=value
See gcc.info for details.
I couldn't find a setting that I liked. Most things compile with
--param max-inline-insns-single=1600, which sort of corresponds to
-finline-linit=3200 (more than 5 times larger than the default).
A few files need amazingly larger values. Compiling with values
smaller than the default unconvered interesting bugs in the source
code (invalid asm and an unitiialized variable). What I want is
for leaf functions declared as inline to always be inlined unless
they are larger than some limit, but the gcc controls are mainly for
for limiting the size of non-leaf functions. Apparently-small
functions can become amazingly large due to nested inllining. This
gives inlining failures which are not entirely the fault of bloat in
the inline functions. E.g., the following trick (which is used a lot
in subr_mbuf.c and kern_descrip.c) doesn't actually give inline functions:
%%%
static inline int
bigfunc(int foo, int flags)
{
/* Large code. */
...
return (resultoflargecode);
}
static int
smallfunc1(int foo)
{
return (bigfunc(foo, 1));
}
static int
smallfunc2(int foo)
{
return (bigfunc(foo, 2));
}
static int
smallfunc3(int foo)
{
return (bigfunc(foo, 3));
}
...
%%%
This trick is used mainly to avoid repeating the relevant parts of
bigfunc() at the source level. Repeating them at the object level is
wanted and expected to do more than just avoid a function call since
large sections of code can be optimized away when `flags' has a constant
value. But gcc-3 doesn't like this trick since it gives large code
to inline. The effectivness of the desired inlining (or lack thereof)
is apparently null. No one noticed when the inlining stopped with
gcc-3.1 14 months ago. (I checked that the interesting inlining of
mb_alloc() was done on 2002/05/09
Re: Fixing gcc 3.3 compile failures -- fix for editors/hte
--- htapp.cc.orig Sat Jul 19 05:35:07 2003 +++ htapp.ccSat Jul 19 05:39:02 2003 @@ -2028,7 +2028,7 @@ get_stdbounds_tool(b); ht_project_window *project_window=new ht_project_window(); - project_window-init(b, project window, FS_KILLER | FS_TITLE | FS_NUMBER | FS_MOVE | FS_RESIZE, 0, (ht_project*)project); + project_window-init(b, project window, FS_KILLER | FS_TITLE | FS_NUMBER | FS_MOVE | FS_RESIZE, 0, (ht_project**)project); bounds k = b; k.x = b.w-2; signature.asc Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for science/gdis
--- rdf.c.orig Sat Jul 19 05:08:36 2003 +++ rdf.c Sat Jul 19 05:09:00 2003 @@ -445,8 +445,8 @@ printf(calculate_rdf(): a = %f b = %f c = %f alpha = %f beta = %f gamma = %f\n, model-pbc[0], model-pbc[1], model-pbc[2], model-pbc[3], model-pbc[4], model-pbc[5]); - printf(calculate_rdf(): latmat[0] = %f latmat[1] = %f latmat[2] = %f - \ncalculate_rdf(): latmat[3] = %f latmat[4] = %f latmat[5] = %f + printf(calculate_rdf(): latmat[0] = %f latmat[1] = %f latmat[2] = %f\ + \ncalculate_rdf(): latmat[3] = %f latmat[4] = %f latmat[5] = %f\ \ncalculate_rdf(): latmat[6] = %f latmat[7] = %f latmat[8] = %f\n, model-latmat[0], model-latmat[1], model-latmat[2], model-latmat[3], model-latmat[4], model-latmat[5], signature.asc Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for sysutils/lsmlib
--- main.c.orig Sat Jul 19 06:04:26 2003 +++ main.c Sat Jul 19 06:03:37 2003 @@ -21,7 +21,7 @@ #define USAGE usage: lsm [-h] [-o file] [dir] \n \ \n \ \th \t: print this help message\n \ -\tv \t: print current version\n +\tv \t: print current version\n\ \to file \t: use file as output \n\n\n\ signature.asc Description: Digital signature
Re: Fixing gcc 3.3 compile failures -- fix for x11/imwheel
The attached patch includes the existing patch file patch-ab, which is
obsolete now.
--- util.c.orig Tue Oct 31 13:06:05 2000
+++ util.c Sat Jul 19 05:45:59 2003
@@ -330,11 +330,11 @@
fclose(f);
if(pid0 useFifo)
{
- fprintf(stderr,\
-ERROR: imwheel is already running or there is a stale pid file
- check on processes listed below.
- run with -k to kill running imwheels.
- remove pid file %s.
+ fprintf(stderr,\n\
+ERROR: imwheel is already running or there is a stale pid file\n\
+ check on processes listed below.\n\
+ run with -k to kill running imwheels.\n\
+ remove pid file %s.\n\
or run with -p to avoid the pid file altogether.\n,PIDFILE);
if((f=fopen(PIDFILE,r)))
{
@@ -710,7 +710,7 @@
struct WinAction *getRC()
{
- char fname[2][1024]={,/etc/imwheelrc}, line[1024], *p, *q, winid[1024];
+ char fname[2][1024]={,/usr/X11R6/etc/imwheelrc}, line[1024], *p, *q,
winid[1024];
int fi,i;
struct WinAction *newwa=NULL;
FILE *f=NULL;
signature.asc
Description: Digital signature
Re: cyclades isa card not recognized on 5-current ?
On Fri, 18 Jul 2003, Bjoern A. Zeeb wrote:
I have further digged into this and from what I can see
--- cy.c:cy_units ---
/* wait for the CD1400 to initialize itself */
for (i = 0; i 200; i++) {
DELAY(50);
/* retrieve firmware version */
firmware_version = cd_inb(iobase, CD1400_GFRCR,
cy_align);
if ((firmware_version 0xf0) == 0x40) {
break;
}
}
--- cut ---
firmware_version always is 0xff.
This usually means that the maddr is wrong or that the hardware is not
there for some other reason. A normal hex dump of cyclades isa memory
looks something like this
(output from dd if=/dev/mem bs=1 iseek=0xd4000 count=0x2000 | hd):
%%%
00 00 00 00 00 00 82 82 00 00 00 00 00 00 00 00 ||
0010 13 13 00 00 06 06 08 08 00 00 26 26 00 00 00 00 |..|
0020 00 00 34 34 00 00 00 00 00 00 10 10 10 10 a0 a0 |..44|
0030 18 18 26 26 00 00 00 00 00 00 00 00 08 08 00 00 |..|
0040 00 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00 ||
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
0080 46 46 00 00 00 00 00 00 00 00 00 00 00 00 47 47 |FFGG|
...
%%%
Values at even offsets are always repeated at the next (odd) offset.
CD1400_GFRCR is at offset 0x80 (contents 0x46 in the above).
If I give another maddr in hints file than dip switches are set to
kernel aborts somwhere in sioprobe(dev) and will reboot so I assume
maddr really is set correct (also verified with cyclades manual
y_30.pdf again).
The abort is a bit unusual since the cyclades probe is not very invasive.
There is a Rev 5 oder 5.0 on the card.
I think mine is much older (model 8Yb).
Did you say that it worked under old versions of FreeBSD?
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MSDOSFS patch of dirty flag (Darwin Import)
Jun Su wrote: I began to import some code from Darwin msdosfs. Here is my first patch about the dirty flag. I patched the msdosfs kernel module and fsck_msdos to enable the flag. Can someone test it and checked in? Must I submit a PR? From my own option, the new features of Darwin's msdosfs are dirty flag, adv_lock and unicode name. I will check them in the next week. Do these features have chance to commit? Not if you never get them published. If you want to send attachments to the mailing list and have them get through, you need to send them as text/plain. The best way to see why your patches are not making it to the mailing list is to look at your last patch posting, and see what's difference between your signature and your file attachments, and make your file attachments look like your signature attachment (since it got through). On a side note, you probably do not want to corsspost between the -hackers and -current lists so much. A lot of us are subscribed to both of them, so we get two copies. For some of us, this triggers SPAM filtering, and we never see your posts, unless we save SPAM to a folder instead of deleting it, and go look at it occasionally. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: warning: inlining failed
Nate Lawson wrote: /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `ext2_unmount': @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' Warning: compiler failed to do what the hell it was told to do. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
