Why is intr taking up so much cpu?
This is happening after I open a flash video in firefox and watch it for 15 minutes: root 20 -80- 0K 160K WAIT0 3:38 14.08% intr After this happens, my system goes into a death spiral and I have to shut it down. vmstat -i interrupt total rate irq1: atkbd0 10384 0 irq9: acpi05 0 irq14: ata0 153410 7 irq15: ata1 58 0 irq17: wpi0 534038 27 irq20: hpet0 uhci0+ 2496833129 irq22: uhci2 66485 3 cpu0:timer 19238037999 irq256: hdac0 189713 9 cpu1:timer 19236431999 Total 41925394 2178 Any suggestions? current (r210135), i386 smp. Dell C2D laptop. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: periodic script in base system to run csup
On 17/07/2010 24:04:38, Lowell Gilbert wrote: Alex Kozlov s...@rm-rf.kiev.ua writes: On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: Em 2010.07.16. 16:23, Alex Kozlov escreveu: On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: Thousands pc simultaneously try to access cvsup servers? Sound like a ddos to me. Yes, this was the only concern and that's why I started this discussion. And because its periodic, We can't use portsnap solution (random delay before csup start). It's not completely impossible; periodic could spin off a separate shell for it, with a random delay. It's not clear what the best way to deal with the output would be, although several approaches present themselves. It would be a lot more complicated than Gabor's approach, though. Simply ensuring the csup periodic job is the last one to run (/etc/periodic/daily/1000.csup ?) should give you the best of both worlds. You can insert a random delay of up to an hour and still deal with csup as a foreground job. All of the other periodic jobs will run as normal (and should help with randomising the time distribution of the csup runs too) -- you'll just have to wait a bit longer for the nightly e-mail to be produced. Even so, I think this is still likely to upset the cvsup servers: a whole timezone worth of machines hitting a small number of servers within one or two hours might be doable with portsnap / freebsd-update but cvsup requires a lot more effort server-side. Cheers Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: periodic script in base system to run csup
[periodic updating source] Besides technical feasibility: What is the use case behind it? Regards Christof Am Saturday 17 July 2010 10:00:07 schrieb Matthew Seaman: On 17/07/2010 24:04:38, Lowell Gilbert wrote: Alex Kozlov s...@rm-rf.kiev.ua writes: On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: Em 2010.07.16. 16:23, Alex Kozlov escreveu: On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: Thousands pc simultaneously try to access cvsup servers? Sound like a ddos to me. Yes, this was the only concern and that's why I started this discussion. And because its periodic, We can't use portsnap solution (random delay before csup start). It's not completely impossible; periodic could spin off a separate shell for it, with a random delay. It's not clear what the best way to deal with the output would be, although several approaches present themselves. It would be a lot more complicated than Gabor's approach, though. Simply ensuring the csup periodic job is the last one to run (/etc/periodic/daily/1000.csup ?) should give you the best of both worlds. You can insert a random delay of up to an hour and still deal with csup as a foreground job. All of the other periodic jobs will run as normal (and should help with randomising the time distribution of the csup runs too) -- you'll just have to wait a bit longer for the nightly e-mail to be produced. Even so, I think this is still likely to upset the cvsup servers: a whole timezone worth of machines hitting a small number of servers within one or two hours might be doable with portsnap / freebsd- update but cvsup requires a lot more effort server-side. Cheers Matthew -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: This is a digitally signed message part.
Re: [HEADSUP] ZFS version 15 committed to head
On Tue, Jul 13, 2010 at 04:02:42PM +0200, you (Martin Matuska) sent the following to the -current list: Dear community, Feel free to test everything and don't forget to report any bugs found. When I create a raidz pool of 3 equally sized hdd's (3x2Tb WD caviar green drives) the reported available space by zpool and zfs is VERY different (not just the known differences). On a 9.0-CURRENT amd64 box: # uname -a FreeBSD trinity.lordsith.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Tue Jul 13 21:58:14 UTC 2010 r...@trinity.lordsith.net:/usr/obj/usr/src/sys/trinity amd64 # zpool create pool1 raidz ada2 ada3 ada4 # zpool list pool1 NAMESIZE USED AVAILCAP HEALTH ALTROOT pool1 5.44T 147K 5.44T 0% ONLINE - # ada drives dmesg output: ada2 at ahcich4 bus 0 scbus5 target 0 lun 0 ada2: WDC WD20EARS-00MVWB0 50.0AB50 ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3 at ahcich5 bus 0 scbus6 target 0 lun 0 ada3: WDC WD20EARS-00MVWB0 50.0AB50 ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4 at ahcich6 bus 0 scbus7 target 0 lun 0 ada4: WDC WD20EADS-11R6B1 80.00A80 ATA-8 SATA 2.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) zfs list however only shows: # zfs list pool1 NAMEUSED AVAIL REFER MOUNTPOINT pool1 91.9K 3.56T 28.0K /pool1 I just lost the space of an entire hdd! To rule out a possible drive issue I created a raidz pool based on 3 65m files. # dd if=/dev/zero of=/file1 bs=1m count=65 # dd if=/dev/zero of=/file2 bs=1m count=65 # dd if=/dev/zero of=/file3 bs=1m count=65 # zpool create test raidz /file1 /file2 /file3 # # zpool list test NAME SIZE USED AVAILCAP HEALTH ALTROOT test 181M 147K 181M 0% ONLINE - # zfs list test NAME USED AVAIL REFER MOUNTPOINT test 91.9K 88.5M 28.0K /test When I create a non-redundant storage pool using the same 3 files or 3 drives the available space reported by zfs is what I'm expecting to see though so it looks like creating a raidz storage pool is showing very weird behavior. This doesn't have as much to do with the ZFS v15 bits commited to -HEAD since I have the exact same behavior on a 8.0-RELEASE-p2 i386 box with ZFS v14. A friend of mine is running osol build 117 but he created his raidz pool on an even older build though. His raidz pool also uses 3 equally-sized drives (3x2Tb) and his raidz pool is showing: % zfs list -r pool2 NAMEUSED AVAIL REFER MOUNTPOINT pool2 3.32T 2.06T 3.18T /export/pool2 % df -h pool2 Filesystem size used avail capacity Mounted on pool2 5.4T 3.2T 2.1T61%/export/pool2 To run further tests he also created a test raidz pool using 3 65m files: % zfs list test2 NAMEUSED AVAIL REFER MOUNTPOINT test2 73.5K 149M21K /test2 So on osol build 117 the available space is what I'm expecting to see whereas on FreeBSD 9.0-CURRENT amd64 and 8.0-RELEASE-p2 i386 Is someone having the same issues? Cheers, marco pgpQwcquU4UgC.pgp Description: PGP signature
Re: [HEADSUP] ZFS version 15 committed to head
Am 17.07.2010 um 12:14 schrieb Marco van Lienen: # zpool list pool1 NAMESIZE USED AVAILCAP HEALTH ALTROOT pool1 5.44T 147K 5.44T 0% ONLINE - ... zfs list however only shows: # zfs list pool1 NAMEUSED AVAIL REFER MOUNTPOINT pool1 91.9K 3.56T 28.0K /pool1 I just lost the space of an entire hdd! zpool always shows the raw capacity (without redundancy), zfs the actual available capacity. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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: [HEADSUP] ZFS version 15 committed to head
On Sat, Jul 17, 2010 at 12:25:56PM +0200, you (Stefan Bethke) sent the following to the -current list: Am 17.07.2010 um 12:14 schrieb Marco van Lienen: # zpool list pool1 NAMESIZE USED AVAILCAP HEALTH ALTROOT pool1 5.44T 147K 5.44T 0% ONLINE - ... zfs list however only shows: # zfs list pool1 NAMEUSED AVAIL REFER MOUNTPOINT pool1 91.9K 3.56T 28.0K /pool1 I just lost the space of an entire hdd! zpool always shows the raw capacity (without redundancy), zfs the actual available capacity. I have read many things about those differences, but why then does zfs on opensolaris report more available space whereas FreeBSD does not? That would imply that my friend running osol build 117 couldn't fill up his raidz pool past the 3.56T. marco pgpQK6Bhz2NSv.pgp Description: PGP signature
RAIDZ capacity (was ZFS version 15 committed to head)
Am 17.07.2010 um 12:51 schrieb Marco van Lienen: On Sat, Jul 17, 2010 at 12:25:56PM +0200, you (Stefan Bethke) sent the following to the -current list: Am 17.07.2010 um 12:14 schrieb Marco van Lienen: # zpool list pool1 NAMESIZE USED AVAILCAP HEALTH ALTROOT pool1 5.44T 147K 5.44T 0% ONLINE - ... zfs list however only shows: # zfs list pool1 NAMEUSED AVAIL REFER MOUNTPOINT pool1 91.9K 3.56T 28.0K /pool1 I just lost the space of an entire hdd! zpool always shows the raw capacity (without redundancy), zfs the actual available capacity. I have read many things about those differences, but why then does zfs on opensolaris report more available space whereas FreeBSD does not? That would imply that my friend running osol build 117 couldn't fill up his raidz pool past the 3.56T. You didn't show us how your friends pool is set up. With RAIDZ1, the capacity of one of the devices in the pool is used for redundancy, with RAIDZ2 it's two disks worth. So three 2TB disks with RAIDZ1 gives you 4TB net capacity. If you don't care about redundancy, use a simple concatenation, i. e. don't specify mirror, raidz or raidz2 when creating the pool. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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: periodic script in base system to run csup
On Fri, Jul 16, 2010 at 07:04:38PM -0400, Lowell Gilbert wrote: Alex Kozlov s...@rm-rf.kiev.ua writes: On Fri, Jul 16, 2010 at 04:27:39PM +0200, Gabor Kovesdan wrote: Em 2010.07.16. 16:23, Alex Kozlov escreveu: On Fri, Jul 16, 2010 at 03:58:33PM +0200, Gabor Kovesdan wrote: Thousands pc simultaneously try to access cvsup servers? Sound like a ddos to me. Yes, this was the only concern and that's why I started this discussion. And because its periodic, We can't use portsnap solution (random delay before csup start). It's not completely impossible; periodic could spin off a separate shell for it, with a random delay. It's not clear what the best way to deal with the output would be, although several approaches present themselves. It would be a lot more complicated than Gabor's approach, though. I think this is overengineering. I personally just put few lines in root's crontab: ? ? * * * * make -C /usr/src update' /dev/null and /etc/make.conf: SUPHOST=cvsup?.xx.FreeBSD.org SUP_UPDATE= true SUPFILE=/etc/site/supfile-rel #PORTSSUPFILE= /etc/site/supfile-port DOCSUPFILE= /etc/site/supfile-doc -- Adios ___ 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
Problem with ZFS version 15
Hi, i updated my 8.1-PRERELEASE to ZFS version 15. The patch http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch applies fine and after reboot i upgrade my pool successfully to version 15. Now, after a new reboot the bootloader can't boot from version 15, it supports only 13. Well, i build a bootable usb pen with 8.1-PRERELEASE and ZFS version 15, boot from it and apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says gpart: No such geom: ad0. How can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror on ad0 and ad1. Michael ___ Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ 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: nvidia-driver crashing kernel on head
On Sunday 11 July 2010 22:14:44 Doug Barton wrote: On 07/08/10 14:52, Rene Ladan wrote: On 08-07-2010 22:09, Doug Barton wrote: On Thu, 8 Jul 2010, John Baldwin wrote: These freezes and panics are due to the driver using a spin mutex instead of a regular mutex for the per-file descriptor event_mtx. If you patch the driver to change it to be a regular mutex I think that should fix the problems. Can you give an example? :) I don't mind creating a patch for all of them if you can illustrate what needs to be changed. See the attached patch In order to use 195.36.15 it was necessary to use the patch Rene sent, the suggestion from jhb previously to remove some locks, plus a bit more. The patch that got it working on HEAD for me (specifically r209633) is attached. With that patch I could start X, and run it for a while, but performance was very poor, even in comparison with the stock nv driver, and it crashed a couple times (although not nearly as bad as previously). So based on other suggestions I tried the newest release version at nvidia, 256.35. Some of the same locking stuff was needed to patch it, a patch for the port which includes the locking patch is also attached. If you are running an amd64 system you'll have to type 'make makesum' after applying this patch to the port. I'm not sure this patch is complete, or what Alexey might want to do with the update, but it does create an accurate plist which means you can cleanly deinstall/pkg_delete when you're done. With 256.35 performance and stability have both been quite good, comparable even to before the the drama started. The only concern I have at this point is that I'm periodically getting a strange sort of flash popping up on my screen that I didn't get while I was running the nv driver recently. It looks sort of like the default X background (the tiny gray crosshatch) is popping through for just a split second. I've been getting these messages on the console: NVRM: Xid (0001:00): 16, Head Count 000218d5 NVRM: Xid (0001:00): 8, Channel NVRM: Xid (0001:00): 16, Head Count 000218d6 NVRM: Xid (0001:00): 8, Channel 0002 This is preceded by X locking hard. I cannot VT switch to a normal console and sometimes the computer needs a hard reset (i.e. does not respond to power button). It appears to only trigger when under heavy load. eg make -C /usr/src -j8 buildworld This seems to be messing with interrupts with other subsystems as my network drivers are less than reliable of late. (Watchdog timeouts). This happens with 195.36.15 unpatched and 256.35 patched. I have not checked if booting with WITNESS enabled works. Regards signature.asc Description: This is a digitally signed message part.
Re: RAIDZ capacity (was ZFS version 15 committed to head)
On Sat, Jul 17, 2010 at 01:04:52PM +0200, you (Stefan Bethke) sent the following to the -current list: I have read many things about those differences, but why then does zfs on opensolaris report more available space whereas FreeBSD does not? That would imply that my friend running osol build 117 couldn't fill up his raidz pool past the 3.56T. You didn't show us how your friends pool is set up. With RAIDZ1, the capacity of one of the devices in the pool is used for redundancy, with RAIDZ2 it's two disks worth. So three 2TB disks with RAIDZ1 gives you 4TB net capacity. If you don't care about redundancy, use a simple concatenation, i. e. don't specify mirror, raidz or raidz2 when creating the pool. My friend created his raidz pool just the same way as I did: zpool create pool2 raidz c0d0 c0d1 c0d2 So just 3 dedicated drives. I also posted the example of creating a test raidz pool based on 3 65Mb files. On osol there is more available space being reported by 'zfs list' on that test raidz pool When I created a similar test raidz pool also based on 3 65Mb files, 'zfs list' on my FreeBSD boxes (9.0-CURRENT amd64 and 8.0-RELEASE-p2 i386) is showing much less available space. So regardless whether we use whole disks or simply files for testing purposes, 'zfs list' on the osol system is reporting more available space. cheers, marco pgpvoeRVwVWU8.pgp Description: PGP signature
Re: [HEADSUP] ZFS version 15 committed to head
On Sat, Jul 17, 2010 at 3:51 AM, Marco van Lienen marco+freebsd-curr...@lordsith.net wrote: On Sat, Jul 17, 2010 at 12:25:56PM +0200, you (Stefan Bethke) sent the following to the -current list: Am 17.07.2010 um 12:14 schrieb Marco van Lienen: # zpool list pool1 NAME SIZE USED AVAIL CAP HEALTH ALTROOT pool1 5.44T 147K 5.44T 0% ONLINE - ... zfs list however only shows: # zfs list pool1 NAME USED AVAIL REFER MOUNTPOINT pool1 91.9K 3.56T 28.0K /pool1 I just lost the space of an entire hdd! zpool always shows the raw capacity (without redundancy), zfs the actual available capacity. I have read many things about those differences, but why then does zfs on opensolaris report more available space whereas FreeBSD does not? That would imply that my friend running osol build 117 couldn't fill up his raidz pool past the 3.56T. You used different commands to check the disk space on OSol (zpool vs df). Try the same commands on both FreeBSD and OSol (zpool and zfs) and you'll see the same results. df works differently on OSol than it does on FreeBSD, you can't compare them. -- Freddie Cash fjwc...@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
Filesystem wedge, SUJ-related?
Hi guys, Semi-regularly (every two-three days) I'm seeing what appears to be some sort of filesystem wedge. I usually see it initially with web browsers, but it's possible that's only because it's what produces most disk activity on this machine. I've seen it with both Opera and Firefox. What happens is that the process will just wedge. A procstat -kk on it shows the following stack backtrace: 9012 100243 firefox-bin initial thread mi_switch+0x21d sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c Xfast_syscall+0xe2 8954 100231 operainitial thread mi_switch+0x21d sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c Xfast_syscall+0xe2 Reading from the disk is fine, indeed writing to the disk seems to work fine for other applications, even once a browser has wedged. I've included the output of sysctl -a | grep debug.softdep later in the email, in case it gives any clues. This was taken while the system was idle, about an hour after both Firefox and Opera had wedged. As I say, this happens every few days, so please let me know what further information can be useful to diagnose this. I can get info from the debugger too - but as I don't have much experience diagnosing FS issues somebody needs to tell me which info to obtain other than the standard (alltrace, ps, etc). Thanks, Gavin debug.softdep.jwait_newblk: 3 debug.softdep.jwait_inode: 44 debug.softdep.jwait_freeblks: 115 debug.softdep.jwait_filepage: 181 debug.softdep.journal_wait: 15488 debug.softdep.journal_min: 0 debug.softdep.journal_low: 0 debug.softdep.jnewblk_rollback: 27953 debug.softdep.jaddref_rollback: 1811 debug.softdep.dir_entry: 23248 debug.softdep.direct_blk_ptrs: 5975 debug.softdep.inode_bitmap: 8631 debug.softdep.indir_blk_ptrs: 7670 debug.softdep.sync_limit_hit: 0 debug.softdep.ino_limit_hit: 0 debug.softdep.blk_limit_hit: 0 debug.softdep.ino_limit_push: 0 debug.softdep.blk_limit_push: 0 debug.softdep.worklist_push: 0 debug.softdep.maxindirdeps: 50 debug.softdep.tickdelay: 2 debug.softdep.max_softdeps: 40 debug.softdep.current.jtrunc: 0 debug.softdep.current.sbdep: 0 debug.softdep.current.jsegdep: 5218 debug.softdep.current.jseg: 3921 debug.softdep.current.jfreefrag: 0 debug.softdep.current.jfreeblk: 0 debug.softdep.current.jnewblk: 0 debug.softdep.current.jmvref: 0 debug.softdep.current.jremref: 0 debug.softdep.current.jaddref: 11 debug.softdep.current.freedep: 18 debug.softdep.current.freework: 4666 debug.softdep.current.newdirblk: 0 debug.softdep.current.dirrem: 122 debug.softdep.current.mkdir: 0 debug.softdep.current.diradd: 132 debug.softdep.current.freefile: 2 debug.softdep.current.freeblks: 4198 debug.softdep.current.freefrag: 0 debug.softdep.current.allocindir: 0 debug.softdep.current.indirdep: 4 debug.softdep.current.allocdirect: 0 debug.softdep.current.newblk: 255 debug.softdep.current.bmsafemap: 3 debug.softdep.current.inodedep: 284 debug.softdep.current.pagedep: 119 debug.softdep.total.jtrunc: 114 debug.softdep.total.sbdep: 6109 debug.softdep.total.jsegdep: 489669 debug.softdep.total.jseg: 23468 debug.softdep.total.jfreefrag: 67993 debug.softdep.total.jfreeblk: 53638 debug.softdep.total.jnewblk: 180654 debug.softdep.total.jmvref: 160 debug.softdep.total.jremref: 95199 debug.softdep.total.jaddref: 92071 debug.softdep.total.freedep: 1044 debug.softdep.total.freework: 57287 debug.softdep.total.newdirblk: 267 debug.softdep.total.dirrem: 95173 debug.softdep.total.mkdir: 490 debug.softdep.total.diradd: 91573 debug.softdep.total.freefile: 67115 debug.softdep.total.freeblks: 38486 debug.softdep.total.freefrag: 67993 debug.softdep.total.allocindir: 0 debug.softdep.total.indirdep: 3798 debug.softdep.total.allocdirect: 0 debug.softdep.total.newblk: 180654 debug.softdep.total.bmsafemap: 11319 debug.softdep.total.inodedep: 197151 debug.softdep.total.pagedep: 89352 ___ 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: Why is intr taking up so much cpu?
On Sat, 17 Jul 2010, Rui Paulo wrote: On 17 Jul 2010, at 08:17, Doug Barton wrote: This is happening after I open a flash video in firefox and watch it for 15 minutes: root 20 -80- 0K 160K WAIT0 3:38 14.08% intr After this happens, my system goes into a death spiral and I have to shut it down. vmstat -i interrupt total rate irq1: atkbd0 10384 0 irq9: acpi05 0 irq14: ata0 153410 7 irq15: ata1 58 0 irq17: wpi0 534038 27 irq20: hpet0 uhci0+ 2496833129 irq22: uhci2 66485 3 cpu0:timer 19238037999 irq256: hdac0 189713 9 cpu1:timer 19236431999 Total 41925394 2178 Any suggestions? current (r210135), i386 smp. Dell C2D laptop. What's vmstat -i before the event happens? Here is the output after a clean boot: interrupt total rate irq1: atkbd0 424 4 irq9: acpi02 0 irq14: ata0 3266 30 irq15: ata1 58 0 irq17: wpi0 2012 18 irq20: hpet0 uhci0+13763129 irq22: uhci2 16 0 cpu0:timer105150991 irq256: hdac0 10 0 cpu1:timer103716978 Total 228417 2154 Thanks for the response, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: [HEADSUP] ZFS version 15 committed to head
On Sat, Jul 17, 2010 at 10:12:10AM -0700, you (Freddie Cash) sent the following to the -current list: I have read many things about those differences, but why then does zfs on opensolaris report more available space whereas FreeBSD does not? That would imply that my friend running osol build 117 couldn't fill up his raidz pool past the 3.56T. You used different commands to check the disk space on OSol (zpool vs df). Try the same commands on both FreeBSD and OSol (zpool and zfs) and you'll see the same results. I guess you missed my original mail of this thread in which I also showed the output of 'zfs list -r pool2' on osol where clearly there is more available space shown then on FreeBSD. % zfs list -r pool2 NAMEUSED AVAIL REFER MOUNTPOINT pool2 3.32T 2.06T 3.18T /export/pool2 df works differently on OSol than it does on FreeBSD, you can't compare them. HTH ___ 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: Why is intr taking up so much cpu?
On 17 Jul 2010, at 19:04, Doug Barton wrote: On Sat, 17 Jul 2010, Rui Paulo wrote: On 17 Jul 2010, at 08:17, Doug Barton wrote: This is happening after I open a flash video in firefox and watch it for 15 minutes: root 20 -80- 0K 160K WAIT0 3:38 14.08% intr After this happens, my system goes into a death spiral and I have to shut it down. vmstat -i interrupt total rate irq1: atkbd0 10384 0 irq9: acpi05 0 irq14: ata0 153410 7 irq15: ata1 58 0 irq17: wpi0 534038 27 irq20: hpet0 uhci0+ 2496833129 irq22: uhci2 66485 3 cpu0:timer 19238037999 irq256: hdac0 189713 9 cpu1:timer 19236431999 Total 41925394 2178 Any suggestions? current (r210135), i386 smp. Dell C2D laptop. What's vmstat -i before the event happens? Here is the output after a clean boot: interrupt total rate irq1: atkbd0 424 4 irq9: acpi02 0 irq14: ata0 3266 30 irq15: ata1 58 0 irq17: wpi0 2012 18 irq20: hpet0 uhci0+13763129 irq22: uhci2 16 0 cpu0:timer105150991 irq256: hdac0 10 0 cpu1:timer103716978 Total 228417 2154 Thanks for the response, This doesn't indicate any problem. I suggest you try to figure out what interrupt is causing this by adding printfs or disabling drivers one by one. Regards, -- Rui Paulo ___ 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: Why is intr taking up so much cpu?
On 17 Jul 2010, at 08:17, Doug Barton wrote: This is happening after I open a flash video in firefox and watch it for 15 minutes: root 20 -80- 0K 160K WAIT0 3:38 14.08% intr After this happens, my system goes into a death spiral and I have to shut it down. vmstat -i interrupt total rate irq1: atkbd0 10384 0 irq9: acpi05 0 irq14: ata0 153410 7 irq15: ata1 58 0 irq17: wpi0 534038 27 irq20: hpet0 uhci0+ 2496833129 irq22: uhci2 66485 3 cpu0:timer 19238037999 irq256: hdac0 189713 9 cpu1:timer 19236431999 Total 41925394 2178 Any suggestions? current (r210135), i386 smp. Dell C2D laptop. What's vmstat -i before the event happens? Regards, -- Rui Paulo ___ 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: [HEADSUP] ZFS version 15 committed to head
On Sat, Jul 17, 2010 at 11:21 AM, Marco van Lienen marco+freebsd-curr...@lordsith.net wrote: On Sat, Jul 17, 2010 at 10:12:10AM -0700, you (Freddie Cash) sent the following to the -current list: I have read many things about those differences, but why then does zfs on opensolaris report more available space whereas FreeBSD does not? That would imply that my friend running osol build 117 couldn't fill up his raidz pool past the 3.56T. You used different commands to check the disk space on OSol (zpool vs df). Try the same commands on both FreeBSD and OSol (zpool and zfs) and you'll see the same results. I guess you missed my original mail of this thread in which I also showed the output of 'zfs list -r pool2' on osol where clearly there is more available space shown then on FreeBSD. % zfs list -r pool2 NAME USED AVAIL REFER MOUNTPOINT pool2 3.32T 2.06T 3.18T /export/pool2 No, I saw that. But you compared zpool and zfs output on FreeBSD, and zfs and df output on OSol. IOW, you didn't compare the same things. Compare the output of zpool and zfs on both FreeBSD and OSol, it should be the same. -- Freddie Cash fjwc...@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: Why is intr taking up so much cpu?
On Sat, 17 Jul 2010, Rui Paulo wrote: This doesn't indicate any problem. I suggest you try to figure out what interrupt is causing this by adding printfs or disabling drivers one by one. I've no idea where to even begin on something like that. Given that there are other -current users who are also having problems (particularly with the nvidia drivers) I'm wondering if some sort of systemic debugging isn't in order here? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: Why is intr taking up so much cpu?
On 17 Jul 2010, at 20:10, Doug Barton wrote: On Sat, 17 Jul 2010, Rui Paulo wrote: This doesn't indicate any problem. I suggest you try to figure out what interrupt is causing this by adding printfs or disabling drivers one by one. I've no idea where to even begin on something like that. Given that there are other -current users who are also having problems (particularly with the nvidia drivers) I'm wondering if some sort of systemic debugging isn't in order here? You can try bisecting the faulty revision. Regards, -- Rui Paulo ___ 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: Why is intr taking up so much cpu?
On Sat, 17 Jul 2010, Rui Paulo wrote: You can try bisecting the faulty revision. The problem has been going on for months, the primary symptom for a long time was the nvidia driver, so I stopped using it for a while hoping that a solution would magically appear. As of the last 6 weeks or so the problem has started happening even without using the nvidia driver, and more users are reporting similar symptoms. So in short, no, I won't be doing that, as there is way too much history to slog back through at this point. What I would like to see is some sort of effort on the part of those who've made the changes to help debug what's wrong with them. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: Why is intr taking up so much cpu?
On Sat, Jul 17, 2010 at 12:10:26PM -0700, Doug Barton wrote: On Sat, 17 Jul 2010, Rui Paulo wrote: This doesn't indicate any problem. I suggest you try to figure out what interrupt is causing this by adding printfs or disabling drivers one by one. I've no idea where to even begin on something like that. Given that there are other -current users who are also having problems (particularly with the nvidia drivers) I'm wondering if some sort of systemic debugging isn't in order here? Note that intr time most likely come from the interrupt threads chewing the CPU, not from the real interrupt handlers doing something, and definitely not due to the high interrupt rate, as your vmstat -i output already shown. Run top in the mode where all system threads are shown separately (e.g. top -HS seems to do it), then watch what thread eats the processor. pgpndi3E8dqD5.pgp Description: PGP signature
Re: Why is intr taking up so much cpu?
On Sat, 17 Jul 2010, Kostik Belousov wrote: Note that intr time most likely come from the interrupt threads chewing the CPU, not from the real interrupt handlers doing something, and definitely not due to the high interrupt rate, as your vmstat -i output already shown. Run top in the mode where all system threads are shown separately (e.g. top -HS seems to do it), then watch what thread eats the processor. Ok, thanks, I'll definitely do that next time and report the results. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: periodic script in base system to run csup
On Fri, 16 Jul 2010 09:58, Gabor Kovesdan wrote: In Message-Id: 4c406589.7030...@freebsd.org Hi folks, Steven Kreuzer wrote a periodic script to run csup updates with periodic daily. I've reviewed it and added support for multiple supfiles. I'd like to commit this to head. : http://kovesdan.org/files/600.csup : : Is there any objection? In a message listed in this thread someone has mentioned that this can already be done from cron. ( make -C /usr/src update ) at your own preferred time of updating. No offense but including something like this into the periodic system without a way to randomize the time at which it will actually run would be irresponsible while wreaking havoc on the source servers and I would strongly advise against it. *** If a way to randomize the time at which this is run is conceived and you wish to proceed I would also strongly advise that it is moved to a periodic weekly location instead. *** Personally I see updating your source tree as a interactive process unless for the use of a mirroring server which is not needed on every machine this would end up on. Adding this I only see results of blatant enabling the controls creating pointless mirrors. Maybe adding this to src/tools would be a better place or creating a port for this. With all do respect Regards, -- jhell,v ___ 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: svn commit: r210194 - head/sys/fs/unionfs
On 17.07.10 17:45, Edward Tomasz Napierala wrote: Author: trasz Date: Sat Jul 17 15:45:20 2010 New Revision: 210194 URL: http://svn.freebsd.org/changeset/base/210194 Log: Remove updating process count by unionfs. It serves no purpose, unionfs just needs root credentials for a moment. Modified: head/sys/fs/unionfs/union_subr.c Modified: head/sys/fs/unionfs/union_subr.c == --- head/sys/fs/unionfs/union_subr.cSat Jul 17 13:34:01 2010 (r210193) +++ head/sys/fs/unionfs/union_subr.cSat Jul 17 15:45:20 2010 (r210194) @@ -50,7 +50,6 @@ #includesys/fcntl.h #includesys/filedesc.h #includesys/stat.h -#includesys/resourcevar.h #includesecurity/mac/mac_framework.h @@ -775,7 +774,6 @@ unionfs_mkshadowdir(struct unionfs_mount /* Authority change to root */ rootinfo = uifind((uid_t)0); cred = crdup(cnp-cn_cred); - chgproccnt(cred-cr_ruidinfo, 1, 0); change_euid(cred, rootinfo); change_ruid(cred, rootinfo); change_svuid(cred, (uid_t)0); @@ -825,7 +823,6 @@ unionfs_mkshadowdir_free_out: unionfs_mkshadowdir_abort: cnp-cn_cred = credbk; - chgproccnt(cred-cr_ruidinfo, -1, 0); crfree(cred); return (error); ___ svn-src-h...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org cc1: warnings being treated as errors /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c: In function 'unionfs_mkshadowdir': /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: warning: implicit declaration of function 'uifind' /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: warning: nested extern declaration of 'uifind' /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:775: warning: assignment makes pointer from integer without a cast /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:780: warning: implicit declaration of function 'uifree' /export/devel/fbsd/head/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:780: warning: nested extern declaration of 'uifree' Hm, I'd like to include this one again: [tc:fbsd/head/src] andreast% svn diff sys/fs/unionfs/union_subr.c Index: sys/fs/unionfs/union_subr.c === --- sys/fs/unionfs/union_subr.c (revision 210200) +++ sys/fs/unionfs/union_subr.c (working copy) @@ -50,6 +50,7 @@ #include sys/fcntl.h #include sys/filedesc.h #include sys/stat.h +#include sys/resourcevar.h #include security/mac/mac_framework.h Gruss, Andreas ___ 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
sensitive emt64 performance degradation over amd64
Hello list, im running two freebsd dists , each one in a diferent notebook.. i have a freebsd 8.1 rc2 running in amd64 with 2 cores 2MB mem.. (my old hp), and a freebsd 9-current running on a intel i3 (2 cores + 2 logical cores) with 4 MB ram.. and im was noting that the amd notebook was performing really fast compared to the i3.. even with for each core of i3 the clock been superior to the amd that i got here... i was looking to the kernel build and disable all the debug options from the 9 / kernel before the SMP option.. to see if it was the performance penalty cause... but that doesnt help to much... i didnt find any cpu flag to build the kernel specific to the intel arquitecture and leave the HAMMER option alone, knowing that emt64 and amd64 pretty the same thing... what could be happening... the biggest number of cores? .. or its a common thing... freebsd perform better on amd hardware... (note that i cant be too precise , since i didnt go any further with more tests... its more a subjective feel (boot time, general use.. etc)) Thanks, Fabio Kaminski ___ 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
