Re: GELI performance on Atom D525
On Sat, Jan 5, 2013 at 4:58 PM, Wiktor Niesiobedzki b...@vink.pl wrote: Hi, Can anyone with access to Atom D525 processor can do a performance check for me: # kldload geom_eli # kldload geom_zero # sysctl kern.geom.zero.clear=0 # geli onetime -s 4096 -l 256 -e aes-cbc gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 # geli kill gzero # geli onetime -s 4096 -l 256 -e aes-xts gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 I'm interested in dd outputs ofcourse. I would like to compare this to VIA Esther processor 1000MHz, which has padlock AES accelerator. My results are: AES-CBC: 4294967296 bytes transferred in 31.805894 secs (135036836 bytes/sec) AES-XTS: 4294967296 bytes transferred in 765.232668 secs (5612629 bytes/sec) Anyone can provide the results for Atom D525? FreeBSD 9.0-RELEASE-p1 amd64: CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1800.04-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106ca Family = 6 Model = 1c Stepping = 10 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=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics # sysctl kern.geom.zero.clear=0 kern.geom.zero.clear: 1 - 0 # geli onetime -s 4096 -l 256 -e aes-cbc gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 192.024101 secs (22366814 bytes/sec) # geli kill gzero # geli onetime -s 4096 -l 256 -e aes-xts gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 232.956895 secs (18436747 bytes/sec) - Max ___ 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: SU+J on 9.1-RC2 ISO
On Sat, Nov 3, 2012 at 10:10 AM, Mark Felder f...@feld.me wrote: On Fri, 2 Nov 2012 23:13:43 +0100 Bas Smeelen b.smee...@ose.nl wrote: I have submitted a PR with patch, see how it goes Cheers Why aren't we patching the dump utility to error/exit saying it's not compatible with SUJ at this time? Update the descriptions in the installer, but leave SUJ as default and patch dump. If I understood Mateusz correctly, r230725 already took care of the panic, so there is no need to modify dump. That, however, still doesn't solve all problems: http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html - Max ___ 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: SU+J on 9.1-RC2 ISO
On Fri, Nov 2, 2012 at 1:13 PM, Mike Jakubik mike.jaku...@intertainservices.com wrote: On Sat, 2012-11-03 at 00:05 +0700, Adam Strohl wrote: On 11/2/2012 23:47, Bas Smeelen wrote: Hi Why are journaled soft updates the default when installing a new system from a 9.1-RC2 ISO? Can SU+J be disabled for the 9.1-RELEASE or do you think this is not going to be a problem for users of FreeBSD? I will have to boot these two systems single user now to disable the soft updates journal, because I use dump + restore on live systems, not a problem for me, it is just an inconvenience. I have to second this sentiment. Unless the dump/snapshot issue has been resolved they journal should be turned off by default. It's a really nasty bug that causes an instant panic which is awful if the server is in production. The fact that it happens when you're trying to exercise due diligence (ie; backups) is even worse. You can disable SU+J after installing, though it would be nice if the installer gave you a choice. I don't think SU+J should even be an option in the installer as long as this bug persists. If you don't use dump, go ahead and enable journaling after the installation, but it's not a decision that new users should be asked to make. This should not have been the default in 9.0-RELEASE and I'm surprised to see that it's still not fixed in 9.1. - Max ___ 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: FreeBSD 9 crash/deadlock when dump(8)ing file system with journaling enabled.
On Mon, Jan 30, 2012 at 9:38 AM, Ivan Voras ivo...@freebsd.org wrote: On 30/01/2012 13:06, Jeremy Chadwick wrote: For now I've turned off journaling (soft updates seem fine) and that works around the issue. Let me know if I can provide more details etc! I'm not sure, but this may be an after-effect of known problems right now with SU+J on 9.0. It would help if you could state if you're using dump -L or not. I've seen the deadlock behaviour you describe on older FreeBSD versions (dating back to at least 7.x) when using dump -L, which generates a fs snapshot. Obviously 7.x does not have SU+J, so I'm a little surprised disabling journalling fixes the problem for you. It's a known bug: SU+J currently deadlocks when used with UFS snapshots. Is there any additional information somewhere on when this is expected to be fixed? Seems like a fairly significant problem to me, especially since SU+J is the default when creating new file systems with bsdinstall. - Max ___ 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
twa (3ware 9690SA) error on shutdown
I'm playing around with the 3ware 9690SA raid controller. At first, I was using FreeBSD 8.0-BETA2, but it kept encountering errors after start-up and on shutdown. There is no 8.x driver on the 3ware site, so I decided to go back to 7.2-RELEASE. This, however, did not solve the problem. The major one that I'm having right now is that the system refuses to reboot. After issuing the command, this is what I see toward the end: Uptime: 9h41m43s twa0: ERROR: (0x15: 0x1104): Internal request timed out: request = 0xfffe80223a28 twa0: INFO: (0x16: 0x1108): Resetting Controller...: twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=1 twa0: INFO: (0x16: 0x1107): Controller reset done!: twa0: ERROR: (0x15: 0x1015): Can't close connection with controller: error = 60 twa0: ERROR: (0x05: 0x2015): Failed to shutdown Common Layer/controller: error = 60 Here the system freezes and I have to hold the power button for 5 sec to turn the power off and then restart. This happened with the default twa driver, so I downloaded the 9.5.2 code set from 3ware website and tried to use the twa.ko that comes with that release (for amd64). This also did not fix the problem. There is one other issue that may be related to this one. The verify process for a newly created array is never finished. When the system is started, I see a verify started message and the activity leds of the drivers connected to the controller light up. If I reboot the system at this point, the first problem does not occur. On other hand, if I wait maybe 5 minutes the activity lights turn off, indicating that something happens to the verify process, and at this point I can no longer reboot the system. My guess is that the verify process causes some sort of a problem for the driver or the controller itself, which then prevents normal communication during shutdown. Has anyone else encountered this problem or has a solution for it? - Max ___ 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: FreeBSD 7, runaway clock as guest OS on Microsoft Virtual Server
On Wed, Jan 21, 2009 at 2:41 PM, Jeffrey Williams j...@sailorfej.net wrote: Hi Folks, I am trying to run FreeBSD 7 on Microsoft Virtual Server 2005 R2, Windows Server 2003, on a Dell 2950. I am having a problem with the system clock running excessively fast, I initially tried installing 7.1 release but received a nearly continuous stream of the calcru: runtime went backward errors, I tried rolling back to 7.0, and it improved somewhat, but I still received regular calcru errors, and it the system clock was running to fast for ntpd to keep up with it, I set sysctl kern.timecounter.hardware to i8254 (it tries to default to ACPI-safe), which helped more, ntpd is now able to keep pace with it, but only barely, and I haven't seen any calcru errors yet. From the boot time dmesg, on the CPU line, the frequency reported with in the parenthesizes varies on almost every reboot. Are there any other adjustments I can make to get this under control? Have you tried reducing the value of kern.hz (kern.hz=100 in /boot/loader.conf)? That fixes some clock-related problems on VMWare Server. - Max ___ 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: How to get djbdns to start early enough to satisfy ntpd at boot?
On Thu, Jan 15, 2009 at 12:14 AM, Andrew Reilly andrew-free...@areilly.bpc-users.org wrote: Hi there, I've been a happy djbdns+tinydns user for many, many years. I want to keep using it, so answers of the form bletch! Use ISC BIND the way BSD intended will be ignored :-) Having said that, one annoying consequence of my transition some time ago to using ntpd, rather than just setting the clock once-off with ntpdate as I used to, is that the /etc/rc.d mechanism starts ntpd before /usr/local/etc/rc.d/svscan.sh starts svscan, which starts /services/dnscache. That wouldn't matter if ntpd was a bit sensible and just kept trying to find its nomminated servers, but it gives up and just sits there not synchronising time from any reference. So I have to remember to manually /etc/rc.d/ntpd restart every time I reboot. So: does anyone know how to modify the boot-time order so that svscan starts at (or before) the point in the boot cycle where BIND would, on other systems? I suspect that it should be possible by changing the PROVIDE: in svscan.sh to include one of the things REQUIRE:'d by ntpd. Or perhaps the REQUIRE: LOGIN in svscan.sh is incompatible with the BEFORE: LOGIN in ntpd? Has any other user of dnscache encountered and solved this problem? I use the following in svscan.sh, no problems with ntpdate or any other service: # PROVIDE: svscan # REQUIRE: FILESYSTEMS netif pf # BEFORE: routing - Max ___ 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: rm(1) bug, possibly serious
On 9/25/07, Oliver Fromme [EMAIL PROTECTED] wrote: Hi, Today I noticed the following behaviour on a 6-stable machine: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ rm -rf ../ $ Note that the command rm -rf ../ was entered twice. The first time I got an error message (and exit code 1), the second time it apparently succeeded. The very same command. Further investigation: $ cd /tmp $ mkdir -p foo/var $ cd foo/bar $ rm -rf ../ rm: ../: Invalid argument $ ls -al .. ls: ..: No such file or directory $ ls /tmp/foo/bar ls: /tmp/foo/bar: No such file or directory That means: Even though rm -rf ../ prints an error message, indicating that the argument is invalid, it *DOES* remove the contents of the parent directory! To add further confusion, another rm -rf ../ does not print an error message and seemingly succeeds, even though .. does not exist anymore in the current directory (which has been removed). Shall I file a PR? Or is rm working correctly, and my assumptions are wrong? Best regards Oliver Confirmed on CURRENT as well. Note that if you run rf -rf .. as the first command, the command does fail with 'rm: . and .. may not be removed'. Adding a / at the end does seem to get around this check. - Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question regarding Intel ICH7 motherboard and integrated RAID
On 9/16/07, Howard Goldstein [EMAIL PROTECTED] wrote: Karl Denninger wrote: Hi folks; I have a new Intel ICH7 board here that has Quad-core support. It works well EXCEPT It has an on-board RAID controller with some internal buffer memory. There's a known issue with an interrupt storm when the ICH7R is configured for AHCI or RAID, and a pr was filed back in July(don't have the number, search for interrupt storm on atapci1+). The suspicion was that some peripheral no one has identified yet is hammering the apic and we can't mask it. The workaround is to set the BIOS for IDE mode. It's a bit of a drag because SATA-II mode isn't reached when in IDE mode, only in AHCI (and RAID?) mode. If you don't panic when you set it for IDE mode then you've probably run into the same problem. On the plus side FreeBSD on the Q6600 *rocks* and our geom stuff does the RAIDdy stuff nicely for a software solution. I sympathize with you as I spent most of the day yesterday trying to work this same problem. Does this issue affect ICH9R as well? I'm about to get Gigabyte's GA-P35-DQ6 motherboard (also with Q6600) and was planning on configuring RAID10 array using the on-board ICH9R chipset. Are you saying that this doesn't current work (on 7-CURRENT), or that there are performance issues with such setup? I need to be able to dual-boot Win XP on the machine, so my plan was to get 4 320GB drives (later expanded to 6), put them into RAID10 array and that way get good redundancy and performance in both operating systems. Would you suggest I go about doing this some other way? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB devices fail to re-attach on 6.2
On 3/31/07, Maxim Khitrov [EMAIL PROTECTED] wrote: Right now I don't even mount it. I boot the system up, insert the drive, give it a few seconds, and then remove it. After I've done this once, attaching the drive a second time doesn't work. - Max Ok, I think I figured it out. Here's basically what I was doing... Besides my flash drive, I had a usb hard drive (Vantec NexStar 2.5 enclosure) connected to the laptop. FreeBSD was installed onto the USB hard drive, because I wanted to download the source and put just the things I needed onto the actual laptop drive. That, and I was also doing full-disk encryption using GELI, so I needed an external OS to do this work. At this point in time, I have the system running from the build-in drive, which means that I can disconnect the usb one. Guess what happens when that drive is removed? Everything works normally again. I can connect and disconnect the flash drive as many times as I want and it works every time. But as soon as I connect the Vantec enclosure, even if I don't use it, I can only connect the flash drive once. After that, we're back to the original problem. Does anyone have a guess as to why the external enclosure would cause this sort of a problem? Could it be consuming too much power (but then why is the flash drive detected the first time)? - Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
USB devices fail to re-attach on 6.2
Hello everyone, I just installed FreeBSD 6.2 release on my Fujitsu P7010 laptop just to see how well it'll work. The problem I'm having is that if I connect a USB device, for example, my OCZ mini-kart flash drive, it'll work perfectly the first time. However, if I disconnect it and reconnect it again, it is not detected the second time. It's the same thing with my Logitech mouse. When the flash drive is connected the first time, it is placed on scbus2. If I reconnect it and try running 'camcontrol rescan scbus2' or 'camcontrol rescan all', no new devices show up. I'm fairly new to FreeBSD, so if there are some other tools I should try, please let me know. Does anyone have ideas on what could be causing the problem? The dmesg.boot contents are listed below. This is a clean installation and I haven't yet made any changes to it, just installed the minimal FreeBSD + man pages. Thanks, Maxim Khitrov Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1100MHz (600.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9f9bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE Features2=0x180EST,TM2 real memory = 527368192 (502 MB) avail memory = 506642432 (483 MB) kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: FUJ FJNB189 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xfc08-0xfc0b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral at device 0.1 (no driver attached) pci0: base peripheral at device 0.3 (no driver attached) agp0: Intel 82855GME (855GME GMCH) SVGA controller port 0x1800-0x1807 mem 0xd800-0xdfff,0xd000-0xd007 irq 11 at device 2.0 on pci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M pci0: display at device 2.1 (no driver attached) uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0x1820-0x183f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801DB (ICH4) USB controller USB-B port 0x1840-0x185f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: Intel 82801DB/L/M (ICH4) USB 2.0 controller mem 0xd010-0xd01003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: Intel 82801DB/L/M (ICH4) USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered umass0: vendor 0x0402 USB 2.0 Storage Device, rev 2.00/1.00, addr 2 pcib1: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib1 cbb0: RF5C476 PCI-CardBus Bridge irq 11 at device 10.0 on pci1 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb1: RF5C476 PCI-CardBus Bridge irq 11 at device 10.1 on pci1 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 fwohci0: Ricoh R5C552 mem 0xd020-0xd02007ff irq 11 at device 10.2 on pci1 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:0e:10:02:81:d2:7a fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:00:0e:81:d2:7a fwe0: Ethernet address: 02:00:0e:81:d2:7a fwe0: if_start running deferred for Giant sbp0: SBP-2/SCSI over FireWire on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci1: base peripheral at device 10.3 (no driver attached) pci1: base peripheral at device 10.4 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0x2000-0x20ff mem 0xd0201000-0xd02010ff irq 11 at device 12.0 on pci1 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:0b:5d:57:c1:2e pci1: network at device 13.0 (no driver attached) isab0: PCI-ISA bridge at device
Re: USB devices fail to re-attach on 6.2
On 3/31/07, Brian A. Seklecki [EMAIL PROTECTED] wrote: Can you show us your dmesg(8) output as you disconnect and reconnect a device. Here you go: (Connect) umass1: vendor 0x0457 USB Mass Storage Device, rev 2.00/1.00, addr 3 da1 at umass-sim1 bus 1 target 0 lun 0 da1: Flash Drive UT_USB20 0.00 Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 1960MB (4014080 512 byte sectors: 255H 63S/T 249C) (Disconnect) umass1: at uhub2 port 2 (addr 3) disconnected (da1:umass-sim1:1:0:0): lost device (da1:umass-sim1:1:0:0): removing device entry umass1: detached After I disconnect the drive the first time, no matter how many times I reconnect or disconnect it, no other messages are added. Are you being careful to umount the file systems on these scsi devices between detaching the underlying USB device? Right now I don't even mount it. I boot the system up, insert the drive, give it a few seconds, and then remove it. After I've done this once, attaching the drive a second time doesn't work. - Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
