Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)
Mike Tancsa wrote: At 10:34 PM 10/5/2006, Kris Kennaway wrote: Based on successful testing on a machine with shared em interrupt, the following patch should work around the problem *in that case*. Note that this patch will not help you if you are not using the em driver, or if you are seeing the problem with non-shared em interrupt (I have investigated on such outlier, which seems to be a problem with a particular model of em hardware and not a generic problem with the driver). Please let Scott and I know whether or not this patch works for you (in addition to the information previously requested, if you have not already sent it). Unfortunately it is only a workaround, but it points to an underlying problem with fast interrupt handlers on a shared irq that can be studied separately. I ran into a em0 timeout on a box I just started testing. The patch seems to fix the issue. (before the patch) Oct 13 21:42:56 am64 kernel: em0: watchdog timeout -- resetting Oct 13 21:42:56 am64 kernel: em0: link state changed to DOWN Oct 13 21:42:58 am64 kernel: em0: link state changed to UP dmesg with patch Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #2: Fri Oct 13 22:28:38 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/up ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.71-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x649d> AMD Features=0x2800 Logical CPUs per core: 2 real memory = 3481198592 (3319 MB) avail memory = 3360186368 (3204 MB) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi0: reservation of 500, 10 (4) failed acpi0: reservation of 560, 20 (4) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 2.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: at device 0.0 on pci2 pci4: on pcib2 pcib3: at device 0.2 on pci2 pci3: on pcib3 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 twa0: <3ware 9000 series Storage Controller> port 0xef80-0xefbf mem 0xfebff000-0xfebf irq 53 at device 2.0 on pci3 twa0: [GIANT-LOCKED] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-4LP, 4 ports, Firmware FE9X 3.01.01.028, BIOS BE9X 3.01.00.024 uhci0: port 0xcc00-0xcc1f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcc80-0xcc9f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xcd00-0xcd1f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfe9ff800-0xfe9ffbff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib4: at device 30.0 on pci0 pci1: on pcib4 em0: port 0xdf80-0xdfbf mem 0xfeae-0xfeaf irq 18 at device 3.0 on pci1 em0: Ethernet address: 00:0e:0c:4b:15:eb isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xcf80-0xcf87,0xcf00-0xcf03,0xce80-0xce87,0xce00-0xce03,0xcd80-0xcd8f mem 0xfe9ffc00-0xfe9f irq 19 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [
Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)
At 12:31 AM 10/14/2006, Scott Long wrote: Mike, I have a new patch that I hope addresses the actual bug, instead of shuffling the timing. Would you be willing to test it? I can't guarantee that it's safe for production use yet, though. It seems to work, but it might set your dog on fire too. Yes, for sure as the box is just for testing mysql right now. I dont think we will end up even using it in production as the whole MB runs insanely hot. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)
At 10:34 PM 10/5/2006, Kris Kennaway wrote: Based on successful testing on a machine with shared em interrupt, the following patch should work around the problem *in that case*. Note that this patch will not help you if you are not using the em driver, or if you are seeing the problem with non-shared em interrupt (I have investigated on such outlier, which seems to be a problem with a particular model of em hardware and not a generic problem with the driver). Please let Scott and I know whether or not this patch works for you (in addition to the information previously requested, if you have not already sent it). Unfortunately it is only a workaround, but it points to an underlying problem with fast interrupt handlers on a shared irq that can be studied separately. I ran into a em0 timeout on a box I just started testing. The patch seems to fix the issue. (before the patch) Oct 13 21:42:56 am64 kernel: em0: watchdog timeout -- resetting Oct 13 21:42:56 am64 kernel: em0: link state changed to DOWN Oct 13 21:42:58 am64 kernel: em0: link state changed to UP dmesg with patch Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #2: Fri Oct 13 22:28:38 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/up ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.71-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x649d> AMD Features=0x2800 Logical CPUs per core: 2 real memory = 3481198592 (3319 MB) avail memory = 3360186368 (3204 MB) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi0: reservation of 500, 10 (4) failed acpi0: reservation of 560, 20 (4) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 2.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: at device 0.0 on pci2 pci4: on pcib2 pcib3: at device 0.2 on pci2 pci3: on pcib3 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 twa0: <3ware 9000 series Storage Controller> port 0xef80-0xefbf mem 0xfebff000-0xfebf irq 53 at device 2.0 on pci3 twa0: [GIANT-LOCKED] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-4LP, 4 ports, Firmware FE9X 3.01.01.028, BIOS BE9X 3.01.00.024 uhci0: port 0xcc00-0xcc1f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcc80-0xcc9f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xcd00-0xcd1f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfe9ff800-0xfe9ffbff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib4: at device 30.0 on pci0 pci1: on pcib4 em0: port 0xdf80-0xdfbf mem 0xfeae-0xfeaf irq 18 at device 3.0 on pci1 em0: Ethernet address: 00:0e:0c:4b:15:eb isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xcf80-0xcf87,0xcf00-0xcf03,0xce80-0xce87,0xce00-0xce03,0xcd80-0xcd8f mem 0xfe9ffc00-0xfe9f irq 19 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" d
Machine hangs when loading snd_emu10k1
Hi everyone. I rebooted my machine today and when it came back up and I tried to load the snd_emu10k1 kernel module, the machine hung without returning to the prompt. I tried waiting 5-10+ minutes and it was totally irrecoverable. At that point, nothing had changed since the last reboot so it was weird that it would happen all of a sudden. Last week I did cvsup to RELENG_6 after 6.2 BETA 2 was out and built world/kernel with the intent to update and use it, but I never got around to finishing the process (I had not installed anything either, so it was just sitting all built). So tonight when the hanging of emu10k1 happened, I did the installkernel/installworld process as normal thinking something might have been fixed between my previous cvsup (September 21 I believe) and my current one from Oct 5. Unfortunately there was no change in behavior -- it hung again and I waited at least 10 minutes before hard rebooting. I'm currently running: FreeBSD amd64.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #15: Thu Oct 5 17:52:05 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AMD643000 amd64 With a Sound Blaster Augidy 2 Platinum: [EMAIL PROTECTED]:8:0: class=0x040100 card=0x10021102 chip=0x00041102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'SoundBlaster Audigy Audigy Audio Processor' class= multimedia subclass = audio [EMAIL PROTECTED]:8:1: class=0x098000 card=0x00601102 chip=0x70031102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10K2 Audigy Gameport' class= input device [EMAIL PROTECTED]:8:2: class=0x0c0010 card=0x00101102 chip=0x40011102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10K2 Audigy IEEE1394 Firewire Controller' class= serial bus subclass = FireWire Later on tonight I can try to cvsup to RELENG_6 and rebuild again to see if it has been fixed already, but I need my CPU power for some encoding at the moment. Also, I'd rather not have to do a third hard reboot with an hour long fsck for seven hard drives, so I wanted to post here first in case it's known already or if anyone has any suggestions before doing it again. Thanks in advance. -Mark -- Internet Radio: Party107 (Trance/Electronic) - http://www.party107.com Rock 101.9 The Edge (Rock) - http://www.rock1019.net IRC: MIXXnet IRC Network - irc.mixxnet.net (Nick: MIXX941) dmesg.boot Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
On Thu, 12 Oct 2006, Jeremie Le Hen wrote: I am all for it. According to this thread, it appears the 4.x branch is still used for whatever reasons, may they be perceived good or bad depends on one's own consideration and feeling. If the FreeBSD Project is going to relinquish RELENG_4 support because of lack of interest from the developpers -- and I can understand this --, it would not hurt though to arrange a place where people still interrested in RELENG_4 could talk together, exchange tricks and patches and so to continue a kind of unofficial support. Although this may appear as a loose and slack support, it is yet better than having nothing, IMHO. FWIW, it's important to remember that what the security officer is doing is not saying that 4.x cannot be supported, it's saying that they no longer guarantee it will be supported. If someone decides to support 4.x anyway, then that's not a problem. This is more about recognizing the reality that the vast majority of new work on FreeBSD is on the 7.x and 6.x branches. If there are people who want to continue to support 4.x, there's nothing preventing from doing that. Existing FreeBSD developers will still be able to commit to the 4.x branches. We will still be able to give commit access to people who turn up who show consistent contributions (and all the normal criteria for a new committer) and are interested in continuing to support 4.x. This is a community project: if people turn up to do the work, and do it well, we're not going to stop them. "Official" support has to do with recognizing that we're doing a good job in supporting something, and that the hands are there to do it. What we're trying to avoid here by announcing EOL's is people incorrectly assuming that something that is not being supported is being supported. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
On Thu, 12 Oct 2006, Kris Kennaway wrote: On Thu, Oct 12, 2006 at 09:59:10AM -0400, Vivek Khera wrote: On Oct 11, 2006, at 6:36 PM, Paul Allen wrote: I think the most likely path of success is, as you say, to make the 4.x userland more like 6.x. For anyone who really wishes to stick to freebsd 4.x for performance, we should refer them to dragonflybsd, which seems to be taking this approach. it was forked from freebsd 4.8 and seems to pretty modern in userland. Well, this is pretty unsubstantiated...it doesn't automatically follow that because they forked from FreeBSD 4 they will retain all the characteristics of FreeBSD 4. FreeBSD 6.x is also a forked 4.x, FWIW :-). Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
On Thu, 12 Oct 2006, Edward B. DREGER wrote: Perhaps work on 7 should have been delayed until 5 and 6 were able to woo people away from 4 -- or at least not leave valid reasons for people wanting to stay behind. (Note that I'm more sympathetic than my tone might indicate; I've also gotten into some jams from long release cycles, and know what it's like.) I think this misconstrues the trade-off. That's like saying "Work on 5.x instead of 6.x". 6.x is 5.x, just significantly refined and improved. 7.x is 6.x, just significantly refined and improved. There are some improvements that are too agressive to MFC, and those are what will constitute the difference between 6.x and 7.0. For example, there are a set of socket layer stabilization/cleanup improvements that I've not yet MFC'd, and may not do so (they've been in the tree for 6-7 months and appear to be good, but need a lot of shake-out). But many of the changes going into 7.x sit there for a period of a few months to stabilize, and then go into 6.x. Right now this MFC pipeline is working quite well, but it's worth keeping in mind that if we MFC'd all the improvements from 6.x to 5.x, it would simply be 6.x, and it would be easier if people switched to 6.x than have us merge all the changes. :-) Robert N M Watson Computer Laboratory University of Cambridge What's done is done, though. Rather than spend undue effort on 4 and 5, improving 6 and 7 is the best way to improve the newer branches... which might well remove objections to jumping from 4. i.e., I like 4.x just as much as anyone else, but there's a bigger picture to consider. *shrug* As others have pointed out, if things really are "that bad", third-party support makes sense. And nothing is stopping anyone from running NetBSD, DragonFly, or OpenBSD. Or Solaris. Or Linux. Or... [ end bikeshed contribution ] Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
On Fri, Oct 13, 2006 at 04:52:18PM -0400, Vivek Khera wrote: > > On Oct 13, 2006, at 4:07 PM, Ruslan Ermilov wrote: > > >OK, please try merging my fix then, it should help. > >Please come back to me with a success report. :-) > > I applied the patch to bring i386/acpica/Makefile up to version 1.7 > > Same exact error on buildkernel -j2, but success without -j2. > > I put up logs + kernel config at http://vivek.khera.org/scratch/ > buildkernel/ > That one has been fixed in RELENG_6, in src/sys/conf/files.i386: : revision 1.538.2.7 : date: 2006/05/25 20:25:44; author: ru; state: Exp; lines: +1 -1 : MFC: 1.545: Add missing acpi_wakecode.h dependency on assym.s. : : : /usr/src/sys/i386/acpica/acpi_wakecode.S:35:19: assym.s: No such file or directory : : /usr/src/sys/i386/acpica/acpi_wakecode.S: Assembler messages: : : /usr/src/sys/i386/acpica/acpi_wakecode.S:103: Error: suffix or operands invalid for `ljmp' : : Reported by:many Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpYUgefyPAmv.pgp Description: PGP signature
Re: FreeBSD and "make -j# buildworld" usability
On Oct 13, 2006, at 4:07 PM, Ruslan Ermilov wrote: OK, please try merging my fix then, it should help. Please come back to me with a success report. :-) I applied the patch to bring i386/acpica/Makefile up to version 1.7 Same exact error on buildkernel -j2, but success without -j2. I put up logs + kernel config at http://vivek.khera.org/scratch/ buildkernel/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
On Friday 13 October 2006 07:31, Buki wrote: > Hi, > > I searched the archives and web a little but found many different > opinions on stability/usability of using make -j# with buildworld > (and buildkernel). > > So I am asking if it is a good idea to use make -j on production > boxes. > I tested buildworlds with different values for -j. On single processors, using a script that basically looked like time make -j? ... yielded fastest builds when I didn't specify a value for -j. On dual cpu's a value around -j8 yielded the fastest build. I am not interested in system and user time. To me the fastest build is the one that produced the smallest wallclock time or elapsed time, which is the 3rd field in the output of time. The fastest build also yielded the highest cpu utilization, which is the 4th field. I figure specifying a value for -j on single cpu system is simply thrashing the cpu by forcing it to save the environment to work on a different section of the build. I also found that mounting /usr/src and /usr/obj on different controller/HDs from the system reduced the build time. I was using ata-133 HDs and a good scsi would be change the results. It is too easy to test in your environment to see what produces the fastest buildworld. I am going to have to upgrade at some point and an AMD X2 should be interesting. Kent -- Kent Stewart Richland, WA http://www.soyandina.com/ "I am Andean project". http://users.owt.com/kstewart/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
Le 13/10/2006 à 16:31:30+0200, Buki a écrit > Hi, > > I searched the archives and web a little but found many different opinions > on stability/usability of using make -j# with buildworld (and buildkernel). > > So I am asking if it is a good idea to use make -j on production boxes. > On my new server Proliant DL 380 I use make -j 5 for buildworld without any problem (15 minutes for make -j 5 buildworld... :-) ). Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. 7 ième étage, plateau D, bureau 10 Heure local/Local time: Fri Oct 13 22:31:25 CEST 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
On Fri, Oct 13, 2006 at 01:12:38PM -0400, Vivek Khera wrote: > > On Oct 13, 2006, at 12:33 PM, Ruslan Ermilov wrote: > > >>Works for me with -j2 on buildworld. > >> > >>My buildkernel fails since I compile acpi static. > >> > >Hmm, and where and how does it break? This commit (not yet > > i poked around some more and i do see acpi broken, but make just > ignores the error during make depend phase when running with -j2 on > the i386: > > /usr/obj/n/lorax1/usr6/src/make.i386/make -f /n/lorax1/usr6/src/sys/ > i386/acpica/Makefile MAKESRCPATH=/n/lorax1/usr6/src/sys/i386/acpica > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- - > DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include - > I/usr/include -I/n/lorax1/usr6/obj.i386/n/lorax1/usr6/src/sys/ > KCI32SMP usb_if.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ > hid.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/uhub.c /n/ > lorax1/usr6/src/sys/modules/usb/../../dev/usb/usb.c /n/lorax1/usr6/ > src/sys/modules/usb/../../dev/usb/usb_mem.c /n/lorax1/usr6/src/sys/ > modules/usb/../../dev/usb/usb_quirks.c /n/lorax1/usr6/src/sys/modules/ > usb/../../dev/usb/usb_subr.c /n/lorax1/usr6/src/sys/modules/usb/../../ > dev/usb/usbdi.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ > usbdi_util.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ > usb_ethersubr.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ > uhci_pci.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/uhci.c /n/ > lorax1/usr6/src/sys/modules/usb/../../dev/usb/ohci_pci.c /n/lorax1/ > usr6/src/sys/modules/usb/../../dev/usb/ohci.c /n/lorax1/usr6/src/sys/ > modules/usb/../../dev/usb/ehci_pci.c /n/lorax1/usr6/src/sys/modules/ > usb/../../dev/usb/ehci.c > Warning: Object directory not changed from original /n/lorax1/usr6/ > obj.i386/n/lorax1/usr6/src/sys/KCI32SMP > cc -O2 -fno-strict-aliasing -pipe -I. -I@ -c /n/lorax1/usr6/src/sys/ > i386/acpica/acpi_wakecode.S > /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S:35:19: assym.s: No > such file or directory > /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S: Assembler messages: > /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S:103: Error: suffix > or operands invalid for `ljmp' > *** Error code 1 > 1 error > *** Error code 2 > ===> ukbd (depend) > @ -> /n/lorax1/usr6/src/sys > ... and keeps going until it hits the nullfs depend step where it > really stops... > OK, please try merging my fix then, it should help. Please come back to me with a success report. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpTYqkkiJ804.pgp Description: PGP signature
Re: FreeBSD and "make -j# buildworld" usability
On Fri, Oct 13, 2006 at 12:56:28PM -0400, Vivek Khera wrote: > > On Oct 13, 2006, at 12:33 PM, Ruslan Ermilov wrote: > > >>Works for me with -j2 on buildworld. > >> > >>My buildkernel fails since I compile acpi static. > >> > >Hmm, and where and how does it break? This commit (not yet > >in RELENG_6) doesn't help? > > > > To be clear: make buildkernel works, but make -j2 builkernel used to > fail complaining that something wasn't built yet. Just tried it now > (twice) on an amd64 box and it worked. might have been luck of timing. > > Tried on an i386 box and it dies here every time with -j2, but builds > to completion without: > > ===> nullfs (depend) > @ -> /n/lorax1/usr6/src/sys > machine -> /n/lorax1/usr6/src/sys/i386/include > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q > awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- - > DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include - > I/usr/include -I/n/lorax1/usr6/obj.i386/n/lorax1/usr6/src/sys/KCI32 / > n/lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_subr.c /n/ > lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c /n/ > lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > 11.259user 14.494sys 84.0%, 0ib 1122ob 1049tx 3006da 4055to 0swp 0:30.63 > > > Perhaps my memory of it being acpi were incorrect (or I've since > added nullfs to my kernel...) > Can you put somewhere a full (combined stdout + stderr) output available for download, together with the kernel config (if it is not GENERIC)? P.S. Please don't manually exclude me from To:. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpG383CHGhVh.pgp Description: PGP signature
Re: sad lack of randomness
On 10/13/06, KAYVEN RIESE <[EMAIL PROTECTED]> wrote: i feel this is relevant to freeBSD because it could be something unique to freeBSD interaction with mico causing the bug. i know there are those here who run both But it is not relevant to the list you are sending these messages to. You should be using the FreeBSD-Ports mailing list, instead of the FreeBSD-Stable mailling list, as it is more relevant to that list. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
Buki <[EMAIL PROTECTED]> writes: > I searched the archives and web a little but found many different opinions > on stability/usability of using make -j# with buildworld (and buildkernel). > > So I am asking if it is a good idea to use make -j on production boxes. In addition to all of the other comments, there is one more point to make clear; although parallel builds work fine, they obscure the output from the different paths of the build. Therefore, if you have trouble with a "-j" buildworld, the first thing you need to do is to run it again without the "-j". This is not because it might work that way, but because the error messages will be much easier to understand. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sad lack of randomness
i feel this is relevant to freeBSD because it could be something unique to freeBSD interaction with mico causing the bug. i know there are those here who run both On Fri, 13 Oct 2006, KAYVEN RIESE wrote: well it doesn't! something is wrong with mico! do u have any advice on diagnostics? On Fri, 13 Oct 2006, Karel Gardas wrote: Hi, sorry, I don't understand. Could you be so kind and be more verbose? IMHO demo/random should just work. Cheers, Karel On Thu, 12 Oct 2006, KAYVEN RIESE wrote: is this a bad thing? cat Makefile # Makefile for a little mico client that reads random numbers from a # Corba-server. See client.cc for details. all: .depend client include /usr/local/mico/MakeVars INSTALL_DIR = random INSTALL_SRCS= Makefile client.cc random.idl client: random.h random.o client.o $(DEPS) $(LD) $(CXXFLAGS) $(LDFLAGS) random.o client.o $(LDLIBS) -o $@ random.h random.cc : random.idl $(IDLGEN) $(IDL) random.idl clean: rm -f random.cc random.h *.o core client *~ .depend cat README This demo retrieves true random numbers from a CORBA server on the internet, so running the client requires a live internet connection. See http://www.random.org/ and http://www.random.org/corba.html The file "random.ior" contains the current IOR of the server. If the client fails to connect to the server, please check the above URL to see if the reference has changed. This demo was kindly contributed by *--* | Frank Schneider Department of Computer Science III | | Phone: ++49 241 80 21312RWTH Aachen, Ahornstr. 55 | | Fax: ++49 241 218 52074 Aachen, Germany | | mailto:[EMAIL PROTECTED] | *--* gmake client gmake: `client' is up to date. client client: Command not found. ./client /libexec/ld-elf.so.1: Shared object "libmico2.3.12.so" not found, required by "client" ls MakefileREADME client.cc random.cc random.idl random.o Makefile.win32 client client.orandom.hrandom.ior pwd /home/kayve/demo/random On Thu, 12 Oct 2006, Karel Gardas wrote: Hi, how exactly have you configured MICO before building? I'm especially curious if your build failed before completion or if you manually disabled either name service (--disable-naming) or all coss (--disable-coss) to save some building time... Anyway, you do have -I../../../include in your CXXFLAGS and it is used so it should work well... Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Tue, 10 Oct 2006, KAYVEN RIESE wrote: On Tue, 10 Oct 2006, KAYVEN RIESE wrote: -o client c++ -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -c server .cc -o server.o c++ -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -L../../../ libs tree.o tree_impl.o server.o -lmico2.3.12 -lcompat -lssl -lcrypto -lm -lp thread -o server gmake[2]: Leaving directory `/usr/local/mico/demo/obv/tree' gmake[2]: Entering directory `/usr/local/mico/demo/obv/tricky' echo '# Module dependencies' > .depend /usr/local/mico/./admin/mkdepend -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE *.c *.cc >> .depend /usr/local/mico/./idl/idl tricky.idl c++ -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -c tricky .cc -o tricky.o c++ -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -c tricky _impl.cc -o tricky_impl.o c++ -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -c client .cc -o client.o c++ -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -L../../../ libs tricky.o tricky_impl.o client.o -lmico2.3.12 -lcompat -lssl -lcrypto -lm -lpthread -o client c++ -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -c server .cc -o server.o c++ -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE -L../../../ libs tricky.o tricky_impl.o server.o -lmico2.3.12 -lcompat -lssl -lcrypto -lm -lpthread -o server gmake[2]: Leaving directory `/usr/local/mico/demo/obv/tricky' gmake[1]: Leaving directory `/usr/local/mico/demo/obv' gmake[1]: Entering directory `/usr/local/mico/demo/services' Makefile:52: warning: overriding commands for target `install' ../MakeVars:76: warning: ignoring old commands for target `install' for i in naming naming-lb naming-mt events property-daemon; do gmake -C $i || e xit 1; done gmake[2]: Entering directory `/usr/local/mico/demo/services/naming' echo '# Module dependencies' > .depend /usr/local/mico/./admin/mkdepend -I. -I../../../include -O2 -Wall -D_REENTRANT -D_THREAD_SAFE *.c *.cc >> .depend /usr/local/mico/
Re: [mico-devel] Re: oh dear.. should mico/demo werk? is mico broke?
On Fri, 13 Oct 2006, Karel Gardas wrote: in the case you installed MICO from the OS packages, then you need to configure MICO runtime by running either . /lib/mico-setup.sh or source /lib/mico-setup.csh this is relevant to freeBSD because the mico guys don't necessarily run on freeBSD and i KNOW there are guys out there who are running freeBSD and mico. i am cofused now by my attempt to reinstall mico: su Password: bsd# pkg_add -r mico Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.1-release/Latest/mico.tbz... Done. pkg_add: package 'mico-2.3.11_3' or its older version already installed bsd# pkg_add -rf mico Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.1-release/Latest/mico.tbz... Done. bsd# oh wait. maybe i'm not, but now i'm aafraid to run pkg_delete ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
> > Some work is now being done so that -j can be reliably used on > 'make buildkernel', but I don't think that has been completed yet. For > now, my own opinion is that you're not going to save enough time with > -j on buildkernel to justify the amount of time you'll lose if it does > not work. That is my answer for today, but I expect -j for buildkernel > will be more reliable as time goes on. > Depends on the target. I've never had any problems with 'make -j6 buildkernel' when cross-compiling to sun4v from i386. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
Buki wrote: Hi, I searched the archives and web a little but found many different opinions on stability/usability of using make -j# with buildworld (and buildkernel). So I am asking if it is a good idea to use make -j on production boxes. I use -j2 on all my dual cpu/core boxes, i don't recall ever having a problem with it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
Adrian Chadd wrote: On 10/13/06, Mark Linimon <[EMAIL PROTECTED]> wrote: DragonFly has made substantial rewrites/changes since the fork from FreeBSD. I think to assume that there are no regressions in either stability, speed, or support may be naive. Has anyone tried benchmarking DragonflyBSD against FreeBSD 5.x and 6.x for some of the specific workloads people are reporting issues with? I'm about to do some MySQL benchmarking between DragonFly and 6.1. Should post the results soon on performance, just as soon as i figure out how the hell to use pkgsrc :P ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
At 4:31 PM +0200 10/13/06, Buki wrote: Hi, I searched the archives and web a little but found many different opinions on stability/usability of using make -j# with buildworld (and buildkernel). So I am asking if it is a good idea to use make -j on production boxes. It depends on the target. There are no bugs in 'make -j' per se, but a makefile target has to pay attention to some extra details if that specific target is going to work reliably when using '-j'. You are asking about two different targets. It should be safe to use -j on 'make buildworld', and in fact I do that all the time. Most of my systems are dual-CPU or dual-core, and -j makes the buildworld go significantly faster. *Occasionally* that does not work (particularly if you are following the freebsd-current branch), but any problems in that target are fixed as soon as they are noticed. In the past it has not been safe to use -j on 'make buildkernel', so I never do that. You probably wouldn't gain all that much time by using -j on 'make buildkernel' -- or at least not as much time as you'll lose the first time it does not work right. So I'm sure you see plenty of people say "DON'T DO THAT!!" when it comes to -j and 'make buildkernel'. Some work is now being done so that -j can be reliably used on 'make buildkernel', but I don't think that has been completed yet. For now, my own opinion is that you're not going to save enough time with -j on buildkernel to justify the amount of time you'll lose if it does not work. That is my answer for today, but I expect -j for buildkernel will be more reliable as time goes on. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
On Oct 13, 2006, at 12:33 PM, Ruslan Ermilov wrote: Works for me with -j2 on buildworld. My buildkernel fails since I compile acpi static. Hmm, and where and how does it break? This commit (not yet i poked around some more and i do see acpi broken, but make just ignores the error during make depend phase when running with -j2 on the i386: /usr/obj/n/lorax1/usr6/src/make.i386/make -f /n/lorax1/usr6/src/sys/ i386/acpica/Makefile MAKESRCPATH=/n/lorax1/usr6/src/sys/i386/acpica rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- - DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include - I/usr/include -I/n/lorax1/usr6/obj.i386/n/lorax1/usr6/src/sys/ KCI32SMP usb_if.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ hid.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/uhub.c /n/ lorax1/usr6/src/sys/modules/usb/../../dev/usb/usb.c /n/lorax1/usr6/ src/sys/modules/usb/../../dev/usb/usb_mem.c /n/lorax1/usr6/src/sys/ modules/usb/../../dev/usb/usb_quirks.c /n/lorax1/usr6/src/sys/modules/ usb/../../dev/usb/usb_subr.c /n/lorax1/usr6/src/sys/modules/usb/../../ dev/usb/usbdi.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ usbdi_util.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ usb_ethersubr.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ uhci_pci.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/uhci.c /n/ lorax1/usr6/src/sys/modules/usb/../../dev/usb/ohci_pci.c /n/lorax1/ usr6/src/sys/modules/usb/../../dev/usb/ohci.c /n/lorax1/usr6/src/sys/ modules/usb/../../dev/usb/ehci_pci.c /n/lorax1/usr6/src/sys/modules/ usb/../../dev/usb/ehci.c Warning: Object directory not changed from original /n/lorax1/usr6/ obj.i386/n/lorax1/usr6/src/sys/KCI32SMP cc -O2 -fno-strict-aliasing -pipe -I. -I@ -c /n/lorax1/usr6/src/sys/ i386/acpica/acpi_wakecode.S /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S:35:19: assym.s: No such file or directory /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S: Assembler messages: /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S:103: Error: suffix or operands invalid for `ljmp' *** Error code 1 1 error *** Error code 2 ===> ukbd (depend) @ -> /n/lorax1/usr6/src/sys ... and keeps going until it hits the nullfs depend step where it really stops... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
At 09:39 AM 10/11/2006, Dan Lukes wrote: Even if no new ports will be compilable on 4.x, even if the old ports will not be updated with exception of update caused by security bug, I vote for delaying EOL of 4.11 I would second that vote. Yes, some of the new enhancements in 6.x are nice to have, but there's something to be said for an older, leaner, meaner, extremely well tested system that "just works" and consumes less memory and fewer computing resources. Just this week, we looked at the status of 6.2 (still just a bit shaky) and its resource consumption (about 40% greater than 4.11) and opted to build another 4.11 server. This wasn't intended as a slight to 6.x; it was just the right thing to do under the circumstances. I also build embedded systems based on 4.11. I sometimes have to backport subtle kernel fixes myself, but it's worth it. IMHO, The FreeBSD Project should have some mechanism for recognizing the fact that in some cases (especially embedded systems and slower hardware) a really good, solid older implementation is the right choice and is worth maintaining. (And that's no April Fool's Day joke.) To do this doesn't constitute a "fork" and is of enough value to warrant a bit of developer time (though obviously different developers will take different amounts of interest in maintaining "classic" releases). --Brett Glass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
On Oct 13, 2006, at 12:33 PM, Ruslan Ermilov wrote: Works for me with -j2 on buildworld. My buildkernel fails since I compile acpi static. Hmm, and where and how does it break? This commit (not yet in RELENG_6) doesn't help? To be clear: make buildkernel works, but make -j2 builkernel used to fail complaining that something wasn't built yet. Just tried it now (twice) on an amd64 box and it worked. might have been luck of timing. Tried on an i386 box and it dies here every time with -j2, but builds to completion without: ===> nullfs (depend) @ -> /n/lorax1/usr6/src/sys machine -> /n/lorax1/usr6/src/sys/i386/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- - DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include - I/usr/include -I/n/lorax1/usr6/obj.i386/n/lorax1/usr6/src/sys/KCI32 / n/lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_subr.c /n/ lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c /n/ lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c 1 error *** Error code 2 1 error *** Error code 2 1 error 11.259user 14.494sys 84.0%, 0ib 1122ob 1049tx 3006da 4055to 0swp 0:30.63 Perhaps my memory of it being acpi were incorrect (or I've since added nullfs to my kernel...) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
On Fri, Oct 13, 2006 at 11:06:37AM -0400, Vivek Khera wrote: > > On Oct 13, 2006, at 10:31 AM, Buki wrote: > > >I searched the archives and web a little but found many different > >opinions > >on stability/usability of using make -j# with buildworld (and > >buildkernel). > > Works for me with -j2 on buildworld. > > My buildkernel fails since I compile acpi static. > Hmm, and where and how does it break? This commit (not yet in RELENG_6) doesn't help? : ru 2006-09-06 14:23:40 UTC : : FreeBSD src repository : : Modified files: : sys/i386/acpica Makefile : Log: : Refine previous revision to allow acpi_wakecode.h to be safely built : from both the acpi module build directory and a kernel build directory. : The latter didn't work when one attempted to build a kernel which had : "device acpi" with the "make kernel-toolchain buildkernel" command : because a cross-compiler couldn't find anything in the standard system : include path (it's empty in the kernel-toolchain case). : : Fix this by passing a better root path to kernel headers (src/sys) : which works for both cases, kernel and module (-I@ only worked for : module). : : Also, while here, pass -nostdinc (and a different spelling for icc) -- : it's a feature that the kernel source tree is self-contained, and this : change enforces this. : : Reported by:glebius : : Revision ChangesPath : 1.7 +7 -1 src/sys/i386/acpica/Makefile Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpmJ1tyFl693.pgp Description: PGP signature
Re: freebsd panic on HP Proliant DL360
On Fri, 13 Oct 2006, 10:50-0400, Ernest Natiello wrote: > On Fri, 2006-10-13 at 14:25 +0400, Maxim Konovalov wrote: > > Gentlemen, sorry I interrupt you. What version of FreeBSD is that? > > If it something < RELENG_6 you should consider to upgrade to it. I > > believe this panic was fixed by rwatson. > > Do you have a date as to when this was patch was committed? One of the > boxes undergoing the issue was cvsup'd and build as of Oct 4th. > > FreeBSD unix35 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #3: Wed Oct 4 > 11:11:37 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX35 i386 This is a different issue then. -- Maxim Konovalov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and "make -j# buildworld" usability
On Oct 13, 2006, at 10:31 AM, Buki wrote: I searched the archives and web a little but found many different opinions on stability/usability of using make -j# with buildworld (and buildkernel). Works for me with -j2 on buildworld. My buildkernel fails since I compile acpi static. But I only build once and NFS mount the src+obj trees on other boxes. no need to do a full build on each box.
Re: freebsd panic on HP Proliant DL360
On Fri, Oct 13, 2006 at 10:50:43AM -0400, Ernest Natiello wrote: E> On Fri, 2006-10-13 at 14:25 +0400, Maxim Konovalov wrote: E> > Gentlemen, sorry I interrupt you. What version of FreeBSD is that? E> > If it something < RELENG_6 you should consider to upgrade to it. I E> > believe this panic was fixed by rwatson. E> E> Do you have a date as to when this was patch was committed? One of the E> boxes undergoing the issue was cvsup'd and build as of Oct 4th. AFAIK, Robert made this panic less probable to happen in RELENG_6, but didn't eliminated it completely. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd panic on HP Proliant DL360
On Fri, 2006-10-13 at 14:25 +0400, Maxim Konovalov wrote: > Gentlemen, sorry I interrupt you. What version of FreeBSD is that? > If it something < RELENG_6 you should consider to upgrade to it. I > believe this panic was fixed by rwatson. Do you have a date as to when this was patch was committed? One of the boxes undergoing the issue was cvsup'd and build as of Oct 4th. FreeBSD unix35 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #3: Wed Oct 4 11:11:37 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/UNIX35 i386 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd panic on HP Proliant DL360
On Fri, 2006-10-13 at 12:22 +0400, Gleb Smirnoff wrote: > Which port/package/software does tcpserver program belong to? > We do not use a FreeBSD package for tcpserver, compiled locally. It is used with qmail. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD and "make -j# buildworld" usability
Hi, I searched the archives and web a little but found many different opinions on stability/usability of using make -j# with buildworld (and buildkernel). So I am asking if it is a good idea to use make -j on production boxes. Thanks, Marek Kozlovsky -- PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net pgpNjbWuDlLeo.pgp Description: PGP signature
Re: carp0 interface goes down on 6.2-PRERELEASE
On Fri, 13 Oct 2006, Vivek Khera wrote: On Oct 13, 2006, at 1:43 AM, Ari Suutari wrote: a kernel implementation. It doesn't require both nodes to be alive when the system starts, if there is only one system and it doesn't hear advertisements from anyone, it goes to MASTER state after a while. This has been my experience. If both systems are rebooted, and one does not come back up, the other is active as MASTER. yes luckily. Else nothing would work;) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[releng_6 tinderbox] failure on sparc64/sparc64
TB --- 2006-10-13 13:15:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-13 13:15:58 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2006-10-13 13:15:58 - cleaning the object tree TB --- 2006-10-13 13:16:26 - checking out the source tree TB --- 2006-10-13 13:16:26 - cd /tinderbox/RELENG_6/sparc64/sparc64 TB --- 2006-10-13 13:16:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2006-10-13 13:27:57 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-13 13:27:57 - cd /src TB --- 2006-10-13 13:27:57 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a-DRESCUE /src/sbin/mount/mount.c /src/sbin/mount/mount_ufs.c /src/sbin/mount/getmntopts.c /src/sbin/mount/vfslist.c echo mount: /obj/sparc64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -c /src/sbin/mount/mount.c /src/sbin/mount/mount.c: In function `mountfs': /src/sbin/mount/mount.c:432: error: `fstab' undeclared (first use in this function) /src/sbin/mount/mount.c:432: error: (Each undeclared identifier is reported only once /src/sbin/mount/mount.c:432: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/mount. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-13 14:04:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-13 14:04:39 - ERROR: failed to build world TB --- 2006-10-13 14:04:39 - tinderbox aborted TB --- 0.62 user 2.24 system 2921.11 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: carp0 interface goes down on 6.2-PRERELEASE
On Oct 13, 2006, at 1:43 AM, Ari Suutari wrote: a kernel implementation. It doesn't require both nodes to be alive when the system starts, if there is only one system and it doesn't hear advertisements from anyone, it goes to MASTER state after a while. This has been my experience. If both systems are rebooted, and one does not come back up, the other is active as MASTER.
[releng_6 tinderbox] failure on i386/pc98
TB --- 2006-10-13 12:58:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-13 12:58:09 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2006-10-13 12:58:09 - cleaning the object tree TB --- 2006-10-13 12:58:46 - checking out the source tree TB --- 2006-10-13 12:58:46 - cd /tinderbox/RELENG_6/i386/pc98 TB --- 2006-10-13 12:58:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2006-10-13 13:10:02 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-13 13:10:02 - cd /src TB --- 2006-10-13 13:10:02 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a-DRESCUE /src/sbin/mount/mount.c /src/sbin/mount/mount_ufs.c /src/sbin/mount/getmntopts.c /src/sbin/mount/vfslist.c echo mount: /obj/pc98/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -c /src/sbin/mount/mount.c /src/sbin/mount/mount.c: In function `mountfs': /src/sbin/mount/mount.c:432: error: `fstab' undeclared (first use in this function) /src/sbin/mount/mount.c:432: error: (Each undeclared identifier is reported only once /src/sbin/mount/mount.c:432: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/mount. *** Error code 1 Stop in /obj/pc98/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-13 13:49:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-13 13:49:14 - ERROR: failed to build world TB --- 2006-10-13 13:49:14 - tinderbox aborted TB --- 0.72 user 2.72 system 3065.49 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[releng_6 tinderbox] failure on i386/i386
TB --- 2006-10-13 12:24:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-13 12:24:08 - starting RELENG_6 tinderbox run for i386/i386 TB --- 2006-10-13 12:24:08 - cleaning the object tree TB --- 2006-10-13 12:24:44 - checking out the source tree TB --- 2006-10-13 12:24:44 - cd /tinderbox/RELENG_6/i386/i386 TB --- 2006-10-13 12:24:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2006-10-13 12:35:55 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-13 12:35:55 - cd /src TB --- 2006-10-13 12:35:55 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a-DRESCUE /src/sbin/mount/mount.c /src/sbin/mount/mount_ufs.c /src/sbin/mount/getmntopts.c /src/sbin/mount/vfslist.c echo mount: /obj/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -c /src/sbin/mount/mount.c /src/sbin/mount/mount.c: In function `mountfs': /src/sbin/mount/mount.c:432: error: `fstab' undeclared (first use in this function) /src/sbin/mount/mount.c:432: error: (Each undeclared identifier is reported only once /src/sbin/mount/mount.c:432: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/mount. *** Error code 1 Stop in /obj/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-13 13:15:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-13 13:15:58 - ERROR: failed to build world TB --- 2006-10-13 13:15:58 - tinderbox aborted TB --- 0.70 user 2.60 system 3109.32 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[releng_6 tinderbox] failure on amd64/amd64
TB --- 2006-10-13 12:06:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-13 12:06:14 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2006-10-13 12:06:14 - cleaning the object tree TB --- 2006-10-13 12:06:45 - checking out the source tree TB --- 2006-10-13 12:06:45 - cd /tinderbox/RELENG_6/amd64/amd64 TB --- 2006-10-13 12:06:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2006-10-13 12:18:00 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-13 12:18:00 - cd /src TB --- 2006-10-13 12:18:00 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a-DRESCUE /src/sbin/mount/mount.c /src/sbin/mount/mount_ufs.c /src/sbin/mount/getmntopts.c /src/sbin/mount/vfslist.c echo mount: /obj/amd64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -c /src/sbin/mount/mount.c /src/sbin/mount/mount.c: In function `mountfs': /src/sbin/mount/mount.c:432: error: `fstab' undeclared (first use in this function) /src/sbin/mount/mount.c:432: error: (Each undeclared identifier is reported only once /src/sbin/mount/mount.c:432: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/mount. *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-13 12:58:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-13 12:58:08 - ERROR: failed to build world TB --- 2006-10-13 12:58:08 - tinderbox aborted TB --- 0.96 user 3.06 system 3114.29 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
Chris Laco <[EMAIL PROTECTED]> writes: > From my personal experience of (4) 4.x machines and (1) 5.x machine, > all on the same hardware, I've had more problems with my 5.x install > than I ever did with my 4.x install. I'm afraid to even look to see > if 6.0 will run on it. The transition from 4.x to 5.x was very painful for a number of reasons (both technical and organisational) mainly having to do with trying to do too much at the same time. 6.x was a significant improvement in terms of stability and maturity, and hopefully 7.x will continue that trend. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
aolserver nsthreadtest fails / aborts ...
Just found this while working on a clients site, and figured I'd mention it ... Aolserver4 has a program called 'nsthreadtest' that you can run from the command line, that aborts part way through: pthread: join 9 = 9 nsthreads: pthread_join failed in Ns_ThreadJoin: Invalid argument Abort (core dumped) It dumps core, with a quick trace showing: (gdb) where #0 0x000800b4781c in pthread_testcancel () from /usr/lib/libpthread.so.2 #1 0x000800b35543 in sigaction () from /usr/lib/libpthread.so.2 #2 0x000800b37062 in sigaction () from /usr/lib/libpthread.so.2 #3 0x000800b30d56 in pthread_kill () from /usr/lib/libpthread.so.2 #4 0x000800b305d3 in raise () from /usr/lib/libpthread.so.2 #5 0x000800d1696d in abort () from /lib/libc.so.6 #6 0x0008007b1cb8 in Tcl_PanicVA () from /usr/local/lib/libtcl84.so.1 #7 0x0008007b1d4d in Tcl_Panic () from /usr/local/lib/libtcl84.so.1 #8 0x000800630a65 in NsThreadFatal () from /usr/local/aolserver/lib/libnsthread.so #9 0x000800632835 in Ns_ThreadJoin () from /usr/local/aolserver/lib/libnsthread.so #10 0x00402868 in main () Don't know if its anything to be concerned about, or just something badly programmed within nsthreadtest, but figured I'd point it out ... if I can provide more details just to confirm it isn't an "OS problem", let me know ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 pgpI6cdSgULu1.pgp Description: PGP signature
Re: carp0 interface goes down on 6.2-PRERELEASE
Hi,
Tom Judge wrote:
Ari Suutari wrote:
Ari Suutari wrote:
I have now tested with real hardware (ethernet is fxp0) and
under VmWare (ethernet is lnc0). Same problem on both.
I'll have to correct this. Carp works with fxp0. Problem is
only under vmware, which makes me more and more suspect
that it is because lnc0 does not support link state reporting
(it seems to be present on only a few drivers).
I do remember seeing this problem when developing some systems in vmware
that the carp interfaces where always in INIT when the system booted. I
added a small rc script to for the interfaces up using 'ifconfig carp0
up' which seemed to make the interfaces come up however if on system is
unplugged from the network it will automatically put itself into the
master state until it can talk to the other servers in the carp group.
I already found the problem, it is in netinet/ip_carp.c.
Since lnc driver doesn't support link state, the state is
always LINK_STATE_UNKNOWN and carp code doesn't understand this.
Following patch fixes it for me:
cvs diff: Diffing .
Index: ip_carp.c
===
RCS file: /opt/freebsd-cvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.27.2.8
diff -c -r1.27.2.8 ip_carp.c
*** ip_carp.c 25 Sep 2006 13:01:59 - 1.27.2.8
--- ip_carp.c 13 Oct 2006 11:11:08 -
***
*** 2116,2122
{
CARP_SCLOCK_ASSERT(sc);
! if (sc->sc_carpdev->if_link_state != LINK_STATE_UP ||
!(sc->sc_carpdev->if_flags & IFF_UP)) {
sc->sc_flags_backup = SC2IFP(sc)->if_flags;
SC2IFP(sc)->if_flags &= ~IFF_UP;
--- 2116,2122
{
CARP_SCLOCK_ASSERT(sc);
! if (sc->sc_carpdev->if_link_state == LINK_STATE_DOWN ||
!(sc->sc_carpdev->if_flags & IFF_UP)) {
sc->sc_flags_backup = SC2IFP(sc)->if_flags;
SC2IFP(sc)->if_flags &= ~IFF_UP;
Ari S.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: carp0 interface goes down on 6.2-PRERELEASE
Ari Suutari wrote: Ari Suutari wrote: I have now tested with real hardware (ethernet is fxp0) and under VmWare (ethernet is lnc0). Same problem on both. I'll have to correct this. Carp works with fxp0. Problem is only under vmware, which makes me more and more suspect that it is because lnc0 does not support link state reporting (it seems to be present on only a few drivers). I do remember seeing this problem when developing some systems in vmware that the carp interfaces where always in INIT when the system booted. I added a small rc script to for the interfaces up using 'ifconfig carp0 up' which seemed to make the interfaces come up however if on system is unplugged from the network it will automatically put itself into the master state until it can talk to the other servers in the carp group. Tom J ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[releng_6 tinderbox] failure on alpha/alpha
TB --- 2006-10-13 11:16:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-10-13 11:16:23 - starting RELENG_6 tinderbox run for alpha/alpha TB --- 2006-10-13 11:16:23 - cleaning the object tree TB --- 2006-10-13 11:16:54 - checking out the source tree TB --- 2006-10-13 11:16:54 - cd /tinderbox/RELENG_6/alpha/alpha TB --- 2006-10-13 11:16:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2006-10-13 11:27:52 - building world (CFLAGS=-O2 -pipe) TB --- 2006-10-13 11:27:52 - cd /src TB --- 2006-10-13 11:27:52 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a-DRESCUE /src/sbin/mount/mount.c /src/sbin/mount/mount_ufs.c /src/sbin/mount/getmntopts.c /src/sbin/mount/vfslist.c echo mount: /obj/alpha/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -DRESCUE -c /src/sbin/mount/mount.c /src/sbin/mount/mount.c: In function `mountfs': /src/sbin/mount/mount.c:432: error: `fstab' undeclared (first use in this function) /src/sbin/mount/mount.c:432: error: (Each undeclared identifier is reported only once /src/sbin/mount/mount.c:432: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/mount. *** Error code 1 Stop in /obj/alpha/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-10-13 12:06:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-10-13 12:06:13 - ERROR: failed to build world TB --- 2006-10-13 12:06:13 - tinderbox aborted TB --- 0.80 user 2.33 system 2990.17 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: carp0 interface goes down on 6.2-PRERELEASE
Hi, Ari Suutari wrote: I have now tested with real hardware (ethernet is fxp0) and under VmWare (ethernet is lnc0). Same problem on both. I'll have to correct this. Carp works with fxp0. Problem is only under vmware, which makes me more and more suspect that it is because lnc0 does not support link state reporting (it seems to be present on only a few drivers). Ari S. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd panic on HP Proliant DL360
On Fri, 13 Oct 2006, 12:22+0400, Gleb Smirnoff wrote:
> On Thu, Oct 12, 2006 at 11:56:21AM -0400, Ernest Natiello wrote:
> E> here we go:
> E>
> E> (kgdb) frame 7
> E> #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
> E> at /usr/src/sys/netinet/ip_output.c:1184
> E> 1184INP_LOCK(inp);
> E> (kgdb) p *sopt
> E> $1 = {sopt_dir = SOPT_SET, sopt_level = 0, sopt_name = 1, sopt_val =
> E> 0x0,
> E> sopt_valsize = 0, sopt_td = 0xc73add80}
>
> Not clear to me what IP option is it trying to set... sopt_valsize is 0.
>
> Which port/package/software does tcpserver program belong to?
Gentlemen, sorry I interrupt you. What version of FreeBSD is that?
If it something < RELENG_6 you should consider to upgrade to it. I
believe this panic was fixed by rwatson.
tcpserver comes from qmail I believe.
--
Maxim Konovalov
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd panic on HP Proliant DL360
On Thu, Oct 12, 2006 at 11:56:21AM -0400, Ernest Natiello wrote:
E> here we go:
E>
E> (kgdb) frame 7
E> #7 0xc072191d in ip_ctloutput (so=0x1, sopt=0xe9226c90)
E> at /usr/src/sys/netinet/ip_output.c:1184
E> 1184INP_LOCK(inp);
E> (kgdb) p *sopt
E> $1 = {sopt_dir = SOPT_SET, sopt_level = 0, sopt_name = 1, sopt_val =
E> 0x0,
E> sopt_valsize = 0, sopt_td = 0xc73add80}
Not clear to me what IP option is it trying to set... sopt_valsize is 0.
Which port/package/software does tcpserver program belong to?
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: carp0 interface goes down on 6.2-PRERELEASE
Eugene Grosbein wrote: On Thu, Oct 12, 2006 at 02:44:32PM +0300, Ari Suutari wrote: I have seen similar problems when the carp multicast (224.0.0.18) traffic was not allowed to be transmitted to the network due to a firewall configuration problem. Firewall wasn't enabled at this point, I wanted to keep things as simple as possible during testing. I have now tested with real hardware (ethernet is fxp0) and under VmWare (ethernet is lnc0). Same problem on both. Make sure you are NOT using ipfw divert for outgoint multicast. These two beasts (divert and multicast) are not friendly in between for FreeBSD. Ipfw is not even loaded. I suspect that this has something to do with sensing of media state, since if I up the carp0 interface manually and disconnect the lan cable carp0 goes down. Ari S. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [netops] Re: bce issues still outstanding
Brian A. Seklecki wrote: Mmmm, the 5787. Such is the way of ordering high end Dell workstations tested only with RHEL3 and Windows XP. ~BAS Actually the Dell Precision 390 has 5754, not 5787, but the driver recognized it wrongly. Also, FreeBSD 6.1 does not panic because driver change/inclusion happens after it, as shown in CVS. I reported this problem twice since last month. Glad to know that it is being worked on. Thanks. Edward On Wed, 2006-10-11 at 11:21 -0500, Kevin Kramer wrote: here is a picture of a panic i get on a Dell Precision 390 booting 6.2-beta2_amd64. hope this helps. http://users.centtech.com/~kramer/broadcom/bge_prec390.jpg -- Kevin Kramer Sr. Systems Administrator 512.418.5725 Centaur Technology, Inc. www.centtech.com Scott Long wrote the following on 10/11/06 10:11: Bill Moran wrote: I've copied many of the people who I've been working with directly on this issue. Can anyone provide a status update on these problems? Discussion seems to have stopped since Oct 5. Any new patches to test? I'm actively working on fixing the driver right now. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: carp0 interface goes down on 6.2-PRERELEASE
On Thu, Oct 12, 2006 at 02:44:32PM +0300, Ari Suutari wrote: > >I have seen similar problems when the carp multicast (224.0.0.18) > >traffic was not allowed to be transmitted to the network due to a > >firewall configuration problem. > Firewall wasn't enabled at this point, I wanted to keep things > as simple as possible during testing. > I have now tested with real hardware (ethernet is fxp0) and > under VmWare (ethernet is lnc0). Same problem on both. Make sure you are NOT using ipfw divert for outgoint multicast. These two beasts (divert and multicast) are not friendly in between for FreeBSD. Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
