Re: Why is intr taking up so much cpu?
On Sat, 17 Jul 2010, Kostik Belousov wrote:
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.
And the winner is!
11 root -32- 0K 168K WAIT0 0:28 18.02% {swi4: clock}
11 root21 -64- 0K 168K WAIT0 1:17 18.90% intr
The first is with -H, the second without.
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 10:21:28PM +0300, Kostik Belousov wrote: 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. I've noticed a few webpages to trigger lot of X11 related network traffic just by watching them even without any seeable content change, but CPU load on browser and especialy X process went high, but of course symptoms might be different with different drivers - I use mga myself. I never analysed it properly beacuse I'm using a quite old Xorg version, but I see the increase of traffic on the domain socket. I also noticed that recent firefox and seamonkey are doing lots of NFS traffic, so I was forced to switch ~/.mozilla to a local disk, where iostat still stays idle. But my OS is also not very recent, so I also never debugged this problem. 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. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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 Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote:
On Sat, 17 Jul 2010, Kostik Belousov wrote:
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.
And the winner is!
11 root -32- 0K 168K WAIT0 0:28 18.02% {swi4:
clock}
11 root21 -64- 0K 168K WAIT0 1:17 18.90% intr
The first is with -H, the second without.
Most likely it is some callout handling. Just in case, do you have
console screensaver active ?
pgpnr7b4o3rZt.pgp
Description: PGP signature
Re: RAIDZ capacity (was ZFS version 15 committed to head)
Am 17.07.2010 um 16:30 schrieb Marco van Lienen: 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. I suggest to read up on ZFS a bit more. With OpenSolaris 09.06, with three 20 GB virtual disks, I'm getting this: r...@opensolaris:~# zpool create tank raidz c8t1d0 c8t2d0 c8t3d0 r...@opensolaris:~# zpool list NAME SIZE USED AVAILCAP HEALTH ALTROOT tank 59.5G 881K 59.5G 0% ONLINE - r...@opensolaris:~# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 91.2K 39.0G 25.3K /tank Which is exactly the same behavior as with FreeBSD. And of course you only get to store 40 GB worth of files on this filesystem. 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: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On Fri, Jul 16, 2010 at 12:31:26PM +0200, Stle Kristoffersen wrote: On 2010-07-15 at 19:52, St?le Kristoffersen wrote: On 2010-07-15 at 18:00, Marius Strobl wrote: On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: Upgraded to from stable to current yesterday and very quickly received a panic. It did however not dump it's core, so I was unable to debug it. Today it did panic again, and I took a picture: (Sorry about the bad quality) http://folk.uio.no/stalk/mpt/IMG_1403.JPG And from the backtrace: http://folk.uio.no/stalk/mpt/IMG_1404.JPG Both times I hade the mpt0: request timed out just before the panic. I'm not sure why it's not dumping it's core (It was working under stable, and I have dumpdev=AUTO and dumpdir=/var/crash in rc.conf) What revision were you using? Not sure exactly what revision I was using, is there an easy way to figure that out? I ran cvsupdate around 13:00 CEST yesterday. Does using current as of r209598 make a difference? Downgrading now... And it crashed again, with current from r209598... Ok, this at least means that your problem isn't caused by the recent changes to mpt(4) as the pre-r209599 version only differed from the 8-STABLE one in a cosmetic change at that time. Marius ___ 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, 17 Jul 2010 12:51:34 +0200 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 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. If you compare the yfs list output of OSol and FreeBSD and they differ where they shouldn't, you should have a look if compression and/or deduplication (were available) is activated. Bye, Alexander. ___ 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: Filesystem wedge, SUJ-related?
On Sat, 17 Jul 2010, Gavin Atkinson wrote: 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 A bit more detail: it does look like whatever is supposed to periodically flush the journal just stops doing it's job. Presumably this is also the root cause of the softdep: Out of journal space! messages I have been seeing in the past, which I had assumed may have been fixed by r209717. (I'm running r209723 at the moment) While processes are starting to hang, sh ffs from ddb shows: db sh ffs mp 0xff0002c45be0 / devvp 0xff0002c51000 fs 0xff0002c67000 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002d705f0 /tmp devvp 0xff0002d48780 fs 0xff0002c64800 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002c458e8 /usr devvp 0xff0002d485a0 fs 0xff0002c66000 su_wl 0 su_wl_in 0 su_deps 17345 su_req 0 mp 0xff0002c455f0 /var devvp 0xff0002d483c0 fs 0xff0002c66800 su_wl 0 su_wl_in 0 su_deps 55 su_req 0 Leaving it another couple of hours, I then see: db sh ffs mp 0xff0002c45be0 / devvp 0xff0002c51000 fs 0xff0002c67000 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xff0002d705f0 /tmp devvp 0xff0002d48780 fs 0xff0002c64800 su_wl 0 su_wl_in 0 su_deps 36 su_req 0 mp 0xff0002c458e8 /usr devvp 0xff0002d485a0 fs 0xff0002c66000 su_wl 0 su_wl_in 0 su_deps 31899 su_req 0 mp 0xff0002c455f0 /var devvp 0xff0002d483c0 fs 0xff0002c66800 su_wl 0 su_wl_in 0 su_deps 95 su_req 0 so, su_deps is increasing significantly. During reboot, vnlru failed to stop within 60 seconds, and gave up on syncing 125 vnodes and 140 buffers (no idea if these are related). On reboot, SU+J fsck shows for /usr: ** SU+J Recovering /dev/ad4s1f ** Reading 33554432 byte journal from inode 150. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 405991 journal records in 18194944 bytes for 71.40% utilization ** Freed 3872 inodes (0 dirs) 48157 blocks, and 8744 frags. So it seems clear that somehow the journal is filling up, and never being written. Any other suggestions as to where I should go from here? Thanks, Gaivn ___ 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: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On 2010-07-16 at 12:31, Ståle Kristoffersen wrote: On 2010-07-15 at 19:52, Ståle Kristoffersen wrote: On 2010-07-15 at 18:00, Marius Strobl wrote: On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: Upgraded to from stable to current yesterday and very quickly received a panic. It did however not dump it's core, so I was unable to debug it. Today it did panic again, and I took a picture: (Sorry about the bad quality) http://folk.uio.no/stalk/mpt/IMG_1403.JPG And from the backtrace: http://folk.uio.no/stalk/mpt/IMG_1404.JPG Both times I hade the mpt0: request timed out just before the panic. I'm not sure why it's not dumping it's core (It was working under stable, and I have dumpdev=AUTO and dumpdir=/var/crash in rc.conf) What revision were you using? Not sure exactly what revision I was using, is there an easy way to figure that out? I ran cvsupdate around 13:00 CEST yesterday. Does using current as of r209598 make a difference? Downgrading now... And it crashed again, with current from r209598... It still keeps on crashing :/ I grabbed the output of show alllocks: http://folk.uio.no/stalk/mpt/IMAG0047.jpg To me it looks like maybe there is a race condition or something that makes TAILQ_REMOVE-call in mpt_scsi_tmf_reply_handler() work on an element that has been removed, but this is an un-educated guess ;) I do not understand enough of the driver to follow the flow of the requests around the driver. -- Ståle Kristoffersen ___ 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
[head tinderbox] failure on sparc64/sparc64
TB --- 2010-07-18 16:59:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-18 16:59:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-07-18 16:59:15 - cleaning the object tree TB --- 2010-07-18 16:59:27 - cvsupping the source tree TB --- 2010-07-18 16:59:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-07-18 17:35:45 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-18 17:35:45 - ERROR: unable to cvsup the source tree TB --- 2010-07-18 17:35:45 - 0.58 user 7.79 system 2190.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ 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
[head tinderbox] failure on sparc64/sun4v
TB --- 2010-07-18 17:03:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-18 17:03:19 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-07-18 17:03:19 - cleaning the object tree TB --- 2010-07-18 17:03:30 - cvsupping the source tree TB --- 2010-07-18 17:03:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-07-18 17:43:50 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-18 17:43:50 - ERROR: unable to cvsup the source tree TB --- 2010-07-18 17:43:50 - 0.52 user 6.58 system 2430.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full ___ 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
[head tinderbox] failure on powerpc/powerpc
TB --- 2010-07-18 16:56:36 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-18 16:56:36 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-07-18 16:56:36 - cleaning the object tree TB --- 2010-07-18 16:56:52 - cvsupping the source tree TB --- 2010-07-18 16:56:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-07-18 19:06:52 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-18 19:06:52 - ERROR: unable to cvsup the source tree TB --- 2010-07-18 19:06:52 - 0.85 user 8.25 system 7816.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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 07/18/10 03:30, Kostik Belousov wrote:
On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote:
On Sat, 17 Jul 2010, Kostik Belousov wrote:
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.
And the winner is!
11 root -32- 0K 168K WAIT0 0:28 18.02% {swi4:
clock}
11 root21 -64- 0K 168K WAIT0 1:17 18.90% intr
The first is with -H, the second without.
Most likely it is some callout handling. Just in case, do you have
console screensaver active ?
I assume you mean saver=yes in rc.conf, and the answer is no, I am not
using that. Usually I run xscreensaver, but at the time this happened I
was not. I do have DPMS enabled in my X config though.
Any suggestions on how to dig deeper on this? Are there any settings I
can twiddle to try and mitigate it?
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.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
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
Re: Why is intr taking up so much cpu?
On Sun, Jul 18, 2010 at 12:21:00PM -0700, Doug Barton wrote:
On 07/18/10 03:30, Kostik Belousov wrote:
On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote:
On Sat, 17 Jul 2010, Kostik Belousov wrote:
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.
And the winner is!
11 root -32- 0K 168K WAIT0 0:28 18.02% {swi4:
clock}
11 root21 -64- 0K 168K WAIT0 1:17 18.90% intr
The first is with -H, the second without.
Most likely it is some callout handling. Just in case, do you have
console screensaver active ?
I assume you mean saver=yes in rc.conf, and the answer is no, I am not
using that. Usually I run xscreensaver, but at the time this happened I
was not. I do have DPMS enabled in my X config though.
Any suggestions on how to dig deeper on this? Are there any settings I
can twiddle to try and mitigate it?
When intr time starts accumulating again, try to do
procstat -kk intr process pid and correlate the clock thread tid
with the backtrace. Might be, it helps to guess what callouts are eating
the CPU.
pgpzAHoszwKlb.pgp
Description: PGP signature
Re: Why is intr taking up so much cpu?
On 07/18/10 12:41, Kostik Belousov wrote: When intr time starts accumulating again, try to do procstat -kk intr process pid and correlate the clock thread tid with the backtrace. Might be, it helps to guess what callouts are eating the CPU. Will do, thanks! Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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?
In the last episode (Jul 18), Doug Barton said:
On 07/18/10 12:41, Kostik Belousov wrote:
When intr time starts accumulating again, try to do
procstat -kk intr process pid and correlate the clock thread tid
with the backtrace. Might be, it helps to guess what callouts are eating
the CPU.
Will do, thanks!
You can also use dtrace to get a count of callouts and their time spent.
Run this for a few seconds then hit ^C:
#! /usr/sbin/dtrace -s
/* #pragma D option quiet */
callout_execute:::callout_start
{
this-start = timestamp;
}
callout_execute:::callout_end
{
this-end = timestamp;
/* printf(%a %d\n,args[0]-c_func, this-end - this-start); */
@times[args[0]-c_func] = quantize(this-end - this-start);
/* @times[args[0]-c_func] = lquantize(this-end -
this-start,0,30,1); */
@counts[args[0]-c_func] = count();
}
END
{
printa(%a %...@u\n,@times);
printa(%a %...@u\n,@counts);
}
--
Dan Nelson
dnel...@allantgroup.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?
In the last episode (Jul 18), Dan Nelson said: In the last episode (Jul 18), Doug Barton said: On 07/18/10 12:41, Kostik Belousov wrote: When intr time starts accumulating again, try to do procstat -kk intr process pid and correlate the clock thread tid with the backtrace. Might be, it helps to guess what callouts are eating the CPU. Will do, thanks! You can also use dtrace to get a count of callouts and their time spent. Run this for a few seconds then hit ^C: That may actually be too verbose (you'll get a histogram per callout). Try the ones at http://wiki.freebsd.org/DTrace/Examples instead. -- Dan Nelson dnel...@allantgroup.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
Can't make distribution TARGET_ARCH=... after r209510
Hi! Attemt to make jail with different target arch on tinderbox (i386 jail on amd64 host) exits with error: ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp Last lines from log: cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail install: freebsd.cf: No such file or directory *** Error code 71 Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. *** Error code 1 Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. Full build and distribution logs avaliable on http://levsha.me/tmp/20100718/world.txt (20M) http://levsha.me/tmp/20100718/distribution.txt (7.4K) Reverting r209510 fixes this problem -- LEFT-(UANIC|RIPE) JID: lev...@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 ___ 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: [CFT] ZFS v15 patch (version 3)
Ivan Voras ivo...@freebsd.org writes: Hello Ivan, I'm not a Solaris guy but from http://hub.opensolaris.org/bin/view/Project+comstar/ it looks like COMSTAR does something similar to what FreeBSD's GEOM does now. Ok. It seems to me that COMSTAR provides one functionality that GEOM misses, a generic SCSI target with plugins for different transports. It seems this overlaps with CAM. Having the same level of functionality as OSol regarding iSCSI exports of ZVols would be really nice. I plan to deploy a storage server @home and OSol seems pretty desirable in this area (native iSCSI for ZVols smb for ZFS filesystems, all imho nicely integrated). Regards Eric Masson -- J'ai pas tout compris... Tu fais ta répartie et tu te proposes au GNU en même temps ? C'est vrai que ça mérite le GNU, mais peut-être pas pour ce que tu crois... -+- BQL in GNU : Gnutez moi, gnutez moi, gnutez moi ça... -+- ___ 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: Can't make distribution TARGET_ARCH=... after r209510
In message: 20100718210154.ga94...@laptop.levsha.me Mykola Dzham i...@levsha.me writes: : Hi! : Attemt to make jail with different target arch on tinderbox (i386 jail : on amd64 host) exits with error: : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : Last lines from log: : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : install: freebsd.cf: No such file or directory : *** Error code 71 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : *** Error code 1 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : Full build and distribution logs avaliable on : http://levsha.me/tmp/20100718/world.txt (20M) : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : Reverting r209510 fixes this problem Try setting both TARGET and TARGET_ARCH. TARGET_ARCH was depricated in favor of TARGET in FreeBSD 8.0. Warner ___ 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: Can't make distribution TARGET_ARCH=... after r209510
In message: 20100718210154.ga94...@laptop.levsha.me Mykola Dzham i...@levsha.me writes: : Hi! : Attemt to make jail with different target arch on tinderbox (i386 jail : on amd64 host) exits with error: : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : Last lines from log: : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : install: freebsd.cf: No such file or directory : *** Error code 71 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : *** Error code 1 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : Full build and distribution logs avaliable on : http://levsha.me/tmp/20100718/world.txt (20M) : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : Reverting r209510 fixes this problem It works for me. on an amd64 box: setenv TARGET=i386 make buildworld make installworld DESTDIR=/tmp/mumble make distribution DESTDIR=/tmp/mumble Warner ___ 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: [panic] Race in IEEE802.11 layer towards device drivers
[NB] Obviously, I didn't click reply ALL last time, so here are missing part
-if(vap-iv_opmode == IEEE80211_M_HOSTAP){
-RUN_LOCK(sc);
+if (vap-iv_opmode == IEEE80211_M_HOSTAP)
sc-cmdq_key_set = RUN_CMDQ_GO;
-RUN_UNLOCK(sc);
-}
Why are you removing these locks?
It is simple assignment, it must be atomic.
Not necessarily. If you don't put lock statements around it or use the
volatile keyword, the compiler can re-organize the execution order. I will
have a look at it.
Another question:
i = RUN_CMDQ_GET(sc-cmdq_store);
DPRINTF(cmdq_store=%d\n, i);
sc-cmdq[i].func = run_update_beacon_cb;
sc-cmdq[i].arg0 = vap;
Why is this code and similar places not enclosed with mutexes?
First, I couldn't use a lock in key_delete() because of LoR. So, I use
atomic instead. RUN_CMDQ_GET is atomic_fetch_add(). Whatever executes that
code gets unique place (cmdq[i]) to write, so there shouldn't be any race.
Then out of order execution happened. Specially, when key_set() overtakes
key_delete(), encryption fails. So, all deferred processes are called back
via run_cmdq_cb() to maintain the order. Because cmdq functions are first
written for key_delete() where lock causes LoR. So, lock isn't needed.
run_cmdq_cb() uses lock. But it is for calling callback functions locked.
So that, functions just call another function locked, like
##_callback()
{
LOCK();
##_locked();
UNLOCK();
}
won't be needed.
If the run_cmdq_cb() is running at the same time which you are queuing
elements, then I note that you set .func before .arg0. The ##_callback() code
only checks if .func has been set. Actually the i increment should be after
that you filled out the data, and then you see that you cannot use atomic. I
think the most simple solution is to add another mutex, sc-sc_cmdq_mtx,
which
protects the queue and it's associated data. Also, what do you do if the
queue
wraps around? You should have a mechanism to prevent that, because you then
might start executing commands in random order?
Here is a patch (patch against P4 if_run.c rev 14 and if_runvar.h rev 8)
-- begin patch --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index 8c96534..c988ad4 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -90,12 +90,6 @@ SYSCTL_INT(_hw_usb_run, OID_AUTO, debug, CTLFLAG_RW,
run_debug, 0,
#define IEEE80211_HAS_ADDR4(wh) \
(((wh)-i_fc[1] IEEE80211_FC1_DIR_MASK) == IEEE80211_FC1_DIR_DSTODS)
-/*
- * Because of LOR in run_key_delete(), use atomic instead.
- * ' RUN_CMDQ_MASQ' is to loop cmdq[].
- */
-#define RUN_CMDQ_GET(c)(atomic_fetchadd_32((c), 1) RUN_CMDQ_MASQ)
-
static const struct usb_device_id run_devs[] = {
{ USB_VP(USB_VENDOR_ABOCOM,USB_PRODUCT_ABOCOM_RT2770) },
{ USB_VP(USB_VENDOR_ABOCOM,USB_PRODUCT_ABOCOM_RT2870) },
@@ -554,6 +548,8 @@ run_attach(device_t self)
mtx_init(sc-sc_mtx, device_get_nameunit(sc-sc_dev),
MTX_NETWORK_LOCK, MTX_DEF);
+mtx_init(sc-sc_cmdq_mtx, device_get_nameunit(sc-sc_dev),
+MTX_NETWORK_LOCK, MTX_DEF);
iface_index = RT2860_IFACE_INDEX;
@@ -737,6 +733,7 @@ run_detach(device_t self)
}
mtx_destroy(sc-sc_mtx);
+mtx_destroy(sc-sc_cmdq_mtx);
return (0);
}
@@ -830,9 +827,6 @@ run_vap_create(struct ieee80211com *ic,
if(sc-rvp_cnt++ == 0)
ic-ic_opmode = opmode;
-if(opmode == IEEE80211_M_HOSTAP)
-sc-cmdq_run = RUN_CMDQ_GO;
-
DPRINTF(rvp_id=%d bmap=%x rvp_cnt=%d\n,
rvp-rvp_id, sc-rvp_bmap, sc-rvp_cnt);
@@ -889,27 +883,31 @@ run_cmdq_cb(void *arg, int pending)
struct run_softc *sc = arg;
uint8_t i;
-/* call cmdq[].func locked */
-RUN_LOCK(sc);
-for(i = sc-cmdq_exec; sc-cmdq[i].func pending;
-i = sc-cmdq_exec, pending--){
+RUN_CMDQ_LOCK(sc);
+for (i = sc-cmdq_exec; sc-cmdq[i].func; i = sc-cmdq_exec) {
DPRINTFN(6, cmdq_exec=%d pending=%d\n, i, pending);
-if(sc-cmdq_run == RUN_CMDQ_GO){
+if (sc-cmdq_run == RUN_CMDQ_GO ||
+(sc-cmdq_key_set == RUN_CMDQ_GO
+sc-cmdq[i].func == run_key_set_cb)) {
+RUN_CMDQ_UNLOCK(sc);
+RUN_LOCK(sc);
/*
* If arg0 is NULL, callback func needs more
* than one arg. So, pass ptr to cmdq struct.
*/
-if(sc-cmdq[i].arg0)
+if (sc-cmdq[i].arg0)
sc-cmdq[i].func(sc-cmdq[i].arg0);
else
sc-cmdq[i].func(sc-cmdq[i]);
+RUN_UNLOCK(sc);
+RUN_CMDQ_LOCK(sc);
}
sc-cmdq[i].arg0 = NULL;
sc-cmdq[i].func = NULL;
sc-cmdq_exec++;
sc-cmdq_exec = RUN_CMDQ_MASQ;
}
-RUN_UNLOCK(sc);
+RUN_CMDQ_UNLOCK(sc);
}
static void
@@ -1771,6 +1769,19 @@ run_newstate(struct ieee80211vap *vap, enum
ieee80211_state nstate, int arg)
case IEEE80211_S_INIT:
restart_ratectl = 1;
+/*
+ * When hostapd has set a key, don't clear it.
+ * But, when the device is being brought down, clear it.
+ */
+if (sc-cmdq_key_set != RUN_CMDQ_GO ||
+ostate == IEEE80211_S_RUN) {
+/* clear shared key table */
+run_set_region_4(sc,
+RT2860_SKEY(rvp-rvp_id,
Re: Can't make distribution TARGET_ARCH=... after r209510
In message: 20100718.171610.338707487962422543@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : In message: 20100718210154.ga94...@laptop.levsha.me : Mykola Dzham i...@levsha.me writes: : : Hi! : : Attemt to make jail with different target arch on tinderbox (i386 jail : : on amd64 host) exits with error: : : : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : : : Last lines from log: : : : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : : install: freebsd.cf: No such file or directory : : *** Error code 71 : : : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : : *** Error code 1 : : : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : : : Full build and distribution logs avaliable on : : http://levsha.me/tmp/20100718/world.txt (20M) : : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : : : Reverting r209510 fixes this problem : : It works for me. : : on an amd64 box: : setenv TARGET=i386 : make buildworld : make installworld DESTDIR=/tmp/mumble : make distribution DESTDIR=/tmp/mumble To which I forgot to add: Please send me the exact sequence of commands that fails, as well as the uname of the host. I'd like to try to track this down... Warner ___ 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 07/18/10 12:41, Kostik Belousov wrote:
On Sun, Jul 18, 2010 at 12:21:00PM -0700, Doug Barton wrote:
On 07/18/10 03:30, Kostik Belousov wrote:
On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote:
On Sat, 17 Jul 2010, Kostik Belousov wrote:
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.
And the winner is!
11 root -32- 0K 168K WAIT0 0:28 18.02% {swi4:
clock}
11 root21 -64- 0K 168K WAIT0 1:17 18.90% intr
The first is with -H, the second without.
Most likely it is some callout handling. Just in case, do you have
console screensaver active ?
I assume you mean saver=yes in rc.conf, and the answer is no, I am not
using that. Usually I run xscreensaver, but at the time this happened I
was not. I do have DPMS enabled in my X config though.
Any suggestions on how to dig deeper on this? Are there any settings I
can twiddle to try and mitigate it?
When intr time starts accumulating again, try to do
procstat -kk intr process pid and correlate the clock thread tid
with the backtrace. Might be, it helps to guess what callouts are eating
the CPU.
Ok, file attached.
--
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
PIDTID COMM TDNAME KSTACK
11 14 intr swi1: netisr 0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 15 intr swi4: clock mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 16 intr swi4: clock mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 17 intr swi3: vm
11 100014 intr swi6: Giant task mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100015 intr swi6: task queue mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100020 intr swi2: cambio mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100021 intr swi5: +
11 100022 intr irq9: acpi0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100023 intr irq16:
11 100024 intr irq256: hdac0mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100026 intr irq17: wpi0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100027 intr irq20: hpet0 uhc mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100032 intr irq21: uhci1
11 100037 intr irq22: uhci2 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100042 intr irq23: uhci3
11 100052 intr irq14: ata0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100053 intr irq15: ata1 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100055 intr irq1: atkbd0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100056 intr irq12: psm0
11 100057 intr swi0: uart
___
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
