Re: FreeBSD 6.3 or FreeBSD 7.0
Dylan Smith wrote: Marko Lerota wrote: I see that 6.3 and 7.0 is comming. Now I'm using 6.2-RELEASE for my servers. To what should I upgrade? Which of them will be stable or production release? Both of them will be production stable at release, i'd say that unless you have reason, such as non-supported hardware in 7, to stay with the 6-branch upgrade to 7-RELEASE. 6.3 will afaik be the last revision to the 6 branch aside from bug/security fixes. If the security webpage at FreeBSD is any indication, then if (for example) 7.0 is released before 6.3, then 6.3 will be supported that much longer than 7.0. And so although the branch may be getting cut off, in the overall big picture, 6.3 may be fine. For example, around the time 6.3 (or 6-stable) stops being supported, 7.0 may be long deprecated in favor of perhaps 7.4 or 7-stable or 8.1 or whatever. The 4.x branch was ultra supported beyond its time, IIRC. Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The code for rebooting an SMP machine doesn't always work (still)
Kris Kennaway wrote: On Tue, Feb 20, 2007 at 06:21:52PM -0600, Billy Newsom wrote: When a SMP machine does not have an AT keyboard controller, there needs to be a way to reboot the machine under FreeBSD! Like the sysctl that was added in 6.2? hw.acpi.handle_reboot=1 Kris Well, what do you know? That works for this machine! I will probably blog this information sometime. That is excellent. Finally, the ACPI code has come up to standard in FreeBSD. It seems like it was lacking for a number of years. As for the old reboot code, I still think it could use some help. I happen to think that the code which tries to reboot the machine using the triple fault should work if it was adjusted somehow. But since we are fully ACPI compliant, this hack works great. In any case, the Mac Pro needs that sysctl variable under FreeBSD 6.2 or we get that awful trap 12 doing a reboot. With this change, I think we have an acceptable server platform, made by Apple, run by free software. Pretty slick system. Maybe I will post my dmesg now. Thanks community! Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
The code for rebooting an SMP machine doesn't always work (still)
When a SMP machine does not have an AT keyboard controller, there needs to be a way to reboot the machine under FreeBSD! I have another system which fails to reboot under FreeBSD. This time it is a bleeding-edge current system and FreeBSD 6.2-release. From what I can tell, the code to reboot machines has not really changed much in over ten years. There is definitely something wrong with it, however, probably in SMP systems. Here is what happens. When I do a shutdown and reboot of this machine (which lacks the keyboard controller), I get a notice that the Keyboard reset failed. //Keyboard reset did not work, attempting CPU shutdown// Then, there is an attempt to reboot the machine which results in a Fatal Trap 12. Google for triple fault reboot perhaps kern/94822 Now, I have looked at the code a lot to see what is happening. Taking vm_mach_dep.c to task, it is obvious that the keyboard reboot is the norm, with the alternate method used as a last resort. (This is true even for AMD64, which is what I am using!) I even looked at the locore.s code to see how that reboot code works (written in assemler, I think) there, and they do not even try the keyboard reset. The idea, it would seem, is to cause what is known as a triple fault in the CPU, which is supposed to force it to reset. (I cross-referenced to other operating systems, like NetBSD) In this case, I think maybe the CPU is somehow surviving the attempt to be rebooted when certain things happen. I wonder if someone would like to test this, simply remove the portion of vm_mach_dep.c that attempts the keyboard reset and see if the remaining C code there works. After all, this bug only shows up on the odd machine which has no KBC. The code is easy to spot because the comment is *//* good night, sweet prince THUNK! */ and it has been in the code since the 1990s at least. /* Examples of affected machines? Well, I am testing a Mac Pro with dual Xeons and four cores. I believe that blade servers are often without a keyboard controller, too. Many embedded systems have no KBC. The other example is a machine that I still run FreeBSD 5 on. It is a dual Pentium Pro 200. Notice that both of my examples are running SMP, and this could have a lot to do with being able to force a CPU to execute and perform three See cpu_reset_real() and its comments at http://fxr.watson.org/fxr/source//amd64/amd64/vm_machdep.c http://fxr.watson.org/fxr/source/i386/i386/vm_machdep.c For those who might think I didn't try everything: I tried this in device.hints: # Billy removed these six things for Mac Pro hint.atkbdc.0.disabled=1 hint.atkbd.0.disabled=1 hint.sio.0.disabled=1 hint.sio.1.disabled=1 hint.ppc.0.disabled=1 hint.psm.0.disabled=1 # Billy removed these six things for Mac Pro I tried removing those culprits from the kernel, too. Less errors at boot, but never would it reboot. It will do this: halt -p (Works) It will reboot under Windows XP (same machine) It will reboot at the Boot Loader prompt (type reboot, and it does that. See locore.s) In other words, amd64's vm_machdep.c is the problem, but I must say that I'm pretty confident that the same is true for i386. My dual Pentium Pro stopped rebooting okay when upgraded from FreeBSD 4.x to 5.2 and still won't reboot. As a footnote, there is a kernel option called BROKEN_KEYBOARD_RESET. Great, right? Well, someone disabled it for amd64, so the kernel wouldn't even build with that option. Shame on us for removing a simple way to troubleshoot a problem. I would recommend adding that back as either a device hint or a kernel option. It's still available for i386. But all it would do for me is avoid the attempt to try the keyboard reset, which doesn't freeze or panic this computer, it simply just doesn't work. Thanks for any help. I have collected a lot of data if someone is interested. I may post my dmesg output for this Macintosh anyway just for someone's reference. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-stable kernel hang during boot
See my posts and others on these topics: critical BOOT failure updating to latest 5-Stable (5.4) 5.3 - 5.4 breaks ATA (Intel ICH2) [PATCH] option to re-enable aggressive ATA probing Those are from September 2005, when I and others started having problems with the latest (poor) edits to the 5-Stable code. There was obviously a regression for many of us with certain hard drives or systems. As an important side note, notice that I am using a similar computer to yours, an IBM PC365 with dual Pentium Pros. Although I have not tried the patch due to lack of time, I hope that will fix your issue. Also, I wonder if we share a similar bad BIOS issue in which our systems seem to choke on this new code for IDE detection during boot time. See my dmesg output in the archives. BTW, this has effectively kept me from upgrading to the latest 5-Stable since September, as it is not a quick and easy task on my old system. Also, there might be another mailing list - ACPI or something where there may be more answers. I don't know if there is a PR for this, yet. I had thought of filing one, but I sort of forgot. Check the archives to see if someone else did. Billy Paul Keusemann wrote: Hi, I've got an IBM Intellistation M Pro with dual 600 Mhz PIIIs, an IBM DNES-309170W (da0 on ahc0) as the root drive and HighPoint RocketRaid 1520 with two WD1600JD drives mirrored as data drives. There is nothing on ata0 and the CD-ROM drive is the master on ata1. I have been running a custom kernel (GENERIC with SMP) since installation. The verbose output from dmesg from the a 5.4 Release kernel (booted from CD-ROM) is attached. I installed 5.3 Release on this machine a while back and just decided to try to upgrade to 5.4 Stable. (This is my first attempt at doing a buildworld upgrade.) I cvsup'ed /usr/src using the stable-supfile in /usr/share/examples/cvsup. I then followed the instructions in /usr/src/Makefile to build world, build a new custom kernel and install the new kernel. Then I attempted to reboot into single user mode. The boot hangs while processing ata1, right after the following: ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 The really interesting part is that after installing the new kernel, I can't boot from kernel.old or another backup of my custom kernel. They both hang in the same way as the new kernel. If I boot off the 5.4 Release CD-ROM, remove the new kernel and rename kernel.old to kernel, the system comes up just fine. At this point I guess I'm looking for any help I can get. Could the fact that there is nothing on ata0 be causing a problem? I know I can boot the 5.4 Release kernel, would I be better off upgrading from the install? I have had no problems with this machine so I can just scratch the upgrade, but it would be nice to be able to get it up to 5-stable and eventually 6-stable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] option to re-enable aggressive ATA probing
Tim Howe wrote: Tim Howe [EMAIL PROTECTED] writes: ata0-master: stat=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 This turned out to be the key. Version 1.51 of ata-lowlevel.c added a check for stat0/1, err, lsb, and I am just wondering about this. As far as I can tell, I have the ata-lowlevel.c file from March with this CVS tag (I run cvsup every other day, so this should be the latest for 5-Stable): src/sys/dev/ata/ata-lowlevel.c,v 1.44.2.5 2005/03/24 18:44:27 mdodd It is the 1.44.2.5 version, and I believe that I have been using it for awhile, eve before the sistuation showed up with my ATA drive not booting. As I reported bvefore, the July 4th cvs code worked for me, but not a recent one (late September). I would guess that something would have changed in that interim. You seem to be targeting either a different cvs version (intended for HEAD) or the problem you mention could have been broken over a period of time with help from other cvs changes? I don't know, but I will try the patch when I can. These are my relevent supfile config options: *default release=cvs tag=RELENG_5 *default delete use-rel-suffix src-all Billy msb being identical. If they are, it aborts the probe. The attached patch creates an option ATA_AGGRESSIVE_PROBE which disables this for the old aggressive behavior (which may wait up to the full 31 seconds). I also took the liberty of reworking the still-busy check from 3 equality tests to 2 bitmask tests. It seems simpler to my eye with identical results, but if I missed something or the other style was preferred please let me know. The patch is against 5-STABLE because that's what I have. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] option to re-enable aggressive ATA probing
Tim Howe wrote: Tim Howe [EMAIL PROTECTED] writes: ata0-master: stat=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 This turned out to be the key. Version 1.51 of ata-lowlevel.c added a check for stat0/1, err, lsb, and msb being identical. If they are, it aborts the probe. The attached patch creates an option ATA_AGGRESSIVE_PROBE which disables this for the old aggressive behavior (which may wait up to the full 31 seconds). I also took the liberty of reworking the still-busy check from 3 equality tests to 2 bitmask tests. It seems simpler to my eye with identical results, but if I missed something or the other style was preferred please let me know. The patch is against 5-STABLE because that's what I have. Looks good except for one issue I talk about below. By the way, I don't think this will ever appear back into the RELENG_5 tree unless it gets a PR or at least someone who can check it in. Is there anyone willing to ask the right people? You might look at the initials for whoever changed the code recently and see if you can figure out who that was. Meanwhile, I will try and test it within the week. See below for my question about the patch. Billy --- sys/conf/options.stock Tue Sep 27 00:28:50 2005 +++ sys/conf/optionsTue Sep 27 00:55:53 2005 @@ -301,6 +301,7 @@ # Options used in the 'ata' ATA/ATAPI driver ATA_STATIC_ID opt_ata.h ATA_NOPCI opt_ata.h +ATA_AGGRESSIVE_PROBE opt_ata.h DEV_ATADISKopt_ata.h DEV_ATAPICDopt_ata.h DEV_ATAPISTopt_ata.h --- sys/conf/NOTES.stockTue Sep 27 00:30:28 2005 +++ sys/conf/NOTES Tue Sep 27 00:56:39 2005 @@ -1501,8 +1501,11 @@ # # ATA_STATIC_ID: controller numbering is static ie depends on location # else the device numbers are dynamically allocated. +# ATA_AGGRESSIVE_PROBE:Does not give up on probing when all err, lsb, and + msb are identical. Shouldn't there be a comment for the above line? Like this: +# msb are identical. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-STABLE changes breaks IDE boot (was Re: 5.3 - 5.4 breaks ATA (Intel ICH2))
Michael L. Squires wrote: This may be a similar problem to the one discussed in the Intel ICH2 thread. System is a Toshiba 8100. System boots from a 5.4-STABLE kernel compiled 5/3/2005 but locks up on boot with kernels compiled in the past few days. I re-cvsup'd after the first lockup and build a GENERIC kernel, same results. The atapci0 lines were divided by the mailer to fit into an 80 col line, I've added the \. The only difference I can see is that the working kernel allocates port 0xfff0-0x to atapci0, and both the non-working kernels don't allocate those ports. This is the only difference I can see between the working and non-working output from the boot process. I would like to concur with this sighting. I will repeat it to emphasize this for whoever can decipher this for bug fixes: 1. In recent 5-Stable 2. The IDE controller, atapci0, 3. seems to be detectected, but without a certain memory allocation 4. namely, 0xfff0-0x 5. while the other memory and I/O segments are detected fine. Furthermore, 6. It won't boot on the affected machines. 7. More than one controller is affected (ICH2, PIIX3, and possibly PIIX4) 8. Mine, at least, boots fine to a July 4th 5-Stable. Here is an example I found from someone reporting a similar issue (Julian Dunn) Look at this from his dmesg: *First* his good booting dmesg line: atapci0: Intel PIIX4 UDMA33 controller port 0xfff0-0x,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 2.1 on pci0 *Second* his non-booting dmesg line: atapci0: Intel PIIX4 UDMA33 controller port 0x376,0x170-0x177,0x3f6,0x1f0-0x1f atapci0: Lazy allocation of 0x10 bytes rid 0x20 type 4 at 0 7 at device 2.1 on pci0 Can I point out the fact that these two lines (first from the good, second from the bad dmesg) seem to say that atapci0 is not getting its memory segment detected -- the segment at 0xfff0-0x. I found this out prior to the post by Mr. Squires, independently. I'm starting to smell a PR, and perhaps some attention by the maintainer of the pci-ata code, which I think is [EMAIL PROTECTED] Billy The complete old dmesg is attached. Mike Squires --hopefully relevant parts of old dmesg-- FreeBSD 5.4-STABLE #0: Tue May 3 21:29:44 EST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/PORT Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (697.42-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 402522112 (383 MB) avail memory = 384188416 (366 MB) npx0: math processor on motherboard npx0: INT 16 interface acpi0: TOSHIB 750 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xfe08-0xfe0b on acpi0 cpu0: ACPI CPU (2 Cx states) on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xd000-0xdfff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 3.0 on pci0 isa0: ISA bus on isab0 isab1: PCI-ISA bridge at device 5.0 on pci0 device_attach: isab1 attach returned 6 atapci0: Intel PIIX4 UDMA33 controller port \ 0xfff0-0x,0x376,0x170-0x177,0x3f6,D0x1f0-0x1f7 at device 5.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ---nonworking atapci0 command, hand copied-- atapci0: Intel PIIX4 UDMA33 controller port \ 0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 5.1 on pci0 Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #0: Tue May 3 21:29:44 EST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/PORT Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (697.42-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 402522112 (383 MB) avail memory = 384188416 (366 MB) npx0: math processor on motherboard npx0: INT 16 interface acpi0: TOSHIB 750 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xfe08-0xfe0b on acpi0 cpu0: ACPI CPU (2 Cx states) on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xd000-0xdfff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge
Re: 5.3 - 5.4 breaks ATA (Intel ICH2)
Okay, Tim, I just reported the same bug in a previous post. So did Julian C. Dunn. I think this is an issue with some recent code changes in CVS... See these threads: critical BOOT failure updating to latest 5-Stable (5.4) 9/23/2005 12:07 AM ATA lockup with 5.4-STABLE 9/21/2005 10:19 PM I have privately emailed Mr. Dunn, and his problem seems a little different perhaps, but I see some similarities. His system is an IBM (so is mine) and his uses the Intel PIIX4 ata chipset. Mine uses the PIIX3. Mine is by far the oldest, and yours is the newest system. Of note maybe is that I was also using an older drive as you are, in my case an 8 or 9 GB Quantum Fireball. Anyway, I count three systems that are normally boting with 5.3 or 5.4, and then the upgrade to the latest 5-Stable breaks the boot. Perhaps you could test one of those identical machines with a simple hard disk swap? Just put the bad booting drive in a working system and see if the error is still there? Has anyone checked the CVS repository for a possible change to the ATA detection or boot code? Can you post your dmesg for 5.3 perhaps? BTW, you can boot that machine to the old kernel using the procedure unload load /boot/kernel.old/kernel boot (or boot -v) Do all of that with option 6 on the Boot Loader menu. Thanks, Billy Tim Howe wrote: I've got a machine here that I'm trying to install FreeBSD 5.4 on. It's identical (except for the hard drive) to another machine that I ran the 4.x series on for some time with no issues. I've got several other Pentium 3-based machines running 5.4-RELEASE-p3 with a GENERIC kernel, and I have a 5.3 installer disk, so my strategy was to do a minimal install of 5.3, then NFS mount /usr/src and /usr/obj from my organizational build server and upgrade to 5.4 from there. The 5.3 install went smoothly, make installkernel went smoothly, but when I tried to reboot I got an error saying that it couldn't find the root filesystem. Further investigation found that it wasn't able to find the ATA HDD (master on ata0) at all, but could find the ATAPI CDROM drive (master on ata0). I verified that the drive had not gone bad by again booting off the 5.3 installer disk, which found ad0 with no difficulty. I then downloaded the 5.4 mini-CD, which was unable to find ad0. Finally, I swapped in another hard drive with identical results. Neither booting with ACPI disabled (didn't bother to check whether this machine even has it) nor booting in safe mode helped at all. I did happen to notice that when the 5.3 CD boots, there is a delay of several seconds when probing ata0. Could this be a timing issue with regard to the controller? The machine is a Gateway ATXSTF FED Pro M1000 with a 1GHz Pentium III and 256MB of RAM. It has an onboard Intel ICH2 UDMA100 controller. The first HDD I tried was a Western Digital Caviar 32500 2559.8MB drive, and the second was a Caviar 24300 4311.9MB drive. If necessary, I'm willing to build custom kernels for testing purposes or to add debugging statements etc, if anyone can give me pointers in the right direction. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
critical BOOT failure updating to latest 5-Stable (5.4)
I have a usable kernel that I built from 5-Stable sources on July 4th, 2005. But the last two days, I tried to compile and install the lastest 5-Stable, and neither one would boot. During the boot, the entire normal dmesg is output (the part which is in bold on the CRT), except the last line which normally says, Mounting root from ufs:/dev/ad0s1a the system freezes with the disk LED on on the computer. So the last message I see on the screen during the failed boot is this: SMP: AP CPU #1 Launched! Freeze Okay, since I tried two kernels, and both froze up at the same place, but there was one minor difference, here it is... I saw this error the very last time I booted to the second bad kernel: ad0: TIMEOUT - READ_DMA retrying (2 retries left) LBA=0 This error was right below the line SMP: AP CPU #1 Launched! Okay, that is definitely an indication of some sort of timing or driver issue. But as far as I know, this hard disk has no other known problems, and obviously it boots flawlessly on the other 5.4 kernels and has for a long, long time. Has anything changed in the bootstrap code for the last two months in 5-Stable? I have not left the machine frozen for more than a couple of minutes, but during that time Scroll Lock/Scroll Back won't work. But it's possible the system is possibly in a long (but finite) state of disk reading and it's not completely frozen. I am inclusing the dmesg from a good boot. It looks like the bad boot messages are the same, at least as far as I can tell. Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #0: Mon Jul 4 18:28:47 CDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BILLYSMP3 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = GenuineIntel Id = 0x617 Stepping = 7 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 536870912 (512 MB) avail memory = 515719168 (491 MB) MPTable: IBM-PCCO CrossFire MP FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0xfff0-0x,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 1.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: Intel 82371SB (PIIX3) USB controller port 0x5400-0x541f irq 19 at device 1.2 on pci0 usb0: Intel 82371SB (PIIX3) USB controller 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 rl0: D-Link DFE-530TX+ 10/100BaseTX port 0x5000-0x50ff mem 0x5000-0x50ff irq 18 at device 6.0 on pci0 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:ba:4d:57:6f pci0: display, VGA at device 11.0 (no driver attached) orm0: ISA Option ROM at iomem 0xc-0xc7fff on isa0 fdc0: Enhanced floppy controller at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 6 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ep0: 3Com 3C509B-TPO EtherLink III (PnP) at port 0x210-0x21f irq 5 on isa0 ep0: Ethernet address: 00:a0:26:77:23:83 unknown: PNP0303 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0401 can't assign resources (port) unknown: IBM37a0 can't assign resources (port) Timecounters tick every 10.000 msec IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled Interrupt storm detected on irq5: ep0; throttling interrupt source ad0: 8809MB QUANTUM FIREBALLP KA9.1/A42.0400 [17898/16/63] at ata0-master WDMA2 ad2: 2014MB WDC AC22100H/10.07H11 [4092/16/63] at ata1-master WDMA2 acd0: DVDROM TOSHIBA DVD-ROM SD-M1212/1R14 at ata1-slave PIO4 SMP: AP CPU #1 Launched! Mounting root from
ep0 Interrupt Storm, 3Com EtherLink III (PnP)
Does anyone know exactly what to do about an interrupt storm, or if it really is a problem? I have an old system acting as a router/firewall. It is a dual processor, so I use SMP. But since going to 5.3 and 5.4, it would seem that this system runs a bit worse than under 4.7. It could be based on just an old BIOS, which will never be updated now, which doesn't support some of the new stuff. It's not ACPI, and PnP seems to be marginal as it always has been. Other than the dmesg output, I would know nothing about such a storm. Since it is happening to a network card, I was wondering if it needs to be addressed. I also don't know about the unknown: PNP0303 can't assign resources (port) errors. But back to the main issue, what is the storm all about? # vmstat -i interrupt total rate irq1: atkbd0 634 0 irq5: ep01037411 2 irq6: fdc010 0 irq8: rtc 58059776127 irq14: ata0 7724041 17 irq15: ata129416 0 irq18: rl0 2068244 4 irq0: clk 45353879 99 Total 114273411251 *dmesg output (Storm is near the last line): FreeBSD 5.4-STABLE #0: Mon Jul 4 18:28:47 CDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BILLYSMP3 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = GenuineIntel Id = 0x617 Stepping = 7 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 536870912 (512 MB) avail memory = 515719168 (491 MB) MPTable: IBM-PCCO CrossFire MP FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0xfff0-0x,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 1.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: Intel 82371SB (PIIX3) USB controller port 0x5400-0x541f irq 19 at device 1.2 on pci0 usb0: Intel 82371SB (PIIX3) USB controller 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 rl0: D-Link DFE-530TX+ 10/100BaseTX port 0x5000-0x50ff mem 0x5000-0x50ff irq 18 at device 6.0 on pci0 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:ba:4d:57:6f pci0: display, VGA at device 11.0 (no driver attached) orm0: ISA Option ROM at iomem 0xc-0xc7fff on isa0 fdc0: Enhanced floppy controller at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 6 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ep0: 3Com 3C509B-TPO EtherLink III (PnP) at port 0x210-0x21f irq 5 on isa0 ep0: Ethernet address: 00:a0:24:6c:1b:46 unknown: PNP0303 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0401 can't assign resources (port) unknown: IBM37a0 can't assign resources (port) Timecounters tick every 10.000 msec IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled Interrupt storm detected on irq5: ep0; throttling interrupt source ad0: 8809MB QUANTUM FIREBALLP KA9.1/A42.0400 [17898/16/63] at ata0-master WDMA2 ad2: 2014MB WDC AC22100H/10.07H11 [4092/16/63] at ata1-master WDMA2 acd0: DVDROM TOSHIBA DVD-ROM SD-M1212/1R14 at ata1-slave PIO4 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s1a ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rcorder dumps core for a circular dependency
I am wondering if I should file a PR on /sbin/rcorder dumping core? This is a reproducible core dump. I am using FreeBSD 5-Stable dated July 2, I think. SMP, i386, custom kernel. First, try this. Make a file that looks like this: #!/bin/sh # # PROVIDE: hello_world # REQUIRE: hello_world Now, save it, and let's call it hello_world.sh Now, try and order this one file. #rcorder hello_world.sh rcorder: Circular dependency on file `hello_world.sh'. rcorder: Circular dependency on provision `hello_world' in file `hello_world.sh'. rcorder in free(): error: chunk is already free Abort (core dumped) Exit 134 Whoops, that's not nice, is it?!?? Since rcorder normally only runs at bootup, I smell a big problem if such a problem existed in a startup script. I know that this file does indeed have a circular dependency, but let's please not dump core because of it. The impending other problem is that 6-current will soon be released, and there will be eventually a stable, and in that branch everything in /usr/local/etc/rc.d/*.sh is sent to rcorder. Putting rcorder into our world of ports maintainers, some of which could write some insane rcng startup files ouch. Perhaps we need to ensure that things of this sort can't happen -- and we need a strenuous sanity check on the files in /usr/local/etc/rc.d between now and 6-release. I know, admins should check these files, but in many cases they may not, and then get a big *surprise* when their machine dumps core during boot. I guess it's one thing for 6-Current, but another thing for the stable tree. We may have a lot of time in the 5.x tree, but as sure as I say that, the new /etc/rc.d/localpkg hack will get backported to 5.x and something may start going wrong. Back to the circular dependency, I have one example of this happening in a port's rc.d script, but I don't want to mention any names... I found this out when a port I had installed kept crashing rcorder when I tried running rcorder on /usr/local/etc/rc.d/*.sh. So now that I found this, I was going to write a PR, but hey, I figured I'd say something here first. Can someone verify this on 6-Current, anyway? If so, it is definitely a major bug for that branch. For 5.x, rcorder is only run on a small set of files in /etc, most of which don't get edited much, minimizing its impact. But still a bug nevertheless. One other thing: I know nothing about NetBSD, but should this be reported to them, too? Okay, one more shot at this bug. Try this shell script: #!/bin/sh # # PROVIDE: hello_world # BEFORE: hello_world Save it as hello1.sh. # rcorder hello1.sh rcorder: Circular dependency on file `hello1.sh'. rcorder: Circular dependency on provision `fake_prov_' in file `hello1.sh'. rcorder in free(): error: chunk is already free Abort (core dumped) Exit 134 Whoops again. Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
How do I determine if ipv6 is enabled?
Is there a sysctl variable, or a quick method to determine if ipv6 is enabled in the kernel? e.g. How do I test for the prescence of ipv6 in a script or at the commandline? Thanks, Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcorder for FreeBSD 5.3?
Hans Lambermont wrote: Billy Newsom wrote: Does anyone have FreeBSD 5.3 installed (preferably a version compiled before March 2005) FreeBSD 5.3-RELEASE #3: Sun Dec 19 14:54:18 CET 2004 What is the output for this command under FreeBSD 5.3? sh -c cd /etc/rc.d ; rcorder -s nostart * 2/dev/null preseedrandom initdiskless rcconf.sh initrandom dumpon vinum gbde_swap gbde ccd swap1 early.sh fsck root mountcritlocal ipfilter var cleanvar addswap sysctl hostname ipmon random adjkerntz atm1 ipnat ipfs kldxref sppp serial pccard netif isdnd ppp-user ipfw dhclient nsswitch ip6addrctl atm2 routing ip6fw network_ipv6 mroute6d route6d mrouted routed NETWORKING devd mountcritremote lomac syslogd savecore SERVERS named ntpdate rpcbind nisdomain ypxfrd ypserv ypupdated ypbind ypset yppasswdd accounting nfsclient amd atm3 tmp cleartmp dmesg ike ipsec ipxrouted kerberos kadmind keyserv kpasswdd ldconfig quota nfsserver mountd nfsd nfslocking pflog pf pppoed pwcheck virecover DAEMON watchdogd usbd ugidfw timed apm apmd bootparams local lpd motd ntpd rarpd rtadvd rwho LOGIN syscons sshd sendmail archdep abi cron devfs jail localpkg netoptions securelevel resolv pcvt othermta msgs moused mixer inetd bgfsck -- Hans Hmm. That's interesting. Thanks. Here's a diff I ran on the two outputs. Notice that the ipfilter script is in a different spot, but just barely. Although I was trying to make something of the situation, I don't immediately see how it can make a big difference. I was really trying to see if/how ipnat would stop working (at least immediately after reboot) until I flushed and reloaded ipnat. #diff -u 53.txt 54.txt --- 53.txt Sat Jul 2 23:05:19 2005 +++ 54.txt Sat Jul 2 23:06:17 2005 @@ -12,9 +12,9 @@ fsck root mountcritlocal -ipfilter var cleanvar +ipfilter addswap sysctl hostname @@ -95,6 +95,7 @@ bootparams local lpd +mixer motd ntpd rarpd @@ -117,6 +118,5 @@ othermta msgs moused -mixer inetd bgfsck Anyhow, I don't see what bearing any of this would have on ipnat mysteriously stop working for me. The only thing I see is that I might have at some point started using interface renaming. The only thing I can figure at this point by looking into this is that when I edited ipnat.rules, I used my renamed interfaces, just as I did in ipf.rules. What I see in the rcorder outputs is that /etc/rc.d/netif comes after /etc/rc.d/ipnat. In other words, perhaps my interface names in my ipnat.rules file is being loaded during bootup *before* those interface names exist! If so, ipnat would act weirdly, perhaps. One of the routines run by /etc/rc.d/netif on line 69 is /etc/rc.d/ipfilter resync which seems to resync ipfilter, but not ipnat. What I see is that it seems like renaming interfaces *might* have broken ipnat. And that might explain why I have to manually run /sbin/ipnat -CF -f /etc/ipnat.rules after every boot. I think I will script this, and watch the output of ipnat -l. As far as I know, ipnat was supposed to work fine with renamed interfaces, but maybe not dunno. Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rcorder for FreeBSD 5.3?
Does anyone have FreeBSD 5.3 installed (preferably a version compiled before March 2005) and you can help? I am still trying to help diagnose a problem I have in which something may be started before something else. In my case, ipnat. When I upgraded to 5.4 (or a late 5-stable), I started having a problem. Someone please help me troubleshoot rcorder on your machine, as I don't have an older release. What is the output for this command under FreeBSD 5.3? sh -c cd /etc/rc.d ; rcorder -s nostart * 2/dev/null I get this output on my machine: preseedrandom initdiskless rcconf.sh initrandom dumpon vinum gbde_swap gbde ccd swap1 early.sh fsck root mountcritlocal var cleanvar ipfilter addswap sysctl hostname ipmon random adjkerntz atm1 ipnat ipfs kldxref sppp serial pccard netif isdnd ppp-user ipfw dhclient nsswitch ip6addrctl atm2 routing ip6fw network_ipv6 mroute6d route6d mrouted routed NETWORKING devd mountcritremote lomac syslogd savecore SERVERS named ntpdate rpcbind nisdomain ypxfrd ypserv ypupdated ypbind ypset yppasswdd accounting nfsclient amd atm3 tmp cleartmp dmesg ike ipsec ipxrouted kerberos kadmind keyserv kpasswdd ldconfig quota nfsserver mountd nfsd nfslocking pflog pf pppoed pwcheck virecover DAEMON watchdogd usbd ugidfw timed apm apmd bootparams local lpd mixer motd ntpd rarpd rtadvd rwho LOGIN syscons sshd sendmail archdep abi cron devfs jail localpkg netoptions securelevel resolv pcvt othermta msgs moused inetd bgfsck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: auto cvsup
Here's a neat little script you can run from cron or commandline. I use
it to update the ports tree and the source tree for 5-STABLE. Feel free
to change the cvsup logging to suit (I don't log the ports, but I do log
important STABLE src stuff). Also, use the correct country for mirrors.
You need to install cvsup, portupgrade, fastest_cvsup, and if you want,
try freebsd-update. The portupgrade line at the bottom may not be
needed by many. But this way, I already have the latest ports
distfiles, if I want, so when I am ready to run portupgrade, the
download is already on my disk.
Ensure you put your cvsup files in the right place (or edit the script
below.) I run this every other day on FreeBSD 5.4. The logs help me
see what needs to be updated. (Every time it runs, it will show you
what ports could be updated. It will also show you what files were
updated in the source tree.)
my cron entry:
33 2 */2 * * /root/mydaily.sh 1/dev/null 2/dev/null
Weekly is like this:
33 2 * * 3 /root/mydaily.sh 1/dev/null 2/dev/null
***/root/mydaily.sh*
#!/bin/sh
#
# Billy saw something like this on 12/18/2004 at:
#http://www.oreillynet.com/pub/wlg/6041?page=lastx-order=date
#
LOGF=/var/log/cvsup.log
exec ${LOGF} 21
echo START @ `/bin/date`
#use fastest_cvsup to find fastest geographically
#close mirror; I'll check Canada and the US
if SERVER=`/usr/local/bin/fastest_cvsup -Q -c ca,us`; then
echo Using STABLE Server: $SERVER
/usr/local/bin/cvsup -L1 -h $SERVER -l /var/log/cvs-lock-s
/root/stable-supfile
echo STABLE done @ `/bin/date`
else
echo cvsup-STABLE has a fastest_cvsup problem on...`/bin/date`
fi
if SERVER=`/usr/local/bin/fastest_cvsup -Q -c ca,us`; then
echo Using PORTS Server: $SERVER
/usr/local/bin/cvsup -L0 -h $SERVER -l /var/log/cvs-lock-p
/root/ports-supfile
echo PORTS done @ `/bin/date`
else
echo cvsup-PORTS has a fastest_cvsup problem on...`/bin/date`
fi
#-U (which takes a long time to execute) isn't needed
#with the fetchindex command
cd /usr/ports
make fetchindex
/usr/local/sbin/portsdb -u
##
# This program is nice, too. Remove two comments below to suit.
# echo Looking for security patches
# freebsd-update fetch
##
echo The following ports need upgrading
/usr/local/sbin/portversion -l
echo
echo Now downloading the new port distfiles
/usr/local/sbin/portupgrade -OaF |grep -v Fetching |grep -v Skipping
echo STOP at `/bin/date`.
echo
Maher Mohamed wrote:
how can i upgrade my cvsup weekly with an auto way?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 SMP kernels now available via FreeBSD Update
Colin Percival wrote: It sounds like the SMP kernel I provided for FreeBSD 5.3 was quite popular, so I've started building an SMP kernel for FreeBSD 5.4 as well, in addition to the usual GENERIC kernel. To take advantage I'm curious how popular. Would you like to report some statistics here on the list? As in, how many SMP downloads did you get, say, in comparison to the GENERIC? I wonder just how popular SMP has become. I ran dual Pentium 120s on a 430HX motherboard once a long time ago. And I know SMP goes farther back to at least the Pentium 60. Back then, it was pretty unusual, but I wonder what it's like now. Thanks. BTW, nice idea you've got. I tried to use it back before you offered SMP kernels and was disappointed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 This is on a Dell PowerEdge 2850. (2 * 2.8 GHz Xeons, 4GB ram, disks), we've been keeping up with stable because supposedly all these new fixes to threading will help us out here. We're trying to get FreeBSD to perform reasonably well, in comparison to Linux, or even what we should expect to see. We're getting about half the performance we get from gentoo on the same application (mysql). [snip] Thanks in advance for anyone that has a clue on this, and has anyone figured out why FreeBSD is just so amazingly slow compared to Linux. Have you looked around for different compilers and/or different compiler options? I was just remembering how different code can be, depending on which gcc, for example, was used, and definitely which optimization. (i.e. Try gcc -v on both systems to see if they match; next see if all compiler options match when they are compiling like -march=pentiumpro.) Meanwhile, I have heard good things about compiler fill in the blank for whatever. Not too long ago, I remember hearing about people who preferred to use, say, an Intel compiler for certain things. It might be interesting to see if FreeBSD 4.11 is just as slow as 5.x. And try feeding the right compiler flags using /etc/make.conf or its equivalent. You should also think about whether the file systems are mounted using similar, or equally-performing systems. Rumour has it that Linux file systems performance is [flame bait mysteriously deleted]... Your benchmark may produce some interesting results, for example, depending on whether it thrashes a disk, or mainly hits memory. Do they perform the same on small sized (cached) lookups and then FreeBSD bogs down on disk throughput, for example? Last, but not least, I have heard some not-so-impressive things about MySQL 4.1 when compared to 4.0. Perhaps the things I heard were in reality specific to FreeBSD, and so by dropping back to 4.0 on a test server, you might see an unexpected performance boost? (Be sure and delete the tables between runs.) 4.0 is still in the ports tree, and I have heard of some who wished they never upgraded to 4.1. But going backwards is not pretty for a live database, so test both versions now. Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ipnat is definitely broken in RELENG_5_4
I posted previously that ipnat failed to start after I upgraded to FreeBSD 5.4. On the same machine, I am having additional ipnat failures. I reported the first time that ipnat failed to start on the first boot. I am now reporting that on the second boot, ipnat loaded and installed its tables, as expected. A quick ipnat -vls at boot confirmed this. YEAH! But ON SECOND LOOK, I found out that ipnat was failing to do its normal network translation. A subsequent ipnat -vls confirmed that there were no statistics for anything a day later -- all 0's, but I should have been mapping in and out a lot of connections. So I cleared ipnat's tables and reloaded the same ones. Instantly some connections that were waiting to start were NATed in, and I saw some active connections in the NAT statistics. There had apparently been none since the second boot using FreeBSD 5.4. I am adding this to the PR I filed, because something is still amiss. I am now trying to figure out how to write a babysitter script for ipnat, so it runs at boot, and maybe periodically to ensure NAT is on. If I am away from this server, I wonder what I would do if I depended on ipnat??? I would be firewalled out, essentially, needing to login locally. This is major, so I am going to keep being persistent about it. Thanks for any insight or workarounds... Still need to try enabling ipv6 in rc.conf as someone suggested??? Does that seem right? Here's a few sanitized shell outputs. We have changed the port numbers to protect the innocent. Sun May 29 18:19:29 CDT 2005 [[My bootup time]] # ipnat -vls mapped in 0 out 0 added 0 expired 0 no memory 0 bad nat 0 inuse 0 rules 6 wilds 0 table 0xbfbfebc8 list 0xc1bc6e00 List of active MAP/Redirect filters: rdr oo0 192.168.1.2/32 port 899 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 2 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 1238 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 1234 - 127.0.0.1 port 56 tcp rdr oo0 192.168.1.2/32 port 1236 - 127.0.0.1 port 192 tcp rdr oo0 192.168.1.2/32 port 1237 - 192.168.0.2 port 152 tcp List of active sessions: List of active host mappings: [And I did this on the 30th!!! with no statistics a day later]] # ipnat -vls mapped in 0 out 0 added 0 expired 0 no memory 0 bad nat 0 inuse 0 rules 6 wilds 0 table 0xbfbfeba8 list 0xc1bc6e00 List of active MAP/Redirect filters: rdr oo0 192.168.1.2/32 port 899 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 2 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 1238 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 1234 - 127.0.0.1 port 56 tcp rdr oo0 192.168.1.2/32 port 1236 - 127.0.0.1 port 192 tcp rdr oo0 192.168.1.2/32 port 1237 - 192.168.0.2 port 152 tcp List of active sessions: List of active host mappings: # ipnat -C 6 entries flushed from NAT list # ipnat -vls mapped in 0 out 0 added 0 expired 0 no memory 0 bad nat 0 inuse 0 rules 0 wilds 0 table 0xbfbfeba8 list 0x0 List of active MAP/Redirect filters: List of active sessions: List of active host mappings: # ipnat -f /etc/ipnat.rules [Here is a few minutess later] # ipnat -vls mapped in 14 out 12 added 1 expired 0 no memory 0 bad nat 0 inuse 1 rules 6 wilds 0 table 0xbfbfeba8 list 0xc43f1a00 List of active MAP/Redirect filters: rdr oo0 192.168.1.2/32 port 899 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 2 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 1238 - 127.0.0.1 port 99 tcp rdr oo0 192.168.1.2/32 port 1234 - 127.0.0.1 port 56 tcp rdr oo0 192.168.1.2/32 port 1236 - 127.0.0.1 port 192 tcp rdr oo0 192.168.1.2/32 port 1237 - 192.168.0.2 port 152 tcp List of active sessions: RDR 127.0.0.1 99- - 192.168.1.2899 [16.10.10.211 42666] age 438 use 0 sumd 0xba36/0xba36 pr 6 bkt 251/408 flags 1 drop 0/0 ifp oo0 bytes 8532 pkts 26 List of active host mappings: ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-Stable (5.4) any ipnat changes?
Billy Newsom wrote: Okay, I'm going to dig up someone who might be responsible or might be able to fix it. Two strikes while doing the same upgrade... While I'm thinking about it, would you see if it happens on the next reboot? I haven't tried, because my system is a firewall that I need to keep up most of the time (I'm behind it right now), but I will definitely see if it happens again soon. I am going to check some cvs checkins in the last three months or so and see if I can track down a change. As for the custom kernel, I wonder if we both need to post the details of our custom kernel to this list for others to see? I wonder if the problem is only with certain kernel switches. I am attaching my kernel (with no comments) to this email. Let me know if it's easier to read with the comments in it, because a lot of the generic kernel fluff has been removed for sake of speed. (Replying to self) Well, I filed a PR for this at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/81606 So if anyone wants to follow it, watch that. I looked at the changes to ipnat, (like ip_nat.c) and found that Darren Reed and Robert Watson seem have put in some changes to the ipfilter code to bring it up to the current release used in Solaris (4.1.8 from 3.4.35 I believe). They had it tested in HEAD (6-current) it looks like, and they just merged it into the STABLE branch in March. Not being familiar with it, I don't see immediately what could have made ipnat not start on boot. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/ipfilter/netinet/ Most changes to STABLE on Mar. 15. Or perhaps something in the rc, rcng, etc. could have done this. ipnat may have slipped through somehow and not gotten started. I just rebooted the machine that had the problem, and so far ipnat was automatically loaded and is running fine. Could this only be a problem on the first reboot or something? Or is it an intermittent problem? Since others have reported having the same problem, can anyone confirm what happens on the subsequent boots? I have ipv6 disabled on my system... Is that a prerequisite? I have had it disabled for a long time with no problems, and of course, ipnat runs fine. I know Darren made some changes to get ipv6 to run recently, but would that be it? Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-Stable (5.4) any ipnat changes?
sergei wrote: I have the same problem: After I cvsuped my system from 5.3 to 5.4, ipfilter (compiled in the my custom kernel) ipnat not start automatically. If I do /etc/rc.d/ipfilter start /etc/rc.d/ipnat start manually - all works fine... Lines ipfilner_enable=YES and ipnat_enable=YES present in the /etc/rc.conf. Okay, I'm going to dig up someone who might be responsible or might be able to fix it. Two strikes while doing the same upgrade... While I'm thinking about it, would you see if it happens on the next reboot? I haven't tried, because my system is a firewall that I need to keep up most of the time (I'm behind it right now), but I will definitely see if it happens again soon. I am going to check some cvs checkins in the last three months or so and see if I can track down a change. As for the custom kernel, I wonder if we both need to post the details of our custom kernel to this list for others to see? I wonder if the problem is only with certain kernel switches. I am attaching my kernel (with no comments) to this email. Let me know if it's easier to read with the comments in it, because a lot of the generic kernel fluff has been removed for sake of speed. I removed them with: cat mykernel | sed -e 's;#.*;;' -e '/^[ ]*$/d' mykernel.1 Billy ~-Original Message- ~From: [EMAIL PROTECTED] ~[mailto:[EMAIL PROTECTED] On Behalf Of Billy Newsom ~Sent: Thursday, May 26, 2005 1:54 AM ~To: freebsd-stable@freebsd.org ~Subject: 5-Stable (5.4) any ipnat changes? ~ ~ ~Is there some reason why ipnat wouldn't automatically startup? ~ ~I just upgraded from a 5-stable in February to a 5-stable in ~May, so I ~could essentially get 5.4 on this firewall machine. I simultaneously ~was upgrading some ports, etc., but nothing too severe. When ~I rebooted ~the machine, everything looked fine. No problems whatsoever. ~ This was ~the first time that I compiled multiple kernels (normally I ~just compile ~a custom and not the generic), but that is not related. ~ ~What happened is that I had a strange problem receiving mail ~on the mail ~server. It took me quite a while to finally track down the ~problem. I ~ended up running a packet sniffer and still couldn't figure it out. ~Well, it turned out that the filters in ipnat weren't ~installed, and so ~all of the NAT routing wasn't happening as normal. ~ ~I have really never seen this server boot without NAT -- it's ~basically ~the same setup I've used for years and it never dawned on me ~what would ~happen if ipnat failed to run its filters. Meanwhile, ~IPFilter was busy ~running the firewall like normal. ~ ~I have looked at the logs in detail and I can't find anything ~that would ~have turned off ipnat or caused it not to run its filter. ~Nor, on the ~otherhand, do I see where ipnat logs anything, anyway. ~ ~Where would I look to track this down? Is it possible that ~something in ~ stable messed this up? ~ ~ ~# ls -l /etc/ipnat.rules ~-rw-r--r-- 1 root wheel 437 Mar 14 14:18 /etc/ipnat.rules ~ ~Notice no changes since March in that file. ~ ~# cat /etc/rc.conf | grep ip ~ipfilter_enable=YES # Set to YES to enable ipfilter ~functionality ~ipfilter_program=/sbin/ipf# where the ipfilter program lives ~ipfilter_rules=/etc/ipf.rules # rules definition file for ~ipfilter, see ~ # ~/usr/src/contrib/ipfilter/rules for ~examples ~ipfilter_flags= # additional flags for ipfilter ~ipnat_enable=YES # Set to YES to enable ipnat ~functionality ~ipnat_program=/sbin/ipnat # where the ipnat program lives ~ipnat_rules=/etc/ipnat.rules # rules definition file for ipnat ~ipnat_flags= # additional flags for ipnat ~ipmon_enable=YES# Set to YES for ipmon; ~needs ipfilter ~or ipnat ~ipmon_program=/sbin/ipmon # where the ipfilter ~monitor program lives ~ipmon_flags=-Ds # typically -Ds or -D ~/var/log/ipflog ~ipfs_enable=YES # Set to YES to enable saving ~and restoring ~ipfs_program=/sbin/ipfs # where the ipfs program lives ~ipfs_flags= # additional flags for ipfs ~ ~Thanks. ~Billy machine i386 cpu I686_CPU ident BILLYSMP3 hints GENERIC.hints options SMP options MSGMNB=8192 options MSGSSZ=64 options MSGTQL=2048 options MAXCONS=6 options IPFILTER options IPFILTER_LOG options SCHED_4BSD options INET options FFS options SOFTUPDATES options UFS_ACL options UFS_DIRHASH options NFSCLIENT options NFSSERVER options PROCFS options PSEUDOFS options GEOM_GPT
5-Stable (5.4) any ipnat changes?
Is there some reason why ipnat wouldn't automatically startup? I just upgraded from a 5-stable in February to a 5-stable in May, so I could essentially get 5.4 on this firewall machine. I simultaneously was upgrading some ports, etc., but nothing too severe. When I rebooted the machine, everything looked fine. No problems whatsoever. This was the first time that I compiled multiple kernels (normally I just compile a custom and not the generic), but that is not related. What happened is that I had a strange problem receiving mail on the mail server. It took me quite a while to finally track down the problem. I ended up running a packet sniffer and still couldn't figure it out. Well, it turned out that the filters in ipnat weren't installed, and so all of the NAT routing wasn't happening as normal. I have really never seen this server boot without NAT -- it's basically the same setup I've used for years and it never dawned on me what would happen if ipnat failed to run its filters. Meanwhile, IPFilter was busy running the firewall like normal. I have looked at the logs in detail and I can't find anything that would have turned off ipnat or caused it not to run its filter. Nor, on the otherhand, do I see where ipnat logs anything, anyway. Where would I look to track this down? Is it possible that something in stable messed this up? # ls -l /etc/ipnat.rules -rw-r--r-- 1 root wheel 437 Mar 14 14:18 /etc/ipnat.rules Notice no changes since March in that file. # cat /etc/rc.conf | grep ip ipfilter_enable=YES # Set to YES to enable ipfilter functionality ipfilter_program=/sbin/ipf# where the ipfilter program lives ipfilter_rules=/etc/ipf.rules # rules definition file for ipfilter, see # /usr/src/contrib/ipfilter/rules for examples ipfilter_flags= # additional flags for ipfilter ipnat_enable=YES # Set to YES to enable ipnat functionality ipnat_program=/sbin/ipnat # where the ipnat program lives ipnat_rules=/etc/ipnat.rules # rules definition file for ipnat ipnat_flags= # additional flags for ipnat ipmon_enable=YES# Set to YES for ipmon; needs ipfilter or ipnat ipmon_program=/sbin/ipmon # where the ipfilter monitor program lives ipmon_flags=-Ds # typically -Ds or -D /var/log/ipflog ipfs_enable=YES # Set to YES to enable saving and restoring ipfs_program=/sbin/ipfs # where the ipfs program lives ipfs_flags= # additional flags for ipfs Thanks. Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs bug df: Can I lock up my kernel and overflow this buffer?
Jonathan Noack wrote: Anyone tried that sort of stuff in fstab? I'm a little skeptical. I use that sort of stuff and have for a long time. Here's one of my fstab lines: optimator:/usr/home /usr/home nfs rw,-3,-T,-r=32768,-w=32768 0 0 It's obvious you don't believe me but why are you unwilling to try it yourself? Well, because this fails to work on the commandline: #mount -o -s -x 2 -T dell:/nfs /dellbak I tried tons of different ways, never could get mount to do that, so I gave up on fstabbing options. Since the above mount command wouldn't even work, I figured I could forget about putting those same options (which mount calls illegal) in the fstab file. That's where the man pages only go so far. Without the examples you give, I was pretty sure that it was pointless to get fstab options to do what mount wouldn't. What it boils down to is that mount is fine with these options in fstab, but barfs when doing them on the commandline. That was so couter-intuitive, I went around it for the sake of getting things done. FreeBSD man pages are nice and all, but without a textbook siting by with some examples, it can be difficult. I learned Unix pretty much ad hoc, so I find that examples (such as you gave) are worth much more than man pages now that I know most of the basics. Thanks. But what I did discover is that if I mount the same nfs resource multiple times, I get multiple, identical mounts (using fstab options, or commandline, either one). I have to umount each one serially. How is this a feature? What good does it do me if I mount the same nfs drive to the same place n times? Won't that eventually cause a deadlock as n increases beyond a few hundred or thousand? -- especially when the NFS server goes down? Shouldn't the second and subsequent mounts either fail or not be attempted due to a sanity check? #mount /usr mount: /dev/ad0s1f: Device busy Exit 1 That seems reasonable for /usr. But as I stated before, NFS resources nevere apparently become busy, and there is no sanity check to prevent mulitiple simultaneous mounts of identical file systems on identical file trees. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs bug df: Can I lock up my kernel and overflow this buffer?
Erik Trulsson wrote: Note that mount(8) (as well as mount_nfs(8)) says about the -o flag that Options are specified with a -o flag followed by a comma separated string of options. If you try writing it as the manpage says, i.e. like mount -o -s,-x=2,-T dell:/nfs /dellbak it should work fine. I felt pretty confident I had tried something of this sort, and of course now that you say all of that, it works for me. I probably didn't use the hyphens, nor the equals sign, etc. It works fine on the commandline, you just got the syntax for the commandline wrong. But what I did discover is that if I mount the same nfs resource multiple times, I get multiple, identical mounts (using fstab options, or commandline, either one). I have to umount each one serially. How is this a feature? It is a feature in that the system does exactly what you asked it to do. This is usually less painful than systems that try to guess what you actually meant. What good does it do me if I mount the same nfs drive to the same place n times? None that I can think of, which doesn't mean that there is no use for it. Won't that eventually cause a deadlock as n increases beyond a few hundred or thousand? -- especially when the NFS server goes down? Probably not a deadlock, but possible a resource starvation - so don't do that. Which leads me to a test. I am going to try and take a server down this way and see what resources I can max out or overflow by mounting and re-mounting the same thing over and over. I'll write a shell script with an infinite loop, and run it on an old server of mine. Then maybe I'll pull its LAN cable (virtually and actually) and see what happens. Perhaps I'll cross-post the results to the hackers list if I get some interesting results. BN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nfs bug df: Can I lock up my kernel and overflow this buffer?
Here's something pretty stupid about either the code in mount, df, or both. I'm on the verge of a denial of service if this lasts much longer. When I mount an nfs device more than once, I get this ridiculous output from df and mount: #df Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ad0s1a253678 137554 9583059%/ devfs 1 1 0 100%/dev /dev/ad0s1e253678 18 233366 0%/tmp /dev/ad0s1f 7782878 3273986 388626246%/usr /dev/ad0s1d253678 125386 10799854%/var devfs 1 1 0 100%/var/named/dev dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak dell:/nfs 8883912 4104516 477939646%/dellbak #mount /dev/ad0s1a on / (ufs, NFS exported, local) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, NFS exported, local, soft-updates) /dev/ad0s1d on /var (ufs, NFS exported, local) devfs on /var/named/dev (devfs, local) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) dell:/nfs on /dellbak (nfs) Ha, ha! How many times will this last line repeat itself? I'm curious to see if I can get it to give me a screenful of data. Will this eventually crash the kernel or fill some buffer up? All I'm doing is mounting the same nfs drive over and over. Normally, mounting a device twice will just give a device busy or something. Is there some sanity check missing that will prevent mount_nfs from actually mounting the same resource at the same mount point over and over? Details: * FreeBSD 5.3. Updated and compiled in mid-February. I froze it there and may soon upgrade to 5.4, but I don't count on this fixing this issue. * I needed to make sure I had an nfs drive mounted properly, even after a reboot, but didn't want to (couldn't?) put it in fstab. So cron has this particular line(s). 44 10 * * * /sbin/mount_nfs -s -x 2 -T dell:/nfs /dellbak * I am connecting to a local net NFS server running Windows 2000 and Services for UNIX 3.5. Due to some major problems with rebooting and NFS, I determined that I needed some of the special commands (-s -x 2) to enable the server to reboot. * I put the mount_nfs command in cron and in an rc.d startup script because I didn't see a way to put all of the options in fstab, nor did I particularly enjoy booting the FreeBSD server without connecting to the NFS drive I would fill up my root directory pretty fast. * Look at the fsid for /dellbak below, using verbose output. Pretty odd. # mount -v /dev/ad0s1a on / (ufs, NFS exported, local, writes: sync 165 async 29170, reads: sync 2308 async 45, fsid f044aa41725bf386) devfs on /dev (devfs, local, fsid 01ff00040400) /dev/ad0s1e on /tmp (ufs, local, soft-updates, writes: sync 9 async 4002, reads: sync 125 async 0, fsid f144aa411e8f31da) /dev/ad0s1f on /usr (ufs, NFS exported, local, soft-updates, writes: sync 420 async 129755, reads: sync 170752 async 1401, fsid f144aa4134661c3c) /dev/ad0s1d on /var (ufs, NFS exported, local, writes: sync 32187 async 49433, reads: sync 4043 async 102, fsid f244aa416aeef171) devfs on /var/named/dev (devfs, local, fsid 02ff00040400) dell:/nfs on /dellbak (nfs, fsid 03ff00020200) dell:/nfs on /dellbak (nfs, fsid 04ff00020200) dell:/nfs on /dellbak (nfs, fsid 05ff00020200) dell:/nfs on /dellbak (nfs, fsid 06ff00020200) dell:/nfs on /dellbak (nfs, fsid 07ff00020200) dell:/nfs on /dellbak (nfs, fsid 08ff00020200) Any help? Thanks. BN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfs bug df: Can I lock up my kernel and overflow this buffer?
Jonathan Noack wrote: On 05/09/05 23:14, Billy Newsom wrote: From the fstab(5) man page: The fourth field, (fs_mntops), describes the mount options associated with the file system. It is formatted as a comma separated list of options. It contains at least the type of mount (see fs_type below) plus any additional options appropriate to the file system type. See the options flag (-o) in the mount(8) page and the file system specific page, such as mount_nfs(8), for additional options that may be specified. That is how I read the man page, too, long ago. But when I tried the -o option on the commandline, I was unable to send mount all of the mount_nfs commandline switches I needed. I either misunderstand the mount -o option, or it doesn't work for all of the mount_nfs stuff I tried to send it. In other words, the -o option seems to not like any of the many switches understood by mount_nfs hence I seemed to be forced to use mount_nfs directly. And that precludes using it in fstab. What trouble did you have with fstab? You can specify as many options as you want as long as you separate them with commas (I think putting a '=' between an option and its value is also necessary, although I don't know for sure). For you it should look like this (assuming you want read/write): dell:/nfs /dellbak nfs rw,-s,-x=2,-T 0 0 I don't know. Since mount wasn't able to understand those switches on the commandline, I never tried anything in fstab, for the sake of not causing any problems with my boot. Anyone tried that sort of stuff in fstab? I'm a little skeptical. Thanks. BN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 STABLE kernel compilation oddity
Alex Burke wrote: Hi, I wasnt quite sure what to call this problem. I am running FreeBSD 5.3 STABLE on a quad Pentium Pro IBM Netfinity 7000 system, and since the GENERIC kernel does not come SMP enabled I compiled a kernel with SMP support and drivers for networks card and SCSI RAID adapter built into it (not loaded as modules). This build happens fine under the original GENERIC kernel. Afterwards, since that machine is quite powerful and its destined to be a unix server I wanted to compile a kernel for another box I have. I wrote the kernel config file, and started the compilation. At some stage the system crashed, on the console it looked as though it had tried to reboot itself (3 times!) with various messages about CPUs ignoring requests. I dont really understand why under the SMP kernel I compiled the I cannot compile another kernel, but under GENERIC it works fine. I can only think two things, either I have stumbled accross an odd bug or my hardware appears to be working fine on the surface and actually there is something slightly wrong, although this machine ran the GENERIC kernel of 5.2 for a long time without any issues (5.2.1 was SMP enabled from the start I believe). I wish FreeBSD 5.3 was as stable as the STABLE tree implies it was. My SMP problems are quite numerous on 5.3 so far. I have a similar system to yours, but a dual processor. One thing I see is that as the days have gone by since the original 5.3-Release, the SMP code has had some code changes that have alternately caused crashes or compile-time errors, at least from my point of view. I am beginning to regret using 5.3, but all of the press releases nudged me to believe that 5.3 ws ready for live systems. I have to admit that I had problems with 4.7 and 4.9, but not like the 5.3-STABLE track. I hope all of this doesn't give FreeBSD a bad reputation, although it might earn it if it continues to be so buggy for SMP systems. Having no experience with 5.2, I almost wish I could provide more advice. But perhaps you can get the generic kernel off the CD and boot to it to recompile your kernel. See this as one documented example: ftp://ftp.freebsd.org/pub/FreeBSD/ERRATA/notices/FreeBSD-EN-05:03.ipi.asc My last cvs update was the 30th (yesterday) and it compiled for me using make -j6 buildworld and took 3:38. My kernel build took 1:27. Those are with a working SMP kernel, so the generic kernel would take longer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mysql crashes on 5.3-stable, SMP, linuxthreads
Billy Newsom wrote: I have just built a FreeBSD 5.3 box with SMP enabled on a dual processor machine. I kept having a lot of crashes at some point in the install, and I believe I now have the cuprit: mysql-server-4.1.7 is doing it. Lately, when mysql-server is running under no load, it caused lockups of the system, with no core dumps. Troubleshooting: I have been frantically trying to re-install a lot of things -- I did a cvsup on the stable tree, recompiled the source, and tried a generic kernel with no SMP. I reinstalled a lot of ports that could have been doing this. Meanwhile, a lot of things were dumping core. I tried cooling the CPU and memory just in case it was hardware-related. Finally, I now have a stable computer, running in SMP, but only if mysql-server is disabled. Does anyone know what sort of things I can do to get mysql to run? I am in the middle of another recompile of the same mysql-server with the same options (I believe they are openssl, linuxthreads, and optimize) as before. Has anyone seen this problem before? I will report back tomorrow if a simple reinstall of the port has fixed this issue, but I have reinstalled it thrice now. Either my problem was with a screensaver, or re-compiling carefully one more time has fixed this problem, I think. No more crashes that I have seen. Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
mysql crashes on 5.3-stable, SMP, linuxthreads
I have just built a FreeBSD 5.3 box with SMP enabled on a dual processor machine. I kept having a lot of crashes at some point in the install, and I believe I now have the cuprit: mysql-server-4.1.7 is doing it. Lately, when mysql-server is running under no load, it caused lockups of the system, with no core dumps. Troubleshooting: I have been frantically trying to re-install a lot of things -- I did a cvsup on the stable tree, recompiled the source, and tried a generic kernel with no SMP. I reinstalled a lot of ports that could have been doing this. Meanwhile, a lot of things were dumping core. I tried cooling the CPU and memory just in case it was hardware-related. Finally, I now have a stable computer, running in SMP, but only if mysql-server is disabled. Does anyone know what sort of things I can do to get mysql to run? I am in the middle of another recompile of the same mysql-server with the same options (I believe they are openssl, linuxthreads, and optimize) as before. Has anyone seen this problem before? I will report back tomorrow if a simple reinstall of the port has fixed this issue, but I have reinstalled it thrice now. Thanks, Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
