Re: freebsd perf testing
On 11/9/13, 1:24 PM, Erik Cederstrand wrote: Hi Julian, Den 08/11/2013 kl. 03.02 skrev Julian Elischer jul...@elischer.org: Some time ago someone showed some freebsd performance graphs graphed against time. He had them up on a website that was updated each day or so. I think they were network perf tests but I'm not sure. He indicated that he was going to continue the daily testing but I've not seen any mention of them since. If you know who that was or how to find him let me (or gnn) know... I did a master’s thesis on this some years ago. I haven’t kept the project up-to-date, due to lack of time and hardware. it would be interesting to know what you did. and what conclusions you came to.. the actual web page I was thinkng of was: http://lists.freebsd.org/pipermail/freebsd-current/2013-April/041323.html but the more players we have thinking about this the better.. it would be good if we could have some project supported way to follow this. it may be that we could make a 'contributor' image that has all the tools and framework on it that would allow people to submit daily reports (from the same hardware each time) to some central aggregator.. or maybe ot would all be project resources. I see that Mr Symbolics (is that his real name?) has some suggestions in another mail in this thread. I wasn't really going to be doing much in this space myself though I think it is important, I just volunteered in the meeting to try find some examples. Julian Erik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) hangs after r257133
On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link 5300 to hang after only a few moments of use. For now, I've just reverted only those aspects of r257133, enabling MRR and keeping the rate index lookup, which seems to do something on my hardware at least (I assume it's not the right thing based on Adrian's analysis, but it works never-the-less). Has anyone else hit this with Intel WiFi hardware? Also, what needs to be done to have MRR working properly? Hi, I have problems with iwn (Intel WiFi Link 5100) as well. Unlike my previous problems, it associates properly and works fine, at first. But then, after some minutes, the link quality somehow deteriorates and I see serious packet drops. Usually it gets back to normal some minutes later, but restarting the interface fixes the problem. I don't think it's a problem with the signal itself, because other devices next to the notebook work just fine during that intervals. Adrian, do you have any ideas, or some data you want from me? Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) hangs after r257133
yup, same info as brandon. :) -a On 10 November 2013 04:17, Stefan Farfeleder stef...@freebsd.org wrote: On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link 5300 to hang after only a few moments of use. For now, I've just reverted only those aspects of r257133, enabling MRR and keeping the rate index lookup, which seems to do something on my hardware at least (I assume it's not the right thing based on Adrian's analysis, but it works never-the-less). Has anyone else hit this with Intel WiFi hardware? Also, what needs to be done to have MRR working properly? Hi, I have problems with iwn (Intel WiFi Link 5100) as well. Unlike my previous problems, it associates properly and works fine, at first. But then, after some minutes, the link quality somehow deteriorates and I see serious packet drops. Usually it gets back to normal some minutes later, but restarting the interface fixes the problem. I don't think it's a problem with the signal itself, because other devices next to the notebook work just fine during that intervals. Adrian, do you have any ideas, or some data you want from me? Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 11/09/13 21:23, Allan Jude wrote: On 2013-11-09 21:13, Adrian Chadd wrote: On 9 November 2013 17:58, Allan Jude free...@allanjude.com wrote: Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. ahh, right, why didn't I think of that I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian If the cron daemon is just scanning /etc/cron.d/* and treating it as if those lines had been appended to /etc/crontab I don't see why you couldn't just cp in the post-install. I think it would be better if you didn't have to 'register' a change. For this whole thread, please s,/etc/rc.d,/usr/local/etc/rc.d,g -- George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
new Xorg (KMS, etc.) for Radeon 9600
I've built the ports with the following lines in my /etc/make.conf: WITH_NEW_XORG=1 WITH_KMS=1 WITH_GALLIUM=1 And I've attempted to run ``startx''. The compiler was a very recent version of Clang. When building the kernel (not the ports): == /etc/make.conf snippet begins == CPUTYPE?=native CXXFLAGS+= -stdlib=libc++ KERNCONF=MYKERNCONF MODULES_OVERRIDE=drm2 == /etc/make.conf snippet ends == == /sys/i386/conf/MYKERNCONF begins == cpu I686_CPU ident MYKERNCONF options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem 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=1000 # Delay (in ms) before probing SCSI 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. # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic# I/O APIC # Bus support. device acpi device pci # ATA controllers device ata # Legacy ATA/SATA controllers # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device rl # RealTek 8129/8139 # Pseudo devices. device loop# Network loopback device random # Entropy device device ether # Ethernet support device md # Memory disks device firmware# firmware assist module # USB support device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device ehci# EHCI PCI-USB interface (USB 2.0) device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # Sound support device sound # Generic sound driver (required) device snd_ich # Intel, NVidia and other ICH AC'97 Audio device drm device radeondrm device iicbus device iic device iicbb == /sys/i386/conf/MYKERNCONF ends == == /etc/X11/xorg.conf begins == Section ServerFlags Option DontZoom on Option VTSysReq on # #Option BlankTime 1 # #Option StandbyTime 2 # #Option SuspendTime 3 # #Option OffTime 4 # Option HandleSpecialKeys Always Option AIGLX off Option GlxVisuals minimal Option AllowEmptyInput off Option AutoAddDevices off Option AutoEnableDevices off EndSection Section InputDevice Identifier mouse1 Driver mouse Option Device /dev/ums0 EndSection Section InputDevice Identifier keyboard1 Driver kbd Option XkbLayout us,hu Option AutoRepeat 320 29 EndSection Section Device Identifier card1 Driver radeon VideoRam 131072 #Option ScalerWidth 1920 Option AGPMode 8 #Option AGPFastWrite on # sux Option BusType AGP Option DisplayPriority HIGH Option
Re: cron(8) improvement
On 2013-11-10 09:04, George Mitchell wrote: On 11/09/13 21:23, Allan Jude wrote: On 2013-11-09 21:13, Adrian Chadd wrote: On 9 November 2013 17:58, Allan Jude free...@allanjude.com wrote: Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. ahh, right, why didn't I think of that I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian If the cron daemon is just scanning /etc/cron.d/* and treating it as if those lines had been appended to /etc/crontab I don't see why you couldn't just cp in the post-install. I think it would be better if you didn't have to 'register' a change. For this whole thread, please s,/etc/rc.d,/usr/local/etc/rc.d,g -- George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org We have never once mentioned /etc/rc.d rc.conf.d is an entirely different system (extending rc.conf) and I proposed both /etc/cron.d/ (stuff you'd normally add to /etc/crontab) and /usr/local/etc/cron.d/ (packages) -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On Sun, 10 Nov 2013, Daniel O'Connor wrote: On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. That would be my preference also. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) hangs after r257133
On Sun, Nov 10, 2013 at 05:14:58AM -0800, Adrian Chadd wrote: yup, same info as brandon. :) http://pastebin.com/MwfL06z7 Stefan On 10 November 2013 04:17, Stefan Farfeleder stef...@freebsd.org wrote: On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link 5300 to hang after only a few moments of use. For now, I've just reverted only those aspects of r257133, enabling MRR and keeping the rate index lookup, which seems to do something on my hardware at least (I assume it's not the right thing based on Adrian's analysis, but it works never-the-less). Has anyone else hit this with Intel WiFi hardware? Also, what needs to be done to have MRR working properly? Hi, I have problems with iwn (Intel WiFi Link 5100) as well. Unlike my previous problems, it associates properly and works fine, at first. But then, after some minutes, the link quality somehow deteriorates and I see serious packet drops. Usually it gets back to normal some minutes later, but restarting the interface fixes the problem. I don't think it's a problem with the signal itself, because other devices next to the notebook work just fine during that intervals. Adrian, do you have any ideas, or some data you want from me? Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
On Sun, 10 Nov 2013, d...@gmx.com wrote: I've built the ports with the following lines in my /etc/make.conf: WITH_NEW_XORG=1 WITH_KMS=1 WITH_GALLIUM=1 And I've attempted to run ``startx''. My -current is still from ~July 3, and I also got panics when trying new Xorg. Take the drm devices out of your kernel configuration and let X load the necessary drm2 devices when it starts. This allowed it to work for me. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On 2013-11-10 11:21, Warren Block wrote: On Sun, 10 Nov 2013, Daniel O'Connor wrote: On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. That would be my preference also. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) I envisioned crond just scanning the directory for added/removed files, rather than some 'add it to cron' system, and cron doesn't read/parse the rc.conf system. maybe it makes most sense to make it scan /usr/local/etc/cron.d/*.cron So ports can install rsnapshot.cron.sample that the user must manually enable (like we do with config files) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
Warren Block schrieb: [...] ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. Given the above scenario, would it be acceptable to set the entry in rc.conf, $portname_cron=YES, to $portname_cron=NO without touching the modified files and inform the user about having done so? Philipp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
Daniel Eischen wrote, On 11/10/2013 17:40: My -current is still from ~July 3, and I also got panics when trying new Xorg. Take the drm devices out of your kernel configuration and let X load the necessary drm2 devices when it starts. This allowed it to work for me. Hmm, works for me to avoid panics and hard reboots. Problems: 1. Switching to the virtual terminals or shutting down X causes the display to go black and unrevivable -- a (soft) reboot is necessary. 2. A 3D application crashes with SIGBUS, and the stack gets toasted. == dmesg begins == Copyright (c) 1992-2013 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 11.0-CURRENT #6 r257831M: Sun Nov 10 17:55:45 CET 2013 root@:/usr/obj/usr/src/sys/CUSTOM i386 clang version 3.4 (trunk 194164) CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2999.72-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Family = 0xf Model = 0x4 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x441dSSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR TSC: P-state invariant real memory = 536870912 (512 MB) avail memory = 515149824 (491 MB) Event timer LAPIC quality 400 ACPI APIC Table: A M I OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard random: Software, Yarrow initialized acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1ff0 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82865 host to AGP bridge on hostb0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xa800-0xa8ff mem 0xd000-0xdfff,0xff0f-0xff0f irq 16 at device 0.0 on pci1 vgapci1: VGA-compatible display mem 0xc000-0xcfff,0xff0e-0xff0e at device 0.1 on pci1 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xe000-0xe01f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xe400-0xe41f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xe800-0xe81f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xec00-0xec1f irq 16 at device 29.3 on pci0 usbus3 on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xff2ffc00-0xff2f irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 rl0: RealTek 8139 10/100BaseTX port 0xb800-0xb8ff mem 0xff1ffc00-0xff1ffcff irq 22 at device 5.0 on pci2 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:25:22:10:7c:de isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) pcm0: Intel ICH5 (82801EB) port 0xd800-0xd8ff,0xdc00-0xdc3f mem 0xff2ff800-0xff2ff9ff,0xff2ff400-0xff2ff4ff irq 17 at device 31.5 on pci0 pcm0: C-Media Electronics CMI9761 AC97 Codec acpi_button0: Power Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] orm0: ISA Option ROM at iomem 0xc-0xccfff pnpid ORM on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 acpi_throttle0: ACPI CPU Throttling on cpu0 Timecounters tick every 1.000 msec random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen1.1: Intel at usbus1 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00,
Re: cron(8) improvement
On Sun, 10 Nov 2013, Philipp Ost wrote: Warren Block schrieb: [...] ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. Given the above scenario, would it be acceptable to set the entry in rc.conf, $portname_cron=YES, to $portname_cron=NO without touching the modified files and inform the user about having done so? I would not want the system modifying rc.conf for me, but don't have a better idea at present. Maybe move customized cronfiles to an old folder on deinstall, so at least the user could recover them. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
On Nov 10, 2013, at 12:20 PM, d...@gmx.com wrote: Daniel Eischen wrote, On 11/10/2013 17:40: My -current is still from ~July 3, and I also got panics when trying new Xorg. Take the drm devices out of your kernel configuration and let X load the necessary drm2 devices when it starts. This allowed it to work for me. Hmm, works for me to avoid panics and hard reboots. Problems: 1. Switching to the virtual terminals or shutting down X causes the display to go black and unrevivable -- a (soft) reboot is necessary. 2. A 3D application crashes with SIGBUS, and the stack gets toasted. Yes, I can get it to crash also when using a Java-based GUI, but it works for all the basic X apps that I need. I also have the virtual terminal switching problem also, but I think that is being addressed with newsyscons. It really does suck not having a functional X. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) hangs after r257133
Right near the end there you have 'status 83' which means 'transmit failed, long retry hit' (the status codes are in if_iwnreg.h somewhere.) The retry count hit 16, which is the max set for the frame. rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at MCS0, which is a bad sign. But, notice how AMRR increased it to MCS2 at a couple stages, and that _always_ fails. But AMRR waits for 10 frame transmits before it adjusts the rate up or down. So yes, we do need to enable MRR again on iwn for things to behave better. There are other issues when you start doing larger amounts of traffic but I'll cover those later.what? If someone wants to take a crack at correctly implementing the link quality table stuff again then please let me know. As I said before, the link quality table setup code is mostly sane. The problem is actually correctly setting 'linkq' to start at the selected rate, as linkq is an index into that table, not the initial rate. Thanks! -adrian On 10 November 2013 08:33, Stefan Farfeleder stef...@freebsd.org wrote: On Sun, Nov 10, 2013 at 05:14:58AM -0800, Adrian Chadd wrote: yup, same info as brandon. :) http://pastebin.com/MwfL06z7 Stefan On 10 November 2013 04:17, Stefan Farfeleder stef...@freebsd.org wrote: On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link 5300 to hang after only a few moments of use. For now, I've just reverted only those aspects of r257133, enabling MRR and keeping the rate index lookup, which seems to do something on my hardware at least (I assume it's not the right thing based on Adrian's analysis, but it works never-the-less). Has anyone else hit this with Intel WiFi hardware? Also, what needs to be done to have MRR working properly? Hi, I have problems with iwn (Intel WiFi Link 5100) as well. Unlike my previous problems, it associates properly and works fine, at first. But then, after some minutes, the link quality somehow deteriorates and I see serious packet drops. Usually it gets back to normal some minutes later, but restarting the interface fixes the problem. I don't think it's a problem with the signal itself, because other devices next to the notebook work just fine during that intervals. Adrian, do you have any ideas, or some data you want from me? Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) hangs after r257133
And for reference, here's the paper: http://hal.inria.fr/docs/00/07/07/84/PDF/RR-5208.pdf -adrian On 10 November 2013 10:48, Adrian Chadd adr...@freebsd.org wrote: Right near the end there you have 'status 83' which means 'transmit failed, long retry hit' (the status codes are in if_iwnreg.h somewhere.) The retry count hit 16, which is the max set for the frame. rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at MCS0, which is a bad sign. But, notice how AMRR increased it to MCS2 at a couple stages, and that _always_ fails. But AMRR waits for 10 frame transmits before it adjusts the rate up or down. So yes, we do need to enable MRR again on iwn for things to behave better. There are other issues when you start doing larger amounts of traffic but I'll cover those later.what? If someone wants to take a crack at correctly implementing the link quality table stuff again then please let me know. As I said before, the link quality table setup code is mostly sane. The problem is actually correctly setting 'linkq' to start at the selected rate, as linkq is an index into that table, not the initial rate. Thanks! -adrian On 10 November 2013 08:33, Stefan Farfeleder stef...@freebsd.org wrote: On Sun, Nov 10, 2013 at 05:14:58AM -0800, Adrian Chadd wrote: yup, same info as brandon. :) http://pastebin.com/MwfL06z7 Stefan On 10 November 2013 04:17, Stefan Farfeleder stef...@freebsd.org wrote: On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link 5300 to hang after only a few moments of use. For now, I've just reverted only those aspects of r257133, enabling MRR and keeping the rate index lookup, which seems to do something on my hardware at least (I assume it's not the right thing based on Adrian's analysis, but it works never-the-less). Has anyone else hit this with Intel WiFi hardware? Also, what needs to be done to have MRR working properly? Hi, I have problems with iwn (Intel WiFi Link 5100) as well. Unlike my previous problems, it associates properly and works fine, at first. But then, after some minutes, the link quality somehow deteriorates and I see serious packet drops. Usually it gets back to normal some minutes later, but restarting the interface fixes the problem. I don't think it's a problem with the signal itself, because other devices next to the notebook work just fine during that intervals. Adrian, do you have any ideas, or some data you want from me? Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) hangs after r257133
On Sun, Nov 10, 2013 at 10:48:48AM -0800, Adrian Chadd wrote: Right near the end there you have 'status 83' which means 'transmit failed, long retry hit' (the status codes are in if_iwnreg.h somewhere.) The retry count hit 16, which is the max set for the frame. rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at MCS0, which is a bad sign. But, notice how AMRR increased it to MCS2 at a couple stages, and that _always_ fails. But AMRR waits for 10 frame transmits before it adjusts the rate up or down. So yes, we do need to enable MRR again on iwn for things to behave better. There are other issues when you start doing larger amounts of traffic but I'll cover those later.what? If someone wants to take a crack at correctly implementing the link quality table stuff again then please let me know. As I said before, the link quality table setup code is mostly sane. The problem is actually correctly setting 'linkq' to start at the selected rate, as linkq is an index into that table, not the initial rate. Hi, after some trial and error I found out that disabling AMPDU makes my iwn0 usable again. Now I actually see the rate as reported by `list sta' going up and down (mostly between 54M and 121M). Before it was always fixed at 135M. Could this be related? Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd perf testing
Den 10/11/2013 kl. 09.45 skrev Julian Elischer jul...@freebsd.org: it would be interesting to know what you did. and what conclusions you came to.. I created a system with a build server, a set of slaves, and a website to collect and publish the benchmark data in graphs and raw data and highlight significant changes. The build server built FreeBSD and any required ports and benchmark software, and bundled it in installation images complete with a script to run the benchmarks on the slave and push data to the website. The slaves were dedicated machines that booted via PXE, wiped the hard drive, fetched and installed an image and proceeded to run the specified benchmarks. The website published graphs, and the graphs were linked to useful related data like raw measurements, slave hardware, commit messages, changed source files and binaries etc. It actually worked pretty well. I only ran benchmarks over a couple of months of commits, but I did identify some significant regressions in MySQL and some of the unixbench microbenchmarks. I did not spend much time designing the benchmarking strategy, and “symbolics” has many good points there. I did find out that all the current continuous integration / performance benchmark frameworks (Jenkins etc) did not play well with a situation where the entire operating system is reinstalled. A wide range of useful benchmarks can be collected in just 10-20 minutes, but building FreeBSD and all the ports takes much longer than that (1-2 hours using the default procedure from the handbook). Most of my work went into optimizing build times, installation image sizes and slave installation times, so I could build an image in just 10-15 minutes and use ca. 10MB disk space amortized, and install an image on a slave in just 2 minutes (cheap 2008-era hardware). But having a complete archive of ready-to-install images for each commit is a real advantage, not just for performance benchmarking. Imagine being able to fetch a VirtualBox disk image for a random SVN commit, booting it and start debugging right away. Or you could write a script to test if a bug is present in a FreeBSD installation, and then let an automated process do a binary search to find the offending commit in maybe less than an hour. My work was completed in 2008 and would (at least) require updating the scripts to handle the upgrade from GCC to Clang, and from CVS to SVN. Erik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn(4) hangs after r257133
Yes. So one of the.. unfortunately broken things in iwn is the ampdu tx code doesn't do retransmits. So if amrr picks a rate that fails to transmit everything, the driver doesn't retransmit them. It frees them. Now when amrr is enabled the hardware will retry at lower rates until something succeeds. But it still doesn't retransmit things. I believe it should be. So yes its more broken with Mrr disabled. But enabling mrr doesn't fix it. It just makes it less broken. Someone needs to implement ampdu retransmit. The latest iwn code in head at least tells the rate selection code that a total ampdu tx failure occured. This BTW is one of the hangs I fixed - if you hit a point where you never successfully transmitted an ampdu at a rate the rate would never be decreased. Now to be clear. I won't be in implementing ampdu retransmit. I'll maybe fix last multi rate retry once the new hardware support is in. I would really appreciate help here with these. Everyone with iwn hardware will appreciate it :) Thanks, Adrian Adrian On Nov 10, 2013 11:34 AM, Stefan Farfeleder stef...@freebsd.org wrote: On Sun, Nov 10, 2013 at 10:48:48AM -0800, Adrian Chadd wrote: Right near the end there you have 'status 83' which means 'transmit failed, long retry hit' (the status codes are in if_iwnreg.h somewhere.) The retry count hit 16, which is the max set for the frame. rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at MCS0, which is a bad sign. But, notice how AMRR increased it to MCS2 at a couple stages, and that _always_ fails. But AMRR waits for 10 frame transmits before it adjusts the rate up or down. So yes, we do need to enable MRR again on iwn for things to behave better. There are other issues when you start doing larger amounts of traffic but I'll cover those later.what? If someone wants to take a crack at correctly implementing the link quality table stuff again then please let me know. As I said before, the link quality table setup code is mostly sane. The problem is actually correctly setting 'linkq' to start at the selected rate, as linkq is an index into that table, not the initial rate. Hi, after some trial and error I found out that disabling AMPDU makes my iwn0 usable again. Now I actually see the rate as reported by `list sta' going up and down (mostly between 54M and 121M). Before it was always fixed at 135M. Could this be related? Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
On Sun, Nov 10, 2013 at 9:34 AM, Daniel Eischen deisc...@freebsd.orgwrote: On Nov 10, 2013, at 12:20 PM, d...@gmx.com wrote: Daniel Eischen wrote, On 11/10/2013 17:40: My -current is still from ~July 3, and I also got panics when trying new Xorg. Take the drm devices out of your kernel configuration and let X load the necessary drm2 devices when it starts. This allowed it to work for me. Hmm, works for me to avoid panics and hard reboots. Problems: 1. Switching to the virtual terminals or shutting down X causes the display to go black and unrevivable -- a (soft) reboot is necessary. 2. A 3D application crashes with SIGBUS, and the stack gets toasted. Yes, I can get it to crash also when using a Java-based GUI, but it works for all the basic X apps that I need. I also have the virtual terminal switching problem also, but I think that is being addressed with newsyscons. It really does suck not having a functional X. For the record, newcons (not newsyscons) is available for testing. I'll admit that I have not tried it, but there have been quite a few positive reports on it. https://wiki.freebsd.org/Newcons. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd perf testing
On Nov 10, 2013, at 1:05 PM, Erik Cederstrand erik+li...@cederstrand.dk wrote: Imagine being able to fetch a VirtualBox disk image for a random SVN commit, booting it and start debugging right away. I’ve been working on Crochet’s support for building VMWare images recently and have started using that approach to iterate my dev environment (using one VM to build a new VM instead of upgrading in place). Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WEAK_REFERENCE?
On Sat, 9 Nov 2013, Andreas Tobler wrote: anyone interested in this patch to remove the WEAK_ALIAS and introduce the WEAK_REFERENCE? http://people.freebsd.org/~andreast/weak_ref.amd64.diff I have this running since months on amd64 and I have no issues with. I remember having had a communication with bde@ that he is in favour in doing that but I lacked the time to complete. A similar thing is pending for i386 and sparc64. The ppc stuff is already committed since a longer time. If no one is interested, I'm happy to clean up my tree and skip this. I have only minor interest in it. I might have looked at it before. This version formats the backslashes in macro definitions very badly by putting them in random columns between about 96 and 120 instead of in column 72. Bruce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Sun, Nov 10, 2013 at 10:13 AM, Adrian Chadd adr...@freebsd.org wrote: The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. sounds like we need a ports/pkg config system for admins *after* they have been installed, if bsdconfig interface for en-/disabling services is too simple to do what users want. For cron.d I believe only a few will object it. It is only question who should put files in it. Taking dbus/hald for example, that probably belongs to xorg meta-ports to do the necessary works to enable it, if dbus users prefer to enable it manually. And that will involve painful package dependencies. Imagine more complex cases like letting user choose cron tasks to enable. ports/pkg being a wrapper around 3rd party packages, inevitably it will need to decide some default settings in advance for user. For compile time it is probably ok, or user can choose to compile it with different options. Do we need to agree on some common user interface to do the run-time user-adjustable settings for applications? That's probably also subject to what a pkg install should do by definition. -Jia-Shiun. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WEAK_REFERENCE?
On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote: Hi all, anyone interested in this patch to remove the WEAK_ALIAS and introduce the WEAK_REFERENCE? http://people.freebsd.org/~andreast/weak_ref.amd64.diff I have this running since months on amd64 and I have no issues with. I remember having had a communication with bde@ that he is in favour in doing that but I lacked the time to complete. A similar thing is pending for i386 and sparc64. The ppc stuff is already committed since a longer time. If no one is interested, I'm happy to clean up my tree and skip this. I am not sure why do you include the changes to END() in the same patch. Did you looked over the all END() usages on amd64, is it always paired with ENTRY() ? The CNAME() for ELF is the pedantism anyway. Other than the somewhat questionable inclusion of the END() change, which should be committed separately, if ever, I think the change is fine. pgpVQ9H_8Jdey.pgp Description: PGP signature
