Re: What happened to DVD writing?
Zaphod Beeblebrox (21:12 2009-09-20): On Sun, Sep 20, 2009 at 4:35 PM, Richard Mahlerwein mahle...@yahoo.comwrote: I have had several exhibit behavior even more odd. The most unusual was this particular CD writer... It read both DVDs and CDs but would write neither (it had worked fine the week before). I took it out of the drive bay and hooked it to another PC to test and it worked fine there. I put it back in the original PC and it failed. I was swapping things around on that PC (assuming bad cable, bad power, etc) and had it sitting loose on the desk and found that it now worked again. Put it back in the drive cage and it again would not write, though reading was fine. Anyway, I finally figured out that even slight pressure in on the sides where it mounts would make it fail to burn CDs. The cage itself exerted a bit of pressure and that was enough to make it fail at any attempt to burn a CD. This is not necessarily odd. The CD burner is one of the highest draw bits in your system... save possibly your CPU and/or graphics card (depending on what they are). I have found that various DVD drives have been very sensitive to power supply voltages and fail to burn properly when they're marginal. Your description here seems to point in that direction. If it works in computer B, try using B's power supply for A --- or maybe B has other lighter draws. Power supplies can also degrade over time --- especially if you have some cheap capacitors in there. I find the DVD drive is often the canary for spotting power supply problems. Hi, I have the same problem. I can read DVDs and CDs and write CDs, but I'm unable to write DVDs. I can't be sure that it is a software problem, but I think it happened when upgrading from 8.0-BETA2 to 8.0-BETA4. Not sure at all though. Martin ___ 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: SASL problems with spnego on 8.0-BETA4
John Marshall wrote: On Sat, 19 Sep 2009, 09:31 +1000, John Marshall wrote: On Fri, 18 Sep 2009, 17:38 -0400, Rick Macklem wrote: When cyrus-sasl2 builds, it uses the little shell script /usr/bin/krb5-config with the args. --libs gssapi to get the list of libraries to link against. This doesn't return -lgssapi_spnego in the list. (The list can be changed by editting line #96 of /usr/bin/krb5-config.) I think this sounds promising! It makes sense. Thanks for pointing us in this direction. This morning, on my 8.0-RC1 system, I did the following to confirm that GSSAPI authentication to the LDAP server via SASL2 using the base Heimdal was still broken: - removed the heimdal-1.2.1 port - rebuilt the cyrus-sasl-2.1.23 port (against the base heimdal) - started the openldap-sasl-server-2.4.18_1 - queried the LDAP server from a separate client using ldapsearch: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) - and noted that the ldap server died at that point. I edited line 96 of /usr/bin/krb5-config to include -lgssapi_krb5 in the libraries list: lib_flags=$lib_flags -lgssapi -lgssapi_krb5 -lheimntlm and then did the following: - rebuilt the cyrus-sasl-2.1.23 port (against the base heimdal) - started the openldap-sasl-server-2.4.18_1 - queried the LDAP server from a separate client using ldapsearch SASL/GSSAPI authentication started SASL username: j...@example.com SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 SUCCESS! So, this fix obviates THAT reason for installing the Heimdal port. If George meets with similar success adding -lgssapi_spnego for his spnego problem, I suggest that both libraries be added to the list in line 96 of /usr/bin/krb5-config prior to release of FreeBSD 8.0. It doesn't look like this fix is as simple as submitting a patch to krb5-config. It looks like magic needs to happen somewhere in the base kerberos build system. I notice that the Heimdal port doesn't build the separate libraries and everything seems to be included in libgssapi (which explains why sasl2 works when linked against the Heimdal port). Guys, I changed my /usr/bin/krb5-config's line 96 to include -lgssapi_spnego and -lgssapi_krb5, and ever since both client and server work correctly!! Of course I get some other error, but at least this must be a configuration error :). So, to sum up: Still running on fbsd.8-BETA4, changed krb5-config to include the missing libraries, recompiled cyrus-sasl-2.1.23 after I changed the krb5-config, restarted openldap-sasl-server-2.4.18_1 and after performing an ldapsearch, the client does not complain (and exits) about missing libraries, NOR does the server crash on sasl authentication. Great job guys, thank you all very very much for your help! I posted my query on the 17th of Sep. and in four days (weekend inclusive!) someone came up with an answer that resolves my issue! Great job, once more, and thank you all again! -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ 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
FreeBSD 7.2-STABLE boot freeze when calibrating clock.
Hi. I have recently upgraded the server from 6.X - Latest 6.X - 7.2. But after the upgrade it boots OK once and after that it freezes. Verbose boot give me these lines: snip Copyright (c) 1992-2009 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 7.2-STABLE #2: Fri Sep 18 13:22:40 CEST 2009 r...@gs4:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc0e7e000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0e7e1d8. Calibrating clock(s) ... i8254 clock: 1193116 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... snap I can boot the system without ACPI enabled w/o problem. But once it is enabled it will freeze at this point. This has happend on both servers I have upgraded. Both of them are identical. /Bjorn Full dmesg w acpi disabled: %dmesg Copyright (c) 1992-2009 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 7.2-STABLE #2: Fri Sep 18 13:22:40 CEST 2009 r...@gs4:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 285 (2605.93-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20f12 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x2CMP Cores per package: 2 real memory = 3221192704 (3071 MB) avail memory = 3146604544 (3000 MB) MPTable: HP PROLIANT FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic2: Assuming intbase of 28 ioapic3: Assuming intbase of 32 ioapic4: Assuming intbase of 36 ioapic0 Version 1.1 irqs 0-23 on motherboard ioapic1 Version 1.1 irqs 24-27 on motherboard ioapic2 Version 1.1 irqs 28-31 on motherboard ioapic3 Version 1.1 irqs 32-35 on motherboard ioapic4 Version 1.1 irqs 36-39 on motherboard kbd1 at kbdmux0 pcib0: Host to PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: MPTable PCI-PCI bridge at device 3.0 on pci0 pci1: PCI bus on pcib1 ohci0: OHCI (generic) USB controller mem 0xf7df-0xf7df0fff irq 19 at device 0.0 on pci1 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: OHCI (generic) USB controller mem 0xf7de-0xf7de0fff irq 19 at device 0.1 on pci1 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: OHCI (generic) USB controller on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 3 ports with 3 removable, self powered pci1: base peripheral at device 2.0 (no driver attached) pci1: base peripheral at device 2.2 (no driver attached) vgapci0: VGA-compatible display port 0x4400-0x44ff mem 0xf600-0xf6ff,0xf5ff-0xf5ff0fff at device 3.0 on pci1 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD 8111 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] pci0: bridge at device 4.3 (no driver attached) pcib2: MPTable PCI-PCI bridge at device 7.0 on pci0 pci2: PCI bus on pcib2 ciss0: HP Smart Array 6i port 0x5000-0x50ff mem 0xf7ef-0xf7ef1fff,0xf7e8-0xf7eb irq 24 at device 4.0 on pci2 ciss0: [ITHREAD] pcib3: MPTable PCI-PCI bridge at device 8.0 on pci0 pci3: PCI bus on pcib3 bge0: HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100 mem 0xf7ff-0xf7ff irq 28 at device 6.0 on pci3 miibus0: MII bus on bge0 brgphy0: BCM5704 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:17:a4:8d:f9:2a bge0: [ITHREAD] bge1: HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100 mem 0xf7fe-0xf7fe irq 29 at device 6.1 on pci3 miibus1: MII bus on bge1 brgphy1: BCM5704 10/100/1000baseTX PHY PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:17:a4:8d:f9:29 bge1: [ITHREAD] cpu0 on motherboard powernow0:
8.0-RC1 Available
The first of the Release Candidates for the FreeBSD 8.0 release cycle is now available. How many RC's we have will depend on how well 8.0-RC1 does. At the moment only one more RC is on the schedule but odds are fairly high we will wind up inserting at least one more RC. Between BETA4 and RC1 a lot of work has gone into IPv6 issues as well as many other issues that have been brought up from the public testing. And a patch set was committed by the people who handle porting ZFS to FreeBSD that they felt makes ZFS production-ready. Details about the current target schedule along with much more detail about the current status of the release is available here: http://wiki.freebsd.org/8.0TODO There are two known problems with 8.0-RC1. One known issue with the 8.0-RC1 build was discovered after the builds got started so is not part of the ISO images or FreeBSD-Update builds. The issue is that local IPv6 link-local addresses are not reachable. A fix for it has been committed to RELENG_8 so if you install from the 8.0-RC1 media or update using FreeBSD-Update you will then need to update using csup/cvsup mechanisms if you need that fix for your environment. It should only impact people using IPv6. The other known issue is that the flowtable may direct packets to the wrong interface under certain routing conditions. We feel confident that this bug will be fixed so the flowtable is enabled in RC1 to maximize testing. If you experience routing problems, please temporarily disable the flowtable using the sysctl =0 and report the results to the freebsd-current@ mailing list. If we are unable to resolve this issue by RC2, we will disable the flowtable in 8.0-RELEASE. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is about to become a stable branch but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a memory stick image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages this time but no other packages. The DVD image includes a rough pass at what packages will be available on the official release media but is subject to change between now and release. For sparc64 the DVD image has the set of packages that currently build for sparc64, which is a sub-set of the set provided for amd64/i386. The sparc64 disc1 does not have any packages on it because I noticed a little too late that adding the doc packages to disc1 caused it to overflow the target size. For 8.0-RC2 sparc64 will have the livefs bits split out to a separate image (which is the way all the other architectures have been for a while now) and the doc packages will be provided on disc1. None of the other images include packages. If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, or 8.0-BETA4 can upgrade as follows: # freebsd-update upgrade -r 8.0-RC1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 8.0-RC1: # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC1-amd64-bootonly.iso) = a84d43c8adaba3fee9a618098668154e MD5 (8.0-RC1-amd64-disc1.iso) = fb4f75c74144239b4994dc3ad040af33 MD5 (8.0-RC1-amd64-dvd1.iso) = 5da3097634fbe049dd01ad4127d0f396 MD5 (8.0-RC1-amd64-livefs.iso) =
Re: What happened to DVD writing?
From: Zaphod Beeblebrox zbee...@gmail.com Subject: Re: What happened to DVD writing? To: mahle...@yahoo.com Cc: sta...@freebsd.org Date: Sunday, September 20, 2009, 9:12 PM On Sun, Sep 20, 2009 at 4:35 PM, Richard Mahlerwein mahle...@yahoo.comwrote: I have had several exhibit behavior even more odd. The most unusual was this particular CD writer... It read both DVDs and CDs but would write neither (it had worked fine the week before). I took it out of the drive bay and hooked it to another PC to test and it worked fine there. I put it back in the original PC and it failed. I was swapping things around on that PC (assuming bad cable, bad power, etc) and had it sitting loose on the desk and found that it now worked again. Put it back in the drive cage and it again would not write, though reading was fine. Anyway, I finally figured out that even slight pressure in on the sides where it mounts would make it fail to burn CDs. The cage itself exerted a bit of pressure and that was enough to make it fail at any attempt to burn a CD. This is not necessarily odd. The CD burner is one of the highest draw bits in your system... save possibly your CPU and/or graphics card (depending on what they are). I have found that various DVD drives have been very sensitive to power supply voltages and fail to burn properly when they're marginal. Your description here seems to point in that direction. If it works in computer B, try using B's power supply for A --- or maybe B has other lighter draws. Power supplies can also degrade over time --- especially if you have some cheap capacitors in there. I find the DVD drive is often the canary for spotting power supply problems. Sorry, the kids woke up from naps and I sent without realizing I hadn't quite finished. Yes, you are completely correct. There was another story where it was a power supply that was inadequate (should have been, but it was aged and seemed to just run out of steam earlier than it used to). Anyway, the point I intended to make and forgot to was that in this case I'd confirm that the DVD drive itself is OK by popping it into another PC, if one is available. If it fails in a different known-OK PC it is likely to be a hardware problem. If it works OK there, try a different power cable on your existing PC, or try swapping out the power supply if you can. You could also try just disconnecting any other power-hungry yet unneeded items temporarily (like additional CD/DVD readers/writers or that old 6x 9GB drive SCSI2 RAID array :), if you have any. ___ 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: 8.0-RC1 Available
On Mon, 21 Sep 2009, Ken Smith wrote: The first of the Release Candidates for the FreeBSD 8.0 release cycle is now available. How many RC's we have will depend on how well 8.0-RC1 does. At the moment only one more RC is on the schedule but odds are fairly high we will wind up inserting at least one more RC. Between BETA4 and RC1 a lot of work has gone into IPv6 issues as well as many other issues that have been brought up from the public testing. And a patch set was committed by the people who handle porting ZFS to FreeBSD that they felt makes ZFS production-ready. Details about the current target schedule along with much more detail about the current status of the release is available here: http://wiki.freebsd.org/8.0TODO There are two known problems with 8.0-RC1. One known issue with the 8.0-RC1 build was discovered after the builds got started so is not part of the ISO images or FreeBSD-Update builds. The issue is that local IPv6 link-local addresses are not reachable. A fix for it has been committed to RELENG_8 so if you install from the 8.0-RC1 media or update using FreeBSD-Update you will then need to update using csup/cvsup mechanisms if you need that fix for your environment. It should only impact people using IPv6. The other known issue is that the flowtable may direct packets to the wrong interface under certain routing conditions. We feel confident that this bug will be fixed so the flowtable is enabled in RC1 to maximize testing. If you experience routing problems, please temporarily disable the flowtable using the sysctl =0 and report the results to the That should be sysctl net.inet.flowtable.enable=0 freebsd-current@ mailing list. If we are unable to resolve this issue by RC2, we will disable the flowtable in 8.0-RELEASE. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is about to become a stable branch but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a memory stick image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages this time but no other packages. The DVD image includes a rough pass at what packages will be available on the official release media but is subject to change between now and release. For sparc64 the DVD image has the set of packages that currently build for sparc64, which is a sub-set of the set provided for amd64/i386. The sparc64 disc1 does not have any packages on it because I noticed a little too late that adding the doc packages to disc1 caused it to overflow the target size. For 8.0-RC2 sparc64 will have the livefs bits split out to a separate image (which is the way all the other architectures have been for a while now) and the doc packages will be provided on disc1. None of the other images include packages. If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, or 8.0-BETA4 can upgrade as follows: # freebsd-update upgrade -r 8.0-RC1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 8.0-RC1: # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC1-amd64-bootonly.iso) = a84d43c8adaba3fee9a618098668154e MD5 (8.0-RC1-amd64-disc1.iso) = fb4f75c74144239b4994dc3ad040af33 MD5 (8.0-RC1-amd64-dvd1.iso) =
Re: 8.0-RC1 Available
The first of the Release Candidates for the FreeBSD 8.0 release cycle is now available. How many RC's we have will depend on how well 8.0-RC1 does. At the moment only one more RC is on the schedule but odds are fairly high we will wind up inserting at least one more RC. Between BETA4 and RC1 a lot of work has gone into IPv6 issues as well as many other issues that have been brought up from the public testing. And a patch set was committed by the people who handle porting ZFS to FreeBSD that they felt makes ZFS production-ready. Details about the current target schedule along with much more detail about the current status of the release is available here: http://wiki.freebsd.org/8.0TODO There are two known problems with 8.0-RC1. One known issue with the 8.0-RC1 build was discovered after the builds got started so is not part of the ISO images or FreeBSD-Update builds. The issue is that local IPv6 link-local addresses are not reachable. A fix for it has been committed to RELENG_8 so if you install from the 8.0-RC1 media or update using FreeBSD-Update you will then need to update using csup/cvsup mechanisms if you need that fix for your environment. It should only impact people using IPv6. The other known issue is that the flowtable may direct packets to the wrong interface under certain routing conditions. We feel confident that this bug will be fixed so the flowtable is enabled in RC1 to maximize testing. If you experience routing problems, please temporarily disable the flowtable using the sysctl =0 and report the results to the freebsd-current@ mailing list. If we are unable to resolve this issue by RC2, we will disable the flowtable in 8.0-RELEASE. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is about to become a stable branch but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a memory stick image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages this time but no other packages. The DVD image includes a rough pass at what packages will be available on the official release media but is subject to change between now and release. For sparc64 the DVD image has the set of packages that currently build for sparc64, which is a sub-set of the set provided for amd64/i386. The sparc64 disc1 does not have any packages on it because I noticed a little too late that adding the doc packages to disc1 caused it to overflow the target size. For 8.0-RC2 sparc64 will have the livefs bits split out to a separate image (which is the way all the other architectures have been for a while now) and the doc packages will be provided on disc1. None of the other images include packages. If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, or 8.0-BETA4 can upgrade as follows: # freebsd-update upgrade -r 8.0-RC1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 8.0-RC1: # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC1-amd64-bootonly.iso) = a84d43c8adaba3fee9a618098668154e MD5 (8.0-RC1-amd64-disc1.iso) = fb4f75c74144239b4994dc3ad040af33 MD5 (8.0-RC1-amd64-dvd1.iso) = 5da3097634fbe049dd01ad4127d0f396 MD5 (8.0-RC1-amd64-livefs.iso) = 43a483ea73cbbe80f0ef068502594363 MD5
Re: SASL problems with spnego on 8.0-BETA4
On Mon, 21 Sep 2009, George Mamalakis wrote: [stuff snipped] SUCCESS! So, this fix obviates THAT reason for installing the Heimdal port. If George meets with similar success adding -lgssapi_spnego for his spnego problem, I suggest that both libraries be added to the list in line 96 of /usr/bin/krb5-config prior to release of FreeBSD 8.0. It doesn't look like this fix is as simple as submitting a patch to krb5-config. It looks like magic needs to happen somewhere in the base kerberos build system. I notice that the Heimdal port doesn't build the separate libraries and everything seems to be included in libgssapi (which explains why sasl2 works when linked against the Heimdal port). Guys, I changed my /usr/bin/krb5-config's line 96 to include -lgssapi_spnego and -lgssapi_krb5, and ever since both client and server work correctly!! Of course I get some other error, but at least this must be a configuration error :). So, to sum up: Still running on fbsd.8-BETA4, changed krb5-config to include the missing libraries, recompiled cyrus-sasl-2.1.23 after I changed the krb5-config, restarted openldap-sasl-server-2.4.18_1 and after performing an ldapsearch, the client does not complain (and exits) about missing libraries, NOR does the server crash on sasl authentication. Great job guys, thank you all very very much for your help! I posted my query on the 17th of Sep. and in four days (weekend inclusive!) someone came up with an answer that resolves my issue! Great job, once more, and thank you all again! Now, hopefully someone who understands enough about dynamic linking will know if this is the correct fix for 8.0? (I'm going on a couple of weeks vacation at the end of this week, so I won't be around to commit anything and don't understand it well enough to know if this is the correct way to fix it.) So, hopefully someone else can pick this one up? Thanks for testing it, rick ___ 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: zpool scrub hangs on 7.2-stable
On Sun, 20 Sep 2009 17:42 -, christof.schulze wrote: Hello, currently I am running a 7.2 stable with zfs v13. Things work nicely except that zpool scrub hangs without disk activity. I do not get any error messages in dmesg or /var/log/messages and therefore I do not know where to look further. Is this a known issue or should I investigate? If the latter is the case I would need some help doing so. % uname -a ~ FreeBSD ccschu935 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Jul 7 04:56:00 CEST 2009 r...@ccschu935:/usr/obj/usr/src/sys/GENERIC amd64 % zpool status ~ pool: tank state: ONLINE scrub: scrub in progress for 0h3m, 0,00% done, 3370h48m to go config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 ad0s6 ONLINE 0 0 0 ad0s3fONLINE 0 0 0 ad0s3eONLINE 0 0 0 cache mmcsd0UNAVAIL 0 0 0 cannot open errors: No known data errors kind Regards Christof I see you cache is disabled no available. Even though I don't think this should or might be the problem can you remove the device from the pool and re-scrub to see if that relieves the problem. -- Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ 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: 8.0-RC1 Available
On Mon, 2009-09-21 at 23:08 +0800, Chao Shin wrote: I don't know whether USB stick can't boot issue is a show stoper, but it really a big problem for me. I hope it can resolve before 8.0-RELEASE. Somebody is working on that, we hope to have it resolved before RC2. It's one of several things that is making having an RC3 likely, we would want there to be a reasonable amount of time for people to test the changes that would be involved in that fix (as well as the flowtable fix and a few other issues). -- Ken Smith - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg attached)
On Friday 18 September 2009 11:52 pm, Ted Faber wrote: On Wed, Sep 16, 2009 at 09:13:27AM -0700, Ted Faber wrote: Hi. I'm trying to upgrade a machine to a new motherboard (the ECS A790GXM-AD3 AM3 790GX) my FreeBSD 7-STABLE system (GENERIC kernel, compiled from source on 10 Sept 2009) reaches the point where it's going to mount the root file system and can't find the disk. It drops me into the manual specification of root file system menu, but there are no GEOM-managed disks to choose from. [...] I managed to boot FreeBSD on this motherboard using a USB key. Attached is the dmesg from a verbose boot. Any help would be appreciated. This is a known problem and should be fixed in 8.0. Sorry, I haven't had time to back-port the code. Proabably it's good time to consider testing 8.0-RC1. ;-) Jung-uk Kim ___ 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: PATA disks/DVD not detected on ATI IXP 700 - cannot boot (dmesg attached)
On Mon, Sep 21, 2009 at 12:39:17PM -0400, Jung-uk Kim wrote: On Friday 18 September 2009 11:52 pm, Ted Faber wrote: On Wed, Sep 16, 2009 at 09:13:27AM -0700, Ted Faber wrote: Hi. I'm trying to upgrade a machine to a new motherboard (the ECS A790GXM-AD3 AM3 790GX) my FreeBSD 7-STABLE system (GENERIC kernel, compiled from source on 10 Sept 2009) reaches the point where it's going to mount the root file system and can't find the disk. It drops me into the manual specification of root file system menu, but there are no GEOM-managed disks to choose from. [...] I managed to boot FreeBSD on this motherboard using a USB key. Attached is the dmesg from a verbose boot. Any help would be appreciated. This is a known problem and should be fixed in 8.0. Sorry, I haven't had time to back-port the code. Proabably it's good time to consider testing 8.0-RC1. ;-) Thanks for getting back to me. It does seem to be fixed in 8.0-RC1 (and thanks for that fix, too). That is, 8.0-RC1 finds the drive, but... 8.0 (RELENG_8, from last night) doesn't seem to find the FBSD partitions on the drive. It finds the drive and the BIOS partition (slice). It fails on my old motherboard (not the one above) that boots 7.2-STABLE just fine. It drops me into the menu to manually configure the root partition, but doesn't accept either the native device names for the root partition (/dev/ad0s1a) or a geom label (/dev/label/root). The list of GEOM devices only includes ad0 and ad0s1. The disk isn't dangerously dedicated, but I only added geom labels to the partitions last night. The glabels work fine under 7.2-STABLE, but RELENG_8 seems to ignore them. I've attached output from fdisk, bsdlabel, and glabel in case I'm misinterpreting them. I've been waiting for a free moment to write a more complete report, but since I've got your attention... Any ideas? I'll be able to run more diagnostics under 8.0 tonight. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 488392002 (238472 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 14/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 419430404.2BSD0 0 0 b: 20971520 4194304 swap c: 4883920020unused0 0 # raw part, don't edit d: 41943040 251658244.2BSD 2048 16384 28552 e: 421283138 671088644.2BSD0 0 0 Name Status Components label/root N/A ad0s1a label/swap N/A ad0s1b label/var N/A ad0s1d label/usr N/A ad0s1e pgpEIGEa7vAvj.pgp Description: PGP signature
Re: SASL problems with spnego on 8.0-BETA4
On Sep 21, 2009, at 5:26 PM, Rick Macklem wrote: Now, hopefully someone who understands enough about dynamic linking will know if this is the correct fix for 8.0? (I'm going on a couple of weeks vacation at the end of this week, so I won't be around to commit anything and don't understand it well enough to know if this is the correct way to fix it.) So, hopefully someone else can pick this one up? Thanks for testing it, rick ___ Could this be the same problem I have with SASL and postfix? http://lists.freebsd.org/pipermail/freebsd-questions/2009-September/205525.html -- Peter Ankerstål pe...@pean.org http://www.pean.org/ ___ 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: SASL problems with spnego on 8.0-BETA4
On Mon, 21 Sep 2009, Peter Ankerstål wrote:
Could this be the same problem I have with SASL and postfix?
http://lists.freebsd.org/pipermail/freebsd-questions/2009-September/205525.html
I have no idea, but there's one way to find out. Apply this patch to
/usr/bin/krb5-config and then rebuild all the cyrus-sasl2 stuff in
/usr/ports. (If you rm -r work before make build, you'll be sure
to use krb5-config again.)
--- krb5-config.sav 2009-09-18 16:54:42.0 -0400
+++ krb5-config 2009-09-21 14:49:34.0 -0400
@@ -93,7 +93,7 @@
lib_flags=-L${libdir}
case $library in
gssapi)
- lib_flags=$lib_flags -lgssapi -lheimntlm
+ lib_flags=$lib_flags -lgssapi -lgssapi_spnego -lgssapi_krb5 -lheimntlm
;;
kadm-client)
lib_flags=$lib_flags -lkadm5clnt
Then see if the newly built binaries work.
Good luck with it, rick___
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: incorrect usleep/select delays with HZ 2500
What we wound up doing was splitting tvtohz() into two functions.
tvtohz_high(tv)
Returned value meets or exceeds requested time. A minimum value
of 1 is returned (really only for {0,0}.. else minimum value is 2).
tvtohz_low(tv)
Returned value might be shorter then requested time, and 0 can
be returned.
Most kernel functions use the tvtohz_high() function. Only a few
use tvtohz_low().
I have not found any 'good' solution to the problem. For example,
average-up errors can mount up when using the results to control a
callout timer resulting in much longer delays then originally intended,
and similarly same-tick interrupts (e.g. a value of 1) can create
much shorter delays then expected. Sometimes one cares more about
the average interval being correct, other times the time must not
be allowed to be too short. You lose no matter what you choose.
http://fxr.watson.org/fxr/source/kern/kern_clock.c?v=DFBSD
If you look at tvtohz_high() you will note that the minimum value
of 1 is only returned if the passed tv is essentially {0,0}. i.e. 0uS.
1uS == 2 ticks (((us + (tick - 1)) / tick) + 1). The 'tick' global
here is the number of uS per tick (not to be confused with 'ticks').
Because of all of that I decided to split the function to make the
requirements more apparent.
--
The nanosleep() work is a different issue... that's for userland calls
(primarily the libc usleep() function). We found that some linux
programs assumed that nanosleep() was far more fine-grained then (hz)
and, anyway, the system call is called 'nanosleep' and 'usleep' which
kind of implies a fine-grained sleep, so we turned it into one when
small time intervals were being requested.
http://fxr.watson.org/fxr/source/kern/kern_time.c?v=DFBSD
The way I figure it if a userland program wants to make system calls
with fine-grained sleeps that are too small, it's really no different
from treating that program as being cpu-bound anyway so why not try to
accomodate it?
--
The 8254 issue is more one of a lack of interest in fixing it.
Basically using the 8254 as a measure of realtime when the reload
value is set to small (i.e. high hz) will always lead to serious
timing problems. The reason there is such a lack of interest
in fixing it is that most machines have other timers available
(lapic, acpi, hpet, tsc, etc). A secondary issue might be tying
real-time functions to 'ticks', which could still be driven by the
8254 interrupt those have to be divorced from ticks. I'm not
sure if FreeBSD has any of those left (does date still skip quickly if
hz is set ultra-high? Even when other timers are available?).
I will note that tying real-time functions to the hz-based tick
function (which is also the 8254-driven problem when other timers
are not available) leads to serious problems, particularly with ntpd,
even if you only lose track of the full cycle of the timer
occassionally.
However, neither do you want to 'skip' the ticks value to catch up
to a lost interrupt. That will mess up tsleep() and other hz-based
timeouts that assume that values of '2' will not instantly
timeout.
So actual realtime operations really do have to be completely divorced
from the hz-based ticks counter and it must only be used for looser
timing needs such as protocol timeouts and sleeps.
-Matt
___
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: zpool scrub hangs on 7.2-stable
Am Montag 21 September 2009 00:10:39 schrieb Artem Belevich: Do you have ZIL disabled? I think I saw the same scrub stall on -7 when I had vfs.zfs.zil_disable=1. After re-enabling ZIL scrub proceeded normally. zil is not disabled % sysctl vfs.zfs.zil_disable vfs.zfs.zil_disable: 0 but thank you for the hint Regards Christof ___ 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
WORKAROUND Re: zpool scrub hangs on 7.2-stable
having removed the cache did not do anything at first but after letting zpool scrub sit there for ~20 minutes (no CPU or HDD activity whatsoever) it suddenly started the scrubbing process. So I seem to have hit a bug. Regards Christof Am Montag 21 September 2009 17:32:05 schrieb Jason J. Hellenthal: On Sun, 20 Sep 2009 17:42 -, christof.schulze wrote: Hello, currently I am running a 7.2 stable with zfs v13. Things work nicely except that zpool scrub hangs without disk activity. I do not get any error messages in dmesg or /var/log/messages and therefore I do not know where to look further. Is this a known issue or should I investigate? If the latter is the case I would need some help doing so. % uname -a ~ FreeBSD ccschu935 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Jul 7 04:56:00 CEST 2009 r...@ccschu935:/usr/obj/usr/src/sys/GENERIC amd64 % zpool status ~ pool: tank state: ONLINE scrub: scrub in progress for 0h3m, 0,00% done, 3370h48m to go config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 ad0s6 ONLINE 0 0 0 ad0s3fONLINE 0 0 0 ad0s3eONLINE 0 0 0 cache mmcsd0UNAVAIL 0 0 0 cannot open errors: No known data errors kind Regards Christof I see you cache is disabled no available. Even though I don't think this should or might be the problem can you remove the device from the pool and re-scrub to see if that relieves the problem. ___ 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: 8.0-Beta installation problem -- Unable to find /dev/ad0s1b
Hi! My previous tests were with 8.0-beta4-amd64. I now tested 8.0-RC1 and it works now, very nice! -- p...@opsec.eu+49 171 310137211 years to go ! ___ 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: 7.2-release/amd64: panic, spin lock held too long
I have patched the sched_ule.c and did a make buildkernel make installkernel (is buildworld and installworld necessary?), rebooted and the machine is running now. I will post here again if there is any update. My server is up for 3.5 days now with HyperThreading powerd enabled. No panic occured yet. C.C. ___ 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: 7.2-release/amd64: panic, spin lock held too long
2009/9/22 C. C. Tang hiyo...@gmail.com: I have patched the sched_ule.c and did a make buildkernel make installkernel (is buildworld and installworld necessary?), rebooted and the machine is running now. I will post here again if there is any update. My server is up for 3.5 days now with HyperThreading powerd enabled. No panic occured yet. Usually how long did it take to panic? Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: 7.2-release/amd64: panic, spin lock held too long
Attilio Rao wrote: 2009/9/22 C. C. Tang hiyo...@gmail.com: I have patched the sched_ule.c and did a make buildkernel make installkernel (is buildworld and installworld necessary?), rebooted and the machine is running now. I will post here again if there is any update. My server is up for 3.5 days now with HyperThreading powerd enabled. No panic occured yet. Usually how long did it take to panic? Attilio It is rather random, but will usually panic within one week. Anyway my server will keep running and I will report if it has any problem. Thanks, C.C. ___ 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
Random Network Drops on Realtek Interfaces (re)
All, I've been experiencing an intermittent issue with a drop in networking connectivity on a couple of boxes. At random times I drop connectivity between the servers and their gateway. I am able to login via the secondary interface and /etc/netstart and everything starts behaving as normal. My switch shows the link is up, ifconfig shows the link is up, but I am unable to ping my gateway until running /etc/netstart. Somedays it'll happen a few times an hour, some days once every 8-10 hours. It really is intermittent, and driving me crazy trying to track down the issue. I've tried different cables, switches, gateways, IPs, and locations. Memtest for 5 days showed no errors. However, the same problem exists on two separate installs at different times. I am able to connect to the one server from the second via their secondary interfaces, so the problem isn't related to both network interfaces. Both servers have the Supermicro X7SLM-L motherboard, same CPU, RAM and disks. Using the Realtek network driver (re). pciconf shows: vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)' class = network subclass = ethernet I've experienced the problem for some time now on both 7.2-RELEASE and 7.2-STABLE (09/20/09) using amd64. Any help or suggestions would be useful in getting to the bottom of this. Thanks, -c ___ 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
