Re: msk0: interrupt storm
On Wed, Apr 25, 2012 at 09:35:28AM -0400, John Baldwin wrote: On Tuesday, April 24, 2012 3:07:14 pm John Baldwin wrote: On Tuesday, April 24, 2012 4:07:19 pm YongHyeon PYUN wrote: 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: Marvell Yukon 88E8072 Gigabit Ethernet port 0x2000-0x20ff mem 0xe000-0xe0003fff irq 19 at device 0.0 on pci32 msk0: Marvell Technology Group Ltd. Yukon EX Id 0xb5 Rev 0x02 on mskc0 msk0: Ethernet address: 00:24:81:40:e3:ef miibus0: MII bus on msk0 e1000phy0: Marvell 88E1149 Gigabit PHY 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. It does fix the interrupt storms. I added a debugging printf to fire each time msk_intr() sees this bit to see if it storms, etc. What I see is that each time I would previously get a single printf reporting an interrupt storm, I now get a single printf reporting that the TWSI_RDY bit was set. Sadly, I spoke too soon. With this patch applied I got another storm last night where this bit was not set during the storm: index cpu timestamptrace -- --- - 71 0 36775451301480 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 70 0 36775450145436 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 69 0 36775449956940 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 68 0 36775449768564 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 67 0 36775448604912 msk_intr: B0_Y2_SP_ISRC2 =
Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak
Security_Multipart(Fri_Apr_27_13_35_56_2012_748)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem rmack...@uoguelph.ca wrote in 1527622626.3418715.1335445225510.javamail.r...@erie.cs.uoguelph.ca: rm Steven Hartland wrote: rm Original Message - rm From: Rick Macklem rmack...@uoguelph.ca rm At a glance, it looks to me like 8.x is affected. Note that the rm bug only affects the new NFS server (the experimental one for 8.x) rm when exporting ZFS volumes. (UFS exported volumes don't leak) rm rm If you are running a server that might be affected, just: rm # vmstat -z | fgrep -i namei rm on the server and see if the 3rd number shown is increasing. rm rm Many thanks Rick wasnt aware we had anything experimental enabled rm but I think that would be a yes looking at these number:- rm rm vmstat -z | fgrep -i namei rm NAMEI: 1024, 0, 1, 1483, 25285086096, 0 rm vmstat -z | fgrep -i namei rm NAMEI: 1024, 0, 0, 1484, 25285945725, 0 rm rm ^ rm I don't think so, since the 3rd number (USED) is 0 here. rm If that # is increasing over time, you have the leak. You are rm probably running the old (default in 8.x) NFS server. Just a report, I confirmed it affected 8.x servers running newnfs. Actually I have been suffered from memory starvation symptom on that server (24GB RAM) for a long time and watching vmstat -z periodically. It stopped working once a week. I investigated the vmstat log again and found the amount of NAMEI leak was 11,543,956 (about 11GB!) just before the locked-up. After applying the patch, the leak disappeared. Thank you for fixing it! -- Hiroki this is on 8.2-STABLE/amd64 from around August: same here, this zfs+newnfs has been hanging every few months, and I can see now the leak, it's slowly increasing: NAMEI: 1024,0, 122975, 529, 15417248,0 NAMEI: 1024,0, 122984, 520, 15421772,0 NAMEI: 1024,0, 123002, 502, 15424743,0 NAMEI: 1024,0, 123008, 496, 15425464,0 cheers, danny ___ 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
make distribution in RELENG_9 i386 tinderbox jail fails on amd64
This problem also showed up a couple of years ago and was caused by TB calling make distribution in a non-supported way. However, that was a long time ago and nowadays crosscompiling RELENG_7 and RELENG_8 works just fine. But /something/ was introduced with RELENG_9 that broke it. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? cd /usr/local/portstools/tinderbox/jails/9-i386/src/etc; install -o root -g wheel -m 644 auth.conf crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab ftpusers gettytab group hosts hosts.allow hosts.equiv inetd.conf libalias.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf nsswitch.conf phones profile protocols rc rc.bsdextended rc.firewall rc.initdiskless rc.sendmail rc.shutdown rc.subr remote rpc services shells sysctl.conf syslog.conf termcap.small etc.i386/ttys amd.map apmd.conf snmpd.config freebsd-update.conf /usr/local/portstools/tinderbox/jails/9-i386/src/etc/../usr.bin/locate/locate/locate.rc hosts.lpd printcap /usr/local/portstools/tinderbox/jails/9-i386/src/etc/../usr.bin/mail/misc/mail.rc ntp.conf nscd.conf portsnap.conf pf.os csh.cshrc csh.login csh.logout regdomain.xml /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc; cap_mkdb -l /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/login.conf; install -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc; install -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc; pwd_mkdb -L -i -p -d /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/master.passwd cd /usr/local/portstools/tinderbox/jails/9-i386/src/etc/bluetooth; make install install -o root -g wheel -m 600 hcsecd.conf /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/bluetooth/hcsecd.conf install -o root -g wheel -m 644 hosts /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/bluetooth/hosts install -o root -g wheel -m 444 protocols /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/bluetooth cd /usr/local/portstools/tinderbox/jails/9-i386/src/etc/defaults; make install install -o root -g wheel -m 444 bluetooth.device.conf devfs.rules periodic.conf rc.conf /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/defaults cd /usr/local/portstools/tinderbox/jails/9-i386/src/etc/devd; make install install -o root -g wheel -m 644 uath.conf usb.conf asus.conf /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/devd cd /usr/local/portstools/tinderbox/jails/9-i386/src/etc/gss; make install install -o root -g wheel -m 444 mech qop /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/gss cd /usr/local/portstools/tinderbox/jails/9-i386/src/etc/periodic; make install === daily (install) install -o root -g wheel -m 755 100.clean-disks 110.clean-tmps 120.clean-preserve 200.backup-passwd 220.backup-pkgdb 330.news 400.status-disks 405.status-ata-raid 406.status-gmirror 407.status-graid3 408.status-gstripe 409.status-gconcat 420.status-network 450.status-security 999.local 310.accounting 470.status-named 300.calendar 130.clean-msgs 480.status-ntpd 490.status-pkg-changes 140.clean-rwho 430.status-rwho 150.clean-hoststat 210.backup-aliases 440.status-mailq 460.status-mail-rejects 500.queuerun 404.status-zfs 800.scrub-zfs /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/periodic/daily === security (install) install -o root -g wheel -m 755 100.chksetuid 110.neggrpperm 200.chkmounts 300.chkuid0 400.passwdless 410.logincheck 700.kernelmsg 800.loginfail 900.tcpwrap security.functions 510.ipfdenied 610.ipf6denied 500.ipfwdenied 550.ipfwlimit 520.pfdenied 460.chkportsum /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/periodic/security === weekly (install) install -o root -g wheel -m 755 340.noid 999.local 310.locate 320.whatis 330.catman 400.status-pkg /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/periodic/weekly === monthly (install) install -o root -g wheel -m 755 999.local 200.accounting /usr/local/portstools/tinderbox/jails/9-i386/tmp/etc/periodic/monthly cd /usr/local/portstools/tinderbox/jails/9-i386/src/etc/rc.d; make install install -o root -g wheel -m 555 DAEMON FILESYSTEMS LOGIN NETWORKING SERVERS abi accounting addswap adjkerntz amd apm apmd archdep atm1 atm2 atm3 auditd bgfsck bluetooth bootparams bridge bsnmpd bthidd ccd cleanvar cleartmp cron ddb defaultroute devd devfs dhclient dmesg dumpon encswap faith fsck ftp-proxy ftpd gbde geli geli2 gptboot gssd hastd hcsecd hostapd hostid hostid_save hostname inetd initrandom ip6addrctl ipfilter ipfs ipfw ipmon ipnat ipsec jail kadmind kerberos keyserv kld kldxref kpasswdd ldconfig local localpkg lockd lpd mixer motd mountcritlocal mountcritremote mountlate
Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak
Daniel Braniss wrote: Security_Multipart(Fri_Apr_27_13_35_56_2012_748)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem rmack...@uoguelph.ca wrote in 1527622626.3418715.1335445225510.javamail.r...@erie.cs.uoguelph.ca: rm Steven Hartland wrote: rm Original Message - rm From: Rick Macklem rmack...@uoguelph.ca rm At a glance, it looks to me like 8.x is affected. Note that the rm bug only affects the new NFS server (the experimental one for 8.x) rm when exporting ZFS volumes. (UFS exported volumes don't leak) rm rm If you are running a server that might be affected, just: rm # vmstat -z | fgrep -i namei rm on the server and see if the 3rd number shown is increasing. rm rm Many thanks Rick wasnt aware we had anything experimental enabled rm but I think that would be a yes looking at these number:- rm rm vmstat -z | fgrep -i namei rm NAMEI: 1024, 0, 1, 1483, 25285086096, 0 rm vmstat -z | fgrep -i namei rm NAMEI: 1024, 0, 0, 1484, 25285945725, 0 rm rm ^ rm I don't think so, since the 3rd number (USED) is 0 here. rm If that # is increasing over time, you have the leak. You are rm probably running the old (default in 8.x) NFS server. Just a report, I confirmed it affected 8.x servers running newnfs. Actually I have been suffered from memory starvation symptom on that server (24GB RAM) for a long time and watching vmstat -z periodically. It stopped working once a week. I investigated the vmstat log again and found the amount of NAMEI leak was 11,543,956 (about 11GB!) just before the locked-up. After applying the patch, the leak disappeared. Thank you for fixing it! -- Hiroki And thanks Hiroki for testing it on 8.x. this is on 8.2-STABLE/amd64 from around August: same here, this zfs+newnfs has been hanging every few months, and I can see now the leak, it's slowly increasing: NAMEI: 1024, 0, 122975, 529, 15417248, 0 NAMEI: 1024, 0, 122984, 520, 15421772, 0 NAMEI: 1024, 0, 123002, 502, 15424743, 0 NAMEI: 1024, 0, 123008, 496, 15425464, 0 cheers, danny Maybe you could try the patch, too. It's at: http://people.freebsd.org/~rmacklem/namei-leak.patch I'll commit it to head soon with a 1 month MFC, so that hopefully Oliver will have a chance to try it on his production server before the MFC. Thanks everyone, for your help with this, rick ___ 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
/var getting full
Hello. I have a server using FreeBSD 8.2, and recently I’ve noticed that /var is getting full But du –hs /var shows me this: 14M/var/ How Can I know what is using var to free space? Thank you. OS info: FreeBSD edh.edh 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 ___ 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: /var getting full
I forgot this: /dev/da0s1d 11G9.9G457M96%/var From: Efraín Déctor Sent: Friday, April 27, 2012 10:14 AM To: freebsd-stable@freebsd.org Subject: /var getting full Hello. I have a server using FreeBSD 8.2, and recently I’ve noticed that /var is getting full But du –hs /var shows me this: 14M/var/ How Can I know what is using var to free space? Thank you. OS info: FreeBSD edh.edh 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 ___ 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: /var getting full
Type: sync Then: df -h Then: cd /var du -hd 1 Post results. On 4/27/12 5:16 PM, Efraín Déctor wrote: I forgot this: /dev/da0s1d 11G9.9G457M96%/var From: Efraín Déctor Sent: Friday, April 27, 2012 10:14 AM To: freebsd-stable@freebsd.org Subject: /var getting full Hello. I have a server using FreeBSD 8.2, and recently I’ve noticed that /var is getting full But du –hs /var shows me this: 14M/var/ How Can I know what is using var to free space? Thank you. OS info: FreeBSD edh.edh 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /var getting full
On Fri, Apr 27, 2012 at 4:19 PM, Damien Fleuriot m...@my.gd wrote: Type: sync Then: df -h Then: cd /var du -hd 1 Post results. As well as this, any unlinked files that have file handles open by running processes will not be accounted for in du, but will be counted in df. You could try restarting services that write to /var. Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /var getting full
Thank you all. I found out that a Java process was using all this space. I restarted it and voilá problem solved. Thanks. -Mensaje original- From: Tom Evans Sent: Friday, April 27, 2012 10:22 AM To: Damien Fleuriot Cc: freebsd-stable@freebsd.org Subject: Re: /var getting full On Fri, Apr 27, 2012 at 4:19 PM, Damien Fleuriot m...@my.gd wrote: Type: sync Then: df -h Then: cd /var du -hd 1 Post results. As well as this, any unlinked files that have file handles open by running processes will not be accounted for in du, but will be counted in df. You could try restarting services that write to /var. Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /var getting full
Hello! On Fri, Apr 27, 2012 at 10:14:27AM -0500, Efraín Déctor wrote: Hello. I have a server using FreeBSD 8.2, and recently I’ve noticed that /var is getting full But du –hs /var shows me this: 14M/var/ How Can I know what is using var to free space? fstat -f /var Maxim Dounin ___ 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: /var getting full
On Fri, 2012-04-27 at 10:14 -0500, Efraín Déctor wrote: Hello. I have a server using FreeBSD 8.2, and recently I’ve noticed that /var is getting full But du hs /var shows me this: 14M/var/ How Can I know what is using var to free space? Thank you. OS info: FreeBSD edh.edh 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I would speculate that some process has unlinked a file but still has it open so the space is still in use. Try procstat -af | grep /var and look especially for lines that have a huge number in the OFFSET column (although I'm not sure that's definitive -- the file descriptor could be positioned at an offset less than the file size). -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /var getting full
Thank you all for your answers. Turns out that a Java process was using all of the space. I restarted it and the problem was solved. Thank you all for helping me to resolv this, also by giving me very useful commands that I will use in the future. -Mensaje original- From: Ian Lepore Sent: Friday, April 27, 2012 10:29 AM To: Efrain Dector Cc: freebsd-stable@freebsd.org Subject: Re: /var getting full On Fri, 2012-04-27 at 10:14 -0500, Efra醇^n D醇Pctor wrote: Hello. I have a server using FreeBSD 8.2, and recently I’ve noticed that /var is getting full But du hs /var shows me this: 14M/var/ How Can I know what is using var to free space? Thank you. OS info: FreeBSD edh.edh 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I would speculate that some process has unlinked a file but still has it open so the space is still in use. Try procstat -af | grep /var and look especially for lines that have a huge number in the OFFSET column (although I'm not sure that's definitive -- the file descriptor could be positioned at an offset less than the file size). -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
High load event idl.
Hi all I'm running 9-stable on all my computer. (csup yesterday). On my desktop everything is fine. But I've two laptop, (both are Dell). On both latptop I've problem about the load, event when I do nothing I got a load between 0.5-1. Here the result of a «top» on the laptop : last pid: 2434; load averages: 0.63, 0.67, 0.59 up 0+00:23:59 22:25:29 57 processes: 3 running, 54 sleeping CPU: 2.7% user, 0.0% nice, 3.7% system, 1.4% interrupt, 92.2% idle Mem: 89M Active, 92M Inact, 198M Wired, 13M Cache, 100M Buf, 3529M Free Swap: 4096M Total, 4096M Free Here on the desktop : last pid: 61010; load averages: 0.00, 0.00, 0.00 up 2+11:02:42 22:29:08 126 processes: 1 running, 125 sleeping CPU: % user, % nice, % system, % interrupt, % idle Mem: 803M Active, 2874M Inact, 1901M Wired, 112M Cache, 620M Buf, 202M Free Swap: 6144M Total, 36M Used, 6107M Free On attachment the dmesg. Any idea ? JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: ven 27 avr 2012 22:29:15 CEST 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-STABLE #0: Thu Apr 26 04:42:08 CEST 2012 j...@io.chezmoi.fr:/usr/obj/usr/src/sys/JAS amd64 CPU: Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz (2592.82-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17 Stepping = 6 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=0x8e3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4081893376 (3892 MB) Event timer LAPIC quality 400 ACPI APIC Table: DELL M08 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: DELL M08 on motherboard hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, dfd83c00 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xdf00-0xdf7f mem 0xf500-0xf5ff,0xe000-0xefff,0xf200-0xf3ff irq 16 at device 0.0 on pci1 nvidia0: Quadro FX 1600M on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io uhci0: Intel 82801H (ICH8) USB controller USB-D port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: Intel 82801H (ICH8) USB controller USB-E port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 uhci1: LegSup = 0x2f00 usbus1 on uhci1 ehci0: Intel 82801H (ICH8) USB 2.0 controller USB2-B mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 hdac0: Intel 82801H HDA Controller mem 0xf6ffc000-0xf6ff irq 21 at device 27.0 on pci0 pcib2: ACPI PCI-PCI bridge at device 28.0 on pci0 pci11: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 28.1 on pci0 pci12: ACPI PCI bus on pcib3 wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xf1fff000-0xf1ff irq 17 at device 0.0 on pci12 pcib4: ACPI PCI-PCI bridge at device 28.3 on pci0 pci13: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 28.5 on pci0 pci9: ACPI PCI bus on pcib5 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x00a200 mem 0xf1bf-0xf1bf irq 17 at device 0.0 on pci9 bge0: CHIP ID 0xa200; ASIC REV 0x0a; CHIP REV 0xa2; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5722 1000BASE-T media interface PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto,
Re: msk0: interrupt storm
On Friday, April 27, 2012 6:20:17 pm YongHyeon PYUN wrote: On Wed, Apr 25, 2012 at 09:35:28AM -0400, John Baldwin wrote: Hmm, would you give attach patch try? Yukon Extreme seems to have a new flow control feature but I'm not sure whether this is related with interrupt storm you're seeing. No luck. :( I did seem to get many more interrupts with TWSI ready asserted with this patch, but I did get a storm after a few hours, it has the same bit set as before: index cpu timestamptrace -- --- - 602 0 26139273204228 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 601 0 26139273105828 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 600 0 26139273007620 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 599 0 26139272909292 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 598 0 26139272311224 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 597 0 26139272212920 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 596 0 26139272114688 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 595 0 26139272016384 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 594 0 26139271917972 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 593 0 26139271819800 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 592 0 26139271705008 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 591 0 26139271593960 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 590 0 26139271492056 msk_intr: B0_Y2_SP_ISRC2 = 0x4000 -- 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
Re: High load event idl.
Le 27/04/2012 ? 22:45:40+0200, Oliver Pinter a écrit I'm running 9-stable on all my computer. (csup yesterday). On my desktop everything is fine. But I've two laptop, (both are Dell). On both latptop I've problem about the load, event when I do nothing I got a load between 0.5-1. Here the result of a «top» on the laptop : last pid: 2434; load averages: 0.63, 0.67, 0.59 up 0+00:23:59 22:25:29 57 processes: 3 running, 54 sleeping CPU: 2.7% user, 0.0% nice, 3.7% system, 1.4% interrupt, 92.2% idle Mem: 89M Active, 92M Inact, 198M Wired, 13M Cache, 100M Buf, 3529M Free Swap: 4096M Total, 4096M Free Here on the desktop : last pid: 61010; load averages: 0.00, 0.00, 0.00 up 2+11:02:42 22:29:08 126 processes: 1 running, 125 sleeping CPU: % user, % nice, % system, % interrupt, % idle Mem: 803M Active, 2874M Inact, 1901M Wired, 112M Cache, 620M Buf, 202M Free Swap: 6144M Total, 36M Used, 6107M Free http://lists.freebsd.org/pipermail/freebsd-bugs/2012-April/048213.html What I understand of your message (I'm definitvly not a dev) is that's only a little problem of accounting. I'm not absolute sure of that because my laptop fan never stop... If you want any more information... Regards. -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: ven 27 avr 2012 23:31:28 CEST ___ 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: High load event idl.
On Fri, Apr 27, 2012 at 1:30 PM, Albert Shih albert.s...@obspm.fr wrote: Hi all I'm running 9-stable on all my computer. (csup yesterday). On my desktop everything is fine. But I've two laptop, (both are Dell). On both latptop I've problem about the load, event when I do nothing I got a load between 0.5-1. Here the result of a «top» on the laptop : last pid: 2434; load averages: 0.63, 0.67, 0.59 up 0+00:23:59 22:25:29 57 processes: 3 running, 54 sleeping CPU: 2.7% user, 0.0% nice, 3.7% system, 1.4% interrupt, 92.2% idle Mem: 89M Active, 92M Inact, 198M Wired, 13M Cache, 100M Buf, 3529M Free Swap: 4096M Total, 4096M Free Here on the desktop : last pid: 61010; load averages: 0.00, 0.00, 0.00 up 2+11:02:42 22:29:08 126 processes: 1 running, 125 sleeping CPU: % user, % nice, % system, % interrupt, % idle Mem: 803M Active, 2874M Inact, 1901M Wired, 112M Cache, 620M Buf, 202M Free Swap: 6144M Total, 36M Used, 6107M Free On attachment the dmesg. ENOINFO You did not supply enough information for a meaningful response. You have three user processes running. They are obviously using a bit of CPU, but you need to find out what those processes might be. Using top(1) with 'H' to show threads and see what they might be. The possibilities with what we have now are nearly endless. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
