Re: msk0: interrupt storm
On Wednesday, March 07, 2012 3:40:53 pm YongHyeon PYUN wrote: > On Tue, Mar 06, 2012 at 10:36:05AM -0500, John Baldwin wrote: > > On Thursday, March 01, 2012 8:29:55 pm YongHyeon PYUN wrote: > > > On Wed, Feb 29, 2012 at 01:03:29AM +0400, Pavel Gorshkov wrote: > > > > My laptop running 9.0-RELEASE/amd64/GENERIC freezes and > > > > (sometimes) unfreezes intermittently, logging the following: > > > > > > > > Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; > > throttling interrupt source > > > > > > > > $ vmstat -i > > > > ... > > > > irq259: mskc0 11669511 3456 > > > > > > > > > > > > Looks very similar to this: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 > > > > > > > > Any suggestions? > > > > > > Try disabling MSI and see whether that makes any difference. > > > > I also get interrupt storms with msk. They do fix themselves when they > > happen, and I've seen it happen with the machine is idle. This is on my > > little netbook where msk had several problems initially that have since > > been > > fixed. > > > > mskc0: port 0x2000-0x20ff mem > > 0xe000-0xe0003fff irq 19 at device 0.0 on pci32 > > msk0: on mskc0 > > msk0: Ethernet address: 00:24:81:40:e3:ef > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > 1000baseT, > > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > > > mskc0@pci0:32:0:0: class=0x02 card=0x3056103c chip=0x436c11ab > > rev=0x10 hdr=0x00 > > vendor = 'Marvell Technology Group Ltd.' > > device = '88E8072 PCI-E Gigabit Ethernet Controller' > > class = network > > subclass = ethernet > > > > John, can you let me know the value of B0_Y2_SP_ISRC2 register in > interrupt handler when you see the interrupt storm? I finally tested this. I added some KTR traces to dump ISRC2 on each call to msk_intr() and hacked the interrupt thread code to turn KTR tracing off when a storm occurred. The traces look like this: index cpu timestamptrace -- --- - 148 0 111662766108828 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 147 0 111662765994576 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 146 0 111662765380260 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 145 0 111662765257308 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 144 0 111662765134356 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 143 0 111662765011560 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 142 0 111662764888656 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 141 0 111662764773924 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 140 0 111662764659360 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 139 0 111662764528140 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 138 0 111662764413576 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 137 0 111662764287852 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 ... (All traces have the same register value.) The TSC on this netbook runs at machdep.tsc_freq: 1596035244 (The timestamps above are TSC values.) Let me know if you'd like me to log more stuff in the driver. Thanks! -- John Baldwin ___ 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_9.0_Port_Upgrade
Dear FreeBSD Friends, i have FreeBSD 9.0 Stable Running the following roles for past four months. Everything is functioning smooth alright. I read that system should be upgraded frequently. i am afraid that if i upgrade something can break. i am planing to run it like that until FreeBSD 9.2 is out, perhaps two years before upgrade. i am not sure if this is a good idea. i seek your advice about the upgrade. ROLE: Postfix Mail Server With Virtual Users Support Using MySQL Database, Apache Web Server, Certificate Authority (CA). Squirrelmail, Postfix Admin, Maia MailGuard Postfix-Admin, SPF, Postgray Filter, spamassassin, Clamav. i want to know the advice from experts, what is best? is it really important to update the system to new ports available. Or once i have no issue, i should follow golden rule. don't fix if not broken. i personally want my system to update at all time and exclude critical ports. i read that sometimes serious problems can occur after Perl upgrade in FreeBSD. these are the things prevent me from upgrade. i am actually working with CentOS / Debian for past 7 years for an ISP. Just did the first setup with FreeBSD. please advice Prabhpal Singh ___ 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.0_Port_Upgrade
On Apr 23, 2012, at 10:08 AM, Prabhpal S. Mavi wrote: > i have FreeBSD 9.0 Stable Running the following roles for past four > months. Everything is functioning smooth alright. I read that system > should be upgraded frequently. i am afraid that if i upgrade something can > break. It's a good idea to update when a relevant security advisory comes out for something you use (see portaudit and FreeBSD security announcements). Beyond that, it's up to you and your users to decide upon how much testing you need to do to validate changes. It's not expected that upgrading the FreeBSD OS or ports would break things, but software can get complicated and people make mistakes sometimes. In any event, if you have working backups, then you should always be able to restore back to a known-working condition. If you don't have backups, fix that before doing anything else. 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: Any options on crypt+zfs ?
On Sat, April 21, 2012 12:46, Ronald Klop wrote: > On Mon, 16 Apr 2012 19:32:43 +0200, Nenhum_de_Nos > wrote: > >> hail, >> >> I have a soekris running an atom and 2GB RAM and ZFS using 7 drives, >> small capacity though, to >> test and study if I can make my home server this box and this way. It >> will be a simple server, >> three users tops. >> >> I followed the handbook and made the geli step on the disks: >> >> Geom name: label/zfs1.eli >> State: ACTIVE >> EncryptionAlgorithm: AES-XTS >> KeyLength: 128 >> Crypto: software >> UsedKey: 0 >> Flags: NONE >> KeysAllocated: 38 >> KeysTotal: 38 >> Providers: >> 1. Name: label/zfs1.eli >>Mediasize: 160041881600 (149G) >>Sectorsize: 4096 >>Mode: r1w1e1 >> Consumers: >> 1. Name: label/zfs1 >>Mediasize: 160041885184 (149G) >>Sectorsize: 512 >>Mode: r1w1e1 >> >> >> all disks are this way (just 4 disks are on geli zfs). >> >> would it be faster, if I had geli over zfs, and not the other way (as is >> now) ? >> >> my performance is too low (I know the hardware is not that much, but I >> compared it to a friend's >> arm based AP-Router gadget and my setup is when much equal. I have 1.6 >> GHz Atom and 2GB ram, he >> has not half this ... I know can't compare arm and x86 clock for clock >> ...) >> >> I'll try to run geli on single disk, to see how much ZFS is impacting on >> performance, but, is >> there any other way around ? All I want is RAID5, and FreeBSD has not >> developed RAID5 from GEOM >> (AFAIK) since a long time. ZFS is the way people go in recent years. >> >> suggestions are welcome, just want to upgrade my old 8.0 BETA3 using >> geom mirror/stripe to a newer >> approach that would be supported by FreeBSD. >> >> I have an external enclosure for 4 SATA disks (port multiplier included) >> using 4 disks, another >> port multiplier 5x1 using now 3 disks, and: >> >> ahci1@pci0:13:0:0: class=0x010601 card=0x10601b21 chip=0x06121b21 >> rev=0x01 hdr=0x00 >> vendor = 'ASMedia Technology Inc.' >> class = mass storage >> subclass = SATA >> >> with two eSATA to the Port Multipliers. > > First try to look for the bottleneck. > What is the performance without GELI? And what performance do you want to > have? If you want performance, why do you use encryption on low-end > hardware? > > Ronald. Hi Ronald, GELI is it. Without GELI I can get to almost 10MB/s (Fast Ethernet wire speed). But when GELI is on the way, 3MB/s is never reached. well, I don't want to have a gigabit wire speed encrypted file server. All I want is to look for the ways to make mine as fast as it can be. If 2MB/s is the fastest it can go, then I'll see if it is enough or not. I just need to make sure I'm in the fastest config possible. I got to see that Via Padlock and their site says is really fast (wouldn't they ?!), so I'm trying to get a board from them to see it myself. But first I need to get rid of the atom board, as this is my home, I can't have so many machines :) thanks for all, matheus >> thanks, >> >> matheus >> >> machine: >> ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) >> Copyright (c) 1992-2012 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 9.0-RELEASE #0: Wed Apr 11 13:04:15 BRT 2012 >> root@macgyver:/usr/obj/usr/src/sys/net6501-amd64 amd64 >> ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) >> CPU: Genuine Intel(R) CPU@ 1.60GHz (1600.04-MHz K8-class CPU) >> Origin = "GenuineIntel" Id = 0x20661 Family = 6 Model = 26 >> Stepping = 1 >> >> Features=0xbfe9fbff >> >> Features2=0x40e3bd >> AMD Features=0x20100800 >> AMD Features2=0x1 >> TSC: P-state invariant, performance statistics >> real memory = 2147352576 (2047 MB) >> avail memory = 2046488576 (1951 MB) >> MPTable: >> Event timer "LAPIC" quality 400 >> 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: Assuming intbase of 0 >> ioapic0 irqs 0-23 on motherboard >> kbd0 at kbdmux0 >> ACPI Error: A valid RSDP was not found (20110527/tbxfroot-237) >> ACPI: Table initialisation failed: AE_NOT_FOUND >> ACPI: Try disabling either ACPI or apic support. >> cryptosoft0: on motherboard > ___ > 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" > -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-stable@freebsd.org ma
Re: FreeBSD_9.0_Port_Upgrade
On 23/04/2012 18:08, Prabhpal S. Mavi wrote: > i want to know the advice from experts, what is best? is it really > important to update the system to new ports available. Or once i have no > issue, i should follow golden rule. don't fix if not broken. i personally > want my system to update at all time and exclude critical ports. i read > that sometimes serious problems can occur after Perl upgrade in FreeBSD. > these are the things prevent me from upgrade. i am actually working with > CentOS / Debian for past 7 years for an ISP. Just did the first setup with > FreeBSD. please advice There isn't a one-size-fits-all best answer to this sort of question. How often you update, how much down time you are willing to tolerate, how much effort you are willing to put in to trade off against the risk of outage depends on the particulars of your system and your user-base. It's a balance of various risks against effort. Not updating at all means the system should just keep running as it is now (assuming there aren't any great variations in usage levels or so forth.) But if any security vulnerabilities are found then you will be vulnerable to system compromise. However, security problems are generally few and far between. If you only upgrade applications exposed to security problems, you run the risk that the updated version will have got out of synch with the rest of your installed application base. This is a common cause of problems in the ports. So you update the application with the security problem, plus anything it depends on, and any other application that depends on something that got updated. That's more like a viable strategy, except you now have to put some effort into working out exactly what needs to be updated. It is also the case that doing infrequent updates involving many applications and over large deltas in version numbers has pretty much the highest risk of something going wrong. So to avoid that, you track updates as they go into ports, and keep everything pretty much up to date. This means that updates tend to happen to one application at a time (so generally a smaller chunk of work, and easier to deal with), and you go from one version to the next (so less chance of breakage because of application changes). Also, you aren't doing updates as an emergency response to security vulnerabilities all the time, so you can plan and schedule your updates in advance. Plus you will be doing updates regularly, so the process will become familiar to you and practice makes mistakes much less likely. Except that now you're following exactly the strategy that so terrifies people at first sight: you track new releases of software as they come out, which surely leaves you vulnerable to regressions in that software. Well, yes. But regressions in such popular applications as apache, mysql and postfix are very quickly discovered and fixed in the ports. Also, those projects have very good developers working for them and good testing regimes, so such regressions are rare in any case. To ameliorate those risks, well, as part of your updating process, you can update your ports tree, and then take maybe two weeks where you watch the freebsd-ports@ mailing lists or various mailing lists specific to your applications of interest and see if there are any reports of trouble. If it's all clear, then you can update with reasonable confidence. (Although I will state here that although this delay is a good concept, in my experience it only very rarely proves to have been necessary.) In fact, probably the biggest risk when updating is that you, the admin, makes a mistake. Making updates into a routine, regular task helps. But the biggest way you can save yourself from grief comes right out of Sysadmin-101: *never do anything you cannot directly undo*. This means: always have a plan for being able to back-out your changes before you start. You can keep backup copies of the ports you are updating (portmaster(8) does this automatically, although it doesn't have a specific command to revert to a saved package; that you have to do manually), or you can use filesystem snapshots (particularly good with ZFS) or you can just rely on good old filesystem backups. If you're running a particularly important system that really cannot afford unscheduled outages, then really you want to have a development server that you can practice the updates on and use for testing (plus you can make package tarballs on the development server, which will cut down the time needed to work on the live server). Or you may have a hot spare system, or you can split up a HA pair or many other means of reducing the risks of something going sufficiently wrong that it affects service. Even if you can't afford spare hardware for a dev system, you could use a jail on your live server to much the same effect. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Desc
Re: FreeBSD_9.0_Port_Upgrade
* Prabhpal S. Mavi wrote: > Dear FreeBSD Friends, > > i have FreeBSD 9.0 Stable Running the following roles for past four > months. Everything is functioning smooth alright. I read that system > should be upgraded frequently. i am afraid that if i upgrade something can > break. > > i am planing to run it like that until FreeBSD 9.2 is out, perhaps two > years before upgrade. i am not sure if this is a good idea. i seek your > advice about the upgrade. > > ROLE: Postfix Mail Server With Virtual Users Support Using MySQL Database, > Apache Web Server, Certificate Authority (CA). Squirrelmail, Postfix > Admin, Maia MailGuard Postfix-Admin, SPF, Postgray Filter, spamassassin, > Clamav. > [...] First you have to be aware that the stable tree in FBSD means something completly different than a release in Red Hat/CentOS land. Here stable is the stable branch which gets updates, bugfixes and new features. From this branch the next release is created. These updates and new features might not be as disruptive as in the development branch but still things change. So you might consider using a release branch instead, which only gets security and critical bugfixes. Critical really means critical here and not every bugfix around. In this regard a release branch is very stable :) So with stable you are really tracking a rolling release more like Debian testing or say a rolling release repository like the fasttrack repo in CentOS/Scientific Linux. While the release branch is more like staying on the same minor release in Red Hat. But the minor release in Red Hat gets far more updates even for not so serious bugs and sometimes even driver updates. The last part is AFAIU the reason that many people recomend the stable branch in FBSD, b/c you get bugfixes and some driver updates faster or even at all. If you would be on the release branch you would either have to switch to stable or wait for the next release branch to get these updates and fixes. As you are on stable i would suggest a test machine with the same setup, or at least a virtual machine with the same setup. Maybe a jail will do for you, else you could use something like virtualbox. Backups, always have backups and do some backups before doing something. Under Linux there is a nifty tool called etckeeper, it basically hooks into the package manager and tracks changes to /etc via version control. No idea if something like this is available under FBSD but you could roll your own ... If you use ZFS snapshots are easy and cheap, also there is basic Live Upgrade/Boot Environment support. http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE If you use ZFS, i really suggest you look into this one, b/c it allows you to switch your complete system around at will. Also, the updates can be tested on an exact production copy without affecting the running system. On the security side i would suggest some form of host basesd intrusion detection and some common sense hardening. Generally monitoring (alarming+capacity/trending) for a live service is a good idea, too. Accompanied by following the security advisories and using portaudit should be enough, i guess ... hth --lars ___ 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: msk0: interrupt storm
On Mon, Apr 23, 2012 at 10:24:41AM -0400, John Baldwin wrote: > On Wednesday, March 07, 2012 3:40:53 pm YongHyeon PYUN wrote: > > On Tue, Mar 06, 2012 at 10:36:05AM -0500, John Baldwin wrote: > > > On Thursday, March 01, 2012 8:29:55 pm YongHyeon PYUN wrote: > > > > On Wed, Feb 29, 2012 at 01:03:29AM +0400, Pavel Gorshkov wrote: > > > > > My laptop running 9.0-RELEASE/amd64/GENERIC freezes and > > > > > (sometimes) unfreezes intermittently, logging the following: > > > > > > > > > > Feb 28 23:07:36 lifebook kernel: interrupt storm detected on > > > > > "irq259:"; > > > throttling interrupt source > > > > > > > > > > $ vmstat -i > > > > > ... > > > > > irq259: mskc0 11669511 3456 > > > > > > > > > > > > > > > Looks very similar to this: > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 > > > > > > > > > > Any suggestions? > > > > > > > > Try disabling MSI and see whether that makes any difference. > > > > > > I also get interrupt storms with msk. They do fix themselves when they > > > happen, and I've seen it happen with the machine is idle. This is on my > > > little netbook where msk had several problems initially that have since > > > been > > > fixed. > > > > > > mskc0: port 0x2000-0x20ff mem > > > 0xe000-0xe0003fff irq 19 at device 0.0 on pci32 > > > msk0: on mskc0 > > > msk0: Ethernet address: 00:24:81:40:e3:ef > > > miibus0: on msk0 > > > e1000phy0: PHY 0 on miibus0 > > > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > > 1000baseT, > > > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > > > > > > mskc0@pci0:32:0:0: class=0x02 card=0x3056103c chip=0x436c11ab > > > rev=0x10 hdr=0x00 > > > vendor = 'Marvell Technology Group Ltd.' > > > device = '88E8072 PCI-E Gigabit Ethernet Controller' > > > class = network > > > subclass = ethernet > > > > > > > John, can you let me know the value of B0_Y2_SP_ISRC2 register in > > interrupt handler when you see the interrupt storm? > > I finally tested this. I added some KTR traces to dump ISRC2 on each > call to msk_intr() and hacked the interrupt thread code to turn KTR tracing > off when a storm occurred. The traces look like this: > > index cpu timestamptrace > -- --- - >148 0 111662766108828 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >147 0 111662765994576 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >146 0 111662765380260 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >145 0 111662765257308 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >144 0 111662765134356 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >143 0 111662765011560 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >142 0 111662764888656 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >141 0 111662764773924 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >140 0 111662764659360 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >139 0 111662764528140 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >138 0 111662764413576 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 >137 0 111662764287852 msk_intr: B0_Y2_SP_ISRC2 = 0x4400 > ... > > (All traces have the same register value.) The TSC on this netbook runs > at machdep.tsc_freq: 1596035244 > > (The timestamps above are TSC values.) > > Let me know if you'd like me to log more stuff in the driver. Thanks! wonder why the deivce gets TWSI completion interrupt since the driver does not monitor temperature sensor. In addition, the interrupt was already disabled so have no idea how this can happen. Here, I assume your controller implemented optional temperature sensor and it is monitored by H/W. Anyway, try attached patch and let me know whether it makes any difference. Index: sys/dev/msk/if_msk.c === --- sys/dev/msk/if_msk.c (revision 234591) +++ sys/dev/msk/if_msk.c (working copy) @@ -3734,6 +3734,9 @@ if ((status & Y2_IS_STAT_BMU) != 0 && domore == 0) CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ); + /* Clear TWSI IRQ. */ + if ((status & Y2_IS_TWSI_RDY) != 0) + CSR_WRITE_4(sc, B2_I2C_IRQ, 1); /* Reenable interrupts. */ CSR_WRITE_4(sc, B0_Y2_SP_ICR, 2); ___ 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"
