Re: [Soekris] net6501 TSC unstable linux 3.7.6 kernel fedora 17, pch_gbe PCI errors fixed
On 2013-02-26 03:13, Eric Malkowski wrote:
> Hi Lon-
>
> Thanks for the response. Can you check what clock you are actually using?
More data:
# cat
/sys/devices/system/clocksource/clocksource0/{available,current}_clocksource
tsc hpet
tsc
# cat /proc/interrupts|grep timer; sleep 1; cat /proc/interrupts|grep timer
0: 93 0 IO-APIC-edge timer
LOC: 27036421 14573576 Local timer interrupts
0: 93 0 IO-APIC-edge timer
LOC: 27036447 14573597 Local timer interrupts
# cat /sys/module/intel_idle/parameters/max_cstate
1
# echo hpet >
/sys/devices/system/clocksource/clocksource0/current_clocksource
[862274.804316] Switching to clocksource hpet
# cat /proc/interrupts|grep timer; sleep 1; cat /proc/interrupts|grep timer
0: 93 0 IO-APIC-edge timer
LOC: 27086015 14607324 Local timer interrupts
0: 93 0 IO-APIC-edge timer
LOC: 27086040 14607346 Local timer interrupts
You might want to check /sys/module/intel_idle/parameters/max_cstate,
just to be sure that no weird kernel patch has screwed it up. But I'd
say your best hope would be to try Peter Neubauer's HPET quirk patch.
Hope this helps.
/Lon
___
Soekris-tech mailing list
Soekris-tech@lists.soekris.com
http://lists.soekris.com/mailman/listinfo/soekris-tech
[Soekris] net6501 TSC unstable linux 3.7.6 kernel fedora 17, pch_gbe PCI errors fixed
Hi Lon- Thanks for the response. Can you check what clock you are actually using? cat /sys/devices/system/clocksource/clocksource0 I'm also curious if your timer interrupts are ticking every HZ (which seems to be 1000 on my system): cat /proc/interrupts; sleep 1; cat /proc/interrupts Take a look at how many timer interrupts go off between checking /proc/interrupts... If you go into /sys/devices/system/clocksource0 you can look at available_clocksource to see what your options are and just echo one of the available ones into current_clocksource to change. I changed mine to tsc and it switched, but I still get interrupts listed every millisecond and I don't know if running with an "unstable" TSC will be a real problem or not... so I switched back to refined-jiffies. From googling around it looks like the "Refined TSC clocksource calibration" message has been in the kernel for a while, but for whatever reason I don't get that message. You do get that message and no sign of the TSC going unstable on yours... interesting. I don't view it as a major problem -- just trying to get this box fairly tuned for a firewall I'll be using it as before putting it into it's final state. On another box I have that has the AMD Geode LX800 CPU (not a soekris or PC engines either but rather a PC-104+ box) I am running and older 2.6.28.4 kernel I configured and built specifically for that hardware -- and it uses the tsc clock with no problems and without a pile of timer interrupts. In this case I've built in the mfgpt timers specific to the Geode and it uses one of them for "clock events" of some sort, but clocksource0 is shown as the tsc on that sytem w/ no unstable complaints -- it says early on "Fast TSC calibration using PIT"... Not sure what might contribute to an unstable TSC. Wish I had time to dig more into it, but I've got other stuff to do. Hopefully some more folks here will chime in -- I do find this stuff interesting and enjoy messing with it! Thanks, -Eric ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] net6501 TSC unstable linux 3.7.6 kernel fedora 17, pch_gbe PCI errors fixed
On 2013-02-25 23:01, Eric Malkowski wrote: > I was hoping to use the TSC for clocksource ... By way of comparison, I have: # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.7.8-net6501 root=UUID=3158adcf-429c-486c-b298-41a3b804b167 ro console=ttyS0,19200n8 intel_idle.max_cstate=1 # dmesg | grep -i clock [0.536808] hpet clockevent registered [0.561046] Switching to clocksource hpet [5.444054] tsc: Refined TSC clocksource calibration: 1599.999 MHz [5.444061] Switching to clocksource tsc [7.380721] rtc_cmos rtc_cmos: setting system clock to 2013-02-16 04:55:01 UTC (1360990501) [9.253939] PTP clock support registered One obvious difference is that I am using the HPET quirks patch from Peter Neubauer. I know very little about what is going on, but perhaps this makes a difference when testing the stability of the TSC. Even if this isn't the case, if you build your kernel with this patch, at least you should have the HPET clock available. So I would recommend trying that. Good luck. /Lon Willett ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
[Soekris] net6501 TSC unstable linux 3.7.6 kernel fedora 17, pch_gbe PCI errors fixed
I was hoping to use the TSC for clocksource since I've read on here that not having interrupts going off every millisecond for the clock would be a performance savings. I'm running an updated kernel 3.7.6 on fedora 17 I'm running the latest 6501 BIOS (rev 1.41c that makes CPU run at 1600 mhz) [root@soekris-6501 ~]# uname -a Linux soekris-6501 3.7.6-102.fc17.i686.PAE #1 SMP Mon Feb 4 17:46:36 UTC 2013 i686 i686 i386 GNU/Linux I'm using these additions on kernel cmdline: pcie_aspm=off intel_idle.max_cstate=1 dmesg | egrep -i clock [0.275344] Switching to clocksource refined-jiffies [1.730903] rtc_cmos rtc_cmos: setting system clock to 2013-02-25 16:42:52 UTC (1361810572) [1.731799] p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition to frequency scaling. You should use that instead of p4-clockmod, if possible. [2.115743] Switching to clocksource tsc [3.762410] Clocksource tsc unstable (delta = 75920774 ns) [3.768036] Switching to clocksource refined-jiffies With the intel_idle.max_cstate=1 it will allow the tsc to be considered and it uses it for a bit, then declares it unstable and switches to jiffies [root@soekris-6501 ~]# cat /proc/interrupts | egrep timer ; sleep 1; cat /proc/interrupts | egrep timer 0: 480637 0 IO-APIC-edge timer LOC: 1130 482017 Local timer interrupts 0: 481645 0 IO-APIC-edge timer LOC: 1130 483025 Local timer interrupts You can see from above I'm getting 1000 timer interrupts per second on one of the CPU cores. One last tip for those running linux on the 6501 -- I blacklisted kernel module pch_gbe because it was causing a slew of MII errors when it tries to load. I think the modules for pch_gbe thinks there's an "internal" intel pch gig-e adapter in this system when there isn't -- it obviously uses the 82574L x 4. So not loading this module gets rid of these annoying errors some of you may have in dmesg: [ 1.490801] pch_gbe: pch-gbe.miim won't go Ready [ 1.492377] pch_gbe: pch-gbe.miim won't go Ready [ 1.492377] pch_gbe: pch-gbe.miim won't go Ready [ 1.492377] pch_gbe: pch-gbe.miim won't go Ready [ 1.492377] pch_gbe: pch-gbe.miim won't go Ready I simply added: blacklist pch_gbe to my /etc/modprobe.d/blacklist.conf to hush those annoying messages on my 6501. Hope this helps someone else searching for the same solution. Thanks for any info on how to get my TSC to be stable so it can be the clocksource... -Eric Malkowski ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] VPN 1401 support for ZFS encryption under Solaris/BSD?
Under FreeBSD the 1401 is supported with a custom kernel config that includes device crypto device cryptodev device hifn The Hi/fn 7955 onboard supports 128/192/256 AES, but - no idea if ZFS is /dev/crypto aware - I'd be surprised if GELI isn't. - M On Mon, Feb 25, 2013 at 1:23 PM, Georg Bauer wrote: > > Hello everybody, > > I'm interested at the product "Soekris vpn 1401, for Std. PCI-sockets" and > I'm wondering if it's possible to use this card to accelerate > zfs-filesystem encryption under Solaris 11, OpenIndiana or FreeBSD (via > geli raw device or zfs version >= 30 filesystem)? Has anybody some > informations about these Unix/BSD systems and zfs support and if yes > what is the implementation process (out of the box or compiling kernel > and zfs/geli sources) and what performance can I expect with > AES-128/192/256 Bit encryption? > And a second question: Is there support for truecrypt > (http://www.truecrypt.org/) acceleration under Windows or Linux? > > I want to encrypt some low power nas storage systems without high > power cpu (like Intel Core i5/i7 with hardware AES support) and the > raid performance is great - until encryption is needed. Then the > performance slows down at factor 6 and more. And I'm interested in low > power Nettop PCs with disk encryption (Windows/Linux with truecrypt). > > Best Regards, > Georg Bauer > ___ > Soekris-tech mailing list > Soekris-tech@lists.soekris.com > http://lists.soekris.com/mailman/listinfo/soekris-tech ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
[Soekris] VPN 1401 support for ZFS encryption under Solaris/BSD?
Hello everybody, I'm interested at the product "Soekris vpn 1401, for Std. PCI-sockets" and I'm wondering if it's possible to use this card to accelerate zfs-filesystem encryption under Solaris 11, OpenIndiana or FreeBSD (via geli raw device or zfs version >= 30 filesystem)? Has anybody some informations about these Unix/BSD systems and zfs support and if yes what is the implementation process (out of the box or compiling kernel and zfs/geli sources) and what performance can I expect with AES-128/192/256 Bit encryption? And a second question: Is there support for truecrypt (http://www.truecrypt.org/) acceleration under Windows or Linux? I want to encrypt some low power nas storage systems without high power cpu (like Intel Core i5/i7 with hardware AES support) and the raid performance is great - until encryption is needed. Then the performance slows down at factor 6 and more. And I'm interested in low power Nettop PCs with disk encryption (Windows/Linux with truecrypt). Best Regards, Georg Bauer ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
Re: [Soekris] Recent netbsd-6 vr changes, trouble at boot
Improvements here: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_vr.c Greg Troxel [g...@work.lexort.com] wrote: > > I have a net5501 that used to run NetBSD 5. I updated to -6, and it's > been fine for quite a while. I just updated to -6 from yesterday, which > includes an improvement to vr(4) to not reset the chip when going in and > out of promiscuous mode. (Before there was a ~1s hiccup when > running/exiting tcpdump.) > > When I updated, I rebooted, and the machine did not come back onto the > net. Visiting it and experimenting, I found: > > booting from applying power worked fine > > rebooting led to the system being up but vr0 being nonfunctional > > on the up/no-vr0 system, running tcpdump printed a message: > vr0: using force reset command. > and then it worked ok. > > This is the change that I think might be relevant: > > sys/dev/pci/if_vr.c 1.112 via patch > > Reset the vr(4) chip if the tx engine gets stuck. No need to > do a full reset when enabling/disabling promiscuous mode. > [taca, ticket #783] > > I wonder if anyone else is seeing this. > > ___ > Soekris-tech mailing list > Soekris-tech@lists.soekris.com > http://lists.soekris.com/mailman/listinfo/soekris-tech -- "Once you can accept the universe as matter expanding into nothing that is something, wearing stripes with plaid comes easy." -- Einstein ___ Soekris-tech mailing list Soekris-tech@lists.soekris.com http://lists.soekris.com/mailman/listinfo/soekris-tech
