Re: [Samba] Samba upgrade HowTo requested
On Fri, Dec 17, 2010 at 11:26:12AM +0100, Willy Offermans wrote: I do not think that this issue is related to dependencies. Of course I need to be sure that the dependencies are correctly installed as well, but this job is accomplished by ``portupgrade -R -N'' quite well. No, the real problem lays in the settings and databases created in a previous version of samba, which will be lost, altered or corrupted upon an upgrade. To phrase the questions again? Is there a procedure on how to upgrade samba to a newer version? How can the ignorant user be informed when using portupgrade? I'm sorry, I just recall the UPDATING file in /usr/ports/. The following is a cut from this file: snip 20101026: AFFECTS: users of net/samba35 AUTHOR: Timur Bakeyev ti...@freebsd.org This is the latest stable release of the Samba3 distribution. It has been extended with the experimental support of the NFS4-like ACLs on ZFS partitions, thanks to the sysutils/libsunacl library by Edward Tomasz Napierala(trasz). This support haven't been tested thoroughly, so try it on your own risk. This looks interesting. I just did a portsnap fetch update in my FreeBSD 8.1 box, but I don't find that snippet. Where can I find those patches? Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
[trimmed cc list] Julian, On 09/01/10 18:09, Julian H. Stacey wrote: On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their FreeBSD -7 -8 do not support ISDN I'm told. So 6.4 is the last working FreeBSD ISDN. Somebody told you wrong. There's still i4b code in 7-STABLE. It's been axed out for 8-CURRENT short before 8.0-R. So you may want to run 7.x if you depend on ISDN (AFAIK it's still in a working condition for 7). Cheers, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: usb keyboard dying at loader prompt
On 11/11/08 19:55, Peter Wemm wrote: ... * There were other consequences of using the partition ID hack - I think I remember it turning off the apic for msdos mode. Your problems may be different, but mine were caused by a BIOS whitelist of MBR partition id's. What a stupid problem. On that motherboard I ended up taking the path of least resistance and using the PS/2 adapter plug on the keyboard. Peter, very interesting what you've found. That reminds me on some investigations I did as I was hunting USB boot device problems. Some BIOSes do not check the partition (slice) ID but are looking for a file system magic. If a FAT filesystem is detected, the BIOS does some stupid things (like ignoring the active partition flag and booting the FAT slice no matter what you've flagged active). Just an example and off-topic to Andriy's keyboard problem. But when combining that with your findings, it may still be a thing to check for... ;) Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb keyboard dying at loader prompt
Andriy, On 12/23/-58 20:59, Andriy Gapon wrote: I have a quite strange problem. This is with 7-BETA amd64. Did it work with earlier versions? All of USB is out of kernel and is loaded via modules. BIOS has Legacy USB enabled. I have only a USB keyboard, no PS/2 port. Can you check BIOS settings for EHCI handover? If the BIOS does not have handover enabled, it may disable legacy support after a timeout, which is often bad. IMO this is the same with booting off USB drives but every BIOS handles that different. The keyboard works file in BIOS and for selecting boot device in boot0 menu. It also works in loader menu. If in the menu I select to go to loader prompt then it works for about 5 seconds and then dies - no reaction to key presses, no led change, nothing. I haven't actually verified if the keyboard would still work if I stayed in loader menu for longer than ~10 seconds. This doesn't happen if USB is built into kernel. That sound strange. I have no idea why that might work (or I'm totally wrong with my handover theory). Weird... Yes, sounds like or it's probably easily explainable ;) Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Western Digital hard disks and ATA timeouts
I can confirm that. Many FreeNAS users had problems with their HDDs (e.g. with APM, awake disks to access them after they felt to sleep). Increasing timeouts solves the problem in most cases. I think increasing the value BUT allowing the user to set it to a preferred value via sysctrl would be the best solution. I don't understand why adding such an sysctl interface is such an problem for some people. If someone wants to set any other value than the default one HE MUST KNOW what he do and live with the consequences. There are so many other kernel/system variables that can harm the system. Regards Volker http://dict.leo.org/ende?lp=endep=thMx..search=implications Peter Wemm wrote: On Thu, Nov 6, 2008 at 11:17 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote: [..] As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, and is not adjustable without editing the ATA code yourself and increasing the value. The FreeNAS folks have made patches available to turn the timeout value into a sysctl. Soren and/or others, please increase this timeout value. Five seconds has now been deemed too aggressive a default. And please consider migrating the timeout value into a sysctl. The 5 second timeout has been a problem for quite a while actually. I've had a number of instances where I've had to increase it to 20 or 30 seconds when recovering from marginal drives. The longest successful recovery attempt I've seen was 26 seconds, I believe on a Maxtor drive a few years ago. (successful == the drive spent 26 seconds but eventually successfully read the sector). Even the IBM death star drives could take much longer than 5 seconds to do a recovery 5 years ago. 5 seconds has never been a good default. I think the timeout should be increased to at least 30 seconds. My windows box has a timeout that goes for several minutes. If there is concern about FreeBSD appearing to hang, I could imagine that a console warning message could be printed after 5 seconds. But just say drive has not yet responded. But give it more time. In this day and age we're generally not playing games with udma33 vs 66, notched cables, poor CRC support etc. SATA seems to have eliminated all that. Hmm, it might make sense to increase the timeout on SATA connections to 2 or 3 minutes by default. Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.5/1764 - Release Date: 03.11.2008 07:46 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On 12/23/-58 20:59, Bruce Cran wrote: div class=moz-text-flowedI recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE. I rebooted it today but despite pf_enable=YES being in /etc/rc.conf no rules got loaded during boot, despite pf itself having been enabled: router# pfctl -s rules router# pfctl -e -f /etc/pf.conf pfctl: pf already enabled [connection is closed due to new rules being loaded] router# pfctl -s rules scrub in all fragment reassemble [... lots of rules listed] Has anyone else seen this problem, or have I just missed something that's changed between 7.0 and 7.1 in the way pf works? Hi Bruce, # pfctl -sr | wc -l 81 # grep pf /etc/rc.conf pf_enable=YES pf_rules=/etc/Firewall/pf-ces.conf pflog_enable=YES this is from a very recent 7-STABLE box: # uname -a FreeBSD cesar.sz.vwsoft.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #46: Tue Sep 30 23:33:36 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CESAR i386 Do you mind to show me your rules? What does ``pfctl -gnf /path/to/your/rules'' give? Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On 10/04/08 00:05, Bruce Cran wrote: On Fri, 3 Oct 2008 04:38:24 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: I've figured out what the problem is. This is not good, and is guaranteed to bite other people. I'd like to believe this is an rc-related problem, but I'm not sure how to fix it. The problem in my case: The physical interfaces were brought online, but were still technically offline (the switch and NIC PHY were taking some time to negotiate speed and duplex). Boot messages: My box is headless so I didn't see the startup messages until I attached a serial cable. It's a similar problem in my case, but caused because I'm firewalling an ADSL connection which uses PPP, and pf is being enabled before PPP has configured tun0: Setting hostname: router.draftnet. vr0: link state changed to DOWN dc0: link state changed to UP dc3: link state changed to UP lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet 127.0.0.1 netmask 0xff00 vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2808VLAN_MTU,WOL_UCAST,WOL_MAGIC ether 00:40:63:e3:d1:b7 inet6 XX%vr0 prefixlen 64 tentative scopeid 0x1 inet X netmask 0xff00 broadcast XX media: Ethernet autoselect (none) status: no carrier dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:80:c8:c9:96:6d inet6 X%dc0 prefixlen 64 tentative scopeid 0x2 inet X netmask 0xff00 broadcast X media: Ethernet autoselect (100baseTX full-duplex) status: active dc3: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:80:c8:c9:96:70 inet6 X%dc3 prefixlen 64 tentative scopeid 0x5 inet X netmask 0xff00 broadcast X media: Ethernet autoselect (100baseTX full-duplex) status: active Enabling pf. no IP address found for tun0 /etc/pf.conf:45: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded pf enabled Starting PPP profile: demonLoading /lib/libalias_cuseeme.so Loading /lib/libalias_ftp.so Loading /lib/libalias_irc.so Lodading /lib/libalcias_nbt.so Load1ing /lib/libalia:s_pptp.so Loadi ng /lib/libaliasl_skinny.so Loadiing /lib/libalians_smedia.so k. no IP address found for tun0 s /etc/pf.conf:45t: could not parsae host specificattion pfctl: Synetax error in con fig file: pf rulces not loaded ahdd net default: agateway tun0 Adnditional routingg options: IP gateeway=YES. dadd net :::0 .0.0.0: gateway t::1 add net ::0o.0.0.0: gateway ::1 net.inet6.iDp6.forwarding: 0O - 1 net.inet6W.ip6.accept_rtadNv: 0 - 0 dc2: link state changed to DOWN The messages following link state changed to DOWN indicate that all the interfaces are now properly configured with IP addresses, including the external ADSL tun0 and IPv6 gif0 interfaces. Bruce, looking into my crystal ball... ;) You seem to have a rule like: pass ... on tun0 from any to tun0 ... If you change that into: pass ... on tun0 from any to (tun0) ... pf will happily parse your rules and activate your firewall even while tun0 does not already have an IP address. You may also try to use rules naming an interface family instead of a single interface. Other than that suggestion, I may help you if you'll send me your rules (private mail is ok for me). Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf rules not being loaded during boot on 7.1-PRERELEASE
On 10/04/08 01:22, Bruce Cran wrote: On Sat, 04 Oct 2008 00:40:45 +0200 Volker [EMAIL PROTECTED] wrote: You seem to have a rule like: pass ... on tun0 from any to tun0 ... If you change that into: pass ... on tun0 from any to (tun0) ... pf will happily parse your rules and activate your firewall even while tun0 does not already have an IP address. You may also try to use rules naming an interface family instead of a single interface. You're right - I mostly used lines with (tun0) but line 45 didn't have the brackets. I've just added them, rebooted and pf loaded the rules during boot. Well, sometimes my crystal ball works ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR with pf + synproxy state
)
pass quick on {$if_lan $if_wlan} from any to 255.255.255.255
pass in log on {$if_lan $if_wlan} proto tcp \
from any to any port $tcp_in \
flags $TCPSYN synproxy state
# change to 'keep state' here to avoid LOR
pass in log on {$if_lan $if_wlan} proto tcp from any port $tcp_in \
to any flags $TCPSYN synproxy state
# change to 'keep state' here to avoid LOR
pass in log on {$if_lan $if_wlan} proto udp from any \
to any port $udp_in keep state
pass in log on {$if_lan $if_wlan} proto udp from any port $udp_in \
to any keep state
pass quick on {$if_lan $if_wlan} from any to multicast
# EOF
That LOR may be the same as reported here before (2007-12) - haven't
checked the old sources (will verify if it's worth the time to confirm):
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2007-12/msg00150.html
`uname -a`:
FreeBSD cesar.sz.vwsoft.com 7.0-STABLE FreeBSD 7.0-STABLE #38: Sun Aug
17 15:12:10 CEST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CESAR i386
Volker
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with /boot/loader
On 12/23/-58 20:59, Kelly Black wrote: Hello, I have a problem with loader. I recently upgraded from 6_rel to 7_rel. Now when I install world there is a problem booting. Here is what I do: cd /usr/src make buildworld make buildkernel KERNCONF=BLACK make installkernel KERNCONF=BLACK At this point I can reboot and all is good. After boot I install the new world: cd /usr/src mergemaster -p reboot into single user mode cd /usr/src make installworld mergemaster Now when I reboot there is a problem. I get an error that the system cannot boot. Part of it looks like this: Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: If I boot from a live disk and replace /boot/loader with /boot/loader.old it boots up fine and everything looks good. A new world and a new kernel. I would be grateful for any help or any pointers. Sincerely, Kel PS I do not do anything special with my loader config files: $ cat loader.conf ... Kelly, the /boot/loader.conf file does not come into play at that stage. Early in the loader code, loader needs to figure out, which disk (BIOS device) has been booted from. Until loader knows which device was booted up, it's unable to access any files (even loader.conf) on your boot device. As I've never seen such a problem while upgrading any system, I suspect your problem must be settings specific. Can you show me your kernel config or are you using a plain vanilla GENERIC? Which arch are we talking about? As I'm currently investigating another boot problem (but earlier in the boot chain), I'll check boot logic in the source code and may check for your issue, too, at that time, so it's just one effort. But please stay patient for some days, as I'm currently too busy. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror+gjournal: unable to boot after crash
root from ufs:/dev/mirror/gm0.journals1a does not look very promising. Have you really created a journaling geom provider and created bsd partitions in it? The 3rd boot loader lists directories. boot1/2 is accessing the device under BIOS control and does not know anything GEOM like, so as long as the boot device / boot-fs can be figured out and the on-disk filesystem structure is valid, it can list files. Any idea how this could be fixed via a remote serial line? Any chance to boot this without GEOM? If I got it right, you've done something really, really bad while organizing your disk / filesystem layout. If I'm not mistaken with that assumption, I don't see much hope to get the system up by a remote console only. At least, you may try to see if you're able to mount root from ufs:adXs1a (assuming root is at S/ATA disk 0, first slice) and get it at least into single user mode. You may also want to try to unload geom modules at the loader prompt. You should try to safe your valuable data, fix your disk partitioning as soon as you're able to get single user access again (again, if I'm not mistaken while assuming you've created partitions within the journaling provider). Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant reboot with FreeBSD 6.3 and 2GB RAM
Hello, i can confirm that the bug fix submitted with PR 108215 solves the reboot problem when using mfsroot images in FreeBSD 6.3. I will test it also on FreeBSD 7.0, but i assume that it will fix it there too. Many users using FreeNAS reporting this reboot problem on their machines with RAM 2GB. Regards Volker Original-Nachricht Datum: Wed, 21 May 2008 21:08:25 +0200 Von: Volker [EMAIL PROTECTED] An: [EMAIL PROTECTED] CC: freebsd-stable@freebsd.org, [EMAIL PROTECTED] Betreff: Re: Instant reboot with FreeBSD 6.3 and 2GB RAM On 12/23/-58 20:59, [EMAIL PROTECTED] wrote: Hello, some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to = 2GB. We are using the following kernel configuration which is based on GENERIC: http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291view=markup I found out another problem that causes a reboot on my 2GB machine. We are using a image for the LiveCD which is 64MB great. If i change back mfs_root size to 63MB all works well, but all above 64MB causes a reboot. Is there any limitation? Could someone help me out of this problem? Regards Volker Hi Volker ;) I'm not quite sure about your 2nd problem and your report is not quite detailed but from your description it looks like loader is causing that. As there's no filesystem available at that time, the loader has to read itself through the filesystem structures. Knowing that, PR misc/108215 comes to mind. I've not been able to check if the issue and the patch to it is right but you may give it a try. Probably somebody with loader and filesystem (ufs) knowledge may answer that question quickly if the patch contained in the PR is right. The report is about 6.2-R but at least I've checked loader code and 7.x code is the same. I came across that report yesterday and was unable to check the calculation. If that is really the case, your problem may be related to that. http://www.freebsd.org/cgi/query-pr.cgi?pr=108215 Assuming the problem report is right, it's about reading huge files by loader reads in wrong sectors. HTH Volker -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Instant reboot with FreeBSD 6.3 and 2GB RAM
On 12/23/-58 20:59, [EMAIL PROTECTED] wrote: Hello, some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to = 2GB. We are using the following kernel configuration which is based on GENERIC: http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291view=markup I found out another problem that causes a reboot on my 2GB machine. We are using a image for the LiveCD which is 64MB great. If i change back mfs_root size to 63MB all works well, but all above 64MB causes a reboot. Is there any limitation? Could someone help me out of this problem? Regards Volker Hi Volker ;) I'm not quite sure about your 2nd problem and your report is not quite detailed but from your description it looks like loader is causing that. As there's no filesystem available at that time, the loader has to read itself through the filesystem structures. Knowing that, PR misc/108215 comes to mind. I've not been able to check if the issue and the patch to it is right but you may give it a try. Probably somebody with loader and filesystem (ufs) knowledge may answer that question quickly if the patch contained in the PR is right. The report is about 6.2-R but at least I've checked loader code and 7.x code is the same. I came across that report yesterday and was unable to check the calculation. If that is really the case, your problem may be related to that. http://www.freebsd.org/cgi/query-pr.cgi?pr=108215 Assuming the problem report is right, it's about reading huge files by loader reads in wrong sectors. HTH Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: ATI SB600 Sata controler isn't detected as such.
On 12/23/-58 20:59, Andrey V. Elsukov wrote: 16.04.08, 19:28, Arnaud Houdelette [EMAIL PROTECTED]: Thanks for the info. The jumper may well be in place. Still it doesn't solve the main issue, that is the controler isn't properly recognised. ATI (ID=43801002) AHCI controller - it is ok. The generic AHCI was added some time ago. So if your controller is true AHCI it will be detected in this way. And now we don't need to add each new device id in the driver. Andrey, Arnaud, I'm using a HP 6715b laptop with the same chipset. Unfortunately there's no enable AHCI option in the BIOS setup and with earlier FreeBSD versions, the driver identified this chip as plain IDE. I needed to patch my kernel with a patch provided by Coleman Kane. With recent versions (new ATA code in 7-STABLE) I don't need that ata patch anymore and the kernel identifies this correctly as AHCI compliant out of the box but the hardware has another problem: ACPI reports a wrong address for the pcm device so it overlaps with memory resources of the sata chip. Using a patch also provided by Coleman, the resources of the pcm device are remapped to free the address space of the sata controller. I'm wondering if this is the same or similar problem with the MSI system? A `devinfo -rv' may show this. Anyway, these lines raises the suggestion to look out for a BIOS update: ACPI APIC Table: 090307 APIC1050 acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fff0, 10 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1df0 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: QA on textdumps (fwd)
On 04/03/08 16:22, Norberto Meijome wrote: On Wed, 02 Apr 2008 21:51:52 +0200 Volker [EMAIL PROTECTED] wrote: while the system is experiencing a panic, it does not have any knowledge about filesystems and also does not know about the GELI swap space anymore. In this situation the geli encrypted swap will be overwritten by a dump (either minidump or the classical one). When the system boots up again, it will check $dumpdev for a dump and save it to $savecore before geli swap is brought up again. Or in short: geli backed swap should not do you any harm. Hi Volker, That is what I had thought. But I clearly remember, back in 6.x the dump would be written to swap, then on restart, geli would kick in before savedump , therefore obliterating anything saved from the previous session. I will need to retest this...luckily 7-STABLE has been rock solid and haven't experienced many crashes. Hi Norberto, you may check the start order by using: `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*' On my 7-stable system, the interesting ones are in this order: dumpon geli encswap swap1 savecore ...ouch! ;) This does not look like the order it should be but I think (fortunately) in most situations this should be ok as nothing gets written to swap space before daemon processes are brought up. On the other side, savecore needs mounted filesystems to save the core to /var/crash. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: QA on textdumps (fwd)
On 12/23/-58 20:59, Norberto Meijome wrote: On Tue, 1 Apr 2008 12:57:06 +0100 (BST) Robert Watson [EMAIL PROTECTED] wrote: (7) I'm in DDB and I suddenly realize I want to save the output, and I haven't configured textdumps. What do I do? As with normal dumps, you must previously have configured support for a dump partition. These days, that is done automatically whenever you have swap configured on the box, so unless you're in single-user mode or don't have swap configured, you should be able to do the following: First of all, thanks Robert - I am definitely not capable to debug kernel crash, but the fact there are tools out there to make things easier is definitely welcome ! :) What happens if one encrypts the swap with GELI? Is this the same case as no swap defined ? I've found back in 6.x that dumps wouldn't work properly (I cant remember whether it would dump the data into the current encrypted disk, or geli would kick in before savedump on reboot) Since then I have a separate partition for the dumps defined in rc.conf and dumps work ok . Norberto, while the system is experiencing a panic, it does not have any knowledge about filesystems and also does not know about the GELI swap space anymore. In this situation the geli encrypted swap will be overwritten by a dump (either minidump or the classical one). When the system boots up again, it will check $dumpdev for a dump and save it to $savecore before geli swap is brought up again. Or in short: geli backed swap should not do you any harm. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7-STABLE not seeing second em interface on supermicro mb
On 12/23/-58 20:59, John Pettitt wrote: I just installed 7-STABLE on a new dual/quad machine based on a supermicro motherboard - it works fine except that it's not seeing the second network interface (em driver) - is there a magic incantation to make this work? FreeBSD echelon.localnet 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Mar 21 23:27:31 PDT 2008 [EMAIL PROTECTED]:/usr/src/sys/amd64/compile/ECHELON amd64 The only word from the em driver is this em0: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0x3000-0x301f mem 0xde20-0xde21 irq 17 at device 0.0 on pci5 em0: Using MSI interrupt em0: Ethernet address: 00:30:48:64:d9:45 em0: [FILTER] ifconfig doesn't show anything other than em0 and lo0 Where should I start debugging this ? John John, I'm not aware whether or not your question has been answered. If not, please send output of `pciconf -lv'. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
arp: unknown hardware address
Hi! This morning, I found this in the daily periodic mail from a RELENG_7 machine: +arp: unknown hardware address format (0x) +arp: unknown hardware address format (0x) +arp: unknown hardware address format (0x) +arp: unknown hardware address format (0x) +arp: unknown hardware address format (0x) I checked my yesterdays' logs and found: Feb 21 20:56:39 bellona dhcpd: DHCPREQUEST for 192.168.178.20 from 00:18:de:a4:b 8:6a via aue0: wrong network. Feb 21 20:56:39 bellona dhcpd: DHCPNAK on 192.168.178.20 to 00:18:de:a4:b8:6a vi a aue0 Feb 21 20:56:40 bellona kernel: arp: unknown hardware address format (0x) Feb 21 20:56:40 bellona kernel: Feb 21 20:56:40 bellona kernel: arp: unknown hardware address format (0x) Feb 21 20:56:42 bellona kernel: arp: unknown hardware address format (0x) Feb 21 20:56:47 bellona last message repeated 3 times Feb 21 20:56:51 bellona dhcpd: DHCPDISCOVER from 00:18:de:a4:b8:6a via aue0 Feb 21 20:56:51 bellona kernel: Feb 21 20:56:51 bellona dhcpd: icmp_echorequest 192.168.20.249: Operation not permitted Feb 21 20:56:52 bellona dhcpd: DHCPOFFER on 192.168.20.249 to 00:18:de:a4:b8:6a (lp4) via aue0 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: Sun Feb 17 19:13:08 CET 2008 The network the dhcp client was requesting (192.168.178.20) is not mine, dhcpd rejected that address and offered another one. But why does FreeBSD complain about the bad hardware address? Any explanations? Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
'vidcontrol -m on' is killing my machine
Hi! I'm using a new HP 6715b notebook. When trying to use this with a docking station (PA286), the machine keeps hanging at message starting default moused:. The machine then just has died (I even can't break into debugger using ctrl+alt+esc). On investigation I figured out, `vidcontrol -m on' (called by /etc/rc.d/moused) is causing that freeze. Using an USB mouse, the system dies immediately when plugging in the mouse (starting ums0 moused: appears). Everything is fine when the system is undocked or moused _completely_ disabled. Running with WITNESS enabled does not give anything. Would INVARIANTS give me something here? FreeBSD cesar.sz.vwsoft.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: Tue Jan 22 01:29:52 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CESAR i386 For now, I've commented out the vidcontrol call in /etc/rc.d/moused to work around that issue. Looking at the code in vidcontrol.c, I have no idea what might cause that as it's really simple code and basically just calling an IOCTL. The notebook has got an internal LCD with 1680x1050 and the docking station has a 1280x1024 display connected (what may get some code being confused?). What's going on there? Thx! Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: patch for review: ATI SB600 SATA AHCI
On 12/23/-58 20:59, Jakub Siroky wrote:
Hello,
I've been using these patches for some time with success. Although
slight correction to patches is needed - code placement changed a bit
(in case of line wrapping, see the attachments).
--- ata-chipset.c.orig Mon Oct 9 23:01:35 2006
+++ ata-chipset.c Wed Sep 5 22:08:02 2007
@@ -1239,12 +1239,16 @@
struct ata_pci_controller *ctlr = device_get_softc(dev);
struct ata_chip_id *idx;
static struct ata_chip_id ids[] =
-{{ ATA_ATI_IXP200,0x00, 0,0, ATA_UDMA5, IXP200 },
- { ATA_ATI_IXP300,0x00, 0,0, ATA_UDMA6, IXP300 },
- { ATA_ATI_IXP400,0x00, 0,0, ATA_UDMA6, IXP400 },
- { ATA_ATI_IXP300_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP300 },
- { ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 },
- { ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 },
+{{ ATA_ATI_IXP200,0x00, 0,0, ATA_UDMA5,
IXP200 },
+ { ATA_ATI_IXP300,0x00, 0,0, ATA_UDMA6,
IXP300 },
+ { ATA_ATI_IXP400,0x00, 0,0, ATA_UDMA6,
IXP400 },
+ { ATA_ATI_IXP600,0x00, 0,ATISINGLE, ATA_UDMA6,
IXP600 },
+ { ATA_ATI_IXP700,0x00, 0,ATISINGLE, ATA_UDMA6,
IXP700 },
+ { ATA_ATI_IXP300_S1, 0x00, SIIMEMIO, 0, ATA_SA150,
IXP300 },
+ { ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150,
IXP400 },
+ { ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150,
IXP400 },
+ { ATA_ATI_IXP600_S1, 0x00, 0,AHCI, ATA_SA300,
IXP600 },
+ { ATA_ATI_IXP700_S1, 0x00, 0,AHCI, ATA_SA300,
IXP700 }, { 0, 0, 0, 0, 0, 0}};
char buffer[64];
@@ -1271,6 +1275,18 @@
if (ata_setup_interrupt(dev))
return ENXIO;
+
+if (ctlr-chip-cfg2 AHCI) {
+ ctlr-r_rid2 = PCIR_BAR(5);
+ ctlr-r_type2 = SYS_RES_MEMORY;
+ if ((ctlr-r_res2 = bus_alloc_resource_any(dev, ctlr-r_type2,
+ ctlr-r_rid2,
+ RF_ACTIVE)))
+ return ata_ahci_chipinit(dev);
+}
+
+if (ctlr-chip-cfg2 ATISINGLE)
+ ctlr-channels = 1;
ctlr-setmode = ata_ati_setmode;
return 0;
-- ata-pci.h.orig Sat Sep 30 21:51:49 2006
+++ ata-pci.h Wed Sep 5 22:00:21 2007
@@ -102,6 +102,10 @@
#define ATA_ATI_IXP300_S1 0x436e1002
#define ATA_ATI_IXP400_S1 0x43791002
#define ATA_ATI_IXP400_S2 0x437a1002
+#define ATA_ATI_IXP600_S1 0x43801002
+#define ATA_ATI_IXP600 0x438c1002
+#define ATA_ATI_IXP700_S1 0x43901002
+#define ATA_ATI_IXP700 0x439c1002
#define ATA_CENATEK_ID 0x16ca
#define ATA_CENATEK_ROCKET 0x000116ca
@@ -415,6 +419,7 @@
#define VIABUG 0x0200
#define VIABAR 0x0400
#define VIAAHCI 0x0800
+#define ATISINGLE 0x1000
Jakub,
I think your patch is against old code before the ATA code has been
restructured. I've tried a similar patch (provided by Coleman Kane)
against recent RELENG_7 but applying the patch failed.
That has been the reason for me to write a new patch (at least for the
chipset my notebook is using, as I don't know much about other
chipsets). I've just been unsure whether or not calling ata_ahci_init
is everything what is required for proper chip initialization or not
but from what I was reading out of the current code, other functions
don't do much more.
I may include other chipset changes (from your patch) and send a new
patch if my patch does not miss anything for proper operation. At
least the codes changes work here for me (or I haven't noticed
anything bad). @sos: can you comment on this?
Volker
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
patch for review: ATI SB600 SATA AHCI
Hi!
I've done the following local changes to get the ATA controller being
correctly detected and initialized as an AHCI controller on an HP
6715b notebook using ATI SB-600 chipset. With stock kernel, the ATA
controller is being recognized as a generic ATA controller and devices
being driven in UDMA-33 mode.
With the following patch, the controller is being initialized in AHCI
mode and devices being set to SATA-150/300 mode.
atapci0: ATI IXP600 SATA300 controller port
0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f
mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0
atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x5020
atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xd0609000
atapci0: [MPSAFE]
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 ports detected
%atacontrol mode ad4
current mode = SATA150
My patch has been tested on RELENG_7 as of 2008-01-19. Please review,
check and test if possible. Should work on 8-CURRENT, too.
If nobody complains until tuesday (2008-01-22), I'll file a PR for
that patch.
Volker
--- sys/dev/ata/ata-chipset.c.orig 2008-01-20 03:22:37.0
+0100
+++ sys/dev/ata/ata-chipset.c 2008-01-20 03:30:03.0 +0100
@@ -1348,6 +1348,7 @@
{ ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 },
{ ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 },
{ ATA_ATI_IXP600,0x00, 0,0, ATA_UDMA6, IXP600 },
+ { ATA_ATI_IXP600_S1, 0x00, 0, AHCI, ATA_SA300, IXP600 },
{ ATA_ATI_IXP700,0x00, 0,0, ATA_UDMA6, IXP700 },
{ 0, 0, 0, 0, 0, 0}};
@@ -1360,7 +1361,10 @@
if (ctlr-chip-cfg1 SIIMEMIO)
ctlr-chipinit = ata_sii_chipinit;
else
- ctlr-chipinit = ata_ati_chipinit;
+ if (ctlr-chip-cfg2 AHCI)
+ ctlr-chipinit = ata_ahci_chipinit;
+ else
+ ctlr-chipinit = ata_ati_chipinit;
return 0;
}
--- sys/dev/ata/ata-pci.h.orig 2008-01-20 03:22:28.0 +0100
+++ sys/dev/ata/ata-pci.h 2008-01-20 03:23:56.0 +0100
@@ -104,6 +104,7 @@
#define ATA_ATI_IXP400_S1 0x43791002
#define ATA_ATI_IXP400_S2 0x437a1002
#define ATA_ATI_IXP600 0x438c1002
+#define ATA_ATI_IXP600_S1 0x43801002
#define ATA_ATI_IXP700 0x439c1002
#define ATA_CENATEK_ID 0x16ca
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Fix for GPE livelock on HPs
On 12/23/-58 20:59, Nate Lawson wrote: Nate Lawson wrote: Volker wrote: On 12/23/-58 20:59, Nate Lawson wrote: I've committed the below patch and want to MFC it to 7.0. To do this, I need people to test this quickly. It probably has no effect in 6.x and probably doesn't apply cleanly there. Please try this patch if you have a laptop and 7.x. If you have -current, just cvsup. I'd like to make sure there is no regression. I'm already aware that it fixes things for some HP users. Nate, can you be a bit specific for a) what GPE is, b) what the problem is, c) what to look for (any test procedures?) and d) which HP laptop models might be affected? I do have an Omnibook vt6200 (P-IV 1.8G) running 6-STABLE and a new HP 6715b (Tur-X2 TL-60) running 7-RC1 (currently installing on this, OS is not yet fully set up). If I knew what to look for, I might test your patches (at least on the 7-RC1 version). A GPE is an interrupt of sorts. I'm looking for any bad behavior the patch might cause. I'm certain it fixes lockups some HPs had during thermal zone events (i.e. fan switching on when it gets hot). Pretty much anyone with a laptop that locks up and you suspect acpi should test it. And anyone who is willing to test it on another brand laptop to be sure the patch doesn't break anything more would be welcome. You should be able to do sysctl hw.acpi and see the temperature and apm to see battery status without any new problems after applying the patch. I've added a patch for 6-stable also (attached). Please test if you have a laptop and 6.x. See -current for the 7.x patch if that's relevant to you. -Nate Nate, I'm sorry, your patch applies cleanly but does not compile on 6-STABLE (csup'ed today, applied patch defer_gpe_6x.diff posted on 2008-01-15). === acpi/acpi (all) cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -DHAVE_KERNEL_OPTIO N_HEADERS -include /usr/obj/usr/src/sys/CESAR/opt_global.h -I. -I@ -I@/contrib/a ltq -I@/../include -finline-limit=8000 -fno-common -g -I/usr/obj/usr/src/sys/CES AR -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mn o-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict -prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat -extensions -std=c99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uniniti alized -c /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c: In function `AcpiEvAsynchExecuteGpeMethod': /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: warning: implicit declaration of function `AcpiOsExecute' /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: warning: nested extern declaration of `AcpiOsExecute' /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: error: ` OSL_NOTIFY_HANDLER' undeclared (first use in this function) /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: error: ( Each undeclared identifier is reported only once /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/evgpe.c:664: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/modules/acpi/acpi. BTW, reading the source code changes and your commit comments, I'm pretty sure I've seen those ACPI related problems on my HP Omnibook vt6200 using 6-STABLE. Sometimes the tz0 temperature values have been nailed to a fixed value, sometimes the system went too hot (with or without the fan running), sometimes it was just freezing and no way out to revitalize the notebook. I haven't reported this before because something like my system freezes w/o message or the system does stupid things but I don't have an error message is most likely not the kind of report to get a useful reply for. If you've got another patch for a 6-STABLE target, I'll be happy to test. Thanks! Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wpa_supplicant features and compile options
On 12/23/-58 20:59, Greg Rivers wrote: div class=moz-text-flowedI connect to certain wireless networks that require the EAP_GTC and EAP_OTP features in wpa_supplicant. These features are not compiled into wpa_supplicant by default. Using the patch below works great, but it's inconvenient having to remember to apply it after every cvsup. Is there a better way to accomplish this? If not, might a change such as this be committed to enable GTC and OTP by default? Greg, I'm unable to comment on including your patch into cvs, but for own patches like your's, I'm using a script which does 1) csup and 2) integrate a bunch of patches into /usr/src. HTH Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
some LORs + non-sleepable locks on recent stable i386 causing freezes
,c671c300,c657b000,c6567000,...) at in_control+0x95e ifioctl(c685d6f4,8040691a,c671c300,c6567000,2,...) at ifioctl+0x1bc soo_ioctl(c675dbd0,8040691a,c671c300,c63aad80,c6567000,...) at soo_ioctl+0x3ef ioctl(c6567000,eed2cd04,c,c07e3c99,3,...) at ioctl+0x44d syscall(3b,3b,3b,80595c0,0,...) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281681c3, esp = 0xbfbfe9ac, ebp = 0xbfbfe9d8 --- %uname -v FreeBSD 6.2-STABLE #1: Sun Aug 26 01:36:20 CEST 2007 Kernel sources sync'ed and compiled yesterday. One of these three (or all together) is causing machine freezes when running w/o witness. The problem has been introduced sometime within the last 6-8 weeks (never had freezes before on that machine running 6-STABLE). Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: default dns config change causing major poolpah
On 12/23/-58 20:59, Doug Barton wrote: Jo Rhett wrote: On Wed, Aug 01, 2007 at 01:32:42PM -0700, Doug Barton wrote: This is about on par with unnamed network equipment manufacturer selling SOHO routers that synchronize their clocks using stratum-1 NTP servers. I don't really think that analogy holds up, given that those who run public stratum-1 NTP servers specifically request that individual hosts not sync from them. The analogy is more true than you believe. Someone told you on this very same list that it was not allowed, If you're talking about Volker I have already explained at great length why he was flat out wrong on just about every particular. Anyone interested can read the archives around 7/17. Well, my fault was to post to the mailing list before checking what has been changed in cvs and this caused me to post about an assumption instead of information and checked cvs later. On the other hand, your postings sounded more likely to be flames as you did not really said something about the issue itself but picked on some bad formulation from a non-native english speaker. But as I wrote you already in private mail, I don't like to discuss further and this is my last word on that topic. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
On 07/31/07 17:25, Tijl Coosemans wrote: On Friday 13 July 2007 20:08:59 Volker wrote: On 07/11/07 20:42, John Baldwin wrote: This patch attempts to remove a gross hack with a slightly less gross hack in order to avoid clobbering data in signal info that Wine needs. In 7 this was fixed by a major change to how the kernel manages signals internally, and that change is too large to be MFC'd, hence this lighter weight patch. It has already been tested by the folks working on Wine, but I would like a bit more widespread testing before I commit it. Please test this patch and let me know if anything breaks. Note that this patch is only for i386. http://www.FreeBSD.org/~jhb/patches/sig_eva.patch I've patched and recompiled world + kernel using your patch. I can confirm it does not hurt but what does it good (my wine already ran fine despite some DDE and performance issues)? What to look for especially - any specific test procedures? Could you try Mozilla Firefox (for Windows) with and without this patch? Tijl, sorry for delay. It took some hours to cleanly build new world + kernel w/o patches, test and patch and rebuild everything. Here are the results: clean world + kernel (unpatched), csup'ed 2007-07-31, ports-tree up to date, installed wine: wine-0.9.42,1 - trying to start an already installed Win32 Firefox (installed under W2k, contained on a mounted NTFS volume): %wine /media/CesNt2/Program\ Files/Comm/Firefox/firefox.exe fixme:actctx:parse_depend_manifests Could not find dependent assembly LMicrosoft.Windows.Common-Controls err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems wine: Unhandled page fault on read access to 0x00a1 at address 0x9ccdc232 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00a1 in 32-bit code (0x9ccdc232). file_set_error: Bad address file_set_error: Bad address Register dump: CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b EIP:9ccdc232 ESP:0034ea78 EBP:0034ea78 EFLAGS:00010202( - 00 - -RI1) EAX:9cc80490 EBX:9cc7fe48 ECX:0009 EDX:9cc7f544 ESI:0064 EDI:7bf1b800 Stack dump: 0x0034ea78: 0034f0c8 9cc40cc3 0009 9cc80490 0x0034ea88: 9cc80494 0064 0d790266 9bf2d300 0x0034ea98: 0001 7bf05840 0034e6a0 7bf38240 0x0034eaa8: 0400 00020048 0034e6a0 0400 0x0034eab8: 9c13a4f0 0034ebe4 0x0034eac8: 9bf087a7 9c12a18c 0034ebb8 0001 0200: sel=1007 base=00112000 limit=1fff 32-bit rw- Backtrace: =1 0x9ccdc232 (0x0034ea78) 2 0x9cc40cc3 (0x0034f0c8) 3 0x9cc5a93f (0x0034f278) 4 0x9cc691de (0x0034f2a8) 5 0x9c195f09 (0x0034f2c8) 6 0x9c197e32 (0x0034f348) 7 0x9c198051 (0x0034f378) 8 0x9c19a0cb (0x0034f398) 9 0x9c26d0d0 in kernel32 (+0x3d0d0) (0x0034f5f8) 10 0x9c26d305 in kernel32 (+0x3d305) (0x0034f618) 11 0x9c26d3d3 in kernel32 (+0x3d3d3) (0x0034f638) 12 0x9c26d3ff in kernel32 (+0x3d3ff) (0x0034f658) 13 0x9c59b308 (0x0034f7d8) 14 0x9c595b6e (0x0034fa78) 15 0x9c48c736 (0x0034fb18) 16 0x9c48cdde (0x0034fb78) 17 0x9c48ee44 (0x0034fc08) 18 0x9c48f4a0 (0x0034fca8) 19 0x9c48f64f (0x0034fce8) 20 0x9c48587e (0x0034fd18) 21 0x9c4858c8 (0x0034fd28) 22 0x9c4e6890 (0x0034fda8) 23 0x9c4f751a (0x0034fdd8) 24 0x9c195f09 (0x0034fdf8) 25 0x9c197e32 (0x0034fe78) 26 0x9c198051 (0x0034fea8) 27 0x9c1980d4 (0x0034fec8) 28 0x9c1980d4 (0x0034fee8) 29 0x9c1980d4 (0x0034ff08) 30 0x9c1980d4 (0x0034ff28) 31 0x9c19a36a (0x0034ff68) 32 0x9c277dcf in kernel32 (+0x47dcf) (0x0034ffe8) 0x9ccdc232: movl0x98(%ecx),%edx Modules: Module Address Debug info Name (27 modules) PE40- b5f000 Deferredfirefox PE 600d-60141000 Deferredjs3250 PE 601a-601c7000 Deferrednspr4 PE 601d-6022b000 Deferrednss3 PE 6028-60287000 Deferredplc4 PE 6029-60296000 Deferredplds4 PE 602b-602ca000 Deferredsmime3 PE 602d-6030f000 Deferredsoftokn3 PE 6031-6033 Deferredssl3 PE 6034-60354000 Deferredxpcom_compat PE 6036-603ca000 Deferredxpcom_core PE 9c17-9c174000 Deferredntdll PE 9c23-9c29c000 Export kernel32 PE 9c33-9c334000 Deferredadvapi32 PE 9c37-9c374000 Deferredwsock32 PE 9c39-9c394000 Deferredws2_32 PE 9c3d-9c418000 Deferredwinmm PE 9c46-9c471000 Deferreduser32 PE 9c58-9c584000 Deferredgdi32 PE 9c66-9c6c9000 Deferredshell32 PE 9c7a-9c824000 Deferredcomctl32 PE 9c84-9c902000 Deferredole32 PE 9c8d-9c923000 Deferredrpcrt4 PE 9c8d-9c923000 Deferredrpcrt4 PE
Re: Problems with named default configuration in 6-STABLE
On 07/17/07 09:20, Michael Nottebrock wrote:
On Tuesday, 17. July 2007, Yuri Pankov wrote:
On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote:
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me a
new named.conf, which I modified to run named as a local resolver, like I
had before:
listen-on { 127.0.0.1; };
listen-on-v6{ ::1; };
forward only;
forwarders {
192.168.8.1;
};
Everything else is default. However, with this default configuration,
named will not resolve any hosts of my local domain (my.domain), which
uses addresses in the 192.168.8 subnet. My dns server on 192.168.8.1,
running 6.2-RELEASE, has a very simple dynamic dns setup: a zone
my.domain and a reverse zone 8.168.192.in-addr.arpa which are both
dynamically updated by dhcpd.
To make this work again, I had to delete everything in the default
named.conf from /* Slaving the following zones from the root [...]
to zone ip6.int { type master;
file master/empty.db; };.
I'm a DNS n00b, but I suspect that such drastic measures shouldn't be
required and somehow my setup is flawed. What can I do to make this work
right?
Cheers,
--
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Hi Michael,
If I understood you correctly, you can't resolve 8.168.192.in-addr.arpa
anymore, and the line below (from default named.conf) is the cause:
zone 168.192.in-addr.arpa { type master; file master/empty.db; };
Yes - and this:
zone . {
type slave;
The root zone MUST be of type hint. You do not want to be a slave of
the root... don't you? ;)
file slave/root.slave;
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
192.228.79.201; // B.ROOT-SERVERS.NET.
192.33.4.12;// C.ROOT-SERVERS.NET.
192.112.36.4; // G.ROOT-SERVERS.NET.
193.0.14.129; // K.ROOT-SERVERS.NET.
};
notify no;
};
prevents me from resolving hostnames in my.domain. What I'm still wondering
though, is this an oversight or by design? I can't imagine setups like mine
are very rare. Doug?
Yes, if the servers of the root zone can't be resolved, all queries
will fail.
If you've got a file /etc/namedb/named.root set it like
file /etc/namedb/named.root;
and change the zone type to hint and all should be well again.
Volker
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with named default configuration in 6-STABLE
On 07/17/07 09:45, Heiko Wundram (Beenic) wrote: On Tuesday 17 July 2007 09:39:59 Volker wrote: The root zone MUST be of type hint. You do not want to be a slave of the root... don't you? ;) Actually, I also thought that this is strange, but in a way, this is pretty sensible, as the only thing you cache (more immediately than by making it a hint zone) being a slave for the root is the name servers used for the different first-level zones, and the root servers allow AXFR requests (which I just verified), so this shouldn't fail. hmm... the root servers should not allow public AXFR. As I've verified using: dig @a.root-servers.net axfr . ; DiG 9.3.4 @a.root-servers.net axfr . ; (1 server found) ;; global options: printcmd ; Transfer failed. it still doesn't. How have you checked? Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with named default configuration in 6-STABLE
On 07/17/07 10:05, Heiko Wundram (Beenic) wrote: On Tuesday 17 July 2007 10:00:43 Volker wrote: hmm... the root servers should not allow public AXFR. As I've verified using: snip Just like you did: [EMAIL PROTECTED] ~]$ dig -t AXFR @k.root-servers.net . | head -30 ; DiG 9.3.4 -t AXFR @k.root-servers.net . ; (1 server found) ;; global options: printcmd . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2007071601 1800 900 604800 86400 . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net. ac. 172800 IN NS a.nic.ac. ac. 172800 IN NS a.ns13.net. ac. 172800 IN NS b.nic.ac. ac. 172800 IN NS b.nic.io. ac. 172800 IN NS b.nic.sh. ac. 172800 IN NS b.ns13.net. ac. 172800 IN NS ns1.communitydns.net. ac. 172800 IN NS ns3.icb.co.uk. a.nic.ac. 172800 IN A 64.251.31.177 b.nic.ac. 172800 IN A 217.160.203.158 ad. 172800 IN NS ad.ns.nic.es. ad. 172800 IN NS ns3.nic.fr. [EMAIL PROTECTED] ~]$ The head is necessary, as the output is far, far longer than that. As k.root-servers.net was one of the servers he put in as masters for the root zone, I should presume that his setup works fine. Not every root server seems to be happy with transfering zone files: %dig @a.root-servers.net axfr . | head ; DiG 9.3.3 @a.root-servers.net axfr . ; (1 server found) ;; global options: printcmd ; Transfer failed. %dig @b.root-servers.net axfr . | head ; DiG 9.3.3 @b.root-servers.net axfr . ; (1 server found) ;; global options: printcmd . 86400 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2007071601 1800 900 604800 86400 . 518400 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 . 518400 IN NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 360 IN A 192.228.79.201 . 518400 IN NS C.ROOT-SERVERS.NET. b.root-servers.net transfers the zone, but a.root-servers.net refuses. I remember some years back there has been an attack against some root servers and the conclusion was to deny zone transfers for them. I thought all root servers are denying zone transfers generally but some seem to still (or again) let it pass. The following servers are refusing zone transfers: a d e h i j l m Relying on a zone transfer doesn't seem to be reliable to me as more than half of the root servers doesn't reply to AXFR requests. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with named default configuration in 6-STABLE
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote: On Tuesday 17 July 2007 10:52:43 Volker wrote: snip Relying on a zone transfer doesn't seem to be reliable to me as more than half of the root servers doesn't reply to AXFR requests. I've heard pretty much the same thing as you did wrt. root name servers denying AXFR, but as it works (TM), I don't see a reason not to use it. And it seems that the author of the FreeBSD default named.conf thought likewise, which is pretty okay with me (from the experience I gathered this morning). By the way: using the roots as hints only adds to the number of requests your server has to do in order to retrieve first-level domain name servers, so in the end, the transmitted data should be way higher than doing one AXFR to find them (simply because you'll see a large subset of those toplevel domains being requested when you're publically offering a DNS server). And the data is also cached on an AXFR in persistant storage, which is another major benefit (for me). Remember, AXFR requires a TCP transfer and not every firewall will happily let it pass. I (partially) agree to the speedup effects you mentioned but if just 5 out of 13 root servers support AXFR, your bind will sit for a while to find a root server responding to it's AXFR requests. That may eat up your speed improvements. Type hint for the root zone always works (regardless of the firewall and which root server is being queried). Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD violates RFC2870 [was: Re: Problems with named default configuration in 6-STABLE]
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote: On Tuesday 17 July 2007 10:52:43 Volker wrote: snip Relying on a zone transfer doesn't seem to be reliable to me as more than half of the root servers doesn't reply to AXFR requests. I've heard pretty much the same thing as you did wrt. root name servers denying AXFR, but as it works (TM), I don't see a reason not to use it. And it seems that the author of the FreeBSD default named.conf thought likewise, which is pretty okay with me (from the experience I gathered this morning). I've googled a bit. RFC 2870 says: 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. This restriction is intended to, among other things, prevent unnecessary load on the root servers as advice has been heard such as To avoid having a corruptible cache, make your server a stealth secondary for the root zone. The root servers MAY put the root zone up for ftp or other access on one or more less critical servers. It's amusing, root servers B, C, F, G and K are operated by ignoring (read: violating) RFC2870 explicit requirements. Still want to be a slave of root servers while knowing it violates RFC2870 or at least uses a mechanism of root servers violating RFC2870? I've checked cvs for named.conf and yes, by default FreeBSD now will be a slave of the root zone by default. Which in fact means, FreeBSD uses something which is a violation of RFC2870 which is not guaranteed to work. Should it be that way? If an (experienced) admin is aware of the consequences of relying on an RFC violation, it's ok for the admin personally. But is it ok for the bunch of DNS noobs to rely on a thing which is not guaranteed to work? If, one day, this will not work anymore (as root servers refuse to AXFR), you will loose 100% connectivity and the noob will never know why he can't reach a single host on the internet. As I think having a default to hint root zone is better, I'll file a PR about that. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD violates RFC2870 [was: Re: Problems with named default configuration in 6-STABLE]
On 07/17/07 13:45, Jeremy Chadwick wrote: On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote: As I think having a default to hint root zone is better, I'll file a PR about that. Which leads me to ask: Why hasn't anyone recommended using stub zones for this? It seems the goal is to cache NS records from the rootservers, and stub zones don't utilise AXFR/IXFR. Jeremy, good point. According to Bind9 ARM: A stub zone is similar to a slave zone, except that it replicates only the NS records of a master zone instead of the entire zone. Stub zones are not a standard part of the DNS; they are a feature specific to the BIND implementation. Stub zones can be used to eliminate the need for glue NS record in a parent zone at the expense of maintaining a stub zone entry and a set of name server addresses in named.conf. This usage is not recommended for new configurations, and BIND 9 supports it only in a limited way. In BIND 4/8, zone transfers of a parent zone included the NS records from stub children of that zone. This meant that, in some cases, users could get away with configuring child stubs only in the master server for the parent zone. BIND 9 never mixes together zone data from different zones in this way. Therefore, if a BIND 9 master serving a parent zone has child stub zones configured, all the slave servers for the parent zone also need to have the same child stub zones configured. Stub zones can also be used as a way of forcing the resolution of a given domain to use a particular set of authoritative servers. For example, the caching name servers on a private network using RFC1918 addressing may be configured with stub zones for 10.in-addr.arpa to use a set of internal name servers as the authoritative servers for that domain. Using the root zone as type stub should work (even while ARM says it's not DNS standard). But ARM says, it's not recommended for new configurations (I have no idea why it does state that). On the other side, the old (outfashioned?) way of caching the root zone NS records worked for years and will continue to work. To get a fresh zone NS record copy is easy by using 'dig @a.root-servers.net NS . /etc/namedb/named.root` and you're done. If anything is in /etc/namedb/named.conf, it needs to be edited manually (or overwritten by mergemaster). The possibilities for the root zone are: 1) make root zone of type hint, cache root NS records in /etc/namedb/named.root (the way it was for years and is reliable) 2) make root a slave zone and rely only on 5 root DNS servers (named.conf modification required if root zone changes) - be aware of the RFC2870 regulations 3) make root zone a stub zone and configure all 13 root servers in named.conf - be aware of Bind9 ARM warnings Currently all three ways will work. It's not the question what works or not. To me the question is, what should be the (reliable) default configuration even for the inexperienced user? An experienced admin will ever be able to solve anything DNS related and find a way if things won't work and is free to change to a configuration serving him best. The default configuration should always and ever just work. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with named default configuration in 6-STABLE
Doug, On 07/17/07 18:14, Doug Barton wrote: Volker, I'm sorry to say that you've provided a great deal of incorrect information in this thread. sorry? really? I couldn't find one! Volker wrote: Remember, AXFR requires a TCP transfer and not every firewall will happily let it pass. This is true, although since to the firewall an AXFR looks just like any other stateful TCP connection out to the wide world, it's actually more likely (percentage wise) that this will succeed than it is that the DNS requests (using UDP) will. Obviously, for those that cannot transfer the zone, the hints mechanism is still in the comments. I've seen setups (not mine but I also tend to suppress 53/tcp) to deny 53/tcp traffic. To see this as a common or uncommon setup is more likely a philosophical discussion. I (partially) agree to the speedup effects you mentioned I think you should read the paper that David posted, http://www.imconf.net/imc-2004/papers/p15-malone.pdf before you comment further. I never said, using hint or slave will have no impact on speed. Where did I write that? Read: I agree to the speedup effects. It's also worth nothing that even if the only benefits were greater reliability vs. a root DDoS attack (which is sadly no longer a theoretical issue) and the substantial improvements to local NXDOMAIN answers, it would be worth it. Add the benefits of at worst a wash with overall root traffic for the root zone, and the extra benefits of also having local copies of ARPA and IN-ADDR.ARPA (which are much smaller, and usually more frequently queried than the root zone) and it's a clear win. Ok, a DDoS attack against the root servers has happend a few times in the past but there has been no single moment in time when not a single root server could be reached. So yes, a DDoS attack is possible, slaving the root zone will make you still being able to resolve DNS addresses but this is a theoretic scenario to have none of 13 root DNS servers worldwide being unreachable. I should add for the sake of completeness that not every DNS professional has reached the same conclusions I have Sorry, but this reads as nobody else has reached my wisdom. And it's comments like these which will get me away from using FreeBSD sometime in the future (while FreeBSD still being a great OS). , however the main objection that is usually raised is not operational from the root server operators, rather it's that DNS admins who are not paying attention might miss a change that would prevent their local resolver from slaving the zone at some time in the future. Given that the IP addresses of the root servers hardly ever change, and given that we have 5 servers to choose from (and we only need one good transfer to make it work), and given that I (and as this thread points out, others) actually do pay attention, I don't think this is going to be a problem for us. The point is, when relying on something which is not guaranteed to work (SHOULD NOT reply to zone transfer requests - RFC2870, 2.7) and you're using this in a default OS configuration, you'll have trouble *if* the remaining 5 root DNS servers refuse to answer zone transfer requests. Even if one after another is changed to refuse, you'll most likely notice after the last remaining root server will refuse to answer. In that situation, the average user will not be able to reach the internet at all as his DNS resolver will not work anymore. We're not talking (at least I'm not) about the experienced admin. _I_ am talking about the average user which does not know a single bit about DNS. Just for the case, the remaining 5 root DNS server refuse to AXFR: You want him (the average user) to figure out himself what's wrong with DNS if he can't reach the internet? but if just 5 out of 13 root servers support AXFR, your bind will sit for a while to find a root server responding to it's AXFR requests. I'm sorry, but that comment means that either you haven't read the new named.conf, or you don't understand what you've read. Either way, you should seriously consider whether or not it's a good idea for you to continue offering DNS advice. The following: You're wrong. I've read named.conf and understood. In it, there're only 5 (of the total 13) root DNS servers configured as the root zone's master servers. Where have I been wrong? What did I don't understand? There are a total of 13 root DNS servers (not phyisical hosts) worldwide. You have configured these 5, which still respond to AXFR requests. Yes, a single root server serving AXFR requests is enough to get the job done, but fact is, you're relying on only 5 out of 13 servers. Again, where have I been wrong? I know you've got the wisdom... :( BTW, so far we've only talked about the savings for an individual resolver. If you are responsible for a network of resolvers you can slave the zones from the roots on one server then slave them out to your network from your local master
Re: Call for testing: patch that helps Wine on 6.x
On 07/11/07 20:42, John Baldwin wrote: This patch attempts to remove a gross hack with a slightly less gross hack in order to avoid clobbering data in signal info that Wine needs. In 7 this was fixed by a major change to how the kernel manages signals internally, and that change is too large to be MFC'd, hence this lighter weight patch. It has already been tested by the folks working on Wine, but I would like a bit more widespread testing before I commit it. Please test this patch and let me know if anything breaks. Note that this patch is only for i386. http://www.FreeBSD.org/~jhb/patches/sig_eva.patch John, I've patched and recompiled world + kernel using your patch. I can confirm it does not hurt but what does it good (my wine already ran fine despite some DDE and performance issues)? What to look for especially - any specific test procedures? Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DDoS in FreeBSD 6.2-STABLE And Problen With The Clock
On 06/11/07 17:30, ExTaZyTi wrote: There are some problems, first DDoS (hardware DDoS) in the system. 'hardware DDoS'... funny thing! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
release cycle
Hi! Reading some of the latest blog entries today, I've seen there has been some (newbie) user frustration with the latest X.org upgrade (mostly by not reading docs or not understanding the ports system at all). flz@ and des@ had a lot of trouble with some guys. Currently, if a new user is trying out FreeBSD, he will most likely set up a 6.2-RELEASE system and end up in the X.org upgrade war. As a new user is most likely not prepared to manage the system at all, he will most likely probe FreeBSD being unmaintainable (as he will most likely not know how to deal with ports at all). While reading about all that latest trouble, I think it might not be a bad idea to have a (quick) release cycle and release something like 6.2.1-RELEASE (6.3 is still TBA). I'm considering the latest X.org upgrade being a major upgrade which would justify a release cycle (@ flz: you did a great job). That would keep the trouble from new users and also from some mailing lists. I know there's a release cycle for 7-CURRENT planned next June but IMHO it can be delayed for some weeks. What does the core and releng team think? It might do good. Just my 2ct. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
On 05/29/07 17:26, Bruce A. Mah wrote: And that's just the src/ part. The original poster was mostly concerned about the X.org upgrade, which as we all know lives in the ports/ tree. If we were to do a point release we'd basically require a complete port freeze and package build run. I believe that we did do that for both 4.6.2-RELEASE and 5.2.1-RELEASE. As someone's pointed out, the ports committers are still fixing up some of the rough edges around the X.org update, so that part of the tree isn't even ready to go yet. The way I see it (and this is just my personal opinion, not an official statement from re@), doing a point release now would be a distraction from our next scheduled release, which is 7.0. Bruce, is there any ETA for 7-STABLE? Thx Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ghosthunting: machine freeze 6.2R
On 05/25/07 11:07, Volker wrote: ... I'm using the following additional kernel options: makeoptions DEBUG=-g options KDB options KDB_UNATTENDED options KDB_TRACE options DDB options WITNESS options WITNESS_SKIPSPIN options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC options PANIC_REBOOT_WAIT_TIME=60 Suggestions on these options? Anything more to enable with massive performace loss? sorry! should (of course) read '*without* massive performance loss' smime.p7s Description: S/MIME Cryptographic Signature
Re: ghosthunting: machine freeze 6.2R
Kris, Roger all, On 05/23/07 23:58, Kris Kennaway wrote: On Wed, May 23, 2007 at 11:31:32PM +0100, Volker wrote: talking to myself... ;) On 2007-05-23 10:27, Volker wrote: Unfortunately three hours later, the machine died completely. It has been a hardware failure which came quietly. Sorry for the noise I've put on this list but when experiencing things like that, one has to think in all possible directions (I first thought about a DoS attack). Even though it turned out to be a hardware failure, it was helpful to publicize this fact. It is often difficult to convince users to accept the possibility that hardware failure may be the cause of weird system behaviour, because it has always been fine. It is worth remembering that if your hardware is going to fail, then there is going to be a first time. well, we replaced the broken machine (totally different hardware), took one of the mirrored hard disks into this replacement machine and took this replacement into production. Unfortunately it took less than 16 hours for this replacement machine to also freeze. My assumption is, the freeze itself has nothing to do with bad hardware, as it's now happening on two different machines. This replacement doesn't have em NICs but gives the same bad behavior (so I also think, it's not em related). As I really do want to know what's going on, I'm now compiling a new world + kernel with WITNESS and INVARIANTS support and see if I can catch something. I'm using the following additional kernel options: makeoptions DEBUG=-g options KDB options KDB_UNATTENDED options KDB_TRACE options DDB options WITNESS options WITNESS_SKIPSPIN options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC options PANIC_REBOOT_WAIT_TIME=60 Suggestions on these options? Anything more to enable with massive performace loss? `uname -v': FreeBSD 6.2-RELEASE-p1 #0: Sun Feb 11 22:35:18 CET 2007 While it's now in a box with an Athlon XP, it's still i386 binary. Anything else I can additionally do to debug these freezes? Thx Volker dmesg: Copyright (c) 1992-2007 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-RELEASE-p1 #0: Sun Feb 11 22:35:18 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GwMbg Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP (1198.83-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0480800SYSCALL,MP,MMX+,3DNow+,3DNow real memory = 1073676288 (1023 MB) avail memory = 1041526784 (993 MB) ACPI APIC Table: AMIINT VIA_K7 ioapic0 Version 0.3 irqs 0-23 on motherboard acpi0: AMIINT VIA_K7 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 8377 (Apollo KT400/KT400A/KT600) host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xd400-0xd4ff mem 0xdfffbf00-0xdfffbfff irq 16 at device 12.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:80:48:15:3f:26 atapci0: VIA 6420 SATA150 controller port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f,0xd800-0xd8ff irq 20 at device 15.0 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 atapci1: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci1 ata1: ATA channel 1 on atapci1 uhci0: VIA 83C572 USB controller port 0xc400-0xc41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xc800-0xc81f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
Re: ghosthunting: machine freeze 6.2R
Using a debug kernel, the machine came up quickly with this LOR after the reboot: lock order reversal: 1st 0xc077078c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:625 2nd 0xc4f18180 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6386 KDB: stack backtrace: kdb_backtrace(0,,c072fcd0,c072e1c8,c06f6124,...) at kdb_backtrace+0x29 witness_checkorder(c4f18180,9,c4f1536e,18f2) at witness_checkorder+0x578 _mtx_lock_flags(c4f18180,0,c4f1536e,18f2,c4f18180,...) at _mtx_lock_flags+0x78 pf_test(2,c4bdec00,e35c5ac4,0,0,...) at pf_test+0x81 pf_check_out(0,e35c5ac4,c4bdec00,2,0) at pf_check_out+0x3d pfil_run_hooks(c0770340,e35c5b40,c4bdec00,2,0,...) at pfil_run_hooks+0xc9 ip_output(c50c8200,0,e35c5b0c,0,0,0) at ip_output+0x83a tcp_respond(0,c4f85810,c4f85824,c50c8200,0,7a481ad6,4) at tcp_respond+0x3e1 tcp_input(c50c8200,14,1,93d306d9,0,...) at tcp_input+0x3124 ip_input(c50c8200) at ip_input+0x785 netisr_processqueue(c076dfd8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c4afca78,c4b4b180) at ithread_execute_handlers+0xe6 ithread_loop(c4adb990,e35c5d38,c4adb990,c0505918,0,...) at ithread_loop+0x67 fork_exit(c0505918,c4adb990,e35c5d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35c5d6c, ebp = 0 --- Expensive timeout(9) function: 0xc0528fb4(0) 0.002565972 s Is it a known LOR? `uname -a' FreeBSD ... 6.2-RELEASE-p5 FreeBSD 6.2-RELEASE-p5 #0: Fri May 25 12:34:43 CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GwMbg.debug i386 I'll keep watching this machine now it has debug functionality in kernel. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ghosthunting: machine freeze 6.2R
On 05/25/07 15:01, Roger Miranda - Digital Relay Inc. wrote: ... Volker Kris, Sorry for kind of hi-jacking your thread. Just hopefully we all can work together to fix this issue (if there is one). For me, that's ok as it may (or may not) be a similar problem. Out machine did goto in to a hard lock. Nothing showed up on the screen or logs. I did see something from WITNESS in dmesg. See below. But this does not show up at the time of the crash. If I remember correctly this show up at boot time. We have added the following kernel options: options DDB options KDB options BREAK_TO_DEBUGGER options INVARIANTS options INVARIANTS_SUPPORT options WITNESS options DEBUG_VFS_LOCKS options DEBUG_MEMGUARD -dmesg--- softdep_waitidle: Failed to flush worklist for 0xc44ffcf8 em1: link state changed to DOWN bridge0: Ethernet address: 66:9e:c9:a6:f5:27 em0: promiscuous mode enabled em1: promiscuous mode enabled em1: link state changed to UP lock order reversal: 1st 0xc06e0820 polling (polling) @ /usr/src/sys/kern/kern_poll.c:422 2nd 0xc473070c if_bridge (if_bridge) @ /usr/src/sys/net/if_bridge.c:1976 KDB: stack backtrace: witness_checkorder(c473070c,9,c068bfbc,7b8) at witness_checkorder+0x55c _mtx_lock_flags(c473070c,0,c068bfbc,7b8,c473070c,...) at _mtx_lock_flags+0x41 bridge_input(c43d9000,c474,c43a828c,c43a8000,c474,...) at bridge_input+0x80 ether_input(c43d9000,c474,c43a828c,0,c0675f3c,...) at ether_input+0x122 e1000_rxeof(d43f2cbc,c0524e5d,d43f2ca8,1,5,...) at e1000_rxeof+0x19b e1000_poll(c43d9000,0,5) at e1000_poll+0x46 netisr_poll(0) at netisr_poll+0x70 swi_net(0,c4315438,c4323a80,c050a484,c4322648,...) at swi_net+0xb0 ithread_loop(c430f700,d43f2d38,c430f700,c050a484,0,...) at ithread_loop+0x1de fork_exit(c050a484,c430f700,d43f2d38) at fork_exit+0x7d fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd43f2d6c, ebp = 0 --- softdep_waitidle: Failed to flush worklist for 0xc44ffcf8 em0: link state changed to UP From this output, I would assume, we're fighting with two completely different problems. I've catched 3 LORs and a strange (?) ACPI message within the last few hours. I'll post everything I've got in another post in a few minutes. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
LORs (was Re: ghosthunting: machine freeze 6.2R)
On 05/25/07 13:45, Volker wrote: Using a debug kernel, the machine came up quickly with this LOR after the reboot: lock order reversal: 1st 0xc077078c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:625 2nd 0xc4f18180 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6386 KDB: stack backtrace: kdb_backtrace(0,,c072fcd0,c072e1c8,c06f6124,...) at kdb_backtrace+0x29 witness_checkorder(c4f18180,9,c4f1536e,18f2) at witness_checkorder+0x578 _mtx_lock_flags(c4f18180,0,c4f1536e,18f2,c4f18180,...) at _mtx_lock_flags+0x78 pf_test(2,c4bdec00,e35c5ac4,0,0,...) at pf_test+0x81 pf_check_out(0,e35c5ac4,c4bdec00,2,0) at pf_check_out+0x3d pfil_run_hooks(c0770340,e35c5b40,c4bdec00,2,0,...) at pfil_run_hooks+0xc9 ip_output(c50c8200,0,e35c5b0c,0,0,0) at ip_output+0x83a tcp_respond(0,c4f85810,c4f85824,c50c8200,0,7a481ad6,4) at tcp_respond+0x3e1 tcp_input(c50c8200,14,1,93d306d9,0,...) at tcp_input+0x3124 ip_input(c50c8200) at ip_input+0x785 netisr_processqueue(c076dfd8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c4afca78,c4b4b180) at ithread_execute_handlers+0xe6 ithread_loop(c4adb990,e35c5d38,c4adb990,c0505918,0,...) at ithread_loop+0x67 fork_exit(c0505918,c4adb990,e35c5d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35c5d6c, ebp = 0 --- Expensive timeout(9) function: 0xc0528fb4(0) 0.002565972 s This first one appeared at 13:22 (short after bootup). ok, the next two LORs (similar to the first): at 13:28 this one came into the logs: lock order reversal: 1st 0xc077078c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:625 2nd 0xc4f18180 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6386 KDB: stack backtrace: kdb_backtrace(0,,c072fcd0,c072e1c8,c06f6124,...) at kdb_backtrace+0x29 witness_checkorder(c4f18180,9,c4f1536e,18f2) at witness_checkorder+0x578 _mtx_lock_flags(c4f18180,0,c4f1536e,18f2,c4f18180,...) at _mtx_lock_flags+0x78 pf_test(2,c4bdec00,e35c5ac4,0,0,...) at pf_test+0x81 pf_check_out(0,e35c5ac4,c4bdec00,2,0) at pf_check_out+0x3d pfil_run_hooks(c0770340,e35c5b40,c4bdec00,2,0,...) at pfil_run_hooks+0xc9 ip_output(c50c8200,0,e35c5b0c,0,0,0) at ip_output+0x83a tcp_respond(0,c4f85810,c4f85824,c50c8200,0,7a481ad6,4) at tcp_respond+0x3e1 tcp_input(c50c8200,14,1,93d306d9,0,...) at tcp_input+0x3124 ip_input(c50c8200) at ip_input+0x785 netisr_processqueue(c076dfd8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c4afca78,c4b4b180) at ithread_execute_handlers+0xe6 ithread_loop(c4adb990,e35c5d38,c4adb990,c0505918,0,...) at ithread_loop+0x67 fork_exit(c0505918,c4adb990,e35c5d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35c5d6c, ebp = 0 --- Expensive timeout(9) function: 0xc0528fb4(0) 0.002565972 s At 16:55 I catched this message: kernel: acpi: suspend request ignored (not ready yet) A minute (or seconds?) the machine died and I did not get anything around that time into the logs. What's the reason for this ACPI message? After bootup (reset key pressed by an operator), the machine brought this LOR: lock order reversal: 1st 0xc4f68180 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6386 2nd 0xc077078c tcp (tcp) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:2744 KDB: stack backtrace: kdb_backtrace(0,,c072e1c8,c072fcd0,c06f6124,...) at kdb_backtrace+0x29 witness_checkorder(c077078c,9,c4f6536e,ab8) at witness_checkorder+0x578 _mtx_lock_flags(c077078c,0,c4f6536e,ab8,c077078c,...) at _mtx_lock_flags+0x78 pf_socket_lookup(e35c5b00,e35c5b04,1,e35c5bc0,0,...) at pf_socket_lookup+0x1d3 pf_test_tcp(e35c5b70,e35c5b68,1,c4ee0e00,c4d6f400,...) at pf_test_tcp+0x11e6 pf_test(1,c4c11c00,e35c5c5c,0,0,...) at pf_test+0xb8b pf_check_in(0,e35c5c5c,c4c11c00,1,0) at pf_check_in+0x37 pfil_run_hooks(c0770340,e35c5cb4,c4c11c00,1,0) at pfil_run_hooks+0xc9 ip_input(c4d6f400) at ip_input+0x272 netisr_processqueue(c076dfd8) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xc2 ithread_execute_handlers(c4afca78,c4b4b180) at ithread_execute_handlers+0xe6 ithread_loop(c4adb990,e35c5d38,c4adb990,c0505918,0,...) at ithread_loop+0x67 fork_exit(c0505918,c4adb990,e35c5d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35c5d6c, ebp = 0 --- My assumption: The LORs are somewhat pf related but are not related to the lockdown of the system. Am I correct? What might be reason for that ACPI message and may ACPI be a cause of the lockdown? What might be a possible cause for WITNESS and INVARIANTS being unable to catch whatever causes the freeze? Thx Volker PS: sorry for flooding this list, should I direct postings to [EMAIL PROTECTED] PPS: Is anybody able to provide me patches for these LORs? ___ freebsd-stable@freebsd.org mailing list http
Re: ghosthunting: machine freeze 6.2R
On 05/23/07 09:17, Oliver Fromme wrote: Roger Miranda wrote: Volker wrote: [...] I've attached the latest dmesg, can you see any similarities (as it still might be a hardware issue)? [...] Our current version is: FreeBSD 6.2-RELEASE FreeBSD 6.2-RELEASE #0 Looks like you are also using the EM network adapter driver. We are suspecting the driver or Network adapters them self. Our other boxes are using xl0 (3com) and are working fine. The em(4) driver has received quite a few updates lately, and I think some of them have been MFCed to RELENG_6 since 6.2-RELEASE. I don't use any em(4) interfaces myself (I prefer bge(4) and others), so I'm not sure if there's any relationship with your trouble, but I suggest you try updating to the latest 6-stable (RELENG_6) code. (Or even give 7-current a try if you have a spare disk for installation so you can quickly swap it back with 6.x if any show-stoppers arise. In general I don't recommend installing 7-current on production machines, though.) Oliver, thanks for your hints. I haven't monitored RELENG_6 for em changes. If the problem remains (today no freeze occurred) I'll go -STABLE on that machine and see if it solves the issues. Currently I'm watching this machine over the distance and waiting for the freeze... I'm unable to check -CURRENT on it (it's 24x7 production and remote and both is a 'don't do it'). Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ghosthunting: machine freeze 6.2R
talking to myself... ;) On 2007-05-23 10:27, Volker wrote: Currently I'm watching this machine over the distance and waiting for the freeze... ...and the machine freeze came this afternoon. I've had a good dump of the network traffic and haven't seen any strange network traffic. Unfortunately three hours later, the machine died completely. It has been a hardware failure which came quietly. Sorry for the noise I've put on this list but when experiencing things like that, one has to think in all possible directions (I first thought about a DoS attack). Thx! Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ghosthunting: machine freeze 6.2R
Hi! Starting yesterday I'm experiencing machine freezes on a 6.2-R system (remote to me). The strange thing: It occurs twice a day, in the morning hours (both freezes are within 1-2 hours) and for the rest of the day everything runs fine. The machine does not respond anymore (no net, no keyboard interaction) but does not panic. The hardware is a Dell PE-750 and is running for the last 4 years w/o any trouble. It's a gateway system (border router, mail hub etc. etc.) and is also running IPSec tunnels and a poptop server for road clients. My first thought is a hardware problem but why does it occur that less and only in the morning? My next thought is a DoS attack (CVE-2007-0244?) but can that lead into a machine freeze? Is anybody else seeing freezes these days? FreeBSD 6.2-RELEASE-p1 #0: Sun Feb 11 22:35:18 CET 2007 i386 Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ghosthunting: machine freeze 6.2R
On 05/22/07 17:18, Ivan Voras wrote: Volker wrote: My first thought is a hardware problem but why does it occur that less and only in the morning? My next thought is a DoS attack (CVE-2007-0244?) but can that lead into a machine freeze? When in the morning? If it's around 3-4 am, that's when the (often hardware intensive) default cron jobs kick in. No, it's not cron (perdiodic daily/security) related. It appears sometime between 7 and 11 am (CEST). That would be too easy. Probably it's too early to see similarities as it's just on two days in a row. Tomorrow I'll have a hub at that location and can watch traffic using a 2nd bsd machine. Let's see, if that leads to any strange traffic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ghosthunting: machine freeze 6.2R
On 05/22/07 18:24, Roger Miranda wrote: On Tuesday 22 May 2007 08:15, Volker wrote: Hi! Starting yesterday I'm experiencing machine freezes on a 6.2-R system (remote to me). The strange thing: It occurs twice a day, in the morning hours (both freezes are within 1-2 hours) and for the rest of the day everything runs fine. The machine does not respond anymore (no net, no keyboard interaction) but does not panic. We also have been experiencing the same type of behavior (as explained in a previous post). freeze times vary throughout the day. However, if we have no network connections attached to the box, It stays up consistantly. Could you take it off your network and see if it still freezes up ? Roger, hmm, it's a gateway which is the connection to the world for a bunch of users, also the endpoint of 4 IPSec tunnels, the main DNS server for a whole company, pptp server for road clients... well, I don't think I can take it offline for too long. ;) There's nothing of interest in the logs (I suspect it's too late to have any daemon write something to syslogd as the system is then dead). As I also think, this is somehow related to network traffic, I'll try to monitor it's traffic starting tomorrow. The tech guys at the office there have to install a hub first (yes, it's remote to me which makes investigation harder). As I think (well, guesswork) this might be related to GRE traffic (the poptop server), I may stop this traffic at the firewall (and take the service to another machine). What's the version of the system you're having trouble with? Is it pre-6.2? I'm wondering if your machine also passes GRE traffic? Does it provide pptp services? I've attached the latest dmesg, can you see any similarities (as it still might be a hardware issue)? Volker Copyright (c) 1992-2007 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-RELEASE-p1 #0: Sun Feb 11 22:35:18 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GwMbg Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2800.11-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf34 Stepping = 4 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x441dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,b14 Logical CPUs per core: 2 real memory = 536608768 (511 MB) avail memory = 51328 (491 MB) ACPI APIC Table: DELL PE750 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic1: Changing APIC ID to 3 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard acpi0: DELL PE750 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 3.0 on pci0 pci1: ACPI PCI bus on pcib1 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xece0-0xecff mem 0xfe1e-0xfe1f irq 18 at device 1.0 on pci1 em0: Ethernet address: 00:c0:9f:46:ec:c6 pcib2: ACPI PCI-PCI bridge at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 uhci0: UHCI (generic) USB controller port 0xcce0-0xccff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) 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 uhci1: UHCI (generic) USB controller port 0xccc0-0xccdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller 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 pci0: base peripheral at device 29.4 (no driver attached) pci0: base peripheral, interrupt controller at device 29.5 (no driver attached) ehci0: Intel 6300ESB USB 2.0 controller mem 0xfe30-0xfe3003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: Intel 6300ESB USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci3: ACPI PCI bus on pcib3 em1: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xdcc0-0xdcff mem 0xfdee-0xfdef irq 21 at device 2.0 on pci3 em1: Ethernet address: 00:c0:9f:46:ec:c7 fxp0: Intel 82557 Pro/100 Ethernet port 0xdca0-0xdcbf mem 0xfe8ff000-0xfe8f,0xfdd0
Re: minimizing downtime on upgrades? (for example: mysql 4.1 - 5.0 or php)
On 05/22/07 21:03, Olivier Mueller wrote: Some freebsd-beginner questions about how to maintain a production server up to date day after day, with a practical example: now I have to update a 6.1-based server from mysql 4.1 to mysql 5.0, minimizing the downtime during the upgrade. In the past under other OS'es I would have taken the mysql source, compiled the whole, and then on upgrade time: - stopped the services (httpd, etc.) - mysqldump of all tables - stopped mysqld - removed the old version (+backup) - 'make install'ed the new one - started mysqld - imported the db and restarted the other services - 2-3 minutes downtime, depending on the size of the databases Now I can't really do that under FreeBSD: if I want to prepare (just make in the ports directory) the mysql50-server part, it answers: Oliver, try something like: portupgrade -o databases/mysql50-client mysql-client portupgrade -o databases/mysql50-server mysql-server Make sure you're doing a backup of your SQL data *before* you're doing this as the MySQL server (AFAIR) is being halted at upgrade time (short after compiling everything has finished). The portupgrade commands mentioned above might just be half of the work as other ports might need an upgrade, too. I did the same some weeks ago but can't remember if there was any extra work needed. HTH Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel trap 12 while reloading pf + altq
On 05/18/07 16:14, Max Laier wrote: On Friday 18 May 2007 13:10, Volker wrote: I'm wondering if any of the hackers is able to take a look at this panic? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/106400 I will try to finally get this into comittable shape one of these days. Can you confirm that it fixes things for you, too? snip - Max Max, long time no read... thanks for your answer. I'll try and see if I can recreate this panic anyhow. At least, I'm unable to get the machine easily. Half a year ago, the machine panic'd when reloading pf rules using altq on ngX interface. This issue has gone a while back. If I can't cause the machine to panic, it will be hard to tell if your patch works or not. Will come back to you as soon as I've got any results. For the PR: I already commented on it. Unfortunately I don't use for myself what I've suggested to the PR committer. Thx Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel trap 12 while reloading pf + altq
Hi!
I'm wondering if any of the hackers is able to take a look at this panic?
The following panic occurred while trying to reload pf rules. The
reload was needed as `pfctl -sq' gave me something like 'bad file
descriptor'. I haven't seen these panics for a while now but months
ago I've had a lot of trouble using altq + netgraph/mpd and the system
panic'ed every time reloading rules (with queuing). Probably this is
also netgraph related again.
Also I'm wondering why kgdb doesn't give me the panic message on
startup (it's taken from dmesg, the backtrace is taken from kgdb as it
also contains source code line numbers).
Machine is 6-STABLE, csup'ed and compiled 20 days ago.
Thx!
Volker
Following: panic message, backtrace, uname, dmesg
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x100
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05ae2ec
stack pointer = 0x28:0xdac91920
frame pointer = 0x28:0xdac91934
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 6033 (pfctl)
trap number = 12
panic: page fault
cpuid = 0
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc05b9af1 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#2 0xc05b9f13 in panic (fmt=0xc07f0c85 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc07aec9e in trap_fatal (frame=0xdac918e0, eva=0)
at /usr/src/sys/i386/i386/trap.c:837
#4 0xc07ae1f4 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -998496384, tf_esi
= 0, tf_ebp = -624355020, tf_isp = -624355060, tf_ebx = -1018739444,
tf_edx = 0, tf_ecx = 2, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip
= -1067785492, tf_cs = 32, tf_eflags = 65606, tf_esp = -1018739444,
tf_ss = -624355004})
at /usr/src/sys/i386/i386/trap.c:270
#5 0xc07951fa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc05ae2ec in _mtx_lock_sleep (m=0xc347450c, tid=3296470912, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546
#7 0xc0472a8e in rmc_delete_class (ifd=0xc4174c04, cl=0xc577aa00)
at /usr/src/sys/contrib/altq/altq/altq_rmclass.c:572
#8 0xc046cd70 in cbq_class_destroy (cbqp=0xc4174800, cl=0xc577aa00)
at /usr/src/sys/contrib/altq/altq/altq_cbq.c:116
#9 0xc046ce6f in cbq_clear_interface (cbqp=0xc4174800)
at /usr/src/sys/contrib/altq/altq/altq_cbq.c:179
#10 0xc046d165 in cbq_remove_altq (a=0x0)
at /usr/src/sys/contrib/altq/altq/altq_cbq.c:299
---Type return to continue, or q return to quit---
#11 0xc0474eb4 in altq_remove (a=0x0)
at /usr/src/sys/contrib/altq/altq/altq_subr.c:642
#12 0xc048ade4 in pf_commit_altq (ticket=1)
at /usr/src/sys/contrib/pf/net/pf_ioctl.c:1123
#13 0xc048eea5 in pfioctl (dev=0xc3482600, cmd=4,
addr=0x3 Address 0x3 out of bounds, flags=3, td=0x1)
at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3056
#14 0xc0556727 in devfs_ioctl_f (fp=0xc396f798, com=3222029394,
data=0xc3dc40d0, cred=0xc57a8900, td=0xc47c2780)
at /usr/src/sys/fs/devfs/devfs_vnops.c:479
#15 0xc05e7e6b in ioctl (td=0xc47c2780, uap=0xdac91d04) at file.h:265
#16 0xc07af0c0 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077944964,
tf_esi = 0, tf_ebp = -1077944952, tf_isp = -624353948, tf_ebx =
-1077942400, tf_edx = 134737920, tf_ecx = 0, tf_eax = 54, tf_trapno =
0, tf_err = 2, tf_eip = 672821475, tf_cs = 51, tf_eflags = 582, tf_esp
= -1077944996, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:983
#17 0xc079524f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:200
#18 0x0033 in ?? ()
uname -a:
FreeBSD bellona.sz.vwsoft.com 6.2-STABLE FreeBSD 6.2-STABLE #20: Fri
Apr 27 16:41:22 CEST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BELLONA i386
dmesg:
Copyright (c) 1992-2007 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-STABLE #20: Fri Apr 27 16:41:22 CEST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BELLONA
ACPI APIC Table: AMIINT VIA_K7
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) XP 2400+ (1998.06-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x681 Stepping = 1
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow
real memory = 536805376 (511 MB)
avail memory = 515674112 (491 MB)
ioapic0 Version 0.3 irqs 0-23 on motherboard
wlan: mac acl policy registered
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: AMIINT VIA_K7 on motherboard
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality
Re: Re: tproxy on freebsd
On 12/23/-58 20:59, zen wrote: i don't have a problem with this but i am going to be setting up a similar setup and would appreciate the help a working setup would provide. any help will be appreciated, i could use a sample configuration file regarding this problem. zen others, building a transparent proxy using pf + squid is an easy topic and well documented on the net. In detail, it's going that way: pf (assuming nve0 is your local IF): rdr on nve0 from any to any port 80 - 127.0.0.1 port 3128 pass in on nve0 from any to any port 80 keep state pass in on nve0 from any to 127.0.0.1 port 3128 keep state Now, compile squid with transparent support and use: 'http_port 3128 transparent' in your squid.conf (assuming you're running squid = 2.6). I'm running several hosts with a setup like that. Also you may want to check out www/havp and use it as a transparent proxy + squid as upstream proxy. That way you also have virus protection for your internal users while surfing the web (I'm also doing things like that as I found it a better solution that squidclam or the like - YMMV). FYI i already running transparent proxy with ipf+ipnat,: rdr nve0 0.0.0.0/0 port 80 - 122.x.x.x port 3128 tcp but with that configuration, still the proxy ip address that visible when my client using the proxy. Don't understand that sentence. What address is visible to whom? And which address do you want to 'hide'? If you don't want to leak your internal addresses to any outside webserver, this is a squid issue and there should (?) be configuration options for squid. is it me or just i cant achieve that with FreeBSD? because i hate to switch to other OS only because of this. No need to switch! :) You may find tons of infos using google or in the ML archives [EMAIL PROTECTED] Also pf@ or isp@ would be the appropriate list for questions like that. HTH, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tproxy on freebsd
On 04/18/07 14:14, Adrian Chadd wrote: On 18/04/07, Volker [EMAIL PROTECTED] wrote: but with that configuration, still the proxy ip address that visible when my client using the proxy. Don't understand that sentence. What address is visible to whom? And which address do you want to 'hide'? If you don't want to leak your internal addresses to any outside webserver, this is a squid issue and there should (?) be configuration options for squid. He means fully transparent - ie, client thinks its talking to the server; server thinks its talking to the client; proxy server IP isn't visible to either. Adrian Adrian, thanks, I got it. Talking about real transparent proxy not just a transparent one... ;) Unfortunately I don't have a solution for that as I'm using mostly NATed environments and it doesn't make sense to hand out private address space to a web server. Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror Issues
On 12/23/-58 20:59, Joe Kelsey wrote: I am having a real hard time with gmirror. I recently bought two new 400G SATA disks and I want to mirror them. I think I am following the directions, but I am not sure. I generally do the following steps: edit /boot/loader.conf to add geom_mirror_load. reboot into single-user gmirror label -v -b round-robin gm0 ad4s1 ad6s1 bsdlabel -w mirror/gm0 bsdlabel -e mirror/gm0 newfs mirror/gm0a Joe, check what `bsdlabel mirror/gm0' gives right after editing the partitioning information and re-check that info after a reboot. There might be an issue... Check if bsdlabel complains about partition c not being sized well. Could you please try to `gmirror unload' before doing anything and a `gmirror load' right after labeling the mirror? Or just try a reboot after labeling the mirror. If that does make a difference, it's a sign I've been right with my last week's experience. If you're still getting into trouble, you may want to zero out the first sectors of the disk using `dd'. When creating a 400 gig mirror, it will take a long time for the mirror to complete and you're mirroring waste in the first step. I would recommend to create the mirror with just one consumer, create the partitions, newfs and then insert the 2nd consumer into the mirror. Just to make sure, I would check the status of the mirror using `gmirror status' and wait until its state is COMPLETE before doing anything else. BTW, do you really want to use a dangerously dedicated disk (by using gm0X) without any slices? HTH, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: bsdlabel blues again
Michel, On 12/23/-58 20:59, Michel Talon wrote: Volker said: As I've done this procedure twice yesterday and once more today, I've double and triple checked everything but I'm running into one single problem: partition c extends past end of unit and doesn't start at 0. I think you should run bsdlabel on the mirror, not on the raw partitions or disks. Then you will have no more problem of the above type, only the innocuous following one: Thanks for your answer but I should have stated in my first message I'm not a totally stupid bloody newby. I do know the difference between raw disk slices and mirrored slices. I've also done this procedure a lot times before with less trouble. I was talking about something what I would like to name a bug or call it strange behavior. Just for the archives, I've got it working now. As I've converted from one (working) mirror to another, gmirror seemed to cache slice / partition infos. To work around that kind of trouble, one needs to create the slices, label the mirror, reboot (!) and then continue with partioning. Otherwise gmirror is working on old, cached values which will give out of bound partitioning values. Creating the slices, label the mirror and create the partitions in one go will most likely get you to bad partition values. This extra step of rebooting should most likely not be needed if one is able to `gmirror load' after labeling the mirror but in my case I've been unable to unload gmirror because I've already been working on a live mirror. So the reboot was needed as there's no command to re-sync geom values. My description does not mean to be technically correct but this is what I've experienced and the only thing I can imagine what's going on in the background. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
bsdlabel blues again
Hi folks! Yesterday and today I've tried to upgrade my hd's (from 80G SATA to 250G SATA) on 6.2-STABLE (recent). My old disks (two equally sized) were under control of gmirror (one per each slice) and so should the setup look like for the new disks. Basically I've created the slices (sysinstall's fdisk), created a gmirror for each new slice, bsdlabel'ed -w, edited the labels and created the filesystems. As I've done this procedure twice yesterday and once more today, I've double and triple checked everything but I'm running into one single problem: partition c extends past end of unit and doesn't start at 0. While/after I've edited the labeles, everything has been fine and I double checked the labels after writing them out. I've seen this problem after rebooting the machine. Before the reboot bsdlabel didn't claim about anything. Now my disklabels are looking as: # bsdlabel mirror/gm1s1 # /dev/mirror/gm1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 4194304 794.2BSD0 0 0 b: 8388608 4194383 swap c: 62910477 63unused0 0 # raw part, don't edit d: 4194304 125829914.2BSD0 0 0 e: 12582912 167772954.2BSD0 0 0 f: 10485760 293602074.2BSD0 0 0 g: 23064572 398459674.2BSD0 0 0 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition g: partition extends past end of unit # bsdlabel mirror/gm1s2 # /dev/mirror/gm1s2: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 56613060 62910540unused0 0 # raw part, don't edit d: 10485760 629105564.2BSD0 0 0 e: 16777216 733963164.2BSD0 0 0 f: 16777216 901735324.2BSD0 0 0 g: 6291456 1069507484.2BSD0 0 0 h: 6281395 1132422044.2BSD0 0 0 partition c: offset past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition d: offset past end of unit partition d: partition extends past end of unit partition e: offset past end of unit partition e: partition extends past end of unit partition f: offset past end of unit partition f: partition extends past end of unit partition g: offset past end of unit partition g: partition extends past end of unit partition h: offset past end of unit partition h: partition extends past end of unit # bsdlabel mirror/gm1s3 # /dev/mirror/gm1s3: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1929245840unused0 0 # raw part, don't edit d: 20971520 164.2BSD 2048 16384 28552 e: 31457280 209715364.2BSD 2048 16384 28552 f: 41943040 524288164.2BSD 2048 16384 28552 g: 16777216 943718564.2BSD 2048 16384 28552 h: 81775512 490724.2BSD 2048 16384 28552 I swear after editing (but before rebooting) each c partition started at 0 and no partition (g or h label) extended past the slice. Also why is the offset of the whole gmirror gm1s2 totally blown? After adding the last gmirror (gm1s3) I also rebooted the system but these labels are still looking fine. While creating all labels, I'm always using bsdlabel's automatic calculation, as I'm just keying in the size (in G or M) and using an asterisk at it's offset. The filesystems are working well so I think the values shown are not used by the kernel when mounting filesystems. What's wrong with gmirror or bsdlabel? # uname -a FreeBSD bellona.sz.vwsoft.com 6.2-STABLE FreeBSD 6.2-STABLE #16: Tue Mar 20 20:10:33 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BELLONA i386 Thanks, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
open source graphics card
Hi! I've followed the thread don't buy ati products not very closely but one thing comes to mind: Years ago we've had a lot of card / chip manufacturers on the market. When thinking about this currently really just two chip manufacturers are coming into my mind. This is bad. It's probably a crazy idea but what about an open source graphics card? There are similar projects already like OsCar so the idea of open source hardware development is not really new but probably exciting. Aren't there any hw devs reading and motivated? Imagine a graphics chip with a BSD style license... ;) Just dreaming? Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open source graphics card
Ralf, On 03/16/07 11:38, Ralf Folkerts wrote: ... there's the Open Graphics Project http://wiki.duskglow.com/tiki-index.php?page=AboutOpenGraphics Unfortunately I haven't heard much news from them for quite a while now :-( So I'm not sure if the Project stalled. I haven't been aware of such a project. The project goals don't sound that bad but I guess you're right about the current project status. The last blog entry has been in 12/2005. On the other side, the site statistics do show an impressive interest in a project like that. 10k page hits per day is not that bad! Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: sysctl segfaulting
On 12/23/-58 20:59, Michael Nottebrock wrote: Does anybody have any further ideas on this? Michael, I didn't follow that thread deeply so I'm not quite sure if you checked all possibilities or my suggestion has already been tried. I've had the system crashing for every `sysctl | less' or `sysctl | grep ...' anytime in the RELENG_5 time. I've always been too lazy to file a PR on that also I didn't take further inspection on that kind of problem. It automagically went away some time a few months ago so I'm now unable to reproduce this problem anymore. Your problem with libelf reminded me to one thing: Have you done a `make check-old' in /usr/src already? I didn't find it in the docs but while reading the Makefile.incl and have not been aware of that check procedure but it clearly showed I've had some elder binaries in my system. Please forgive me if that hint has already been posted. HTH, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: non-sleepable lock 6-STABLE
Hi! This evening I've had a mysterious thing: Two reboots caused by a panic in a row. The machine itself is running fine for months (always on 6-STABLE). The last kernel / world build has been a week ago. As I'm having KDB_UNATTENDED in my kernel, I didn't took notice of that crash. Trying to inspect the crashdump does not give anything useful: kgdb /usr/obj/usr/src/sys/BELLONA/kernel.debug /var/crash/vmcore.1 [snip] This GDB was configured as i386-marcel-freebsd. Cannot access memory at address 0xc08295f4 (kgdb) From the messagelog I've been able to fish the following: Sleeping thread (tid 100147, pid 1750) owns a non-sleepable lock sched_switch(c3adbc00,0,1) at sched_switch+0x15b mi_switch(1,0,c3adbc00,daab9a20,c05a657c,...) at mi_switch+0x1be sleepq_switch(c36be500) at sleepq_switch+0x84 sleepq_wait(c36be500,0,c3adbc00,1,c36be500,...) at sleepq_wait+0x5c msleep(c36be500,0,4c,c0766afa,0) at msleep+0x26f usbd_transfer(c36be500,daab9aa0,c052b619,c36be500,c0598573,...) at usbd_transfer +0x145 usbd_sync_transfer(c36be500) at usbd_sync_transfer+0x11 usbd_do_request_flags_pipe(c3440780,c3440800,daab9afc,daab9afb,0,...) at usbd_do _request_flags_pipe+0x69 usbd_do_request_flags(c3440780,daab9afc,daab9afb,0,0,...) at usbd_do_request_fla gs+0x25 usbd_do_request(c3440780,daab9afc,daab9afb,ab9b14,f0c0,...) at usbd_do_request+0 x1a aue_csr_read_1(c3470600,0,0,0,80206932,...) at aue_csr_read_1+0x50 aue_setmulti(c3470600,c3adc100,c3b69a40,c346e800,daab9b68,...) at aue_setmulti+0 x4d aue_ioctl(c346e800,80206932,0) at aue_ioctl+0x106 if_delmulti(c346e800,c35ca1a0) at if_delmulti+0x203 in_delmulti_locked(c3adc0a0) at in_delmulti_locked+0x7b in_delmulti(c3adc0a0) at in_delmulti+0x7b ip_freemoptions(c3a37900,c36ebec4,0,c3b392c8,daab9bec,...) at ip_freemoptions+0x 21 in_pcbdetach(c36ebec4) at in_pcbdetach+0x159 udp_detach(c3b392c8) at udp_detach+0xba soclose(c3b392c8) at soclose+0xa1 soo_close(c3ae7798,c3adbc00) at soo_close+0x63 fdrop_locked(c3ae7798,c3adbc00,c3aeee00,daab9cb4,c056157b,...) at fdrop_locked+0 xd8 fdrop(c3ae7798,c3adbc00,c058dde0,c09be140,c1de0668,...) at fdrop+0x40 closef(c3ae7798,c3adbc00,0,c3adbc00,6,...) at closef+0x43b close(c3adbc00,daab9d04) at close+0x209 syscall(3b,3b,3b,2,807e6c0,...) at syscall+0x2cd Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x281670ef, esp = 0xbfbfdcd0, ebp = 0xbfbfdcdc --- panic: sleeping thread cpuid = 0 KDB: stack backtrace: kdb_backtrace(100,c3adba80,c3adba80,c3adbc00,c3adbc00,...) at kdb_backtrace+0x29 panic(c077339a,c3adbc00,,c077335e,18733,...) at panic+0x113 propagate_priority(c3adba80,c35f81c0,c0805320,c080a8cc,c3adbc00,...) at propagat e_priority+0x58 turnstile_wait(c080a8cc,c3adbc00) at turnstile_wait+0x2e3 _mtx_lock_sleep(c080a8cc,c3adba80,0,0,0) at _mtx_lock_sleep+0x10c udp_bind(c3bc9164,c35cab50,c3adba80,daab6cc0,c05c8177,...) at udp_bind+0x34 sobind(c3bc9164,c35cab50,c3adba80,c3bef678,daab6d04,...) at sobind+0x16 kern_bind(c3adba80,5,c35cab50,c35cab50,c3adac90,...) at kern_bind+0x77 bind(c3adba80,daab6d04) at bind+0x2f syscall(3b,3b,3b,80501a8,805f041,...) at syscall+0x2cd Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (104, FreeBSD ELF32, bind), eip = 0x2811877b, esp = 0xbfbfe76c, ebp = 0xbfbfe7d8 --- GEOM_MIRROR: Device gm0s2: rebuilding provider ad4s2 stopped. Uptime: 8m50s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 ... ok I guess pid 1750 has been mDNSResponder (/usr/ports/net/mDNSResponder - I found something in the logs which indicates this might have been pid 1750 some time before the crash occurs). I've installed this port just today (8 hours before the crash). My main question now: Why didn't I get anything useful from the savecore dumps? I'll now prepare for a fresh kernel build, install and try to rerun mdsnd to get a proper dump. Greetings, Volker PS: I didn't include dmesg + config as I hate those lengthy postings to the list. If a kernel hacker want's to take a closer look or needs more infos, I'll put it up on the webserver for download if it's of interest in this case. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getting garbage faster using FreeBSD?
On 02/19/07 22:25, Kris Kennaway wrote: On Mon, Feb 19, 2007 at 10:09:50PM +0100, Volker wrote: On 02/19/07 20:51, Kris Kennaway wrote: On Mon, Feb 19, 2007 at 08:40:37PM +0100, Volker wrote: I suspect this to be a slow /dev/random. This sounds odd to me, I get 18-20MB/sec sustained read performance from /dev/random on this 2GHz system, which is probably faster than your tape write speed. Hmm, so this might be the tape drive(r)? I'll check this out as soon as I'm going to write to hard disk. I'm going to make some tests with /dev/random to get the real speed. Yes, it could be - you should do some more tests to find out where your bottleneck really is before trying to possibly optimize the wrong thing. As there is medical data on all media I really need garbage (/dev/zero wouldn't be enough for data security as this might get recovered). Neither would a single pass with /dev/random, but you presumably knew this. Yes, I know... I would like to run 5 or more passes if it's not that slow. Do you think playing with randoms' sysctl interface might influence performance? Does /dev/random automatically re-seed from time to time or is it seeded at boot time only? It re-seeds continuously, see random(4) and/or the yarrow specification. Don't frob the sysctls until you have confirmed that /dev/random is really your problem though. Kris, ok and thanks - it has been the person in front of the computer, who has been too stupid (could it be me??). I've played a bit on that machine using /dev/random to /dev/null and used different blocksizes. The results are somewhat around 33MB/sec (with blocksizes between 1M and 8M). Now I've played with different blocksizes while dd'ing /dev/random to the hard disk and getting similar results. dd'ing to the tape drive gives best results with blocksizes around 64k. Using blocksizes with 1k gives 230KB/sec, 8k gives 1.7MB/sec. The tape drive did not stream well and I guess that (too short block sizes) has been my problem. Now it performs well. Sorry for sending my stupidity to the list. ;) Thx, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
getting garbage faster using FreeBSD?
Hi! For my dentist I'm currently in the process of destroying some tape cartridges (SLR7) and also two hard disks (147G SCSI). As I started for the tapes, I've used dd to fill the tape with random garbage. Just a simple `dd if=/dev/random of=/dev/nsa0'. The tape sits there since 48 hours writing a block of data every other minute and still didn't fill up the tape completely. The system this is running on is a P-4 3GHz machine using FreeSBIE 2.0 (6.2-RELEASE based). I suspect this to be a slow /dev/random. Is there any chance to speed up /dev/random? Would a hifn accelerator card help here to get FreeBSD produce garbage faster? As there is medical data on all media I really need garbage (/dev/zero wouldn't be enough for data security as this might get recovered). Thx, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getting garbage faster using FreeBSD?
On 02/19/07 20:51, Kris Kennaway wrote: On Mon, Feb 19, 2007 at 08:40:37PM +0100, Volker wrote: The tape sits there since 48 hours writing a block of data every other minute and still didn't fill up the tape completely. The system this is running on is a P-4 3GHz machine using FreeSBIE 2.0 (6.2-RELEASE based). I suspect this to be a slow /dev/random. This sounds odd to me, I get 18-20MB/sec sustained read performance from /dev/random on this 2GHz system, which is probably faster than your tape write speed. Hmm, so this might be the tape drive(r)? I'll check this out as soon as I'm going to write to hard disk. I'm going to make some tests with /dev/random to get the real speed. Is there any chance to speed up /dev/random? Would a hifn accelerator card help here to get FreeBSD produce garbage faster? As there is medical data on all media I really need garbage (/dev/zero wouldn't be enough for data security as this might get recovered). Neither would a single pass with /dev/random, but you presumably knew this. Yes, I know... I would like to run 5 or more passes if it's not that slow. Do you think playing with randoms' sysctl interface might influence performance? Does /dev/random automatically re-seed from time to time or is it seeded at boot time only? Thx, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: impossible rc.d ordering problem with stf and pf ?
On 12/23/-58 20:59, Pete French wrote: Am trying to solve a little problem with 'pf'. I have a ruleset which has some firewall rules for the IPv6 interface stf0. This works fine, except when I rreboot the machine, as the pf script is run before the network_ipv6 script - so stf0 does not exist. but I cannot work out how to arrange for stf0 to be created before the pf script is run - as network_ipv6 requires 'routing', but the pf script says it must be run before 'routing', if I am reading the 'REQUIRE' and 'BEFORE' lines correctly. Pete, I've played with that problems a few times. It's not a perfect solution, but you may create your own pf loading script and place it in /usr/local/etc/rc.d/. To make sure it's running late in startup, use a proper # REQUIRE: line. That way (and that what makes me saying it's not perfect) pf load script /etc/rc.d/pf is being run but aborts loading pf rules in first place and later (when rc is working though /usr/local/etc/rc.d/) pf rules are loaded by your custom script. HTH, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: impossible rc.d ordering problem with stf and pf ?
On 01/28/07 16:40, Alexey Karagodov wrote: 2007/1/28, Volker [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: I've played with that problems a few times. It's not a perfect solution, but you may create your own pf loading script and place it in /usr/local/etc/rc.d/. To make sure it's running late in startup, use a proper # REQUIRE: line. That way (and that what makes me saying it's not perfect) pf load script /etc/rc.d/pf is being run but aborts loading pf rules in first place and later (when rc is working though /usr/local/etc/rc.d/) pf rules are loaded by your custom script. or just make a symlink from /etc/rc.d/pf to /usr/local/etc/rc.d/pf i solved this way problem with FQDN in pf rules Alexey, yes, I also did it using a simple symlink in the past but reading stable@ (or has it been [EMAIL PROTECTED]) it is planned (or already implemented?) to respect the rcorder for /etc/rc.d/ _and_ /usr/local/etc/rc.d/ in one go. That means the rcorder is being calculated for both directories in one step. I suspect when just symlinking an rc-script from /etc/rc.d/ this might lead into the script being executed two times in a row. I might be wrong on this but your suggestion is using a side effect which might not work with all versions. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
IPSEC clarifications
Hi folks, I'm wondering if someone please could clarify some IPSec specific questions to me? IPSEC_FILTERGIF: What are the consequences when enabling this if one does use IPSEC (or FAST_IPSEC) w/o any GIF tunnels? Are there any or does IPSEC_FILTERGIF only influence packet flow with gif devices? NOTES says: # Set IPSEC_FILTERGIF to force packets coming through a gif tunnel # to be processed by any configured packet filtering (ipfw, ipf). # The default is that packets coming from a tunnel are _not_ processed; # they are assumed trusted. But I've found signs in the archives even while not using gif tunnels with IPSec packets are getting filtered with FILTERGIF option. I might be wrong about this. device enc: I haven't been aware of the fact that we already have such a device. There's a man page (man 4 enc) but it's not in NOTES or GENERIC. Is the enc(4) man page correct and up to date? Shouldn't there at least be a note in NOTES somewhere around the options FAST_IPSEC line with a hint for enc(4)? Is just compiling device enc into the kernel, using options FAST_IPSEC and passing (or blocking) traffic on interface enc0 using pf rules all one has to do? IPSEC / FAST_IPSEC: What is the (say) 'official' recommended option to use? Where are the differences, what are the consequences while using one or the other? Will both do the same w/o any consequences for the admin? I'm currently in the process of checking for migration to racoon2 and need to re-check every IPSec related setup. Thanks, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2
On 37378-12-23 20:59, Patrick M. Hausen wrote: Hello! Well, the best I can say at the moment is, Wow. =-( I guess the thing to do here is to figure out if the problem lies with the em interrupt handler not getting run, or the taskqueue not getting run. I helped Pyun with some debugging by providing ssh access to a machine showing the (seemingly) same problem. At first he thought the interrupt handler of the em driver was the culprit, but we applied quite a few patches and tested afterwards - seems like the driver is not the cause. On -stable occasionally other people complained about very similar looking problems with bge and other drivers. My guess is, though I'm not a kernel developer, just an experienced admin, that em stands out as problematic just by coincidence. Certain onboard network components tend to come with certaiin chipsets and certain architectures. So, Pyun suggested it was a problem with the taskqueue that was introduced some time between 6.0 and 6.1. With my system (Tyan GT20 B5161G20) the problem shows when there is heavy disk and cpu activity, like make buildworld. I made sure that the em interface doesn't share an interrupt with the SATA controller. When the problem occurs, I get the well known watchdog timeout messages and then the system's network activity over that interface freezes completely for a couple of minutes. Usually the system recovers after a while without reboot or other measures. Strange... I've seen exactly that on a (recent) RELENG_6 box but using a dirty old USB 1.1 NIC (aue). I've seen DOWN and UP messages (mostly while rebuilding kernel + world + ports) on the console all the time (but did not care about). The machine in question is an Athlon XP-64 Socket 939, Asus A8N-VM CSM. The USB ethernet NIC is a low budget ADMtek device. My observations are probably not related to your issues but maybe a sign of not really being a driver issue or not GigE related. Greeting, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2
On 2006-09-27 23:29, Scott Long wrote: Volker wrote: [...] Strange... I've seen exactly that on a (recent) RELENG_6 box but using a dirty old USB 1.1 NIC (aue). I've seen DOWN and UP messages (mostly while rebuilding kernel + world + ports) on the console all the time (but did not care about). [...] As soon as I can locate the O/U/EHCI register docs, I'll crank out a patch for everyone to try. If that works then I'll give the same treatment to ichsmb. Scott Scott, as I'll leave for a one week vacation tomorrow and will not be able to answer or test any patches, I just powered up the machine to get you some infos (just for the records). All devices are on-board except the ADMtek USB NIC. 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 6.2-PRERELEASE #0: Mon Sep 25 23:34:09 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DESKTOPBSD ACPI APIC Table: A M I OEMAPIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.16-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20ff2 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x1LAHF real memory = 503054336 (479 MB) avail memory = 477794304 (455 MB) ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: A M I OEMXSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x508-0x50b on acpi0 cpu0: ACPI CPU on acpi0 powernow0: Cool`n'Quiet K8 on cpu0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory, RAM at device 0.0 (no driver attached) pci0: memory, RAM at device 0.1 (no driver attached) pci0: memory, RAM at device 0.2 (no driver attached) pci0: memory, RAM at device 0.3 (no driver attached) pci0: memory, RAM at device 0.4 (no driver attached) pci0: memory, RAM at device 0.5 (no driver attached) pci0: memory, RAM at device 0.6 (no driver attached) pci0: memory, RAM at device 0.7 (no driver attached) pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 4.0 on pci0 pci3: ACPI PCI bus on pcib3 pci0: display, VGA at device 5.0 (no driver attached) pci0: memory, RAM at device 9.0 (no driver attached) isab0: PCI-ISA bridge at device 10.0 on pci0 isa0: ISA bus on isab0 pci0: serial bus, SMBus at device 10.1 (no driver attached) ohci0: OHCI (generic) USB controller mem 0xfebde000-0xfebdefff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 8 ports with 8 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfebdfc00-0xfebdfcff irq 22 at device 11.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: EHCI (generic) USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 8 ports with 8 removable, self powered atapci0: nVidia nForce MCP51 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 13.0 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: nVidia nForce MCP51 SATA300 controller port 0xe800-0xe807,0xe480-0xe483,0xe400-0xe407,0xe080-0xe083,0xe000-0xe00f mem 0xfebdd000-0xfebddfff irq 23 at device 14.0 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 atapci2: nVidia nForce MCP51 SATA300 controller port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfebdc000-0xfebdcfff irq 20 at device 15.0 on pci0 ata4: ATA channel 0 on atapci2 ata5: ATA channel 1 on atapci2 pcib4: ACPI PCI-PCI bridge at device 16.0 on pci0 pci4: ACPI PCI bus on pcib4 fwohci0: VIA Fire II (VT6306) port 0xcc00-0xcc7f mem 0xfaaff800-0xfaaf irq 16 at device 5.0 on pci4 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:00:67:ed:4b fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:67:ed:4b fwe0: Ethernet address: 02:11:d8:67:ed:4b fwe0: if_start running deferred for Giant sbp0: SBP-2/SCSI over FireWire on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0
ACPI issue with RELENG_6
Hi! With a recent RELENG_6 I've experienced what I suspect to be an ACPI issue. When powering down the system using `halt -p' I'm seeing a message like 'power off using ACPI' after the system has been shut down but the system does not power off. I've seen this yesterday with a csup'ed system as of yesterday and also today (csup'ed last night). I haven't had issues like that on this system before (using RELEASE-anything or an older RELENG_6 ACPI power off did work on that hardware). Following is my dmesg. If you need to see something more (like ACPI tables) please advise. Greetings, Volker 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 6.2-PRERELEASE #11: Fri Sep 22 01:31:31 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BELLONA WARNING: debug.mpsafenet forced to 0 as i4b_ipr requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: AMIINT VIA_K7 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2400+ (1998.05-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow real memory = 536805376 (511 MB) avail memory = 515727360 (491 MB) ioapic0 Version 0.3 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: AMIINT VIA_K7 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 8377 (Apollo KT400/KT400A/KT600) host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) ath0: Atheros 5212 mem 0xdffe-0xdffe irq 18 at device 10.0 on pci0 ath0: [GIANT-LOCKED] ath0: Ethernet address: 00:09:5b:89:7d:1f ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 ifpi0: AVM Fritz!Card PCI port 0xd400-0xd41f mem 0xdfffbfe0-0xdfffbfff irq 19 at device 11.0 on pci0 ifpi0: [GIANT-LOCKED] ifpi0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) ifpi0: passive stack unit 0 ahc0: Adaptec 29160N Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xdfffa000-0xdfffafff irq 16 at device 12.0 on pci0 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs cbb0: RF5C475 PCI-CardBus Bridge at device 13.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 atapci0: VIA 6420 SATA150 controller port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f,0xd800-0xd8ff irq 20 at device 15.0 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 atapci1: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci1 ata1: ATA channel 1 on atapci1 uhci0: VIA 83C572 USB controller port 0xc000-0xc01f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xc400-0xc41f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0xc800-0xc81f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: VIA 83C572 USB controller on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: VIA VT6202 USB 2.0 controller mem 0xdfffbd00-0xdfffbdff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: VIA VT6202 USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 pci0: multimedia, audio at device 17.5 (no driver attached) vr0: VIA VT6102 Rhine II 10/100BaseTX port 0xb800-0xb8ff mem 0xdfffbc00-0xdfffbcff irq 23 at device 18.0
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
This should be documented somewhere clearly then, as my understanding was that -STABLE meant that anything MFCd back to it *was* tested and deemed stable ... and yes, I do run stable, and yes, I do expect to hit the occasional 'oopses', but blantant and obvious bugs due to insufficient testing, IMHO, doesn't classify as an 'oops' Guys, we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking about real software. Also, you should never go with -STABLE on a production server. I'm sure this has been made clear in the handbook. If it's really a that import server in production use, go with a RELEASE. -STABLE is not a technology playground as CURRENT but should be seen as a BETA testing system. If that's not the case, then why use RELEASE at all? Sure you may blame a developer for not testing enough but you're on your own if you use beta quality software on your production systems. As a developer I've seen many bugs which haven't been found during testing and I know it's nearly impossible to find _all_ bugs while testing. I've seen applications failing just because the user typed the wrong key at the wrong time (or an unexpected key). As a user I'm thankful for bugs being fast fixed bugs but on the other side I really know what I'm doing when using -STABLE software on my system. I do see this as a give-back to the community to find bugs early before -RELEASE. Also keep in mind most kernel hackers do kernel hacking in their spare time. Everyone using FreeBSD (or any other OS system) is profiting from their spare time and it's unfair to be not that polite. And back to the issue: The gmirror bug has already been fixed and I posted a note to the ML hours before the first who the f... did cause that bug post. A short look into ML postings would have made this thread needless. If you blame developers, then please shut off your computer. my2ct Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On 2006-09-11 01:33, 'Anubhav A.' wrote: in message [EMAIL PROTECTED], wrote Volker thusly... we're talking about software. Have you ever seen a piece of software which has been really bug-free? Not the hello-world, I'm talking Recently i read about which is more than hello-world ... They Write the Right Stuff http://www.fastcompany.com/online/06/writestuff.html ... but you did ask. - Parv Interesting article but I really do not believe even the shuttle software is 100% bug free. Just because there has been only one bug found in the last version, does not mean it's really guaranteed to be bug free. It's just: No one experienced one and no one discovered one more. On the other side they do not implement much new features every day and they do not have to care about hardware and market changes every other day. I suspect a lot of trouble even for NASA's mission does come from software bugs and who knows how many lifes can be accounted for software bugs. Remembering the first launch of a Ariane-5 rocket? It has been self destroyed because of nothing but a software bug. Or what about the first NAVY combat ship w/ steering controlled by Windows NT? Out of control by a blue screen... A developer can't always foresee the environment where his code will later work in and that is even causing trouble. And again, errors and mistakes are human. And those who shout out why didn't you test enough should ask themself, how much have THEY contributed to the community? The hackers are contributing enough (my view) and are really doing a good job. I do not care about HOW MANY bugs a beta quality piece of software does contain but what IMHO matters is the timeframe to FIX them and the FreeBSD project and other OS communities are good in that. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug-free software (Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!)
On 2006-09-11 02:25, Stephen Clark wrote: Sorry to be dense but what does MFCing mean. I have googled for it but can find nothing that explains it. Thanks, Steve Steve, MFC means merge from current (read as: merge from CURRENT [HEAD] cvs tree into the current -STABLE tree). I'm seeing -CURRENT as a playground for new features, technologies and support for latest hardware. If something has worked out there, the changes are merged from the -CURRENT tree into the (non-release) -STABLE tree. -STABLE has a broader audience and mistakes will probably being detected there. At a time before RELEASE date the -STABLE tree is being frozen (no new features are allowed to be merged into -STABLE) and after a testing phase (BETA / PRE-RELEASE) the code will be released. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror RAID-1: rebuilding freezes machine
regarding the gmirror issue, I've seen the following cvs commit: Revision 1.66.2.9 / (download) - annotate - [select for diffs], Fri Sep 8 17:39:41 2006 UTC (20 hours, 35 minutes ago) by pjd Branch: RELENG_6 Changes since 1.66.2.8: +5 -12 lines Diff to previous 1.66.2.8 (colored) to branchpoint 1.66 (colored) next main 1.67 (colored) Back out previous change from RELENG_6. There is a problem with synchronization with those changes and I need some time to investigate it. I've csup'ed again, rebuild world + kernel and now gmirror sounds fine again and does the syncing. Thanks, pjd for fast fixing! One feature request on gmirror: If a system comes up and more than one mirror is out of sync, currently gmirror tries (in automatic mode) to re-sync all providers at the same time which slows down the system. When gmirror tries to do a resync, it would make sense to do that one by one and not all at the same time as the disk head moves erratically and seek time is wasted time. Because of that I'm now using automatic rebuild mode on the first (root-fs) gmirror slice and will fire a manual re-sync on the others one by one if needed. I guess I'll put that logic in an rc script but gmirror might avoid doing concurrent re-syncs and instead using a queue like behavior. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror RAID-1: rebuilding freezes machine
On 2006-09-07 03:03, Michael Butler wrote: I'm backing out the attached change to see if it fixes it .. Michael Michael, have you had any success using your patch? I was just standing up and couldn't test it. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror RAID-1: rebuilding freezes machine
On 2006-09-07 22:50, Michael Butler wrote: I wrote: I'm backing out the attached change to see if it fixes it .. Nope, not this change .. unfortunately, the machine I have available to test is both remote and in production so I can't pursue it further. I've just detached a drive from the mirror until it gets looked at :-( Michael, if you need me to check any patch, just tell me. My machine is as remote as 2 meters can be... :) Also this machine is important to me (it's a SOHO/Home server, router etc.) but I may test anything on it. If anything is critical to test, I've got another testing only machine which I may deploy quickly. I'm in the european time zone (Germany) so please expect a delay in response. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gmirror RAID-1: rebuilding freezes machine
Hi folks, running at RELENG_6. I've csup'ed and rebuild kernel + world on 2006-09-03 and again on 2006-09-05 because of some trouble (panics related to altq). Because I've experienced some panics (well... not really me who does panic), my gmirror RAID-1 is causing trouble since the kernel + world build done at 2006-09-05. This issue hasn't been experienced with my 2006-09-03 build. Now the issue: The system panics (not related to this problem). Because of the panic, my gmirror RAID-1 is going out of sync. When the machine comes up again, gmirror tries an automatic syncing of the mirror(s). As soon as this is starting, the machine is blocking (keyboard input is ok as long as I'm not going to do something disk-consuming). `gmirror status' says it's rebuilding but in fact there's no disk activity and the HDD LED is constantly ON. The only way out is sometimes CTRL+ALT+DEL, sometimes I need to break to debugger and hard-reset the system. The only way out of this machine freeze is to startup into su-mode, deactivate/remove some gmirror providers and run in degraded mode all time. The machine also does freeze in su-mode as soon as I'm manually trying to re-sync the mirror. So I think I've made sure it's really a gmirror problem. I've seen there have been some cvs commits between 2006-09-03 and 2006-09-05. Are there any changes to take note of? Any configuration changes which I should have done? I'll now go on and rebuild kernel (already done) + world with freshly csup'ed sources, reboot and test once more if gmirror freezes again (will take an hour). Running gmirror with four slices (gm0s1: ad4s1, ad6s1; gm0s2: ad4s2, ad6s2 etc.). Greetings, Volker `gmirror list': Geom name: gm0s1 State: DEGRADED Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 5 ID: 1809089446 Providers: 1. Name: mirror/gm0s1 Mediasize: 9656445952 (9.0G) Sectorsize: 512 Mode: r5w5e5 Consumers: 1. Name: ad4s1 Mediasize: 9656446464 (9.0G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 5 ID: 3309288876 Geom name: gm0s2 State: COMPLETE Components: 1 Balance: round-robin Slice: 4096 Flags: NOAUTOSYNC GenID: 0 SyncID: 2 ID: 1504765676 Providers: 1. Name: mirror/gm0s2 Mediasize: 10733989888 (10G) Sectorsize: 512 Mode: r5w5e6 Consumers: 1. Name: ad4s2 Mediasize: 10733990400 (10G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 2 ID: 2791311183 Geom name: gm0s3 State: COMPLETE Components: 1 Balance: round-robin Slice: 4096 Flags: NOAUTOSYNC GenID: 0 SyncID: 2 ID: 2973128024 Providers: 1. Name: mirror/gm0s3 Mediasize: 28985886208 (27G) Sectorsize: 512 Mode: r5w5e6 Consumers: 1. Name: ad4s3 Mediasize: 28985886720 (27G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 2 ID: 2358433002 Geom name: gm0s4 State: COMPLETE Components: 1 Balance: round-robin Slice: 4096 Flags: NOAUTOSYNC GenID: 0 SyncID: 1 ID: 3151030525 Providers: 1. Name: mirror/gm0s4 Mediasize: 30647392768 (29G) Sectorsize: 512 Mode: r1w1e2 Consumers: 1. Name: ad4s4 Mediasize: 30647393280 (29G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 2328062130 `dmesg': 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 6.1-STABLE #6: Tue Sep 5 01:34:11 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BELLONA WARNING: debug.mpsafenet forced to 0 as i4b_ipr requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: AMIINT VIA_K7 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 2600+ (1832.75-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0480800SYSCALL,MP,MMX+,3DNow+,3DNow real memory = 536805376 (511 MB) avail memory = 515743744 (491 MB) ioapic0 Version 0.3 irqs 0-23 on motherboard wlan: mac acl policy registered ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: AMIINT VIA_K7 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 8377 (Apollo KT400/KT400A/KT600) host to PCI bridge mem 0xe000-0 xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI
Re: gmirror RAID-1: rebuilding freezes machine
On 2006-09-07 00:17, Volker wrote: ... The only way out of this machine freeze is to startup into su-mode, deactivate/remove some gmirror providers and run in degraded mode all time. The machine also does freeze in su-mode as soon as I'm manually trying to re-sync the mirror. So I think I've made sure it's really a gmirror problem. ... I'll now go on and rebuild kernel (already done) + world with freshly csup'ed sources, reboot and test once more if gmirror freezes again (will take an hour). talking to myself... I hate that ;) ok, I've now finished rebuilding world + kernel, installed everything and tried again. In single user mode, the machine does not freeze anymore while trying to rebuild the (any) container. But the rebuild process hangs forever at 0% without any noticeable disk activity. When going into multiuser mode with an auto re-syncing provider, the machine is hanging just right after the the message 'rebuilding provider gm0sN'. But I was able to cancel this by CTRL+C and was back into su mode again. I'll run in degraded mode for the next few hours but I'm now quite sure there's an issue with gmirror. What kind of debugging features may I turn on with gmirror to get a verbose output of what gmirror does? Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: missed hostapd / ath MFC warning?
On 2006-09-04 22:57, Sam Leffler wrote: Volker wrote: ifconfig ath0 says: ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 2290 ether 00:09:5b:89:7d:1f media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid vtec channel 9 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpowmax 30 bmiss 7 protmode CTS burst bintval 100 I just get a 'no carrier' and so no client system is able to see the AP. There's no configuration change just a recently csup'ed and rebuild system. Is there something I've overseen? ath0 is not set in hostap mode. Sam Sam, thanks for your answer... that's it and I've overseen that fact! The strange thing is, I've got that: ifconfig_ath0=inet 192.168.18.2/24 ssid 'vtec' mode 11g mediaopt hostap channel 9 chanlist '1-11' -powersave pureg hidessid wepmode on -apbridge -wme ... (removed a bunch of mac:add entries at the end) in my /etc/rc.conf. After I've manually set the interface into hostap mode, the device was defaulting to channel 36 (11a mode). After manually correcting hostap and 11g mode, everything now works fine again. I'm wondering if there has been something changed at initializing the ath device? Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
missed hostapd / ath MFC warning?
Hi folks, I've recently (september 3rd) csup'ed RELENG_6 and made a buildkernel buildworld process. After the reboot hostapd doesn't work as expected. Did I miss a MFC warning for ath / hostapd? hostapd just says: bellona# hostapd -dd /etc/hostapd.conf Configuration file: /etc/hostapd.conf bsd_set_iface_flags: dev_up=0 bsd_get_ssid: ssid=vtec Using interface ath0 with hwaddr 00:09:5b:89:7d:1f and ssid 'vtec' bsd_set_ieee8021x: enabled=1 bsd_configure_wpa: group key cipher=TKIP (1) bsd_configure_wpa: pairwise key ciphers=0x2 bsd_configure_wpa: key management algorithms=0x2 bsd_configure_wpa: rsn capabilities=0x0 bsd_configure_wpa: enable WPA= 0x1 bsd_set_iface_flags: dev_up=1 bsd_set_privacy: enabled=1 WPA: group state machine entering state GTK_INIT GMK - hexdump(len=32): 33 e9 d7 a0 86 d2 4f 23 5b a8 21 f7 ed ef cf 57 ae 2b 29 5e 8e 5e 91 a8 92 9b 0b dd fa 10 28 ac GTK - hexdump(len=32): 8e 9c 18 a4 59 ca 79 bc 04 01 9f e2 82 a5 5b 17 94 d7 fd e8 e2 7e 65 30 bf de 9b 5f 9b 72 b3 f5 WPA: group state machine entering state SETKEYSDONE bsd_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1 Flushing old station entries bsd_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 Deauthenticate all stations .and all looks fine. ifconfig ath0 says: ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 2290 ether 00:09:5b:89:7d:1f media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid vtec channel 9 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpowmax 30 bmiss 7 protmode CTS burst bintval 100 I just get a 'no carrier' and so no client system is able to see the AP. There's no configuration change just a recently csup'ed and rebuild system. Is there something I've overseen? Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portupgrade failed - /var/db/pkg/pkgdb.db: unexpected file type or format
On 12/23/-58 20:59, Dominik Zalewski wrote: I'm using FreeBSD 6.1-stable . Today I updated my ports tree using cvsup and then I ran as usually portupgrade -a . It upgraded my portupgrade to version portupgrade-2.1.3.2,2. After that portupgrade stopped working. in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Dominik, I've had the same today and thought it has been my mistake (doing a pkg_version in parallel). Just delete /var/db/pkg/pkgdb.db and run `pkgdb -F' and all should be fine. At least on my system I was able to rebuild pkgdb.db that way and all is working again. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendmail-sasl port not work
* Paul.LKW [EMAIL PROTECTED]: Dear all: I find the sendmail-sasl port will not compile with the option SASLv2 and I can not get SMTP Auth. The port will install TLS and Cyrus-SASL but as I use the command --sendmail -d0.1 -bv root | grep SASL-- I can not find it compiled with SASL. Did you follow the instructions in /usr/ports/mail/sendmail/pkg-message and invoke the right sendmail (ie. preferably with full path in case you're unsure)? Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME FIFA go home! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
{Spam?} Re: problems with an SATA drive on nVidia3 controller
Hello! We have an amd64 machine with an nVidia3 SATA controller on motherboard. [...] ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=249306496 ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=261467776 ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=273629312 ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=273629312 Is this controller working for others? We connected the disk to it in preference to the Silicon Image connectors, which are also present on-board, because SI has poor reputation :-( Is this controller supposed to work? Thanks! -mi Mikhail, I've had a similar problem (or probably still have). Someone answered to my post this might be a SATA-cable problem and this seems to be true. As far as I'm aware of the ICRC error message might be a hint to an interface problem. The system(s) I was seeing this kind of problem are providing SATA on board (VIA 6420). Whenever the problem occurs, the drive isn't being seen by the OS anymore until a reboot (atacontrol list doesn't show the failed drive anymore) and SMART shows DMA error and ICRC error messages. I really guess it's a cable problem. On the other side I've seen this problem only on RELENG_6_0 systems (but this does not say it's a FreeBSD problem). AsRock (the mainboard manufacturer) also asked me to change the SATA cable and they told me to change the disks jumper settings of the failed drive to run on SATA150 (if it's a SATA300 disk). Because my troubled box is remote, I've been unable to check those both suggestions. Probably you may check that first if it solves your problem. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
SATA drive 1 disappears
Dear list, I've seen GEOM mirror error messages at two nearly identical systems. Both are running on Asrock K7VT4xx (VIA chipset) boards and having two SATA drives connected (Hitachi HDS728080PLA380/PF2OA60A). On both systems we're using gmirror RAID-1 per slice. After same weeks of productional use, on both systems the first disc (ad4) within the RAID set came out with error messages like: +ad4: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=127199808 +ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=10968959 +ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=10968959 +ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=118404223 +ad4: FAILURE - WRITE_DMA timed out LBA=10968959 +GEOM_MIRROR: Request failed (error=5). ad4s1[WRITE(offset=5616074752, length=16384)] +GEOM_MIRROR: Device gm0s1: provider ad4s1 disconnected. +ad4: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=118404223 +ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=122117983 +ad4: FAILURE - WRITE_DMA timed out LBA=118404223 ... +subdisk4: detached +ad4: detached +GEOM_MIRROR: Device gm0s2: provider ad4s2 disconnected. +GEOM_MIRROR: Request failed (error=5). ad4s2[READ(offset=8987662336, length=2048)] After these messages the disc isn't seen by the system anymore: atacontrol list ATA channel 0: Master: acd0 NEC DVD RW ND-3540A/1.01 ATA/ATAPI revision 0 Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: no device present Slave: no device present ATA channel 3: Master: ad6 HDS728080PLA380/PF2OA60A Serial ATA v1.0 Slave: no device present The (S)ATA controller and devices is being detected at startup as: +atapci0: VIA 6420 SATA150 controller port +atapci1: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f +ad4: 78533MB HDS728080PLA380 PF2OA60A at ata2-master SATA150 +ad6: 78533MB HDS728080PLA380 PF2OA60A at ata3-master SATA150 +GEOM_MIRROR: Device gm0s1 created (id=613166686). +GEOM_MIRROR: Device gm0s1: provider ad4s1 detected. +GEOM_MIRROR: Device gm0s2 created (id=91558579). +GEOM_MIRROR: Device gm0s2: provider ad4s2 detected. +GEOM_MIRROR: Device gm0s1: provider ad6s1 detected. +GEOM_MIRROR: Device gm0s1: provider ad6s1 activated. +GEOM_MIRROR: Device gm0s1: provider ad4s1 activated. +GEOM_MIRROR: Device gm0s1: provider mirror/gm0s1 launched. +GEOM_MIRROR: Device gm0s2: provider ad6s2 detected. +GEOM_MIRROR: Device gm0s2: provider ad6s2 activated. +GEOM_MIRROR: Device gm0s2: provider ad4s2 activated. +GEOM_MIRROR: Device gm0s2: provider mirror/gm0s2 launched. The RAID set is now running degraded. Both systems are running on R 6.0. I know it's more like guesswork, but what might be the reason for these disc errors? Are the discs really dying? When rebooting the system(s) the first disc re-appears for a few days and will disappear again later. The hdu connectors have been checked. Is there something wrong with gmirror, geom or the controller driver? What makes me scratching my head is on both systems just the first disc is dying. I've found postings from one year ago and the conclusion was faulty hardware. Are there any signs for geom or driver problems? `uname -a': FreeBSD GwOsl 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Nov 30 02:41:47 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GwOsl i386 Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
On Friday 03 March 2006 23:45, Mark Kirkwood wrote: I would certainly see the installer handling software RAID as a considerable benefit. From what I've seen on the net, to install and boot off RAIDed system disks is quite fiddly (maybe gmirror is the exception here, as I've mainly been looking at striping). Cheers Mark geom changed this complications definitely, using gmirror or gstripe commands is easy as copying a file. Probably one of the most important things that with vinum as example it was not possible to mirror a root partition but since gmirror places the metadata different we can have now a mirrored and bootable root partition. Striping with ccd and vinum or mirroring was certainly a pain even if it worked then stable and reliable. So in comparism the easy use of geom is great and the people which developed geom did a really fantastic job. João Joao, I do agree that gmirror is not that bad and not that difficult. But take a look at how to setup a fresh system using gmirror (slice by slice mirroring): - install a complete system to a fresh disc - create the (well sized) slices on a 2nd disc (not that easy) - create the gmirror set on disc 2 - bring gmirror up - copy all filesystems over to the gmirror set - reboot - create exactly sized slices on disc 1 - insert everything into the gmirror set Using that procedure you're going to copy each installed file three times (install, copy to mirror, sync mirror). That's a waste of time compared to a solution where the installer would be able to install directly into a mirror. When using disc based gmirror (instead of per slice gmirror) the procedure is a bit easier, but similar. If one could create a gmirror set before installing the base system and tell the installer to install into gmX instead of adX/daX, the whole procedure would be much easier and would take less time. I've had to setup a handful of fresh systems over the last months and it was a pain to manually setup gmirror on each fresh system. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
Patrick, On 2006-03-07 13:45, Patrick M. Hausen wrote: . Are there instructions on how to do this to mirror a slice instead of an entire disk? Thanks, Patrick Yes, Ralf S. Engelschall created a good guide: http://people.freebsd.org/~rse/mirror/ See 'GEOM mirror Approach 2: Single Slice, Preferred, More Flexible' Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fresh install on gmirror'ed disks?
Patrick, On 2006-03-07 14:22, Patrick M. Hausen wrote: Hello! On Tue, Mar 07, 2006 at 01:56:57PM +0100, Volker wrote: Patrick, On 2006-03-07 13:45, Patrick M. Hausen wrote: . Are there instructions on how to do this to mirror a slice instead of an entire disk? Thanks, Patrick Yes, Ralf S. Engelschall created a good guide: http://people.freebsd.org/~rse/mirror/ See 'GEOM mirror Approach 2: Single Slice, Preferred, More Flexible' I _know_. This guide was first mentioned by me in this thread. But it assumes - install - boot - create mirror on second disk - copy data - reboot - sync mirror Now Joao said, creating a mirrored disk can be done from the emergency holographic shell at install time. OK, fine. Spares the copying. My question was: can I create a mirrored slice instead of a mirrored disk without copying the data at install time from the emergency shell? Otherwise I will still have to use Ralf's instructions, which are a bit more work to follow. Thanks, Patrick As far as I understand Joao's solution, he's mentioning disc mirroring (disc in a whole). When using slice mirroring I don't see a simple solution and RSE's paper is the only way to go. Anybody please correct me if I'm wrong. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ppp HDLC errors
Dear list members, I'm trying to get a 3g / UMTS connection to work on my RELENG_6 (i386, AMD Sempron) machine. I've installed a Novatel Merlin U630 card (pcmcia) which is providing a hayes serial modem to the system (on sio4 in my case). Dialing works fine but most DNS queries are timing out, but also most tcp sessions won't work. While in ppp (userland) I'm seeing messages like: Phase: deflink: HDLC errors - FCS: 28, ADDR: 0, COMD: 0, PROTO: 0 Phase: deflink: HDLC errors - FCS: 27, ADDR: 0, COMD: 0, PROTO: 0 Phase: deflink: HDLC errors - FCS: 102, ADDR: 0, COMD: 0, PROTO: 0 Phase: deflink: HDLC errors - FCS: 25, ADDR: 0, COMD: 0, PROTO: 0 Phase: deflink: HDLC errors - FCS: 9, ADDR: 0, COMD: 0, PROTO: 0 Phase: deflink: HDLC errors - FCS: 10, ADDR: 0, COMD: 0, PROTO: 0 Later I'm seeing message like that on the console screen: sio4: 152599 more interrupt-level buffer overflows (total 152599) I've tried increased and decreased the baud rate in ppp but the same appears. dmesg for the devices involved: cbb0: RF5C475 PCI-CardBus Bridge at device 13.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 pccard0: Allocation failed for cfe 7 sio4: Novatel Wireless Merlin UMTS Modem at port 0x2f8-0x2ff irq 17 function 0 config 15 on pccard0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode pccard0: Allocation failed for cfe 7 pccard0: Allocation failed for cfe 15 sio5: Novatel Wireless Merlin UMTS Modem at port 0x2e8-0x2ef irq 17 function 1 config 23 on pccard0 sio5: type 16550A sio5: unable to activate interrupt in fast mode - using normal mode It's a RELENG_6 machine with a recent kernel (compiled yesterday with kernel sources from Feb-26). The same appears whether or not SMP kernel is being used. I've been unable to find anything in the archives closely related. The card works fine under Win2k (on a different machine). The RELENG_6 machine is using a PCI-PCMCIA adapter. Any hint is welcome! :) Is there a workaround? Should I go with pppd or mpd? Do you need any more info on that? Is there something more I might check out? What about the dmesg messages: pccard0: Allocation failed for cfe 7 sio4: unable to activate interrupt in fast mode - using normal mode As always, thanks a lot for your help! Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp HDLC errors
On 2006-03-01 17:35, Holger Kipp wrote: On Wed, Mar 01, 2006 at 04:19:37PM +0100, Volker wrote: Dear list members, I'm trying to get a 3g / UMTS connection to work on my RELENG_6 (i386, AMD Sempron) machine. I've installed a Novatel Merlin U630 card (pcmcia) which is providing a hayes serial modem to the system (on sio4 in my case). Dialing works fine but most DNS queries are timing out, but also most tcp sessions won't work. While in ppp (userland) I'm seeing messages like: I had a similar problem with PCI-800H card. Later I'm seeing message like that on the console screen: sio4: 152599 more interrupt-level buffer overflows (total 152599) Have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=51982 maybe it is related. You could change sio.c and increase cp4ticks by factor of 10, then recompile your kernel and see if it helps. Thanks for that pointer - it DID help! :) But multiplying cp4ticks by factor 10 didn't do it. I've set HZ=1000 in my kernel config and first tried the PR suggested value. Then I tried the second PR suggested solution which was a bit better but still produced error messages. I've now set: cp4ticks = speed / 10 / 100 * 160 so I multiplied the default value by 40 (not just by 10) and the ppp HDLC error messages and the interrupt kernel messages went away. I've seen the error messages and bad behaviour even at 'low' baud rates of 57600 kbit/s. With my mods I'm now running at 230400 kbit/s and don't see the error messages anymore. have you activated rtscts-flowcontrol (see /etc/rc.d/serial) for sio4? Now I did it but just after making sure it doesn't mask my true problem. But on the other hand I've already told ppp to use ctsrts before. It's a RELENG_6 machine with a recent kernel (compiled yesterday with kernel sources from Feb-26). sio4: unable to activate interrupt in fast mode - using normal mode this might be if sio4 shares its irq with other resources... Yes it does. I would have to move PCI cards to change irq assignment. But as long as it works, I don't care about irq sharing and now it seems to work. Again, thank you for your hint! It saved me some more hours. Greetings, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH login takes very long time...sometimes
* Atanas [EMAIL PROTECTED]: I really miss the inetd features. A setting like nowait/100/20/5 (/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]) would effectively bounce the bad guys, but AFAIK (correct me if I'm wrong), ssh is no longer supposed to work via inetd and still has no such capabilities. We're succesfully running openssh-portable from inetd with: ssh stream tcp nowait/0/12 root/usr/local/sbin/sshdsshd -i -f /etc/ssh/sshd_config [EMAIL PROTECTED] grep ssh /var/log/messages Feb 14 02:15:04 lambda inetd[19345]: ssh from 62.81.185.120 exceeded counts/min (limit 12/min) Feb 14 02:15:04 lambda inetd[19345]: ssh from 62.81.185.120 exceeded counts/min (limit 12/min) Feb 14 16:43:15 lambda inetd[19345]: ssh from 220.130.23.134 exceeded counts/min (limit 12/min) ... I'd also recommend pam_af for locking out brute-forcers: http://mbsd.msk.ru/pam_af.html For example we have: host hostname='tin.cn.ee.ccu.edu.tw' attempts9/attempts last_attemptMon Nov 7 15:05:50 2005/last_attempt statuslocked/status /host [EMAIL PROTECTED] sudo pam_af_tool statlist | grep locked | wc -l 363 Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME All the excitement lies in pattern matching. (SPJ et al.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cool 'n quiet and other AMD stuff
* Graham North [EMAIL PROTECTED]: 1) Is the AMD Cool 'n quiet feature (PowerNow) feature supported while running i386 FBSD on this AMD64 processor? (Assuming MB support). Maybe this will work: http://www.freshports.org/sysutils/fvcool/ -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME It's a million to one chance, but it just might work. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
OT: adding bugs
Quote from bsdnews.org: FreeBSD Core Team's Robert Watson says he has added lots of minor bugs in the POSIX FIFO code fifofs. Great announcement... :) -- GPG/PGP fingerprint: FF93 13A1 2477 B631 E953 06DF 4C49 ADD9 E4BF 79B1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
releng_6 sysinstall creating labels
Hi! I guess I found a (new?) issue with RELENG_6 (as of 2005-08-23). When creating slices and labels by using /stand/sysinstall, the label editor is miscalculating the partition sizes. While having a (SCSI) disk outage yesterday night, I've been forced to put in a new hdu. After labeling it by using sysinstall, sysinstall aborted at creating the partitions and the filesystems. Error message has been 'unable to write to da5'. After that I found that sysinstall created a partition which exceeded past the end of the slice. As far as I remember it has been 16 bytes past the end of the slice, but my memories might be wrong. Because I've been unable to backup my data to tape (another issue with scsi cam, but I have to check that first before posting), I installed another 18G hd, created a slice and a partition by using sysinstall covering the whole disk and even that failed by a partition exceeding the end of the slice. Manual corrections by using bsdlabel -e and manually newfs'ing went ok. This must be an issue with sysinstall and should be fixed before -RELEASE or someone might not be able to install from CDROM because not being able to create filesystems (don't you consider that being a show stopper?). I'm unable to check if this is a SCSI only issue but I guess it should be re-creatable on ata systems. Sorry, but I don't have any other examples for that issue or any dumps, screenshots etc. I had that hd-crash last night and tried to solve that first. I might try to recreate that problem on a testing machine at the weekend and give exact information. Bye, Volker -- GPG/PGP fingerprint: FF93 13A1 2477 B631 E953 06DF 4C49 ADD9 E4BF 79B1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: releng_6 sysinstall creating labels
Hi Andrey, uups... seems like you're right. My /stand/sysinstall is dated back to the days where I've been running RELENG_4. So please ignore my first posting... sorry! Volker On 2005-08-26 13:16, Andrey V. Elsukov wrote: Volker wrote: When creating slices and labels by using /stand/sysinstall, the label editor is miscalculating the partition sizes. Maybe, you must use /usr/sbin/sysinstall ? -- GPG/PGP fingerprint: FF93 13A1 2477 B631 E953 06DF 4C49 ADD9 E4BF 79B1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_6 periodic security default problem
Hi folks,
since running on RELENG_6 starting last week on my home server, I'm not
getting any useful periodic security output anymore.
After inspecting the problem I found that the default of
daily_status_security_diff_flags in /etc/defaults/periodic.conf is -b
-u but the ${filter} expression in /etc/periodic/security.functions is
being set to grep '^'
diff produces a +/- diff format but the output is being filtered for ^
so no output comes from any of the /etc/periodic/security scripts. This
should be either changed to daily_status_security_diff_flags=-b in
/etc/defaults/periodic.conf or ${filter} being changed to 'grep ^+' in
/etc/periodic/security/security.functions.
Bye,
Volker
--
GPG/PGP fingerprint:
FF93 13A1 2477 B631 E953 06DF 4C49 ADD9 E4BF 79B1
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2.1 - Freenet6 TSPC Client dumps core
* Karl M. Joch [EMAIL PROTECTED]: i had the verion 1 of the freenet6 client running for a long time. now, after upgrading to 2.1.1 on a 5.2.1 box the tspc client dumps core. What does the coredump say? Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Asus P4P800 SE RAID1 on Intel ICH5 not working
Hi Niels! If that's not working (I don't know anything about ICH5) you may use atacontrol to create a RAID1. I've set this up on two Dell PE 750 machines with each having two 80 GB SATA disks and it's working perfect. Greetings, Volker Hi, I want to use the RAID1 on this ASUS mobo. I've configured it as RAID1 in the bios, but BSD53 just sees two discs and not a RAID1 array. (ad4 and ad6). The drives are two identical Maxtor 80Gb SATA discs. Any special things I need to do? NIels -- GPG/PGP fingerprint: FF93 13A1 2477 B631 E953 06DF 4C49 ADD9 E4BF 79B1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI0680 ATA RAID question
On Wed, Nov 17, 2004 at 04:03:50PM +0200, Dmitry Pryanishnikov wrote: In 5.3-RELEASE ERRATA I see the following: (1 Nov 2004) ATA RAID support for the CMD649 and SiI0680 ATA controllers is non-functional in this release. When such a controller is brough up under ata(4) (ataraid) on 5.3, the RAID configuration stored under 5.2 or prior may be corrupted. am i getting this right: a raid config stored under 5.3 will probably not get corrupted??? What's the reason of the problem with SiI0680: inferiority of the hardware or just programming error? Is this problem fixed in 6-CURRENT? If so, will this fix be merged to 5-STABLE? as i had problems with an nfs-server (with SiI0680) running 5.2 for no obvious reason, i upgraded to 5.3 - and did not encounter the above mentioned problem since the release of 5.3 to date. i had to recreate my raid configuration, though, which seemed not to harm my data. (like this: atacontrol create RAID1 ad4 ad6) is this the expected behaviour: doesn't recognise raids created under 5.2, but works fine with raids created under 5.3? wondering, Volker. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
natd same_ports
Hi folks! Running natd under 5.3-RELEASE I've seen natd doesn't touch the port numbers - natd let packets pass with the same port numbers. I've tried setting the -same_ports natd option to no but natd behaviour doesn't change. From what I've found in the natd sources (/usr/src/sbin/natd/natd.c) the command line option for -same_ports never gets processed. It's my believe there's been some code forgotten in natd.c but I'm not quite sure. Would please the maintainer or a core member check the natd.c source for the processing and correct defaults of natds' -same_ports option? Function ParseOption doesn't show any processing of this parameter. From my experience with natd under 5.3 I would say, natd isn't working as expected for the source port numbering. Thanks, Volker -- GPG/PGP fingerprint: FF93 13A1 2477 B631 E953 06DF 4C49 ADD9 E4BF 79B1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld stops at -lssh
Hi, building shared library pam_ssh.so /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot find -lssh *** Error code 1 I encountered the same problem yesterday afternoon. After defining src-all in the cvsupfile cvsup fetched more files (crypto) and today it compiled without errors. Hope that helps -volker To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: umass/memory stick
On Tue, Mar 26, 2002 at 12:01:38AM +, Josef Karthauser wrote:
The patch applies cleanly, but the problem persists. Do I have to wibble a
knob or something?
No; if it doesn't work then we'll probably need a code quirk in there.
Okay, I've got the quirk, and it works now, although the pattern is rather coarse:
{T_DIRECT, SIP_MEDIA_REMOVABLE, RiteLink*, *,*},
/*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
Where do I derive the second pattern from?
Another thing: If the stick is connected at boot time, I get:
umass0: BBB reset failed, TIMEOUT
umass0: BBB bulk-in clear stall failed, TIMEOUT
umass0: BBB bulk-out clear stall failed, TIMEOUT
umass0: BBB reset failed, TIMEOUT
and then the port got disabled :-/
--
Wonderful \hbox (0.80312pt too nice) in paragraph at lines 16--18
Volker Stolz * [EMAIL PROTECTED]
Please use PGP or S/MIME for correspondence!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
sendmail hanging on ::1
[This remained unanswered on -questions] I have one sendmail process sitting here in a tight nanosleep() loop on 4.5-STABLE and I don't know why: [All output slightly trimmed] erde:[vs] ps auxww | grep sendm root 29275?? STue01PM 94:03.88 sendmail: ./g1QC72529275 localhost.ikea.net [::1]: DATA (sendmail) root 233?? Ss 24Feb02 1:05.45 sendmail: accepting connections (sendmail) root 29274?? ITue01PM 0:00.04 sendmail: server localhost.ikea.net [::1] child wait (sendmail) root 29276?? STue01PM 10:45.85 sendmail: ./g1QC72529275: from queue (sendmail) Additionally, 'lsof' show various incarnations of sendmail 29275 root1u IPv60t0 TCP can't read in6pcb at 0x Although it isn't the plain sendmail.cf as shipped with FreeBSD, I just includes minimal changes from the default setup. Any help on tracking this down, including further tips where to look for more debugging output is appreciated! -- Wonderful \hbox (0.80312pt too nice) in paragraph at lines 16--18 Volker Stolz * [EMAIL PROTECTED] Please use PGP or S/MIME for correspondence! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
