Installworld broken with an NFS /tmp
I've found the following thread from 2009 which matches what I've just come across while trying to install 9-RELEASE to disk on a machine with an NFS root. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00084.html I've just worked around this by nullfs mounting the local disk's /tmp over the existing (nfs) /tmp, but is there a better way of doing this - an environment variable to specify an alternate to /tmp perhaps? Thanks. -- Apologies for the below The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ___ 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: Installworld broken with an NFS /tmp
On 19 January 2012 13:11, Matt Burke mattbli...@icritical.com wrote: I've found the following thread from 2009 which matches what I've just come across while trying to install 9-RELEASE to disk on a machine with an NFS root. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00084.html I've just worked around this by nullfs mounting the local disk's /tmp over the existing (nfs) /tmp, but is there a better way of doing this - an environment variable to specify an alternate to /tmp perhaps? To solve the sillyrename problem visible during installworld, I just add the following to rc.conf (nfs) once and for all: tmpmfs=YES varmfs=YES # why? probably needs for /var/tmp -- wbr, pluknet ___ 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: Installworld broken with an NFS /tmp
On Jan 19, 2012, at 5:25 AM, Sergey Kandaurov pluk...@gmail.com wrote: On 19 January 2012 13:11, Matt Burke mattbli...@icritical.com wrote: I've found the following thread from 2009 which matches what I've just come across while trying to install 9-RELEASE to disk on a machine with an NFS root. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00084.html I've just worked around this by nullfs mounting the local disk's /tmp over the existing (nfs) /tmp, but is there a better way of doing this - an environment variable to specify an alternate to /tmp perhaps? To solve the sillyrename problem visible during installworld, I just add the following to rc.conf (nfs) once and for all: tmpmfs=YES varmfs=YES # why? probably needs for /var/tmp I had to do the same thing, and to be honest I don't like the Nfs root setup. I like having all of the tools , but a smaller setup would work better for me . I want to see how hard it will be to do a 9 install via mfsbsd or a mfsroot akin to what was in 7 and 8 . Has anyone tried that ? -- wbr, pluknet ___ 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 Mark Saad | mark.saad@longcount.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
Strange 'hangs' with RELENG_9
Hello, Recently I updated my RELENG_8 to RELENG_9. Since then, the server hangs from time to time for 5 minutes. When I run a top in a remote terminal, I can see that it hangs so strong, that the clock hangs too. When it continues to run , the time continues from the when it 'hanged'. TCP connections are also dropped with timeout at that time. However, no kernel panic, and i can't see anything in the dmesg log too. A strange thing is, the server continues working when I press a key at the physical console (I'm doing this with a remote IP console). More strange thing is, when I do a reboot, the server flushes all its disks, and then does a panic, instead of rebooting. I have to revert to the RELENG_8 kernel (userland is RELENG_9 now), I have no other choice. I hardly can get the configuration and log out from it these times, because of the hangs. Hardware details: This has 4 SAMSUNG disk (1.5TB each) array, driven by a 3ware Raid controller, each disk exported as is. It also has an OCZ Revodrive as a disk cache (zfs L2ARC cache) limited to SATA1 speed (strange kernel panics because of disk timeouts when using at full speed), 8GB RAM, AMD64 processor. FreeBSD details: The server runs on the 4-disk zfs array, boots from it and uses the zfs array also as root media. It has 4 jails, connections handled by pf. Kernel configuration: cpu HAMMER ident MYSERVER machine amd64 options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options NFSCLIENT # Network Filesystem Client options NFSLOCKD# Network Lock Manager options MSDOSFS # MSDOS Filesystem options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache options INCLUDE_CONFIG_FILE # Include this file in kernel options SMP # Symmetric MultiProcessor Kernel device cpufreq device acpi device pci device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives options ATA_STATIC_ID # Static device numbering device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device twa # 3ware 9000 series PATA/SATA RAID device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device agp # support several AGP chipsets device uart# Generic UART driver device ppc device ppbus # Parallel port bus (required) device lpt # Printer device miibus # MII bus support device re # RealTek 8139C+/8169/8169S/8110S device loop# Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory disks device gif # IPv6 and
Re: Strange 'hangs' with RELENG_9
László KÁROLYI wrote: Hello, Recently I updated my RELENG_8 to RELENG_9. Since then, the server hangs from time to time for 5 minutes. When I run a top in a remote terminal, I can see that it hangs so strong, that the clock hangs too. When it continues to run , the time continues from the when it 'hanged'. TCP connections are also dropped with timeout at that time. However, no kernel panic, and i can't see anything in the dmesg log too. Obtaining kernel dump is the way to go. You can occasionally find that obtaining dump on world built with clang is much easier than on gcc-compiled one. I remember at least one such case with broken zfs directory when trying to read such directory result in process with no state on gcc-compiled world and result in imminent panic in zfs code on clang-compiled world. Remember to set dumpdev to something appropriate. /boot/loader.conf: zfs_load=YES vfs.root.mountfrom=zfs:pool/root vfs.zfs.vdev.max_pending=8 geom_raid_load=YES hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 /etc/sysctl.conf: vfs.zfs.l2arc_noprefetch=0 This has impact on performance. You sure you really need that one? Can you try without it? /etc/make.conf, the kernel was compiled with this settings: CPUTYPE?=athlon64 Compiling with clang you better turn that thing off. -- Sphinx of black quartz judge my vow. ___ 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: Strange 'hangs' with RELENG_9
Recently I updated my RELENG_8 to RELENG_9. Since then, the server hangs from time to time for 5 minutes. When I run a top in a remote terminal, I can see that it hangs so strong, that the clock hangs too. When it continues to run , the time continues from the when it 'hanged'. TCP connections are also dropped with timeout at that time. However, no kernel panic, and i can't see anything in the dmesg log too. ... /etc/make.conf, the kernel was compiled with this settings: CPUTYPE?=athlon64 I'd highly appreciate any help, as I am clueless with this one. It may not help at all, but you could try to change scheduler from ULE to BSD. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare twitter.com/kometen ___ 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: Strange 'hangs' with RELENG_9
Volodymyr Kostyrko wrote: Obtaining kernel dump is the way to go. You can occasionally find that obtaining dump on world built with clang is much easier than on gcc-compiled one. I remember at least one such case with broken zfs directory when trying to read such directory result in process with no state on gcc-compiled world and result in imminent panic in zfs code on clang-compiled world. Remember to set dumpdev to something appropriate. I'm not near to the server for putting any dumpdevice in (if you meant that way), and also, there's no kernel panic but just at the end of the reboot process, and not all the time. This has impact on performance. You sure you really need that one? Can you try without it? /etc/make.conf, the kernel was compiled with this settings: CPUTYPE?=athlon64 Compiling with clang you better turn that thing off. Okay, I turned it off, recompiled the kernel, also turned the vfs.zfs.vdev.max_pending option off in /boot/loader.conf, rebooted, but the hangs are still there. Moreover, I couldn't set SCHED_BSD in the kernel config, it said that it's an illegal option. Maybe it does not exist in RELENG_9. Any other ideas? ___ 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: Strange 'hangs' with RELENG_9
On Thu, Jan 19, 2012 at 3:00 PM, László KÁROLYI las...@karolyi.hu wrote: Moreover, I couldn't set SCHED_BSD in the kernel config, it said that it's an illegal option. Maybe it does not exist in RELENG_9. options SCHED_4BSD Cheers Tom ___ 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: Strange 'hangs' with RELENG_9
On Thu, Jan 19, 2012 at 04:00:24PM +0100, L??szl?? K??ROLYI wrote: Moreover, I couldn't set SCHED_BSD in the kernel config, it said that it's an illegal option. Maybe it does not exist in RELENG_9. This should be options SCHED_4BSD ^ if you want to try it. It can be used with RELENG_9; check the NOTES file. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: Strange 'hangs' with RELENG_9
Hello, I managed to get a screenshot from the kernel panic at reboot, although I don't know if it will get through here, attached. László KÁROLYI http://linkedin.com/in/karolyi Tom Evans wrote: On Thu, Jan 19, 2012 at 3:00 PM, László KÁROLYI las...@karolyi.hu wrote: Moreover, I couldn't set SCHED_BSD in the kernel config, it said that it's an illegal option. Maybe it does not exist in RELENG_9. options SCHED_4BSD Cheers Tom ___ 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-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: Strange 'hangs' with RELENG_9
Ok, couldn't get it through... So here is it, uploaded: http://www.freeimagehosting.net/s836i László KÁROLYI http://linkedin.com/in/karolyi Tom Evans wrote: On Thu, Jan 19, 2012 at 3:00 PM, László KÁROLYI las...@karolyi.hu wrote: Moreover, I couldn't set SCHED_BSD in the kernel config, it said that it's an illegal option. Maybe it does not exist in RELENG_9. options SCHED_4BSD Cheers Tom ___ 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: Fighting with vnet / jails epair and so on
hi, I've created a new patch (adapted the old freebsd-9RC2 patch) for /etc/rc.d/jail: The original patch: http://wiki.polymorf.fr/files/jail_rc.patch My patch: http://pastebin.com/9LdLwaNA It works (was very happy) if you start the jail, but has problems with stopping: it shows in jls still as active: # jls JID IP Address Hostname Path 1 - template.domain /jails/template If I try to remove with jail -r 1 than first the process hang, second after while, the whole machine needs a reset. There is no process from the jail active, nor any epair* interfaces or mounts, which is quite good, but ... I you try to create the jail again (after /etc/rc.d/jail stop), it tries to create the epair0a (the last I can see) interface and than it hangs again - reset needed Also nice to know: # umount /jails/template umount: unmount of /jails/template failed: Device busy Also not possible: a normal reboot after starting / stopping the jail. - reset needed cu denny___ 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: Strange 'hangs' with RELENG_9
Greg Byshenk wrote: This should be options SCHED_4BSD ^ if you want to try it. It can be used with RELENG_9; check the NOTES file. Changed to this scheduler, still no luck. The server still hangs, and when it hangs, only a keypress on the console can bring it out of that state (for example, CTRL key does too). ___ 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: Strange 'hangs' with RELENG_9
László KÁROLYI wrote: Volodymyr Kostyrko wrote: Obtaining kernel dump is the way to go. You can occasionally find that obtaining dump on world built with clang is much easier than on gcc-compiled one. I remember at least one such case with broken zfs directory when trying to read such directory result in process with no state on gcc-compiled world and result in imminent panic in zfs code on clang-compiled world. Remember to set dumpdev to something appropriate. I'm not near to the server for putting any dumpdevice in (if you meant that way), and also, there's no kernel panic but just at the end of the reboot process, and not all the time. I mean setting dumpdev=auto in /etc/rc.conf so the kernel can dump to any available device such as swap partition. -- Sphinx of black quartz judge my vow. ___ 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: Strange 'hangs' with RELENG_9
László KÁROLYI wrote: Ok, couldn't get it through... So here is it, uploaded: http://www.freeimagehosting.net/s836i Another screenshot here: http://www.freeimagehosting.net/xv26d ___ 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: Strange 'hangs' with RELENG_9
CC: Alexander Motin On 1/19/12, László KÁROLYI las...@karolyi.hu wrote: László KÁROLYI wrote: Ok, couldn't get it through... So here is it, uploaded: http://www.freeimagehosting.net/s836i Another screenshot here: http://www.freeimagehosting.net/xv26d ___ 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-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: Strange 'hangs' with RELENG_9
On 19.01.2012 18:51, Oliver Pinter wrote: CC: Alexander Motin On 1/19/12, László KÁROLYIlas...@karolyi.hu wrote: László KÁROLYI wrote: Ok, couldn't get it through... So here is it, uploaded: http://www.freeimagehosting.net/s836i Another screenshot here: http://www.freeimagehosting.net/xv26d I am not sure how freezes that could be fixed with key press could be related to panics around storage. I would try to go two different ways: - for panics, if dumping is not possible, I would try to resolve address of the instruction pointer from both messages with `addr2line -e /path/to/kernel address`. - for freezes I would try to look on eventtimers(4) subsystem: check what timer is used, try to switch to different one, try to switch into periodic mode. Since cause of siis timeouts in SATA2 mode is also unclear, I can't also exclude that it may be somehow related. -- Alexander Motin ___ 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: Strange 'hangs' with RELENG_9
on 19/01/2012 15:51 László KÁROLYI said the following: Recently I updated my RELENG_8 to RELENG_9. Since then, the server hangs from time to time for 5 minutes. When I run a top in a remote terminal, I can see that it hangs so strong, that the clock hangs too. When it continues to run , the time continues from the when it 'hanged'. TCP connections are also dropped with timeout at that time. However, no kernel panic, and i can't see anything in the dmesg log too. A strange thing is, the server continues working when I press a key at the physical console (I'm doing this with a remote IP console). More strange thing is, when I do a reboot, the server flushes all its disks, and then does a panic, instead of rebooting. Please provide output of the following sysctls: sysctl kern.eventtimer sysctl kern.timecounter -- Andriy Gapon ___ 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: Strange 'hangs' with RELENG_9
on 19/01/2012 19:14 Alexander Motin said the following: On 19.01.2012 18:51, Oliver Pinter wrote: CC: Alexander Motin On 1/19/12, László KÁROLYIlas...@karolyi.hu wrote: László KÁROLYI wrote: Ok, couldn't get it through... So here is it, uploaded: http://www.freeimagehosting.net/s836i Another screenshot here: http://www.freeimagehosting.net/xv26d I am not sure how freezes that could be fixed with key press could be related to panics around storage. I would try to go two different ways: - for panics, if dumping is not possible, I would try to resolve address of the instruction pointer from both messages with `addr2line -e /path/to/kernel address`. I would recommend to add the following options to the kernel config: options STACK options DDB options DDB_NUMSYM options KDB options KDB_TRACE options KDB_UNATTENDED (if you don't have any of them already). That should add some useful information to the panic messages. Please try to capture the first panic report before any secondary panics cloud the situation. And I agree with Alexander that the panics and the hangs could be unrelated. -- Andriy Gapon ___ 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: Strange 'hangs' with RELENG_9
On Thu, 2012-01-19 at 19:14 +0200, Alexander Motin wrote: On 19.01.2012 18:51, Oliver Pinter wrote: CC: Alexander Motin On 1/19/12, László KÁROLYIlas...@karolyi.hu wrote: László KÁROLYI wrote: Ok, couldn't get it through... So here is it, uploaded: http://www.freeimagehosting.net/s836i Another screenshot here: http://www.freeimagehosting.net/xv26d I am not sure how freezes that could be fixed with key press could be related to panics around storage. I would try to go two different ways: - for panics, if dumping is not possible, I would try to resolve address of the instruction pointer from both messages with `addr2line -e /path/to/kernel address`. - for freezes I would try to look on eventtimers(4) subsystem: check what timer is used, try to switch to different one, try to switch into periodic mode. Since cause of siis timeouts in SATA2 mode is also unclear, I can't also exclude that it may be somehow related. The new eventtimers was also the first thing that came to my mind, but I couldn't quickly find the right way to boot with a different timer. I saw in the eventtimers(7) manpage that there's a sysctl to change the timer, but when I used it the system timing went completely wonky (ntpd reported it was off by many seconds, a few seconds after I changed it). When I just tried it again the system locked up and had to be power cycled. (I'm trying this on old hardware where my only choices are i8254 and RTC, and changing to RTC apparently doesn't work well.) So I didn't want to recommend it to someone else. :) For both eventtimers and timecounters, I think it'd be nice if a tunable or hint could let the user override the quality number. But maybe there's already some better way of influencing the choices the kernel makes? -- Ian ___ 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: Strange 'hangs' with RELENG_9
On 2012.01.19., at 18:18, Andriy Gapon wrote: Please provide output of the following sysctls: sysctl kern.eventtimer sysctl kern.timecounter [root@sys ~]# sysctl kern.eventtimer kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 450 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 450 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 [root@sys ~]# sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(800) HPET(950) i8254(0) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: HPET kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.ACPI-fast.counter: 3649705857 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 27536 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1224089625 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1655163352 kern.timecounter.tc.TSC-low.frequency: 11772185 kern.timecounter.tc.TSC-low.quality: 800 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 -- László Károlyi http://linkedin.com/in/karolyi ___ 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: Strange 'hangs' with RELENG_9
On 01/19/12 21:05, Ian Lepore wrote: On Thu, 2012-01-19 at 19:14 +0200, Alexander Motin wrote: On 19.01.2012 18:51, Oliver Pinter wrote: CC: Alexander Motin On 1/19/12, László KÁROLYIlas...@karolyi.hu wrote: László KÁROLYI wrote: Ok, couldn't get it through... So here is it, uploaded: http://www.freeimagehosting.net/s836i Another screenshot here: http://www.freeimagehosting.net/xv26d I am not sure how freezes that could be fixed with key press could be related to panics around storage. I would try to go two different ways: - for panics, if dumping is not possible, I would try to resolve address of the instruction pointer from both messages with `addr2line -e /path/to/kernel address`. - for freezes I would try to look on eventtimers(4) subsystem: check what timer is used, try to switch to different one, try to switch into periodic mode. Since cause of siis timeouts in SATA2 mode is also unclear, I can't also exclude that it may be somehow related. The new eventtimers was also the first thing that came to my mind, but I couldn't quickly find the right way to boot with a different timer. I saw in the eventtimers(7) manpage that there's a sysctl to change the timer, but when I used it the system timing went completely wonky (ntpd reported it was off by many seconds, a few seconds after I changed it). When I just tried it again the system locked up and had to be power cycled. (I'm trying this on old hardware where my only choices are i8254 and RTC, and changing to RTC apparently doesn't work well.) So I didn't want to recommend it to someone else. :) That's strange. On all systems I have, I can safely set any event timer in any way. Though for better precision it is better to set them using loader tunable. For both eventtimers and timecounters, I think it'd be nice if a tunable or hint could let the user override the quality number. But maybe there's already some better way of influencing the choices the kernel makes? kern.eventtimer.timer is both sysctl and loader tunable. You can set it anywhere you want. Also for most enevt timers there are documented tunables to disable them, Also, as I've already said, you may try to switch to old periodic mode by setting kern.eventtimer.periodic. On your old system with just i8254 and RTC it is enabled always automatically. -- Alexander Motin ___ 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: Strange 'hangs' with RELENG_9
on 19/01/2012 21:24 László Károlyi said the following: On 2012.01.19., at 18:18, Andriy Gapon wrote: Please provide output of the following sysctls: sysctl kern.eventtimer sysctl kern.timecounter [root@sys ~]# sysctl kern.eventtimer kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 450 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 450 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 [root@sys ~]# sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(800) HPET(950) i8254(0) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: HPET kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.ACPI-fast.counter: 3649705857 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 27536 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1224089625 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1655163352 kern.timecounter.tc.TSC-low.frequency: 11772185 kern.timecounter.tc.TSC-low.quality: 800 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 I wonder whether there could be an interference between HPET being used as timecounter and HPET being used as an event timer. Alexander, what do you think? László, can you please try changing kern.timecounter.hardware to TSC-low or ACPI-fast? -- Andriy Gapon ___ 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: Timekeeping in stable/9
Looks like this is down to the dynamic/tickless changes in 9 (that aren't even noted in the release notes), the machines have now been switched to linux as the lack of responses/care given to my recent postings has been noted and it was deemed that using linux would be less hassle in the long run. Unfortunate decision but I am inclined to agree. Thanks, J Ian Lepore wrote: On Tue, 2012-01-17 at 20:12 +, Joe Holden wrote: Hi guys, Has anyone else noticed the tendency for 9.0-R to be unable to accurately keep time? I've got a couple of machines that have been upgraded from 8.2 that are struggling, in particular a Virtual box guest that was fine on 8.2, but now that's its been upgraded to 9.0 counts at anything from 2 to 20 seconds per 5 second sample, the result is similar with HPET, ACPI-fast and TSC. I also have physical boxes which new seem to drift quite substantially, ntpd cannot keep up and as these boxes need to be able to report the time relatively accurately, it is causing problems with log times and such... Any suggestions most welcome! Thanks, J I finally got a 9.0 generic build done today and I've been watching the timekeeping on 3 systems and they're all doing just fine. Two of the systems are performing pretty much identically to how they did on 8.2; the clock frequency correction calculated by ntpd differs by less than 1ppm. On the other system the kernel timekeeping routines are now choosing to use a different clock so I don't get a direct comparison of the old vs new drift rate, but the drift is still reasonable (100ppm now, used to be around 88, on an old 300mhz MediaGx-based system). I haven't had time yet to learn about the new eventtimer stuff in 9.0, but I know you can get some info on the choices it made via sysctl kern.eventtimer. Before 9.0 I'd check sysctl kern.clockrate and vmstat -i and make sure the chosen clock is interrupting at the right rate, but now with the eventtimer stuff there's not an obvious correlation between hz and profhz and stathz and any particular device's interrupt rate, at least for some clock choices (on the old MediaGx system without ACPI or HPET it seems to work more like it used to). -- Ian ___ 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: Strange 'hangs' with RELENG_9
On 2012.01.19., at 21:03, Andriy Gapon wrote: I wonder whether there could be an interference between HPET being used as timecounter and HPET being used as an event timer. Alexander, what do you think? László, can you please try changing kern.timecounter.hardware to TSC-low or ACPI-fast? Sure. An interesting thing is, looks like when pf is not turned on (that means, no traffic forwarded to the servers that are waiting for incoming connections in their jails), the server does not hang. I need to recompile the RELENG_9 pfctl binary, turn packet filtering on, after that I can test this. -- László Károlyi http://linkedin.com/in/karolyi ___ 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: Timekeeping in stable/9
On Jan 19, 2012, at 12:04 PM, Joe Holden wrote: Looks like this is down to the dynamic/tickless changes in 9 (that aren't even noted in the release notes), the machines have now been switched to linux as the lack of responses/care given to my recent postings has been noted and it was deemed that using linux would be less hassle in the long run. Sounds like you were looking for commercial support, since unpaid volunteers don't have an obligation to promptly leap out and provide solutions within your ETA. Regards, -- -Chuck ___ 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: Timekeeping in stable/9
Chuck Swiger wrote: On Jan 19, 2012, at 12:04 PM, Joe Holden wrote: Looks like this is down to the dynamic/tickless changes in 9 (that aren't even noted in the release notes), the machines have now been switched to linux as the lack of responses/care given to my recent postings has been noted and it was deemed that using linux would be less hassle in the long run. Sounds like you were looking for commercial support, since unpaid volunteers don't have an obligation to promptly leap out and provide solutions within your ETA. Regards, Not really, just an acknowledgement would be fine. It is what it is, everyday I try to argue in favour of the project, I still use it for myself everywhere but increasingly things happen that just don't on other volunteer projects... it's rather difficult to argue the case when they can install Ubuntu or whatever nonsense distro is the current favourite and it just works. Just a bit more accurate info would solve it, if it doesn't do X reliably, or Y has changed, note it. ___ 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: Strange 'hangs' with RELENG_9
On 01/19/12 22:03, Andriy Gapon wrote: on 19/01/2012 21:24 László Károlyi said the following: On 2012.01.19., at 18:18, Andriy Gapon wrote: Please provide output of the following sysctls: sysctl kern.eventtimer sysctl kern.timecounter [root@sys ~]# sysctl kern.eventtimer kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 450 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 450 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 [root@sys ~]# sysctl kern.timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(800) HPET(950) i8254(0) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: HPET kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.ACPI-fast.counter: 3649705857 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 27536 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1224089625 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1655163352 kern.timecounter.tc.TSC-low.frequency: 11772185 kern.timecounter.tc.TSC-low.quality: 800 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 I wonder whether there could be an interference between HPET being used as timecounter and HPET being used as an event timer. Alexander, what do you think? I don't expect interference between them. HPET timecounter just reads same hardware counter that is also read by comparators for eventtimer interrupts generation. Theoretically they could interfere if that timer was stopped during comparators programming, but it is not. László, can you please try changing kern.timecounter.hardware to TSC-low or ACPI-fast? -- Alexander Motin ___ 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: Timekeeping in stable/9
On Jan 19, 2012, at 12:18 PM, Joe Holden wrote: Sounds like you were looking for commercial support, since unpaid volunteers don't have an obligation to promptly leap out and provide solutions within your ETA. Not really, just an acknowledgement would be fine. It is what it is, everyday I try to argue in favour of the project, I still use it for myself everywhere but increasingly things happen that just don't on other volunteer projects... it's rather difficult to argue the case when they can install Ubuntu or whatever nonsense distro is the current favourite and it just works. Just a bit more accurate info would solve it, if it doesn't do X reliably, or Y has changed, note it. You asked a question and got two or three responses back in a day. You mentioned trying different timekeeping choices, but I don't recall seeing what your kern.timecounter sysctl values looked like; without that, folks are missing info that is likely to be relevant. Ah, well Regards, -- -Chuck ___ 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: Timekeeping in stable/9
Chuck Swiger wrote: On Jan 19, 2012, at 12:18 PM, Joe Holden wrote: Sounds like you were looking for commercial support, since unpaid volunteers don't have an obligation to promptly leap out and provide solutions within your ETA. Not really, just an acknowledgement would be fine. It is what it is, everyday I try to argue in favour of the project, I still use it for myself everywhere but increasingly things happen that just don't on other volunteer projects... it's rather difficult to argue the case when they can install Ubuntu or whatever nonsense distro is the current favourite and it just works. Just a bit more accurate info would solve it, if it doesn't do X reliably, or Y has changed, note it. You asked a question and got two or three responses back in a day. You mentioned trying different timekeeping choices, but I don't recall seeing what your kern.timecounter sysctl values looked like; without that, folks are missing info that is likely to be relevant. Ah, well Regards, Yeah my gripe isn't with having no responses, the handful of people that have responded have been helpful but ultimately no responses from anyone involved. Just a one liner saying we changed the timecounter stuff in 9, look at sysctl tree X would have been more than sufficient, this sort of thing should really be mentioned in the relnotes though... For the record though, setting kern.eventtimer.periodic to 1 fixes the problem on all affected machines (returns my virtualbox guest to normality, reduces the drift on physical machines to 8.2 figures). FWIW, I can't even see any notes relating to this in UPDATING either. ___ 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: Timekeeping in stable/9
Joe Holden wrote: Chuck Swiger wrote: On Jan 19, 2012, at 12:18 PM, Joe Holden wrote: Sounds like you were looking for commercial support, since unpaid volunteers don't have an obligation to promptly leap out and provide solutions within your ETA. Not really, just an acknowledgement would be fine. It is what it is, everyday I try to argue in favour of the project, I still use it for myself everywhere but increasingly things happen that just don't on other volunteer projects... it's rather difficult to argue the case when they can install Ubuntu or whatever nonsense distro is the current favourite and it just works. Just a bit more accurate info would solve it, if it doesn't do X reliably, or Y has changed, note it. You asked a question and got two or three responses back in a day. You mentioned trying different timekeeping choices, but I don't recall seeing what your kern.timecounter sysctl values looked like; without that, folks are missing info that is likely to be relevant. Ah, well Regards, Yeah my gripe isn't with having no responses, the handful of people that have responded have been helpful but ultimately no responses from anyone involved. Just a one liner saying we changed the timecounter stuff in 9, look at sysctl tree X would have been more than sufficient, this sort of thing should really be mentioned in the relnotes though... For the record though, setting kern.eventtimer.periodic to 1 fixes the problem on all affected machines (returns my virtualbox guest to normality, reduces the drift on physical machines to 8.2 figures). FWIW, I can't even see any notes relating to this in UPDATING either. I should probably clarify here that some responses were received from the maintainers (eg: Qing for mpath) for a couple of bits of code but the wider issues weren't discussed further. I'm not trying to say that no effort is made, but as a whole for the project to be comparable to the alternatives this sort of thing shouldn't happen. ___ 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: Strange 'hangs' with RELENG_9
On 2012.01.19., at 21:03, Andriy Gapon wrote: László, can you please try changing kern.timecounter.hardware to TSC-low or ACPI-fast? No results, the machine still does hang :( Tried all options. Any other suggestions? -- László Károlyi http://linkedin.com/in/karolyi ___ 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: Strange 'hangs' with RELENG_9
On 2012.01.19., at 22:36, Andriy Gapon wrote: on 19/01/2012 23:24 László Károlyi said the following: On 2012.01.19., at 21:03, Andriy Gapon wrote: László, can you please try changing kern.timecounter.hardware to TSC-low or ACPI-fast? No result, the machine still does hang :( Tried all options. While you are there, can you try changing the eventtimer choice instead? E.g. to LAPIC. Looks like this solved the hang problem. No system hang in the last 10 minutes. Shall i make a sysctl.conf entry to change this value by default, or what do you suggest? I'll do a reboot now, to see if there will be a kernel panic at reboot, I compiled the kernel now with all the debug options. When it panicks, I'll post another screenshot of the console, this time a bigger one, as I managed to change the resolution of the console. -- László Károlyi http://linkedin.com/in/karolyi ___ 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: Strange 'hangs' with RELENG_9
on 19/01/2012 23:47 László Károlyi said the following: On 2012.01.19., at 22:36, Andriy Gapon wrote: on 19/01/2012 23:24 László Károlyi said the following: On 2012.01.19., at 21:03, Andriy Gapon wrote: László, can you please try changing kern.timecounter.hardware to TSC-low or ACPI-fast? No result, the machine still does hang :( Tried all options. While you are there, can you try changing the eventtimer choice instead? E.g. to LAPIC. Looks like this solved the hang problem. No system hang in the last 10 minutes. Shall i make a sysctl.conf entry to change this value by default, or what do you suggest? You can do that via loader.conf or sysctl.conf. The first option should be more reliable. What you see can mean two things (at least that's what I can think of): - problems/quirks with HPET hardware on your system - problems with IPI forwarding of time ticks between CPUs Maybe there would be additional requests for debugging info if you are interested in pursuing this further and are able to provide the info. I'll do a reboot now, to see if there will be a kernel panic at reboot, I compiled the kernel now with all the debug options. When it panicks, I'll post another screenshot of the console, this time a bigger one, as I managed to change the resolution of the console. -- Andriy Gapon ___ 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: Strange 'hangs' with RELENG_9
On 2012.01.19., at 22:47, László Károlyi wrote: I'll do a reboot now, to see if there will be a kernel panic at reboot, I compiled the kernel now with all the debug options. When it panicks, I'll post another screenshot of the console, this time a bigger one, as I managed to change the resolution of the console. And here we go, another kernel panic at reboot: http://img828.imageshack.us/img828/2433/crashw.png -- László Károlyi http://linkedin.com/in/karolyi ___ 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
Odd reboot problems with 9.0-RELEASE i386
Hi all, I recently upgraded my 8.2-RELEASE box to 9.0-RELEASE using the old-fashioned cvsup way. I've run into a really strange situation. Everything went smoothly with the upgrade. I then deleted all my installed ports and started reinstalling. I noticed the problem when trying to compile openjdk6. The box would spontaneously reboot. All the time. So, I put the following into /etc/rc.conf. I'll repost here, it's entirely possible I did something wrong: dumpdev=/dev/ada0s1b # Device to crashdump to (device name, AUTO, or NO). dumpdir=/usr/crash/# Directory where crash dumps are to be stored I made sure /usr/crash was created and had permissions wide open. Yet, I never got any crash dumps (I recreated the reboot several times over.) I tried compiling a GENERIC kernel; that failed as well. So I got the DVD iso, and copied over the /boot/kernel directory from it. Once I did that, i was able to compile a new GENERIC kernel no problem. (I need to take out the pcn driver; I need le and pcn jumps it.) With the slightly-modified GENERIC kernel, the problem has disappeared. I've compiled openjdk no problem. I tried recompiling my custom kernel and reinstalled it; the problem reappeared. I've attached my kernel config file; there's nothing revolutionary about it. It's almost identical to the one I used for 8.2-RELEASE, but based on the new 9.0 GENERIC. Maybe someone here will find it useful. A cc would be appreciated as I don't follow -stable. Cheers, DMK # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.553.2.7.2.1 2011/11/11 04:20:22 kensmith Exp $ #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident ADMINPC5 makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD# New Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options
Re: Fighting with vnet / jails epair and so on
On 19/01/12 18:22, Denny Schierz wrote:
hi,
Am 18.01.2012 um 23:21 schrieb Philipp Huebner:
I use 9.0.0 release for host and jail and a generic kernel with
OPTIONS VIMAGE being the only change/addition. No problem.
so, how looks your rc.conf config ? Do you use vimage the tool? I
can't use vimage (as I know) on sparc64.
/etc/rc.conf
=
jail_enable=YES
jail_v2_enable=YES
jail_dir=/etc/jails
jail_list=`ls ${jail_dir}`
for j in ${jail_list}; do
. ${jail_dir}/${j}
done
=
/etc/jails/dhcp
=
jail_dhcp_name=dhcp
jail_dhcp_hostname=dhcp.vv.fda
jail_dhcp_devfs_enable=YES
jail_dhcp_rootdir=/jails/dhcp/20120110
jail_dhcp_vnet_enable=YES
jail_dhcp_exec_prestart0=ifconfig epair9 create
jail_dhcp_exec_prestart1=ifconfig bridge300 addm epair9a
jail_dhcp_exec_prestart2=ifconfig epair9a up
jail_dhcp_exec_earlypoststart0=ifconfig epair9b vnet dhcp
jail_dhcp_exec_afterstart0=/etc/rc.jail
#jail_dhcp_exec_poststop0=ifconfig bridge300 deletem epair9a
#jail_dhcp_exec_poststop1=ifconfig epair9a destroy
=
/jails/dhcp/20120110/etc/rc.jail
=
#!/bin/sh
. /etc/rc.conf
echo #
echo # Starting JAIL: $hostname
echo #
/etc/rc.d/netif start
route add default $defaultrouter
/etc/rc.d/sshd start
/usr/local/etc/rc.d/nrpe2 start
/usr/local/etc/rc.d/isc-dhcpd start
echo #
echo # JAIL $hostname is now up and running!
echo #
echo
==
I do not use (and never have) the vimage commandline tool.
Regards,
Philipp
___
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: Fighting with vnet / jails epair and so on
On 19. Jan 2012, at 22:33 , Philipp Huebner wrote: On 19/01/12 18:22, Denny Schierz wrote: hi, Am 18.01.2012 um 23:21 schrieb Philipp Huebner: I use 9.0.0 release for host and jail and a generic kernel with OPTIONS VIMAGE being the only change/addition. No problem. so, how looks your rc.conf config ? Do you use vimage the tool? I can't use vimage (as I know) on sparc64. ... I do not use (and never have) the vimage commandline tool. Are you sure you (reading and posting here, plural, in general) sure, that you don't want to read up on freebsd-jail and give the framework a try which might make your life easier... http://lists.freebsd.org/pipermail/freebsd-jail/2011-July/thread.html#1568 I am sure Jamie would like feedback and now that 9.0 is done get review and get it in... /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Odd reboot problems with 9.0-RELEASE i386
On Thu, 2012-01-19 at 14:06 -0800, Dwayne MacKinnon wrote: Hi all, I recently upgraded my 8.2-RELEASE box to 9.0-RELEASE using the old-fashioned cvsup way. I've run into a really strange situation. Everything went smoothly with the upgrade. I then deleted all my installed ports and started reinstalling. I noticed the problem when trying to compile openjdk6. The box would spontaneously reboot. All the time. So, I put the following into /etc/rc.conf. I'll repost here, it's entirely possible I did something wrong: dumpdev=/dev/ada0s1b # Device to crashdump to (device name, AUTO, or NO). dumpdir=/usr/crash/# Directory where crash dumps are to be stored I made sure /usr/crash was created and had permissions wide open. Yet, I never got any crash dumps (I recreated the reboot several times over.) I tried compiling a GENERIC kernel; that failed as well. So I got the DVD iso, and copied over the /boot/kernel directory from it. Once I did that, i was able to compile a new GENERIC kernel no problem. (I need to take out the pcn driver; I need le and pcn jumps it.) With the slightly-modified GENERIC kernel, the problem has disappeared. I've compiled openjdk no problem. I tried recompiling my custom kernel and reinstalled it; the problem reappeared. I've attached my kernel config file; there's nothing revolutionary about it. It's almost identical to the one I used for 8.2-RELEASE, but based on the new 9.0 GENERIC. Maybe someone here will find it useful. A cc would be appreciated as I don't follow -stable. Cheers, DMK This sounds suspciously like a bug the ports team found on the the 9 RC series. I can't recall where it got fixed, but I'm pretty sure it did *not* make it to the release. You may have better luck with stable/9 instead of 9.0-RELEASE if you can do that. Sean ___ 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: Strange 'hangs' with RELENG_9
On Thu, 2012-01-19 at 21:46 +0200, Alexander Motin wrote: On 01/19/12 21:05, Ian Lepore wrote: I saw in the eventtimers(7) manpage that there's a sysctl to change the timer, but when I used it the system timing went completely wonky (ntpd reported it was off by many seconds, a few seconds after I changed it). When I just tried it again the system locked up and had to be power cycled. (I'm trying this on old hardware where my only choices are i8254 and RTC, and changing to RTC apparently doesn't work well.) So I didn't want to recommend it to someone else. :) That's strange. On all systems I have, I can safely set any event timer in any way. Though for better precision it is better to set them using loader tunable. As it turns out, this isn't a problem with eventtimers in any way, sorry for the confusion. I had checked out and built a completely clean RELENG_9_0_0_RELEASE so that I could be sure I was testing against the offical release before telling the OP I do/don't see similar problems. As it turns out, one of my local hacks is required if I want use the RTC clock for anything (buggy old hardware). Once I applied that patch, I can now switch eventtimers without any problems. -- Ian ___ 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: Timekeeping in stable/9
.. if you have a _reproducable_ case for this, mav@ needs to see it ASAP. The trouble is that mav@ isn't handed reproducable cases and thus can't debug it. If you can supply some kind of box that provides this as a reproducable issue, we can get it fixed ASAP. Otherwise it's a case of can't reproduce in our environments, sorry. Adrian On 19 January 2012 13:09, Joe Holden li...@rewt.org.uk wrote: Joe Holden wrote: Chuck Swiger wrote: On Jan 19, 2012, at 12:18 PM, Joe Holden wrote: Sounds like you were looking for commercial support, since unpaid volunteers don't have an obligation to promptly leap out and provide solutions within your ETA. Not really, just an acknowledgement would be fine. It is what it is, everyday I try to argue in favour of the project, I still use it for myself everywhere but increasingly things happen that just don't on other volunteer projects... it's rather difficult to argue the case when they can install Ubuntu or whatever nonsense distro is the current favourite and it just works. Just a bit more accurate info would solve it, if it doesn't do X reliably, or Y has changed, note it. You asked a question and got two or three responses back in a day. You mentioned trying different timekeeping choices, but I don't recall seeing what your kern.timecounter sysctl values looked like; without that, folks are missing info that is likely to be relevant. Ah, well Regards, Yeah my gripe isn't with having no responses, the handful of people that have responded have been helpful but ultimately no responses from anyone involved. Just a one liner saying we changed the timecounter stuff in 9, look at sysctl tree X would have been more than sufficient, this sort of thing should really be mentioned in the relnotes though... For the record though, setting kern.eventtimer.periodic to 1 fixes the problem on all affected machines (returns my virtualbox guest to normality, reduces the drift on physical machines to 8.2 figures). FWIW, I can't even see any notes relating to this in UPDATING either. I should probably clarify here that some responses were received from the maintainers (eg: Qing for mpath) for a couple of bits of code but the wider issues weren't discussed further. I'm not trying to say that no effort is made, but as a whole for the project to be comparable to the alternatives this sort of thing shouldn't happen. __**_ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**stablehttp://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscribe@**freebsd.orgfreebsd-stable-unsubscr...@freebsd.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
