From rea-fbsd at codelabs.ru Mon Dec 1 00:12:58 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon Dec 1 00:13:06 2008 Subject: Collecting hardware compatibility, Was: i give up In-Reply-To: <3cb459ed0811302342o62e38009h3b853ae325c8e330@mail.gmail.com> References: <20081128234155.0221e263@serene.no-ip.org> <3cb459ed0811291342i524eaab3g1acadcd9cbdb638b@mail.gmail.com> <7d6fde3d0811291556g3f08a814td68466ad02dee4fc@mail.gmail.com> <200811291515.01962.beech@freebsd.org> <4932DD73.9000109@freebsd.org> <20081130235621.GA51043@duncan.reilly.home> <49338183.3040500@freebsd.org> <49338F56.9050101@freebsd.org> <3cb459ed0811302342o62e38009h3b853ae325c8e330@mail.gmail.com> Message-ID: Alexander, good day. Mon, Dec 01, 2008 at 10:42:50AM +0300, Alexander Churanov wrote: > Probably it is useful to gather information after a month since the system > was installed and user obtained some information about what does work an > what does not. If any, please make it optional and off by-default: some people (at least me myself) don't want to be bothered by this and aren't going to disclose any details about their systems. And, yes, I am a paranoidal person ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081201/1f33626a/attachment.pgp From lars.engels at 0x20.net Mon Dec 1 01:07:49 2008 From: lars.engels at 0x20.net (Lars Engels) Date: Mon Dec 1 01:07:56 2008 Subject: i give up In-Reply-To: <4932DD73.9000109@freebsd.org> References: <20081128234155.0221e263@serene.no-ip.org> <3cb459ed0811291342i524eaab3g1acadcd9cbdb638b@mail.gmail.com> <7d6fde3d0811291556g3f08a814td68466ad02dee4fc@mail.gmail.com> <200811291515.01962.beech@freebsd.org> <4932DD73.9000109@freebsd.org> Message-ID: <20081201100747.jivl1alh6owok4s4@0x20.net> Quoting Tim Kientzle : >>>> I have some ideas on that. The problem is it's sometimes hard to check >>>> that given hardware is supported by FreeBSD, even in case you know and >>>> want to do it. The list of supported hardware is often written in terms >>>> of chipsets and manufacturers often produce cards using supported chips, >>>> but named after their own trademark. > > I wonder if there's some way to partially automate > collecting some of this information. > > Something like a "register" program people can > use to register their FreeBSD installation that > would optionally include hardware information. > (Get a list of hardware IDs and running drivers > from the kernel, then prompt the user to enter > the actual hardware manufacturer/brand name for > each one.) > > Then the process of registering the OS installation > would also collect a lot of information about > "known good" hardware. > > Bonus points, of course, if the register program > first queries the web site to collect lists of > hardware names that other people have already > entered so that most of the time people can simply > click and say "I'm using that one" and only > occasionally have to type in a new brand name. > > The cross-reference information of vendor, hardware > ID, driver, and OS version would be very valuable > for people setting up new systems. Of course, > you'd want to keep careful counts of how often each > piece of hardware was registered and provide an easy > way for human editors to be able to clean up data > afterwards, since there will be a certain amount > of mispellings and simple nonsense. OpenSolaris has a decent tool which collects your harware configuration and automatically adds it to a hardware database and also shows if your HW is suitable for Opensolaris: http://www.sun.com/bigadmin/hcl/hcts/device_detect.jsp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Digitale PGP-Unterschrift Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081201/6ed913e1/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Mon Dec 1 01:45:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Dec 1 01:45:27 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD Message-ID: <20081201085229.D80401@maildrop.int.zabbadoz.net> Hi, as you may have already noticed multi-IPv4/v6/no-IP jails have hit HEAD. See commit message attached. The bad news first: expect an update on the rc script to make the more obscure rc features like configuring IPs on interfaces when starting jails and giving a possible netmask work with multiple IPs and IPv6. The good news: In case you do not use those features or still only use one IP per jail everything should just work fine and there are no changes needed. More news: In case you want to use multiple IPs or a mix of v4 and v6 addresses you just give them as a comma separated list on both the command line or in rc.conf like: jail / example 192.0.2.250,2001:db8::75,2001:db8::99,2001:db8::55,2001:db8::14,192.0.2.254 /bin/sh or: jail_example_ip="192.0.2.2,2001:db8::2,2001:db8::1,2001:db8::4,2001:db8::13,192.0.2.3" In case you do want to start a jail without any IP, give an empty argument on command line: jail / noip.example.net "" /bin/sh Additionally you can give a jail a name now using the -n option: jail -n "bz's private noip jail" / noip.example.net "" /bin/sh You may not want to use special characters or whitespace but it is just a string, so you can. There are no restrictions and even 10 jails could have the same name. The jail (inside) cannot change the name. It's set upon jail creation and unchangeable from then on. What else is new: the -h option to jail makes it resolve the hostname to IP addresses and will merge those to the jail IPs. Note: that this can give you unexpected results on the primary jail IP. See jail(8) for more information. jls tries to be as backward compatible as possible. That means it will only show one IPv4 if called as `jls`; obviously this won't work well for no-IP or IPv6-only jails. This was done to try to not confuse scripts people have in their classic setups. jls -v will give you the full information, including: - state: usually ACTIVE. - in case you also give '-a' you will also see jails in other states, for example jails hanging around waiting for a socket to timeout but with no processes left after it was stopped; it will say DYING. - Every jail gets its own cpuset inherited from the process that started the jail. You can list, etc the mask by jail id: cpuset -g -j 8 or by set id: cpuset -g -s 5 Or even change it if you want. Threads within jails should be able to further restrict themselves even within the jail but nothing outside their scope. See the cpuset manpages for further information. The IPs will be listed in the following order: the primary IP per AF which is the first IP of that AF given to the jail command and then they should be sorted in ascending order. jexec now takes the optional jail name to attach to a jail but will refuse to do anything if the jail cannot be uniquely identifed. In case you use the jail name you have to give an empty argument for the jail id like: jexec -n "bz's private noip jail" "" /bin/sh You can also give both jail name and jail ID and both will have to match, else it will complain. Obviously only giving the jail id still works. The -h hostname option is gone again. You should use the jail name for management purposes now. A sample full jls output (admittedly a bit ugly this way): sun$ jls -av JID Hostname Path Name State CPUSetID IP Address(es) 21 sun / hangtest DYING 6 192.0.2.99 8 noip.example.net / bz's private noip jail ALIVE 5 3 j3.sunny.example.net /local/jails/j1 ALIVE 4 2001:db8::5 2 j2.sunny.example.net /local/jails/j1 ALIVE 3 192.0.2.1 1 j1.sunny.example.net /local/jails/j1 ALIVE 2 192.0.2.2 192.0.2.3 2001:db8::2 2001:db8::1 2001:db8::4 2001:db8::13 In case you have more questions the man pages do not address, or problem, etc. please follow-up to freebsd-jail@ . Regards, Bjoern PS: the MFC question was answered in the commit message so do not ask. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ---------- Forwarded message ---------- Date: Sat, 29 Nov 2008 14:32:14 +0000 (UTC) Subject: svn commit: r185435 - in head: lib/libc/sys lib/libkvm share/man/man4 sys/compat/freebsd32 sys/kern sys/net sys/netinet sys/netinet6 sys/security/mac_bsdextended sys/sys usr.bin/cpuset usr.sbin/jai... Author: bz Date: Sat Nov 29 14:32:14 2008 New Revision: 185435 URL: http://svn.freebsd.org/changeset/base/185435 Log: MFp4: Bring in updated jail support from bz_jail branch. This enhances the current jail implementation to permit multiple addresses per jail. In addtion to IPv4, IPv6 is supported as well. Due to updated checks it is even possible to have jails without an IP address at all, which basically gives one a chroot with restricted process view, no networking,.. SCTP support was updated and supports IPv6 in jails as well. Cpuset support permits jails to be bound to specific processor sets after creation. Jails can have an unrestricted (no duplicate protection, etc.) name in addition to the hostname. The jail name cannot be changed from within a jail and is considered to be used for management purposes or as audit-token in the future. DDB 'show jails' command was added to aid debugging. Proper compat support permits 32bit jail binaries to be used on 64bit systems to manage jails. Also backward compatibility was preserved where possible: for jail v1 syscalls, as well as with user space management utilities. Both jail as well as prison version were updated for the new features. A gap was intentionally left as the intermediate versions had been used by various patches floating around the last years. Bump __FreeBSD_version for the afore mentioned and in kernel changes. Special thanks to: - Pawel Jakub Dawidek (pjd) for his multi-IPv4 patches and Olivier Houchard (cognet) for initial single-IPv6 patches. - Jeff Roberson (jeff) and Randall Stewart (rrs) for their help, ideas and review on cpuset and SCTP support. - Robert Watson (rwatson) for lots and lots of help, discussions, suggestions and review of most of the patch at various stages. - John Baldwin (jhb) for his help. - Simon L. Nielsen (simon) as early adopter testing changes on cluster machines as well as all the testers and people who provided feedback the last months on freebsd-jail and other channels. - My employer, CK Software GmbH, for the support so I could work on this. Reviewed by: (see above) MFC after: 3 months (this is just so that I get the mail) X-MFC Before: 7.2-RELEASE if possible From lulf at freebsd.org Mon Dec 1 02:29:02 2008 From: lulf at freebsd.org (Ulf Lilleengen) Date: Mon Dec 1 02:29:09 2008 Subject: HEADSUP: CVS/Mirror mode for csup to be merged soon In-Reply-To: <20081125154040.GA12632@nobby.lan> References: <20081125154040.GA12632@nobby.lan> Message-ID: <20081201092900.GB1397@nobby.lan> On Tue, Nov 25, 2008 at 04:40:40PM +0100, Ulf Lilleengen wrote: > Hello, > > After some feedback on previous patches and some adjustments, I think the > CVSMode for csup project have come to a place where a wider testing audience > is needed, and I would like to make this a call for review and a HEADSUP to > allow willing reviewers and eventual protesters to give their opinion before > merging this to HEAD. A few things about the current state of CVSMode: > > - Complete CVS mode (mirror mode) is supported, allowing the whole CVS > repository to be fetched by csup. > - rsync fetch supported if not explicitly not wanted by user or not supported > by server. > - Support using the status file to speed up detailing of files. This means no > bigger inpact on files that are up to date. > > For the state of the code itself, I have went over it a couple of times the > last couple of days, fixing style issues and a few differences between cvsup > and csup. One important thing to note is that the impact on the existing csup > operation is _minimal_, so that the risk of introducing bugs to the normal > csup operation is very small, and because of this I see no problems with > committing the current version. If you find any issues, please e-mail me, and > I will look at it. > > So, for those of you wanting to test, please do so now. If people are okay > with this, I would like to merge it by the end of the week/early next week. > > A patch can be found here: http://people.freebsd.org/~lulf/csup_cvsmode.diff > or you can just do a checkout of projects/csup_cvsmode > Small update, I have gotten some positive reports, thanks for testing! So far, a bug involving SKIP directory handling have been fixed. I still have one report which I'd like to investigate more before getting anything in. In addition, there seems to be performance problems on some files (with many deltas, such as CVSROOT-*/modules,v etc.) due to some slow algorithms used in the RCS handling. I'll try to speed it up a bit when it seems to work ok. -- Ulf Lilleengen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081201/ffaa7e46/attachment.pgp From Alexander at Leidinger.net Mon Dec 1 03:29:47 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Dec 1 03:29:55 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <20081201085229.D80401@maildrop.int.zabbadoz.net> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> Message-ID: <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> Quoting "Bjoern A. Zeeb" (from Mon, 1 Dec 2008 09:41:46 +0000 (UTC)): > Hi, > > as you may have already noticed multi-IPv4/v6/no-IP jails have hit > HEAD. See commit message attached. Will this introduce changes how multicast is handled in jails, or is it the same behavior as before (whatever the previous behavior was). > Additionally you can give a jail a name now using the -n option: > jail -n "bz's private noip jail" / noip.example.net "" /bin/sh > You may not want to use special characters or whitespace but it is > just a string, so you can. There are no restrictions and even 10 jails > could have the same name. The jail (inside) cannot change the name. > It's set upon jail creation and unchangeable from then on. Is this private name visible inside the jail (I don't need this feature, so I don't care, but people should know so that they don't put offensive stuff there in case it is visible inside)? Bye, Alexander. -- Since we cannot hope for order, let us withdraw with style from the chaos. -- Tom Stoppard http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From beech at freebsd.org Mon Dec 1 03:42:34 2008 From: beech at freebsd.org (Beech Rintoul) Date: Mon Dec 1 03:42:41 2008 Subject: Regression in -CURRENT Message-ID: <200812010242.33125.beech@freebsd.org> Something committed last week is hosing php apps. I updated to today's - CURRENT and started getting two errors. 1: grep unable to write broken pipe before each port configure with portupgrade and 2: Fatal error: Call to undefined function preg_match() in /usr/local/share/pear/DB.php on line 766 when I tried to open the webui on my tinderbox. Reverting back to a week ago sunday fixed both problems. Beech -- --------------------------------------------------------------------------------------- Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/7.0R/announce.html --------------------------------------------------------------------------------------- From kallender at completecomputing.com Mon Dec 1 05:16:57 2008 From: kallender at completecomputing.com (Kyle Allender) Date: Mon Dec 1 05:17:06 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 Message-ID: <4933E158.5030407@completecomputing.com> Hello. I ran into an error while attempting to build kde4 from source in FreeBSD 8.0-CURRENT: FreeBSD sia.prismequine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Sun Nov 30 13:49:59 CST 2008 root@sia.prismequine.com:/usr/obj/usr/src/sys/GENERIC i386 where phonon-4.2.0 failed due to what appears to be an issue with the # of processors (1) and waiting for a lock? The relevant portions of the build messages are below. I should note that I updated my source yesterday around 4PM CST, ran into the build problem overnight (I kicked off an install and then went to bed). I noted the error, checked cvs and noted that a newer version of malloc.c had been committed. At that point, I resynced my source and re-started the build. However, the error remains the same. I'm running on a P4, 2.40Ghz system if that helps. Build error: Linking CXX executable backendtester cd /usr/ports/multimedia/phonon/work/phonon-4.2.0/build/phonon/tests && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/backendtester.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -fno-strict-aliasing -pipe -Woverloaded-virtual -fvisibility=hidden -fvisibility-inlines-hidden -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-check-new -fno-common -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline -fPIC CMakeFiles/backendtester.dir/backendtester_automoc.o CMakeFiles/backendtester.dir/backendtester.o -o backendtester -L/usr/local/lib/qt4 /usr/local/lib/qt4/libQtCore.so -lpthread /usr/local/lib/qt4/libQtGui.so -Wl,-rpath,/usr/local/lib/qt4 /usr/local/bin/cmake -E cmake_progress_report /usr/ports/multimedia/phonon/work/phonon-4.2.0/build/CMakeFiles 33 34 35 [ 39%] Built target backendtester make -f phonon/tests/CMakeFiles/mediaobjecttest.dir/build.make phonon/tests/CMakeFiles/mediaobjecttest.dir/depend cd /usr/ports/multimedia/phonon/work/phonon-4.2.0/build/phonon/tests && /usr/local/kde4/bin/automoc4 /usr/ports/multimedia/phonon/work/phonon-4.2.0/build/phonon/tests/mediaobjecttest_automoc.cpp /usr/ports/multimedia/phonon/work/phonon-4.2.0/phonon/tests /usr/ports/multimedia/phonon/work/phonon-4.2.0/build/phonon/tests /usr/local/bin/moc-qt4 /usr/local/bin/cmake --touch Generating mediaobjecttest.moc Assertion failed: ((ret << BLOCK_COST_2POW) != 0), function malloc_spin_lock, file /usr/src/lib/libc/stdlib/malloc.c, line 1287. Abort trap (core dumped) *** Error code 134 Stop in /usr/ports/multimedia/phonon/work/phonon-4.2.0/build. *** Error code 1 Stop in /usr/ports/multimedia/phonon/work/phonon-4.2.0/build. *** Error code 1 Stop in /usr/ports/multimedia/phonon/work/phonon-4.2.0/build. *** Error code 1 Stop in /usr/ports/multimedia/phonon. *** Error code 1 Stop in /usr/ports/x11/kdelibs4. *** Error code 1 Stop in /usr/ports/accessibility/kdeaccessibility4. *** Error code 1 Stop in /usr/ports/x11/kde4. *** Error code 1 Stop in /usr/ports/x11/kde4. Thanks. From kallender at completecomputing.com Mon Dec 1 05:34:45 2008 From: kallender at completecomputing.com (Kyle Allender) Date: Mon Dec 1 05:34:53 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <20081201132656.GB1397@lizard.fafoe.narf.at> References: <4933E158.5030407@completecomputing.com> <20081201132656.GB1397@lizard.fafoe.narf.at> Message-ID: <4933E7D9.7030707@completecomputing.com> Stefan Farfeleder wrote: > On Mon, Dec 01, 2008 at 07:06:32AM -0600, Kyle Allender wrote: >> Hello. > >> Generating mediaobjecttest.moc >> Assertion failed: ((ret << BLOCK_COST_2POW) != 0), function >> malloc_spin_lock, file /usr/src/lib/libc/stdlib/malloc.c, line 1287. >> Abort trap (core dumped) > > Hi, > > this assertion has been fixed yesterday (svn r185483). Should I rerun build/installworld before re-attempting the kde build or just run make clean in the phonon directory? K > > Stefan > From stefan at fafoe.narf.at Mon Dec 1 05:44:15 2008 From: stefan at fafoe.narf.at (Stefan Farfeleder) Date: Mon Dec 1 05:44:21 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <4933E158.5030407@completecomputing.com> References: <4933E158.5030407@completecomputing.com> Message-ID: <20081201132656.GB1397@lizard.fafoe.narf.at> On Mon, Dec 01, 2008 at 07:06:32AM -0600, Kyle Allender wrote: > Hello. > Generating mediaobjecttest.moc > Assertion failed: ((ret << BLOCK_COST_2POW) != 0), function > malloc_spin_lock, file /usr/src/lib/libc/stdlib/malloc.c, line 1287. > Abort trap (core dumped) Hi, this assertion has been fixed yesterday (svn r185483). Stefan From stefan at fafoe.narf.at Mon Dec 1 05:49:47 2008 From: stefan at fafoe.narf.at (Stefan Farfeleder) Date: Mon Dec 1 05:49:55 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <4933E7D9.7030707@completecomputing.com> References: <4933E158.5030407@completecomputing.com> <20081201132656.GB1397@lizard.fafoe.narf.at> <4933E7D9.7030707@completecomputing.com> Message-ID: <20081201134942.GC1397@lizard.fafoe.narf.at> On Mon, Dec 01, 2008 at 07:34:17AM -0600, Kyle Allender wrote: > Stefan Farfeleder wrote: >> On Mon, Dec 01, 2008 at 07:06:32AM -0600, Kyle Allender wrote: >>> Hello. >> >>> Generating mediaobjecttest.moc >>> Assertion failed: ((ret << BLOCK_COST_2POW) != 0), function >>> malloc_spin_lock, file /usr/src/lib/libc/stdlib/malloc.c, line 1287. >>> Abort trap (core dumped) >> >> Hi, >> >> this assertion has been fixed yesterday (svn r185483). > > Should I rerun build/installworld before re-attempting the kde build or > just run make clean in the phonon directory? You need at least an updated libc. build/installworld will do that but there are faster ways for this small update. After that you can continue building kde. From kallender at completecomputing.com Mon Dec 1 05:57:45 2008 From: kallender at completecomputing.com (Kyle Allender) Date: Mon Dec 1 05:58:12 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <20081201134942.GC1397@lizard.fafoe.narf.at> References: <4933E158.5030407@completecomputing.com> <20081201132656.GB1397@lizard.fafoe.narf.at> <4933E7D9.7030707@completecomputing.com> <20081201134942.GC1397@lizard.fafoe.narf.at> Message-ID: <4933ED44.7010205@completecomputing.com> Stefan Farfeleder wrote: > On Mon, Dec 01, 2008 at 07:34:17AM -0600, Kyle Allender wrote: >> Stefan Farfeleder wrote: >>> On Mon, Dec 01, 2008 at 07:06:32AM -0600, Kyle Allender wrote: >>>> Hello. >>>> Generating mediaobjecttest.moc >>>> Assertion failed: ((ret << BLOCK_COST_2POW) != 0), function >>>> malloc_spin_lock, file /usr/src/lib/libc/stdlib/malloc.c, line 1287. >>>> Abort trap (core dumped) >>> Hi, >>> >>> this assertion has been fixed yesterday (svn r185483). >> Should I rerun build/installworld before re-attempting the kde build or >> just run make clean in the phonon directory? > > You need at least an updated libc. build/installworld will do that but > there are faster ways for this small update. After that you can > continue building kde. > OK. I've kicked off a buildworld as that's about the only method I know that will resolve this issue. The "faster ways" I'm unaware of - if someone could enlighten me, that'd be great. Buildworld will work in the meantime, though. Thanks for the help. K From des at des.no Mon Dec 1 06:41:12 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Dec 1 06:42:09 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <4933ED44.7010205@completecomputing.com> (Kyle Allender's message of "Mon, 01 Dec 2008 07:57:24 -0600") References: <4933E158.5030407@completecomputing.com> <20081201132656.GB1397@lizard.fafoe.narf.at> <4933E7D9.7030707@completecomputing.com> <20081201134942.GC1397@lizard.fafoe.narf.at> <4933ED44.7010205@completecomputing.com> Message-ID: <86vdu4ot4p.fsf@ds4.des.no> Kyle Allender writes: > Stefan Farfeleder writes: > > You need at least an updated libc. build/installworld will do that > > but there are faster ways for this small update. After that you can > > continue building kde. > OK. I've kicked off a buildworld as that's about the only method I > know that will resolve this issue. The "faster ways" I'm unaware of - > if someone could enlighten me, that'd be great. Buildworld will work > in the meantime, though. # cd /usr/src/lib/libc # make && make install DES -- Dag-Erling Sm?rgrav - des@des.no From rink at FreeBSD.org Mon Dec 1 06:58:11 2008 From: rink at FreeBSD.org (Rink Springer) Date: Mon Dec 1 06:59:22 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <86vdu4ot4p.fsf@ds4.des.no> References: <4933E158.5030407@completecomputing.com> <20081201132656.GB1397@lizard.fafoe.narf.at> <4933E7D9.7030707@completecomputing.com> <20081201134942.GC1397@lizard.fafoe.narf.at> <4933ED44.7010205@completecomputing.com> <86vdu4ot4p.fsf@ds4.des.no> Message-ID: <20081201145845.GA16431@rink.nu> On Mon, Dec 01, 2008 at 03:41:10PM +0100, Dag-Erling Sm??rgrav wrote: > Kyle Allender writes: > > Stefan Farfeleder writes: > > > You need at least an updated libc. build/installworld will do that > > > but there are faster ways for this small update. After that you can > > > continue building kde. > > OK. I've kicked off a buildworld as that's about the only method I > > know that will resolve this issue. The "faster ways" I'm unaware of - > > if someone could enlighten me, that'd be great. Buildworld will work > > in the meantime, though. > > # cd /usr/src/lib/libc > # make && make install The following works too: # cd /usr/src/lib/libc # make all install :-) -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From des at des.no Mon Dec 1 07:02:11 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Dec 1 07:02:24 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <20081201145845.GA16431@rink.nu> (Rink Springer's message of "Mon, 1 Dec 2008 15:58:45 +0100") References: <4933E158.5030407@completecomputing.com> <20081201132656.GB1397@lizard.fafoe.narf.at> <4933E7D9.7030707@completecomputing.com> <20081201134942.GC1397@lizard.fafoe.narf.at> <4933ED44.7010205@completecomputing.com> <86vdu4ot4p.fsf@ds4.des.no> <20081201145845.GA16431@rink.nu> Message-ID: <86r64sos5q.fsf@ds4.des.no> Rink Springer writes: > "Dag-Erling Sm?rgrav" writes: > > # cd /usr/src/lib/libc > > # make && make install > > The following works too: > > # cd /usr/src/lib/libc > # make all install It is not always safe to run multiple targets in one invocation (though in this case, it shouldn't matter). The classic example is 'make depend all'. DES -- Dag-Erling Sm?rgrav - des@des.no From hselasky at c2i.net Mon Dec 1 07:10:03 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Dec 1 07:10:10 2008 Subject: usb2: no sound with M-Audio Transit (problem solved) In-Reply-To: <200811161131.39014.hselasky@c2i.net> References: <200811141541.49595.shoesoft@gmx.net> <200811151022.56606.hselasky@c2i.net> <200811161131.39014.hselasky@c2i.net> Message-ID: <200812011612.15528.hselasky@c2i.net> Hi, Patches for the problems reported by Stefan are on its way to -current. --HPS From rizzo at iet.unipi.it Mon Dec 1 07:19:23 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Dec 1 07:19:31 2008 Subject: upcoming change to boot0.S (mostly documentation) In-Reply-To: <20081126192237.GB91382@onelab2.iet.unipi.it> References: <20081126192237.GB91382@onelab2.iet.unipi.it> Message-ID: <20081201152410.GA8048@onelab2.iet.unipi.it> Hi, in the past few days I have been looking at the boot0.S code (the 512 byte version, i386) and found at least a couple of bugs or "features" worth fixing: one of them is the bogus %si value passed to the next stage loader, already fixed in head and RELENG_7. Another bug, already mentioned on the -developers list a few days ago, is related to the fact that the code might write back the boot sector on a different disk than the one it was loaded from, thus trashing the master boot record. A fix for this is upcoming, and among other things it involves changing the default mode from 'update' to 'noupdate'. Part of the problem with these bugs was/is that the existing boot0.S code is extremely difficult to follow, because it employs all sort of clever tricks to save memory. So, I have tried to annotate it as much as possible to make it easier to change or reconfigure it in the future, and reduce the risk of introducing bugs because of side effects of the changes. A preview of what will be committed is at http://info.iet.unipi.it/~luigi/FreeBSD/20081201-boot0.S While the diff is very large, it is 95% comments. The functional changes are extremely limited, as follows (all can be easily reverted if there is demand): + make 'noupdate' the default mode of operation (this is forced in the Makefile). It can be reverted back to 'update' using boot0cfg. + never overwrite the boot sector if the BIOS-supplied drive number is overridden by the 'setdrv' option. This was a potential source of trouble because we might write (and trash the MBR) on a different driver. + do not check for a valid drive number, allowing boot0 to be used even when the BIOS does 'floppy emulation' on a flash drive. Adding the check back requires 4 bytes. + force CHS mode ('nopacket') when loaded from a floppy unit. Removing the change saves 4 bytes. Because of some minor code rearrangements, I also managed to make room for a 'WIN' string (3 extra bytes) to be printed for certain FAT32 partitions, and for recognising an additional FAT16 partition as DOS (2 extra bytes). Right now the code uses the full 512 bytes (the SIO version is slightly shorter) so the changes need to fit in the memory budget -- this is why i mention the cost of each of the options above. cheers luigi From glz at hidden-powers.com Mon Dec 1 08:10:27 2008 From: glz at hidden-powers.com (Goran Lowkrantz) Date: Mon Dec 1 08:10:35 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> Message-ID: <85C044B15658D05E484832BA@syn> --On November 17, 2008 21:55:26 +0100 Pawel Jakub Dawidek wrote: > Hi. > > So ZFS was updated from version 6 to 13. Be very careful when updating > your system if you use ZFS. The number of changes is huge and my > regression tests and manual tests I did only cover part of the entire > functionality. > > More info here: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 > > Enjoy. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! OK, I have been playing around with this for a while now and it seems to work well with the workload I have tested with, mostly external file access via samba and nfs plus some PostgreSQL databases. The only feature I have missed is a deferred modify when a change by zpool or zfs commands requires re-mounting, then just writing it and have it take on the next mount would save a trip to single-user. Thanks for all the good stuff! /glz From phk at phk.freebsd.dk Mon Dec 1 08:36:29 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon Dec 1 08:36:37 2008 Subject: upcoming change to boot0.S (mostly documentation) In-Reply-To: Your message of "Mon, 01 Dec 2008 16:24:10 +0100." <20081201152410.GA8048@onelab2.iet.unipi.it> Message-ID: <12387.1228149386@critter.freebsd.dk> In message <20081201152410.GA8048@onelab2.iet.unipi.it>, Luigi Rizzo writes: >in the past few days I have been looking at the boot0.S code (the >512 byte version, i386) [...] Ahh too bad, it would have been much more productive to work on the 1024 byte version instead... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From sam at freebsd.org Mon Dec 1 09:03:40 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Dec 1 09:03:52 2008 Subject: HEADS UP: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... Message-ID: <493418EA.7020602@freebsd.org> Things to note: This also represents an upgrade of the hal code over what was in the tree. There are many bug fixes in this code, especially for AR5416 parts. I have no idea when this will be MFC'd. Because of the directory change from contrib/dev/ath to dev/ath/ath_hal backporting by hand may be painful. Definitely not before 7.1 goes out. I no longer be have access to internal Atheros' information (e.g. their hal code). In particular this means support for new parts will have to come by scraping code from the ath9k linux driver. I expect other people to pitch in to do that. I will be happy to assist. Sam -------------- next part -------------- An embedded message was scrubbed... From: Sam Leffler Subject: svn commit: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... Date: Mon, 1 Dec 2008 16:53:02 +0000 (UTC) Size: 47969 Url: http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081201/a816051a/sample....eml From rizzo at iet.unipi.it Mon Dec 1 09:14:14 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Dec 1 09:14:22 2008 Subject: upcoming change to boot0.S (mostly documentation) In-Reply-To: <12387.1228149386@critter.freebsd.dk> References: <20081201152410.GA8048@onelab2.iet.unipi.it> <12387.1228149386@critter.freebsd.dk> Message-ID: <20081201171901.GA13277@onelab2.iet.unipi.it> On Mon, Dec 01, 2008 at 04:36:26PM +0000, Poul-Henning Kamp wrote: > In message <20081201152410.GA8048@onelab2.iet.unipi.it>, Luigi Rizzo writes: > > > >in the past few days I have been looking at the boot0.S code (the > >512 byte version, i386) [...] > > Ahh too bad, it would have been much more productive to work on the > 1024 byte version instead... there's indeed a lot in common among the two (as a matter of fact, now i notice that some the 1024 byte version has some more comments in it that also explain what goes on in the 512 byte version...) From phk at phk.freebsd.dk Mon Dec 1 09:17:34 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon Dec 1 09:17:42 2008 Subject: HEADS UP: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... In-Reply-To: Your message of "Mon, 01 Dec 2008 09:03:38 PST." <493418EA.7020602@freebsd.org> Message-ID: <12565.1228151852@critter.freebsd.dk> In message <493418EA.7020602@freebsd.org>, Sam Leffler writes: >I no longer be have access to internal Atheros' information (e.g. their >hal code). In particular this means support for new parts will have to >come by scraping code from the ath9k linux driver. I expect other >people to pitch in to do that. I will be happy to assist. Sam, Thanks a lot for all this work, it is much appreciated. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From marius at nuenneri.ch Mon Dec 1 09:34:51 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Mon Dec 1 09:34:58 2008 Subject: HOWTO in wiki: adding custom dtrace probes in the kernel In-Reply-To: <49304D0E.3030201@freebsd.org> References: <20081128154514.82247fe47bn83lkw@webmail.leidinger.net> <20081128171243.18141hd28pf4ve00@webmail.leidinger.net> <49304D0E.3030201@freebsd.org> Message-ID: On Fri, Nov 28, 2008 at 8:57 PM, Tim Kientzle wrote: >>> SDT_PROBE(foobar, source_file1, foo, entry, a, b, 0, 0, 0); >>> >>> Here: why are the last three arguments zeroes? >> >> SDT_PROBE() is a macro with a fixed number of macros, so we have to fill >> with 0 in case we don't want to provide some data. Maybe there's a way to >> provide more arguments if you do it by hand instead of using the >> SDT_PROBE() macro (TODO item added in the wiki to have a look at this, feel >> free to improve the wiki page). > > Seems that SDT_PROBE() should be using C99s "variadic macro" > feature. Is the kernel compiled in C99 mode? From des at des.no Mon Dec 1 09:50:46 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Dec 1 09:50:53 2008 Subject: HOWTO in wiki: adding custom dtrace probes in the kernel In-Reply-To: ("Marius =?utf-8?Q?N=C3=BCnnerich=22's?= message of "Mon, 1 Dec 2008 18:34:49 +0100") References: <20081128154514.82247fe47bn83lkw@webmail.leidinger.net> <20081128171243.18141hd28pf4ve00@webmail.leidinger.net> <49304D0E.3030201@freebsd.org> Message-ID: <86iqq3pyx8.fsf@ds4.des.no> "Marius N?nnerich" writes: > Tim Kientzle wrote: > > Seems that SDT_PROBE() should be using C99s "variadic macro" > > feature. > Is the kernel compiled in C99 mode? No, but it is compiled using a compiler that supports variadic macros and has for many years (even before C99), and variadic macros are already used in many places, including GEOM, ZFS and WITNESS. DES -- Dag-Erling Sm?rgrav - des@des.no From andrew at atrens.ca Mon Dec 1 10:00:52 2008 From: andrew at atrens.ca (Andrew Atrens) Date: Mon Dec 1 10:00:59 2008 Subject: HEADS UP: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... In-Reply-To: <12565.1228151852@critter.freebsd.dk> References: <12565.1228151852@critter.freebsd.dk> Message-ID: <49342274.2020300@atrens.ca> In message <493418EA.7020602@freebsd.org>, Sam Leffler writes: >> I no longer be have access to internal Atheros' information (e.g. their >> hal code). In particular this means support for new parts will have to >> come by scraping code from the ath9k linux driver. I expect other >> people to pitch in to do that. I will be happy to assist. >> Thanks Sam for your incredible efforts in championing this for so long!! :o) :o) --Andrew From jasone at FreeBSD.org Mon Dec 1 11:08:45 2008 From: jasone at FreeBSD.org (Jason Evans) Date: Mon Dec 1 11:08:51 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <4933ED44.7010205@completecomputing.com> References: <4933E158.5030407@completecomputing.com> <20081201132656.GB1397@lizard.fafoe.narf.at> <4933E7D9.7030707@completecomputing.com> <20081201134942.GC1397@lizard.fafoe.narf.at> <4933ED44.7010205@completecomputing.com> Message-ID: <4934363C.9090200@FreeBSD.org> Kyle Allender wrote: > Stefan Farfeleder wrote: >> On Mon, Dec 01, 2008 at 07:34:17AM -0600, Kyle Allender wrote: >>> Stefan Farfeleder wrote: >>>> On Mon, Dec 01, 2008 at 07:06:32AM -0600, Kyle Allender wrote: >>>>> Hello. >>>>> Generating mediaobjecttest.moc >>>>> Assertion failed: ((ret << BLOCK_COST_2POW) != 0), function >>>>> malloc_spin_lock, file /usr/src/lib/libc/stdlib/malloc.c, line 1287. >>>>> Abort trap (core dumped) >>>> Hi, >>>> >>>> this assertion has been fixed yesterday (svn r185483). >>> Should I rerun build/installworld before re-attempting the kde build >>> or just run make clean in the phonon directory? >> >> You need at least an updated libc. build/installworld will do that but >> there are faster ways for this small update. After that you can >> continue building kde. >> > OK. I've kicked off a buildworld as that's about the only method I know > that will resolve this issue. The "faster ways" I'm unaware of - if > someone could enlighten me, that'd be great. Buildworld will work in > the meantime, though. In this case of libc, it's usually a good idea to do the full buildworld, since libc gets statically linked into various toolchain binaries. Fortunately, this bug in malloc only affects multi-threaded applications; otherwise you'd have an unrecoverable system (though I would have noticed that before committing). Jason From linimon at lonesome.com Mon Dec 1 12:08:15 2008 From: linimon at lonesome.com (Mark Linimon) Date: Mon Dec 1 12:32:16 2008 Subject: HEADS UP: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... In-Reply-To: <49342274.2020300@atrens.ca> References: <12565.1228151852@critter.freebsd.dk> <49342274.2020300@atrens.ca> Message-ID: <20081201195028.GA6788@soaustin.net> On Mon, Dec 01, 2008 at 12:44:20PM -0500, Andrew Atrens wrote: > Thanks Sam for your incredible efforts in championing this for so long!! +1 From beech at freebsd.org Mon Dec 1 13:44:38 2008 From: beech at freebsd.org (Beech Rintoul) Date: Mon Dec 1 13:44:45 2008 Subject: HEADS UP: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... In-Reply-To: <49342274.2020300@atrens.ca> References: <12565.1228151852@critter.freebsd.dk> <49342274.2020300@atrens.ca> Message-ID: <200812011244.37250.beech@freebsd.org> On Monday 01 December 2008 08:44:20 Andrew Atrens wrote: > In message <493418EA.7020602@freebsd.org>, Sam Leffler writes: > >> I no longer be have access to internal Atheros' information (e.g. their > >> hal code). In particular this means support for new parts will have to > >> come by scraping code from the ath9k linux driver. I expect other > >> people to pitch in to do that. I will be happy to assist. > > Thanks Sam for your incredible efforts in championing this for so long!! > > :o) :o) > > --Andrew I second that! My atheros based wifi card was my main internet access for two years and your drivers worked flawlessly. This card will also work as an AP in FreeBSD. That feature isn't available with the same card in windows, It's reserved for the more expensive model. So, thanks for all the hard work. It's definitely appreciated. Beech -- --------------------------------------------------------------------------------------- Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/7.0R/announce.html --------------------------------------------------------------------------------------- From subbsd at gmail.com Mon Dec 1 13:52:02 2008 From: subbsd at gmail.com (Ole Vole) Date: Mon Dec 1 13:52:10 2008 Subject: HEADS UP: r185522 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/contrib/dev/ath sys/dev/ath sys/dev/ath/ath_rate/amrr sys/dev/ath/ath_rate/onoe sys/dev/ath/ath_rate/sample ... In-Reply-To: <493418EA.7020602@freebsd.org> References: <493418EA.7020602@freebsd.org> Message-ID: <200812020051.56207.subbsd@gmail.com> Hello! Thanks a lot! Fix please misprint in /usr/src/UPDATING : -- 20081130: .. options ATH_SUPPORT_AR5416 must be .. options AH_SUPPORT_AR5416 ? -- On Monday 01 December 2008 20:03:38 Sam Leffler wrote: > Things to note: > > This also represents an upgrade of the hal code over what was in the > tree. There are many bug fixes in this code, especially for AR5416 parts. > > I have no idea when this will be MFC'd. Because of the directory change > from contrib/dev/ath to dev/ath/ath_hal backporting by hand may be > painful. Definitely not before 7.1 goes out. > > I no longer be have access to internal Atheros' information (e.g. their > hal code). In particular this means support for new parts will have to > come by scraping code from the ath9k linux driver. I expect other > people to pitch in to do that. I will be happy to assist. > > Sam From subbsd at gmail.com Mon Dec 1 14:02:16 2008 From: subbsd at gmail.com (Ole Vole) Date: Mon Dec 1 14:02:24 2008 Subject: ale driver on asus eeepc 901 could not disable Tx/Rx under traffic flow Message-ID: <200812020102.04504.subbsd@gmail.com> Hello Maillist, Im using FreeBSD-CURRENT (from 01122008 snap from cvs) and got looped notice in dmesg buffer when LAN Ethernet generate some traffic: .. ale0: could not disable Tx/Rx MAC(0x00000008)! ale0: DMA read error! -- resetting .. ale0: could not disable Tx/Rx MAC(0x00000008)! .. with flapping interface (link going to down and back up). ifconfig ale0 -txcsum -rxcsum -tso and forcing link for media 10BaseT/UTP is in vain. Under small traffic flow ale0 work is fine without errors. Somebody meet with like similar prombel on Asus eee pc 901 ? Thanks From rdivacky at freebsd.org Mon Dec 1 14:43:46 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Dec 1 14:44:00 2008 Subject: HOWTO in wiki: adding custom dtrace probes in the kernel In-Reply-To: <86iqq3pyx8.fsf@ds4.des.no> References: <20081128154514.82247fe47bn83lkw@webmail.leidinger.net> <20081128171243.18141hd28pf4ve00@webmail.leidinger.net> <49304D0E.3030201@freebsd.org> <86iqq3pyx8.fsf@ds4.des.no> Message-ID: <20081201222248.GA99892@freebsd.org> On Mon, Dec 01, 2008 at 06:50:43PM +0100, Dag-Erling Sm??rgrav wrote: > "Marius N??nnerich" writes: > > Tim Kientzle wrote: > > > Seems that SDT_PROBE() should be using C99s "variadic macro" > > > feature. > > Is the kernel compiled in C99 mode? > > No, but it is compiled using a compiler that supports variadic macros > and has for many years (even before C99), and variadic macros are > already used in many places, including GEOM, ZFS and WITNESS. are you sure? I am seeing -std=c99 in the kernel build. check sys/conf/kern.pre.mk. it has been introduced more than 2 years ago in rev 1.75 of kern.pre.mk if I read it correctly. roman From fujita at soum.co.jp Mon Dec 1 15:40:54 2008 From: fujita at soum.co.jp (FUJITA Kazutoshi) Date: Mon Dec 1 15:41:04 2008 Subject: boot panic with SiS 961 UDMA100 controller Message-ID: <20081202.084049.74179593.fujita@soum.co.jp> hi, i cvsuped after a long time (3 months), kernel panics when boot, in ata_pci_dmareset() my pc has atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on pci0 svn r183723 works, but r183724(and later) cause panic any suggestions? regards, From pyunyh at gmail.com Mon Dec 1 17:22:49 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Dec 1 17:23:02 2008 Subject: ale driver on asus eeepc 901 could not disable Tx/Rx under traffic flow In-Reply-To: <200812020102.04504.subbsd@gmail.com> References: <200812020102.04504.subbsd@gmail.com> Message-ID: <20081202012237.GB5306@cdnetworks.co.kr> On Tue, Dec 02, 2008 at 01:02:04AM +0300, Ole Vole wrote: > Hello Maillist, > > Im using FreeBSD-CURRENT (from 01122008 snap from cvs) and got looped notice > in dmesg buffer when LAN Ethernet generate some traffic: > .. > ale0: could not disable Tx/Rx MAC(0x00000008)! > ale0: DMA read error! -- resetting > .. > ale0: could not disable Tx/Rx MAC(0x00000008)! > .. > with flapping interface (link going to down and back up). > Hmm, there was similiar report but I couldn't reproduce this on my box. In fact I'm out of idea why it happens. Since I have no access to datasheet I'm not sure what can be done at the moment. Even a developer in Atheros answered that changing mainboard would be the first step to diagnose the issue. :-( > ifconfig ale0 -txcsum -rxcsum -tso and forcing link for media 10BaseT/UTP is > in vain. > There are a couple of magic values related with PHY in Linux driver which I didn't want to include as I don't understand what it does. Do you use 10baseT media? Would you show me the output of "ifconfig ale0"? > Under small traffic flow ale0 work is fine without errors. Somebody meet with > like similar prombel on Asus eee pc 901 ? Thanks Anyway, I'll let you know if I mange to find a clue to the issue. -- Regards, Pyun YongHyeon From kallender at completecomputing.com Mon Dec 1 18:22:34 2008 From: kallender at completecomputing.com (Kyle Allender) Date: Mon Dec 1 18:22:40 2008 Subject: Problem in malloc.c, rev. 1.183 while building phonon-4.2.0 In-Reply-To: <4934363C.9090200@FreeBSD.org> References: <4933E158.5030407@completecomputing.com> <20081201132656.GB1397@lizard.fafoe.narf.at> <4933E7D9.7030707@completecomputing.com> <20081201134942.GC1397@lizard.fafoe.narf.at> <4933ED44.7010205@completecomputing.com> <4934363C.9090200@FreeBSD.org> Message-ID: <49349BD5.8080901@completecomputing.com> Jason Evans wrote: > Kyle Allender wrote: >> Stefan Farfeleder wrote: >>> On Mon, Dec 01, 2008 at 07:34:17AM -0600, Kyle Allender wrote: >>>> Stefan Farfeleder wrote: >>>>> On Mon, Dec 01, 2008 at 07:06:32AM -0600, Kyle Allender wrote: >>>>>> Hello. >>>>>> Generating mediaobjecttest.moc >>>>>> Assertion failed: ((ret << BLOCK_COST_2POW) != 0), function >>>>>> malloc_spin_lock, file /usr/src/lib/libc/stdlib/malloc.c, line 1287. >>>>>> Abort trap (core dumped) >>>>> Hi, >>>>> >>>>> this assertion has been fixed yesterday (svn r185483). >>>> Should I rerun build/installworld before re-attempting the kde build >>>> or just run make clean in the phonon directory? >>> >>> You need at least an updated libc. build/installworld will do that but >>> there are faster ways for this small update. After that you can >>> continue building kde. >>> >> OK. I've kicked off a buildworld as that's about the only method I >> know that will resolve this issue. The "faster ways" I'm unaware of - >> if someone could enlighten me, that'd be great. Buildworld will work >> in the meantime, though. > > In this case of libc, it's usually a good idea to do the full > buildworld, since libc gets statically linked into various toolchain > binaries. Fortunately, this bug in malloc only affects multi-threaded > applications; otherwise you'd have an unrecoverable system (though I > would have noticed that before committing). > > Jason > I ended up issuing a cd /usr/src/lib/libc; cd /usr/src/lib/libc; make && make install which did the trick - the KDE4 installation was able to proceed after that. I appreciate your help and will make a note of the better ways to do what I was after this morning. I would suppose I should go ahead and kick off a buildworld when the kde build completes later this evening. Will that necessitate having to rebuild the ports or would that be possible to put off until a later time? The system should remain stable correct? K From ninjin at nada.kth.se Mon Dec 1 17:49:51 2008 From: ninjin at nada.kth.se (Pontus Stenetorp) Date: Mon Dec 1 18:34:45 2008 Subject: atapci IRQ storm on a Dell E6400 In-Reply-To: <491D32CE.10206@nada.kth.se> References: <491D32CE.10206@nada.kth.se> Message-ID: <49349433.7010609@nada.kth.se> Update, Problem solved and the solution was quite interesting. The BIOS of an E6400 enables you to set the behaviour of the SATA-controller, the options are ATA, AHCI and IRRT (Intel Rapid Recovery Technology). It was set to ATA in order to enable installation of Windows XP which apparently doesn't play nice with IRRT and AHCI (blue screen on boot anyone?). FreeBSD works just fine for the AHCI and IRRT options but choosing ATA will give you an IRQ storm. Pontus Pontus Stenetorp wrote: > Hello CURRENT, > > I am running FreeBSD 8.0-CURRENT on a Dell E6400 laptop and I am > experiencing an IRQ storm on atapci. My dual-core ends up working at > about 40% CPU on interrupts. I have attached, uname -a, dmesg, vmstat > -i, top -S and my kernconf. The only changes made to the kernconf are > the ones described in /usr/src/UPDATING as to improve performance for > FreeBSD 8.x The reason I have for running CURRENT is that the my Dell > E6400 kern panics shortly after boot on FreeBSD 7.0-STABLE and on > FreeBSD 7.1-BETA2. A photo of a panic can be found below. > > Thanks for any help regarding this, > Pontus Stenetorp > > \begin{uname -a} > FreeBSD enoki 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Nov 10 04:08:41 > PST 2008 root@enoki:/usr/obj/usr/src/sys/ENOKI0 i386 > \end{uname -a} > > \begin{dmesg} > Copyright (c) 1992-2008 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 8.0-CURRENT #0: Mon Nov 10 04:08:41 PST 2008 > root@enoki:/usr/obj/usr/src/sys/ENOKI0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz (2527.02-MHz > 686-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > > Features=0xbfebfbff > > > Features2=0x8e3fd > > AMD Features=0x20100000 > AMD Features2=0x1 > Cores per package: 2 > real memory = 2135216128 (2036 MB) > avail memory = 2081230848 (1984 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, > RF2413, RF5413, RF2133, RF2425, RF2417) > acpi0: on motherboard > acpi0: [ITHREAD] > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi0: reservation of 0, 9f000 (3) failed > acpi0: reservation of 100000, 7f34d400 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_ec0: port 0x930,0x934 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xdf00-0xdf7f mem > 0xf5000000-0xf5ffffff,0xe0000000-0xefffffff,0xf2000000-0xf3ffffff irq > 16 at device 0.0 on pci1 > em0: port 0xefe0-0xefff > mem 0xf6fe0000-0xf6ffffff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 > on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:21:70:b5:24:b8 > uhci0: port 0x6f60-0x6f7f irq 20 > at device 26.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x6f80-0x6f9f irq 21 > at device 26.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x6fa0-0x6fbf irq 22 > at device 26.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem > 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 6 ports with 6 removable, self powered > ugen0: 239/2, rev 2.00/86.10, addr 2> on uhub3 > pci0: at device 27.0 (no driver attached) > pcib2: at device 28.0 on pci0 > pci11: on pcib2 > ath0: mem 0xf1ff0000-0xf1ffffff irq 16 at device 0.0 on > pci11 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: mac 10.3 phy 6.1 radio 10.2 > pcib3: at device 28.1 on pci0 > pci12: on pcib3 > pci12: at device 0.0 (no driver attached) > pcib4: at device 28.2 on pci0 > pci13: on pcib4 > pcib5: at device 28.3 on pci0 > pci14: on pcib5 > uhci3: port 0x6f00-0x6f1f irq 20 > at device 29.0 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb4: on uhci3 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 2 ports with 2 removable, self powered > uhci4: port 0x6f20-0x6f3f irq 21 > at device 29.1 on pci0 > uhci4: [GIANT-LOCKED] > uhci4: [ITHREAD] > usb5: on uhci4 > usb5: USB revision 1.0 > uhub5: on usb5 > uhub5: 2 ports with 2 removable, self powered > uhci5: port 0x6f40-0x6f5f irq 22 > at device 29.2 on pci0 > uhci5: [GIANT-LOCKED] > uhci5: [ITHREAD] > usb6: on uhci5 > usb6: USB revision 1.0 > uhub6: on usb6 > uhub6: 2 ports with 2 removable, self powered > ehci1: mem > 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 > ehci1: [GIANT-LOCKED] > ehci1: [ITHREAD] > usb7: EHCI version 1.0 > usb7: companion controllers, 2 ports each: usb4 usb5 usb6 > usb7: on ehci1 > usb7: USB revision 2.0 > uhub7: on usb7 > uhub7: 6 ports with 6 removable, self powered > pcib6: at device 30.0 on pci0 > pci3: on pcib6 > fwohci0: <1394 Open Host Controller Interface> mem > 0xf1bff800-0xf1bfffff irq 17 at device 1.0 on pci3 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 33:4f:c0:00:20:81:35:e1 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 32:4f:c0:81:35:e1 > fwe0: Ethernet address: 32:4f:c0:81:35:e1 > fwip0: on firewire0 > fwip0: Firewire address: 33:4f:c0:00:20:81:35:e1 @ 0xfffe00000000, > S400, maxrec 2048 > sbp0: on firewire0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x1094000 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > pci3: at device 1.1 (no driver > attached) > pci3: at device 1.2 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x6e70-0x6e77,0x6e78-0x6e7b,0x6e80-0x6e87,0x6e88-0x6e8b,0x6ea0-0x6eaf,0x6e90-0x6e9f > irq 19 at device 31.2 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > pci0: at device 31.3 (no driver attached) > atapci1: port > 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eef,0xefa0-0xefaf > irq 19 at device 31.5 on pci0 > atapci1: [ITHREAD] > ata4: on atapci1 > ata4: [ITHREAD] > ata5: on atapci1 > ata5: [ITHREAD] > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > battery1: on acpi0 > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 > on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model GlidePoint, device ID 0 > atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 > uart0: <16550 or compatible> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 > uart0: [FILTER] > cpu0: on acpi0 > ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj > 0xc52c66c0 [20070320] > ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving > operands for [OpcodeName unavailable] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed > [\\_PR_.CPU0._OSC] (Node 0xc52a0180), AE_AML_INTERNAL > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj > 0xc52c6440 [20070320] > ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving > operands for [OpcodeName unavailable] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed > [\\_PR_.CPU1._OSC] (Node 0xc52a00a0), AE_AML_INTERNAL > est1: on cpu1 > p4tcc1: on cpu1 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xce7ff,0xce800-0xcffff pnpid > ORM0000 on isa0 > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > ata0: [ITHREAD] > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > ata1: [ITHREAD] > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > uhub8: on uhub0 > uhub8: 3 ports with 0 removable, self powered > ukbd0: 3> on uhub8 > kbd2 at ukbd0 > ums0: > on uhub8 > ums0: 3 buttons. > ugen1: on uhub2 > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > ad4: 238475MB at ata2-master UDMA33 > unknown: timeout waiting for read DRQ > unknown: timeout waiting for read DRQ > acd0: DVDR at ata3-master UDMA33 > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad4s2a > wlan0: Ethernet address: xx:xx:xx:xx:xx:xx > ath0: ath_hal_init_channels failed, rd 98 cc 511 outdoor 0 ecm 1 > wlan0: link state changed to UP > \end{dmesg} > > \begin{vmstat -i output} > interrupt total rate > irq1: atkbd0 8899 3 > irq9: acpi0 1208 0 > irq12: psm0 82725 29 > irq16: ath0 91826 32 > irq17: fwohci0 3 0 > irq19: atapci0+ 154687206 55245 > irq20: uhci0 uhci+ 12 0 > irq22: uhci2 ehci+ 5 0 > cpu0: timer 5599330 1999 > cpu1: timer 5589315 1996 > Total 166060529 59307 > \end{vmstat -i output} > > \begin{top -S output} > last pid: 83401; load averages: 0.11, 0.15, 0.24 > up 0+00:49:20 22:44:12 > 121 processes: 4 running, 97 sleeping, 2 zombie, 18 waiting > CPU: 1.3% user, 0.0% nice, 0.4% system, 42.7% interrupt, 55.6% idle > Mem: 171M Active, 245M Inact, 116M Wired, 2316K Cache, 112M Buf, 1454M > Free > Swap: 2048M Total, 2048M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 11 root 2 171 ki31 0K 16K RUN 0 41:41 108.06% idle > 12 root 19 -64 - 0K 152K WAIT 0 41:41 88.28% intr > \end{top -S output} > > \begin{kernconf} > # > # GENERIC -- Generic kernel configuration file for FreeBSD/i386 > # > # For more information on this file, please read the handbook section on > # Kernel Configuration Files: > # > # > http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html > > # > # The handbook is also available locally in /usr/share/doc/handbook > # if you've installed the doc distribution, otherwise always see the > # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the > # latest information. > # > # An exhaustive list of options and more detailed explanations of the > # device lines is also present in the ../../conf/NOTES and NOTES files. > # If you are in doubt as to the purpose or necessity of a line, check > first > # in NOTES. > # > # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.500 2008/10/09 21:25:01 > n_hibma Exp $ > > cpu I486_CPU > cpu I586_CPU > cpu I686_CPU > ident ENKI0 > > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for > devices. > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > options SCHED_ULE # ULE scheduler > options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options SCTP # Stream Control Transmission Protocol > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big directories > options UFS_GJOURNAL # Enable gjournal-based UFS journaling > options MD_ROOT # MD is a potential root device > options NFSCLIENT # Network Filesystem Client > options NFSSERVER # Network Filesystem Server > options NFSLOCKD # Network Lock Manager > options NFS_ROOT # NFS usable as /, requires NFSCLIENT > options MSDOSFS # MSDOS Filesystem > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > options KTRACE # ktrace(1) support > options STACK # stack(9) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options STOP_NMI # Stop CPUS using NMI instead of IPI > options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) > options AUDIT # Security event auditing > > # Debugging for use in -current > #options KDB # Enable kernel debugger support. > #options DDB # Support DDB. > #options GDB # Support remote GDB. > #options INVARIANTS # Enable calls of extra sanity checking > #options INVARIANT_SUPPORT # Extra sanity checks of internal > structures, required by INVARIANTS > #options WITNESS # Enable checks to detect deadlocks > and cycles > #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for > speed > > # To make an SMP kernel, the next two lines are needed > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC > > # CPU frequency control > device cpufreq > > # Bus support. > device acpi > device eisa > device pci > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives > options ATA_STATIC_ID # Static device numbering > > # SCSI Controllers > device ahb # EISA AHA1742 family > device ahc # AHA2940 and onboard AIC7xxx devices > options AHC_REG_PRETTY_PRINT # Print register bitfields in debug > # output. Adds ~128k to driver. > device ahd # AHA39320/29320 and onboard AIC79xx devices > options AHD_REG_PRETTY_PRINT # Print register bitfields in debug > # output. Adds ~215k to driver. > device amd # AMD 53C974 (Tekram DC-390(T)) > device hptiop # Highpoint RocketRaid 3xxx series > device isp # Qlogic family > #device ispfw # Firmware for QLogic HBAs- normally a module > device mpt # LSI-Logic MPT-Fusion > #device ncr # NCR/Symbios Logic > device sym # NCR/Symbios Logic (newer chipsets + those > of `ncr') > device trm # Tekram DC395U/UW/F DC315U adapters > > device adv # Advansys SCSI adapters > device adw # Advansys wide SCSI adapters > device aha # Adaptec 154x SCSI adapters > device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. > device bt # Buslogic/Mylex MultiMaster SCSI adapters > > device ncv # NCR 53C500 > device nsp # Workbit Ninja SCSI-3 > device stg # TMC 18C30/18C50 > > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > device ses # SCSI Environmental Services (and SAF-TE) > > # RAID controllers interfaced to the SCSI subsystem > device amr # AMI MegaRAID > device arcmsr # Areca SATA II RAID > device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID > device ciss # Compaq Smart RAID 5* > device dpt # DPT Smartcache III, IV - See NOTES for options > device hptmv # Highpoint RocketRAID 182x > device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx > device iir # Intel Integrated RAID > device ips # IBM (Adaptec) ServeRAID > device mly # Mylex AcceleRAID/eXtremeRAID > device twa # 3ware 9000 series PATA/SATA RAID > > # RAID controllers > device aac # Adaptec FSA RAID > device aacp # SCSI passthrough for aac (requires CAM) > device ida # Compaq Smart RAID > device mfi # LSI MegaRAID SAS > device mlx # Mylex DAC960 family > device pst # Promise Supertrak SX6000 > device twe # 3ware ATA RAID > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device kbdmux # keyboard multiplexer > > device vga # VGA video card driver > > device splash # Splash screen and screen saver support > > # syscons is the default console driver, resembling an SCO console > device sc > > device agp # support several AGP chipsets > > # Power management support (see NOTES for more options) > #device apm > # Add suspend/resume support for the i8254. > device pmtimer > > # PCCARD (PCMCIA) support > # PCMCIA and cardbus bridge support > device cbb # cardbus (yenta) bridge > device pccard # PC Card (16-bit) bus > device cardbus # CardBus (32-bit) bus > > # Serial (COM) ports > device uart # Generic UART driver > > # Parallel port > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > device plip # TCP/IP over parallel > device ppi # Parallel port interface device > #device vpo # Requires scbus and da > > # If you've got a "dumb" serial or parallel PCI card that is > # supported by the puc(4) glue driver, uncomment the following > # line to enable it (connects to sio, uart and/or ppc drivers): > #device puc > > # PCI Ethernet NICs. > device de # DEC/Intel DC21x4x (``Tulip'') > device em # Intel PRO/1000 Gigabit Ethernet Family > device igb # Intel PRO/1000 PCIE Server Gigabit Family > device ixgb # Intel PRO/10GbE Ethernet Card > device le # AMD Am7900 LANCE and Am79C9xx PCnet > device ti # Alteon Networks Tigon I/II gigabit Ethernet > device txp # 3Com 3cR990 (``Typhoon'') > device vx # 3Com 3c590, 3c595 (``Vortex'') > > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use these > NICs! > device miibus # MII bus support > device ae # Attansic/Atheros L2 FastEthernet > device age # Attansic/Atheros L1 Gigabit Ethernet > device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet > device bfe # Broadcom BCM440x 10/100 Ethernet > device bge # Broadcom BCM570xx Gigabit Ethernet > device dc # DEC/Intel 21143 and various workalikes > device et # Agere ET1310 10/100/Gigabit Ethernet > device fxp # Intel EtherExpress PRO/100B (82557, 82558) > device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet > device lge # Level 1 LXT1001 gigabit Ethernet > device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet > device nfe # nVidia nForce MCP on-board Ethernet > device nge # NatSemi DP83820 gigabit Ethernet > #device nve # nVidia nForce MCP on-board Ethernet > Networking > device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') > device re # RealTek 8139C+/8169/8169S/8110S > device rl # RealTek 8129/8139 > device sf # Adaptec AIC-6915 (``Starfire'') > device sis # Silicon Integrated Systems SiS 900/SiS 7016 > device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet > device ste # Sundance ST201 (D-Link DFE-550TX) > device stge # Sundance/Tamarack TC9021 gigabit Ethernet > device tl # Texas Instruments ThunderLAN > device tx # SMC EtherPower II (83c170 ``EPIC'') > device vge # VIA VT612x gigabit Ethernet > device vr # VIA Rhine, Rhine II > device wb # Winbond W89C840F > device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') > > # ISA Ethernet NICs. pccard NICs included. > device cs # Crystal Semiconductor CS89x0 NIC > # 'device ed' requires 'device miibus' > device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards > device ex # Intel EtherExpress Pro/10 and Pro/10+ > device ep # Etherlink III based cards > device fe # Fujitsu MB8696x based cards > device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. > device sn # SMC's 9000 series of Ethernet chips > device xe # Xircom pccard Ethernet > > # Wireless NIC cards > device wlan # 802.11 support > options IEEE80211_DEBUG # enable debug msgs > options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's > device wlan_wep # 802.11 WEP support > device wlan_ccmp # 802.11 CCMP support > device wlan_tkip # 802.11 TKIP support > device wlan_amrr # AMRR transmit rate control algorithm > device an # Aironet 4500/4800 802.11 wireless NICs. > device ath # Atheros pci/cardbus NIC's > device ath_hal # Atheros HAL (Hardware Access Layer) > device ath_rate_sample # SampleRate tx rate control for ath > device ral # Ralink Technology RT2500 wireless NICs. > device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. > #device wl # Older non 802.11 Wavelan wireless NIC. > > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device tun # Packet tunnel. > device pty # BSD-style compatibility pseudo ttys > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > device firmware # firmware assist module > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > # USB support > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > #device udbp # USB Double Bulk Pipe devices > device ugen # Generic > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device ulpt # Printer > device umass # Disks/Mass storage - Requires scbus and da > device ums # Mouse > device ural # Ralink Technology RT2500USB wireless NICs > device rum # Ralink Technology RT2501USB wireless NICs > device zyd # ZyDAS zb1211/zb1211b wireless NICs > device urio # Diamond Rio 500 MP3 player > device uscanner # Scanners > # USB Serial devices > device ucom # Generic com ttys > device u3g # USB-based 3G modems (Option, Huawei, Sierra) > device uark # Technologies ARK3116 based serial adapters > device ubsa # Belkin F5U103 and compatible serial adapters > device uftdi # For FTDI usb serial adapters > device uipaq # Some WinCE based devices > device uplcom # Prolific PL-2303 serial adapters > device uslcom # SI Labs CP2101/CP2102 serial adapters > device uvisor # Visor and Palm devices > device uvscom # USB serial support for DDI pocket's PHS > # USB Ethernet, requires miibus > device aue # ADMtek USB Ethernet > device axe # ASIX Electronics USB Ethernet > device cdce # Generic USB over Ethernet > device cue # CATC USB Ethernet > device kue # Kawasaki LSI USB Ethernet > device rue # RealTek RTL8150 USB Ethernet > device udav # Davicom DM9601E USB > > # FireWire support > device firewire # FireWire bus code > device sbp # SCSI over FireWire (Requires scbus and da) > device fwe # Ethernet over FireWire (non-standard!) > device fwip # IP over FireWire (RFC 2734,3146) > device dcons # Dumb console driver > device dcons_crom # Configuration ROM for dcons > \end{kernconf} > > \begin{FreeBSD 7.1-BETA2 panic photo} > http://pici.se/p/BwsmUJsvx/ > \end{FreeBSD 7.1-BETA2 panic photo} > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From rmtodd at ichotolot.servalan.com Mon Dec 1 21:45:07 2008 From: rmtodd at ichotolot.servalan.com (Richard Todd) Date: Mon Dec 1 21:45:13 2008 Subject: Panic upon unmounting zfs snapshot: "vput: negative ref cnt" In-Reply-To: (Richard Todd's message of "Sat, 29 Nov 2008 12:16:23 -0600") References: Message-ID: Richard Todd writes: > I'm running -CURRENT as of this Thursday, and discovered the following panic > upon doing the fairly straightforward steps of making a snapshot, mounting > it, doing some activity reading from the snapshot, and unmounting it -- > the exact sequence of commands was something like > zfs snapshot u1@foosnap > mount -r -t zfs u1@foosnap /mnt > ls -lR /mnt > umount /mnt > > Got a crash dump, gdb info follows. Note that the offending vp seems to be > the vnode for the mount point that the snapshot was mounted on. A bit more exploration and littering the unmount code with vprint()s and I think I've narrowed down the problem to the following bit of code near the end of zfs_umount in /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c if (zfsvfs->z_issnap) { vnode_t *svp = vfsp->mnt_vnodecovered; ASSERT(svp->v_count == 2); VN_RELE(svp); } The above code seems to assume that the ZFS snapshot being unmounted was mounted through the .zfs/snapshot pseudo-directory mechanism; apparently on mount the underlying vnode (for the .zfs/snapshot/xxx) has an extra reference added, so a VN_RELE needs to be done. But if the mount of the snapshot was done manually (via mount -t zfs), then the underlying vnode *doesn't* have the extra reference, so the VN_RELE here means that the later vput() in dounmount will panic. The above code should be probably smarter and test whether vfsp->mnt_vnodecovered points to the .zfs/snapshot pseudodirectory or not; unfortunately, I'm not sure how to do that. Since I usually mount snapshots by hand instead of using the .zfs/snapshot mechanism, for my purposes just commenting out the above chunk of code solves my problem for the time being. From stb at lassitu.de Mon Dec 1 22:57:09 2008 From: stb at lassitu.de (Stefan Bethke) Date: Mon Dec 1 22:57:21 2008 Subject: boot panic with SiS 961 UDMA100 controller In-Reply-To: <20081202.084049.74179593.fujita@soum.co.jp> References: <20081202.084049.74179593.fujita@soum.co.jp> Message-ID: <9A1A0B00-0E6D-4CFA-8EDF-CC1A3E4171F5@lassitu.de> Am 02.12.2008 um 00:40 schrieb FUJITA Kazutoshi: > hi, > > i cvsuped after a long time (3 months), kernel panics when boot, > in ata_pci_dmareset() > > my pc has > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on > pci0 > > svn r183723 works, but r183724(and later) cause panic > > > any suggestions? Showing us at least some part of the panic, if not a full backtrace, probably would be helpful. Try disabling DMA at the loader with set hw.ata.ata_dma="0" Stefan -- Stefan Bethke Fon +49 170 346 0140 From samspeed at mail.ru Tue Dec 2 00:20:51 2008 From: samspeed at mail.ru (=?koi8-r?Q?=E1=CE=C4=D2=C5=CA_=F3=CD=C1=C7=C9=CE?=) Date: Tue Dec 2 00:20:59 2008 Subject: Error while making openoffice-3.0 on CURRENT Message-ID: Hi. Please help, can't build OOo-3.0 on latest current with following error: ............................. ---------------------------------------------------------- - start unit test on library ../unxfbsdi.pro/lib/libtests.so ---------------------------------------------------------- testshl2 ../unxfbsdi.pro/lib/libtests.so Use default signal file name 'signalfile_1228173411.txt' # Current Time: 02:16:52 [2008.12.02//] # -- BEGIN: cow_wrapper_test.cow_wrapper_test.testCowWrapper;PASSED#OK# o3tltests.range_test.global;PASSED#OK# o3tltests.heap_ptr_test.global;PASSED#OK# # -- END: Test #PASSED# Running processes: 0 deliver -- version: 1.130 Module 'o3tl' delivered successfully. 0 files copied, 5 files unchanged ============= Building module udkapi Running processes: 1 /mnt/local/storage/usr/ports/editors/openoffice.org-3/work/OOO300_m9/udkapi/com/sun/star/uno idlc @/tmp/mkfCrUPm idlc: could not create registry file 'file:///mnt/local/storage/usr/ports/editors/openoffice.org-3/work/OOO300_m9/udkapi/unxfbsdi.pro/ucr/com/sun/star/uno/Exception._idlc_' idlc: compile 'Exception.idl' ... idlc: detected 1 errors Sun Microsystems (R) idlc Version 1.1 dmake: Error code 1, while making '../../../../unxfbsdi.pro/ucr/cssuno.db' Running processes: 0 1 module(s): udkapi need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /mnt/local/storage/usr/ports/editors/openoffice.org-3/work/OOO300_m9/udkapi/com/sun/star/uno Attention: if you build and deliver the above module(s) you may prolongue your the build issuing command "build --from udkapi" rmdir /tmp/3213 *** Error code 1 Stop in /mnt/local/storage/usr/ports/editors/openoffice.org-3. From tinderbox at freebsd.org Tue Dec 2 00:33:39 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 00:33:54 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081202083335.BB96173039@freebsd-current.sentex.ca> TB --- 2008-12-02 08:06:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 08:06:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-12-02 08:06:04 - cleaning the object tree TB --- 2008-12-02 08:06:51 - cvsupping the source tree TB --- 2008-12-02 08:06:51 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-12-02 08:07:02 - building world TB --- 2008-12-02 08:07:02 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 08:07:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 08:07:02 - TARGET=sparc64 TB --- 2008-12-02 08:07:02 - TARGET_ARCH=sparc64 TB --- 2008-12-02 08:07:02 - TZ=UTC TB --- 2008-12-02 08:07:02 - __MAKE_CONF=/dev/null TB --- 2008-12-02 08:07:02 - cd /src TB --- 2008-12-02 08:07:02 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 08:07:04 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/hexdump.c cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/humanize_number.c cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/kinfo_getfile.c cc1: warnings being treated as errors /src/lib/libutil/kinfo_getfile.c: In function 'kinfo_getfile': /src/lib/libutil/kinfo_getfile.c:45: warning: cast increases required alignment of target type /src/lib/libutil/kinfo_getfile.c:60: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 08:33:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 08:33:35 - ERROR: failed to build world TB --- 2008-12-02 08:33:35 - 1160.30 user 128.70 system 1651.66 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From rea-fbsd at codelabs.ru Tue Dec 2 00:49:13 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Dec 2 00:49:19 2008 Subject: Error while making openoffice-3.0 on CURRENT In-Reply-To: References: Message-ID: Andrey, good day. Tue, Dec 02, 2008 at 09:30:11AM +0300, ?????? ?????? wrote: > Please help, can't build OOo-3.0 on latest current with following error: [...] > ERROR: error 65280 occurred while making /mnt/local/storage/usr/ports/editors/openoffice.org-3/work/OOO300_m9/udkapi/com/sun/star/uno Only at -CURRENT? Any luck for the -STABLE on the same hardware? How much (free) memory do you have on your machine? I had seen simular errors while was building OO on the machines with small amount (<2Gb) of free memory. If this isn't the case, then may be this can be cured by the latest changes in jemalloc: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/malloc.c How current is your -CURRENT? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081202/484efd55/attachment.pgp From tinderbox at freebsd.org Tue Dec 2 00:59:05 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 00:59:18 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081202085902.7E3D273039@freebsd-current.sentex.ca> TB --- 2008-12-02 08:33:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 08:33:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-12-02 08:33:35 - cleaning the object tree TB --- 2008-12-02 08:34:03 - cvsupping the source tree TB --- 2008-12-02 08:34:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-12-02 08:34:11 - building world TB --- 2008-12-02 08:34:11 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 08:34:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 08:34:11 - TARGET=sun4v TB --- 2008-12-02 08:34:11 - TARGET_ARCH=sparc64 TB --- 2008-12-02 08:34:11 - TZ=UTC TB --- 2008-12-02 08:34:11 - __MAKE_CONF=/dev/null TB --- 2008-12-02 08:34:11 - cd /src TB --- 2008-12-02 08:34:11 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 08:34:12 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/hexdump.c cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/humanize_number.c cc -O2 -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/kinfo_getfile.c cc1: warnings being treated as errors /src/lib/libutil/kinfo_getfile.c: In function 'kinfo_getfile': /src/lib/libutil/kinfo_getfile.c:45: warning: cast increases required alignment of target type /src/lib/libutil/kinfo_getfile.c:60: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 08:59:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 08:59:02 - ERROR: failed to build world TB --- 2008-12-02 08:59:02 - 1157.52 user 128.34 system 1526.60 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Tue Dec 2 01:23:42 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 01:23:49 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20081202092339.5174373039@freebsd-current.sentex.ca> TB --- 2008-12-02 09:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 09:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-12-02 09:00:00 - cleaning the object tree TB --- 2008-12-02 09:00:31 - cvsupping the source tree TB --- 2008-12-02 09:00:31 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-12-02 09:00:39 - building world TB --- 2008-12-02 09:00:39 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 09:00:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 09:00:39 - TARGET=arm TB --- 2008-12-02 09:00:39 - TARGET_ARCH=arm TB --- 2008-12-02 09:00:39 - TZ=UTC TB --- 2008-12-02 09:00:39 - __MAKE_CONF=/dev/null TB --- 2008-12-02 09:00:39 - cd /src TB --- 2008-12-02 09:00:39 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 09:00:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/hexdump.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/humanize_number.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/kinfo_getfile.c cc1: warnings being treated as errors /src/lib/libutil/kinfo_getfile.c: In function 'kinfo_getfile': /src/lib/libutil/kinfo_getfile.c:45: warning: cast increases required alignment of target type /src/lib/libutil/kinfo_getfile.c:60: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 09:23:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 09:23:39 - ERROR: failed to build world TB --- 2008-12-02 09:23:39 - 1079.20 user 133.81 system 1418.43 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Tue Dec 2 02:16:43 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 02:17:00 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081202101639.93F7773039@freebsd-current.sentex.ca> TB --- 2008-12-02 09:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 09:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-12-02 09:00:00 - cleaning the object tree TB --- 2008-12-02 09:00:53 - cvsupping the source tree TB --- 2008-12-02 09:00:53 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-12-02 09:01:00 - building world TB --- 2008-12-02 09:01:00 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 09:01:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 09:01:00 - TARGET=amd64 TB --- 2008-12-02 09:01:00 - TARGET_ARCH=amd64 TB --- 2008-12-02 09:01:00 - TZ=UTC TB --- 2008-12-02 09:01:00 - __MAKE_CONF=/dev/null TB --- 2008-12-02 09:01:00 - cd /src TB --- 2008-12-02 09:01:00 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 09:01:02 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_basic.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_bin.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_cred.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_files.c: In function 'procstat_files': /src/usr.bin/procstat/procstat_files.c:272: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 10:16:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 10:16:39 - ERROR: failed to build world TB --- 2008-12-02 10:16:39 - 3596.12 user 362.23 system 4598.56 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From kvedulv at kvedulv.de Tue Dec 2 02:22:40 2008 From: kvedulv at kvedulv.de (Michael Moll) Date: Tue Dec 2 02:22:48 2008 Subject: boot panic with SiS 961 UDMA100 controller In-Reply-To: <20081202.084049.74179593.fujita@soum.co.jp> References: <20081202.084049.74179593.fujita@soum.co.jp> Message-ID: <20081202102237.GA61096@darkthrone.kvedulv.de> Hi, On Tue, Dec 02, 2008 at 08:40:49AM +0900, FUJITA Kazutoshi wrote: > i cvsuped after a long time (3 months), kernel panics when boot, > in ata_pci_dmareset() > > my pc has > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on pci0 > > svn r183723 works, but r183724(and later) cause panic Maybe this patch resolves your problem also: http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000669.html Regards -- Michael Moll From tinderbox at freebsd.org Tue Dec 2 02:38:14 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 02:38:31 2008 Subject: [head tinderbox] failure on i386/i386 Message-ID: <20081202103810.038DF73039@freebsd-current.sentex.ca> TB --- 2008-12-02 09:23:39 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 09:23:39 - starting HEAD tinderbox run for i386/i386 TB --- 2008-12-02 09:23:39 - cleaning the object tree TB --- 2008-12-02 09:24:17 - cvsupping the source tree TB --- 2008-12-02 09:24:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-12-02 09:24:25 - building world TB --- 2008-12-02 09:24:25 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 09:24:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 09:24:25 - TARGET=i386 TB --- 2008-12-02 09:24:25 - TARGET_ARCH=i386 TB --- 2008-12-02 09:24:25 - TZ=UTC TB --- 2008-12-02 09:24:25 - __MAKE_CONF=/dev/null TB --- 2008-12-02 09:24:25 - cd /src TB --- 2008-12-02 09:24:25 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 09:24:27 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_basic.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_bin.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_cred.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_files.c: In function 'procstat_files': /src/usr.bin/procstat/procstat_files.c:272: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 10:38:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 10:38:09 - ERROR: failed to build world TB --- 2008-12-02 10:38:09 - 3540.35 user 338.39 system 4470.59 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From subbsd at gmail.com Tue Dec 2 03:00:04 2008 From: subbsd at gmail.com (Ole) Date: Tue Dec 2 03:00:11 2008 Subject: ale driver on asus eeepc 901 could not disable Tx/Rx under traffic flow Message-ID: <200812021359.56698.subbsd@gmail.com> Hello Maillist, ifconfig ale0: ale0: flags=8843 metric 0 mtu 1500 options=319b ether 00:22:15:92:4f:a0 inet 172.32.1.51 netmask 0xffff0000 broadcast 172.32.255.255 media: Ethernet autoselect (100baseTX ) status: active I see, the problem is floating and in my case depend from type of remote port on ethernet cable. For example when connect my book (with ale0) to 1Gbit/s pc port (with FreeBSD- Current and Marvell card (msk driver)) i get ale0: could not disable Tx/Rx MAC(0x00000008)! ale0: DMA read error! -- resetting and flapping interface forever when traffic flow. when i connection ale0 to 100Mbit/s switch port or to 100Mbit/s PC (with Windows OS) through cross-over cable, ale0 work perfect without any warning. Currenlty i reproduce problem only with PC:msk<->PC:ale link. I try to collect more information for other situation. PS: PC with FreeBSD/msk driver working with other (!= ale0) link (to switch or to PC) is fine. > Hello Maillist, > > Im using FreeBSD-CURRENT (from 01122008 snap from cvs) and got looped notice > in dmesg buffer when LAN Ethernet generate some traffic: > .. > ale0: could not disable Tx/Rx MAC(0x00000008)! > ale0: DMA read error! -- resetting > .. > ale0: could not disable Tx/Rx MAC(0x00000008)! > .. > with flapping interface (link going to down and back up). > Hmm, there was similiar report but I couldn't reproduce this on my box. In fact I'm out of idea why it happens. Since I have no access to datasheet I'm not sure what can be done at the moment. Even a developer in Atheros answered that changing mainboard would be the first step to diagnose the issue. :-( > ifconfig ale0 -txcsum -rxcsum -tso and forcing link for media 10BaseT/UTP is > in vain. > There are a couple of magic values related with PHY in Linux driver which I didn't want to include as I don't understand what it does. Do you use 10baseT media? Would you show me the output of "ifconfig ale0"? > Under small traffic flow ale0 work is fine without errors. Somebody meet with > like similar prombel on Asus eee pc 901 ? Thanks Anyway, I'll let you know if I mange to find a clue to the issue. -- Regards, Pyun YongHyeon From tinderbox at freebsd.org Tue Dec 2 03:31:06 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 03:31:18 2008 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20081202113103.7431873039@freebsd-current.sentex.ca> TB --- 2008-12-02 10:16:39 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 10:16:39 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-12-02 10:16:39 - cleaning the object tree TB --- 2008-12-02 10:17:10 - cvsupping the source tree TB --- 2008-12-02 10:17:10 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-12-02 10:17:20 - building world TB --- 2008-12-02 10:17:20 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 10:17:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 10:17:20 - TARGET=pc98 TB --- 2008-12-02 10:17:20 - TARGET_ARCH=i386 TB --- 2008-12-02 10:17:20 - TZ=UTC TB --- 2008-12-02 10:17:20 - __MAKE_CONF=/dev/null TB --- 2008-12-02 10:17:20 - cd /src TB --- 2008-12-02 10:17:20 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 10:17:23 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_basic.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_bin.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_cred.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_files.c: In function 'procstat_files': /src/usr.bin/procstat/procstat_files.c:272: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 11:31:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 11:31:03 - ERROR: failed to build world TB --- 2008-12-02 11:31:03 - 3528.58 user 353.62 system 4463.26 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Tue Dec 2 04:13:26 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 04:13:34 2008 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20081202121323.ED05173039@freebsd-current.sentex.ca> TB --- 2008-12-02 10:38:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 10:38:10 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-12-02 10:38:10 - cleaning the object tree TB --- 2008-12-02 10:38:45 - cvsupping the source tree TB --- 2008-12-02 10:38:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-12-02 10:38:52 - building world TB --- 2008-12-02 10:38:52 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 10:38:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 10:38:52 - TARGET=ia64 TB --- 2008-12-02 10:38:52 - TARGET_ARCH=ia64 TB --- 2008-12-02 10:38:52 - TZ=UTC TB --- 2008-12-02 10:38:52 - __MAKE_CONF=/dev/null TB --- 2008-12-02 10:38:52 - cd /src TB --- 2008-12-02 10:38:52 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 10:38:54 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_basic.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_bin.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_cred.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_files.c: In function 'procstat_files': /src/usr.bin/procstat/procstat_files.c:272: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 12:13:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 12:13:23 - ERROR: failed to build world TB --- 2008-12-02 12:13:23 - 4687.92 user 357.02 system 5713.55 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From tinderbox at freebsd.org Tue Dec 2 04:48:36 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 04:50:22 2008 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20081202124831.68BC473039@freebsd-current.sentex.ca> TB --- 2008-12-02 11:31:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 11:31:03 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-12-02 11:31:03 - cleaning the object tree TB --- 2008-12-02 11:31:34 - cvsupping the source tree TB --- 2008-12-02 11:31:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-12-02 11:31:42 - building world TB --- 2008-12-02 11:31:42 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 11:31:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 11:31:42 - TARGET=powerpc TB --- 2008-12-02 11:31:42 - TARGET_ARCH=powerpc TB --- 2008-12-02 11:31:42 - TZ=UTC TB --- 2008-12-02 11:31:42 - __MAKE_CONF=/dev/null TB --- 2008-12-02 11:31:42 - cd /src TB --- 2008-12-02 11:31:42 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 11:31:45 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_kstack.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_threads.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_vm.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_vm.c: In function 'procstat_vm': /src/usr.bin/procstat/procstat_vm.c:59: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' /src/usr.bin/procstat/procstat_vm.c:60: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 12:48:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 12:48:31 - ERROR: failed to build world TB --- 2008-12-02 12:48:31 - 3677.00 user 338.99 system 4647.80 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Tue Dec 2 05:26:33 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 05:26:40 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081202132630.C3C3773039@freebsd-current.sentex.ca> TB --- 2008-12-02 12:13:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 12:13:24 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-12-02 12:13:24 - cleaning the object tree TB --- 2008-12-02 12:13:37 - cvsupping the source tree TB --- 2008-12-02 12:13:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-12-02 12:13:44 - building world TB --- 2008-12-02 12:13:44 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 12:13:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 12:13:44 - TARGET=sparc64 TB --- 2008-12-02 12:13:44 - TARGET_ARCH=sparc64 TB --- 2008-12-02 12:13:44 - TZ=UTC TB --- 2008-12-02 12:13:44 - __MAKE_CONF=/dev/null TB --- 2008-12-02 12:13:44 - cd /src TB --- 2008-12-02 12:13:44 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 12:13:46 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_kstack.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_threads.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_vm.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_vm.c: In function 'procstat_vm': /src/usr.bin/procstat/procstat_vm.c:59: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' /src/usr.bin/procstat/procstat_vm.c:60: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 13:26:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 13:26:30 - ERROR: failed to build world TB --- 2008-12-02 13:26:30 - 3446.40 user 333.91 system 4386.67 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Dec 2 05:57:30 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 05:57:44 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081202135726.BE3F873039@freebsd-current.sentex.ca> TB --- 2008-12-02 12:48:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 12:48:31 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-12-02 12:48:31 - cleaning the object tree TB --- 2008-12-02 12:48:38 - cvsupping the source tree TB --- 2008-12-02 12:48:38 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-12-02 12:48:45 - building world TB --- 2008-12-02 12:48:45 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 12:48:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 12:48:45 - TARGET=sun4v TB --- 2008-12-02 12:48:45 - TARGET_ARCH=sparc64 TB --- 2008-12-02 12:48:45 - TZ=UTC TB --- 2008-12-02 12:48:45 - __MAKE_CONF=/dev/null TB --- 2008-12-02 12:48:45 - cd /src TB --- 2008-12-02 12:48:45 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 12:48:46 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_kstack.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_threads.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_vm.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_vm.c: In function 'procstat_vm': /src/usr.bin/procstat/procstat_vm.c:59: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' /src/usr.bin/procstat/procstat_vm.c:60: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 13:57:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 13:57:26 - ERROR: failed to build world TB --- 2008-12-02 13:57:26 - 3447.77 user 332.59 system 4135.09 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From tinderbox at freebsd.org Tue Dec 2 07:01:16 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 07:01:25 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20081202150113.1242B73039@freebsd-current.sentex.ca> TB --- 2008-12-02 14:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 14:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-12-02 14:00:00 - cleaning the object tree TB --- 2008-12-02 14:00:20 - cvsupping the source tree TB --- 2008-12-02 14:00:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-12-02 14:00:29 - building world TB --- 2008-12-02 14:00:29 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 14:00:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 14:00:29 - TARGET=arm TB --- 2008-12-02 14:00:29 - TARGET_ARCH=arm TB --- 2008-12-02 14:00:29 - TZ=UTC TB --- 2008-12-02 14:00:29 - __MAKE_CONF=/dev/null TB --- 2008-12-02 14:00:29 - cd /src TB --- 2008-12-02 14:00:29 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 14:00:33 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_kstack.c cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_threads.c cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_vm.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_vm.c: In function 'procstat_vm': /src/usr.bin/procstat/procstat_vm.c:59: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' /src/usr.bin/procstat/procstat_vm.c:60: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 15:01:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 15:01:12 - ERROR: failed to build world TB --- 2008-12-02 15:01:12 - 2845.97 user 342.51 system 3672.18 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Tue Dec 2 07:17:47 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 07:18:01 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081202151745.1627A73039@freebsd-current.sentex.ca> TB --- 2008-12-02 14:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 14:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-12-02 14:00:00 - cleaning the object tree TB --- 2008-12-02 14:00:24 - cvsupping the source tree TB --- 2008-12-02 14:00:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-12-02 14:00:32 - building world TB --- 2008-12-02 14:00:32 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 14:00:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 14:00:32 - TARGET=amd64 TB --- 2008-12-02 14:00:32 - TARGET_ARCH=amd64 TB --- 2008-12-02 14:00:32 - TZ=UTC TB --- 2008-12-02 14:00:32 - __MAKE_CONF=/dev/null TB --- 2008-12-02 14:00:32 - cd /src TB --- 2008-12-02 14:00:32 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 14:00:35 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_kstack.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_threads.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_vm.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_vm.c: In function 'procstat_vm': /src/usr.bin/procstat/procstat_vm.c:59: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' /src/usr.bin/procstat/procstat_vm.c:60: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 15:17:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 15:17:45 - ERROR: failed to build world TB --- 2008-12-02 15:17:45 - 3597.14 user 359.62 system 4664.35 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Tue Dec 2 08:15:27 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 08:15:34 2008 Subject: [head tinderbox] failure on i386/i386 Message-ID: <20081202161524.AA9BD73039@freebsd-current.sentex.ca> TB --- 2008-12-02 15:01:13 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 15:01:13 - starting HEAD tinderbox run for i386/i386 TB --- 2008-12-02 15:01:13 - cleaning the object tree TB --- 2008-12-02 15:01:36 - cvsupping the source tree TB --- 2008-12-02 15:01:36 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-12-02 15:01:43 - building world TB --- 2008-12-02 15:01:43 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 15:01:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 15:01:43 - TARGET=i386 TB --- 2008-12-02 15:01:43 - TARGET_ARCH=i386 TB --- 2008-12-02 15:01:43 - TZ=UTC TB --- 2008-12-02 15:01:43 - __MAKE_CONF=/dev/null TB --- 2008-12-02 15:01:43 - cd /src TB --- 2008-12-02 15:01:43 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 15:01:44 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_kstack.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_threads.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_vm.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_vm.c: In function 'procstat_vm': /src/usr.bin/procstat/procstat_vm.c:59: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' /src/usr.bin/procstat/procstat_vm.c:60: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 16:15:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 16:15:24 - ERROR: failed to build world TB --- 2008-12-02 16:15:24 - 3535.16 user 339.80 system 4451.22 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From olivier at gid0.org Tue Dec 2 10:31:25 2008 From: olivier at gid0.org (Olivier SMEDTS) Date: Tue Dec 2 10:31:33 2008 Subject: COMPAT_43TTY and MPSAFE tty Message-ID: <367b2c980812021023s3c9f005dwf8092cb56d56db2c@mail.gmail.com> Hello, Is it safe to run a kernel without options COMPAT_43TTY since the new MPSAFE tty layer was introduced ? I removed it from my kernel config file since few days and didn't notice any change... I use nearly latest -CURRENT on amd64 and never tried removing this option before because of the big "KEEP THIS!". Now I don't use any COMPAT_* option. Olivier -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From ed at 80386.nl Tue Dec 2 10:57:20 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue Dec 2 10:57:27 2008 Subject: COMPAT_43TTY and MPSAFE tty In-Reply-To: <367b2c980812021023s3c9f005dwf8092cb56d56db2c@mail.gmail.com> References: <367b2c980812021023s3c9f005dwf8092cb56d56db2c@mail.gmail.com> Message-ID: <20081202185719.GR64969@hoeg.nl> Hello Olivier, * Olivier SMEDTS wrote: > Is it safe to run a kernel without options COMPAT_43TTY since the new > MPSAFE tty layer was introduced ? > I removed it from my kernel config file since few days and didn't > notice any change... > I use nearly latest -CURRENT on amd64 and never tried removing this > option before because of the big "KEEP THIS!". Now I don't use any > COMPAT_* option. If you compiled your applications after June 14, everything should just work (not taking binary-only applications into account). Even if you did not, there is a slim chance your application depends on COMPAT_43TTY. COMPAT_43TTY only introduces some binary-only compatibility interfaces (ioctls) for applications that used . I already removed before I imported MPSAFE TTY: http://www.freebsd.org/cgi/cvsweb.cgi/src/include/Attic/sgtty.h I guess we'd better keep COMPAT_43TTY in our stock kernel configuration files for another couple of years, but maybe we should already remove the "[KEEP THIS!]" message. It's also possible to remove "device pty" from your kernel configuration file. If you remove this line, you can only allocate pts(4)-style pseudo-terminals (/dev/pts/...). This means you cannot allocate any pseudo-terminals inside a FreeBSD 4/5/6/7 jail. I guess we should keep "device pty" a little longer than COMPAT_43TTY, because recompiling applications won't migrate the offending ones to pts(4). -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081202/6791e49c/attachment.pgp From olivier at gid0.org Tue Dec 2 11:05:22 2008 From: olivier at gid0.org (Olivier SMEDTS) Date: Tue Dec 2 11:05:29 2008 Subject: COMPAT_43TTY and MPSAFE tty In-Reply-To: <20081202185719.GR64969@hoeg.nl> References: <367b2c980812021023s3c9f005dwf8092cb56d56db2c@mail.gmail.com> <20081202185719.GR64969@hoeg.nl> Message-ID: <367b2c980812021104h6453799epa210de327a21f54b@mail.gmail.com> 2008/12/2 Ed Schouten : > Hello Olivier, > > * Olivier SMEDTS wrote: >> Is it safe to run a kernel without options COMPAT_43TTY since the new >> MPSAFE tty layer was introduced ? >> I removed it from my kernel config file since few days and didn't >> notice any change... >> I use nearly latest -CURRENT on amd64 and never tried removing this >> option before because of the big "KEEP THIS!". Now I don't use any >> COMPAT_* option. > > If you compiled your applications after June 14, everything should just > work (not taking binary-only applications into account). Even if you did > not, there is a slim chance your application depends on COMPAT_43TTY. > > COMPAT_43TTY only introduces some binary-only compatibility interfaces > (ioctls) for applications that used . I already removed > before I imported MPSAFE TTY: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/include/Attic/sgtty.h > > I guess we'd better keep COMPAT_43TTY in our stock kernel configuration > files for another couple of years, but maybe we should already remove > the "[KEEP THIS!]" message. > > It's also possible to remove "device pty" from your kernel configuration > file. If you remove this line, you can only allocate pts(4)-style > pseudo-terminals (/dev/pts/...). This means you cannot allocate any > pseudo-terminals inside a FreeBSD 4/5/6/7 jail. I guess we should keep > "device pty" a little longer than COMPAT_43TTY, because recompiling > applications won't migrate the offending ones to pts(4). Ok, thanks for the clarification :) Cheers, Olivier -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From peter.schuller at infidyne.com Tue Dec 2 12:33:11 2008 From: peter.schuller at infidyne.com (Peter Schuller) Date: Tue Dec 2 12:33:18 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <20081117205526.GC1733@garage.freebsd.pl> References: <20081117205526.GC1733@garage.freebsd.pl> Message-ID: <20081202203308.GA13818@hyperion.scode.org> I just upgraded my workstation to CURRENT for the purpose of testing ZFS. I wanted to report one anomoly that I have seen so far, that I never saw before and that I do not recognize from other posts. I had ktorrent seemingly hang. The process is in state TL, and does not respond to SIGKILL. SIGCONT also has no effect; neither has SIGSTOP followed by SIGCONT. Though I do not know how ktorrent works internally, the typical behavior, and behavior that I saw just prior to this hang, is one of periodically flushing out a lot of (bittorrent, not file system) blocks. This happens to the point that the pool is more or less saturated for the duration of these bursts (when downloading quickly; around 10 MB/sec in this case). So possibly the triggering factor is quick writing of a lot of randomly located blocks in a handful of files. The current kernel has WITNESS/INVARIATNS, but I did not see anyting in dmesg subsequent or just prior to this hang. Both the pool and the file system seem fully functional; this is distinct from the "hang in zfs state" issue that I see every now and then on 7.0 whereby the affect ZFS file systems will be completely inoperable (but not the entire pool). The sources were cvsup:ed late yesterday. The pool consists of two mirrored vdev:s with one hot spare. The on-disk format is 6 (I have not yet upgrade:d the pool nor any file systems). This is on an amd64 dual-core system with 4 GB:s of RAM. No ZFS related loader variables remain in loader.conf (I let it auto-tune the ARC to around 600 MB). The file system on which ktorrent was doing it's bulk I/O has its recordsize set to 8 kb, but is otherwise standard (no compression or funny options). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081202/3e2d7162/attachment.pgp From peter.schuller at infidyne.com Tue Dec 2 12:35:11 2008 From: peter.schuller at infidyne.com (Peter Schuller) Date: Tue Dec 2 12:35:17 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <20081202203308.GA13818@hyperion.scode.org> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> Message-ID: <20081202203509.GA14126@hyperion.scode.org> > I had ktorrent seemingly hang. The process is in state TL, and does > not respond to SIGKILL. SIGCONT also has no effect; neither has > SIGSTOP followed by SIGCONT. This was the case for something like half an hour before I decided to post. Right after posting (typical) I noticed that the process has now become unstuck and is killed (presumably due to my previous kill -9). No further output in dmesg to indicate what happened. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081202/11674f5b/attachment.pgp From fjwcash at gmail.com Tue Dec 2 13:15:00 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Tue Dec 2 13:15:07 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <20081202203308.GA13818@hyperion.scode.org> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> Message-ID: <200812021254.21242.fjwcash@gmail.com> On December 2, 2008 12:33 pm Peter Schuller wrote: > I just upgraded my workstation to CURRENT for the purpose of testing > ZFS. I wanted to report one anomoly that I have seen so far, that I > never saw before and that I do not recognize from other posts. > > I had ktorrent seemingly hang. The process is in state TL, and does > not respond to SIGKILL. SIGCONT also has no effect; neither has > SIGSTOP followed by SIGCONT. > > Though I do not know how ktorrent works internally, the typical > behavior, and behavior that I saw just prior to this hang, is one of > periodically flushing out a lot of (bittorrent, not file system) > blocks. This happens to the point that the pool is more or less > saturated for the duration of these bursts (when downloading quickly; > around 10 MB/sec in this case). So possibly the triggering factor is > quick writing of a lot of randomly located blocks in a handful of > files. Hrm, I wonder if this is what I'm running into with 7.1-PRERELEASE (Nov 17). I'm running a P4 3.0 GHz system w/2 GB RAM, and 3x 200 GB SATA drives in raidz1 config (/ is on USB flash drive, everything else is on ZFS). I'm also running ktorrent. I've noticed the past couple of days, when using the server (not very often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 minutes (no mouse movement, no keyboard events), while the drives work like crazy. The drives will quiet, and everything will go back to working all nice and snappy. Most noticeable when new torrents start to download (pre- allocate space for new torrents is disabled), or when combined download rate goes above 100 KBps, or combined up/down rate goes above 200 KBps. Unfortunately, when this happens, I can't swith terminals or apps to see what's happening with gstat, zpool stats, vmstat, top, etc. During this "hang" period, network throughput also drops to nil, most noticeable when watching video over Samba/NFS via the laptop in the living room. Movie pauses for up to 2 minutes, then either continues, or the player aborts and starts the next one in the queue. Gets really annoying when it pauses multiple times in a 60-minute video. I figured this was a networking issue, as it only ever affected streaming movies off the server, and have been playing with Samba setting, NFS settings, TCP/IP sysctls, and NIC options on the server and laptop. Never thought to look at ZFS, as it's only been in the last couple days that I noticed the drives working like crazy in burst. Unfortunately, by the time I go from the living room downstairs to the computer room upstairs, things have generally resolved themselves, so I can't say for sure that the pausing video stream is happening at the same time as the drives are working like crazy. loader.conf sets kmem_max to 1 GB, zfs_arc_max to 0.5 GB, and disables ZFS prefetching. All ZFS filesystems have recordsize set to 64 KB; /usr/src and /usr/ports have lzjb compression enabled; all the other filesystems have compression disabled. TCP send and receive buffers are also set to 64 KB. Not sure what to look for, or how to go about debugging this one. Just been living with it. So any and all suggestions, comments, threats, and flames welcomed. :) -- Freddie fjwcash@gmail.com From peter.schuller at infidyne.com Tue Dec 2 15:29:26 2008 From: peter.schuller at infidyne.com (Peter Schuller) Date: Tue Dec 2 15:29:33 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <200812021254.21242.fjwcash@gmail.com> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> Message-ID: <20081202232924.GA19134@hyperion.scode.org> > I've noticed the past couple of days, when using the server (not very > often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 > minutes (no mouse movement, no keyboard events), while the drives work like > crazy. I was not explicit about it, but FWIW in my case the hang is not due to drive saturation. The drives were mostly idle (except some stuff triggered by a buildworld I had going) during the extended period of ktorrent being unkillable. But again I never had this happen pre-CURRENT. > The drives will quiet, and everything will go back to working all > nice and snappy. Most noticeable when new torrents start to download (pre- > allocate space for new torrents is disabled), or when combined download rate > goes above 100 KBps, or combined up/down rate goes above 200 KBps. FWIW I never see any problems at all, even normally, until at least a couple of megabytes (not megabits) per second of throughput. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081202/0f5b6c03/attachment.pgp From jhb at freebsd.org Tue Dec 2 15:30:46 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Dec 2 15:30:54 2008 Subject: [PATCH] Make udf(4) MPSAFE and use shared lookups In-Reply-To: <20081122115028.GB6408@deviant.kiev.zoral.com.ua> References: <200811201627.58289.jhb@freebsd.org> <200811211452.02545.jhb@freebsd.org> <20081122115028.GB6408@deviant.kiev.zoral.com.ua> Message-ID: <200812021828.36857.jhb@freebsd.org> On Saturday 22 November 2008 06:50:28 am Kostik Belousov wrote: > udf_vget() does insmntque() before vnode is fully initialized, allowing > other threads to find the vnode on the mount list. This is typical for > !MPSAFE fs, and it seems corresponding call was not marked XXX for udf. It does the same as ufs. ufs only partially initializes the i-node (as much as both cd9660 and udf do) and then exclusive locks the vnode before insmntque(). They then finish initializing the i-node (bread() the d-node, for example) and finally drop the vnode lock. > udf_lookup for ISDOTDOT case unlocks dvp before vget'ing "..", allowing > the same race on forced unmount as ufs (I will finally commit ufs patch > today). The race happens for !MPSAFE code too, but it is easier to > execute without Giant. Every fs is going to need this workaround it seems. Would be nice if there was an easier way to avoid cut and pasting this code N times. Perhaps we could make lookup() check VI_DOOMED instead? I had changed it do that at one point, but then someone pointed me at the deadfs stuff and said that was sufficient. -- John Baldwin From rizzo at iet.unipi.it Tue Dec 2 16:19:57 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Dec 2 16:20:04 2008 Subject: RFC - two more pending issues for boot0 In-Reply-To: <200812021457.mB2Evmha063418@svn.freebsd.org> References: <200812021457.mB2Evmha063418@svn.freebsd.org> Message-ID: <20081203002446.GA70507@onelab2.iet.unipi.it> It has been brought to my attention that there are two more pending issues for the boot0 code: 1. allow booting from 'DOS Extended' partitions (type 0x5 and 0xf) These partition types are currently in the 'kill list' with no option to override them (other than poking into the bootsector). According to http://www.freebsd.org/cgi/query-pr.cgi?pr=70531 LILO and GRUB _can_ be installed in those partitions so it would make sense to allow them. The change is pretty trivial and safe (boot0 already allows booting from any unknown partition) and one can disable a particular partition using boot0cfg -m This is a trivial change (actually a simplification of the code), so I think it should go in unconditionally. 2. preserve the 'NT Disk UID', claimed to be used in Vista as well. see http://www.freebsd.org/cgi/query-pr.cgi?pr=127764 This change, even though trivial in terms of code, is a bit more intrusive as it requires to move the data area in boot0, and as a consequence requires a patch (though a trivial one) to boot0cfg to let it recognise and manipulate the boot sector. I have implemented this (in a form slightly different from the PR), and it can be conditionally compiled with -DNT_SERIAL , I plan to commit it, but not make it the default. I would like to know how useful people consider this feature. cheers luigi From maksim.yevmenkin at gmail.com Tue Dec 2 17:01:15 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue Dec 2 17:01:22 2008 Subject: RFC: small syscons and kbd patch Message-ID: Dear Hackers, can someone please review the attached small patch for syscons and kbd? it should be a no-op mostly. the patch basically does 1) removes bogus layering in syscons, i.e. basically removes sccngetch(); 2) implements advisory lock for kbd (based on atomic(9)); 3) implements new POLLED flag for kbd; this is a part of a plan to fix keyboard access races in syscons. thanks, max -------------- next part -------------- Index: sys/dev/syscons/syscons.c =================================================================== --- sys/dev/syscons/syscons.c (revision 185319) +++ sys/dev/syscons/syscons.c (working copy) @@ -179,7 +179,6 @@ static u_int scgetc(sc_softc_t *sc, u_int flags); #define SCGETC_CN 1 #define SCGETC_NONBLOCK 2 -static int sccngetch(int flags); static void sccnupdate(scr_stat *scp); static scr_stat *alloc_scp(sc_softc_t *sc, int vty); static void init_scp(sc_softc_t *sc, int vty, scr_stat *scp); @@ -1558,12 +1557,6 @@ static int sc_cngetc(struct consdev *cd) { - return sccngetch(SCGETC_NONBLOCK); -} - -static int -sccngetch(int flags) -{ static struct fkeytab fkey; static int fkeycp; scr_stat *scp; @@ -1604,7 +1597,7 @@ kbdd_ioctl(scp->sc->kbd, KDSKBMODE, (caddr_t)&scp->kbd_mode); kbdd_poll(scp->sc->kbd, TRUE); - c = scgetc(scp->sc, SCGETC_CN | flags); + c = scgetc(scp->sc, SCGETC_CN | SCGETC_NONBLOCK); kbdd_poll(scp->sc->kbd, FALSE); scp->kbd_mode = cur_mode; Index: sys/dev/kbd/kbd.c =================================================================== --- sys/dev/kbd/kbd.c (revision 185319) +++ sys/dev/kbd/kbd.c (working copy) @@ -1102,6 +1102,12 @@ } } +int +genkbd_lock(keyboard_t *kbd, int on) +{ + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); +} + #define set_lockkey_state(k, s, l) \ if (!((s) & l ## DOWN)) { \ int i; \ Index: sys/dev/kbd/kbdreg.h =================================================================== --- sys/dev/kbd/kbdreg.h (revision 185319) +++ sys/dev/kbd/kbdreg.h (working copy) @@ -60,7 +60,9 @@ #define KB_INITIALIZED (1 << 19) /* device initialized */ #define KB_REGISTERED (1 << 20) /* device registered to kbdio */ #define KB_BUSY (1 << 21) /* device used by a client */ +#define KB_POLLED (1 << 22) /* device is in polled mode */ int kb_active; /* 0: inactive */ + int kb_locked; /* 0: unlocked */ void *kb_token; /* id of the current client */ keyboard_callback_t kb_callback;/* callback function */ @@ -107,6 +109,9 @@ #define KBD_IS_BUSY(k) ((k)->kb_flags & KB_BUSY) #define KBD_BUSY(k) ((k)->kb_flags |= KB_BUSY) #define KBD_UNBUSY(k) ((k)->kb_flags &= ~KB_BUSY) +#define KBD_IS_POLLED(k) ((k)->kb_flags & KB_POLLED) +#define KBD_POLLED(k) ((k)->kb_flags |= KB_POLLED) +#define KBD_UNPOLLED(k) ((k)->kb_flags &= ~KB_POLLED) #define KBD_IS_ACTIVE(k) ((k)->kb_active) #define KBD_ACTIVATE(k) (++(k)->kb_active) #define KBD_DEACTIVATE(k) (--(k)->kb_active) @@ -170,7 +175,7 @@ (*kbdsw[(kbd)->kb_index]->intr)((kbd), (arg)) #define kbdd_test_if(kbd) \ (*kbdsw[(kbd)->kb_index]->test_if)((kbd)) -#define kbdd_enable(kbd) \ +#define kbdd_enable(kbd) \ (*kbdsw[(kbd)->kb_index]->enable)((kbd)) #define kbdd_disable(kbd) \ (*kbdsw[(kbd)->kb_index]->disable)((kbd)) @@ -194,7 +199,7 @@ (*kbdsw[(kbd)->kb_index]->get_state)((kbd), (buf), (len)) #define kbdd_set_state(kbd, buf, len) \ (*kbdsw[(kbd)->kb_index]->set_state)((kbd), (buf), (len)) -#define kbdd_get_fkeystr(kbd, fkey, len) \ +#define kbdd_get_fkeystr(kbd, fkey, len) \ (*kbdsw[(kbd)->kb_index]->get_fkeystr)((kbd), (fkey), (len)) #define kbdd_poll(kbd, on) \ (*kbdsw[(kbd)->kb_index]->poll)((kbd), (on)) @@ -293,6 +298,7 @@ kbd_get_fkeystr_t genkbd_get_fkeystr; kbd_diag_t genkbd_diag; +kbd_lock_t genkbd_lock; int genkbd_commonioctl(keyboard_t *kbd, u_long cmd, caddr_t arg); int genkbd_keyaction(keyboard_t *kbd, int keycode, int up, From alexus at gmail.com Tue Dec 2 18:31:26 2008 From: alexus at gmail.com (alexus) Date: Tue Dec 2 19:17:53 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> Message-ID: <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> as far as I understood HEAD is 8.0-CURRENT is there a way for us to start using it before 8.0 hits -RELEASE which according to freebsd.org will be in june 2009, which we all know how accured their schedule is, so, my guess is very well Q4 of 2009 (if we lucky), I somehow was under impression (and i guess i was wrong) that it will come out in 7.1, I have a server that needs to be migrated and really doing so without multi ip patch will be a really big ......... -- http://alexus.org/ From conrads at cox.net Tue Dec 2 20:06:45 2008 From: conrads at cox.net (Conrad J. Sabatier) Date: Tue Dec 2 20:06:52 2008 Subject: i give up In-Reply-To: <4930D7CE.4080909@psg.com> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> Message-ID: <20081202220643.72eb52a3@serene.no-ip.org> On Sat, 29 Nov 2008 14:49:02 +0900 Randy Bush wrote: > what a tragic story. and zero technical info, like even what your > controller is. best of luck in penguin land. bye! > > randy No, actually, I forwarded to Soren all the information I could glean from Windows Vista, Linux and FreeBSD (which I managed to install on an external USB drive). I also applied the patches he sent me, which failed to cure the problem, and have been monitoring the mailing lists and CVS repo for any signs of progress, but so far I've seen nothing. If I were more technically adept in the realm of hardware drivers and low-level system programming, I'd gladly help out. I did, in fact, ask Soren if there was anything else I could do to help, but was met with absolute silence. Believe me, I'm none too eager to have to forsake FreeBSD for the land of the penguin, after 12+ years of happily using FreeBSD, and even contributing where I could, in the areas of port maintenance and sharing my accumulated knowledge in the mailing lists. It's more than a little saddening to me that little or no attention has been paid to this problem, leaving me no choice but to seek another platform capable of managing all of my hardware. So, what can I say, other than that it's been a great 12 years, and I will sadly miss continuing to be an active member of the FreeBSD community, your flippant response notwithstanding. Perhaps if you'd been following the lists more closely over the last several months, you'd have realized that this was not my first post on this subject, although it will probably be the last. I'd certainly love it if I were proven wrong and a solution to my problem was indeed forthcoming, but given the utter silence and neglect I've been seeing, I'm not holding out any great hopes. Best wishes to the FreeBSD community. No hard feelings, and I will still continue to checkout the latest sources from time to time just on the outside chance that a solution will eventually be found. Sincerest regards from a long-time FreeBSD user now in exile. :-( -- Conrad J. Sabatier From m.k12015 at gmail.com Tue Dec 2 21:10:32 2008 From: m.k12015 at gmail.com (k m) Date: Tue Dec 2 21:10:40 2008 Subject: ASUS Eee PC S101 Message-ID: <870d2e5a0812022051q2007b46eq4fd2115f76f3e5d6@mail.gmail.com> Hi, I bought ASUS Eee PC S101 (http://eeepc.asus.com/global/products101.html), and installed the recent CURRENT according to the information at http://wiki.freebsd.org/AsusEee . It basically works. Atheros L1 FastEthernet: (it works) It basically works. But, I met the same situation as mentioned in the recent mail(http://lists.freebsd.org/pipermail/freebsd-current/2008-December/000871.html). It had happened when I mounted nfs of ports tree and did 'make instlall' for some ports. It made everything very slow, but everything worked. For example, I could log in from the other machine by ssh. Wireless lan: (it doesn't work) % pciconf -l -v ... none1@pci0:1:0:0: class=0x028000 card=0x10671a3b chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' class = network It looks it is not supported yet. (see http://lists.freebsd.org/pipermail/freebsd-net/2008-September/019563.html) I'm waiting for new driver ;-) Suspend/resume: (it doesn't work) According to the wiki, I have set hw.acpi.reset_video=1 in /etc/sysctl.conf. And 'acpiconf -s3' makes the machine be suspended. After the resuming by the power button, my eee hanged up with the following kernel message; acpi_acad0: unknown notify 0x81 ale0: 2 link states coalesced ad0: FAILURE - SET_MULTI status=51 error=4 Touchpad (synaptics): (it probably works) X and KDE 4.1 work without moused. I declared moused="NO" in /etc/rc.conf. According to the wiki, to use suspend/resume, I need to set hw.psm.synaptics_support=1 and write the additional configuration in xorg.conf. Although suspend/resume has problem, I did. But, % sysctl hw.psm.synaptics_support sysctl: unknown oid 'hw.psm.synaptics_support' and, % ps ax | grep mouse 954 ?? S 0:00.82 hald-addon-mouse-sysmouse: /dev/psm0 (hald-addon-mous I'm wondering who works with my touchpad. Is it good for me? Although it did not fully function, it is a beautiful machine. I liked it very much. best regards m.k. dmesg: Copyright (c) 1992-2008 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 8.0-CURRENT #3: Mon Dec 1 08:38:28 JST 2008 xxxxxxxx@thebe.xxxxx.xxx:/usr/obj/usr/src/sys/ARTEMIS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1600.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d> AMD Features=0x100000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 1064960000 (1015 MB) avail memory = 1028812800 (981 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.10.5.10 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3f700000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xdc80-0xdc87 mem 0xfbd00000-0xfbd7ffff,0xd0000000-0xdfffffff,0xfbcc0000-0xfbcfffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfbd80000-0xfbdfffff at device 2.1 on pci0 hdac0: mem 0xfbcb8000-0xfbcbbfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20081123_0118 hdac0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 ale0: port 0xec80-0xecff mem 0xfbfc0000-0xfbffffff irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. miibus0: on ale0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto ale0: Ethernet address: 00:23:54:7e:2b:79 ale0: [FILTER] pcib3: irq 18 at device 28.2 on pci0 pci1: on pcib3 pci1: at device 0.0 (no driver attached) uhci0: port 0xd480-0xd49f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd800-0xd81f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd880-0xd89f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xdc00-0xdc1f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfbcb7c00-0xfbcb7fff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered ugen0: on uhub4 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_asus0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 60f0c2706000c27 device_attach: est1 attach returned 6 p4tcc1: on cpu1 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. ugen1: on uhub3 Timecounters tick every 10.000 msec ad0: FAILURE - SET_MULTI status=51 error=4 ad0: 15392MB at ata0-master SATA150 hdac0: HDA Codec #0: Realtek ALC269 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a ale0: link state changed to UP From matthias.andree at gmx.de Tue Dec 2 21:23:45 2008 From: matthias.andree at gmx.de (Matthias Andree) Date: Tue Dec 2 21:23:52 2008 Subject: i give up In-Reply-To: <20081202220643.72eb52a3@serene.no-ip.org> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> Message-ID: <4936119A.6020905@gmx.de> Conrad J. Sabatier schrieb: > No, actually, I forwarded to Soren all the information I could glean > from Windows Vista, Linux and FreeBSD (which I managed to install on an > external USB drive). I also applied the patches he sent me, which > failed to cure the problem, and have been monitoring the mailing lists > and CVS repo for any signs of progress, but so far I've seen nothing. Seems Soeren is busy with family and real life, with contributions that are far between but usually high quality... OTOH, > So, what can I say, other than that it's been a great 12 years, and I > will sadly miss continuing to be an active member of the FreeBSD > community, your flippant response notwithstanding. Perhaps if you'd > been following the lists more closely over the last several months, > you'd have realized that this was not my first post on this subject, > although it will probably be the last. I'd certainly love it if I were > proven wrong and a solution to my problem was indeed forthcoming, but > given the utter silence and neglect I've been seeing, I'm not holding > out any great hopes. ...I've seen this deafening silence with Linux, too, with various distros: I've tried SuSE/openSUSE and Ubuntu, and there are outright showstopper bugs that have been unfixed for months, if not years. If it runs somedistro Version X.Y, you can never be sure that X.(Y+2) causes no regressions -- I've seen that happen with clock drivers, a pet peeve of mine: cause erratic clock behaviour that ntpd cannot correct. Error handling in drivers is often a game of luck with Linux... it's always a compromise, aka "choose your poison". I don't feel tied to any of the communities, but hop here and there, since then having to cut ties doesn't hurt if there is nothing to cut :-) At least, Linux desktop experience in graphical surfaces is "feels more responsive" for me... Take care -- Matthias Andree From rink at FreeBSD.org Tue Dec 2 23:36:23 2008 From: rink at FreeBSD.org (Rink Springer) Date: Tue Dec 2 23:36:31 2008 Subject: RFC - two more pending issues for boot0 In-Reply-To: <20081203002446.GA70507@onelab2.iet.unipi.it> References: <200812021457.mB2Evmha063418@svn.freebsd.org> <20081203002446.GA70507@onelab2.iet.unipi.it> Message-ID: <20081203073659.GA38628@rink.nu> Hi Luigi, On Wed, Dec 03, 2008 at 01:24:46AM +0100, Luigi Rizzo wrote: > 1. allow booting from 'DOS Extended' partitions (type 0x5 and 0xf) > These partition types are currently in the 'kill list' with no > option to override them (other than poking into the bootsector). This looks OK to me. > 2. preserve the 'NT Disk UID', claimed to be used in Vista as well. > > see http://www.freebsd.org/cgi/query-pr.cgi?pr=127764 > > This change, even though trivial in terms of code, is a bit more > intrusive as it requires to move the data area in boot0, and > as a consequence requires a patch (though a trivial one) to > boot0cfg to let it recognise and manipulate the boot sector. > > I have implemented this (in a form slightly different from the PR), > and it can be conditionally compiled with -DNT_SERIAL , > I plan to commit it, but not make it the default. > > I would like to know how useful people consider this feature. I'd say this is something we definitely should have, and by default. I've been bitten too much by BSD happily nuking my Vista-infested MBR, and the more we can do to prevent it, the better - I'm pretty sure this holds for J. Random User too. -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From stas at FreeBSD.org Wed Dec 3 00:55:46 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Dec 3 00:55:52 2008 Subject: ASUS Eee PC S101 In-Reply-To: <870d2e5a0812022051q2007b46eq4fd2115f76f3e5d6@mail.gmail.com> References: <870d2e5a0812022051q2007b46eq4fd2115f76f3e5d6@mail.gmail.com> Message-ID: <20081203110844.96cc9d0a.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 3 Dec 2008 13:51:54 +0900 "k m" mentioned: > Touchpad (synaptics): (it probably works) > X and KDE 4.1 work without moused. I declared moused="NO" in > /etc/rc.conf. According to the wiki, to use suspend/resume, I need to > set hw.psm.synaptics_support=1 and write the additional configuration > in xorg.conf. Although suspend/resume has problem, I did. But, > > % sysctl hw.psm.synaptics_support > sysctl: unknown oid 'hw.psm.synaptics_support' > This is not a sysctl variable, but kenv one. It should be set via /boot/loader.conf. Thanks for your information, I added it to the wiki. Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkk2PpEACgkQK/VZk+smlYE+8gCggn8KGzAAYJXbdjfjFw2XzP5e SEsAn0i/G9V2CmCxmvu9lrDXOJcTL1sj =J2jk -----END PGP SIGNATURE----- From pyunyh at gmail.com Wed Dec 3 01:03:33 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Dec 3 01:03:40 2008 Subject: ASUS Eee PC S101 In-Reply-To: <870d2e5a0812022051q2007b46eq4fd2115f76f3e5d6@mail.gmail.com> References: <870d2e5a0812022051q2007b46eq4fd2115f76f3e5d6@mail.gmail.com> Message-ID: <20081203090322.GH9639@cdnetworks.co.kr> On Wed, Dec 03, 2008 at 01:51:54PM +0900, k m wrote: > Hi, > > I bought ASUS Eee PC S101 > (http://eeepc.asus.com/global/products101.html), and installed the > recent CURRENT according to the information at > http://wiki.freebsd.org/AsusEee . It basically works. > > > Atheros L1 FastEthernet: (it works) > It basically works. But, I met the same situation as mentioned in the > recent mail(http://lists.freebsd.org/pipermail/freebsd-current/2008-December/000871.html). > It had happened when I mounted nfs of ports tree and did 'make > instlall' for some ports. It made everything very slow, but everything I've committed fix to HEAD(r185577). Copy ale(4) from HEAD and try again. -- Regards, Pyun YongHyeon From pyunyh at gmail.com Wed Dec 3 01:05:48 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Dec 3 01:05:58 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <20081124045846.GM78954@cdnetworks.co.kr> References: <46d45f030811160642m2dff1481g457f1fa1a4ac1372@mail.gmail.com> <20081117010558.GD50872@cdnetworks.co.kr> <46d45f030811171014i2ae5df78mbbebc367ef2ca7d4@mail.gmail.com> <20081124045846.GM78954@cdnetworks.co.kr> Message-ID: <20081203090540.GI9639@cdnetworks.co.kr> On Mon, Nov 24, 2008 at 01:58:46PM +0900, To albri wrote: > On Mon, Nov 17, 2008 at 07:14:12PM +0100, albri wrote: > > hello, > > > > On 11/17/08, Pyun YongHyeon wrote: > > > On Sun, Nov 16, 2008 at 03:42:16PM +0100, albri wrote: > > > > hello, > > > > > > > > I have issues transfering big or many files over ethernet on 1000H, also. > > > > Using yongari's ale(4) driver > > > > http://people.freebsd.org/~yongari/ale/ale.20081114.tar.gz I did not > > > > have any problems while I surf or download 37MB sourcecode from inet. > > > > Then scp(1)'ing source from 1000H to desktop PC showed a transfer rate > > > > with maximum 86kB/s regardless to which direction is copied. The > > > > ethernet NIC, while copying, is switched off regularily then. No > > > > copies possible after three megabytes. > > > > > > Try turning off TSO and let me know how it goes. > > > ("#ifconfig ale0 -tso" will do the job.) > > > > > > > this helps a little bit with two effects. > > Copying source-tree with scp(1): > > Now I can see transfers with up to approx. 500kB/s - inaccurate > > measured with scp(1), > > but relation counts. > > Transfer stalles after different data volumes with DMA-error on tty0, > > but networking > > port is not turned off. This happens after 30-80MB data transfers. > > You can restart the whole copy at once again. > > > > Copying source-tree with nc(1) tar-gzipped: > > Transfer stops and starts with DMA-error every approx. 7MB with turning off NIC. > > I still can't reproduce this and I have no idea how to solve it > even if I can reproduce that on my box. :-( > There could be a wrong in DMA configuration or some mis-programmed > registers but I still see no errors in these area. > FYI: Fix committed to HEAD(r185577). -- Regards, Pyun YongHyeon From pyunyh at gmail.com Wed Dec 3 01:07:08 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Dec 3 01:07:15 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <20081105013558.GA99795@cdnetworks.co.kr> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> Message-ID: <20081203090658.GJ9639@cdnetworks.co.kr> On Wed, Nov 05, 2008 at 10:35:58AM +0900, To Jan Henrik Sylvester wrote: > On Tue, Nov 04, 2008 at 10:36:21PM +0100, Jan Henrik Sylvester wrote: > > Pyun YongHyeon wrote: > > >On Mon, Nov 03, 2008 at 07:49:34PM +0100, Jan Henrik Sylvester wrote: > > > > >Pyun YongHyeon writes: > > > > >> http://people.freebsd.org/~yongari/ale/if_ale.c > > > > > > > > I got an Eee PC 1000H, too, with 7.1-BETA2 and just used scp to copy > > > > with 11.5MB/s -- much better than wlan for big files. Great! > > > > > > > > > >Thanks for testing! > > > > I was happy too early. Now I keep getting these: > > ale0: DMA read error! -- resetting > > ale0: could not disable Tx/Rx MAC(0x00000008)! > FYI: Fix committed to HEAD(r185577). -- Regards, Pyun YongHyeon From pyunyh at gmail.com Wed Dec 3 01:57:48 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Dec 3 01:57:55 2008 Subject: ale driver on asus eeepc 901 could not disable Tx/Rx under traffic flow In-Reply-To: <20081202012237.GB5306@cdnetworks.co.kr> References: <200812020102.04504.subbsd@gmail.com> <20081202012237.GB5306@cdnetworks.co.kr> Message-ID: <20081203095739.GK9639@cdnetworks.co.kr> On Tue, Dec 02, 2008 at 10:22:37AM +0900, To Ole Vole wrote: > On Tue, Dec 02, 2008 at 01:02:04AM +0300, Ole Vole wrote: > > Hello Maillist, > > > > Im using FreeBSD-CURRENT (from 01122008 snap from cvs) and got looped notice > > in dmesg buffer when LAN Ethernet generate some traffic: > > .. > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > ale0: DMA read error! -- resetting > > .. > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > .. > > with flapping interface (link going to down and back up). > > > > Hmm, there was similiar report but I couldn't reproduce this on > my box. In fact I'm out of idea why it happens. Since I have no > access to datasheet I'm not sure what can be done at the moment. > Even a developer in Atheros answered that changing mainboard would > be the first step to diagnose the issue. :-( > > > ifconfig ale0 -txcsum -rxcsum -tso and forcing link for media 10BaseT/UTP is > > in vain. > > > > There are a couple of magic values related with PHY in Linux driver > which I didn't want to include as I don't understand what it does. > Do you use 10baseT media? Would you show me the output of > "ifconfig ale0"? > > > Under small traffic flow ale0 work is fine without errors. Somebody meet with > > like similar prombel on Asus eee pc 901 ? Thanks > > > Anyway, I'll let you know if I mange to find a clue to the issue. FYI: Fix committed to HEAD(r185577). -- Regards, Pyun YongHyeon From kostikbel at gmail.com Wed Dec 3 04:41:43 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Dec 3 04:41:50 2008 Subject: [PATCH] Make udf(4) MPSAFE and use shared lookups In-Reply-To: <200812021828.36857.jhb@freebsd.org> References: <200811201627.58289.jhb@freebsd.org> <200811211452.02545.jhb@freebsd.org> <20081122115028.GB6408@deviant.kiev.zoral.com.ua> <200812021828.36857.jhb@freebsd.org> Message-ID: <20081203124137.GE3045@deviant.kiev.zoral.com.ua> On Tue, Dec 02, 2008 at 06:28:36PM -0500, John Baldwin wrote: > On Saturday 22 November 2008 06:50:28 am Kostik Belousov wrote: > > udf_vget() does insmntque() before vnode is fully initialized, allowing > > other threads to find the vnode on the mount list. This is typical for > > !MPSAFE fs, and it seems corresponding call was not marked XXX for udf. > > It does the same as ufs. ufs only partially initializes the i-node (as much > as both cd9660 and udf do) and then exclusive locks the vnode before > insmntque(). They then finish initializing the i-node (bread() the d-node, > for example) and finally drop the vnode lock. My bad, unjustified grumbling. > > > udf_lookup for ISDOTDOT case unlocks dvp before vget'ing "..", allowing > > the same race on forced unmount as ufs (I will finally commit ufs patch > > today). The race happens for !MPSAFE code too, but it is easier to > > execute without Giant. > > Every fs is going to need this workaround it seems. Would be nice if there > was an easier way to avoid cut and pasting this code N times. Perhaps we > could make lookup() check VI_DOOMED instead? I had changed it do that at one > point, but then someone pointed me at the deadfs stuff and said that was > sufficient. The point of the patch is busying mp while parent vnode is locked, that guarantees that mp is not unmounted during whole DOTDOT traversing in vop_lookup(). The deadfs stuff works for lookup result vnode and is sufficient. The fragment that someone committed into UFS can be extracted into the vfs support routine. I doubt that it can be embedded into lookup(). The problem is that some filesystems do additional operations inside vop_lookup(). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081203/1a99bc56/attachment.pgp From cpghost at cordula.ws Wed Dec 3 07:29:27 2008 From: cpghost at cordula.ws (cpghost) Date: Wed Dec 3 07:29:34 2008 Subject: i give up In-Reply-To: <20081202220643.72eb52a3@serene.no-ip.org> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> Message-ID: <20081203151537.GA1045@phenom.cordula.ws> On Tue, Dec 02, 2008 at 10:06:43PM -0600, Conrad J. Sabatier wrote: > Best wishes to the FreeBSD community. No hard feelings, and I will > still continue to checkout the latest sources from time to time just on > the outside chance that a solution will eventually be found. > > Sincerest regards from a long-time FreeBSD user now in exile. :-( Changing the OS just because one specific piece of swappable and replaceable hardware isn't supported... isn't that overreacting a little bit? Can't you circumvent your specific problem by adding a supported adapter to your system(s)... at least until the issue is fixed? As sysadmins, we do this all the time, wether with Linux or FreeBSD. I feel your pain, but maybe you've built up quite a bit of frustration over this specific issue and need a little hiatus. I hope you'll come back soon. > Conrad J. Sabatier -cpghost. -- Cordula's Web. http://www.cordula.ws/ From ken at mthelicon.com Wed Dec 3 08:03:04 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Wed Dec 3 08:03:10 2008 Subject: i give up In-Reply-To: <20081203151537.GA1045@phenom.cordula.ws> References: <20081128234155.0221e263@serene.no-ip.org><4930D7CE.4080909@psg.com><20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> Message-ID: ----- Original Message ----- From: "cpghost" To: "Conrad J. Sabatier" Cc: Sent: Wednesday, December 03, 2008 3:15 PM Subject: Re: i give up > On Tue, Dec 02, 2008 at 10:06:43PM -0600, Conrad J. Sabatier wrote: >> Best wishes to the FreeBSD community. No hard feelings, and I will >> still continue to checkout the latest sources from time to time just on >> the outside chance that a solution will eventually be found. >> >> Sincerest regards from a long-time FreeBSD user now in exile. :-( > > Changing the OS just because one specific piece of swappable and > replaceable hardware isn't supported... isn't that overreacting a > little bit? Can't you circumvent your specific problem by adding a > supported adapter to your system(s)... at least until the issue is > fixed? As sysadmins, we do this all the time, wether with Linux or > FreeBSD. > > I feel your pain, but maybe you've built up quite a bit of frustration > over this specific issue and need a little hiatus. > > I hope you'll come back soon. > >> Conrad J. Sabatier > > -cpghost. I have also had the same problem as Conrad with the nVidia drivers. I think the most fustrating thing about my situation is that I have not found a supported PCI-e card that there exists 2D acceleration / opengl drivers. At the moment I have shoved in a ATI Radeon HD and keep checking the developers webpage for the glorious day they finish the piece for my chip-set (Its still not 2D accelerated, but atleast it still works). In my situation, there are no computer stores that I can go into and say, "Hey.. I would like a PCI-e Intel based video card." I have to pick up pieces of hardware where it is convient and this means usually at the bleading edge of video-gamers "marketable" choice (ATI or nVidia). -Peg -Peg From frode at nordahl.net Wed Dec 3 09:23:32 2008 From: frode at nordahl.net (Frode Nordahl) Date: Wed Dec 3 09:23:41 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't Message-ID: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> Hello, I have a server with FreeBSD 7.1-PRERELEASE-p1 amd64 on it. Upgraded from a 7.0-RELEASE system using freebsd-update. It's a DELL PE2950 with E5420 Quad Core 2.50GHz processor, 4 GB RAM, using DELL PERC 6 RAID card (mfi0). The system is running a custom kernel to get quota support. During some tests which involved removing a large number of files simultaneously (ran 20+ copies of rm -rf), it paniced with this message: dqget: free dquot isn't Output from DDB, kernel config and dmesg is attached. I also secured a crashdump, so further queries using kgdb is possible. -- Frode Nordahl -------------- next part -------------- db> where Tracing pid 41111 tid 100199 td 0xffffff0056f1f370 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x17b dqget() at dqget+0xaa4 getinoquota() at getinoquota+0x5b ufs_access() at ufs_access+0x28c ufs_lookup() at ufs_lookup+0x9fe vfs_cache_lookup() at vfs_cache_lookup+0xf8 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 lookup() at lookup+0x531 namei() at namei+0x35d kern_rmdir() at kern_rmdir+0xbd syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (137, FreeBSD ELF64, rmdir), rip = 0x800686d3c, rsp = 0x7fffffffeb98, rbp = 0x602400 --- db> ps pid ppid pgrp uid state wmesg wchan cmd 41220 40666 41220 0 S+ biord 0xffffffff9a321520 rm 41119 40666 41119 0 S+ biord 0xffffffff9a77aea0 rm 41118 40666 41118 0 S+ biord 0xffffffff9a4f8e20 rm 41117 40666 41117 0 S+ biord 0xffffffff9a503fa0 rm 41115 40666 41115 0 S+ biord 0xffffffff9a3c58a0 rm 41114 40666 41114 0 S+ biord 0xffffffff9a745520 rm 41113 40666 41113 0 S+ biord 0xffffffff9a4b0120 rm 41112 40666 41112 0 S+ biord 0xffffffff9a3d3c20 rm 41111 40666 41111 0 R+ CPU 1 rm 41110 40666 41110 0 S+ biord 0xffffffff9a259020 rm 41109 40666 41109 0 S+ biord 0xffffffff9a0dda20 rm 41108 40666 41108 0 S+ biord 0xffffffff9a5a0da0 rm 41107 40666 41107 0 S+ biord 0xffffffff9a5b4da0 rm 41106 40666 41106 0 S+ biord 0xffffffff9a29dc20 rm 41104 40666 41104 0 S+ biord 0xffffffff9a58d7a0 rm 41103 40666 41103 0 S+ biord 0xffffffff9a1dd6a0 rm 41102 40666 41102 0 S+ biord 0xffffffff9a04cf20 rm 41101 40666 41101 0 S+ biord 0xffffffff9a3a7da0 rm 41100 40666 41100 0 S+ biord 0xffffffff9a169a20 rm 40929 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40928 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40927 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40926 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40925 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40924 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40923 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40922 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40921 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40920 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40919 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40918 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40917 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40916 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40915 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40914 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40913 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40912 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40911 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40910 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40909 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40908 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40907 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40906 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40905 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40904 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40903 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40902 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40901 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40900 40891 40891 58 S select 0xffffffff80af2910 perl5.8.8 40891 1 40891 0 Ss select 0xffffffff80af2910 perl5.8.8 40754 40751 40754 0 Ss+ ttyin 0xffffff0003740010 bash 40751 892 40751 0 Ss select 0xffffffff80af2910 sshd 40666 40663 40666 0 Ss+ wait 0xffffff0003ee78f0 bash 40663 892 40663 0 Ss select 0xffffffff80af2910 sshd 40613 34783 34783 125 S kqread 0xffffff005795c100 pickup 35540 34783 34783 125 S kqread 0xffffff005bc7b700 qmgr 34783 1 34783 0 Ss kqread 0xffffff0076102e00 master 34615 1 34615 389 Ss (threaded) slapd 100291 S ucond 0xffffff000381e000 slapd 100290 S ucond 0xffffff0012f4f300 slapd 100289 S ucond 0xffffff00129b0280 slapd 100288 S ucond 0xffffff0012ec9000 slapd 100287 S ucond 0xffffff0012cfa800 slapd 100286 S ucond 0xffffff00210eb200 slapd 100285 S ucond 0xffffff0003cb8880 slapd 100284 S ucond 0xffffff0021451e00 slapd 100283 S ucond 0xffffff00210ebc80 slapd 100281 S select 0xffffffff80af2910 slapd 100074 S uwait 0xffffff00037c7000 slapd 34297 34277 34276 88 S+ (threaded) mysqld 100279 S sigwait 0xffffffffb4c39a58 mysqld 100276 S ucond 0xffffff0012315d00 mysqld 100278 S select 0xffffffff80af2910 mysqld 100277 S select 0xffffffff80af2910 mysqld 100275 S ucond 0xffffff0012aae400 mysqld 100221 S ucond 0xffffff0021451300 mysqld 100220 S ucond 0xffffff0012b29a00 mysqld 100218 S ucond 0xffffff0003cbed00 mysqld 100065 S select 0xffffffff80af2910 initial thread 34277 1 34276 88 S+ wait 0xffffff0076c6b000 sh 960 958 960 0 Ss+ ttyin 0xffffff000141a810 bash 958 1 958 0 Ss select 0xffffffff80af2910 screen 950 1 950 0 Ss+ ttyin 0xffffff0003700810 getty 949 1 949 0 Ss+ ttyin 0xffffff000372b410 getty 948 1 948 0 Ss+ ttyin 0xffffff000372b810 getty 947 1 947 0 Ss+ ttyin 0xffffff0003721c10 getty 946 1 946 0 Ss+ ttyin 0xffffff0003721810 getty 945 1 945 0 Ss+ ttyin 0xffffff000372c010 getty 944 1 944 0 Ss+ ttyin 0xffffff000372d010 getty 943 1 943 0 Ss+ ttyin 0xffffff000372d410 getty 942 1 942 0 Ss+ ttyin 0xffffff000372c810 getty 936 1 936 0 Ss select 0xffffffff80af2910 bsnmpd 922 1 922 0 Ss select 0xffffffff80af2910 inetd 899 1 899 0 Ss nanslp 0xffffffff80add5a8 cron 892 1 892 0 Ss select 0xffffffff80af2910 sshd 851 1 851 181 Ss select 0xffffffff80af2910 nrpe2 755 1 755 106 Ss pause 0xffffff0003b139b0 freshclam 750 1 750 106 Ss (threaded) clamd 100294 S ucond 0xffffff0012282500 clamd 100293 S ucond 0xffffff005283e700 clamd 100292 S ucond 0xffffff005283e800 clamd 100282 S ucond 0xffffff005283e880 clamd 100280 S ucond 0xffffff0012ec6800 clamd 100219 S ucond 0xffffff0012d54680 clamd 100102 S accept 0xffffff0003d2e5fe clamd 720 1 720 0 Ss select 0xffffffff80af2910 ntpd 630 1 630 53 Ss (threaded) named 100114 S select 0xffffffff80af2910 named 100113 S ucond 0xffffff00038dab80 named 100112 S ucond 0xffffff0003b9ea00 named 100111 S ucond 0xffffff0003b9e980 named 100110 S ucond 0xffffff000391db80 named 100109 S ucond 0xffffff000391db00 named 100077 S sigwait 0xffffffffb483da58 named 531 1 531 0 Ss select 0xffffffff80af2910 syslogd 468 1 468 0 Ss select 0xffffffff80af2910 devd 48 0 0 0 SL biord 0xffffffff9a036ea0 [softdepflush] 47 0 0 0 SL vlruwt 0xffffff00037358f0 [vnlru] 46 0 0 0 SL ufs 0xffffff0012b52098 [syncer] 45 0 0 0 SL psleep 0xffffffff80af315c [bufdaemon] 44 0 0 0 SL pgzero 0xffffffff80b05064 [pagezero] 43 0 0 0 SL psleep 0xffffffff80b043a8 [vmdaemon] 42 0 0 0 SL psleep 0xffffffff80b0436c [pagedaemon] 41 0 0 0 SL waiting_ 0xffffffff80af6898 [sctp_iterator] 40 0 0 0 WL [irq1: atkbd0] 39 0 0 0 WL [swi0: sio] 38 0 0 0 WL [irq15: ata1] 37 0 0 0 WL [irq14: ata0] 36 0 0 0 SL usbevt 0xffffff00012b5420 [usb4] 35 0 0 0 SL usbevt 0xffffffff80e4d420 [usb3] 34 0 0 0 SL usbevt 0xffffffff80e4b420 [usb2] 33 0 0 0 SL usbevt 0xffffffff80e49420 [usb1] 32 0 0 0 WL [irq20: uhci1 uhci3] 31 0 0 0 SL usbtsk 0xffffffff80ad8208 [usbtask-dr] 30 0 0 0 SL usbtsk 0xffffffff80ad81e0 [usbtask-hc] 29 0 0 0 SL usbevt 0xffffffff80e47420 [usb0] 28 0 0 0 WL [irq21: uhci0 uhci+] 27 0 0 0 WL [irq257: bce1] 26 0 0 0 RL [irq16: mfi0] 25 0 0 0 WL [irq256: bce0] 24 0 0 0 WL [irq9: acpi0] 23 0 0 0 WL [swi6: Giant taskq] 22 0 0 0 SL - 0xffffff000122ed80 [thread taskq] 21 0 0 0 WL [swi5: +] 9 0 0 0 SL - 0xffffff0001250080 [kqueue taskq] 8 0 0 0 SL - 0xffffff0001250500 [acpi_task_2] 7 0 0 0 SL - 0xffffff0001250500 [acpi_task_1] 6 0 0 0 SL - 0xffffff0001250500 [acpi_task_0] 20 0 0 0 WL [swi2: cambio] 5 0 0 0 SL ccb_scan 0xffffffff80aa6220 [xpt_thrd] 19 0 0 0 WL [swi6: task queue] 18 0 0 0 SL - 0xffffffff80add228 [yarrow] 4 0 0 0 SL - 0xffffffff80ad91f8 [g_down] 3 0 0 0 SL - 0xffffffff80ad91f0 [g_up] 2 0 0 0 SL - 0xffffffff80ad91e0 [g_event] 17 0 0 0 WL [swi1: net] 16 0 0 0 WL [swi3: vm] 15 0 0 0 RL [swi4: clock sio] 14 0 0 0 RL CPU 0 [idle: cpu0] 13 0 0 0 RL [idle: cpu1] 12 0 0 0 RL CPU 2 [idle: cpu2] 11 0 0 0 RL CPU 3 [idle: cpu3] 1 0 1 0 SLs wait 0xffffff00010fc8f0 [init] 10 0 0 0 SL audit_wo 0xffffffff80b02a60 [audit] 0 0 0 0 SLs sched 0xffffffff80ad9300 [swapper] db> show pcpu cpuid = 1 curthread = 0xffffff0056f1f370: pid 41111 "rm" curpcb = 0xffffffffb4aa9d40 fpcurthread = none idlethread = 0xffffff00010ff000: pid 13 "idle: cpu1" db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xffffff000110d6e0: pid 14 "idle: cpu0" curpcb = 0xffffffffac266d40 fpcurthread = none idlethread = 0xffffff000110d6e0: pid 14 "idle: cpu0" cpuid = 1 curthread = 0xffffff0056f1f370: pid 41111 "rm" curpcb = 0xffffffffb4aa9d40 fpcurthread = none idlethread = 0xffffff00010ff000: pid 13 "idle: cpu1" cpuid = 2 curthread = 0xffffff00010ff370: pid 12 "idle: cpu2" curpcb = 0xffffffffac25cd40 fpcurthread = none idlethread = 0xffffff00010ff370: pid 12 "idle: cpu2" cpuid = 3 curthread = 0xffffff00010ff6e0: pid 11 "idle: cpu3" curpcb = 0xffffffffac257d40 fpcurthread = none idlethread = 0xffffff00010ff6e0: pid 11 "idle: cpu3" db> alltrace Tracing command rm pid 41220 tid 100144 td 0xffffff0003ec36e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e indir_trunc() at indir_trunc+0x11f handle_workitem_freeblocks() at handle_workitem_freeblocks+0x281 process_worklist_item() at process_worklist_item+0x293 request_cleanup() at request_cleanup+0x83 newdirrem() at newdirrem+0x267 softdep_setup_remove() at softdep_setup_remove+0x12 ufs_dirremove() at ufs_dirremove+0xa8 ufs_remove() at ufs_remove+0x8f VOP_REMOVE_APV() at VOP_REMOVE_APV+0x34 kern_unlink() at kern_unlink+0x259 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (10, FreeBSD ELF64, unlink), rip = 0x80070682c, rsp = 0x7fffffffeb58, rbp = 0x602400 --- Tracing command rm pid 41119 tid 100133 td 0xffffff00039616e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41118 tid 100092 td 0xffffff00038dd370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41117 tid 100157 td 0xffffff0003fde6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e indir_trunc() at indir_trunc+0x11f handle_workitem_freeblocks() at handle_workitem_freeblocks+0x281 process_worklist_item() at process_worklist_item+0x293 request_cleanup() at request_cleanup+0x83 newdirrem() at newdirrem+0x267 softdep_setup_remove() at softdep_setup_remove+0x12 ufs_dirremove() at ufs_dirremove+0xa8 ufs_remove() at ufs_remove+0x8f VOP_REMOVE_APV() at VOP_REMOVE_APV+0x34 kern_unlink() at kern_unlink+0x259 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (10, FreeBSD ELF64, unlink), rip = 0x80070682c, rsp = 0x7fffffffeb98, rbp = 0x602400 --- Tracing command rm pid 41115 tid 100241 td 0xffffff005bd5c370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41114 tid 100265 td 0xffffff0076ac8370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41113 tid 100239 td 0xffffff005bd5ca50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41112 tid 100254 td 0xffffff0076acd000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41111 tid 100199 td 0xffffff0056f1f370 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x17b dqget() at dqget+0xaa4 getinoquota() at getinoquota+0x5b ufs_access() at ufs_access+0x28c ufs_lookup() at ufs_lookup+0x9fe vfs_cache_lookup() at vfs_cache_lookup+0xf8 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 lookup() at lookup+0x531 namei() at namei+0x35d kern_rmdir() at kern_rmdir+0xbd syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (137, FreeBSD ELF64, rmdir), rip = 0x800686d3c, rsp = 0x7fffffffeb98, rbp = 0x602400 --- Tracing command rm pid 41110 tid 100099 td 0xffffff0003cc2370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41109 tid 100084 td 0xffffff0003971000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e indir_trunc() at indir_trunc+0x11f handle_workitem_freeblocks() at handle_workitem_freeblocks+0x281 process_worklist_item() at process_worklist_item+0x293 request_cleanup() at request_cleanup+0x83 newdirrem() at newdirrem+0x267 softdep_setup_remove() at softdep_setup_remove+0x12 ufs_dirremove() at ufs_dirremove+0xa8 ufs_rmdir() at ufs_rmdir+0xdf VOP_RMDIR_APV() at VOP_RMDIR_APV+0x34 kern_rmdir() at kern_rmdir+0x28f syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (137, FreeBSD ELF64, rmdir), rip = 0x800686d3c, rsp = 0x7fffffffeb9, rbp = 0x602400 --- Tracing command rm pid 41108 tid 100249 td 0xffffff005bd59370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41107 tid 100050 td 0xffffff00038106e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e indir_trunc() at indir_trunc+0x11f handle_workitem_freeblocks() at handle_workitem_freeblocks+0x281 process_worklist_item() at process_worklist_item+0x293 request_cleanup() at request_cleanup+0x76 newdirrem() at newdirrem+0x267 softdep_setup_remove() at softdep_setup_remove+0x12 ufs_dirremove() at ufs_dirremove+0xa8 ufs_rmdir() at ufs_rmdir+0xdf VOP_RMDIR_APV() at VOP_RMDIR_APV+0x34 kern_rmdir() at kern_rmdir+0x28f syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (137, FreeBSD ELF64, rmdir), rip = 0x800686d3c, rsp = 0x7fffffffeb98, rbp = 0x602400 --- Tracing command rm pid 41106 tid 100203 td 0xffffff00211c3370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7ffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41104 tid 100168 td 0xffffff0003cc36e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41103 tid 100149 td 0xffffff0003d186e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41102 tid 100260 td 0xffffff0076acb6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41101 tid 100235 td 0xffffff0003836000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command rm pid 41100 tid 100156 td 0xffffff0003fdea50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e ffs_read() at ffs_read+0x369 ufs_readdir() at ufs_readdir+0xbb getdirentries() at getdirentries+0x18d syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8006ff40c, rsp = 0x7fffffffeaa8, rbp = 0x1 --- Tracing command perl5.8.8 pid 40929 tid 100167 td 0xffffff0003cc3a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40928 tid 100256 td 0xffffff0076acc6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40927 tid 100194 td 0xffffff0021371000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40926 tid 100066 td 0xffffff00036e2a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40925 tid 100175 td 0xffffff00038dea50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40924 tid 100142 td 0xffffff00038d5000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40923 tid 100154 td 0xffffff00120e2370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40922 tid 100227 td 0xffffff00212d36e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40921 tid 100058 td 0xffffff000380c6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e, rbp = 0x3 --- Tracing command perl5.8.8 pid 40920 tid 100069 td 0xffffff00038376e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40919 tid 100217 td 0xffffff00212d7370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e, rbp = 0x3 --- Tracing command perl5.8.8 pid 40918 tid 100226 td 0xffffff00212d3a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40917 tid 100153 td 0xffffff00120e26e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e, rbp = 0x3 --- Tracing command perl5.8.8 pid 40916 tid 100264 td 0xffffff0076ac86e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40915 tid 100131 td 0xffffff0003b14000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e, rbp = 0x3 --- Tracing command perl5.8.8 pid 40914 tid 100120 td 0xffffff0003b17a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40913 tid 100169 td 0xffffff0021390370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e, rbp = 0x3 --- Tracing command perl5.8.8 pid 40912 tid 100192 td 0xffffff00213716e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40911 tid 100173 td 0xffffff0003844000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40910 tid 100196 td 0xffffff00120fa6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40909 tid 100143 td 0xffffff0003ec3a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e, rbp = 0x3 --- Tracing command perl5.8.8 pid 40908 tid 100250 td 0xffffff005bd59000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40907 tid 100195 td 0xffffff00120faa50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e, rbp = 0x3 --- Tracing command perl5.8.8 pid 40906 tid 100258 td 0xffffff0076acc000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40905 tid 100079 td 0xffffff0003960370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40904 tid 100073 td 0xffffff00038366e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40903 tid 100273 td 0xffffff0076b26370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40902 tid 100059 td 0xffffff000380c370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40901 tid 100206 td 0xffffff001211c6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e, rbp = 0x3 --- Tracing command perl5.8.8 pid 40900 tid 100130 td 0xffffff0003b14370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command perl5.8.8 pid 40891 tid 100159 td 0xffffff0003fde000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c795fc, rsp = 0x7fffffffe8e8, rbp = 0x3 --- Tracing command bash pid 40754 tid 100246 td 0xffffff005bd5a000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 ptsread() at ptsread+0x37 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800bef67c, rsp = 0x7fffffffe808, rbp = 0x7fffffffe827 --- Tracing command sshd pid 40751 tid 100204 td 0xffffff00211c3000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x8013985fc, rsp = 0x7fffffffe4b, rbp = 0x7fffffffe540 --- Tracing command bash pid 40666 tid 100208 td 0xffffff0012d996e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 kern_wait() at kern_wait+0x76b wait4() at wait4+0x35 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800b73dac, rsp = 0x7fffffffe9c8, rbp = 0x673b20 --- Tracing command sshd pid 40663 tid 100243 td 0xffffff005bd5aa50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x8013985fc, rsp = 0x7fffffffe4b8, rbp = 0x7fffffffe540 --- Tracing command pickup pid 40613 tid 100104 td 0xffffff0003ca3000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee kern_kevent() at kern_kevent+0x353 kevent() at kevent+0x90 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (363, FreeBSD ELF64, kevent), rip = 0x800e7153c, rsp = 0x7fffffffdb68, rbp = 0x7fffffffdb70 --- Tracing command qmgr pid 35540 tid 100215 td 0xffffff00212d7a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee kern_kevent() at kern_kevent+0x353 kevent() at kevent+0x90 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (363, FreeBSD ELF64, kevent), rip = 0x800e7d53c, rsp = 0x7fffffffdb8, rbp = 0x7fffffffdb10 --- Tracing command master pid 34783 tid 100262 td 0xffffff0076acb000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee kern_kevent() at kern_kevent+0x353 kevent() at kevent+0x90 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (363, FreeBSD ELF64, kevent), rip = 0x800e6353c, rsp = 0x7fffffffde58, rbp = 0x7fffffffde60 --- Tracing command slapd pid 34615 tid 100291 td 0xffffff00038446e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7ffffb3f5ba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100290 td 0xffffff0076b25370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7ffffbbf6ba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100289 td 0xffffff0003c8c000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7ffffc3fba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100288 td 0xffffff0076ca7370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7ffffcbf8ba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100287 td 0xffffff0076acd6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7ffffd3f9ba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100286 td 0xffffff0076acda50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7ffffdbfaba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100285 td 0xffffff0076bb6000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7ffffe3fbba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100284 td 0xffffff0003c8ca50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7ffffebfcba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100283 td 0xffffff008d580000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7fffff3fdba8, rbp = 0 --- Tracing command slapd pid 34615 tid 100281 td 0xffffff0076bb6370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x8014655fc, rsp = 0x7fffffbfe1d, rbp = 0x57 --- Tracing command slapd pid 34615 tid 100074 td 0xffffff000380c000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_wait() at do_wait+0x4da __umtx_op_wait() at __umtx_op_wait+0x5b syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127c54c, rsp = 0x7fffffffe5c8, rbp = 0x602600 --- Tracing command mysqld pid 34297 tid 100279 td 0xffffff008d581000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 kern_sigtimedwait() at kern_sigtimedwait+0x5ff sigwait() at sigwait+0x74 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x8013cd85c, rsp = 0x7ffffebf6f18, rbp = 0xa02f00 --- Tracing command mysqld pid 34297 tid 100276 td 0xffffff008d581370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127654c, rsp = 0x7ffffedf7e98, rbp = 0 --- Tracing command mysqld pid 34297 tid 100278 td 0xffffff008d5816e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x80145f5fc, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 34297 tid 100277 td 0xffffff008d581a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x80145f5fc, rsp = 0x7fffff1f9f18, rbp = 0 --- Tracing command mysqld pid 34297 tid 100275 td 0xffffff008d582370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127654c, rsp = 0x7fffff5fbe8, rbp = 0 --- Tracing command mysqld pid 34297 tid 100221 td 0xffffff008d5826e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127654c, rsp = 0x7fffff7fcbe8, rbp = 0 --- Tracing command mysqld pid 34297 tid 100220 td 0xffffff008d582a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127654c, rsp = 0x7fffff9fdbe8, rbp = 0 --- Tracing command mysqld pid 34297 tid 100218 td 0xffffff008d583000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80127654c, rsp = 0x7fffffbfbe8, rbp = 0 --- Tracing command mysqld pid 34297 tid 100065 td 0xffffff0003797000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x80145f5fc, rsp = 0x7fffffffe098, rbp = 0xd --- Tracing command sh pid 34277 tid 100271 td 0xffffff0076b26a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 kern_wait() at kern_wait+0x76b wait4() at wait4+0x35 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80091bdac, rsp = 0x7fffffffe048, rbp = 0x85e4 --- Tracing command bash pid 960 tid 100152 td 0xffffff0003d16a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 ptsread() at ptsread+0x37 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x800bef67c, rsp = 0x7fffffffe328, bp = 0x7fffffffe347 --- Tracing command screen pid 958 tid 100150 td 0xffffff0003d18370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800ad15fc, rsp = 0x7fffffffe36, rbp = 0x7fffffffe3f0 --- Tracing command getty pid 950 tid 100137 td 0xffffff0003d19370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, rbp = 0 --- Tracing command getty pid 949 tid 100055 td 0xffffff000380f370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, rbp = 0 --- Tracing command getty pid 948 tid 100071 td 0xffffff0003837000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, rbp = 0 --- Tracing command getty pid 947 tid 100097 td 0xffffff0003cc2a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, rbp = 0 --- Tracing command getty pid 946 tid 100053 td 0xffffff000380fa50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, bp = 0 --- Tracing command getty pid 945 tid 100080 td 0xffffff0003960000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, rbp = 0 --- Tracing command getty pid 944 tid 100095 td 0xffffff0003cc3370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, rbp = 0 --- Tracing command getty pid 943 tid 100093 td 0xffffff0003970000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, bp = 0 --- Tracing command getty pid 942 tid 100094 td 0xffffff0003837a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 ttysleep() at ttysleep+0x25 ttread() at ttread+0x315 giant_read() at giant_read+0x6f devfs_read_f() at devfs_read_f+0x81 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x80082967c, rsp = 0x7fffffffed88, rbp = 0 --- Tracing command bsnmpd pid 936 tid 100124 td 0xffffff00038d5a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800a475fc, rsp = 0x7fffffffc4a, rbp = 0x7fffffffedac --- Tracing command inetd pid 922 tid 100085 td 0xffffff0003970a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800a3e5fc, rsp = 0x7fffffffdf18, rbp = 0 --- Tracing command cron pid 899 tid 100067 td 0xffffff00036e26e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x8009183bc, rsp = 0x7fffffffec18, rbp = 0x3c --- Tracing command sshd pid 892 tid 100052 td 0xffffff0003810000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x8013985fc, rsp = 0x7fffffffe5c, rbp = 0x2 --- Tracing command nrpe2 pid 851 tid 100106 td 0xffffff0003c9e6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x117 kern_select() at kern_select+0x939 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c025fc, rsp = 0x7fffffffdd18, rbp = 0xa120 --- Tracing command freshclam pid 755 tid 100121 td 0xffffff0003b176e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 kern_sigsuspend() at kern_sigsuspend+0xda sigsuspend() at sigsuspend+0x34 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x800edf0bc, rsp = 0x7ffffffebf8, rbp = 0x608040 --- Tracing command clamd pid 750 tid 100294 td 0xffffff001211c000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee do_cv_wait() at do_cv_wait+0x501 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800d8054c, rsp = 0x7ffffdf1ea8, rbp = 0x7ffffdf10f00 --- Tracing command clamd pid 750 tid 100293 td 0xffffff005b1f8000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee do_cv_wait() at do_cv_wait+0x501 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800d8054c, rsp = 0x7ffffd2aea8, rbp = 0x7ffffd2aaf00 --- Tracing command clamd pid 750 tid 100292 td 0xffffff005b1f8370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee do_cv_wait() at do_cv_wait+0x501 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800d8054c, rsp = 0x7ffffdcfea8, rbp = 0x7ffffdcfff00 --- Tracing command clamd pid 750 tid 100282 td 0xffffff005b1f86e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee do_cv_wait() at do_cv_wait+0x501 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800d8054c, rsp = 0x7ffffe965ea8, rbp = 0x7ffffe965f00 --- Tracing command clamd pid 750 tid 100280 td 0xffffff0076b25000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee do_cv_wait() at do_cv_wait+0x501 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800d8054c, rsp = 0x7fffffbfeea8, rbp = 0x7fffffbfef00 --- Tracing command clamd pid 750 tid 100219 td 0xffffff005679c370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee do_cv_wait() at do_cv_wait+0x501 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800d8054c, rsp = 0x7ffffe543ea8, rbp = 0x7ffffe543f00 --- Tracing command clamd pid 750 tid 100102 td 0xffffff0003ca36e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 kern_accept() at kern_accept+0x18a accept() at accept+0xfe syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (30, FreeBSD ELF64, accept), rip = 0x800f09bdc, rsp = 0x7fffffffe778, rbp = 0x1 --- Tracing command ntpd pid 720 tid 100078 td 0xffffff00039606e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800d1f5fc, rsp = 0x7fffffffecc8, rbp = 0x7fffffffede0 --- Tracing command named pid 630 tid 100114 td 0xffffff00038dca50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x800c345fc, rsp = 0x7fffff1f9cb8, rbp = 0x31 --- Tracing command named pid 630 tid 100113 td 0xffffff00038dd000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x1ee do_cv_wait() at do_cv_wait+0x501 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800a4b54c, rsp = 0x7fffff3fadc8, rbp = 0x7fffff3fae20 --- Tracing command named pid 630 tid 100112 td 0xffffff0003d1a000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800a4b54c, rsp = 0x7fffff5feb8, rbp = 0 --- Tracing command named pid 630 tid 100111 td 0xffffff0003d1a370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800a4b54c, rsp = 0x7fffff7fceb8, rbp = 0 --- Tracing command named pid 630 tid 100110 td 0xffffff0003b056e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800a4b54c, rsp = 0x7fffff9feb8, rbp = 0 --- Tracing command named pid 630 tid 100109 td 0xffffff0003b05a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 do_cv_wait() at do_cv_wait+0x644 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800a4b54c, rsp = 0x7fffffbfeeb8, rbp = 0 --- Tracing command named pid 630 tid 100077 td 0xffffff0003960a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 kern_sigtimedwait() at kern_sigtimedwait+0x5ff sigwait() at sigwait+0x74 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x800ba285c, rsp = 0x7fffffffec28, rbp = 0x702180 --- Tracing command syslogd pid 531 tid 100081 td 0xffffff0003971a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x80082c5fc, rsp = 0x7fffffffdd88, rbp = 0x8 --- Tracing command devd pid 468 tid 100075 td 0xffffff0003961370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x10e kern_select() at kern_select+0xa23 select() at select+0x56 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (93, FreeBSD ELF64, select), rip = 0x43fd3c, rsp = 0x7fffffffe918, rbp = 0x7fffffffed40 --- Tracing command softdepflush pid 48 tid 100047 td 0xffffff000379a370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 bwait() at bwait+0x59 bufwait() at bufwait+0x56 bread() at bread+0x1e indir_trunc() at indir_trunc+0x11f handle_workitem_freeblocks() at handle_workitem_freeblocks+0x281 process_worklist_item() at process_worklist_item+0x293 softdep_process_worklist() at softdep_process_worklist+0xf2 softdep_flush() at softdep_flush+0x12a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb249fd30, rbp = 0 --- Tracing command vnlru pid 47 tid 100046 td 0xffffff000379a6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e vnlru_proc() at vnlru_proc+0x6c2 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb249ad30, rbp = 0 --- Tracing command syncer pid 46 tid 100045 td 0xffffff000379aa50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 acquire() at acquire+0x7c _lockmgr() at _lockmgr+0x203 ffs_lock() at ffs_lock+0x96 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 _vn_lock() at _vn_lock+0x83 vget() at vget+0xf9 qsync() at qsync+0x1a4 ffs_sync() at ffs_sync+0x2e4 sync_fsync() at sync_fsync+0x1ac sched_sync() at sched_sync+0x609 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb2495d30, rbp = 0 --- Tracing command bufdaemon pid 45 tid 100044 td 0xffffff0001414a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e buf_daemon() at buf_daemon+0x2b5 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb2490d30, rbp = 0 --- Tracing command pagezero pid 44 tid 100043 td 0xffffff00036e0000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e vm_pagezero() at vm_pagezero+0x83 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb248bd30, rbp = 0 --- Tracing command vmdaemon pid 43 tid 100042 td 0xffffff00036e0370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 vm_daemon() at vm_daemon+0x58 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb2486d30, rbp = 0 --- Tracing command pagedaemon pid 42 tid 100041 td 0xffffff00036e06e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e vm_pageout() at vm_pageout+0xbbc fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb2481d30, rbp = 0 --- Tracing command sctp_iterator pid 41 tid 100040 td 0xffffff00036e0a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 sctp_iterator_thread() at sctp_iterator_thread+0x54 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb247cd30, rbp = 0 --- Tracing command irq1: atkbd0 pid 40 tid 100039 td 0xffffff00036e1000 fork_trampoline() at fork_trampoline Tracing command swi0: sio pid 39 tid 100038 td 0xffffff00036e1370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ithread_loop() at ithread_loop+0x3be fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb244fd30, rbp = 0 --- Tracing command irq15: ata1 pid 38 tid 100037 td 0xffffff00036e16e0 fork_trampoline() at fork_trampoline Tracing command irq14: ata0 pid 37 tid 100036 td 0xffffff00036e1a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ithread_loop() at ithread_loop+0x3be fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb2432d30, rbp = 0 --- Tracing command usb4 pid 36 tid 100035 td 0xffffff00036e2000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e usb_event_thread() at usb_event_thread+0xb9 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb241ad30, rbp = 0 --- Tracing command usb3 pid 35 tid 100034 td 0xffffff00012586e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e usb_event_thread() at usb_event_thread+0xb9 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb23ffd30, rbp = 0 --- Tracing command usb2 pid 34 tid 100033 td 0xffffff0001258a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e usb_event_thread() at usb_event_thread+0xb9 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb23f3d30, rbp = 0 --- Tracing command usb1 pid 33 tid 100032 td 0xffffff0001413000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e usb_event_thread() at usb_event_thread+0xb9 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb23e7d30, rbp = 0 --- Tracing command irq20: uhci1 uhci3 pid 32 tid 100031 td 0xffffff0001413370 fork_trampoline() at fork_trampoline Tracing command usbtask-dr pid 31 tid 100030 td 0xffffff00014136e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 usb_task_thread() at usb_task_thread+0xa3 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb23d6d30, rbp = 0 --- Tracing command usbtask-hc pid 30 tid 100029 td 0xffffff0001413a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 usb_task_thread() at usb_task_thread+0xa3 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb23d1d30, rbp = 0 --- Tracing command usb0 pid 29 tid 100028 td 0xffffff0001414000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e usb_event_thread() at usb_event_thread+0xb9 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb23ccd30, rbp = 0 --- Tracing command irq21: uhci0 uhci+ pid 28 tid 100027 td 0xffffff0001414370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ithread_loop() at ithread_loop+0x3be fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb03c1d30, rbp = 0 --- Tracing command irq257: bce1 pid 27 tid 100026 td 0xffffff00014146e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ithread_loop() at ithread_loop+0x3be fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb03bcd30, rbp = 0 --- Tracing command irq16: mfi0 pid 26 tid 100025 td 0xffffff000111a6e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ithread_loop() at ithread_loop+0x3be fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffae3b3d30, rbp = 0 --- Tracing command irq256: bce0 pid 25 tid 100024 td 0xffffff000111aa50 fork_trampoline() at fork_trampoline Tracing command irq9: acpi0 pid 24 tid 100023 td 0xffffff0001257000 fork_trampoline() at fork_trampoline Tracing command swi6: Giant taskq pid 23 tid 100022 td 0xffffff0001257370 fork_trampoline() at fork_trampoline Tracing command thread taskq pid 22 tid 100021 td 0xffffff00012576e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 taskqueue_thread_loop() at taskqueue_thread_loop+0x92 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac2bbd30, rbp = 0 --- Tracing command swi5: + pid 21 tid 100020 td 0xffffff0001257a50 fork_trampoline() at fork_trampoline Tracing command kqueue taskq pid 9 tid 100019 td 0xffffff0001258000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 taskqueue_thread_loop() at taskqueue_thread_loop+0x92 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac2b1d30, rbp = 0 --- Tracing command acpi_task_2 pid 8 tid 100018 td 0xffffff0001258370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 taskqueue_thread_loop() at taskqueue_thread_loop+0x92 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac2acd30, rbp = 0 --- Tracing command acpi_task_1 pid 7 tid 100017 td 0xffffff000110da50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 taskqueue_thread_loop() at taskqueue_thread_loop+0x92 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac2a7d30, rbp = 0 --- Tracing command acpi_task_0 pid 6 tid 100016 td 0xffffff0001119000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 taskqueue_thread_loop() at taskqueue_thread_loop+0x92 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac2a2d30, rbp = 0 --- Tracing command swi2: cambio pid 20 tid 100015 td 0xffffff0001119370 fork_trampoline() at fork_trampoline Tracing command xpt_thrd pid 5 tid 100014 td 0xffffff00011196e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _sleep() at _sleep+0x351 xpt_scanner_thread() at xpt_scanner_thread+0x3a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac298d30, rbp = 0 --- Tracing command swi6: task queue pid 19 tid 100013 td 0xffffff0001119a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ithread_loop() at ithread_loop+0x3be fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac293d30, rbp = 0 --- Tracing command yarrow pid 18 tid 100012 td 0xffffff000111a000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e random_kthread() at random_kthread+0x20c fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac28ed30, rbp = 0 --- Tracing command g_down pid 4 tid 100011 td 0xffffff000111a370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e g_io_schedule_down() at g_io_schedule_down+0x227 g_down_procbody() at g_down_procbody+0x5a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac285d30, rbp = 0 --- Tracing command g_up pid 3 tid 100010 td 0xffffff0001101370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e g_io_schedule_up() at g_io_schedule_up+0xfe g_up_procbody() at g_up_procbody+0x5a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac280d30, rbp = 0 --- Tracing command g_event pid 2 tid 100009 td 0xffffff00011016e0 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e g_event_procbody() at g_event_procbody+0x91 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac27bd30, rbp = 0 --- Tracing command swi1: net pid 17 tid 100008 td 0xffffff0001101a50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ithread_loop() at ithread_loop+0x3be fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac276d30, rbp = 0 --- Tracing command swi3: vm pid 16 tid 100007 td 0xffffff000110d000 fork_trampoline() at fork_trampoline Tracing command swi4: clock sio pid 15 tid 100006 td 0xffffff000110d370 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ithread_loop() at ithread_loop+0x3be fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac26cd30, rbp = 0 --- Tracing command idle: cpu0 pid 14 tid 100005 td 0xffffff000110d6e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x335 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff804e9643, rsp = 0xffffffff80b0fdb0, rbp = 0xfffffffac266c20 --- sched_idletd() at sched_idletd+0xc3 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac266d30, rbp = 0 --- Tracing command idle: cpu1 pid 13 tid 100004 td 0xffffff00010ff000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e ipi_bitmap_handler() at ipi_bitmap_handler+0xa4 Xipi_intr_bitmap_handler() at Xipi_intr_bitmap_handler+0x76 --- interrupt, rip = 0xffffffff80782486, rsp = 0xffffffffac261b90, rbp = 0xffffffffac261ba0 --- acpi_cpu_c1() at acpi_cpu_c1+0x6 acpi_cpu_idle() at acpi_cpu_idle+0x19c sched_idletd() at sched_idletd+0x46 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac261d30, rbp = 0 --- Tracing command idle: cpu2 pid 12 tid 100003 td 0xffffff00010ff370 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x335 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff807d0713, rsp = 0xffffffffab795ff0, rbp = 0xffffffffac25caa0 --- siointr1() at siointr1+0x243 siointr() at siointr+0x58 intr_execute_handlers() at intr_execute_handlers+0x8b Xapic_isr1() at Xapic_isr1+0x7f --- interrupt, rip = 0xffffffff80791943, rsp = 0xffffffffac25cbc0, rbp = 0xffffffffac25cbe0 --- spinlock_exit() at spinlock_exit+0x33 sched_idletd() at sched_idletd+0x13b fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac25cd30, rbp = 0 --- Tracing command idle: cpu3 pid 11 tid 100002 td 0xffffff00010ff6e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x335 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff80782486, rsp = 0xffffffffab79aff0, rbp = 0xffffffffac257ba0 --- acpi_cpu_c1() at acpi_cpu_c1+0x6 acpi_cpu_idle() at acpi_cpu_idle+0x19c sched_idletd() at sched_idletd+0x46 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac257d30, rbp = 0 --- Tracing command init pid 1 tid 100001 td 0xffffff00010ffa50 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_catch_signals() at sleepq_catch_signals+0x359 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x295 kern_wait() at kern_wait+0x76b wait4() at wait4+0x35 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (7, FreeBSD ELF64, wait4), rip = 0x40bf4c, rsp = 0x7fffffffe8d8, rbp = 0x7fffffffed60 --- Tracing command audit pid 10 tid 100000 td 0xffffff0001101000 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_wait() at sleepq_wait+0x3b _cv_wait() at _cv_wait+0xfe audit_worker() at audit_worker+0x359 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffac24dd30, rbp = 0 --- Tracing command swapper pid 0 tid 0 td 0xffffffff80ad9780 sched_switch() at sched_switch+0x1fe mi_switch() at mi_switch+0x18e sleepq_timedwait() at sleepq_timedwait+0x31 _sleep() at _sleep+0x33e scheduler() at scheduler+0x3d3 mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> show lockedvnods Locked vnodes 0xffffff0076437dc8: tag ufs, type VDIR usecount 2, writecount 0, refcount 7 mountedhere 0 flags () v_object 0xffffff005474f4e0 ref 0 pages 584 lock type ufs: EXCL (count 1) by thread 0xffffff0003ec36e0 (pid 41220) ino 20820014, on dev mfid0s1g 0xffffff00038ba1f8: tag syncer, type VNON usecount 1, writecount 0, refcount 2 mountedhere 0 flags () lock type syncer: EXCL (count 1) by thread 0xffffff000379aa50 (pid 46) 0xffffff0003d643f0: tag ufs, type VREG usecount 2, writecount 1, refcount 3614 mountedhere 0 flags (VV_SYSTEM) v_object 0xffffff0003cdf4e0 ref 0 pages 24028 lock type ufs: SHARED (count 1) ino 7, on dev mfid0s1g 0xffffff005b312dc8: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0053d1dc30 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff00038106e0 (pid 41107) ino 89026686, on dev mfid0s1g 0xffffff0003e297e0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0012c51820 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0076acd000 (pid 41112) ino 1012827, on dev mfid0s1g 0xffffff0003874dc8: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0054ffb270 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff005bd5ca50 (pid 41113) ino 2991239, on dev mfid0s1g 0xffffff0012b52000: tag ufs, type VDIR usecount 2, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xffffff00538c6c30 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff00039616e0 (pid 41119) with 1 pending ino 14602248, on dev mfid0s1g 0xffffff00210371f8: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xffffff0053480000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff00038106e0 (pid 41107) ino 89050235, on dev mfid0s1g 0xffffff0123d99dc8: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff00aeedd410 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0076ac8370 (pid 41114) ino 4427870, on dev mfid0s1g 0xffffff001265d3f0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff008d4e19c0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff00211c3370 (pid 41106) ino 78216337, on dev mfid0s1g 0xffffff0056512bd0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff005b5fc9c0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0003d186e0 (pid 41103) ino 86600744, on dev mfid0s1g 0xffffff00210817e0: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xffffff0003ec36e0 (pid 41220) ino 20993589, on dev mfid0s1g 0xffffff00564ed3f0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff00210b4680 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0003fde6e0 (pid 41117) ino 7536668, on dev mfid0s1g 0xffffff0052344dc8: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0054c359c0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff005bd59370 (pid 41108) ino 86930594, on dev mfid0s1g 0xffffff008d1729d8: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xffffff0003fde6e0 (pid 41117) ino 7536941, on dev mfid0s1g 0xffffff008d40cdc8: tag ufs, type VDIR usecount 2, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xffffff00564cb0d0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0003971000 (pid 41109) ino 93218956, on dev mfid0s1g 0xffffff0053590000: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff00546f9270 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0076acb6e0 (pid 41102) ino 82078744, on dev mfid0s1g 0xffffff008d3e6bd0: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xffffff0079fb9270 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0003971000 (pid 41109) ino 93218957, on dev mfid0s1g 0xffffff008d0037e0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff00534028f0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff005bd5c370 (pid 41115) ino 91593902, on dev mfid0s1g 0xffffff005469d000: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff00037394e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0003836000 (pid 41101) ino 101768214, on dev mfid0s1g 0xffffff002128d3f0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0076c1d410 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0003cc36e0 (pid 41104) ino 81113179, on dev mfid0s1g 0xffffff00217897e0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0054b3b5b0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0003fdea50 (pid 41100) ino 78899204, on dev mfid0s1g 0xffffff005bc0f3f0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff005455a000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff00038dd370 (pid 41118) ino 9821288, on dev mfid0s1g 0xffffff011e0767e0: tag ufs, type VDIR usecount 2, writecount 0, refcount 5 mountedhere 0 flags () v_object 0xffffff005b6bc0d0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0056f1f370 (pid 41111) ino 100967484, on dev mfid0s1g 0xffffff0076377bd0: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xffffff0076bff820 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xffffff0003cc2370 (pid 41110) ino 96775287, on dev mfid0s1g db> show locks No such command db> show alllocks No such command db> -------------- next part -------------- include GENERIC ident PTSMP options KDB # Enable kernel debugger support. options BREAK_TO_DEBUGGER options DDB # Support DDB. options GDB # Support remote GDB. options QUOTA options SMP -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.today Type: application/octet-stream Size: 11949 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081203/9a8ac9b0/dmesg-0001.obj From kostikbel at gmail.com Wed Dec 3 09:39:47 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Dec 3 09:39:54 2008 Subject: FreeBSD 7.1-PRERELEASE-p1, panic: dqget: free dquot isn't In-Reply-To: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> References: <3B675385-956D-4A26-8E09-E338DF7D7244@nordahl.net> Message-ID: <20081203173939.GA2401@deviant.kiev.zoral.com.ua> On Wed, Dec 03, 2008 at 06:03:26PM +0100, Frode Nordahl wrote: > Hello, > > I have a server with FreeBSD 7.1-PRERELEASE-p1 amd64 on it. Upgraded > from a 7.0-RELEASE system using freebsd-update. > > It's a DELL PE2950 with E5420 Quad Core 2.50GHz processor, 4 GB RAM, > using DELL PERC 6 RAID card (mfi0). > > The system is running a custom kernel to get quota support. > > During some tests which involved removing a large number of files > simultaneously (ran 20+ copies of rm -rf), it paniced with this > message: dqget: free dquot isn't > > Output from DDB, kernel config and dmesg is attached. I also secured a > crashdump, so further queries using kgdb is possible. > > -- > Frode Nordahl > > > db> where > Tracing pid 41111 tid 100199 td 0xffffff0056f1f370 > kdb_enter_why() at kdb_enter_why+0x3d > panic() at panic+0x17b > dqget() at dqget+0xaa4 > getinoquota() at getinoquota+0x5b > ufs_access() at ufs_access+0x28c > ufs_lookup() at ufs_lookup+0x9fe > vfs_cache_lookup() at vfs_cache_lookup+0xf8 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 > lookup() at lookup+0x531 > namei() at namei+0x35d > kern_rmdir() at kern_rmdir+0xbd > syscall() at syscall+0x256 > Xfast_syscall() at Xfast_syscall+0xab For the start, I want to see the content of the *dq in the dqget() frame. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081203/c781b6c3/attachment.pgp From joe at zircon.seattle.wa.us Wed Dec 3 10:59:16 2008 From: joe at zircon.seattle.wa.us (Joe Kelsey) Date: Wed Dec 3 11:17:44 2008 Subject: i give up In-Reply-To: <20081202220643.72eb52a3@serene.no-ip.org> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> Message-ID: <4936D0C2.2090306@zircon.seattle.wa.us> Conrad J. Sabatier wrote: > On Sat, 29 Nov 2008 14:49:02 +0900 > Randy Bush wrote: > > >> what a tragic story. and zero technical info, like even what your >> controller is. best of luck in penguin land. bye! >> >> randy >> > > No, actually, I forwarded to Soren all the information I could glean > from Windows Vista, Linux and FreeBSD (which I managed to install on an > external USB drive). I also applied the patches he sent me, which > failed to cure the problem, and have been monitoring the mailing lists > and CVS repo for any signs of progress, but so far I've seen nothing. > The first step in upgrading a FreeBSD system is to NEVER purchase ANYTHING with an nVidia logo anywhere near it. nVidia purposelessly witholds programming information form free developers, so there is virtually no chance for being able to make anything with nVidia work at any time. Second, DO NOT use motherboards with built-in video. These are almost always nvidia chipsets and suffer from the nvidia problem. Also, the video is crappy and buggy. Several people have mentioned reliable internet shops to order proven hardware from. Whenever you walk into a "local" computer store, you get no expertise in anything non-windoze. Go somewhere where you can use a magnifying glass to examine the chips and actually determine whether or not you are likely to suffer the nvidia disaster. Write down the motherboard information and ask on the mailing lists. I had a horrid problem with crappy SATA chips on my motherboard, and I had to buy two different SATA PCI cards before I got one that worked. Trade in the defective motherboard to get a new one that works. Think before you ever try to buy anything with nVidia logos on it, unless you are willing to run Linux crap. Good luck in the future. /Joe From fbsdlist at src.cx Wed Dec 3 11:44:17 2008 From: fbsdlist at src.cx (Artem Belevich) Date: Wed Dec 3 11:44:23 2008 Subject: i give up In-Reply-To: <4936D0C2.2090306@zircon.seattle.wa.us> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> Message-ID: > Second, DO NOT use motherboards with built-in video. These are almost > always nvidia chipsets and suffer from the nvidia problem. Also, the video > is crappy and buggy. I'd not discount them all as a class. Intel's built-in G33/G35 with recent DRM and x86-video-intel driver seem to work pretty well for accelerated 2D on the few boxes I have under FreeBSD-8/amd64. I even get 3D working on occasion. :-) --Artem From tinderbox at freebsd.org Wed Dec 3 12:55:16 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Dec 3 12:55:32 2008 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20081203205512.C5AB873039@freebsd-current.sentex.ca> TB --- 2008-12-03 19:32:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-03 19:32:59 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-12-03 19:33:00 - cleaning the object tree TB --- 2008-12-03 19:33:37 - cvsupping the source tree TB --- 2008-12-03 19:33:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-12-03 19:33:45 - building world TB --- 2008-12-03 19:33:45 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-03 19:33:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-03 19:33:45 - TARGET=ia64 TB --- 2008-12-03 19:33:45 - TARGET_ARCH=ia64 TB --- 2008-12-03 19:33:45 - TZ=UTC TB --- 2008-12-03 19:33:45 - __MAKE_CONF=/dev/null TB --- 2008-12-03 19:33:45 - cd /src TB --- 2008-12-03 19:33:45 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 3 19:33:48 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/newfs_msdos/newfs_msdos.c echo newfs_msdos: /obj/ia64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/newfs_msdos/newfs_msdos.c cc1: warnings being treated as errors /src/sbin/newfs_msdos/newfs_msdos.c: In function 'main': /src/sbin/newfs_msdos/newfs_msdos.c:367: warning: format '%lld' expects type 'long long int', but argument 3 has type 'off_t' /src/sbin/newfs_msdos/newfs_msdos.c:377: warning: format '%lld' expects type 'long long int', but argument 3 has type 'off_t' *** Error code 1 Stop in /src/sbin/newfs_msdos. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-03 20:55:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-03 20:55:12 - ERROR: failed to build world TB --- 2008-12-03 20:55:12 - 4019.27 user 313.95 system 4932.56 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From mike at sentex.net Wed Dec 3 13:05:56 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Dec 3 13:06:03 2008 Subject: i give up In-Reply-To: <4936D0C2.2090306@zircon.seattle.wa.us> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> Message-ID: <200812031946.mB3Jk71w011580@lava.sentex.ca> At 01:32 PM 12/3/2008, Joe Kelsey wrote: >Trade in the defective motherboard to get a new one that >works. Think before you ever try to buy anything with nVidia logos >on it, unless you are willing to run Linux crap. Actually, the LINUX 'forcedeath' driver for quite some time was quite inferior to the nfe/nve driver which also was cobbled together through reverse engineering. I had to use a MB that had those NICs on a few customer LINUX boxes and we ended up just installing a some old fxp nics we had sitting around to avoid various stability issues... As others have said, LINUX can have the same issues despite the oodles of extra $$$ resources. ---Mike From tinderbox at freebsd.org Wed Dec 3 14:09:59 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Dec 3 14:10:08 2008 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20081203220955.C22C273039@freebsd-current.sentex.ca> TB --- 2008-12-03 21:05:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-03 21:05:11 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-12-03 21:05:11 - cleaning the object tree TB --- 2008-12-03 21:05:40 - cvsupping the source tree TB --- 2008-12-03 21:05:40 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-12-03 21:05:49 - building world TB --- 2008-12-03 21:05:49 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-03 21:05:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-03 21:05:49 - TARGET=sparc64 TB --- 2008-12-03 21:05:49 - TARGET_ARCH=sparc64 TB --- 2008-12-03 21:05:49 - TZ=UTC TB --- 2008-12-03 21:05:49 - __MAKE_CONF=/dev/null TB --- 2008-12-03 21:05:49 - cd /src TB --- 2008-12-03 21:05:49 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 3 21:05:52 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/newfs_msdos/newfs_msdos.c echo newfs_msdos: /obj/sparc64/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/newfs_msdos/newfs_msdos.c cc1: warnings being treated as errors /src/sbin/newfs_msdos/newfs_msdos.c: In function 'main': /src/sbin/newfs_msdos/newfs_msdos.c:367: warning: format '%lld' expects type 'long long int', but argument 3 has type 'off_t' /src/sbin/newfs_msdos/newfs_msdos.c:377: warning: format '%lld' expects type 'long long int', but argument 3 has type 'off_t' *** Error code 1 Stop in /src/sbin/newfs_msdos. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-03 22:09:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-03 22:09:55 - ERROR: failed to build world TB --- 2008-12-03 22:09:55 - 3030.86 user 302.60 system 3884.26 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From rnoland at FreeBSD.org Wed Dec 3 14:12:47 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Dec 3 14:12:53 2008 Subject: i give up In-Reply-To: References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> Message-ID: <1228342356.2078.24.camel@wombat.2hip.net> On Wed, 2008-12-03 at 11:44 -0800, Artem Belevich wrote: > > Second, DO NOT use motherboards with built-in video. These are almost > > always nvidia chipsets and suffer from the nvidia problem. Also, the video > > is crappy and buggy. > > I'd not discount them all as a class. Intel's built-in G33/G35 with > recent DRM and x86-video-intel driver seem to work pretty well for > accelerated 2D on the few boxes I have under FreeBSD-8/amd64. I even > get 3D working on occasion. :-) Correct, Despite my occasional frustration with them, Intel is very supportive. They are providing docs and code (linux code) and I have a decent relationship with the Intel graphics devs. ATI/AMD has also become much more friendly and r500 and below should work fairly well. r600+ is still under development. Interestingly enough, VIA just released docs on some of their chips as well. I have it on my list to work on, but I don't yet have hardware to work with. robert. > --Artem > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081203/9d2de546/attachment.pgp From tinderbox at freebsd.org Wed Dec 3 15:13:06 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Dec 3 15:13:24 2008 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20081203231303.1992973039@freebsd-current.sentex.ca> TB --- 2008-12-03 22:09:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-03 22:09:56 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-12-03 22:09:56 - cleaning the object tree TB --- 2008-12-03 22:10:20 - cvsupping the source tree TB --- 2008-12-03 22:10:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-12-03 22:10:28 - building world TB --- 2008-12-03 22:10:28 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-03 22:10:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-03 22:10:28 - TARGET=sun4v TB --- 2008-12-03 22:10:28 - TARGET_ARCH=sparc64 TB --- 2008-12-03 22:10:28 - TZ=UTC TB --- 2008-12-03 22:10:28 - __MAKE_CONF=/dev/null TB --- 2008-12-03 22:10:28 - cd /src TB --- 2008-12-03 22:10:28 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 3 22:10:30 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/newfs_msdos/newfs_msdos.c echo newfs_msdos: /obj/sun4v/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/newfs_msdos/newfs_msdos.c cc1: warnings being treated as errors /src/sbin/newfs_msdos/newfs_msdos.c: In function 'main': /src/sbin/newfs_msdos/newfs_msdos.c:367: warning: format '%lld' expects type 'long long int', but argument 3 has type 'off_t' /src/sbin/newfs_msdos/newfs_msdos.c:377: warning: format '%lld' expects type 'long long int', but argument 3 has type 'off_t' *** Error code 1 Stop in /src/sbin/newfs_msdos. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-03 23:13:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-03 23:13:02 - ERROR: failed to build world TB --- 2008-12-03 23:13:02 - 3029.77 user 297.81 system 3786.95 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From erik at cederstrand.dk Wed Dec 3 15:18:21 2008 From: erik at cederstrand.dk (Erik Cederstrand) Date: Wed Dec 3 15:18:29 2008 Subject: i give up In-Reply-To: <4936D0C2.2090306@zircon.seattle.wa.us> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> Message-ID: <9FE3410C-2439-4AB6-B993-579E06489CBE@cederstrand.dk> Den 03/12/2008 kl. 19.32 skrev Joe Kelsey: > The first step in upgrading a FreeBSD system is to NEVER purchase > ANYTHING with an nVidia logo anywhere near it. nVidia purposelessly > witholds programming information form free developers, so there is > virtually no chance for being able to make anything with nVidia work > at any time. While I acknowledge that they withhold information, that's only half the truth. nVidia has presented us with a list of kernel features which are necessary for them to improve their binary driver for FreeBSD: http://wiki.freebsd.org/NvidiaFeatureRequests So we have some work to do, too. Erik From stb at lassitu.de Wed Dec 3 15:33:56 2008 From: stb at lassitu.de (Stefan Bethke) Date: Wed Dec 3 15:34:04 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <20081202232924.GA19134@hyperion.scode.org> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> Message-ID: <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Am 03.12.2008 um 00:29 schrieb Peter Schuller: >> I've noticed the past couple of days, when using the server (not very >> often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 >> minutes (no mouse movement, no keyboard events), while the drives >> work like >> crazy. > > I was not explicit about it, but FWIW in my case the hang is not due > to drive saturation. The drives were mostly idle (except some stuff > triggered by a buildworld I had going) during the extended period of > ktorrent being unkillable. But again I never had this happen > pre-CURRENT. Just a very brief "me too" (but possibly different effect): I'm stress testing two machines I put together over the weekend with an endless loop of make -j4 universe, with /usr/obj on ZFS, with a single disk. One of the two machines has now been stuck for a couple of hours, and trying to access /tank results in a hung process, as will zfs list. I'll reboot and see what happens, and if I can trigger it again, willt try to produce more details. I have set vfs.zfs.arc_max="512M" vfs.zfs.prefetch_disable=1 in loader.conf FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Dec 3 07:05:03 UTC 2008 root@lokschuppen.lassitu.de:/usr/obj/usr/ src/sys/EISENBOOT amd64 Stefan -- Stefan Bethke Fon +49 170 346 0140 From ken at mthelicon.com Wed Dec 3 17:39:30 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Wed Dec 3 17:39:37 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Message-ID: <200812040139.26236.ken@mthelicon.com> On Wednesday 03 December 2008 23:33:53 Stefan Bethke wrote: > Am 03.12.2008 um 00:29 schrieb Peter Schuller: > >> I've noticed the past couple of days, when using the server (not very > >> often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 > >> minutes (no mouse movement, no keyboard events), while the drives > >> work like > >> crazy. > > > > I was not explicit about it, but FWIW in my case the hang is not due > > to drive saturation. The drives were mostly idle (except some stuff > > triggered by a buildworld I had going) during the extended period of > > ktorrent being unkillable. But again I never had this happen > > pre-CURRENT. > > Just a very brief "me too" (but possibly different effect): I'm stress > testing two machines I put together over the weekend with an endless > loop of make -j4 universe, with /usr/obj on ZFS, with a single disk. > One of the two machines has now been stuck for a couple of hours, and > trying to access /tank results in a hung process, as will zfs list. > > I'll reboot and see what happens, and if I can trigger it again, willt > try to produce more details. > > I have set > vfs.zfs.arc_max="512M" > vfs.zfs.prefetch_disable=1 > in loader.conf > > FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed > Dec 3 07:05:03 UTC 2008 root@lokschuppen.lassitu.de:/usr/obj/usr/ > src/sys/EISENBOOT amd64 Another Me to... I have had this problem with zfs as well, but not during a build. I was using ktorrent with a geli volume mounted within a zvol that I created in my raidz zpool. It appeared to lock up while doing its preallocation. Another strange lock up I had was when I had my SSD disk go wonkey on me and I lost the ZIL I had placed on it. The machine would boot up and when it tried to taste the ZFS drives, the machine would dead lock. After rebuilding the pool from various snapshot sends I made, everything seemed OK, however, recently (and I know this is subjective) my machine is acting a bit sluggish and under heavy load while building the world (-j4) I get very jerkey mouse movements while in KDE4.1 In my loader I have: vm.kmem_size_max="2G" vm.kmem_size="2G" vfs.zfs.arc_min="32M" vfs.zfs.arc_max="1G" and my pool is configured as: pool: PegaBase state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM PegaBase ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad16 ONLINE 0 0 0 ad18 ONLINE 0 0 0 ad20 ONLINE 0 0 0 ad22 ONLINE 0 0 0 ad24 ONLINE 0 0 0 cache ad14 ONLINE 0 0 0 errors: No known data errors feathers# -Peg From phreaki at gmail.com Wed Dec 3 20:24:53 2008 From: phreaki at gmail.com (Robert Atkinson) Date: Wed Dec 3 20:25:00 2008 Subject: i give up In-Reply-To: <20081203151537.GA1045@phenom.cordula.ws> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> Message-ID: <6fb2b4650812031953y14ddfeb4ycb4f5ae2bddffd49@mail.gmail.com> I second this idea since with my nearly a decade of FreeBSD administration under the belt, it is a waste of my time to throw it away. It is much cheaper for me to swap a card or even task a different machine for hardware that just isn't meant to be in FBSD. I'll use the penguin where I have too, I am forced to use it due to the VPS solution I chose. The price was right and it does what I wish it to do, but I would never, ever give up on the box under my desk and turn my back on this otherwise outstanding operating system. I have however, had many users who I show Linux give up because everything they own in the house is not supported. They always say "isn't linux supposed to be great?" and I can only say that they should learn to write device drivers and only buy hardware that has well known support. Thanks, Robert On Wed, Dec 3, 2008 at 10:15 AM, cpghost wrote: > On Tue, Dec 02, 2008 at 10:06:43PM -0600, Conrad J. Sabatier wrote: >> Best wishes to the FreeBSD community. No hard feelings, and I will >> still continue to checkout the latest sources from time to time just on >> the outside chance that a solution will eventually be found. >> >> Sincerest regards from a long-time FreeBSD user now in exile. :-( > > Changing the OS just because one specific piece of swappable and > replaceable hardware isn't supported... isn't that overreacting a > little bit? Can't you circumvent your specific problem by adding a > supported adapter to your system(s)... at least until the issue is > fixed? As sysadmins, we do this all the time, wether with Linux or > FreeBSD. > > I feel your pain, but maybe you've built up quite a bit of frustration > over this specific issue and need a little hiatus. > > I hope you'll come back soon. > >> Conrad J. Sabatier > > -cpghost. > > -- > Cordula's Web. http://www.cordula.ws/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From rnoland at FreeBSD.org Wed Dec 3 20:46:39 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Dec 3 20:46:47 2008 Subject: i give up In-Reply-To: <6fb2b4650812031953y14ddfeb4ycb4f5ae2bddffd49@mail.gmail.com> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> <6fb2b4650812031953y14ddfeb4ycb4f5ae2bddffd49@mail.gmail.com> Message-ID: <1228365988.1945.15.camel@wombat.2hip.net> On Wed, 2008-12-03 at 22:53 -0500, Robert Atkinson wrote: > I second this idea since with my nearly a decade of FreeBSD > administration under the belt, it is a waste of my time to throw it > away. It is much cheaper for me to swap a card or even task a > different machine for hardware that just isn't meant to be in FBSD. > > I'll use the penguin where I have too, I am forced to use it due to > the VPS solution I chose. The price was right and it does what I wish > it to do, but I would never, ever give up on the box under my desk and > turn my back on this otherwise outstanding operating system. > > I have however, had many users who I show Linux give up because > everything they own in the house is not supported. They always say > "isn't linux supposed to be great?" and I can only say that they > should learn to write device drivers and only buy hardware that has > well known support. Folks, I hate to contribute to this bikeshed, but developers are few, hardware specs are scarce and developers have to put what resources they have to work where it does the most good. I personally think that we do a fantastic job, given the resources available, but we can't support every random piece of hardware. For the original poster, I hope that you will reconsider your options and send specific details to a wider audience than Soren. If Soren is busy with life, perhaps someone else has the bandwidth to help with your issue. I generally find our developer community is quite willing to help sort out issues, often at the expense of having a life. All of that said, when given an option I also try to acquire hardware from vendors that provide open documentation as attempting to reverse engineer, or crib from linux code is the suck... Vendors that do provide open documentation are usually well supported. robert. > Thanks, > Robert > > > > > On Wed, Dec 3, 2008 at 10:15 AM, cpghost wrote: > > On Tue, Dec 02, 2008 at 10:06:43PM -0600, Conrad J. Sabatier wrote: > >> Best wishes to the FreeBSD community. No hard feelings, and I will > >> still continue to checkout the latest sources from time to time just on > >> the outside chance that a solution will eventually be found. > >> > >> Sincerest regards from a long-time FreeBSD user now in exile. :-( > > > > Changing the OS just because one specific piece of swappable and > > replaceable hardware isn't supported... isn't that overreacting a > > little bit? Can't you circumvent your specific problem by adding a > > supported adapter to your system(s)... at least until the issue is > > fixed? As sysadmins, we do this all the time, wether with Linux or > > FreeBSD. > > > > I feel your pain, but maybe you've built up quite a bit of frustration > > over this specific issue and need a little hiatus. > > > > I hope you'll come back soon. > > > >> Conrad J. Sabatier > > > > -cpghost. > > > > -- > > Cordula's Web. http://www.cordula.ws/ > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081204/5d432920/attachment.pgp From vehemens at verizon.net Wed Dec 3 22:35:21 2008 From: vehemens at verizon.net (vehemens) Date: Wed Dec 3 22:35:28 2008 Subject: i give up In-Reply-To: <1228365988.1945.15.camel@wombat.2hip.net> References: <20081128234155.0221e263@serene.no-ip.org> <6fb2b4650812031953y14ddfeb4ycb4f5ae2bddffd49@mail.gmail.com> <1228365988.1945.15.camel@wombat.2hip.net> Message-ID: <200812032139.47862.vehemens@verizon.net> On Wednesday 03 December 2008 08:46:28 pm Robert Noland wrote: > On Wed, 2008-12-03 at 22:53 -0500, Robert Atkinson wrote: > > I second this idea since with my nearly a decade of FreeBSD > > administration under the belt, it is a waste of my time to throw it > > away. It is much cheaper for me to swap a card or even task a > > different machine for hardware that just isn't meant to be in FBSD. > > > > I'll use the penguin where I have too, I am forced to use it due to > > the VPS solution I chose. The price was right and it does what I wish > > it to do, but I would never, ever give up on the box under my desk and > > turn my back on this otherwise outstanding operating system. > > > > I have however, had many users who I show Linux give up because > > everything they own in the house is not supported. They always say > > "isn't linux supposed to be great?" and I can only say that they > > should learn to write device drivers and only buy hardware that has > > well known support. > > Folks, I hate to contribute to this bikeshed, but developers are few, > hardware specs are scarce and developers have to put what resources they > have to work where it does the most good. I personally think that we do > a fantastic job, given the resources available, but we can't support > every random piece of hardware. > > For the original poster, I hope that you will reconsider your options > and send specific details to a wider audience than Soren. If Soren is > busy with life, perhaps someone else has the bandwidth to help with your > issue. I generally find our developer community is quite willing to > help sort out issues, often at the expense of having a life. > > All of that said, when given an option I also try to acquire hardware > from vendors that provide open documentation as attempting to reverse > engineer, or crib from linux code is the suck... Vendors that do > provide open documentation are usually well supported. If the device interface was more common between the BSDs and Linux, then the work would be minimal. As long as people create/insist on incompatible interfaces, then the work will always be time-consuming and difficult. From rea-fbsd at codelabs.ru Wed Dec 3 22:51:00 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Dec 3 22:51:07 2008 Subject: ASUS Eee PC S101 In-Reply-To: <20081203110844.96cc9d0a.stas@FreeBSD.org> References: <870d2e5a0812022051q2007b46eq4fd2115f76f3e5d6@mail.gmail.com> <20081203110844.96cc9d0a.stas@FreeBSD.org> Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081204/98d3c4c5/attachment.pgp From fujita at soum.co.jp Wed Dec 3 22:52:13 2008 From: fujita at soum.co.jp (FUJITA Kazutoshi) Date: Wed Dec 3 22:52:20 2008 Subject: boot panic with SiS 961 UDMA100 controller In-Reply-To: <20081202102237.GA61096@darkthrone.kvedulv.de> References: <20081202.084049.74179593.fujita@soum.co.jp> <20081202102237.GA61096@darkthrone.kvedulv.de> Message-ID: <20081204.155206.113950612.fujita@soum.co.jp> From: Michael Moll Subject: Re: boot panic with SiS 961 UDMA100 controller Date: Tue, 2 Dec 2008 11:22:37 +0100 > > i cvsuped after a long time (3 months), kernel panics when boot, > > in ata_pci_dmareset() > > > > my pc has > > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 2.5 on pci0 > > > > svn r183723 works, but r183724(and later) cause panic > > Maybe this patch resolves your problem also: > http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000669.html this patch is good for me. current kernel boot without panic. thanks! From freebsdlists at bsdunix.ch Wed Dec 3 22:58:20 2008 From: freebsdlists at bsdunix.ch (Thomas Vogt) Date: Wed Dec 3 22:58:27 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Message-ID: Hello Stefan Am 04.12.2008 um 00:33 schrieb Stefan Bethke: > Am 03.12.2008 um 00:29 schrieb Peter Schuller: > >>> I've noticed the past couple of days, when using the server (not >>> very >>> often), every now and then, the GUI (KDE 4.1) will "hang" for up >>> to 5 >>> minutes (no mouse movement, no keyboard events), while the drives >>> work like >>> crazy. >> >> I was not explicit about it, but FWIW in my case the hang is not due >> to drive saturation. The drives were mostly idle (except some stuff >> triggered by a buildworld I had going) during the extended period of >> ktorrent being unkillable. But again I never had this happen >> pre-CURRENT. > > Just a very brief "me too" (but possibly different effect): I'm > stress testing two machines I put together over the weekend with an > endless loop of make -j4 universe, with /usr/obj on ZFS, with a > single disk. One of the two machines has now been stuck for a couple > of hours, and trying to access /tank results in a hung process, as > will zfs list. > > I'll reboot and see what happens, and if I can trigger it again, > willt try to produce more details. > > I have set > vfs.zfs.arc_max="512M" > vfs.zfs.prefetch_disable=1 > in loader.conf > > FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: > Wed Dec 3 07:05:03 UTC 2008 root@lokschuppen.lassitu.de:/usr/ > obj/usr/src/sys/EISENBOOT amd64 Try to disable ZIL in loader.conf: vfs.zfs.zil_disable="1" It helped me to stop deadlocks during rsync processes. As long as you don't run any databases or any fsync() intensiv applications, i don't see any drawbacks in disabling zil. The drawbacks are for the applications itself not for ZFS. ZFS will be always consistent on disk due to its transaction model even without ZIL. Regards, Thomas From stas at FreeBSD.org Thu Dec 4 00:15:31 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Dec 4 00:15:38 2008 Subject: ASUS Eee PC S101 In-Reply-To: References: <870d2e5a0812022051q2007b46eq4fd2115f76f3e5d6@mail.gmail.com> <20081203110844.96cc9d0a.stas@FreeBSD.org> Message-ID: <20081204111702.998fa59b.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 4 Dec 2008 09:50:57 +0300 Eygene Ryabinkin mentioned: > Stanislav, *, good day. > > Wed, Dec 03, 2008 at 11:08:44AM +0300, Stanislav Sedov wrote: > > > % sysctl hw.psm.synaptics_support > > > sysctl: unknown oid 'hw.psm.synaptics_support' > > > > > > > This is not a sysctl variable, but kenv one. It should be set via > > /boot/loader.conf. > > May be the attached patch for psm(4) will be good? I had seen some > people who also tried to use sysctl here, because > "hw.psm.synaptics_support" looks like sysctl node name and psm(4) was > not explicitely stating where it should be set. The manual page clearly states it should be set at boot. The /boot/loader.conf isn't the single possible way to achive this, you can aslo set this manually in loaded, or there might be another ways to set kenv variables in another bootloaders. Claiming that the variable should be set in /boot/loader.conf isn't good, I think. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkk3kgQACgkQK/VZk+smlYHiJgCfe50mQr9O/SPPHTH0I3Ry7T5j P8EAnRxHdSXXLXKjwyaO13nk+JCvPDz6 =RQtA -----END PGP SIGNATURE----- From rdivacky at freebsd.org Thu Dec 4 00:24:46 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu Dec 4 00:24:52 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Message-ID: <20081204082008.GA79808@freebsd.org> On Thu, Dec 04, 2008 at 12:33:53AM +0100, Stefan Bethke wrote: > Am 03.12.2008 um 00:29 schrieb Peter Schuller: > > >>I've noticed the past couple of days, when using the server (not very > >>often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 > >>minutes (no mouse movement, no keyboard events), while the drives > >>work like > >>crazy. > > > >I was not explicit about it, but FWIW in my case the hang is not due > >to drive saturation. The drives were mostly idle (except some stuff > >triggered by a buildworld I had going) during the extended period of > >ktorrent being unkillable. But again I never had this happen > >pre-CURRENT. > > Just a very brief "me too" (but possibly different effect): I'm stress > testing two machines I put together over the weekend with an endless > loop of make -j4 universe, with /usr/obj on ZFS, with a single disk. > One of the two machines has now been stuck for a couple of hours, and > trying to access /tank results in a hung process, as will zfs list. I am not sure if it's relevant but I am getting deadlocks and stuck processes over the last few days (a week at most?) even with only UFS... does anyone see that? From rea-fbsd at codelabs.ru Thu Dec 4 01:30:20 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Dec 4 01:30:26 2008 Subject: ASUS Eee PC S101 In-Reply-To: <20081204111702.998fa59b.stas@FreeBSD.org> References: <870d2e5a0812022051q2007b46eq4fd2115f76f3e5d6@mail.gmail.com> <20081203110844.96cc9d0a.stas@FreeBSD.org> <20081204111702.998fa59b.stas@FreeBSD.org> Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081204/67f2ed4c/attachment.pgp From yanefbsd at gmail.com Thu Dec 4 01:47:03 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 4 01:47:10 2008 Subject: i give up In-Reply-To: <49338183.3040500@freebsd.org> References: <20081128234155.0221e263@serene.no-ip.org> <3cb459ed0811291342i524eaab3g1acadcd9cbdb638b@mail.gmail.com> <7d6fde3d0811291556g3f08a814td68466ad02dee4fc@mail.gmail.com> <200811291515.01962.beech@freebsd.org> <4932DD73.9000109@freebsd.org> <20081130235621.GA51043@duncan.reilly.home> <49338183.3040500@freebsd.org> Message-ID: <7d6fde3d0812040147w4dfb42b7iec5372e611399da4@mail.gmail.com> On Sun, Nov 30, 2008 at 10:17 PM, Tim Kientzle wrote: > Andrew Reilly wrote: >> >> On Sun, Nov 30, 2008 at 10:37:39AM -0800, Tim Kientzle wrote: >> >>> I wonder if there's some way to partially automate >>> collecting some of this information. >> >> There is. Just install ports/sysutils/bsdstats, set the >> appropriate frobs in /etc/rc.conf and be happy. Look at the >> http://bsdstats.org/ page from time to time. > > This is a start towards what I had in mind, but > still has a ways to go. Here are a few questions > I would like to ask of such a database: > > "What ethernet cards have people used with FreeBSD 7.0?" > > This would require being able to start from > a particular OS (and version?). > > "I have a Broadcom card, what driver do I need with FreeBSD 7?" > > This requires being able to navigate from OS/version > to device type, manufacturer, then driver. This > should also have callouts for any driver that's not > part of the GENERIC kernel. > > "pciconf just gave me an ID xyz123; what chip is that?" > > I see device names but not hardware-level IDs. > > "Any suggestions for a good network card to buy?" > > This information seems to stop at the chipset level. > When I go to the store, very few boxes have chipset > names on them. It would be good to give users the > option to provide a manufacturer (and product name?) > for the card or motherboard in use. Such information > would necessarily be more sporadic than the automatically > collected information, but it would build up over time. > > Based on the numbers here, I'm going to guess that > PC-BSD has this service turned on by default. You > should talk to folks maintaining installers for other > systems about possibly getting it integrated there. > (With clearly-worded notices about data being anonymous, > etc.) > > It would also be interesting to use this from the installer > to look up missing drivers (enumerate PCI IDs for any > device that didn't attach a driver and query the bsdstats > service for information about that device); this would > make it a lot easier for users to find drivers supported > out-of-tree. > > Such a database could provide very useful information to the > development community ("most popular unsupported ethernet > cards") and to users ("most popular supported ethernet > cards"). > > Tim Sounds like you're looking for something like Kudzu for Redhat. -Garrett From yanefbsd at gmail.com Thu Dec 4 01:51:35 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 4 01:51:43 2008 Subject: i give up In-Reply-To: <1228342356.2078.24.camel@wombat.2hip.net> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> <1228342356.2078.24.camel@wombat.2hip.net> Message-ID: <7d6fde3d0812040151t77ca6200n5aa5a644223c2040@mail.gmail.com> On Wed, Dec 3, 2008 at 2:12 PM, Robert Noland wrote: > On Wed, 2008-12-03 at 11:44 -0800, Artem Belevich wrote: >> > Second, DO NOT use motherboards with built-in video. These are almost >> > always nvidia chipsets and suffer from the nvidia problem. Also, the video >> > is crappy and buggy. >> >> I'd not discount them all as a class. Intel's built-in G33/G35 with >> recent DRM and x86-video-intel driver seem to work pretty well for >> accelerated 2D on the few boxes I have under FreeBSD-8/amd64. I even >> get 3D working on occasion. :-) > > Correct, Despite my occasional frustration with them, Intel is very > supportive. They are providing docs and code (linux code) and I have a > decent relationship with the Intel graphics devs. > > ATI/AMD has also become much more friendly and r500 and below should > work fairly well. r600+ is still under development. > > Interestingly enough, VIA just released docs on some of their chips as > well. I have it on my list to work on, but I don't yet have hardware to > work with. > > robert. > >> --Artem Eh? ATI can't write drivers to get themselves out of a cardboard box on Linux, let alone FreeBSD. I have little faith that they'll get functional 64-bit drivers before nVidia does, as ATI as definitely demonstrated that they don't care for the *BSD market as much as nVidia has. -Garrett From yanefbsd at gmail.com Thu Dec 4 01:54:06 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 4 01:54:13 2008 Subject: i give up In-Reply-To: <4936D0C2.2090306@zircon.seattle.wa.us> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> Message-ID: <7d6fde3d0812040154g30fc2c2egf82f5fc2dd1d9e83@mail.gmail.com> On Wed, Dec 3, 2008 at 10:32 AM, Joe Kelsey wrote: > Conrad J. Sabatier wrote: >> >> On Sat, 29 Nov 2008 14:49:02 +0900 >> Randy Bush wrote: >> >> >>> >>> what a tragic story. and zero technical info, like even what your >>> controller is. best of luck in penguin land. bye! >>> >>> randy >>> >> >> No, actually, I forwarded to Soren all the information I could glean >> from Windows Vista, Linux and FreeBSD (which I managed to install on an >> external USB drive). I also applied the patches he sent me, which >> failed to cure the problem, and have been monitoring the mailing lists >> and CVS repo for any signs of progress, but so far I've seen nothing. >> > > The first step in upgrading a FreeBSD system is to NEVER purchase ANYTHING > with an nVidia logo anywhere near it. nVidia purposelessly witholds > programming information form free developers, so there is virtually no > chance for being able to make anything with nVidia work at any time. > > Second, DO NOT use motherboards with built-in video. These are almost > always nvidia chipsets and suffer from the nvidia problem. Also, the video > is crappy and buggy. > > Several people have mentioned reliable internet shops to order proven > hardware from. Whenever you walk into a "local" computer store, you get no > expertise in anything non-windoze. Go somewhere where you can use a > magnifying glass to examine the chips and actually determine whether or not > you are likely to suffer the nvidia disaster. Write down the motherboard > information and ask on the mailing lists. I had a horrid problem with > crappy SATA chips on my motherboard, and I had to buy two different SATA PCI > cards before I got one that worked. > > Trade in the defective motherboard to get a new one that works. Think > before you ever try to buy anything with nVidia logos on it, unless you are > willing to run Linux crap. > > Good luck in the future. > > /Joe Disclaimer: the above assumptions only apply (for the most part) to motherboards with nVidia chipsets. Read the specs, do your homework, and 9/10 Intel chipsets with onboard video will have Intel graphics chipsets and AMD motherboard chipsets will come with ATI onboard chipsets (surprise, surprise). -Garrett From doublef-ctm at yandex.ru Thu Dec 4 02:12:23 2008 From: doublef-ctm at yandex.ru (Sergey Zaharchenko) Date: Thu Dec 4 02:12:33 2008 Subject: i give up In-Reply-To: <4936D0C2.2090306@zircon.seattle.wa.us> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> Message-ID: <20081204095204.GA64194@shark.localdomain> Hello Joe! Wed, Dec 03, 2008 at 10:32:34AM -0800 you wrote: > Conrad J. Sabatier wrote: > > On Sat, 29 Nov 2008 14:49:02 +0900 > > Randy Bush wrote: > > > > > >> what a tragic story. and zero technical info, like even what your > >> controller is. best of luck in penguin land. bye! > >> > >> randy > >> > > > > No, actually, I forwarded to Soren all the information I could glean > > from Windows Vista, Linux and FreeBSD (which I managed to install on an > > external USB drive). I also applied the patches he sent me, which > > failed to cure the problem, and have been monitoring the mailing lists > > and CVS repo for any signs of progress, but so far I've seen nothing. > > > The first step in upgrading a FreeBSD system is to NEVER purchase > ANYTHING with an nVidia logo anywhere near it. Huh, I haven't had any serious problems with neither the nForce2 chipset my m/b is based on (including the nfe/nve Ethernet card) nor with the nVidia FX 5200 video card. I guess that's because both are quite antique by now. In general, the newer the stuff, the harder it might be to get it to work. This might apply to nVidia more than to other stuff, but in general it's just better to be able to check compatibility, e.g. using a LiveCD on a friend's machine... -- DoubleF No virus detected in this message. Ehrm, wait a minute... /kernel: pid 56921 (antivirus), uid 32000: exited on signal 9 Oh yes, no virus:) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081204/5773d90c/attachment.pgp From keramida at freebsd.org Thu Dec 4 02:42:20 2008 From: keramida at freebsd.org (Giorgos Keramidas) Date: Thu Dec 4 02:42:27 2008 Subject: i give up In-Reply-To: <6fb2b4650812031953y14ddfeb4ycb4f5ae2bddffd49@mail.gmail.com> (Robert Atkinson's message of "Wed, 3 Dec 2008 22:53:10 -0500") References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> <6fb2b4650812031953y14ddfeb4ycb4f5ae2bddffd49@mail.gmail.com> Message-ID: <87k5agbgzl.fsf@kobe.laptop> On Wed, 3 Dec 2008 22:53:10 -0500, "Robert Atkinson" wrote: > I have however, had many users who I show Linux give up because > everything they own in the house is not supported. They always say > "isn't linux supposed to be great?" and I can only say that they > should learn to write device drivers and only buy hardware that has > well known support. Isn't this the case with *any* operating system? The main reason that companies like Sun publish extensive hardware compatibility lists is to avoid getting thousands of support calls that say ``I bought this random modem from a retail store for USD $2, and it attaches as a generic USB device on Solaris. How do I make it work? WTF, why is Solaris so hopelessly broken?'' Most of the time buying hardware that is known to be supported pays back in avoiding lost time, frustration and many hours of troubleshooting driver issues. I'm sure Conrad already knows that buying hardware that is known to be supported is worth the trouble of looking for it. That's why I was a bit baffled by the drama-like tone of the thread. All I can say at this point to Conrad is ``Good luck with your future endeavors in the Linux land! I'll be glad to see you continue to appear on the lists, and use FreeBSD in those machines of yours that support it, and if you manage to fix the one that triggered this, we are always here :-)''. From marius at nuenneri.ch Thu Dec 4 03:02:46 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Dec 4 03:02:54 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Message-ID: On Thu, Dec 4, 2008 at 7:39 AM, Thomas Vogt wrote: > Hello Stefan > > Am 04.12.2008 um 00:33 schrieb Stefan Bethke: >> >> Am 03.12.2008 um 00:29 schrieb Peter Schuller: >> >>>> I've noticed the past couple of days, when using the server (not very >>>> often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 >>>> minutes (no mouse movement, no keyboard events), while the drives work >>>> like >>>> crazy. >>> >>> I was not explicit about it, but FWIW in my case the hang is not due >>> to drive saturation. The drives were mostly idle (except some stuff >>> triggered by a buildworld I had going) during the extended period of >>> ktorrent being unkillable. But again I never had this happen >>> pre-CURRENT. >> >> Just a very brief "me too" (but possibly different effect): I'm stress >> testing two machines I put together over the weekend with an endless loop of >> make -j4 universe, with /usr/obj on ZFS, with a single disk. One of the two >> machines has now been stuck for a couple of hours, and trying to access >> /tank results in a hung process, as will zfs list. >> >> I'll reboot and see what happens, and if I can trigger it again, willt try >> to produce more details. >> >> I have set >> vfs.zfs.arc_max="512M" >> vfs.zfs.prefetch_disable=1 >> in loader.conf >> >> FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Dec >> 3 07:05:03 UTC 2008 >> root@lokschuppen.lassitu.de:/usr/obj/usr/src/sys/EISENBOOT amd64 > > Try to disable ZIL in loader.conf: > vfs.zfs.zil_disable="1" > > It helped me to stop deadlocks during rsync processes. As long as you don't > run any databases or any fsync() intensiv applications, i don't see any > drawbacks in disabling zil. The drawbacks are for the applications itself > not for ZFS. ZFS will be always consistent on disk due to its transaction > model even without ZIL. While you are talking about it: Does anyone know if the fsync blocks until the data is really stable on the device or if it simply returns when ZIL is disabled? In my understanding the topmost block would need to be written for the "commit" to be on disk. From yanefbsd at gmail.com Thu Dec 4 03:24:29 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 4 03:24:35 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: References: Message-ID: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> On Tue, Dec 2, 2008 at 5:01 PM, Maksim Yevmenkin wrote: > Dear Hackers, > > can someone please review the attached small patch for syscons and > kbd? it should be a no-op mostly. the patch basically does > > 1) removes bogus layering in syscons, i.e. basically removes sccngetch(); > 2) implements advisory lock for kbd (based on atomic(9)); > 3) implements new POLLED flag for kbd; > > this is a part of a plan to fix keyboard access races in syscons. > > thanks, > max Max, Why are you double and triple negating on this line? + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); -Garrett From yanefbsd at gmail.com Thu Dec 4 03:40:45 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 4 03:41:16 2008 Subject: freebsd current @ 20081201 In-Reply-To: <6101e8c40811301536g7229841cx741cafcfcce4df69@mail.gmail.com> References: <6101e8c40811301536g7229841cx741cafcfcce4df69@mail.gmail.com> Message-ID: <7d6fde3d0812040340h4ca854f6o2e078c48790845b0@mail.gmail.com> On Sun, Nov 30, 2008 at 3:36 PM, Oliver Pinter wrote: > LOR error on amd64 More data? -Garrett From bzeeb-lists at lists.zabbadoz.net Thu Dec 4 03:50:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Dec 4 03:50:17 2008 Subject: building module regression In-Reply-To: <3a142e750811300815we050f66l5abc85d02fe3931b@mail.gmail.com> References: <3a142e750811300815we050f66l5abc85d02fe3931b@mail.gmail.com> Message-ID: <20081204114553.E80401@maildrop.int.zabbadoz.net> On Sun, 30 Nov 2008, Paul B. Mahol wrote: Hi, > With latest kernel it is no more possible > to do something like this (with net drivers): > > # cd /sys/modules/mii && make this hsould have been fixed ~36 hours ago, in case you haven't seen the commit. In case there's still a problem please let me know. Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From rea-fbsd at codelabs.ru Thu Dec 4 03:52:31 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Dec 4 03:52:39 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> Message-ID: Garrett, good day. Thu, Dec 04, 2008 at 03:24:28AM -0800, Garrett Cooper wrote: > On Tue, Dec 2, 2008 at 5:01 PM, Maksim Yevmenkin > Why are you double and triple negating on this line? > + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); Double negation is easy -- !!N = 1 for int N != 0, so it is the way to turn N != 0 to one. Triple negation? I am out of guesses, because it seems redundant to me: !0 = 1, !5 = 0, so adding another two negations is seem to be worthless. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081204/ce23eb94/attachment.pgp From onemda at gmail.com Thu Dec 4 04:06:37 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Dec 4 04:06:44 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <20081204082008.GA79808@freebsd.org> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <20081204082008.GA79808@freebsd.org> Message-ID: <3a142e750812040406k5b7d758xadb0e441bd93a7d0@mail.gmail.com> On 12/4/08, Roman Divacky wrote: > On Thu, Dec 04, 2008 at 12:33:53AM +0100, Stefan Bethke wrote: >> Am 03.12.2008 um 00:29 schrieb Peter Schuller: >> >> >>I've noticed the past couple of days, when using the server (not very >> >>often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 >> >>minutes (no mouse movement, no keyboard events), while the drives >> >>work like >> >>crazy. >> > >> >I was not explicit about it, but FWIW in my case the hang is not due >> >to drive saturation. The drives were mostly idle (except some stuff >> >triggered by a buildworld I had going) during the extended period of >> >ktorrent being unkillable. But again I never had this happen >> >pre-CURRENT. >> >> Just a very brief "me too" (but possibly different effect): I'm stress >> testing two machines I put together over the weekend with an endless >> loop of make -j4 universe, with /usr/obj on ZFS, with a single disk. >> One of the two machines has now been stuck for a couple of hours, and >> trying to access /tank results in a hung process, as will zfs list. > > I am not sure if it's relevant but I am getting deadlocks and stuck > processes over the last few days (a week at most?) even with only > UFS... > > does anyone see that? I do not, how it can be reproduced? -- Paul From matthias.andree at gmx.de Thu Dec 4 04:12:21 2008 From: matthias.andree at gmx.de (Matthias Andree) Date: Thu Dec 4 04:12:28 2008 Subject: i give up In-Reply-To: <20081204095204.GA64194@shark.localdomain> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> <20081204095204.GA64194@shark.localdomain> Message-ID: <4937C921.20103@gmx.de> Sergey Zaharchenko schrieb: > Huh, I haven't had any serious problems with neither the nForce2 chipset > my m/b is based on (including the nfe/nve Ethernet card) nor with the > nVidia FX 5200 video card. I guess that's because both are quite antique > by now. In general, the newer the stuff, the harder it might be to get > it to work. This might apply to nVidia more than to other stuff, but in > general it's just better to be able to check compatibility, e.g. using a > LiveCD on a friend's machine... OTOH, the "older" is where new problems start, nVidia has several series of "legacy" drivers, and they show various issues if used with recent Linux kernels, or recent X.org server version... The FX5200 is legacy now, supported by the (nowadays outdated) 173 series of drivers -- which relies on compat5x and doesn't support PAE, to mention two issues with that... From rdivacky at freebsd.org Thu Dec 4 04:17:47 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu Dec 4 04:17:54 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <3a142e750812040406k5b7d758xadb0e441bd93a7d0@mail.gmail.com> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <20081204082008.GA79808@freebsd.org> <3a142e750812040406k5b7d758xadb0e441bd93a7d0@mail.gmail.com> Message-ID: <20081204121308.GA12048@freebsd.org> On Thu, Dec 04, 2008 at 01:06:35PM +0100, Paul B. Mahol wrote: > On 12/4/08, Roman Divacky wrote: > > On Thu, Dec 04, 2008 at 12:33:53AM +0100, Stefan Bethke wrote: > >> Am 03.12.2008 um 00:29 schrieb Peter Schuller: > >> > >> >>I've noticed the past couple of days, when using the server (not very > >> >>often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 > >> >>minutes (no mouse movement, no keyboard events), while the drives > >> >>work like > >> >>crazy. > >> > > >> >I was not explicit about it, but FWIW in my case the hang is not due > >> >to drive saturation. The drives were mostly idle (except some stuff > >> >triggered by a buildworld I had going) during the extended period of > >> >ktorrent being unkillable. But again I never had this happen > >> >pre-CURRENT. > >> > >> Just a very brief "me too" (but possibly different effect): I'm stress > >> testing two machines I put together over the weekend with an endless > >> loop of make -j4 universe, with /usr/obj on ZFS, with a single disk. > >> One of the two machines has now been stuck for a couple of hours, and > >> trying to access /tank results in a hung process, as will zfs list. > > > > I am not sure if it's relevant but I am getting deadlocks and stuck > > processes over the last few days (a week at most?) even with only > > UFS... > > > > does anyone see that? > > I do not, how it can be reproduced? I am seeing it when doing a lot of io activity, torrents + cvs/svn up seems to trigger it quite successfully From eculp at encontacto.net Thu Dec 4 06:57:32 2008 From: eculp at encontacto.net (eculp) Date: Thu Dec 4 06:57:40 2008 Subject: Kernel doesn't compile since Dec 1. Stops at /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c Message-ID: <20081204084727.16714wjmus539s4k@econet.encontacto.net> I have been cvsuping, compiling and installing all daily with no changes nor errors until the morning of Dec 2 and I now get to the following error: cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contri b/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-gro wth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno- sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c -I/usr/ src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c: In function 'ar5416ProcRxDesc': /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:111: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:119: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:120: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:121: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:122: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:123: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:124: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:135: error: 'struct ath_rx_status' has no member named 'rs_isaggr' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:136: error: 'struct ath_rx_status' has no member named 'rs_moreaggr' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:140: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:142: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:145: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:147: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:149: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:151: error: 'struct ath_rx_status' has no member named 'rs_flags' *** Error code 1 Stop in /usr/obj/usr/src/sys/ENCONTACTO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Maybe I should go to Sam's patches and try his latest? Thanks, ed From bms at FreeBSD.org Thu Dec 4 07:01:04 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Dec 4 07:01:10 2008 Subject: [PATCH] ppbus/ppc locking In-Reply-To: <200811191503.02192.jhb@freebsd.org> References: <200811191503.02192.jhb@freebsd.org> Message-ID: <4937EC6D.7050703@FreeBSD.org> John Baldwin wrote: > Please test! This is the last non-MPSAFE network driver at this point. This > patch adds locking for the ppbus(4)/ppc(4) devices and the various ppbus > child devices (lpt, vpo, lpbb, ppi, pps). The basic model is that a single > mutex in the ppc(4) driver protects the ppc0 hardware and is shared with the > various child drivers. Two drivers now have detach methods that did not have > them before (plip and ppi). I've done some simple testing on my laptop (able > to load the drivers and do some simple things w/o panic'ing or tripping > assertions), but I am not really able to test the peripheral drivers fully. > > http://www.FreeBSD.org/~jhb/patches/ppc_locking.patch > > Runway lpt Giant is an occasionally show stopping issue for me because my printer is attached via the plt port. I may get time to look at this later on... I tried applying these patches against 7-STABLE. ppc_cleanup.patch applied OK to 7. ppc_intr.patch applied OK to 7 with interrupt.h change manually merged, and some fixups to ppc.c for earlier intr_event kpi. ppc_locking.patch does not apply cleanly, and it's too much for me to deal with right now. I found I had to hack up an existing 7 tree in /usr/src to get things to compile because of the wide scope of the changes (touching kern, sys etc), I couldn't just use an svn checkout to work from. cheers BMS From jkoshy at freebsd.org Thu Dec 4 07:04:59 2008 From: jkoshy at freebsd.org (Joseph Koshy) Date: Thu Dec 4 07:05:30 2008 Subject: hwpmc deadlock: processes hang on pmc-sx In-Reply-To: <20081111215413.7aa9ea86@tau.draftnet> References: <20081111204941.4bfdb7c4@tau.draftnet> <20081111215413.7aa9ea86@tau.draftnet> Message-ID: <84dead720812040704i7e6e1c66te16090eb3343e04@mail.gmail.com> Please try the patch at: http://people.freebsd.org/~jkoshy/download/hwpmc-deadlock.patch.2.gz MD5 (hwpmc-deadlock.patch.2.gz) = 0eb9292dff4fef1bedb19f1a94eee75c and let me know how it goes. Koshy From ken at mthelicon.com Thu Dec 4 07:20:30 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Thu Dec 4 07:20:38 2008 Subject: Kernel doesn't compile since Dec 1. Stops at/usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c In-Reply-To: <20081204084727.16714wjmus539s4k@econet.encontacto.net> References: <20081204084727.16714wjmus539s4k@econet.encontacto.net> Message-ID: I found the Atheros driver is broken in AMD64. If you are not using the Atheros wireless adapter, remove any reference to it from your config file, IE: #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath and recompile... -Peg ----- Original Message ----- From: "eculp" To: "freebsd-current" Sent: Thursday, December 04, 2008 2:47 PM Subject: Kernel doesn't compile since Dec 1. Stops at/usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c I have been cvsuping, compiling and installing all daily with no changes nor errors until the morning of Dec 2 and I now get to the following error: cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contri b/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-gro wth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno- sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c -I/usr/ src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c: In function 'ar5416ProcRxDesc': /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:111: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:119: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:120: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:121: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:122: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:123: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:124: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:135: error: 'struct ath_rx_status' has no member named 'rs_isaggr' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:136: error: 'struct ath_rx_status' has no member named 'rs_moreaggr' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:140: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:142: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:145: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:147: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:149: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:151: error: 'struct ath_rx_status' has no member named 'rs_flags' *** Error code 1 Stop in /usr/obj/usr/src/sys/ENCONTACTO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Maybe I should go to Sam's patches and try his latest? Thanks, ed _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From lulf at stud.ntnu.no Thu Dec 4 07:23:59 2008 From: lulf at stud.ntnu.no (Ulf Lilleengen) Date: Thu Dec 4 07:24:06 2008 Subject: Kernel doesn't compile since Dec 1. Stops at /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c In-Reply-To: <20081204084727.16714wjmus539s4k@econet.encontacto.net> References: <20081204084727.16714wjmus539s4k@econet.encontacto.net> Message-ID: <20081204142356.GA2945@nobby.lan> On Thu, Dec 04, 2008 at 08:47:27AM -0600, eculp wrote: > I have been cvsuping, compiling and installing all daily with no > changes nor errors until the morning of Dec 2 and I now get to the > following error: > > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar > ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contri > b/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h > -fno-common -finline-limit=8000 --param inline-unit-gro > wth=100 --param large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno- > sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c -I/usr/ > src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal > /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c: In function > 'ar5416ProcRxDesc': > /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:111: error: 'struct > *** Error code 1 *snip* > > Stop in /usr/src. > > Maybe I should go to Sam's patches and try his latest? > Have you read UPDATING and followed the instructions there? 20081130: __FreeBSD_version 800057 marks the switchover from the binary ath hal to source code. Users must add the line: options AH_SUPPORT_AR5416 to their kernel config files when specifying: device ath_hal The ath_hal module no longer exists; the code is now compiled together with the driver in the ath module. It is now possible to tailor chip support (i.e. reduce the set of chips and thereby the code size); consult ath_hal(4) for details. -- Ulf Lilleengen From maksim.yevmenkin at gmail.com Thu Dec 4 07:24:42 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Dec 4 07:24:48 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> Message-ID: On Thu, Dec 4, 2008 at 3:24 AM, Garrett Cooper wrote: > On Tue, Dec 2, 2008 at 5:01 PM, Maksim Yevmenkin > wrote: >> Dear Hackers, >> >> can someone please review the attached small patch for syscons and >> kbd? it should be a no-op mostly. the patch basically does >> >> 1) removes bogus layering in syscons, i.e. basically removes sccngetch(); >> 2) implements advisory lock for kbd (based on atomic(9)); >> 3) implements new POLLED flag for kbd; >> >> this is a part of a plan to fix keyboard access races in syscons. >> >> thanks, >> max > > Max, > Why are you double and triple negating on this line? > > + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); the idea was to ensure that kbd->kb_locked variable only takes values 0 (zero) and 1 (one). thanks, max From onemda at gmail.com Thu Dec 4 07:34:43 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Dec 4 07:34:49 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> Message-ID: <3a142e750812040734g26ecda23pfe646c27521cdc82@mail.gmail.com> On 12/4/08, Maksim Yevmenkin wrote: > On Thu, Dec 4, 2008 at 3:24 AM, Garrett Cooper wrote: >> On Tue, Dec 2, 2008 at 5:01 PM, Maksim Yevmenkin >> wrote: >>> Dear Hackers, >>> >>> can someone please review the attached small patch for syscons and >>> kbd? it should be a no-op mostly. the patch basically does >>> >>> 1) removes bogus layering in syscons, i.e. basically removes sccngetch(); >>> 2) implements advisory lock for kbd (based on atomic(9)); >>> 3) implements new POLLED flag for kbd; >>> >>> this is a part of a plan to fix keyboard access races in syscons. >>> >>> thanks, >>> max >> >> Max, >> Why are you double and triple negating on this line? >> >> + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); > > the idea was to ensure that kbd->kb_locked variable only takes values > 0 (zero) and 1 (one). > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Maybe it is usefull to report, maybe not. I'm experiencing keyboard (atkbd) death now and then when inside Xorg once Xorg is started in following (racey) way: alias onlyx "/usr/local/bin/xinit -- -nolisten tcp -br & && exit" and /etc/csh.logout: echo $TERM | grep cons25 >> /dev/null && clear && vidcontrol -C I will test it and report if it fix my "problem". -- Paul From onemda at gmail.com Thu Dec 4 08:00:26 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Dec 4 08:00:33 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: <3a142e750812040734g26ecda23pfe646c27521cdc82@mail.gmail.com> References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> <3a142e750812040734g26ecda23pfe646c27521cdc82@mail.gmail.com> Message-ID: <3a142e750812040800h5bfa55fcsf52675c425183f8a@mail.gmail.com> On 12/4/08, Paul B. Mahol wrote: > On 12/4/08, Maksim Yevmenkin wrote: >> On Thu, Dec 4, 2008 at 3:24 AM, Garrett Cooper wrote: >>> On Tue, Dec 2, 2008 at 5:01 PM, Maksim Yevmenkin >>> wrote: >>>> Dear Hackers, >>>> >>>> can someone please review the attached small patch for syscons and >>>> kbd? it should be a no-op mostly. the patch basically does >>>> >>>> 1) removes bogus layering in syscons, i.e. basically removes >>>> sccngetch(); >>>> 2) implements advisory lock for kbd (based on atomic(9)); >>>> 3) implements new POLLED flag for kbd; >>>> >>>> this is a part of a plan to fix keyboard access races in syscons. >>>> >>>> thanks, >>>> max >>> >>> Max, >>> Why are you double and triple negating on this line? >>> >>> + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); >> >> the idea was to ensure that kbd->kb_locked variable only takes values >> 0 (zero) and 1 (one). >> >> thanks, >> max >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > Maybe it is usefull to report, maybe not. > > I'm experiencing keyboard (atkbd) death now and then when inside Xorg once > Xorg is started in following (racey) way: > > alias onlyx "/usr/local/bin/xinit -- -nolisten tcp -br & && > exit" > > and /etc/csh.logout: > > echo $TERM | grep cons25 >> /dev/null && clear && vidcontrol -C > > I will test it and report if it fix my "problem". No luck. Typing blindly I managed to panic from kdb, and I got only this: KDB: enter: manual escape to debugger panic: from debugger cpuid = 1 KDB: stack backtrace: panic: bufwrite: buffer is not busy??? cpuid = 1 KDB: enter: panic exclusive sleep mutex Giant (Giant) r = 1 (0xc0725a70) locked @ /usr/src/sys/dev /syscons/syscons.c:618 -- Paul From maksim.yevmenkin at gmail.com Thu Dec 4 09:18:54 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Dec 4 09:19:01 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> Message-ID: On Thu, Dec 4, 2008 at 3:33 AM, Eygene Ryabinkin wrote: > Garrett, good day. > > Thu, Dec 04, 2008 at 03:24:28AM -0800, Garrett Cooper wrote: >> On Tue, Dec 2, 2008 at 5:01 PM, Maksim Yevmenkin >> Why are you double and triple negating on this line? >> + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); > > Double negation is easy -- !!N = 1 for int N != 0, so it is the way to > turn N != 0 to one. yep, that was the idea. > Triple negation? I am out of guesses, because it > seems redundant to me: !0 = 1, !5 = 0, so adding another two negations > is seem to be worthless. well, that's just silly typo (blame my sticky fingers). you are correct single negation should work just as good :) thanks for catching this guys, i fixed it. thanks, max > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > From maksim.yevmenkin at gmail.com Thu Dec 4 09:27:09 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Dec 4 09:27:15 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: <3a142e750812040800h5bfa55fcsf52675c425183f8a@mail.gmail.com> References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> <3a142e750812040734g26ecda23pfe646c27521cdc82@mail.gmail.com> <3a142e750812040800h5bfa55fcsf52675c425183f8a@mail.gmail.com> Message-ID: On Thu, Dec 4, 2008 at 8:00 AM, Paul B. Mahol wrote: > On 12/4/08, Paul B. Mahol wrote: >> On 12/4/08, Maksim Yevmenkin wrote: >>> On Thu, Dec 4, 2008 at 3:24 AM, Garrett Cooper wrote: >>>> On Tue, Dec 2, 2008 at 5:01 PM, Maksim Yevmenkin >>>> wrote: >>>>> Dear Hackers, >>>>> >>>>> can someone please review the attached small patch for syscons and >>>>> kbd? it should be a no-op mostly. the patch basically does >>>>> >>>>> 1) removes bogus layering in syscons, i.e. basically removes >>>>> sccngetch(); >>>>> 2) implements advisory lock for kbd (based on atomic(9)); >>>>> 3) implements new POLLED flag for kbd; >>>>> >>>>> this is a part of a plan to fix keyboard access races in syscons. >>>>> >>>>> thanks, >>>>> max >>>> >>>> Max, >>>> Why are you double and triple negating on this line? >>>> >>>> + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); >>> >>> the idea was to ensure that kbd->kb_locked variable only takes values >>> 0 (zero) and 1 (one). >>> >>> thanks, >>> max >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> >> Maybe it is usefull to report, maybe not. >> >> I'm experiencing keyboard (atkbd) death now and then when inside Xorg once >> Xorg is started in following (racey) way: >> >> alias onlyx "/usr/local/bin/xinit -- -nolisten tcp -br & && >> exit" >> >> and /etc/csh.logout: >> >> echo $TERM | grep cons25 >> /dev/null && clear && vidcontrol -C >> >> I will test it and report if it fix my "problem". > > No luck. sorry, but the patch was not really intended to fix anything yet. it was just a small bit. > Typing blindly I managed to panic from kdb, and I got only this: > > KDB: enter: manual escape to debugger > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > panic: bufwrite: buffer is not busy??? this looks like it came from ffs_bufwrite() in ufs/ffs/ffs_vfsops.c > cpuid = 1 > KDB: enter: panic > exclusive sleep mutex Giant (Giant) r = 1 (0xc0725a70) locked @ /usr/src/sys/dev > /syscons/syscons.c:618 > can you please setup a serial console and reproduce the panic? thanks max From onemda at gmail.com Thu Dec 4 10:10:53 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Dec 4 10:11:00 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> <3a142e750812040734g26ecda23pfe646c27521cdc82@mail.gmail.com> <3a142e750812040800h5bfa55fcsf52675c425183f8a@mail.gmail.com> Message-ID: <3a142e750812041010n34fbb9bdm9032299d1ab734ab@mail.gmail.com> On 12/4/08, Maksim Yevmenkin wrote: > On Thu, Dec 4, 2008 at 8:00 AM, Paul B. Mahol wrote: >> On 12/4/08, Paul B. Mahol wrote: >>> On 12/4/08, Maksim Yevmenkin wrote: >>>> On Thu, Dec 4, 2008 at 3:24 AM, Garrett Cooper >>>> wrote: >>>>> On Tue, Dec 2, 2008 at 5:01 PM, Maksim Yevmenkin >>>>> wrote: >>>>>> Dear Hackers, >>>>>> >>>>>> can someone please review the attached small patch for syscons and >>>>>> kbd? it should be a no-op mostly. the patch basically does >>>>>> >>>>>> 1) removes bogus layering in syscons, i.e. basically removes >>>>>> sccngetch(); >>>>>> 2) implements advisory lock for kbd (based on atomic(9)); >>>>>> 3) implements new POLLED flag for kbd; >>>>>> >>>>>> this is a part of a plan to fix keyboard access races in syscons. >>>>>> >>>>>> thanks, >>>>>> max >>>>> >>>>> Max, >>>>> Why are you double and triple negating on this line? >>>>> >>>>> + return (atomic_cmpset_acq_int(&kbd->kb_locked, !!!on, !!on)); >>>> >>>> the idea was to ensure that kbd->kb_locked variable only takes values >>>> 0 (zero) and 1 (one). >>>> >>>> thanks, >>>> max >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>>> >>> >>> Maybe it is usefull to report, maybe not. >>> >>> I'm experiencing keyboard (atkbd) death now and then when inside Xorg >>> once >>> Xorg is started in following (racey) way: >>> >>> alias onlyx "/usr/local/bin/xinit -- -nolisten tcp -br & && >>> exit" >>> >>> and /etc/csh.logout: >>> >>> echo $TERM | grep cons25 >> /dev/null && clear && vidcontrol -C >>> >>> I will test it and report if it fix my "problem". >> >> No luck. > > sorry, but the patch was not really intended to fix anything yet. it > was just a small bit. > >> Typing blindly I managed to panic from kdb, and I got only this: >> >> KDB: enter: manual escape to debugger Manul ecape to debugger. >> panic: from debugger >> cpuid = 1 >> KDB: stack backtrace: >> panic: bufwrite: buffer is not busy??? > > this looks like it came from ffs_bufwrite() in ufs/ffs/ffs_vfsops.c > >> cpuid = 1 >> KDB: enter: panic >> exclusive sleep mutex Giant (Giant) r = 1 (0xc0725a70) locked @ >> /usr/src/sys/dev >> /syscons/syscons.c:618 >> > > can you please setup a serial console and reproduce the panic? > > thanks > max > No, it is not panic, I manualy paniced it because display was blank and keyboard did not worked inside Xorg (ctr+alt+backpace didn't work), but ctrl+alt+esc worked after some time and I blindly typed panic, followed with enter. -- Paul From peterjeremy at optushome.com.au Thu Dec 4 11:08:52 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Dec 4 11:08:59 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> Message-ID: <20081204190848.GG58682@server.vk2pj.dyndns.org> On 2008-Dec-02 21:00:23 -0500, alexus wrote: >as far as I understood HEAD is 8.0-CURRENT Yes. >is there a way for us to start using it before 8.0 hits -RELEASE There are two ways. The first is: 1) Checkout a copy of the HEAD src tree via your chosen source tracker (cvs/cvsup/ctm/...) 2) Follow the instructions in /usr/src/UPDATING to build and install 3) Test well on a non-production box in as close to your production environment as possible. Be prepared to feed back problems and test fixes. 4) Once you are satisfied that it works for you, place it in production. This is basically the same as any other FreeBSD release except that you should test more rigourously. Your second option is to take the patches from r185435 and apply them to your 7.x source tree. This may take some massaging (I'm not sure how much 7 and 8 differ in the affected areas). bz@ may be interested in your experiences. Then test and roll-out as above. >lucky), I somehow was under impression (and i guess i was wrong) that >it will come out in 7.1, It's far too late for any new features in 7.1 but the commit log says it should be in 7.2. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081204/823a7c6a/attachment.pgp From onemda at gmail.com Thu Dec 4 12:21:58 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Dec 4 12:22:05 2008 Subject: [Call for Test] a patch for kern/121385 - Unionfs cross mount issue In-Reply-To: <4917E0C9.5020105@ongs.co.jp> References: <4917E0C9.5020105@ongs.co.jp> Message-ID: <3a142e750812041221v26520a53q4f7df488af607305@mail.gmail.com> On 11/10/08, Daichi GOTO wrote: > Hi Unionfs users > > About kern/121385 - Unionfs cross mount issue, by discussion at > EuroBSDCon2008, > unionfs does not allow user to do cross mount operation. If you have some > interest > this issue, please get this patch and try with current. I'll commit this > patch after 1 week later. > > PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121385 > Patch: > http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-cross-mount.diff > > This issue was discussed at EuroBSDCon2008 FreeBSD developer summit. > Thanks for hrs and gnn :) > > -- > Daichi GOTO, http://people.freebsd.org/~daichi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I tested CURRENT and was unable to reproduce panic. -- Paul From jhb at freebsd.org Thu Dec 4 13:24:59 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Dec 4 13:25:17 2008 Subject: lockup booting 8.0-CURRENT-200811 snap image In-Reply-To: <49226603.5030204@nixil.net> References: <49226603.5030204@nixil.net> Message-ID: <200812041421.53099.jhb@freebsd.org> On Tuesday 18 November 2008 01:51:47 am Phil Oleson wrote: > Hi, I've been trying to update my system to Current to try out the new > usb stack etc.. > and have had some problems. Initially I attempted to just do a cvsup, > make buildworld, > make kernel and had problems at the reboot. Ended up having to use the > livecd to swap > out the kernel (loader was strangely hanging before I could type unload; > boot kernel.old) > > Anyways, I picked up a new drive to split my system up to have a > working 7 & current. > So, I downloaded the 200811 snap iso's for amd64 & i386 and tried to > boot to them. > Same/similar lockup happens.. now since this board currently doesn't > have a serial port > I've had to handtype what was left on the screen.. so hopefully it's > enough for now. > > System: INTEL BLKDG35EC 775 G35 (flashed to the **ECG3510M.86A.0107** > Bios Image) > INTEL C2Q Q9300 2.5G 775 > 2 gigs memory (messed up on original order and havnt fixed > it yet) > using the built-in Intel video.. > > so the i386 and the amd64 dvd image I booted with had the same stopping > screen/output > that I could see.. this is what I was able to get down from a verbose boot. > > ------------------------------------------------------ > Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 > Validation 0 10 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route > 64-bit Timecounter "HPET" frequency 143181800 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x8086, dev=0x2980, revid=0x03 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2982, revid=0x03 > domain=0, bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range32, base 0x90200000, size 20, > enabled > -------------------------------- > > > Any suggestions on how to proceed? > > I'll see about installing the new install on the new drive starting at > RELENG_7 > and updating to HEAD from there.. so any source changes will have to wait on > completing that.. but anything would help. Try setting hw.pci.mcfg=0 -- John Baldwin From jhb at freebsd.org Thu Dec 4 13:24:59 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Dec 4 13:25:17 2008 Subject: lockup booting 8.0-CURRENT-200811 snap image In-Reply-To: <49226603.5030204@nixil.net> References: <49226603.5030204@nixil.net> Message-ID: <200812041421.53099.jhb@freebsd.org> On Tuesday 18 November 2008 01:51:47 am Phil Oleson wrote: > Hi, I've been trying to update my system to Current to try out the new > usb stack etc.. > and have had some problems. Initially I attempted to just do a cvsup, > make buildworld, > make kernel and had problems at the reboot. Ended up having to use the > livecd to swap > out the kernel (loader was strangely hanging before I could type unload; > boot kernel.old) > > Anyways, I picked up a new drive to split my system up to have a > working 7 & current. > So, I downloaded the 200811 snap iso's for amd64 & i386 and tried to > boot to them. > Same/similar lockup happens.. now since this board currently doesn't > have a serial port > I've had to handtype what was left on the screen.. so hopefully it's > enough for now. > > System: INTEL BLKDG35EC 775 G35 (flashed to the **ECG3510M.86A.0107** > Bios Image) > INTEL C2Q Q9300 2.5G 775 > 2 gigs memory (messed up on original order and havnt fixed > it yet) > using the built-in Intel video.. > > so the i386 and the amd64 dvd image I booted with had the same stopping > screen/output > that I could see.. this is what I was able to get down from a verbose boot. > > ------------------------------------------------------ > Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 > Validation 0 10 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route > 64-bit Timecounter "HPET" frequency 143181800 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x8086, dev=0x2980, revid=0x03 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2982, revid=0x03 > domain=0, bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range32, base 0x90200000, size 20, > enabled > -------------------------------- > > > Any suggestions on how to proceed? > > I'll see about installing the new install on the new drive starting at > RELENG_7 > and updating to HEAD from there.. so any source changes will have to wait on > completing that.. but anything would help. Try setting hw.pci.mcfg=0 -- John Baldwin From jhb at freebsd.org Thu Dec 4 13:25:05 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Dec 4 13:25:40 2008 Subject: atrtc0: Warnings about mappings of I/O and interrupt In-Reply-To: <20081120171325.GA53026@freebsd.org> References: <20081120171325.GA53026@freebsd.org> Message-ID: <200812041424.13298.jhb@freebsd.org> On Thursday 20 November 2008 12:13:25 pm Roman Divacky wrote: > hi > > I upgraded from roughly 10 days old -CURRENT to this: > > FreeBSD witten 8.0-CURRENT FreeBSD 8.0-CURRENT #55: Wed Nov 19 23:23:49 CET 2008 > root@witten:/usr/obj/usr/src/sys/MYKERNEL i386 > > and I am getting this at boot: > > atrtc0: at port 0x70 irq 8 on isa0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: Warning: Couldn't map Interrupt. > > the booting itself works fine and I dont see any odd effects. The driver is just a stub anyway. Do you have any atrtc0 hints, and can you grab the output for the 'atrtc0' device from 'devinfo -r'? -- John Baldwin From jhb at freebsd.org Thu Dec 4 13:25:05 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Dec 4 13:25:41 2008 Subject: atrtc0: Warnings about mappings of I/O and interrupt In-Reply-To: <20081120171325.GA53026@freebsd.org> References: <20081120171325.GA53026@freebsd.org> Message-ID: <200812041424.13298.jhb@freebsd.org> On Thursday 20 November 2008 12:13:25 pm Roman Divacky wrote: > hi > > I upgraded from roughly 10 days old -CURRENT to this: > > FreeBSD witten 8.0-CURRENT FreeBSD 8.0-CURRENT #55: Wed Nov 19 23:23:49 CET 2008 > root@witten:/usr/obj/usr/src/sys/MYKERNEL i386 > > and I am getting this at boot: > > atrtc0: at port 0x70 irq 8 on isa0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: Warning: Couldn't map Interrupt. > > the booting itself works fine and I dont see any odd effects. The driver is just a stub anyway. Do you have any atrtc0 hints, and can you grab the output for the 'atrtc0' device from 'devinfo -r'? -- John Baldwin From jhb at freebsd.org Thu Dec 4 13:25:14 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Dec 4 13:25:41 2008 Subject: if_le unit number change? In-Reply-To: <20081127195902.GA65404@alchemy.franken.de> References: <1d6d20bc0811260656t101ddb0eu35296ac973c6ba10@mail.gmail.com> <20081127195902.GA65404@alchemy.franken.de> Message-ID: <200812041438.27992.jhb@freebsd.org> On Thursday 27 November 2008 02:59:02 pm Marius Strobl wrote: > On Thu, Nov 27, 2008 at 09:36:48AM +0000, Robert Watson wrote: > > > > On Wed, 26 Nov 2008, Jia-Shiun Li wrote: > > > > >I use vmware to run freebsd. > > > > > >recent update of 8-current changed the unit number of the virtual network > > >interface, an emulated if_le. usually the unit number should start from 0 > > >,namely le0. But after updating the source, le0 becomes le1. This makes > > >interface name mismatching that in rc.conf. I checked the commit log but > > >there seems nothing related in sys/dev/le. So should this be caused by > > >something else? > > > > > >The kernels dated 11/5 & 11/26. > > > > Just ran into an identical problem with HEAD on VMWare here as well. It > > appears to work fine as le1, which is reassuring, but the unit numbering > > change is worrying. I may get a chance to do some binary searching today, > > but we'll see. > > > > I think the reason is that since r185059 the isa(4) hints (in this > case the default one for le0) are now also applied to acpi(4). > Even previously reserving the device unit number corresponding to > the hint (i.e. le0 for hint.le.0.at="isa") regardless of whether > it's actually present and enabled or not was the expected beaviour > AFAICT, although limited to the presence of a ISA bus. ISA hints were always applied to ACPI, but in odd ways. For example, if you had 'hint.sio.0.port=0x3f8' and 'hint.sio.0.flags=0x10' but ACPI's sio0 was actually at some other I/O port, it would still use the sio0 flags. The change now is that hints always "reserve" a device name/unit. If a bus driver determines that a set of hints matches a device it can self-enumerate (e.g. ACPI namespace or PNPBIOS), then it can let the self-enumerated device take over the "reserved" device name/unit. In effect, you can wire device name/units based on resources (only acpi(4) and isa(4) support this currently). I tend to trim my /boot/device.hints to remove hints for devices that aren't in my machines. However, with 8.0, if you leave the bogus hints around you won't be hurt and the device will stay as 'le1' so long as you don't remove the 'le0' hints, so if you never edit your /boot/device.hints it will just be called le1 forever. -- John Baldwin From rnoland at FreeBSD.org Thu Dec 4 13:26:00 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Dec 4 13:26:24 2008 Subject: i give up In-Reply-To: <7d6fde3d0812040151t77ca6200n5aa5a644223c2040@mail.gmail.com> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> <1228342356.2078.24.camel@wombat.2hip.net> <7d6fde3d0812040151t77ca6200n5aa5a644223c2040@mail.gmail.com> Message-ID: <1228425956.2012.12.camel@wombat.2hip.net> On Thu, 2008-12-04 at 01:51 -0800, Garrett Cooper wrote: > On Wed, Dec 3, 2008 at 2:12 PM, Robert Noland wrote: > > On Wed, 2008-12-03 at 11:44 -0800, Artem Belevich wrote: > >> > Second, DO NOT use motherboards with built-in video. These are almost > >> > always nvidia chipsets and suffer from the nvidia problem. Also, the video > >> > is crappy and buggy. > >> > >> I'd not discount them all as a class. Intel's built-in G33/G35 with > >> recent DRM and x86-video-intel driver seem to work pretty well for > >> accelerated 2D on the few boxes I have under FreeBSD-8/amd64. I even > >> get 3D working on occasion. :-) > > > > Correct, Despite my occasional frustration with them, Intel is very > > supportive. They are providing docs and code (linux code) and I have a > > decent relationship with the Intel graphics devs. > > > > ATI/AMD has also become much more friendly and r500 and below should > > work fairly well. r600+ is still under development. > > > > Interestingly enough, VIA just released docs on some of their chips as > > well. I have it on my list to work on, but I don't yet have hardware to > > work with. > > > > robert. > > > >> --Artem > > Eh? ATI can't write drivers to get themselves out of a cardboard box > on Linux, let alone FreeBSD. I have little faith that they'll get > functional 64-bit drivers before nVidia does, as ATI as definitely > demonstrated that they don't care for the *BSD market as much as > nVidia has. I'm not referring to ATI/AMDs proprietary drivers. They are providing open documentation now, as well as information that isn't yet public when I ask for it. So, I'm speaking about the open drm/mesa/Xorg driver, which afaik is working pretty well on r500 and below now. robert. > -Garrett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081204/3e8fc719/attachment.pgp From yanefbsd at gmail.com Thu Dec 4 13:39:25 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 4 13:39:31 2008 Subject: i give up In-Reply-To: <1228425956.2012.12.camel@wombat.2hip.net> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <4936D0C2.2090306@zircon.seattle.wa.us> <1228342356.2078.24.camel@wombat.2hip.net> <7d6fde3d0812040151t77ca6200n5aa5a644223c2040@mail.gmail.com> <1228425956.2012.12.camel@wombat.2hip.net> Message-ID: <7d6fde3d0812041339t5af6c8dfoc877d68cdb163bb0@mail.gmail.com> On Thu, Dec 4, 2008 at 1:25 PM, Robert Noland wrote: > On Thu, 2008-12-04 at 01:51 -0800, Garrett Cooper wrote: >> On Wed, Dec 3, 2008 at 2:12 PM, Robert Noland wrote: >> > On Wed, 2008-12-03 at 11:44 -0800, Artem Belevich wrote: >> >> > Second, DO NOT use motherboards with built-in video. These are almost >> >> > always nvidia chipsets and suffer from the nvidia problem. Also, the video >> >> > is crappy and buggy. >> >> >> >> I'd not discount them all as a class. Intel's built-in G33/G35 with >> >> recent DRM and x86-video-intel driver seem to work pretty well for >> >> accelerated 2D on the few boxes I have under FreeBSD-8/amd64. I even >> >> get 3D working on occasion. :-) >> > >> > Correct, Despite my occasional frustration with them, Intel is very >> > supportive. They are providing docs and code (linux code) and I have a >> > decent relationship with the Intel graphics devs. >> > >> > ATI/AMD has also become much more friendly and r500 and below should >> > work fairly well. r600+ is still under development. >> > >> > Interestingly enough, VIA just released docs on some of their chips as >> > well. I have it on my list to work on, but I don't yet have hardware to >> > work with. >> > >> > robert. >> > >> >> --Artem >> >> Eh? ATI can't write drivers to get themselves out of a cardboard box >> on Linux, let alone FreeBSD. I have little faith that they'll get >> functional 64-bit drivers before nVidia does, as ATI as definitely >> demonstrated that they don't care for the *BSD market as much as >> nVidia has. > > I'm not referring to ATI/AMDs proprietary drivers. They are providing > open documentation now, as well as information that isn't yet public > when I ask for it. So, I'm speaking about the open drm/mesa/Xorg > driver, which afaik is working pretty well on r500 and below now. > > robert. Well, yeah. I was referring to the proprietary drivers though, because all you get is 2D acceleration with the open ATI/nVidia drivers. Given the fact that r500 is rather old too though... that lags a lot more behind nVidia -- but I'm sure that's due to volunteering and lack of man-hours because nVidia has a few devs dedicated towards maintaining their driver on *BSD. -Garrett From matheus at eternamente.info Thu Dec 4 13:45:52 2008 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Thu Dec 4 13:45:59 2008 Subject: problem on ath code - current from yesterday Message-ID: hail, when trying to compile from source, this is the nov snapshot from current, I got this twice: cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c: In function 'ar5416ProcRxDesc': /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:111: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:119: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:120: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:121: error: 'struct ath_rx_status' has no member named 'rs_rssi_ctl' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:122: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:123: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:124: error: 'struct ath_rx_status' has no member named 'rs_rssi_ext' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:135: error: 'struct ath_rx_status' has no member named 'rs_isaggr' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:136: error: 'struct ath_rx_status' has no member named 'rs_moreaggr' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:140: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:142: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:145: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:147: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:149: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:151: error: 'struct ath_rx_status' has no member named 'rs_flags' *** Error code 1 Stop in /usr/obj/usr/src/sys/Cygnus8. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. You have new mail. cygnus# I'll csup again now. best regards, matheus -- We will call you cygnus, The God of balance you shall be From rdivacky at freebsd.org Thu Dec 4 14:09:17 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu Dec 4 14:09:30 2008 Subject: atrtc0: Warnings about mappings of I/O and interrupt In-Reply-To: <200812041424.13298.jhb@freebsd.org> References: <20081120171325.GA53026@freebsd.org> <200812041424.13298.jhb@freebsd.org> Message-ID: <20081204220438.GA17059@freebsd.org> On Thu, Dec 04, 2008 at 02:24:13PM -0500, John Baldwin wrote: > On Thursday 20 November 2008 12:13:25 pm Roman Divacky wrote: > > hi > > > > I upgraded from roughly 10 days old -CURRENT to this: > > > > FreeBSD witten 8.0-CURRENT FreeBSD 8.0-CURRENT #55: Wed Nov 19 23:23:49 CET > 2008 > > root@witten:/usr/obj/usr/src/sys/MYKERNEL i386 > > > > and I am getting this at boot: > > > > atrtc0: at port 0x70 irq 8 on isa0 > > atrtc0: Warning: Couldn't map I/O. > > atrtc0: Warning: Couldn't map Interrupt. > > > > the booting itself works fine and I dont see any odd effects. > > The driver is just a stub anyway. Do you have any atrtc0 hints, and can you > grab the output for the 'atrtc0' device from 'devinfo -r'? witten ~# grep atrtc /boot/device.hints hint.atrtc.0.at="isa" hint.atrtc.0.port="0x70" hint.atrtc.0.irq="8" (but that's the default I believe) devinfo -r shows "empty" atrtc0 but: atrtc1 Interrupt request lines: 8 I/O ports: 0x70-0x71 any more info I can provide? From rdivacky at freebsd.org Thu Dec 4 14:09:17 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu Dec 4 14:09:30 2008 Subject: atrtc0: Warnings about mappings of I/O and interrupt In-Reply-To: <200812041424.13298.jhb@freebsd.org> References: <20081120171325.GA53026@freebsd.org> <200812041424.13298.jhb@freebsd.org> Message-ID: <20081204220438.GA17059@freebsd.org> On Thu, Dec 04, 2008 at 02:24:13PM -0500, John Baldwin wrote: > On Thursday 20 November 2008 12:13:25 pm Roman Divacky wrote: > > hi > > > > I upgraded from roughly 10 days old -CURRENT to this: > > > > FreeBSD witten 8.0-CURRENT FreeBSD 8.0-CURRENT #55: Wed Nov 19 23:23:49 CET > 2008 > > root@witten:/usr/obj/usr/src/sys/MYKERNEL i386 > > > > and I am getting this at boot: > > > > atrtc0: at port 0x70 irq 8 on isa0 > > atrtc0: Warning: Couldn't map I/O. > > atrtc0: Warning: Couldn't map Interrupt. > > > > the booting itself works fine and I dont see any odd effects. > > The driver is just a stub anyway. Do you have any atrtc0 hints, and can you > grab the output for the 'atrtc0' device from 'devinfo -r'? witten ~# grep atrtc /boot/device.hints hint.atrtc.0.at="isa" hint.atrtc.0.port="0x70" hint.atrtc.0.irq="8" (but that's the default I believe) devinfo -r shows "empty" atrtc0 but: atrtc1 Interrupt request lines: 8 I/O ports: 0x70-0x71 any more info I can provide? From morganw at chemikals.org Thu Dec 4 14:14:59 2008 From: morganw at chemikals.org (Wes Morgan) Date: Thu Dec 4 14:15:06 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Message-ID: On Thu, 4 Dec 2008, Thomas Vogt wrote: > Hello Stefan > > Am 04.12.2008 um 00:33 schrieb Stefan Bethke: >> Am 03.12.2008 um 00:29 schrieb Peter Schuller: >> >>>> I've noticed the past couple of days, when using the server (not very >>>> often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 >>>> minutes (no mouse movement, no keyboard events), while the drives work >>>> like >>>> crazy. >>> >>> I was not explicit about it, but FWIW in my case the hang is not due >>> to drive saturation. The drives were mostly idle (except some stuff >>> triggered by a buildworld I had going) during the extended period of >>> ktorrent being unkillable. But again I never had this happen >>> pre-CURRENT. >> >> Just a very brief "me too" (but possibly different effect): I'm stress >> testing two machines I put together over the weekend with an endless loop >> of make -j4 universe, with /usr/obj on ZFS, with a single disk. One of the >> two machines has now been stuck for a couple of hours, and trying to access >> /tank results in a hung process, as will zfs list. >> >> I'll reboot and see what happens, and if I can trigger it again, willt try >> to produce more details. >> >> I have set >> vfs.zfs.arc_max="512M" >> vfs.zfs.prefetch_disable=1 >> in loader.conf >> >> FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Dec >> 3 07:05:03 UTC 2008 >> root@lokschuppen.lassitu.de:/usr/obj/usr/src/sys/EISENBOOT amd64 > > Try to disable ZIL in loader.conf: > vfs.zfs.zil_disable="1" > > It helped me to stop deadlocks during rsync processes. As long as you don't > run any databases or any fsync() intensiv applications, i don't see any > drawbacks in disabling zil. The drawbacks are for the applications itself not > for ZFS. ZFS will be always consistent on disk due to its transaction model > even without ZIL. Are you sure about that? Without the ZIL, wouldn't you need to scrub each pool after every crash, much as fsck with UFS? From jhb at freebsd.org Thu Dec 4 14:45:45 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Dec 4 14:46:25 2008 Subject: atrtc0: Warnings about mappings of I/O and interrupt In-Reply-To: <20081204220438.GA17059@freebsd.org> References: <20081120171325.GA53026@freebsd.org> <200812041424.13298.jhb@freebsd.org> <20081204220438.GA17059@freebsd.org> Message-ID: <200812041745.14587.jhb@freebsd.org> On Thursday 04 December 2008 05:04:38 pm Roman Divacky wrote: > On Thu, Dec 04, 2008 at 02:24:13PM -0500, John Baldwin wrote: > > On Thursday 20 November 2008 12:13:25 pm Roman Divacky wrote: > > > hi > > > > > > I upgraded from roughly 10 days old -CURRENT to this: > > > > > > FreeBSD witten 8.0-CURRENT FreeBSD 8.0-CURRENT #55: Wed Nov 19 23:23:49 CET > > 2008 > > > root@witten:/usr/obj/usr/src/sys/MYKERNEL i386 > > > > > > and I am getting this at boot: > > > > > > atrtc0: at port 0x70 irq 8 on isa0 > > > atrtc0: Warning: Couldn't map I/O. > > > atrtc0: Warning: Couldn't map Interrupt. > > > > > > the booting itself works fine and I dont see any odd effects. > > > > The driver is just a stub anyway. Do you have any atrtc0 hints, and can you > > grab the output for the 'atrtc0' device from 'devinfo -r'? > > witten ~# grep atrtc /boot/device.hints > hint.atrtc.0.at="isa" > hint.atrtc.0.port="0x70" > hint.atrtc.0.irq="8" > > (but that's the default I believe) > > devinfo -r shows "empty" atrtc0 but: > > atrtc1 > Interrupt request lines: > 8 > I/O ports: > 0x70-0x71 > > any more info I can provide? Hmmmm, that should have worked fine in that atrtc1 should have taken over the 'atrtc0' hints. If you don't mind, can you add some debugging printfs to acpi_hint_device_unit() (maybe only do them if the 'name' parameter is "atrtc" to avoid clutter). -- John Baldwin From ertr1013 at student.uu.se Thu Dec 4 14:59:11 2008 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Thu Dec 4 14:59:19 2008 Subject: problem on ath code - current from yesterday In-Reply-To: References: Message-ID: <20081204224354.GA24673@owl.midgard.homeip.net> On Thu, Dec 04, 2008 at 07:15:23PM -0200, Nenhum_de_Nos wrote: > hail, > > when trying to compile from source, this is the nov snapshot from current, > I got this twice: Have you read the 20081130 entry in /usr/src/UPDATING ? > > > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal > /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c: In function > 'ar5416ProcRxDesc': > /usr/src/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c:111: error: 'struct > ath_rx_status' has no member named 'rs_flags' [snip] -- Erik Trulsson ertr1013@student.uu.se From thomas at bsdunix.ch Thu Dec 4 15:58:22 2008 From: thomas at bsdunix.ch (Thomas Vogt) Date: Thu Dec 4 16:25:58 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Message-ID: <49386A6E.50500@bsdunix.ch> Wes Morgan schrieb: > On Thu, 4 Dec 2008, Thomas Vogt wrote: > >> Hello Stefan >> >> Am 04.12.2008 um 00:33 schrieb Stefan Bethke: >>> Am 03.12.2008 um 00:29 schrieb Peter Schuller: >>> >>>>> I've noticed the past couple of days, when using the server (not very >>>>> often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 >>>>> minutes (no mouse movement, no keyboard events), while the drives >>>>> work like >>>>> crazy. >>>> >>>> I was not explicit about it, but FWIW in my case the hang is not due >>>> to drive saturation. The drives were mostly idle (except some stuff >>>> triggered by a buildworld I had going) during the extended period of >>>> ktorrent being unkillable. But again I never had this happen >>>> pre-CURRENT. >>> >>> Just a very brief "me too" (but possibly different effect): I'm >>> stress testing two machines I put together over the weekend with an >>> endless loop of make -j4 universe, with /usr/obj on ZFS, with a >>> single disk. One of the two machines has now been stuck for a couple >>> of hours, and trying to access /tank results in a hung process, as >>> will zfs list. >>> >>> I'll reboot and see what happens, and if I can trigger it again, >>> willt try to produce more details. >>> >>> I have set >>> vfs.zfs.arc_max="512M" >>> vfs.zfs.prefetch_disable=1 >>> in loader.conf >>> >>> FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: >>> Wed Dec 3 07:05:03 UTC 2008 >>> root@lokschuppen.lassitu.de:/usr/obj/usr/src/sys/EISENBOOT amd64 >> >> Try to disable ZIL in loader.conf: >> vfs.zfs.zil_disable="1" >> >> It helped me to stop deadlocks during rsync processes. As long as you >> don't run any databases or any fsync() intensiv applications, i don't >> see any drawbacks in disabling zil. The drawbacks are for the >> applications itself not for ZFS. ZFS will be always consistent on disk >> due to its transaction model even without ZIL. > > Are you sure about that? Without the ZIL, wouldn't you need to scrub > each pool after every crash, much as fsck with UFS? AFAIK no. http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29 The ZFS pool integrity itself is not compromised by this tuning. There are many blog entries from ZFS developer with the same conclusion. Regards, Thomas From nakaji at jp.FreeBSD.org Thu Dec 4 16:55:29 2008 From: nakaji at jp.FreeBSD.org (NAKAJI Hiroyuki) Date: Thu Dec 4 16:55:36 2008 Subject: Fatal trap 12: page fault while in kernel mode Message-ID: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> Hi, I found that my 8-current box sometimes gets panic recently. >From a serial console, I saved a textdump. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0a57285 stack pointer = 0x28:0xe682dc44 frame pointer = 0x28:0xe682dcec code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1015 (nfsd: service) panic: from debugger cpuid = 0 KDB: stack backtrace: Uptime: 1d16h10m24s And, $ addr2line -e /boot/kernel/kernel.symbols 0xc0a57285 /usr/src/sys/rpc/svc.c:787 781 /* now receive msgs from xprtprt (support batch calls) */ 782 r = malloc(sizeof(*r), M_RPC, M_WAITOK|M_ZERO); 783 784 msg.rm_call.cb_cred.oa_base = r->rq_credarea; 785 msg.rm_call.cb_verf.oa_base = &r->rq_credarea[MAX_AUTH_BYTES]; 786 r->rq_clntcred = &r->rq_credarea[2*MAX_AUTH_BYTES]; 787 if (SVC_RECV(xprt, &msg, &r->rq_addr, &args)) { 788 enum auth_stat why; 789 Why this occurs and what do I have to check? === /var/run/dmesg.boot === Copyright (c) 1992-2008 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 8.0-CURRENT #167: Wed Dec 3 11:33:19 JST 2008 root@roddy.4407.kankyo-u.ac.jp:/usr/obj/usr/src/sys/RODDY Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.04-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf25 Stepping = 5 Features=0xbfebfbff Features2=0x4400 Logical CPUs per core: 2 real memory = 1073152000 (1023 MB) avail memory = 1036349440 (988 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.LPT_ - AE_AML_INVALID_RESOURCE_TYPE Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pci0: at device 0.1 (no driver attached) pcib1: mem 0xf8000000-0xfbffffff at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfc000000-0xfdffffff,0xf0100000-0xf0103fff,0xf0800000-0xf0ffffff irq 16 at device 0.0 on pci1 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xf4000000 64MB info: [drm] Initialized mga 3.2.2 20060319 pcib2: at device 2.0 on pci0 pci2: on pcib2 pcib3: at device 29.0 on pci2 pci3: on pcib3 pcib4: at device 31.0 on pci2 pci4: on pcib4 bge0: mem 0xf1100000-0xf110ffff irq 52 at device 4.0 on pci4 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:50:45:00:a0:37 bge0: [ITHREAD] uhci0: port 0x1400-0x141f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1420-0x143f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1440-0x145f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf0000000-0xf00003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 atapci0: port 0x2450-0x2457,0x2444-0x2447,0x2448-0x244f,0x2440-0x2443,0x2000-0x20ff irq 21 at device 0.0 on pci5 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcm0: port 0x2400-0x243f irq 22 at device 1.0 on pci5 pcm0: pcm0: [ITHREAD] pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1460-0x146f at device 31.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc1: port 0x378-0x37f on acpi0 ppc1: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc1: FIFO with 16/16/8 bytes threshold ppbus0: on ppc1 ppbus0: IEEE1284 device found /NIBBLE/PS2 ppbus0: Probing for PnP devices: ppbus0: PRINTER LIPS,N201,ESCP,HP-GL,CJL plip0: on ppbus0 plip0: cannot reserve interrupt, failed. device_attach: plip0 attach returned 6 lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x30 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xd4fff,0xe0000-0xe3fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. uhid0: on uhub1 Timecounters tick every 1.000 msec ad0: 114473MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 ad4: DMA limited to UDMA33, controller found non-ATA66 cable ad4: 152627MB at ata2-master UDMA33 ad6: 152627MB at ata3-master UDMA100 SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted umass0: on uhub3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 286188MB (586114703 512 byte sectors: 255H 63S/T 36483C) === /sys/i386/conf/RODDY === include GENERIC ident RODDY nooption INVARIANTS nooption INVARIANT_SUPPORT nooption WITNESS nooption WITNESS_SKIPSPIN device sound device "snd_es137x" options MSGBUF_SIZE=81920 options DEVICE_POLLING options HZ=1000 options NETATALK -- NAKAJI Hiroyuki From daichi at freebsd.org Thu Dec 4 16:55:47 2008 From: daichi at freebsd.org (Daichi GOTO) Date: Thu Dec 4 16:55:53 2008 Subject: [Call for Test] a patch for kern/121385 - Unionfs cross mount issue In-Reply-To: <3a142e750812041221v26520a53q4f7df488af607305@mail.gmail.com> References: <4917E0C9.5020105@ongs.co.jp> <3a142e750812041221v26520a53q4f7df488af607305@mail.gmail.com> Message-ID: <49387783.7080503@freebsd.org> Thanks for your test, Paul B. Mahol wrote: > On 11/10/08, Daichi GOTO wrote: >> Hi Unionfs users >> >> About kern/121385 - Unionfs cross mount issue, by discussion at >> EuroBSDCon2008, >> unionfs does not allow user to do cross mount operation. If you have some >> interest >> this issue, please get this patch and try with current. I'll commit this >> patch after 1 week later. >> >> PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121385 >> Patch: >> http://people.freebsd.org/~daichi/unionfs/experiments/unionfs-cross-mount.diff >> >> This issue was discussed at EuroBSDCon2008 FreeBSD developer summit. >> Thanks for hrs and gnn :) >> >> -- >> Daichi GOTO, http://people.freebsd.org/~daichi >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > I tested CURRENT and was unable to reproduce panic. You cannot get the same panic described on kern/121385 as follow: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121385 How-To-Repeat: # mkdir -p /unionfs/disk1 # mkdir -p /unionfs/disk2 # mount -t unionfs /unionfs/disk1 /unionfs/disk2 # mount -t unionfs /unionfs/disk2 /unionfs/disk1 # touch /unionfs/disk1/foo The r178483 (http://svn.freebsd.org/viewvc/base?view=revision&revision=178483) avoids this panic. Try without r178483 and you will get a panic. Some discussions with some developers, we are testing a new cross-mount issue patch, after some more check, I'll open it. thanks :) -- Daichi GOTO, http://people.freebsd.org/~daichi From alexbestms at math.uni-muenster.de Thu Dec 4 17:46:47 2008 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Dec 4 19:22:00 2008 Subject: ath cannot connect using WEP Message-ID: hello everybody, i'm having problems with the ath driver in connection with WEP encryption under CURRENT. i've already posted a PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=129022), but maybe somebody else is experiencing the very same problems i'm having. if i disable WEP encryption in my routers web interface i'm able to connect without any problems. this is my wlan device: ath0@pci0:5:1:0: class=0x020000 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet my rc.conf contains the following wlan related entries: wlans_ath0=wlan0 ifconfig_wlan0="inet 192.168.1.10 ssid XXXXXX wepmode on authmode shared wepkey 1:0xXXXXXXXXXXXXXXXXXXXXXXXXXX wepkey 2:- wepkey 3:- wepkey 4:- deftxkey 1 channel 11" this is the output from ifconfig: ath0: flags=8843 metric 0 mtu 2290 ether XX:XX:XX:XX:XX:XX media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 wlan0: flags=8c43 metric 0 mtu 1500 ether XX:XX:XX:XX:XX:XX inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid XXXXXX channel 11 (2462 Mhz 11g) country US ecm authmode SHARED privacy ON deftxkey 1 wepkey 1:104-bit txpower 18.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst ff dturbo enabling wlan debugging using wlandebug scan+auth+assoc revealed the following errors: Nov 20 19:24:58 moshnroll kernel: wlan0: notify scan done Nov 20 19:24:58 moshnroll kernel: wlan0: [XX:XX:XX:XX:XX:XX] recv auth frame with algorithm 1 seq 2 Nov 20 19:24:58 moshnroll kernel: wlan0: [XX:XX:XX:XX:XX:XX] request encrypt frame (ieee80211_send_mgmt) Nov 20 19:24:58 moshnroll kernel: wlan0: [XX:XX:XX:XX:XX:XX] encrypting frame (ieee80211_mgmt_output) Nov 20 19:25:00 moshnroll kernel: wlan0: [XX:XX:XX:XX:XX:XX] ieee80211_scan_assoc_fail: reason 1 Nov 20 19:25:00 moshnroll kernel: wlan0: [XX:XX:XX:XX:XX:XX] sta_assoc_fail: reason 1 fails 2 i've also enabled ath debugging output, but couldn't find any errors. but please ask me if you think the ath debug output should reveal something. all i need are the command line options for athdebug. i had a look at the sources and it seems the net80211 warning is being issued by one of these statements: http://fxr.watson.org/fxr/source/net80211/ieee80211_sta.c#L174 or http://fxr.watson.org/fxr/source/net80211/ieee80211_sta.c#L270 however the problem seems to be caused somewhere in the ath driver i guess. i've also tried to use wpa_supplicant, but without any luck. i got the following error: ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. this seems to be a bug in wpa_supplicant, because scanning for APs isn't the problem. if i apply this patch: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=146030+0+/usr/local/www/db/text/2008/freebsd-current/20080525.freebsd-current the warning dissapears, but i'm getting timeouts during the associate phase. please tell me if you need more details and/or any debug output. i haven't tried any kind of WPA encryption yet. my router is not broadcasting its ssid, but during AP scanning my router and it's ssid are being discovered. before switching to CURRENT a week ago i was using 7-STABLE where i had absolutely no problems at all using WEP encryption. thanks in advance. alex From yr.retarded at gmail.com Thu Dec 4 19:34:08 2008 From: yr.retarded at gmail.com (Chris Ruiz) Date: Thu Dec 4 19:34:16 2008 Subject: lockup booting 8.0-CURRENT-200811 snap image In-Reply-To: <200812041421.53099.jhb@freebsd.org> References: <49226603.5030204@nixil.net> <200812041421.53099.jhb@freebsd.org> Message-ID: <58c737d70812041934v359e9833vbe68e6be871875f8@mail.gmail.com> On Thu, Dec 4, 2008 at 1:21 PM, John Baldwin wrote: > On Tuesday 18 November 2008 01:51:47 am Phil Oleson wrote: >> Hi, I've been trying to update my system to Current to try out the new >> usb stack etc.. >> and have had some problems. Initially I attempted to just do a cvsup, >> make buildworld, >> make kernel and had problems at the reboot. Ended up having to use the >> livecd to swap >> out the kernel (loader was strangely hanging before I could type unload; >> boot kernel.old) >> >> Anyways, I picked up a new drive to split my system up to have a >> working 7 & current. >> So, I downloaded the 200811 snap iso's for amd64 & i386 and tried to >> boot to them. >> Same/similar lockup happens.. now since this board currently doesn't >> have a serial port >> I've had to handtype what was left on the screen.. so hopefully it's >> enough for now. >> >> System: INTEL BLKDG35EC 775 G35 (flashed to the **ECG3510M.86A.0107** >> Bios Image) >> INTEL C2Q Q9300 2.5G 775 >> 2 gigs memory (messed up on original order and havnt fixed >> it yet) >> using the built-in Intel video.. >> >> so the i386 and the amd64 dvd image I booted with had the same stopping >> screen/output >> that I could see.. this is what I was able to get down from a verbose boot. >> >> ------------------------------------------------------ >> Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 >> Validation 0 10 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >> acpi0 >> acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route >> 64-bit Timecounter "HPET" frequency 143181800 Hz quality 900 >> acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: domain=0, physical bus=0 >> found-> vendor=0x8086, dev=0x2980, revid=0x03 >> domain=0, bus=0, slot=0, func=0 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) >> found-> vendor=0x8086, dev=0x2982, revid=0x03 >> domain=0, bus=0, slot=2, func=0 >> class=03-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> map[10]: type Memory, range32, base 0x90200000, size 20, >> enabled >> -------------------------------- >> >> >> Any suggestions on how to proceed? >> >> I'll see about installing the new install on the new drive starting at >> RELENG_7 >> and updating to HEAD from there.. so any source changes will have to wait on >> completing that.. but anything would help. > > Try setting hw.pci.mcfg=0 I also have an Intel board (INTEL DQ35JO) and had posted last month with a boot hang in the same place. I recieved a quick reply from the list and setting hw.pci.mcg=0 fixed everything. Should this be marked as a known problem somewhere on the wiki? It appears to happen to Intel boards with onboard graphics and I imagine that as more people migrate from 7.x to CURRENT that this will happen to more users. Thanks, Chris Ruiz > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- http://young-alumni.com ++ http://oldschoolpunx.net From jackie at boolome.com Thu Dec 4 19:37:09 2008 From: jackie at boolome.com (boolome) Date: Thu Dec 4 19:37:17 2008 Subject: how to config for run compiz fusion Message-ID: <1228446881.1442.8.camel@www.boolome.cn> pciconf -lv vgapci0@pci0:0:2:0: class=0x030000 card=0x27728086 chip=0x27728086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82945G Integrated Graphics Controller' class = display subclass = VGA I install the driver of xf86-video-intel-2.4.2 xorg.conf: Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" Option "AIGLX" "true" EndSection Section "Files" RgbPath "/usr/local/share/X11/rgb" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/TrueType/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "extmod" Load "record" Load "dbe" Load "glx" Load "GLcore" Load "xtrap" Load "dri" Load "freetype" Load "type1" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" Modeline "1440x900" 106.47 1440 1520 1672 1904 900 901 904 932 EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "ColorKey" # #Option "CacheLines" # #Option "Dac6Bit" # [] #Option "DRI" # [] #Option "NoDDC" # [] #Option "ShowCache" # [] #Option "XvMCSurfaces" # #Option "PageFlip" # [] Option "AccelMethod" "XAA" Option "XAANoOffscreenPixmaps" "true" Option "AddARGBGLXVisuals" "true" Option "DRI" "true" Identifier "Card0" Driver "intel" VendorName "Intel Corporation" BoardName "82945G/GZ Integrated Graphics Controller" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 #Option "AddARGBGLXVisuals" "True" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 Modes "1440x900" EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "DRI" Group "video" Mode 0660 EndSection Section "Extensions" Option "Composite" "Enable" EndSection I have used the guide on FreeBSD http://www.freebsd.org/doc/en/articl...ion/index.html. and tried setenv LIBGL_ALWAYS_INDIRECT true compiz --replace --indirect-rendering --sm-disable ccp & The only left working is the mouse cursor, all windows, buttons and menus nothing works not even the keyboard hitting Ctrl-Alt-Backspace. The entire system hangs and I have to reset the computer. That would be X right? From rnoland at FreeBSD.org Thu Dec 4 20:35:44 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Dec 4 20:35:51 2008 Subject: how to config for run compiz fusion In-Reply-To: <1228446881.1442.8.camel@www.boolome.cn> References: <1228446881.1442.8.camel@www.boolome.cn> Message-ID: <1228451740.1982.2.camel@wombat.2hip.net> On Fri, 2008-12-05 at 11:14 +0800, boolome wrote: > Option "AccelMethod" "XAA" > Option "XAANoOffscreenPixmaps" "true" > Option "AddARGBGLXVisuals" "true" Try using EXA, which is the default. i.e. comment out all of the above lines. Otherwise, it looks very much like what I run on my 965... What version of FreeBSD are you running? robert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081205/8427371e/attachment.pgp From jackie at boolome.com Thu Dec 4 23:20:33 2008 From: jackie at boolome.com (boolome) Date: Thu Dec 4 23:20:42 2008 Subject: how to config for run compiz fusion Message-ID: <1228461620.1175.1.camel@www.boolome.cn> > On Fri, 2008-12-05 at 11:14 +0800, boolome wrote: > > Option "AccelMethod" "XAA" > > Option "XAANoOffscreenPixmaps" "true" > > Option "AddARGBGLXVisuals" "true" > > Try using EXA, which is the default. i.e. comment out all of the above > lines. Otherwise, it looks very much like what I run on my 965... What > version of FreeBSD are you running? > > robert. > I have commented the lines you mentioned . but problem same. %uname -a FreeBSD www.boolome.cn 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Oct 19 16:07:48 CST 2008 boolome@www.boolome.cn:/usr/obj/usr/src/sys/boolome i386 Thanks your reply,robert . and Can I have a look at your xorg.conf , and how you run compiz ? From ed at 80386.nl Thu Dec 4 23:22:30 2008 From: ed at 80386.nl (Ed Schouten) Date: Thu Dec 4 23:22:38 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> Message-ID: <20081205072229.GE18652@hoeg.nl> * Maksim Yevmenkin wrote: > the idea was to ensure that kbd->kb_locked variable only takes values > 0 (zero) and 1 (one). I often use constructs like these to do that: foo = bar ? 1 : 0; Maybe !!bar is a lot shorter to write, I think the line above is a lot easier to read. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081205/a26a771e/attachment.pgp From yanefbsd at gmail.com Fri Dec 5 00:29:04 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Dec 5 00:29:12 2008 Subject: lockup booting 8.0-CURRENT-200811 snap image In-Reply-To: <58c737d70812041934v359e9833vbe68e6be871875f8@mail.gmail.com> References: <49226603.5030204@nixil.net> <200812041421.53099.jhb@freebsd.org> <58c737d70812041934v359e9833vbe68e6be871875f8@mail.gmail.com> Message-ID: <7d6fde3d0812050029r7308ec57jaed2733a2396a9fe@mail.gmail.com> On Thu, Dec 4, 2008 at 7:34 PM, Chris Ruiz wrote: > On Thu, Dec 4, 2008 at 1:21 PM, John Baldwin wrote: >> On Tuesday 18 November 2008 01:51:47 am Phil Oleson wrote: >>> Hi, I've been trying to update my system to Current to try out the new >>> usb stack etc.. >>> and have had some problems. Initially I attempted to just do a cvsup, >>> make buildworld, >>> make kernel and had problems at the reboot. Ended up having to use the >>> livecd to swap >>> out the kernel (loader was strangely hanging before I could type unload; >>> boot kernel.old) >>> >>> Anyways, I picked up a new drive to split my system up to have a >>> working 7 & current. >>> So, I downloaded the 200811 snap iso's for amd64 & i386 and tried to >>> boot to them. >>> Same/similar lockup happens.. now since this board currently doesn't >>> have a serial port >>> I've had to handtype what was left on the screen.. so hopefully it's >>> enough for now. >>> >>> System: INTEL BLKDG35EC 775 G35 (flashed to the **ECG3510M.86A.0107** >>> Bios Image) >>> INTEL C2Q Q9300 2.5G 775 >>> 2 gigs memory (messed up on original order and havnt fixed >>> it yet) >>> using the built-in Intel video.. >>> >>> so the i386 and the amd64 dvd image I booted with had the same stopping >>> screen/output >>> that I could see.. this is what I was able to get down from a verbose boot. >>> >>> ------------------------------------------------------ >>> Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 >>> Validation 0 10 N 0 3 4 5 7 9 10 11 12 >>> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >>> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >>> acpi0 >>> acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route >>> 64-bit Timecounter "HPET" frequency 143181800 Hz quality 900 >>> acpi_button0: on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> pci0: domain=0, physical bus=0 >>> found-> vendor=0x8086, dev=0x2980, revid=0x03 >>> domain=0, bus=0, slot=0, func=0 >>> class=06-00-00, hdrtype=0x00, mfdev=0 >>> cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) >>> lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) >>> found-> vendor=0x8086, dev=0x2982, revid=0x03 >>> domain=0, bus=0, slot=2, func=0 >>> class=03-00-00, hdrtype=0x00, mfdev=1 >>> cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) >>> lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) >>> intpin=a, irq=11 >>> powerspec 2 supports D0 D3 current D0 >>> MSI supports 1 message >>> map[10]: type Memory, range32, base 0x90200000, size 20, >>> enabled >>> -------------------------------- >>> >>> >>> Any suggestions on how to proceed? >>> >>> I'll see about installing the new install on the new drive starting at >>> RELENG_7 >>> and updating to HEAD from there.. so any source changes will have to wait on >>> completing that.. but anything would help. >> >> Try setting hw.pci.mcfg=0 > > I also have an Intel board (INTEL DQ35JO) and had posted last month > with a boot hang in the same place. I recieved a quick reply from > the list and setting hw.pci.mcg=0 fixed everything. > > Should this be marked as a known problem somewhere on the wiki? It > appears to happen to Intel boards with onboard graphics and I imagine > that as more people migrate from 7.x to CURRENT that this will happen > to more users. > > Thanks, > > Chris Ruiz > >> >> -- >> John Baldwin This definitely should be listed in a FAQ, IMHO. Where would the best place be for this? -Garrett From bzeeb-lists at lists.zabbadoz.net Fri Dec 5 01:15:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Dec 5 01:15:16 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <20081204190848.GG58682@server.vk2pj.dyndns.org> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <20081204190848.GG58682@server.vk2pj.dyndns.org> Message-ID: <20081205085902.K80401@maildrop.int.zabbadoz.net> On Fri, 5 Dec 2008, Peter Jeremy wrote: Hi, > On 2008-Dec-02 21:00:23 -0500, alexus wrote: >> as far as I understood HEAD is 8.0-CURRENT > > Yes. > >> is there a way for us to start using it before 8.0 hits -RELEASE > > There are two ways. The first is: > 1) Checkout a copy of the HEAD src tree via your chosen source tracker > (cvs/cvsup/ctm/...) > 2) Follow the instructions in /usr/src/UPDATING to build and install > 3) Test well on a non-production box in as close to your production > environment as possible. Be prepared to feed back problems and > test fixes. > 4) Once you are satisfied that it works for you, place it in production. > > This is basically the same as any other FreeBSD release except that you > should test more rigourously. That's for running HEAD. I would be careful doing this on a production system if one does not know what one is really doing when doing this;) > Your second option is to take the patches from r185435 and apply them > to your 7.x source tree. This may take some massaging (I'm not sure > how much 7 and 8 differ in the affected areas). bz@ may be interested > in your experiences. Then test and roll-out as above. There is difference, though not much. Thus just taking the patch won't work but the solution was posted like 2 weeks ago: http://lists.freebsd.org/pipermail/freebsd-jail/2008-November/000615.html Look for where it says "RELENG_7". >> lucky), I somehow was under impression (and i guess i was wrong) that >> it will come out in 7.1, > > It's far too late for any new features in 7.1 but the commit log says > it should be in 7.2. Yupp that's the plan. And the reason it will not be in 7.1-RELEASE is that noone provided the needed bribing money. See http://lists.freebsd.org/pipermail/freebsd-jail/2008-November/000619.html (not serious here). It's been just too late. Regards, Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. From avg at icyb.net.ua Fri Dec 5 03:35:57 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Dec 5 03:36:05 2008 Subject: RFC: small syscons and kbd patch In-Reply-To: <20081205072229.GE18652@hoeg.nl> References: <7d6fde3d0812040324y3bf0901cy1f4a6d961362c314@mail.gmail.com> <20081205072229.GE18652@hoeg.nl> Message-ID: <49391203.9070009@icyb.net.ua> on 05/12/2008 09:22 Ed Schouten said the following: > * Maksim Yevmenkin wrote: >> the idea was to ensure that kbd->kb_locked variable only takes values >> 0 (zero) and 1 (one). > > I often use constructs like these to do that: > > foo = bar ? 1 : 0; > > Maybe !!bar is a lot shorter to write, I think the line above is a lot > easier to read. Another variation is: foo = (bar != 0); I think that this is something in the middle. BTW, gcc 4.2 produces exactly the same assembly for all 3 forms. -- Andriy Gapon From me at janh.de Fri Dec 5 02:50:33 2008 From: me at janh.de (Jan Henrik Sylvester) Date: Fri Dec 5 04:35:13 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <20081203090658.GJ9639@cdnetworks.co.kr> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> Message-ID: <49390727.7070309@janh.de> Pyun YongHyeon wrote: > On Wed, Nov 05, 2008 at 10:35:58AM +0900, To Jan Henrik Sylvester wrote: > > On Tue, Nov 04, 2008 at 10:36:21PM +0100, Jan Henrik Sylvester wrote: > > > Pyun YongHyeon wrote: > > > >On Mon, Nov 03, 2008 at 07:49:34PM +0100, Jan Henrik Sylvester wrote: > > > > > >Pyun YongHyeon writes: > > > > > >> http://people.freebsd.org/~yongari/ale/if_ale.c > > > > > > > > > > I got an Eee PC 1000H, too, with 7.1-BETA2 and just used scp to copy > > > > > with 11.5MB/s -- much better than wlan for big files. Great! > > > > > > > > > > > > >Thanks for testing! > > > > > > I was happy too early. Now I keep getting these: > > > ale0: DMA read error! -- resetting > > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > > > FYI: Fix committed to HEAD(r185577). I just did a test on 7.1-BETA2. With the Nov-14 if_ale.c, I immediately hit the problem (35.4KB/s+messages). Applying r185576 and r185577 solved the problem (10.2MB/s+no messages). Thank you very much! In the commit message, there is no MFC date. Can this go into 7.1? (I see that the driver without the patch is already there.) Cheers, Jan Henrik From onemda at gmail.com Fri Dec 5 06:13:40 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Dec 5 06:13:46 2008 Subject: Fatal trap 12: page fault while in kernel mode In-Reply-To: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> Message-ID: <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> On 12/5/08, NAKAJI Hiroyuki wrote: > Hi, > > I found that my 8-current box sometimes gets panic recently. > >From a serial console, I saved a textdump. > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0a57285 > stack pointer = 0x28:0xe682dc44 > frame pointer = 0x28:0xe682dcec > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1015 (nfsd: service) > panic: from debugger > cpuid = 0 > KDB: stack backtrace: > Uptime: 1d16h10m24s > > And, > > $ addr2line -e /boot/kernel/kernel.symbols 0xc0a57285 > /usr/src/sys/rpc/svc.c:787 > > 781 /* now receive msgs from xprtprt (support batch calls) */ > 782 r = malloc(sizeof(*r), M_RPC, M_WAITOK|M_ZERO); > 783 > 784 msg.rm_call.cb_cred.oa_base = r->rq_credarea; > 785 msg.rm_call.cb_verf.oa_base = > &r->rq_credarea[MAX_AUTH_BYTES]; > 786 r->rq_clntcred = &r->rq_credarea[2*MAX_AUTH_BYTES]; > 787 if (SVC_RECV(xprt, &msg, &r->rq_addr, &args)) { > 788 enum auth_stat why; > 789 > > Why this occurs and what do I have to check? > > === /var/run/dmesg.boot === > Copyright (c) 1992-2008 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 8.0-CURRENT #167: Wed Dec 3 11:33:19 JST 2008 > root@roddy.4407.kankyo-u.ac.jp:/usr/obj/usr/src/sys/RODDY > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.04-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf25 Stepping = 5 > > Features=0xbfebfbff > Features2=0x4400 > Logical CPUs per core: 2 > real memory = 1073152000 (1023 MB) > avail memory = 1036349440 (988 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.LPT_ - > AE_AML_INVALID_RESOURCE_TYPE > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pci0: at device 0.1 (no driver attached) > pcib1: mem 0xf8000000-0xfbffffff at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: mem > 0xfc000000-0xfdffffff,0xf0100000-0xf0103fff,0xf0800000-0xf0ffffff irq 16 at > device 0.0 on pci1 > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xf4000000 64MB > info: [drm] Initialized mga 3.2.2 20060319 > pcib2: at device 2.0 on pci0 > pci2: on pcib2 > pcib3: at device 29.0 on pci2 > pci3: on pcib3 > pcib4: at device 31.0 on pci2 > pci4: on pcib4 > bge0: mem > 0xf1100000-0xf110ffff irq 52 at device 4.0 on pci4 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge0: Ethernet address: 00:50:45:00:a0:37 > bge0: [ITHREAD] > uhci0: port 0x1400-0x141f irq 16 > at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x1420-0x143f irq 19 > at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x1440-0x145f irq 18 > at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem > 0xf0000000-0xf00003ff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 6 ports with 6 removable, self powered > pcib5: at device 30.0 on pci0 > pci5: on pcib5 > atapci0: port > 0x2450-0x2457,0x2444-0x2447,0x2448-0x244f,0x2440-0x2443,0x2000-0x20ff irq 21 > at device 0.0 on pci5 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > pcm0: port 0x2400-0x243f irq 22 at device 1.0 on pci5 > pcm0: > pcm0: [ITHREAD] > pcm0: > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1460-0x146f at device 31.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > ata1: on atapci1 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc1: port 0x378-0x37f on acpi0 > ppc1: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc1: FIFO with 16/16/8 bytes threshold > ppbus0: on ppc1 > ppbus0: IEEE1284 device found /NIBBLE/PS2 > ppbus0: Probing for PnP devices: > ppbus0: PRINTER LIPS,N201,ESCP,HP-GL,CJL > plip0: on ppbus0 > plip0: cannot reserve interrupt, failed. > device_attach: plip0 attach returned 6 > lpt0: on ppbus0 > lpt0: Polled port > ppi0: on ppbus0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x30 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3 > cpu0: on acpi0 > p4tcc0: on cpu0 > cpu1: on acpi0 > p4tcc1: on cpu1 > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xc8fff,0xc9000-0xd4fff,0xe0000-0xe3fff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: parallel port not found. > uhid0: on uhub1 > Timecounters tick every 1.000 msec > ad0: 114473MB at ata0-master UDMA100 > acd0: DVDR at ata1-master UDMA33 > ad4: DMA limited to UDMA33, controller found non-ATA66 cable > ad4: 152627MB at ata2-master UDMA33 > ad6: 152627MB at ata3-master UDMA100 > SMP: AP CPU #2 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > Trying to mount root from ufs:/dev/ad0s1a > WARNING: / was not properly dismounted > umass0: on uhub3 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 286188MB (586114703 512 byte sectors: 255H 63S/T 36483C) > > === /sys/i386/conf/RODDY === > include GENERIC > > ident RODDY > > nooption INVARIANTS > nooption INVARIANT_SUPPORT > nooption WITNESS > nooption WITNESS_SKIPSPIN > > device sound > device "snd_es137x" > > options MSGBUF_SIZE=81920 > > options DEVICE_POLLING > options HZ=1000 > > options NETATALK > -- > NAKAJI Hiroyuki > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Full bt would be better, also make sure that world and kernel are in sync (because of recent libc changes). -- Paul From rizzo at iet.unipi.it Fri Dec 5 06:21:05 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Dec 5 06:21:13 2008 Subject: Running Forth/ficl as a user command ? Message-ID: <20081205142558.GA5394@onelab2.iet.unipi.it> apologies if the question is silly, but is there a way to run the Forth interpreter embedded in /boot/loader as a user command ? I am trying some modifications to the loader config files and it is a pain to have to go through rebooting a machine, even if just in qemu... cheers luigi From bseklecki at collaborativefusion.com Fri Dec 5 05:52:58 2008 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Fri Dec 5 06:36:38 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> Message-ID: <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Tue, 2008-12-02 at 21:00 -0500, alexus wrote: > as far as I understood HEAD is 8.0-CURRENT The trick is to bribe the right people to get it RFP'd into 7.2R. :) ~BAS -- Brian A. Seklecki Collaborative Fusion, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081205/a9c314bf/attachment.pgp From matt at chronos.org.uk Fri Dec 5 06:37:06 2008 From: matt at chronos.org.uk (Matt Dawson) Date: Fri Dec 5 06:37:13 2008 Subject: i give up In-Reply-To: <20081204221511.254FE1065758@hub.freebsd.org> References: <20081204221511.254FE1065758@hub.freebsd.org> Message-ID: <200812051436.59308.matt@chronos.org.uk> On Thursday 04 December 2008 22:15:11 freebsd-current-request@freebsd.org wrote: > > I'm not referring to ATI/AMDs proprietary drivers. ?They are providing > > open documentation now, as well as information that isn't yet public > > when I ask for it. ?So, I'm speaking about the open drm/mesa/Xorg > > driver, which afaik is working pretty well on r500 and below now. > > > > robert. > > Well, yeah. I was referring to the proprietary drivers though, because > all you get is 2D acceleration with the open ATI/nVidia drivers. > Given the fact that r500 is rather old too though... that lags a lot > more behind nVidia -- but I'm sure that's due to volunteering and lack > of man-hours because nVidia has a few devs dedicated towards > maintaining their driver on *BSD. Actually, no. The subset of ATi cards Robert refers to has direct rendering support on the to-be-committed (after the ports repo is thawed) Xorg 7.4, DRM kernel update (which is already in -HEAD) and new Mesa. I have personally tested R200-R480 cards here with good results, after some time messing about with nVidia hardware under the same illusion that they are better supported. Even the troublesome RS48x (Radeon XPress 200/1100M IGP) which I had abandoned all hope of ever seeing DRM working upon now works with the open driver, although there are still rendering issues with some 3D workloads using ports' Xorg and Mesa. nVidia's team consists of Christian Zander and another guy (whose name eludes me right now) as far as I can tell. "Our" team consists of work already done by Eric Anholt, by whose own admission no longer uses FreeBSD and most of it over 24 months old, and Robert. Also, the open ATi driver/DRI/DRM works (again, verified here) to the same standard on amd64 as it does on i386. This is not the case with nVidia's proprietary driver, so quite how nVidia's offering leads the OSS ATi driver escapes me right now. Robert's work in this area over the past few months has brought this hardware, along with many of the Intel IGPs, almost bang up to date. Only the R6/700 cards lack 3D/2D accel/possibly Xv (I could be wrong on that last item, but the man page still says no support) but this work is ongoing. One more little niggle in nVidia's direction: The OSS ATi driver integrates with the base system and ports' Xorg without having to faff about. nVidia's screws up the system config with odd .so files and symlinks to the point that manual intervention is required to upgrade xorg-server and get the linuxulator working. Not optimal, IMHO. Bottom line is we have rather good support in -CURRENT for ATi cards and similar in -STABLE with Robert's patches applied. This is probably set to get a whole lot better when 7.1-RELEASE shows up (I doubt the DRM kernel stuff will be MFC'd to 7.1, but I'd like to be wrong) and we get the new stuff into ports. When one compares the resource gap between Robert's dedicated volunteer efforts and two full-time paid nVidia devs with full docs, this is nothing short of amazing and I, for one, am very grateful. -- Matt Dawson ku.gro.sonorhc@ttam MTD15-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081205/34f0f82d/attachment.pgp From rb at gid.co.uk Fri Dec 5 06:42:07 2008 From: rb at gid.co.uk (Bob Bishop) Date: Fri Dec 5 06:42:14 2008 Subject: Running Forth/ficl as a user command ? In-Reply-To: <20081205142558.GA5394@onelab2.iet.unipi.it> References: <20081205142558.GA5394@onelab2.iet.unipi.it> Message-ID: <3C5650B9-8BC4-4D6B-9E00-12078C44C3FB@gid.co.uk> Hi, On 5 Dec 2008, at 14:25, Luigi Rizzo wrote: > apologies if the question is silly, but is there a > way to run the Forth interpreter embedded in /boot/loader > as a user command ? ficl is available in ports/lang > I am trying some modifications to the loader config files and it > is a pain to have to go through rebooting a machine, even if just > in qemu... > > cheers > luigi -- Bob Bishop rb@gid.co.uk From bsam at ipt.ru Fri Dec 5 07:00:15 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Fri Dec 5 07:00:23 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <20081203090658.GJ9639@cdnetworks.co.kr> (Pyun YongHyeon's message of "Wed\, 3 Dec 2008 18\:06\:58 +0900") References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> Message-ID: <37502393@bb.ipt.ru> Pyun YongHyeon writes: > On Wed, Nov 05, 2008 at 10:35:58AM +0900, To Jan Henrik Sylvester wrote: > > On Tue, Nov 04, 2008 at 10:36:21PM +0100, Jan Henrik Sylvester wrote: > > > Pyun YongHyeon wrote: > > > >On Mon, Nov 03, 2008 at 07:49:34PM +0100, Jan Henrik Sylvester wrote: > > > > > >Pyun YongHyeon writes: > > > > > >> http://people.freebsd.org/~yongari/ale/if_ale.c > > > > > > > > > > I got an Eee PC 1000H, too, with 7.1-BETA2 and just used scp to copy > > > > > with 11.5MB/s -- much better than wlan for big files. Great! > > > > > > > > > > > > >Thanks for testing! > > > > > > I was happy too early. Now I keep getting these: > > > ale0: DMA read error! -- resetting > > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > FYI: Fix committed to HEAD(r185577). Works fine for me at EEEPC-1000. Good rate (~10MB/s), no interface UP/DOWN, no messages. Big thank you! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From jhb at freebsd.org Fri Dec 5 08:43:19 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Dec 5 08:43:30 2008 Subject: lockup booting 8.0-CURRENT-200811 snap image In-Reply-To: <58c737d70812041934v359e9833vbe68e6be871875f8@mail.gmail.com> References: <49226603.5030204@nixil.net> <200812041421.53099.jhb@freebsd.org> <58c737d70812041934v359e9833vbe68e6be871875f8@mail.gmail.com> Message-ID: <200812051131.30003.jhb@freebsd.org> On Thursday 04 December 2008 10:34:06 pm Chris Ruiz wrote: > On Thu, Dec 4, 2008 at 1:21 PM, John Baldwin wrote: > > On Tuesday 18 November 2008 01:51:47 am Phil Oleson wrote: > >> Hi, I've been trying to update my system to Current to try out the new > >> usb stack etc.. > >> and have had some problems. Initially I attempted to just do a cvsup, > >> make buildworld, > >> make kernel and had problems at the reboot. Ended up having to use the > >> livecd to swap > >> out the kernel (loader was strangely hanging before I could type unload; > >> boot kernel.old) > >> > >> Anyways, I picked up a new drive to split my system up to have a > >> working 7 & current. > >> So, I downloaded the 200811 snap iso's for amd64 & i386 and tried to > >> boot to them. > >> Same/similar lockup happens.. now since this board currently doesn't > >> have a serial port > >> I've had to handtype what was left on the screen.. so hopefully it's > >> enough for now. > >> > >> System: INTEL BLKDG35EC 775 G35 (flashed to the **ECG3510M.86A.0107** > >> Bios Image) > >> INTEL C2Q Q9300 2.5G 775 > >> 2 gigs memory (messed up on original order and havnt fixed > >> it yet) > >> using the built-in Intel video.. > >> > >> so the i386 and the amd64 dvd image I booted with had the same stopping > >> screen/output > >> that I could see.. this is what I was able to get down from a verbose boot. > >> > >> ------------------------------------------------------ > >> Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 > >> Validation 0 10 N 0 3 4 5 7 9 10 11 12 > >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on > >> acpi0 > >> acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route > >> 64-bit Timecounter "HPET" frequency 143181800 Hz quality 900 > >> acpi_button0: on acpi0 > >> pcib0: port 0xcf8-0xcff on acpi0 > >> pci0: on pcib0 > >> pci0: domain=0, physical bus=0 > >> found-> vendor=0x8086, dev=0x2980, revid=0x03 > >> domain=0, bus=0, slot=0, func=0 > >> class=06-00-00, hdrtype=0x00, mfdev=0 > >> cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > >> lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) > >> found-> vendor=0x8086, dev=0x2982, revid=0x03 > >> domain=0, bus=0, slot=2, func=0 > >> class=03-00-00, hdrtype=0x00, mfdev=1 > >> cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > >> lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) > >> intpin=a, irq=11 > >> powerspec 2 supports D0 D3 current D0 > >> MSI supports 1 message > >> map[10]: type Memory, range32, base 0x90200000, size 20, > >> enabled > >> -------------------------------- > >> > >> > >> Any suggestions on how to proceed? > >> > >> I'll see about installing the new install on the new drive starting at > >> RELENG_7 > >> and updating to HEAD from there.. so any source changes will have to wait on > >> completing that.. but anything would help. > > > > Try setting hw.pci.mcfg=0 > > I also have an Intel board (INTEL DQ35JO) and had posted last month > with a boot hang in the same place. I recieved a quick reply from > the list and setting hw.pci.mcg=0 fixed everything. > > Should this be marked as a known problem somewhere on the wiki? It > appears to happen to Intel boards with onboard graphics and I imagine > that as more people migrate from 7.x to CURRENT that this will happen > to more users. > > Thanks, > > Chris Ruiz Well, we probably need to come up with a better way to determine which machines to actually use it on. It's a shame that MCFG is apparently busted on so many machines (either that or we are not doing something correctly). -- John Baldwin From joseph.koshy at gmail.com Fri Dec 5 09:04:04 2008 From: joseph.koshy at gmail.com (Joseph Koshy) Date: Fri Dec 5 09:04:11 2008 Subject: Fatal trap 12: page fault while in kernel mode In-Reply-To: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> Message-ID: <84dead720812050840j28c95014wf76095c3d6def985@mail.gmail.com> > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0a57285 > Why this occurs and what do I have to check? The trap is being caused by a null pointer access. You may want to take a full dump and use kgdb(1) to investigate the matter: ddb> call doadump ddb> reset and after the reboot finishes, # kgdb /boot/kernel/kernel /var/crash/vmcore.N where "vmcore.N" is the name of the dump file saved by savecore(8). Koshy From jhb at freebsd.org Fri Dec 5 09:30:18 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Dec 5 09:30:25 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <200811201747.28540.jhb@freebsd.org> References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> <200811201747.28540.jhb@freebsd.org> Message-ID: <200812051206.01927.jhb@freebsd.org> On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: > On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: > > On 11/19/08, John Baldwin wrote: > > > This is a relatively simple patch to mark cd9660 MPSAFE and enable shared > > > lookups. The changes to cd9660_lookup() mirror similar changes to > > > ufs_lookup() to use static variables for local data rather than abusing > > > i-node members of the parent directory. I've done some light testing of > > > this, but not super-strenuous. This patch also includes simple locking > for > > > the iconv support in the kernel. That locking uses an sx lock to > serialize > > > open and close of translator tables and the associated refcount. Actual > > > conversions do not need any locks, however as the mount holds a reference > on > > > the table. > > > > > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch > > > > > > > With this patch I'm unable to kldunload libiconv.ko once it is loaded. > > And trying to kldunload libiconv.ko will make any next > kldload/kldstat/kldunload > > to fail waiting forever(livelock). > > > > Regression were not encountered while only cd9660.ko were kldloaded. > > So this is actually due to a bug in the module code. If you have two modules > like this: > > DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); > DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); > > The SI_* constants ensure that foo's module handler is called before bar's > module handler for MOD_LOAD. However, we don't enforce a reverse order (bar > then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is random > and has no relation to the SI_* constants. :( > > What is happening here is that one of the 'bar' modules in libiconv.ko is > getting unloaded after 'foo' gets unloaded and using a destroyed lock (you > get a panic if you run with INVARIANTS). So this should now be fixed with this commit. If you could verify that iconv works ok with the latest kern_module.c I would appreciate it. Author: jhb Date: Fri Dec 5 16:47:30 2008 New Revision: 185642 URL: http://svn.freebsd.org/changeset/base/185642 Log: When the SYSINIT() to load a module invokes the MOD_LOAD event successfully, move that module to the head of the associated linker file's list of modules. The end result is that once all the modules are loaded, they are sorted in the reverse of their load order. This causes the kernel linker to invoke the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order that MOD_LOAD was invoked. This means that the ordering of MOD_LOAD events that is set by the SI_* paramters to DECLARE_MODULE() are now honored in the same order they would be for SYSUNINIT() for the MOD_QUIESCE and MOD_UNLOAD events. MFC after: 1 month -- John Baldwin From david at catwhisker.org Fri Dec 5 10:24:19 2008 From: david at catwhisker.org (David Wolfskill) Date: Fri Dec 5 10:24:25 2008 Subject: "interrupt storm..."; seems associated with an0 NIC Message-ID: <20081205174838.GA22652@albert.catwhisker.org> After updating my laptop to CURRENT as of this morning, I now see interrupt storm detected on "irq11:"; throttling interrupt source repeated indefinitely if I have inserted a Cisco/Aironet 350 PCCard. Once the situation has been detected, the only way I've found to escape is by power-cycling -- I can't even do anything with a serial console (unless I had logged in to that serial console ahead of time -- in that case, I was able to reboot gracefully). Here's a list of the files that saw updates today: U sys/cddl/contrib/opensolaris/uts/common/sys/isa_defs.h U sys/dev/cxgb/common/cxgb_ael1002.c U sys/dev/pccbb/pccbb.c U sys/dev/pccbb/pccbb_pci.c U sys/dev/pccbb/pccbbvar.h And here are some other related bits: FreeBSD g1-37.catwhisker.org 8.0-CURRENT FreeBSD 8.0-CURRENT #881: Fri Dec 5 06:38:46 PST 2008 root@g1-37.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Here's what "vmstat -i" says when an0 hasn't been connected since the last boot: interrupt total rate irq0: clk 637184 998 irq1: atkbd0 46 0 irq4: uart0 2261 3 irq6: fdc1 1 0 irq7: ppc0 6 0 irq8: rtc 81638 127 irq11: cbb0 cbb1+* 3112 4 irq14: ata0 65357 102 Total 789605 1237 And here's output from the same command shortly after I inserted the NIC: interrupt total rate irq0: clk 671999 998 irq1: atkbd0 46 0 irq4: uart0 2300 3 irq6: fdc1 1 0 irq7: ppc0 6 0 irq8: rtc 86095 127 irq11: cbb0 cbb1+* 7907 11 irq14: ata0 65388 97 Total 833742 1238 I note that even after pulling the NIC, the messages continue -- and other PCCards inserted in the slot do not appear to be recognized -- probably because doing so would require use of the "throttl[ed] interrupt source." Rebooting with yesterday's kernel -- with older revisions of the above files -- appears to avoid the observed problem. Here's ouput of "pciconf -l -v" under yesterday's kernel, but wiht the an0 NIC inserted: hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x1a308086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82845G[GL/GV/GE/PE] Host-Hub Interface Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0x1a318086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '82845/E/MP/MZ Brookdale CPU to AGP Bridge' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x45418086 chip=0x24828086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) USB Controller' class = serial bus subclass = USB uhci1@pci0:0:29:2: class=0x0c0300 card=0x45418086 chip=0x24878086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM USB Controller' class = serial bus subclass = USB pcib2@pci0:0:30:0: class=0x060400 card=0x00000000 chip=0x24488086 rev=0x42 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x248c8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CAM LPC Interface or ISA bridge: see Notes' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x45418086 chip=0x248a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CAM (ICH3-M) UltraATA/100 EIDE Controller' class = mass storage subclass = ATA pcm0@pci0:0:31:5: class=0x040100 card=0x59591013 chip=0x24858086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) AC'97 Audio Controller' class = multimedia subclass = audio none0@pci0:0:31:6: class=0x070300 card=0x4c21134d chip=0x24868086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801CA/CAM (ICH3-S/ICH3-M) AC'97 Modem Controller' class = simple comms subclass = generic modem vgapci0@pci0:1:0:0: class=0x030000 card=0x00d51028 chip=0x4c661002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'ATI MOBILITY RADEON 9000 (Microsoft Corporation - Radeon Mobility M9' class = display subclass = VGA xl0@pci0:2:0:0: class=0x020000 card=0x00d51028 chip=0x920010b7 rev=0x78 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C905 CX-TX-M Fast EtherLink for PC Management NIC' class = network subclass = ethernet cbb0@pci0:2:1:0: class=0x060700 card=0x00d51028 chip=0xac42104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCI4451 PC card CardBus Controller' class = bridge subclass = PCI-CardBus cbb1@pci0:2:1:1: class=0x060700 card=0x00d51028 chip=0xac42104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments (TI)' device = 'PCI4451 PC card CardBus Controller' class = bridge subclass = PCI-CardBus fwohci0@pci0:2:1:2: class=0x0c0010 card=0x00d51028 chip=0x8027104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'PCI4451 OHCI-Lynx IEEE-1394 FireWire Adapter' class = serial bus subclass = FireWire wi0@pci0:2:3:0: class=0x028000 card=0x25138086 chip=0x38731260 rev=0x01 hdr=0x00 vendor = 'Intersil Americas Inc (Was: Harris Semiconductor)' device = 'PRISM 2.5 802.11b 11Mbps Wireless Controller' class = network and here's what ifconfig(8) says about an0 (under yesterday's kernel): an0: flags=8802 metric 0 mtu 1500 ether 00:40:96:40:5d:44 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid 1:tsunami channel 6 (2437 Mhz 11b) stationname "" authmode OPEN privacy OFF deftxkey 1 txpower 0 rtsthreshold 0 fragthreshold 0 bmiss 0 ucastrate 0 mcastrate 0 mgmtrate 0 maxretry 0 roaming DEVICE bintval 0 [At home, the NIC would be associated & in use, as it's the NIC I normally use when running FreeBSD above 6.x, as I have yet to be able to get the wi0 NIC to work under RELENG_7 or HEAD.] Here's a list of the old & new revisions for each of the changed files: 1.6/185029 1.7/185614 sys/cddl/contrib/opensolaris/uts/common/sys/isa_defs.h 1.9/185157 1.10/185620 sys/dev/cxgb/common/cxgb_ael1002.c 1.175/185624 1.176/185625 sys/dev/pccbb/pccbb.c 1.29/183558 1.30/185625 sys/dev/pccbb/pccbb_pci.c 1.32/ 1.33/185625 sys/dev/pccbb/pccbbvar.h So I'm guessing that imp's svn rev. 185625 may have had an unfortunate interaction with some aspect of my machine. I'm willing to test, but confess to little knowledge in this area. I do have a local mirror of the CVS repository handy, if that helps. Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081205/a3ca797d/attachment.pgp From imp at bsdimp.com Fri Dec 5 11:04:29 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Dec 5 11:04:59 2008 Subject: "interrupt storm..."; seems associated with an0 NIC In-Reply-To: <20081205174838.GA22652@albert.catwhisker.org> References: <20081205174838.GA22652@albert.catwhisker.org> Message-ID: <20081205.120056.255409238.imp@bsdimp.com> Thanks. Grump. Will have to back out and try again. Warner From des at des.no Fri Dec 5 11:47:09 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Dec 5 11:47:17 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> (Brian A. Seklecki's message of "Fri, 05 Dec 2008 13:26:14 +0000") References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Message-ID: <86skp2l804.fsf@ds4.des.no> "Brian A. Seklecki" writes: > alexus writes: > > as far as I understood HEAD is 8.0-CURRENT > The trick is to bribe the right people to get it RFP'd into 7.2R. :) The question is, does it change existing behavior, or just add new functionality? If the former, it should not be MFCed. DES -- Dag-Erling Sm?rgrav - des@des.no From bseklecki at collaborativefusion.com Fri Dec 5 12:05:31 2008 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Fri Dec 5 12:38:10 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <86skp2l804.fsf@ds4.des.no> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> Message-ID: <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Fri, 2008-12-05 at 20:47 +0100, Dag-Erling Sm?rgrav wrote: > The question is, does it change existing behavior, or just add new > functionality? The syntax semantics should be backward compatible, so likely the latter. -- Brian A. Seklecki Collaborative Fusion, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081205/b837c09e/attachment.pgp From stb at lassitu.de Fri Dec 5 12:45:57 2008 From: stb at lassitu.de (Stefan Bethke) Date: Fri Dec 5 12:46:04 2008 Subject: Labeling disks Message-ID: I'm trying to set up a new machine with three disks, which should host a root ufs file system, swap space, and a raidz zfs pool. Doing this the old-fashioned way with fdisk and bsdlabel (and gmirror for the a and b slices) works just fine, but I figured I might use the opportunity and try a GPT partition table. Also, I'd like to label the disks, and use the labels to reference the disks and contained partitions, instead of the ATA disk device. If I need to swap disks, I then don't have to take care to reinsert them into the exact same spots. Unfortunatly, I'm coming up short: - Using glabel to label the disks, and then fdisk/bsdlabel partioning them, works nicely. As soon as I put a gmirror on the label/disk?s1a partitions, *all* labels disappear. Huh? I can understand removing the labels for the partitions that are now the providers used by the gmirror, but why to the other get removed? Also, it seems that gmirror references the actual disks (see gmirror output below) instead of the labels. I was under the impression that glabel would consume a provider and provide it minus the last sector, so /dev/label/foo and / dev/ad22 are not the same device (but do overlap). - I did manage to create a GPT partitioned USB stick, but the partition label doesn't show up. I would be grateful if someone could commit kern/128398 or similar. (Unless I'm misunderstanding how GPT labels should show up.) Am I going about this the wrong way? Is there another way to configure gmirror and ZFS to use specific disks as opposed to certain channels on certain controllers? Thanks, Stefan $ gmirror list Geom name: root State: COMPLETE Components: 3 Balance: load Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 1289874545 Providers: 1. Name: mirror/root Mediasize: 4294966784 (4.0G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: ad6s1a Mediasize: 4294967296 (4.0G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 148493928 2. Name: ad8s1a Mediasize: 4294967296 (4.0G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 1 Flags: DIRTY GenID: 0 SyncID: 1 ID: 1518735210 3. Name: ad10s1a Mediasize: 4294967296 (4.0G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 2 Flags: DIRTY GenID: 0 SyncID: 1 ID: 291618695 -- Stefan Bethke Fon +49 170 346 0140 From onemda at gmail.com Fri Dec 5 12:56:33 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Dec 5 12:56:39 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <200812051206.01927.jhb@freebsd.org> References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750811201330p3084255em390d94b352dee532@mail.gmail.com> <200811201747.28540.jhb@freebsd.org> <200812051206.01927.jhb@freebsd.org> Message-ID: <3a142e750812051256v1c0c4f3eke2f953b907a4653@mail.gmail.com> On 12/5/08, John Baldwin wrote: > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >> > On 11/19/08, John Baldwin wrote: >> > > This is a relatively simple patch to mark cd9660 MPSAFE and enable > shared >> > > lookups. The changes to cd9660_lookup() mirror similar changes to >> > > ufs_lookup() to use static variables for local data rather than >> > > abusing >> > > i-node members of the parent directory. I've done some light testing >> > > of >> > > this, but not super-strenuous. This patch also includes simple >> > > locking >> for >> > > the iconv support in the kernel. That locking uses an sx lock to >> serialize >> > > open and close of translator tables and the associated refcount. >> > > Actual >> > > conversions do not need any locks, however as the mount holds a > reference >> on >> > > the table. >> > > >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >> > > >> > >> > With this patch I'm unable to kldunload libiconv.ko once it is loaded. >> > And trying to kldunload libiconv.ko will make any next >> kldload/kldstat/kldunload >> > to fail waiting forever(livelock). >> > >> > Regression were not encountered while only cd9660.ko were kldloaded. >> >> So this is actually due to a bug in the module code. If you have two > modules >> like this: >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >> >> The SI_* constants ensure that foo's module handler is called before bar's >> >> module handler for MOD_LOAD. However, we don't enforce a reverse order >> (bar >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is >> random >> and has no relation to the SI_* constants. :( >> >> What is happening here is that one of the 'bar' modules in libiconv.ko is >> getting unloaded after 'foo' gets unloaded and using a destroyed lock (you >> >> get a panic if you run with INVARIANTS). > > So this should now be fixed with this commit. If you could verify that > iconv > works ok with the latest kern_module.c I would appreciate it. > > Author: jhb > Date: Fri Dec 5 16:47:30 2008 > New Revision: 185642 > URL: http://svn.freebsd.org/changeset/base/185642 > > Log: > When the SYSINIT() to load a module invokes the MOD_LOAD event > successfully, > move that module to the head of the associated linker file's list of > modules. > The end result is that once all the modules are loaded, they are sorted in > the reverse of their load order. This causes the kernel linker to invoke > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order that > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD events > that > is set by the SI_* paramters to DECLARE_MODULE() are now honored in the > same > order they would be for SYSUNINIT() for the MOD_QUIESCE and MOD_UNLOAD > events. > > MFC after: 1 month > > -- > John Baldwin > Yes it works, I tried hard multiple times kldload/kldunload {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, but without success. FYI following LORs happened: lock order reversal: 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc4322bdc isofs (isofs) @ /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 KDB: stack backtrace: db_trace_self_wrapper(c061bff9,c3b566c0,c04e75e5,4,c0617724,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0617724,c3c91468,c3c93828,c3b5671c,...) at kdb_backtrace+0x29 _witness_debugger(c061ecc6,c4322bdc,c44e75c3,c3c93828,c44e7507,...) at _witness_debugger+0x25 witness_checkorder(c4322bdc,9,c44e7507,2b6,0,...) at witness_checkorder+0x839 __lockmgr_args(c4322bdc,80000,0,0,0,...) at __lockmgr_args+0x797 cd9660_vget_internal(c3feea00,d000,200000,c3b568a8,0,...) at cd9660_vget_internal+0x147 cd9660_lookup(c3b569f8,c4322c90,c3b56bb0,c4322c90,c3b56a18,...) at cd9660_lookup+0x4c1 VOP_CACHEDLOOKUP_APV(c44e8a20,c3b569f8,c3b56bb0,c3b56b9c,c3fd1b00,...) at VOP_CACHEDLOOKUP_APV+0xa5 vfs_cache_lookup(c3b56a78,c3b56a78,5000104,200000,c4322c90,...) at vfs_cache_lookup+0xcc VOP_LOOKUP_APV(c44e8a20,c3b56a78,c06249d7,1ba,c3b56b9c,...) at VOP_LOOKUP_APV+0xa5 lookup(c3b56b84,c06249d7,dc,bc,c410482c,...) at lookup+0x51e namei(c3b56b84,c108ba38,c108ba34,c3c5e000,c3b56b2c,...) at namei+0x48b kern_statat(c442d480,200,ffffff9c,282162f8,0,...) at kern_statat+0x6b kern_lstat(c442d480,282162f8,0,c3b56c18,0,...) at kern_lstat+0x36 lstat(c442d480,c3b56cf8,8,c061f959,c0647af0,...) at lstat+0x2f syscall(c3b56d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (190, FreeBSD ELF32, lstat), eip = 0x281ac413, esp = 0xbfbfe5ac, ebp = 0xbfbfe638 --- lock order reversal: 1st 0xc440fbdc ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1207 2nd 0xc440fad0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2179 KDB: stack backtrace: db_trace_self_wrapper(c061bff9,c3b50a38,c04e75e5,4,c0617724,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0617724,c3c934e8,c3c93418,c3b50a94,...) at kdb_backtrace+0x29 _witness_debugger(c061ecad,c440fad0,c0610530,c3c93418,c06252f3,...) at _witness_debugger+0x25 witness_checkorder(c440fad0,9,c06252f3,883,0,...) at witness_checkorder+0x839 __lockmgr_args(c440fad0,80100,c440faec,0,0,...) at __lockmgr_args+0x797 vop_stdlock(c3b50b9c,4,c0617724,80100,c440fa78,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0644760,c3b50b9c,c067fa18,c066aac0,c440fa78,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c440fa78,80100,c06252f3,883,c44e7507,...) at _vn_lock+0x5e vrele(c440fa78,0,c44e7507,208,0,...) at vrele+0x142 cd9660_unmount(c3feea00,8000000,c416d240,4fc,0,...) at cd9660_unmount+0xed dounmount(c3feea00,8000000,c416d240,482,3,...) at dounmount+0x482 unmount(c416d240,c3b50cf8,8,c416d240,c0646b30,...) at unmount+0x2bf syscall(c3b50d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d1e7f, esp = 0xbfbfe5bc, ebp = 0xbfbfe688 --- -- Paul From jhb at freebsd.org Fri Dec 5 13:09:06 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Dec 5 13:09:14 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <3a142e750812051256v1c0c4f3eke2f953b907a4653@mail.gmail.com> References: <200811191510.53793.jhb@FreeBSD.org> <200812051206.01927.jhb@freebsd.org> <3a142e750812051256v1c0c4f3eke2f953b907a4653@mail.gmail.com> Message-ID: <200812051608.50120.jhb@freebsd.org> On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: > On 12/5/08, John Baldwin wrote: > > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: > >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: > >> > On 11/19/08, John Baldwin wrote: > >> > > This is a relatively simple patch to mark cd9660 MPSAFE and enable > > shared > >> > > lookups. The changes to cd9660_lookup() mirror similar changes to > >> > > ufs_lookup() to use static variables for local data rather than > >> > > abusing > >> > > i-node members of the parent directory. I've done some light testing > >> > > of > >> > > this, but not super-strenuous. This patch also includes simple > >> > > locking > >> for > >> > > the iconv support in the kernel. That locking uses an sx lock to > >> serialize > >> > > open and close of translator tables and the associated refcount. > >> > > Actual > >> > > conversions do not need any locks, however as the mount holds a > > reference > >> on > >> > > the table. > >> > > > >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch > >> > > > >> > > >> > With this patch I'm unable to kldunload libiconv.ko once it is loaded. > >> > And trying to kldunload libiconv.ko will make any next > >> kldload/kldstat/kldunload > >> > to fail waiting forever(livelock). > >> > > >> > Regression were not encountered while only cd9660.ko were kldloaded. > >> > >> So this is actually due to a bug in the module code. If you have two > > modules > >> like this: > >> > >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); > >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); > >> > >> The SI_* constants ensure that foo's module handler is called before bar's > >> > >> module handler for MOD_LOAD. However, we don't enforce a reverse order > >> (bar > >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is > >> random > >> and has no relation to the SI_* constants. :( > >> > >> What is happening here is that one of the 'bar' modules in libiconv.ko is > >> getting unloaded after 'foo' gets unloaded and using a destroyed lock (you > >> > >> get a panic if you run with INVARIANTS). > > > > So this should now be fixed with this commit. If you could verify that > > iconv > > works ok with the latest kern_module.c I would appreciate it. > > > > Author: jhb > > Date: Fri Dec 5 16:47:30 2008 > > New Revision: 185642 > > URL: http://svn.freebsd.org/changeset/base/185642 > > > > Log: > > When the SYSINIT() to load a module invokes the MOD_LOAD event > > successfully, > > move that module to the head of the associated linker file's list of > > modules. > > The end result is that once all the modules are loaded, they are sorted in > > the reverse of their load order. This causes the kernel linker to invoke > > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order that > > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD events > > that > > is set by the SI_* paramters to DECLARE_MODULE() are now honored in the > > same > > order they would be for SYSUNINIT() for the MOD_QUIESCE and MOD_UNLOAD > > events. > > > > MFC after: 1 month > > > > -- > > John Baldwin > > > > Yes it works, I tried hard multiple times kldload/kldunload > {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, > but without success. > > FYI following LORs happened: > > lock order reversal: > 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 > 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > 3rd 0xc4322bdc isofs (isofs) @ > /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 This LOR should be addressed in the latest cd9660 locking patches. -- John Baldwin From onemda at gmail.com Fri Dec 5 13:54:25 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Dec 5 13:54:31 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <200812051608.50120.jhb@freebsd.org> References: <200811191510.53793.jhb@FreeBSD.org> <200812051206.01927.jhb@freebsd.org> <3a142e750812051256v1c0c4f3eke2f953b907a4653@mail.gmail.com> <200812051608.50120.jhb@freebsd.org> Message-ID: <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> On 12/5/08, John Baldwin wrote: > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >> On 12/5/08, John Baldwin wrote: >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >> >> > On 11/19/08, John Baldwin wrote: >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and enable >> > shared >> >> > > lookups. The changes to cd9660_lookup() mirror similar changes to >> >> > > ufs_lookup() to use static variables for local data rather than >> >> > > abusing >> >> > > i-node members of the parent directory. I've done some light >> >> > > testing >> >> > > of >> >> > > this, but not super-strenuous. This patch also includes simple >> >> > > locking >> >> for >> >> > > the iconv support in the kernel. That locking uses an sx lock to >> >> serialize >> >> > > open and close of translator tables and the associated refcount. >> >> > > Actual >> >> > > conversions do not need any locks, however as the mount holds a >> > reference >> >> on >> >> > > the table. >> >> > > >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >> >> > > >> >> > >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >> >> > loaded. >> >> > And trying to kldunload libiconv.ko will make any next >> >> kldload/kldstat/kldunload >> >> > to fail waiting forever(livelock). >> >> > >> >> > Regression were not encountered while only cd9660.ko were kldloaded. >> >> >> >> So this is actually due to a bug in the module code. If you have two >> > modules >> >> like this: >> >> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >> >> >> >> The SI_* constants ensure that foo's module handler is called before > bar's >> >> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse order >> >> (bar >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is >> >> random >> >> and has no relation to the SI_* constants. :( >> >> >> >> What is happening here is that one of the 'bar' modules in libiconv.ko >> >> is >> >> getting unloaded after 'foo' gets unloaded and using a destroyed lock > (you >> >> >> >> get a panic if you run with INVARIANTS). >> > >> > So this should now be fixed with this commit. If you could verify that >> > iconv >> > works ok with the latest kern_module.c I would appreciate it. >> > >> > Author: jhb >> > Date: Fri Dec 5 16:47:30 2008 >> > New Revision: 185642 >> > URL: http://svn.freebsd.org/changeset/base/185642 >> > >> > Log: >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >> > successfully, >> > move that module to the head of the associated linker file's list of >> > modules. >> > The end result is that once all the modules are loaded, they are >> > sorted > in >> > the reverse of their load order. This causes the kernel linker to > invoke >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order that >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD events >> > that >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored in >> > the >> > same >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and MOD_UNLOAD >> > events. >> > >> > MFC after: 1 month >> > >> > -- >> > John Baldwin >> > >> >> Yes it works, I tried hard multiple times kldload/kldunload >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >> but without success. >> >> FYI following LORs happened: >> >> lock order reversal: >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >> 3rd 0xc4322bdc isofs (isofs) @ >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 > > This LOR should be addressed in the latest cd9660 locking patches. > > -- > John Baldwin > Oh, why I did not checked new version? Yes that LOR have gone, but when doing "ll -R" first time on /mnt I got following messages from kernel: RRIP without PX field? x ~ 50 times. I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... -- Paul From nakaji at jp.freebsd.org Fri Dec 5 15:53:29 2008 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Fri Dec 5 15:53:36 2008 Subject: Fatal trap 12: page fault while in kernel mode In-Reply-To: <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> (Paul B. Mahol's message of "Fri, 5 Dec 2008 15:13:38 +0100") References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> Message-ID: <863ah2qivi.fsf@ra333.heimat.gr.jp> Thanks for advice. I noticed I had just upgraded the kernel only and the userland remains old, that is, kernel is on Dec 3 while userland is on Oct 20. I'll do installworld too, after next buildworld, buildkernel, installkernel and reboot. And, I found same panic this morning (JST), but before I read Koshy's instruction, I typed 'reset' without doadump and I cannot show you a full bt. I'll do it when next panic. So, what I have to do are three: 1. Full upgrade to the latest kernel and userland (world) 2. Observe whether a panic occurs, and 3. When panic, save the crash dump and get full bt with kgdb I hope it will not reach to the step three. Thanks. >>>>> In <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> >>>>> "Paul B. Mahol" wrote: Paul> Full bt would be better, also make sure that world and kernel are in Paul> sync (because of recent libc changes). >>>>> In <84dead720812050840j28c95014wf76095c3d6def985@mail.gmail.com> >>>>> "Joseph Koshy" wrote: > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x0 > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc0a57285 > > Why this occurs and what do I have to check? Koshy> The trap is being caused by a null pointer access. Koshy> You may want to take a full dump and use kgdb(1) to investigate the matter: Koshy> ddb> call doadump Koshy> ddb> reset Koshy> and after the reboot finishes, Koshy> # kgdb /boot/kernel/kernel /var/crash/vmcore.N Koshy> where "vmcore.N" is the name of the dump file saved by savecore(8). -- NAKAJI Hiroyuki From oliver.pntr at gmail.com Fri Dec 5 16:06:21 2008 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Fri Dec 5 16:07:31 2008 Subject: freebsd current @ 20081201 In-Reply-To: <7d6fde3d0812040340h4ca854f6o2e078c48790845b0@mail.gmail.com> References: <6101e8c40811301536g7229841cx741cafcfcce4df69@mail.gmail.com> <7d6fde3d0812040340h4ca854f6o2e078c48790845b0@mail.gmail.com> Message-ID: <6101e8c40812051606q4d271ea7u31732594aeef4b4b@mail.gmail.com> it's a c2q with 4gb ram, on asus p5q-e mb, with 3x500GB sata disk, ad4 -> fbsd7.1 ad6 -> fbsd8 ad8 -> debian which data is requied for you? in pervious e-mail attached the dmesg of fbsd8 On 12/4/08, Garrett Cooper wrote: > On Sun, Nov 30, 2008 at 3:36 PM, Oliver Pinter > wrote: >> LOR error on amd64 > > More data? > -Garrett > From pyunyh at gmail.com Fri Dec 5 18:29:37 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Dec 5 18:29:44 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <49390727.7070309@janh.de> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <49390727.7070309@janh.de> Message-ID: <20081206022928.GE22093@cdnetworks.co.kr> On Fri, Dec 05, 2008 at 11:49:11AM +0100, Jan Henrik Sylvester wrote: > Pyun YongHyeon wrote: > >On Wed, Nov 05, 2008 at 10:35:58AM +0900, To Jan Henrik Sylvester wrote: > > > On Tue, Nov 04, 2008 at 10:36:21PM +0100, Jan Henrik Sylvester wrote: > > > > Pyun YongHyeon wrote: > > > > >On Mon, Nov 03, 2008 at 07:49:34PM +0100, Jan Henrik Sylvester > > wrote: > > > > > > >Pyun YongHyeon writes: > > > > > > >> http://people.freebsd.org/~yongari/ale/if_ale.c > > > > > > > > > > > > I got an Eee PC 1000H, too, with 7.1-BETA2 and just used scp to > > copy > > > > with 11.5MB/s -- much better than wlan for big files. Great! > > > > > > > > > > > > > > > >Thanks for testing! > > > > > > > > I was happy too early. Now I keep getting these: > > > > ale0: DMA read error! -- resetting > > > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > > > > > >FYI: Fix committed to HEAD(r185577). > > I just did a test on 7.1-BETA2. With the Nov-14 if_ale.c, I immediately > hit the problem (35.4KB/s+messages). Applying r185576 and r185577 solved > the problem (10.2MB/s+no messages). > Thanks for testing! > Thank you very much! > > In the commit message, there is no MFC date. Can this go into 7.1? (I > see that the driver without the patch is already there.) > MFC done. :-) -- Regards, Pyun YongHyeon From pyunyh at gmail.com Fri Dec 5 18:30:24 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Dec 5 18:30:30 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <37502393@bb.ipt.ru> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> Message-ID: <20081206023016.GF22093@cdnetworks.co.kr> On Fri, Dec 05, 2008 at 06:00:06PM +0300, Boris Samorodov wrote: > Pyun YongHyeon writes: > > On Wed, Nov 05, 2008 at 10:35:58AM +0900, To Jan Henrik Sylvester wrote: > > > On Tue, Nov 04, 2008 at 10:36:21PM +0100, Jan Henrik Sylvester wrote: > > > > Pyun YongHyeon wrote: > > > > >On Mon, Nov 03, 2008 at 07:49:34PM +0100, Jan Henrik Sylvester wrote: > > > > > > >Pyun YongHyeon writes: > > > > > > >> http://people.freebsd.org/~yongari/ale/if_ale.c > > > > > > > > > > > > I got an Eee PC 1000H, too, with 7.1-BETA2 and just used scp to copy > > > > > > with 11.5MB/s -- much better than wlan for big files. Great! > > > > > > > > > > > > > > > >Thanks for testing! > > > > > > > > I was happy too early. Now I keep getting these: > > > > ale0: DMA read error! -- resetting > > > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > > > FYI: Fix committed to HEAD(r185577). > > Works fine for me at EEEPC-1000. Good rate (~10MB/s), no interface > UP/DOWN, no messages. Big thank you! > No problem. Thanks for testing! -- Regards, Pyun YongHyeon From yanefbsd at gmail.com Fri Dec 5 20:06:35 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Dec 5 20:06:42 2008 Subject: freebsd current @ 20081201 In-Reply-To: <6101e8c40812051606q4d271ea7u31732594aeef4b4b@mail.gmail.com> References: <6101e8c40811301536g7229841cx741cafcfcce4df69@mail.gmail.com> <7d6fde3d0812040340h4ca854f6o2e078c48790845b0@mail.gmail.com> <6101e8c40812051606q4d271ea7u31732594aeef4b4b@mail.gmail.com> Message-ID: <7d6fde3d0812052006x6655ecf7wff2d22fe61dec9bb@mail.gmail.com> On Fri, Dec 5, 2008 at 4:06 PM, Oliver Pinter wrote: > it's a c2q with 4gb ram, on asus p5q-e mb, with 3x500GB sata disk, > ad4 -> fbsd7.1 > ad6 -> fbsd8 > ad8 -> debian > > which data is requied for you? > in pervious e-mail attached the dmesg of fbsd8 > > On 12/4/08, Garrett Cooper wrote: >> On Sun, Nov 30, 2008 at 3:36 PM, Oliver Pinter >> wrote: >>> LOR error on amd64 >> >> More data? >> -Garrett Hmmm... I saw this on an older version of CURRENT (I'm running a version from ~3 weeks ago). -Garrett From jackie at boolome.com Sat Dec 6 01:30:44 2008 From: jackie at boolome.com (boolome) Date: Sat Dec 6 01:30:51 2008 Subject: make buildworld failed! Message-ID: <1228555830.1186.6.camel@www.boolome.cn> %uname -a FreeBSD www.boolome.cn 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Fri Dec 5 09:33:04 CST 2008 root@www.boolome.cn:/usr/obj/usr/src/sys/boolome i386 %cd /usr/src %make buildworld -------------------------------------------------------------- >>> World build started on Sat Dec 6 17:19:08 CST 2008 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- skip.... -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 800049" MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk" make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=800049 -DWITHOUT_SSP -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF legacy ===> tools/build (obj,includes,depend,all,install) /usr/obj/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/build cd /usr/src/tools/build; make buildincludes; make installincludes rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/tools/build/dummy.c cc -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/tools/build/dummy.c building static egacy library ranlib libegacy.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/tmp/legacy/usr/lib -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- ..... echo "NULL};" >> gtyp-gen.h echo "static const char * const lang_dir_names[] = {" >> gtyp-gen.h echo "\"c\", " >> gtyp-gen.h echo "\"cp\", " >> gtyp-gen.h echo "\"objc\", " >> gtyp-gen.h echo "NULL};" >> gtyp-gen.h cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c yacc -d -o gengtype-yacc.c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype-yacc.y cat gengtype-yacc.c > gengtype-yacc+%DIKED.c sed -e "s/xmalloc/malloc/g" -e "s/xrealloc/realloc/g" -e "s/malloc/xmalloc/g" -e "s/realloc/xrealloc/g" gengtype-yacc.c > gengtype-yacc+%DIKED.c cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -I/usr/obj/usr/src/tmp/legacy/usr/include -c gengtype-yacc+%DIKED.c flex -ogengtype-lex.c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype-lex.l *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. What's wrong.. From hselasky at c2i.net Sat Dec 6 04:32:44 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Dec 6 04:32:56 2008 Subject: [Serious] busdma bug in -current in relation to USB hardware - review wanted In-Reply-To: <200811161408.21562.hselasky@c2i.net> References: <20081107082740.GA1334@icarus.home.lan> <200811081023.10058.hselasky@freebsd.org> <200811161408.21562.hselasky@c2i.net> Message-ID: <200812061334.55365.hselasky@c2i.net> Hi, After various feedback from several people I have made a new patch proposal that will fix the busdma problem. See: http://perforce.freebsd.org/chv.cgi?CH=154181 Review wanted! I don't know how to patch the psyco interface for SUN. Maybe there is nothing that needs to be patched? --HPS From xcllnt at mac.com Sat Dec 6 09:45:06 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Dec 6 09:45:13 2008 Subject: [Serious] busdma bug in -current in relation to USB hardware - review wanted In-Reply-To: <200812061334.55365.hselasky@c2i.net> References: <20081107082740.GA1334@icarus.home.lan> <200811081023.10058.hselasky@freebsd.org> <200811161408.21562.hselasky@c2i.net> <200812061334.55365.hselasky@c2i.net> Message-ID: <031DE609-3E5B-4508-BAB0-95800B7F02F4@mac.com> On Dec 6, 2008, at 4:34 AM, Hans Petter Selasky wrote: > Hi, > > After various feedback from several people I have made a new patch > proposal > that will fix the busdma problem. > > See: > > http://perforce.freebsd.org/chv.cgi?CH=154181 > > Review wanted! The USB stack has a fixed page size of 4K. On our 64-bit platforms PAGE_SIZE is at least 8K. Your change is sloppy in that respect and doesn't make the distinction. That makes the patch a kluge. The definition of BUS_DMA_NO_REALIGN is based on circumstantial evidence only and as such, works as a side-effect. I don't think that's a good design. I don't think there's any reason not to preserve the page offset in all cases. So far all hardware worked whether or not their DMA pages were bounced and the non-bounced pages would have a possible non-zero page offset, whereas the bounced pages would always have a zero page offset. In short: it works either way. In particular, it works with the page offset preserved. Why not preserve it always? What's the downside? -- Marcel Moolenaar xcllnt@mac.com From jackie at boolome.com Sat Dec 6 16:54:46 2008 From: jackie at boolome.com (boolome) Date: Sat Dec 6 16:54:57 2008 Subject: how to config for run compiz fusion In-Reply-To: <1228577856.1939.5.camel@wombat.2hip.net> References: <1228446881.1442.8.camel@www.boolome.cn> <1228451740.1982.2.camel@wombat.2hip.net> <1228454182.1172.1.camel@www.boolome.cn> <1228480648.1982.9.camel@wombat.2hip.net> <1228526478.1167.7.camel@www.boolome.cn> <1228577856.1939.5.camel@wombat.2hip.net> Message-ID: <1228611269.1716.6.camel@www.boolome.cn> ? 2008-12-06?? 10:37 -0500?Robert Noland??? > On Sat, 2008-12-06 at 09:21 +0800, boolome wrote: > > ? 2008-12-05?? 07:37 -0500?Robert Noland??? > > > On Fri, 2008-12-05 at 13:16 +0800, boolome wrote: > > > > ? 2008-12-04?? 23:35 -0500?Robert Noland??? > > > > > On Fri, 2008-12-05 at 11:14 +0800, boolome wrote: > > > > > > Option "AccelMethod" "XAA" > > > > > > Option "XAANoOffscreenPixmaps" "true" > > > > > > Option "AddARGBGLXVisuals" "true" > > > > > > > > > > Try using EXA, which is the default. i.e. comment out all of the above > > > > > lines. Otherwise, it looks very much like what I run on my 965... What > > > > > version of FreeBSD are you running? > > > > > > > > > > robert. > > > > > > > > > I have commented the lines you mentioned . but problem same. > > > > %uname -a > > > > FreeBSD www.boolome.cn 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Oct 19 > > > > 16:07:48 CST 2008 > > > > boolome@www.boolome.cn:/usr/obj/usr/src/sys/boolome i386 > > > > > > > > Thanks your reply,robert . > > > > > > > > and Can I have a look at your xorg.conf , and how you run compiz ? > > > > > > I posted my xorg.conf at http://people.freebsd.org/~rnoland/xorg.conf > > > Note that I'm running a pre-release of xserver 1.6 at the moment, but > > > the it should still be pretty much the same. For starting compiz, I use > > > fusion-icon, which has never been released, so there is no port. > > > "compiz --replace --sm-disable --ignore-desktop-hints ccp" should work > > > correctly though. > > > > > > If your still having issues, send me an xorg.log. > > > > > > robert. > > > > > > > > > > > > > > > > > This is some attachment . > > I found when I run "change screensave properties" ,the x crashed and the > > message is "drm0:[ithread]" , > > This message is displayed when the interrupt handler is installed. It > is normal when X is restarting after the crash or after a vt switch. > > X crashing could be many things... The log you sent doesn't show the > crash, it is probably from the restarted session. A backtrace from X is > probably the best way to track that down. > > robert. > > > There is something wrong with drm ? > > > > Thanks ,Robert . > > Are these messages useful? from xorg.log (II) intel(0): Output VGA connected (II) intel(0): Output VGA using initial mode 1440x900 (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear (II) intel(0): detected 256 kB GTT. (II) intel(0): detected 7932 kB stolen memory. (==) intel(0): video overlay key set to 0x101fe (==) intel(0): Will not try to enable page flipping (==) intel(0): Triple buffering disabled (==) intel(0): Intel XvMC decoder disabled (==) intel(0): Using gamma correction (1.0, 1.0, 1.0) (**) intel(0): Display dimensions: (410, 260) mm (**) intel(0): DPI set to (89, 140) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/local/lib/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.4.2, module version = 2.2.0 ABI class: X.Org Video Driver, version 2.0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (II) intel(0): Comparing regs from server start up to After PreInit (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xfdf80000 - 0xfdfbffff (0x40000) MS[B] [1] 0 0 0xd0000000 - 0xdfffffff (0x10000000) MS[B] [2] 0 0 0xfdf00000 - 0xfdf7ffff (0x80000) MS[B] [3] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xfdeff000 - 0xfdefffff (0x1000) MX[B]E [8] -1 0 0xfdffd000 - 0xfdffdfff (0x1000) MX[B]E [9] -1 0 0xfdffe000 - 0xfdffefff (0x1000) MX[B]E [10] -1 0 0xfdfff000 - 0xfdffffff (0x1000) MX[B]E [11] -1 0 0xfdf80000 - 0xfdfbffff (0x40000) MX[B](B) [12] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [13] -1 0 0xfdf00000 - 0xfdf7ffff (0x80000) MX[B](B) [14] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [15] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [16] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [17] 0 0 0x0000ff00 - 0x0000ff07 (0x8) IS[B] [18] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [19] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [20] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B]E [21] -1 0 0x00000500 - 0x000005ff (0x100) IX[B]E [22] -1 0 0x0000f300 - 0x0000f3ff (0x100) IX[B]E [23] -1 0 0x0000f400 - 0x0000f4ff (0x100) IX[B]E [24] -1 0 0x0000f500 - 0x0000f5ff (0x100) IX[B]E [25] -1 0 0x0000f600 - 0x0000f6ff (0x100) IX[B]E [26] -1 0 0x0000f700 - 0x0000f7ff (0x100) IX[B]E [27] -1 0 0x0000f800 - 0x0000f8ff (0x100) IX[B]E [28] -1 0 0x0000fa00 - 0x0000faff (0x100) IX[B]E [29] -1 0 0x0000f000 - 0x0000f0ff (0x100) IX[B]E [30] -1 0 0x0000fb00 - 0x0000fbff (0x100) IX[B]E [31] -1 0 0x0000fc00 - 0x0000fcff (0x100) IX[B]E [32] -1 0 0x0000fd00 - 0x0000fdff (0x100) IX[B]E [33] -1 0 0x0000fe00 - 0x0000feff (0x100) IX[B]E [34] -1 0 0x0000ff00 - 0x0000ff07 (0x8) IX[B](B) [35] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [36] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) intel(0): Kernel reported 491520 total, 0 used (II) intel(0): I830CheckAvailableMemory: 1966080 kB available drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) [drm] DRM interface version 1.0 (EE) [drm] Could not set DRM device bus ID. (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. (**) intel(0): Framebuffer compression disabled (**) intel(0): Tiling enabled (==) intel(0): Write-combining range (0xfdf00000,0x80000) was already clear (==) intel(0): Write-combining range (0xfdf80000,0x40000) was already clear (==) intel(0): VideoRam: 262144 KB (II) intel(0): Attempting memory allocation with tiled buffers. (II) intel(0): Tiled allocation successful. (II) intel(0): Page Flipping disabled (==) intel(0): Write-combining range (0xfdf00000,0x80000) was already clear (==) intel(0): Write-combining range (0xfdf80000,0x40000) was already clear (==) intel(0): Write-combining range (0xd0000000,0x10000000) was already set (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear (II) EXA(0): Offscreen pixmap area of 35389440 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): xf86BindGARTMemory: bind key 10 at 0x01000000 (pgoffset 4096) (II) intel(0): xf86BindGARTMemory: bind key 11 at 0x02000000 (pgoffset 8192) (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB) (II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB, 0x000000007f820000 physical ) (II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB) (II) intel(0): 0x00032000-0x00032fff: overlay registers (4 kB, 0x000000007f832000 physical ) (II) intel(0): 0x007bf000: end of stolen memory (II) intel(0): 0x01000000-0x01ffffff: front buffer (11520 kB) X tiled (II) intel(0): 0x02000000-0x041bffff: exa offscreen (34560 kB) (II) intel(0): 0x10000000: end of aperture (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0x46c13f78) and PRB0_TAIL (0x000156e8) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x7ffc0001 getbl_err: 0x00000000 ipeir: 0x00000000 iphdr: 0x6db3ffff LP ring tail: 0x000156f0 head: 0x00013f78 len: 0x0001f001 start 0x00000000 eir: 0x0000 esr: 0x0000 emr: 0xffff instdone: 0xffc1 instpm: 0x0000 memmode: 0x00000306 instps: 0x800f00d0 hwstam: 0xeffe ier: 0x0042 imr: 0x0000 iir: 0x1020 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f0 count 1502 Ring end space: 125056 wanted 131064 Fatal server error: lockup Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x7ffc0001 getbl_err: 0x00000000 ipeir: 0x00000000 iphdr: 0x6db3ffff LP ring tail: 0x000156f8 head: 0x00013f78 len: 0x0001f001 start 0x00000000 eir: 0x0000 esr: 0x0000 emr: 0xffff instdone: 0xffc1 instpm: 0x0000 memmode: 0x00000306 instps: 0x800f00d0 hwstam: 0xeffe ier: 0x0042 imr: 0x0000 iir: 0x1020 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring at virtual 0x28800000 head 0x13f78 tail 0x156f8 count 1504 Ring end space: 125048 wanted 131064 FatalError re-entered, aborting lockup >From messages Dec 7 08:29:44 www console-kit-daemon[1005]: GLib-CRITICAL: g_hash_table_lookup: assertion `hash_table != NULL' failed Dec 7 08:29:44 www kernel: pid 1004 (Xorg), uid 0: exited on signal 6 (core dumped) Dec 7 08:29:44 www console-kit-daemon[1005]: GLib-CRITICAL: g_hash_table_destroy: assertion `hash_table != NULL' failed Dec 7 08:29:44 www gdm-binary[1003]: WARNING: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Dec 7 08:29:51 www kernel: pid 29007 (Xorg), uid 0: exited on signal 6 (core dumped) Dec 7 08:30:01 www kernel: pid 29013 (Xorg), uid 0: exited on signal 6 (core dumped) Dec 7 08:30:10 www kernel: pid 29023 (Xorg), uid 0: exited on signal 6 (core dumped) Dec 7 08:30:11 www gdm-binary[1002]: WARNING: Failed to start X server several times in a short time period; disabling display :0 From conrads at cox.net Sat Dec 6 17:07:46 2008 From: conrads at cox.net (Conrad J. Sabatier) Date: Sat Dec 6 17:08:03 2008 Subject: i give up In-Reply-To: <20081203151537.GA1045@phenom.cordula.ws> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> Message-ID: <20081206190754.6c2bbd70@serene.no-ip.org> On Wed, 3 Dec 2008 16:15:37 +0100 cpghost wrote: > On Tue, Dec 02, 2008 at 10:06:43PM -0600, Conrad J. Sabatier wrote: > > Best wishes to the FreeBSD community. No hard feelings, and I will > > still continue to checkout the latest sources from time to time > > just on the outside chance that a solution will eventually be found. > > > > Sincerest regards from a long-time FreeBSD user now in exile. :-( > > Changing the OS just because one specific piece of swappable and > replaceable hardware isn't supported... isn't that overreacting a > little bit? Can't you circumvent your specific problem by adding a > supported adapter to your system(s)... at least until the issue is > fixed? As sysadmins, we do this all the time, wether with Linux or > FreeBSD. > > I feel your pain, but maybe you've built up quite a bit of frustration > over this specific issue and need a little hiatus. > > I hope you'll come back soon. I agree with you totally in principle, but my current financial situation/credit standing is such that I was forced to purchase this machine from one of the few vendors willing to offer me a line of credit. :-( If I could, I would gladly replace the non-functioning components, but I'm just too strapped for cash at the moment, so... I'm continuing to hold out hope that I can provide the missing bits of the puzzle that will lead to a solution. But I've already passed along everything I could get from Windows Vista's System Information tool, Linux's lspci command, and FreeBSD's pciconf and dmesg. I don't know what more iI can provide at this point. As another poster suggested, it's possible there's a bug/typo in the patches Soren sent me, although they all apply quite cleanly to every successive version of current I've tried them on. So...I'm at a loss at this point. It really is frustrating. I'm no fan of either Windows or Linux, but at least they do recognize my hardware. So I'm stuck for the time being. If anyone's interested, I'll repost or mail directly to them all the pertinent info I can gather. Just say the word and it shall be done. Thanks. -- Conrad J. Sabatier From ken at mthelicon.com Sat Dec 6 19:19:22 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Sat Dec 6 19:19:29 2008 Subject: Problems with zfsboot loader if raidz present on any drive Message-ID: <200812070319.18461.ken@mthelicon.com> Hello Hackers, Recently and friend and I have been trying to get the new gptzfsboot working on our machines and ran into a interesting problem. Initially I was building the world without the environment variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt work very well. Every time the machine booted, it would throw 2 lines after the pin-wheel and then reboot. I couldent read what the lines were it went so fast. My friend had a bit more luck and got his machine working OK with a single drive and later a mirror drive added. I added the environment variable and rebuilt everything and installed. This time, I could see the bios drives and a further 2 lines of ZFS something and a reboot... No matter what I tried, I couldent get the machine to boot up to a point where I could try and fix the problem, so I started pulling devices out and found the following: If there is a raidz pool on any drive (not necessarily the one that you are trying to boot from) the loader dies and reboots the machine. My friend, as an experiment created 3 gpt partitions (in addition to the single partition that he had been previously booted from) on his single drive and made a raidz pool for testing. His machine showed the same condition as mine, however he was able to capture the message before the machine rebooted: ZFS: can only boot from disk or mirror vdevs ZFS: inconsistent nvlist contents / ~Peg From peterjeremy at optushome.com.au Sat Dec 6 23:10:03 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Dec 6 23:10:09 2008 Subject: Running Forth/ficl as a user command ? In-Reply-To: <20081205142558.GA5394@onelab2.iet.unipi.it> References: <20081205142558.GA5394@onelab2.iet.unipi.it> Message-ID: <20081206204611.GO58682@server.vk2pj.dyndns.org> On 2008-Dec-05 15:25:58 +0100, Luigi Rizzo wrote: >apologies if the question is silly, but is there a >way to run the Forth interpreter embedded in /boot/loader >as a user command ? You could try building 'testmain' in src/sys/boot/ficl - I've not tried this but I think it does what you want. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081207/12038799/attachment.pgp From dfr at rabson.org Sun Dec 7 01:22:19 2008 From: dfr at rabson.org (Doug Rabson) Date: Sun Dec 7 01:22:26 2008 Subject: Problems with zfsboot loader if raidz present on any drive In-Reply-To: <200812070319.18461.ken@mthelicon.com> References: <200812070319.18461.ken@mthelicon.com> Message-ID: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > Hello Hackers, > > Recently and friend and I have been trying to get the new > gptzfsboot working > on our machines and ran into a interesting problem. > > Initially I was building the world without the environment variable > LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, > didnt work > very well. Every time the machine booted, it would throw 2 lines > after the > pin-wheel and then reboot. I couldent read what the lines were it > went so > fast. > > My friend had a bit more luck and got his machine working OK with a > single > drive and later a mirror drive added. > > I added the environment variable and rebuilt everything and > installed. This > time, I could see the bios drives and a further 2 lines of ZFS > something and a > reboot... > > No matter what I tried, I couldent get the machine to boot up to a > point > where I could try and fix the problem, so I started pulling devices > out and > found the following: If there is a raidz pool on any drive (not > necessarily > the one that you are trying to boot from) the loader dies and > reboots the > machine. My friend, as an experiment created 3 gpt partitions (in > addition to > the single partition that he had been previously booted from) on his > single > drive and made a raidz pool for testing. His machine showed the same > condition > as mine, however he was able to capture the message before the machine > rebooted: > > > ZFS: can only boot from disk or mirror vdevs > > ZFS: inconsistent nvlist contents The zfsboot code in current doesn't support raidz or raidz2. I have been working on adding that support but its not ready yet. The code works in my test harness but crashes instantly when I put it in the boot code :(. I should have time to finish debugging it soon. From hselasky at c2i.net Sun Dec 7 01:23:49 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Dec 7 01:24:01 2008 Subject: [Serious] busdma bug in -current in relation to USB hardware - review wanted In-Reply-To: <031DE609-3E5B-4508-BAB0-95800B7F02F4@mac.com> References: <20081107082740.GA1334@icarus.home.lan> <200812061334.55365.hselasky@c2i.net> <031DE609-3E5B-4508-BAB0-95800B7F02F4@mac.com> Message-ID: <200812071026.00497.hselasky@c2i.net> On Saturday 06 December 2008, Marcel Moolenaar wrote: > On Dec 6, 2008, at 4:34 AM, Hans Petter Selasky wrote: > > Hi, > > > > After various feedback from several people I have made a new patch > > proposal > > that will fix the busdma problem. > > > > See: > > > > http://perforce.freebsd.org/chv.cgi?CH=154181 > > > > Review wanted! > > The USB stack has a fixed page size of 4K. On our 64-bit platforms > PAGE_SIZE is at least 8K. Your change is sloppy in that respect > and doesn't make the distinction. That makes the patch a kluge. > The definition of BUS_DMA_NO_REALIGN is based on circumstantial > evidence only and as such, works as a side-effect. I don't think > that's a good design. > > I don't think there's any reason not to preserve the page offset > in all cases. So far all hardware worked whether or not their > DMA pages were bounced and the non-bounced pages would have a > possible non-zero page offset, whereas the bounced pages would > always have a zero page offset. In short: it works either way. > In particular, it works with the page offset preserved. Why not > preserve it always? What's the downside? Hi Marcel, I think you might be right there. There is one case in which I don't understand what is the correct busdma behaviour. If the DMA tag has an alignment of 4 bytes, and the memory loaded is not aligned to four bytes, then should a bounce page be used? If yes, then you will need to clear the page offset. Else not. NOTE: We are not talking about allocating DMA memory, only loading it. --HPS From stb at lassitu.de Sun Dec 7 02:21:16 2008 From: stb at lassitu.de (Stefan Bethke) Date: Sun Dec 7 02:21:28 2008 Subject: ZFS gets stuck In-Reply-To: <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Message-ID: <5C97E586-4296-4835-A103-FD273B2D7A4F@lassitu.de> For the past week, I've been stress testing two new boxes by running make -j4 universe. /usr/src is on ufs, /usr/obj on zfs, backed by a single disk pool. Every so often (about once every one or two days), processes start getting wedged on accessing the zfs file systems. Just this morning I found: output from make universe: >> sparc64 started on Sun Dec 7 01:34:41 UTC 2008 >> amd64 completed on Sun Dec 7 02:18:39 UTC 2008 >> pc98 buildworld completed on Sun Dec 7 02:24:35 UTC 2008 >> sun4v started on Sun Dec 7 02:30:45 UTC 2008 ps shows me these processes that apparently are waiting on some zfs operation: 0 81836 81830 0 47 0 6732 4056 zio->i D ?? 0:13.11 find -sx / /tank /tank/ports /usr/obj /dev/null -type f ( -perm -u+x - or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls - liTd {} + 0 86345 86344 0 76 0 11392 10300 zio->i D+ 0 0:00.53 make all DIRPRFX=kerberos5/lib/libasn1/ 0 91920 91420 0 76 0 7144 1792 zfsvfs D+ 0 0:00.00 sh -ev 0 91923 91902 0 76 0 2180 400 zfsvfs D+ 0 0:00.00 [cc] 0 91924 91900 0 76 0 10456 7572 zfsvfs D+ 0 0:00.02 / usr/obj/pc98/usr/src/tmp/usr/libexec/cc1 -E -quiet -nostdinc -I. -I@ - I@/contrib/altq -I/usr/obj/pc98/usr/src/sys/MAC -M -D_LONGLONG -DPC98 - D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS /usr/src/sys/ modules/smbfs/../../netsmb/smb_dev.c df still works, ls /tank blocks. FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Dec 3 07:05:03 UTC 2008 root@lokschuppen.lassitu.de:/usr/obj/usr/ src/sys/EISENBOOT amd64 So far, I've had this in loader.conf: vfs.zfs.arc_max="512M" vfs.zfs.prefetch_disable="1" I'm now adding vfs.zfs.zil_disable="1" to see if that makes a difference. Is there anything in particular people would want me to check out? Kernel is GENERIC minus a number of devices, and without INVARIANTS and WITNESS. Stefan -- Stefan Bethke Fon +49 170 346 0140 From joao.barros at gmail.com Sun Dec 7 03:09:36 2008 From: joao.barros at gmail.com (Joao Barros) Date: Sun Dec 7 03:09:43 2008 Subject: Problems with zfsboot loader if raidz present on any drive In-Reply-To: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> References: <200812070319.18461.ken@mthelicon.com> <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> Message-ID: <70e8236f0812070248p3341c24aob024995be08b962a@mail.gmail.com> On Sun, Dec 7, 2008 at 9:22 AM, Doug Rabson wrote: > > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > >> Hello Hackers, >> >> Recently and friend and I have been trying to get the new >> gptzfsboot working >> on our machines and ran into a interesting problem. >> >> Initially I was building the world without the environment variable >> LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt >> work >> very well. Every time the machine booted, it would throw 2 lines after the >> pin-wheel and then reboot. I couldent read what the lines were it went so >> fast. >> >> My friend had a bit more luck and got his machine working OK with a >> single >> drive and later a mirror drive added. >> >> I added the environment variable and rebuilt everything and >> installed. This >> time, I could see the bios drives and a further 2 lines of ZFS something >> and a >> reboot... >> >> No matter what I tried, I couldent get the machine to boot up to a >> point >> where I could try and fix the problem, so I started pulling devices out >> and >> found the following: If there is a raidz pool on any drive (not >> necessarily >> the one that you are trying to boot from) the loader dies and reboots the >> machine. My friend, as an experiment created 3 gpt partitions (in addition >> to >> the single partition that he had been previously booted from) on his >> single >> drive and made a raidz pool for testing. His machine showed the same >> condition >> as mine, however he was able to capture the message before the machine >> rebooted: >> >> >> ZFS: can only boot from disk or mirror vdevs >> >> ZFS: inconsistent nvlist contents > > The zfsboot code in current doesn't support raidz or raidz2. I have been > working on adding that support but its not ready yet. The code works in my > test harness but crashes instantly when I put it in the boot code :(. I > should have time to finish debugging it soon. > After installing my system yesterday on a single disk with gptzfsboot, I connected my old raidz and I only got cyclic reboots. I knew instantly it had something to do with the raidz. Disconnecting 2 out of the 4 disks of the raidz would allow the system to boot as the raidz would not present itself as ONLINE. As a temporary workaround for this problem I disabled those 2 disks on the BIOS, the system boots fine and the kernel is able to find them later. Doug, when you feel comfortable to share any patches, I'm willing to test :-) -- Joao Barros From peter.schuller at infidyne.com Sun Dec 7 03:35:12 2008 From: peter.schuller at infidyne.com (Peter Schuller) Date: Sun Dec 7 03:35:20 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> Message-ID: <20081207113509.GA19385@hyperion.scode.org> > While you are talking about it: Does anyone know if the fsync blocks > until the data is really stable on the device or if it simply returns > when ZIL is disabled? > > In my understanding the topmost block would need to be written for the > "commit" to be on disk. My understanding is that disabling the ZIL *will* break the semantics of fsync(). The claim of "always consistent on disk" is not violated and is still maintained, since consistency refers to ZFS' internal consistency. The tuning guide someone posts a link to later in this thread has specific claims about this IIRC; such as NFS breaking (because fsync-on-close semantics mandated by NFS, among other things, will not be honored). -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081207/2c6a6e2c/attachment.pgp From ken at mthelicon.com Sun Dec 7 04:17:24 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Sun Dec 7 04:17:36 2008 Subject: Problems with zfsboot loader if raidz present on any drive In-Reply-To: <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> References: <200812070319.18461.ken@mthelicon.com> <66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> Message-ID: <200812071217.20500.ken@mthelicon.com> On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > > Hello Hackers, > > > > Recently and friend and I have been trying to get the new > > gptzfsboot working > > on our machines and ran into a interesting problem. > > > > Initially I was building the world without the environment variable > > LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, > > didnt work > > very well. Every time the machine booted, it would throw 2 lines > > after the > > pin-wheel and then reboot. I couldent read what the lines were it > > went so > > fast. > > > > My friend had a bit more luck and got his machine working OK with a > > single > > drive and later a mirror drive added. > > > > I added the environment variable and rebuilt everything and > > installed. This > > time, I could see the bios drives and a further 2 lines of ZFS > > something and a > > reboot... > > > > No matter what I tried, I couldent get the machine to boot up to a > > point > > where I could try and fix the problem, so I started pulling devices > > out and > > found the following: If there is a raidz pool on any drive (not > > necessarily > > the one that you are trying to boot from) the loader dies and > > reboots the > > machine. My friend, as an experiment created 3 gpt partitions (in > > addition to > > the single partition that he had been previously booted from) on his > > single > > drive and made a raidz pool for testing. His machine showed the same > > condition > > as mine, however he was able to capture the message before the machine > > rebooted: > > > > > > ZFS: can only boot from disk or mirror vdevs > > > > ZFS: inconsistent nvlist contents > > The zfsboot code in current doesn't support raidz or raidz2. I have > been working on adding that support but its not ready yet. The code > works in my test harness but crashes instantly when I put it in the > boot code :(. I should have time to finish debugging it soon. Hi Doug, In my haste to put a message to the group, I didnt do a very good job of explaining or give what platform I was working with. I set up a single disk pool with the gptzfsboot code on it as a boot drive. My idea was to have a single disk boot (and after it boots and I can kill the UFS drive I am currently booting from) convert it to a mirror. But I have 6 other drives in the machine that I have as a raidz for my /usr/home, et al. If the 6 raidz drives are present at boot time, the machine starts to cyclic reboot just after the pin-wheel. The machine I am working on is running FBSD8.0-Current as of midnight 7/12/2008 and the platform is AMD64. If I can help test in any way I would be more than happy to try, or provide any information necessary.. ~Peg From morganw at chemikals.org Sun Dec 7 04:41:19 2008 From: morganw at chemikals.org (Wes Morgan) Date: Sun Dec 7 04:41:26 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: <20081207113509.GA19385@hyperion.scode.org> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <20081207113509.GA19385@hyperion.scode.org> Message-ID: On Sun, 7 Dec 2008, Peter Schuller wrote: >> While you are talking about it: Does anyone know if the fsync blocks >> until the data is really stable on the device or if it simply returns >> when ZIL is disabled? >> >> In my understanding the topmost block would need to be written for the >> "commit" to be on disk. > > My understanding is that disabling the ZIL *will* break the semantics > of fsync(). > > The claim of "always consistent on disk" is not violated and is still > maintained, since consistency refers to ZFS' internal consistency. > > The tuning guide someone posts a link to later in this thread has > specific claims about this IIRC; such as NFS breaking (because > fsync-on-close semantics mandated by NFS, among other things, will not > be honored). And this would also apply to databases that rely on fsync() for ACID compliance, such as postgres, right? From freebsdlists at bsdunix.ch Sun Dec 7 05:01:50 2008 From: freebsdlists at bsdunix.ch (Thomas Vogt) Date: Sun Dec 7 05:01:57 2008 Subject: HEADS UP: New ZFS in the tree. In-Reply-To: References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <20081207113509.GA19385@hyperion.scode.org> Message-ID: <9668C184-9534-4F0F-B633-C807DAD8ED95@bsdunix.ch> Hello Am 07.12.2008 um 13:41 schrieb Wes Morgan: > On Sun, 7 Dec 2008, Peter Schuller wrote: > >>> While you are talking about it: Does anyone know if the fsync blocks >>> until the data is really stable on the device or if it simply >>> returns >>> when ZIL is disabled? >>> >>> In my understanding the topmost block would need to be written for >>> the >>> "commit" to be on disk. >> >> My understanding is that disabling the ZIL *will* break the semantics >> of fsync(). >> >> The claim of "always consistent on disk" is not violated and is still >> maintained, since consistency refers to ZFS' internal consistency. >> >> The tuning guide someone posts a link to later in this thread has >> specific claims about this IIRC; such as NFS breaking (because >> fsync-on-close semantics mandated by NFS, among other things, will >> not >> be honored). > > And this would also apply to databases that rely on fsync() for ACID > compliance, such as postgres, right? Yes. I do not recomment to disable ZIL in general. In my case it's just a workaround to get rid of deadlocks on my -CURRENT server (many rsync,http and ftp processes). It's also common to disable ZIL for better NFS performance but as Peter mentioned it has some drawbacks. Read: http://blogs.sun.com/erickustarz/entry/zil_disable it explains some drawbacks for fsync() and NFS. Quote: Disabling the ZIL can cause corruption for NFS clients in the case where a reply to the client is done before the server crashes, and the server crashes before the data is commited to stable storage. If you can't live with this, then don't turn off the ZIL. Regrads, Thomas Vogt From zeiztm at gmail.com Sun Dec 7 06:56:29 2008 From: zeiztm at gmail.com (Greg Wang) Date: Sun Dec 7 07:28:54 2008 Subject: 8.0-CURRENT: No disks found! Message-ID: Regular boot gives "fatal trap #12", "no acpi" and "safe mode" both give message "no disks found!" on sysinstall screen (partitioning). Both hashes are OK, burned @x4, 3 different CDs were tried. Asus P4S333c (SiS chipset 645/961), P4 2.4GHz, mem 768MB, ps2 keyboard, ps2 mouse, GeForce3-Ti200, monitor Viewsonic VA912b (1280x1024). 6.0, 6.2, 6.3, 6.4, 7.0 and 7.1-Beta2 - all run perfectly on that machine. Did 8.0 drop supporting SiS? Or what could be a reason? Another machine: Asus M3N78-VM, AthlonX2 (4450e) 2.3GHz, DDR2-800-4GB, NVidia chip, GeForce 8200 (onboard), ps2 keyboard, usb-mouse, SATA -HDD, SATA CD/DVD-W, all features - onboard. Monitor: SyncMaster2253bw. 8.0-CURRENT amd64 version. With CD1 could install only Base, Kernel and docs. Anything else including Xorg cannot be installed (error: no Index present). FTP: "there is no distribution on ftp://... do you want to try another ftp site?" pkg_add output: command not found. Again hashes are OK, 2 CDs were tried. Downloaded dvd.iso 3 times: first failed @97% (error: cannot copy from server), second download finished successfully but .iso file couldn't be found (mystery!), 3-rd download was OK. However I got the same problem with Index files on the DVD and "no distribution" with FTP using sysinstall. Fortunately dvd installed pkg_add and I managed to install X and then Gnome. Currently have problem with correct resolution (1680x1050) only 1280x1024 available as maximum. There is no data for ModeLine in xorg.0.log mentioned in handbook. Tried to force in xorg.conf: Section Monitor: HoryzSync 30.0-81.0 VertRefresh 50.0-76.0 Option "DPMS" that was accepted as well as DefaultDepth 24 under Screen section. Section Screen: Modes "1680x1050" Doesn't work. xorg.0.log output: "not used, no such name" ) xorg.0.log + - in the attachment. Installed KDE4 to try adjusting the resolution from there. Installed successfully, but then on boot screen: .../kdm: no such file or directory. The file /usr/local/bin/kdm - is there. In general 8.0-CURRENT-amd64 runs amazingly! Much better than Ubuntu8.10x64 and Suse11.1-beta5 I tried. Many thanks to developers! I realize that it's not even a beta and some features might not work, but maybe my info is useful. Thanks once more. -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log.old Type: application/octet-stream Size: 67120 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081207/ee395233/Xorg.0.log.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 2239 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081207/ee395233/xorg.obj From bsam at ipt.ru Sun Dec 7 08:16:37 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Dec 7 08:16:45 2008 Subject: gmirror+gjournal, newfs -J: can't figure out file system partition Message-ID: <48202685@bb.ipt.ru> Hello List, I can't do a newfs for gmirror+gjournal at two days old amd64-current: ----- tba# gmirror label -vb round-robin gm0 ad8 ad12 Metadata value stored on ad8. Metadata value stored on ad12. Done. tba# gmirror load GEOM_MIRROR: Device mirror/gm0 launched (2/2). tba# gjournal label mirror/gm0 ad4s2d tba# gjournal load GEOM_JOURNAL: Journal 3161485294: mirror/gm0 contains data. GEOM_JOURNAL: Journal 3161485294: ad4s2d contains journal. GEOM_JOURNAL: Journal mirror/gm0 clean. tba# newfs -J /dev/mirror/gm0.journal newfs: /dev/mirror/gm0.journal: can't figure out file system partition ----- Am I doing something stupid? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From marius at alchemy.franken.de Sun Dec 7 08:19:50 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Dec 7 08:19:57 2008 Subject: [Serious] busdma bug in -current in relation to USB hardware - review wanted In-Reply-To: <200812061334.55365.hselasky@c2i.net> References: <20081107082740.GA1334@icarus.home.lan> <200811081023.10058.hselasky@freebsd.org> <200811161408.21562.hselasky@c2i.net> <200812061334.55365.hselasky@c2i.net> Message-ID: <20081207161947.GA82662@alchemy.franken.de> On Sat, Dec 06, 2008 at 01:34:54PM +0100, Hans Petter Selasky wrote: > Hi, > > After various feedback from several people I have made a new patch proposal > that will fix the busdma problem. > > See: > > http://perforce.freebsd.org/chv.cgi?CH=154181 > > Review wanted! > > I don't know how to patch the psyco interface for SUN. Maybe there is nothing > that needs to be patched? Neither sparc64 nor sun4u has support for bounce buffers; it's not really worth the effort to implement IOMMU-bypass and bounce buffers for the few devices only doing < 32-bit DMA and for >= 32-bit DMA the IOMMU takes care of the address translation for all practical purposes. In any case this isn't specific to psycho(4). Marius From bsam at ipt.ru Sun Dec 7 08:45:53 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Dec 7 08:46:01 2008 Subject: gmirror+gjournal, newfs -J: can't figure out file system partition In-Reply-To: <48202685@bb.ipt.ru> (Boris Samorodov's message of "Sun\, 07 Dec 2008 19\:16\:34 +0300") References: <48202685@bb.ipt.ru> Message-ID: <82120927@bb.ipt.ru> Boris Samorodov writes: > I can't do a newfs for gmirror+gjournal at two days old amd64-current: Hm, even gjournal is not newfs'ed: ----- tba# gjournal label ad8 tba# gjournal load GEOM_JOURNAL: Journal 2321310154: ad8 contains data. GEOM_JOURNAL: Journal 2321310154: ad8 contains journal. GEOM_JOURNAL: Journal ad8 clean. tba# newfs -J ad8.journal newfs: /dev/ad8.journal: can't figure out file system partition ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From marck at rinet.ru Sun Dec 7 09:39:44 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Dec 7 09:39:53 2008 Subject: gmirror+gjournal, newfs -J: can't figure out file system partition In-Reply-To: <82120927@bb.ipt.ru> References: <48202685@bb.ipt.ru> <82120927@bb.ipt.ru> Message-ID: On Sun, 7 Dec 2008, Boris Samorodov wrote: BS> Boris Samorodov writes: BS> BS> > I can't do a newfs for gmirror+gjournal at two days old amd64-current: BS> BS> Hm, even gjournal is not newfs'ed: BS> ----- BS> tba# gjournal label ad8 BS> tba# gjournal load BS> GEOM_JOURNAL: Journal 2321310154: ad8 contains data. BS> GEOM_JOURNAL: Journal 2321310154: ad8 contains journal. BS> GEOM_JOURNAL: Journal ad8 clean. BS> tba# newfs -J ad8.journal BS> newfs: /dev/ad8.journal: can't figure out file system partition BS> ----- well, what if you create BSD partition inside it: bsdlabel -Bw ad8 gjournal ad8a gjournal load newfs -J ad8a.journal ? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From bsam at ipt.ru Sun Dec 7 10:37:53 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Dec 7 10:38:00 2008 Subject: gmirror+gjournal, newfs -J: can't figure out file system partition In-Reply-To: (Dmitry Morozovsky's message of "Sun\, 7 Dec 2008 20\:39\:42 +0300 \(MSK\)") References: <48202685@bb.ipt.ru> <82120927@bb.ipt.ru> Message-ID: <05319744@bb.ipt.ru> Dmitry Morozovsky writes: > On Sun, 7 Dec 2008, Boris Samorodov wrote: > BS> Boris Samorodov writes: > BS> > BS> > I can't do a newfs for gmirror+gjournal at two days old amd64-current: > BS> > BS> Hm, even gjournal is not newfs'ed: > BS> ----- > BS> tba# gjournal label ad8 > BS> tba# gjournal load > BS> GEOM_JOURNAL: Journal 2321310154: ad8 contains data. > BS> GEOM_JOURNAL: Journal 2321310154: ad8 contains journal. > BS> GEOM_JOURNAL: Journal ad8 clean. > BS> tba# newfs -J ad8.journal > BS> newfs: /dev/ad8.journal: can't figure out file system partition > BS> ----- > > well, what if you create BSD partition inside it: > > bsdlabel -Bw ad8 > gjournal ad8a > gjournal load > newfs -J ad8a.journal The same. But: # gjournal label ad8 # gjournal load # bsdlabel -Bw ad8.journal # newfs -J ad8.journala ...was a success. CCing to luigi@. There are chances his recent commit may broke newfs for journal. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From onemda at gmail.com Sun Dec 7 10:51:05 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Dec 7 10:51:12 2008 Subject: how to config for run compiz fusion In-Reply-To: <1228461620.1175.1.camel@www.boolome.cn> References: <1228461620.1175.1.camel@www.boolome.cn> Message-ID: <3a142e750812071051m51d65581p49640ce5adc3c023@mail.gmail.com> On 12/5/08, boolome wrote: >> On Fri, 2008-12-05 at 11:14 +0800, boolome wrote: >> > Option "AccelMethod" "XAA" >> > Option "XAANoOffscreenPixmaps" "true" >> > Option "AddARGBGLXVisuals" "true" >> >> Try using EXA, which is the default. i.e. comment out all of the > above >> lines. Otherwise, it looks very much like what I run on my 965... > What >> version of FreeBSD are you running? >> >> robert. >> > I have commented the lines you mentioned . but problem same. > %uname -a > FreeBSD www.boolome.cn 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Oct 19 > 16:07:48 CST 2008 > boolome@www.boolome.cn:/usr/obj/usr/src/sys/boolome i386 You are using very old CURRENT. That version of CURRENT is known to have broken DRM/DRI on some intel cards. -- Paul From pr+freebsd-current at x0.dk Sun Dec 7 15:03:21 2008 From: pr+freebsd-current at x0.dk (Phil Regnauld) Date: Sun Dec 7 15:03:28 2008 Subject: em(4) not sending/receiving data in recent current ? Message-ID: <20081207223009.GA27635@macbook.catpipe.net> Hi all, I recently upgraded a system (Dell Vostro desktop) running 8.0-CURRENT/amd64 from July to -current from a few days ago, and em(4) stopped working. By this I mean: - em0 probes and attaches correctly - link is detected - sending any data to/from the host simply fails tcpdump shows incoming ARP requests and they seem to be accepted by the ARP stack, and pinging another host shows outgoing ARP requests, but nothing is seen on the wire by the other hosts. Anyone else experiencing this, and could this be related to the em/e1000/igb split ? Cheers, Phil em0: port 0xfe00-0xfe1f mem 0xfdfc0000-0xfdfdffff,0xfdfff000-0xfdffffff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1d:09:91:25:e4 em0: link state changed to UP From marck at rinet.ru Sun Dec 7 15:38:07 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Dec 7 15:38:15 2008 Subject: HEADSUP: CVS/Mirror mode for csup to be merged soon In-Reply-To: <20081201092900.GB1397@nobby.lan> References: <20081125154040.GA12632@nobby.lan> <20081201092900.GB1397@nobby.lan> Message-ID: On Mon, 1 Dec 2008, Ulf Lilleengen wrote: UL> I have gotten some positive reports, thanks for testing! So far, a bug UL> involving SKIP directory handling have been fixed. I still have one report UL> which I'd like to investigate more before getting anything in. In addition, UL> there seems to be performance problems on some files (with many deltas, such UL> as CVSROOT-*/modules,v etc.) due to some slow algorithms used in the RCS UL> handling. I'll try to speed it up a bit when it seems to work ok. Together I found my building machin stuck with csup eating all CPU and non-killable wither by HUP or TERM. It seems csup goes mad after server closing connection for some reason: Rsync CVSROOT-ports/exclude Receiver: Connection reset by peer ... there csup runs and runs... Any comments? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From mike at sentex.net Sun Dec 7 15:38:21 2008 From: mike at sentex.net (Mike Tancsa) Date: Sun Dec 7 15:38:28 2008 Subject: em(4) not sending/receiving data in recent current ? In-Reply-To: <20081207223009.GA27635@macbook.catpipe.net> References: <20081207223009.GA27635@macbook.catpipe.net> Message-ID: <200812072338.mB7NcIOu037177@lava.sentex.ca> At 05:30 PM 12/7/2008, Phil Regnauld wrote: >Anyone else experiencing this, and could this be related to the >em/e1000/igb split ? My current test box seems to be functioning fine from Dec 5th code igb0: port 0x3020-0x303f mem 0x48420000-0x4843ffff,0x48200000-0x483fffff,0x48444000-0x48447fff irq 16 at device 0.0 on pci1 igb0: Using MSIX interrupts with 6 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:30:48:94:87:68 igb1: port 0x3000-0x301f mem 0x48400000-0x4841ffff,0x48000000-0x481fffff,0x48440000-0x48443fff irq 17 at device 0.1 on pci1 igb1: Using MSIX interrupts with 6 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:30:48:94:87:69 em0: port 0x2000-0x201f mem 0x48680000-0x4869ffff,0x48600000-0x4867ffff irq 17 at device 0.0 on pci5 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:57:21:52 vgapci0: port 0x1000-0x10ff mem 0x40000000-0x47ffffff,0x48540000-0x4854ffff irq 18 at device 4.0 on pci6 em1: port 0x1100-0x113f mem 0x48520000-0x4853ffff,0x48500000-0x4851ffff irq 17 at device 5.0 on pci6 em1: [FILTER] em1: Ethernet address: 00:15:17:57:21:53 em0@pci0:5:0:0: class=0x020000 card=0x348d8086 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint em1@pci0:6:5:0: class=0x020000 card=0x348d8086 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction ---Mike From marck at rinet.ru Sun Dec 7 15:54:20 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Dec 7 15:54:28 2008 Subject: HEADSUP: CVS/Mirror mode for csup to be merged soon In-Reply-To: References: <20081125154040.GA12632@nobby.lan> <20081201092900.GB1397@nobby.lan> Message-ID: On Mon, 8 Dec 2008, Dmitry Morozovsky wrote: DM> Together I found my building machin stuck with csup eating all CPU and DM> non-killable wither by HUP or TERM. It seems csup goes mad after server closing DM> connection for some reason: DM> DM> Rsync CVSROOT-ports/exclude DM> Receiver: Connection reset by peer DM> ... DM> there csup runs and runs... DM> DM> Any comments? Thanks in advance. Sidenote: for current dataset, I can reliably lock csup in running state right after beginning parsing cvsroot-all collection. I tried two different CVSUP mirrors. I use ZFS on FreeBSD tree at given machine, and have a snapshot in case it would be useful. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From jfvogel at gmail.com Sun Dec 7 16:11:48 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun Dec 7 16:11:55 2008 Subject: em(4) not sending/receiving data in recent current ? In-Reply-To: <20081207223009.GA27635@macbook.catpipe.net> References: <20081207223009.GA27635@macbook.catpipe.net> Message-ID: <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> Can you please give me pciconf -lv Jack On Sun, Dec 7, 2008 at 2:30 PM, Phil Regnauld > wrote: > Hi all, > > I recently upgraded a system (Dell Vostro desktop) running > 8.0-CURRENT/amd64 from July to -current from a few days ago, > and em(4) stopped working. > > By this I mean: > > - em0 probes and attaches correctly > - link is detected > - sending any data to/from the host simply fails > > tcpdump shows incoming ARP requests and they seem to be accepted > by the ARP stack, and pinging another host shows outgoing ARP requests, but > nothing is seen on the wire by the other hosts. > > Anyone else experiencing this, and could this be related to the > em/e1000/igb split ? > > Cheers, > Phil > > > em0: port 0xfe00-0xfe1f mem > 0xfdfc0000-0xfdfdffff,0xfdfff000-0xfdffffff irq 20 at device 25.0 on pci0 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:1d:09:91:25:e4 > em0: link state changed to UP > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From bzeeb-lists at lists.zabbadoz.net Sun Dec 7 17:05:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Dec 7 17:05:15 2008 Subject: em(4) not sending/receiving data in recent current ? In-Reply-To: <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> References: <20081207223009.GA27635@macbook.catpipe.net> <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> Message-ID: <20081208010013.R80401@maildrop.int.zabbadoz.net> On Sun, 7 Dec 2008, Jack Vogel wrote: Hi, > Can you please give me pciconf -lv I think the problem here is that the last driver import nuked one line essential for IPv4. Andrew Thompson readded it a few hours ago. See http://svn.freebsd.org/changeset/base/185748 /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From jfvogel at gmail.com Sun Dec 7 17:46:09 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun Dec 7 17:46:16 2008 Subject: em(4) not sending/receiving data in recent current ? In-Reply-To: <20081208010013.R80401@maildrop.int.zabbadoz.net> References: <20081207223009.GA27635@macbook.catpipe.net> <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> <20081208010013.R80401@maildrop.int.zabbadoz.net> Message-ID: <2a41acea0812071746n2d4b1094mf0631ff9163b3c1a@mail.gmail.com> DUH, and I was SO careful to keep those new #ifdef INET, somehow that header include just flew right on by :) Sorry all!! Jack On Sun, Dec 7, 2008 at 5:02 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Sun, 7 Dec 2008, Jack Vogel wrote: > > Hi, > > Can you please give me pciconf -lv >> > > I think the problem here is that the last driver import nuked one > line essential for IPv4. Andrew Thompson readded it a few hours ago. > See > http://svn.freebsd.org/changeset/base/185748 > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. > From mcdouga9 at egr.msu.edu Sun Dec 7 19:24:42 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Sun Dec 7 19:24:49 2008 Subject: ZFS gets stuck In-Reply-To: <5C97E586-4296-4835-A103-FD273B2D7A4F@lassitu.de> References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <5C97E586-4296-4835-A103-FD273B2D7A4F@lassitu.de> Message-ID: <20081208032440.GU93166@egr.msu.edu> On Sun, Dec 07, 2008 at 11:21:13AM +0100, Stefan Bethke wrote: For the past week, I've been stress testing two new boxes by running make -j4 universe. /usr/src is on ufs, /usr/obj on zfs, backed by a single disk pool. Every so often (about once every one or two days), processes start getting wedged on accessing the zfs file systems. FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed Dec 3 07:05:03 UTC 2008 root@lokschuppen.lassitu.de:/usr/obj/usr/ src/sys/EISENBOOT amd64 So far, I've had this in loader.conf: vfs.zfs.arc_max="512M" vfs.zfs.prefetch_disable="1" I'm now adding vfs.zfs.zil_disable="1" to see if that makes a difference. Is there anything in particular people would want me to check out? Kernel is GENERIC minus a number of devices, and without INVARIANTS and WITNESS. I have one system running a recent -current with 2G of ram that would tend to get stuck almost nightly during a nightly rsync, and have been trying to tune it to get rid of the problems. I've made it about 6 days so far using just: vm.kmem_size=2G vm.kmem_size_max=2G vfs.zfs.arc_max=512M With these settings, I had two rsyncs running constantly for probably 12 hours on the first day or two and still once nightly, so far so good. I tried leaving the kmem settings out and while vm.kmem_size_max appeared to auto tune to approx 4.5G, I still had a out of kmem panic (a low number around 600 or 900M, I don't remember) until I boosted both kmem settings to 2G. I previously had ~1.6G for the kmem settings from when that was the highest they could be set, and maybe that wasn't high enough with recent -current because it had hangs every few days as opposed to every few months with zfs "6" (same zfs as in -stable). I might just be having a string of good luck, and the data that rsync transfers might have played a role (it changes a varying amount each day). If it looks fairly stable then I will apply the settings to a different, busier server with ZFS. From pr+freebsd-current at x0.dk Mon Dec 8 00:49:27 2008 From: pr+freebsd-current at x0.dk (Phil Regnauld) Date: Mon Dec 8 00:49:35 2008 Subject: em(4) not sending/receiving data in recent current ? In-Reply-To: <2a41acea0812071746n2d4b1094mf0631ff9163b3c1a@mail.gmail.com> References: <20081207223009.GA27635@macbook.catpipe.net> <2a41acea0812071550g40aaefc2yf0b9ccd6bc7bc981@mail.gmail.com> <20081208010013.R80401@maildrop.int.zabbadoz.net> <2a41acea0812071746n2d4b1094mf0631ff9163b3c1a@mail.gmail.com> Message-ID: <20081208084924.GA28330@macbook.catpipe.net> Jack Vogel (jfvogel) writes: > DUH, and I was SO careful to keep those new #ifdef INET, somehow that > header include just flew right on by :) > > Sorry all!! Funny, I have two IPv6 tunnels, rtsold running, IPv6 etc... and I NEVER thought to check if IPv6 was running :) Phil From yanefbsd at gmail.com Mon Dec 8 01:55:53 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Dec 8 01:56:00 2008 Subject: make buildworld failed! In-Reply-To: <1228555830.1186.6.camel@www.boolome.cn> References: <1228555830.1186.6.camel@www.boolome.cn> Message-ID: <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: [snip] Looks like your source tree is incomplete. -Garrett From vova at fbsd.ru Mon Dec 8 04:27:23 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Mon Dec 8 04:27:30 2008 Subject: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample In-Reply-To: <200811301906.mAUJ6Z30099035@svn.freebsd.org> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> Message-ID: <1228739237.1860.21.camel@localhost> * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: > Author: sam > Date: Sun Nov 30 19:06:35 2008 > New Revision: 185482 > URL: http://svn.freebsd.org/changeset/base/185482 > > Log: > Major overhaul: > o eliminate private state indexed by 802.11 rate codes; use the hal's > rate tables directly to get the same info > o calculate a mask of operational rates to optimize lookups and checks > (instead of using for loops and similar) > o optimize size bin operations > o ignore rates marked as "do not use" in the hal phy tables > o fix bug that caused upshifting to break in 11g once the rate dropped > below 11Mb/s > o add more intelligent multi-rate tx schedules > o add support for 1/2 and 1/4 width channels > o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console > (needs to go up to a user app) > o export more tuning knobs via sysctls (still a couple of magic constants) Looks like, after that commit, I can't use if_ath loaded as module any more: # kldload /boot/kernel/ath_rate.ko kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory # dmesg | tail -n1 link_elf: symbol ath_hal_computetxtime undefined # Yes, I've read UPDATING entry 20081130. But I have no ath_hal entry in my kernel config, I've loaded ath as KLDs. How to fix that problem ? -- Vladimir B. Grebenschikov vova@fbsd.ru From vova at fbsd.ru Mon Dec 8 04:40:09 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Mon Dec 8 04:40:16 2008 Subject: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample In-Reply-To: <493D1436.3030606@quis.cx> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> <493D1436.3030606@quis.cx> Message-ID: <1228740002.1860.26.camel@localhost> On Mon, 2008-12-08 at 13:33 +0100, Jille Timmermans wrote: after cd /sys/modules/ath_rate_amrr make all make install kldload /boot/kernel/ath_rate .ko It works now, but why three directories in sys/modules tree make same .ko object: # fgrep ath /sys/modules/Makefile ath \ ath_rate_amrr \ ath_rate_onoe \ ath_rate_sample \ # fgrep KMOD /sys/modules/ath_rate*/Makefile /sys/modules/ath_rate_amrr/Makefile:KMOD= ath_rate /sys/modules/ath_rate_onoe/Makefile:KMOD= ath_rate /sys/modules/ath_rate_sample/Makefile:KMOD= ath_rate # Looks like one overwrites another. What is right behaviour ? > Vladimir Grebenschikov wrote: > > * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: > > > >> Author: sam > >> Date: Sun Nov 30 19:06:35 2008 > >> New Revision: 185482 > >> URL: http://svn.freebsd.org/changeset/base/185482 > >> > >> Log: > >> Major overhaul: > >> o eliminate private state indexed by 802.11 rate codes; use the hal's > >> rate tables directly to get the same info > >> o calculate a mask of operational rates to optimize lookups and checks > >> (instead of using for loops and similar) > >> o optimize size bin operations > >> o ignore rates marked as "do not use" in the hal phy tables > >> o fix bug that caused upshifting to break in 11g once the rate dropped > >> below 11Mb/s > >> o add more intelligent multi-rate tx schedules > >> o add support for 1/2 and 1/4 width channels > >> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console > >> (needs to go up to a user app) > >> o export more tuning knobs via sysctls (still a couple of magic constants) > >> > > > > Looks like, after that commit, I can't use if_ath loaded as module any > > more: > > > > # kldload /boot/kernel/ath_rate.ko > > kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory > > # dmesg | tail -n1 > > link_elf: symbol ath_hal_computetxtime undefined > > # > > > > Yes, I've read UPDATING entry 20081130. > > But I have no ath_hal entry in my kernel config, > > I've loaded ath as KLDs. > > > > How to fix that problem ? > > > I have the same problem if I load it with kernel modules. > If I compile it into my kernel (with ath, ath_hal and that option (can't > remember it for now)) my system paniced during boot. > I can't get a coredump, but I will try getting a stacktrace with ddb > tonight. > > My Atheros (2413 iirc) wasn't usable before the import (did some > printf's during boot, but I couldn't get ath0 showing up in ifconfig) > I am willing to help debugging if needed. > > -- Jille -- Vladimir B. Grebenschikov vova@fbsd.ru From jille at quis.cx Mon Dec 8 04:49:07 2008 From: jille at quis.cx (Jille Timmermans) Date: Mon Dec 8 04:49:16 2008 Subject: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample In-Reply-To: <1228739237.1860.21.camel@localhost> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> Message-ID: <493D1436.3030606@quis.cx> Vladimir Grebenschikov wrote: > * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: > >> Author: sam >> Date: Sun Nov 30 19:06:35 2008 >> New Revision: 185482 >> URL: http://svn.freebsd.org/changeset/base/185482 >> >> Log: >> Major overhaul: >> o eliminate private state indexed by 802.11 rate codes; use the hal's >> rate tables directly to get the same info >> o calculate a mask of operational rates to optimize lookups and checks >> (instead of using for loops and similar) >> o optimize size bin operations >> o ignore rates marked as "do not use" in the hal phy tables >> o fix bug that caused upshifting to break in 11g once the rate dropped >> below 11Mb/s >> o add more intelligent multi-rate tx schedules >> o add support for 1/2 and 1/4 width channels >> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console >> (needs to go up to a user app) >> o export more tuning knobs via sysctls (still a couple of magic constants) >> > > Looks like, after that commit, I can't use if_ath loaded as module any > more: > > # kldload /boot/kernel/ath_rate.ko > kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory > # dmesg | tail -n1 > link_elf: symbol ath_hal_computetxtime undefined > # > > Yes, I've read UPDATING entry 20081130. > But I have no ath_hal entry in my kernel config, > I've loaded ath as KLDs. > > How to fix that problem ? > I have the same problem if I load it with kernel modules. If I compile it into my kernel (with ath, ath_hal and that option (can't remember it for now)) my system paniced during boot. I can't get a coredump, but I will try getting a stacktrace with ddb tonight. My Atheros (2413 iirc) wasn't usable before the import (did some printf's during boot, but I couldn't get ath0 showing up in ifconfig) I am willing to help debugging if needed. -- Jille From gavin.atkinson at ury.york.ac.uk Mon Dec 8 06:36:39 2008 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Mon Dec 8 06:36:56 2008 Subject: i give up In-Reply-To: <20081206190754.6c2bbd70@serene.no-ip.org> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> <20081206190754.6c2bbd70@serene.no-ip.org> Message-ID: <1228746983.27498.1.camel@buffy.york.ac.uk> On Sat, 2008-12-06 at 19:07 -0600, Conrad J. Sabatier wrote: > I'm continuing to hold out hope that I can provide the missing bits of > the puzzle that will lead to a solution. But I've already passed along > everything I could get from Windows Vista's System Information tool, > Linux's lspci command, and FreeBSD's pciconf and dmesg. I don't know > what more iI can provide at this point. You could perhaps provide it again? I've still not seen it. > As another poster suggested, it's possible there's a bug/typo in the > patches Soren sent me, although they all apply quite cleanly to every > successive version of current I've tried them on. So...I'm at a loss > at this point. It really is frustrating. > > I'm no fan of either Windows or Linux, but at least they do recognize > my hardware. So I'm stuck for the time being. > > If anyone's interested, I'll repost or mail directly to them all the > pertinent info I can gather. Just say the word and it shall be done. Please. Gavin From onemda at gmail.com Mon Dec 8 06:58:16 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Dec 8 06:58:23 2008 Subject: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head Message-ID: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> I got panic, after pressing shutdown button: FreeBSD dhcppc1 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Dec 8 12:39:23 CET 2008 root@dhcppc1:/usr/obj/usr/src/sys/KERNEL i386 db:1:lockinfo> show locks db:1:locks> show alllocks Process 994 (wpa_supplicant) thread 0xc4756900 (100112) db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid = 0 curthread = 0xc4756900: pid 994 "wpa_supplicant" curpcb = 0xe6518d90 fpcurthread = none idlethread = 0xc3d0ab40: pid 10 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: db:0:kdb.enter.panic> bt Tracing pid 994 tid 100112 td 0xc4756900 kdb_enter(c06181da,c06181da,c0617bc2,e6518868,0,...) at kdb_enter+0x3a panic(c0617bc2,c0603f55,c061e0eb,c0627193,3a9,...) at panic+0x136 _rw_wlock_hard(c3e53280,c4756900,c0627193,3a9,0,...) at _rw_wlock_hard+0x66 _rw_wlock(c3e53280,c0627193,3a9,c061da2b,3,...) at _rw_wlock+0xae rtrequest1_fib(2,e6518920,0,0,0,...) at rtrequest1_fib+0x92 rtrequest_fib(2,c59b2500,0,0,20405,...) at rtrequest_fib+0x5e rt_fixdelete(c59c10f0,c4124e10,22,c4124e10,c4124e74,...) at rt_fixdelete+0x51 rn_walktree_from(c3e53200,e6518a54,c47e8370,c054fa60,c4124e10,...) at rn_walktree_from+0xd6 rtrequest1_fib(2,e6518a20,e6518a50,0,c4744a00,...) at rtrequest1_fib+0x1ad rtinit(c4744a00,2,0,c4744a00,c06586c0,...) at rtinit+0x2d4 in_ifscrub(c3e6ec00,c4744a00,c06586c0,c06582fc,e6518b38,...) at in_ifscrub+0xed rip_ctlinput(0,c4744ab4,0,c4744a00,c3e6ec00,...) at rip_ctlinput+0x49 pfctlinput(0,c4744ab4,80206910,8842,e6518bb0,...) at pfctlinput+0x3b if_down(c3e6ec00,18f,c07ece44,63a,c3e6ec00,...) at if_down+0x36 ifhwioctl(c4756900,c07bfdc8,c47569a4,c07bfdc8,c064ded0,...) at ifhwioctl+0x2f9 ifioctl(c412e7a8,80206910,c477f440,c4756900,80206910,...) at ifioctl+0x301 soo_ioctl(c4016d20,80206910,c477f440,c4111d00,c4756900,...) at soo_ioctl+0x397 kern_ioctl(c4756900,3,80206910,c477f440,c477f440,...) at kern_ioctl+0x1dd ioctl(c4756900,e6518cf8,c,c063bd0b,c0646070,...) at ioctl+0x12f syscall(e6518d38) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28370063, esp = 0xbfbfe77c, ebp = 0xbfbfe7e8 --- <118>Stopping moused. <118>Stopping powerd. <118>Stopping devd. <118>Writing entropy file: <118>. <118>. <118>Dec 8 15:08:04 syslogd: exiting on signal 15 panic: _rw_wlock_hard: recursing but non-recursive rw radix node head @ /usr/src/sys/net/route.c:937 cpuid = 0 KDB: enter: panic exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ /usr/src/sys/net/route.c:1019 exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) locked @ /usr/src/sys/net/route.c:937 exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ /usr/src/sys/net/route.c:1019 exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) locked @ /usr/src/sys/net/route.c:937 -- Paul From kmacy at freebsd.org Mon Dec 8 07:30:19 2008 From: kmacy at freebsd.org (Kip Macy) Date: Mon Dec 8 07:30:26 2008 Subject: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head In-Reply-To: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> References: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> Message-ID: <3c1674c90812080730k7f5cc57cqcd41c574cc46ae3d@mail.gmail.com> Will post a fix this afternoon. Thanks, Kip On Mon, Dec 8, 2008 at 6:58 AM, Paul B. Mahol wrote: > I got panic, after pressing shutdown button: > > FreeBSD dhcppc1 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Dec 8 12:39:23 CET 2008 > root@dhcppc1:/usr/obj/usr/src/sys/KERNEL i386 > > db:1:lockinfo> show locks > db:1:locks> show alllocks > Process 994 (wpa_supplicant) thread 0xc4756900 (100112) > db:1:alllocks> show lockedvnods > Locked vnodes > db:0:kdb.enter.panic> show pcpu > cpuid = 0 > curthread = 0xc4756900: pid 994 "wpa_supplicant" > curpcb = 0xe6518d90 > fpcurthread = none > idlethread = 0xc3d0ab40: pid 10 "idle: cpu0" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > db:0:kdb.enter.panic> bt > Tracing pid 994 tid 100112 td 0xc4756900 > kdb_enter(c06181da,c06181da,c0617bc2,e6518868,0,...) at kdb_enter+0x3a > panic(c0617bc2,c0603f55,c061e0eb,c0627193,3a9,...) at panic+0x136 > _rw_wlock_hard(c3e53280,c4756900,c0627193,3a9,0,...) at _rw_wlock_hard+0x66 > _rw_wlock(c3e53280,c0627193,3a9,c061da2b,3,...) at _rw_wlock+0xae > rtrequest1_fib(2,e6518920,0,0,0,...) at rtrequest1_fib+0x92 > rtrequest_fib(2,c59b2500,0,0,20405,...) at rtrequest_fib+0x5e > rt_fixdelete(c59c10f0,c4124e10,22,c4124e10,c4124e74,...) at rt_fixdelete+0x51 > rn_walktree_from(c3e53200,e6518a54,c47e8370,c054fa60,c4124e10,...) at > rn_walktree_from+0xd6 > rtrequest1_fib(2,e6518a20,e6518a50,0,c4744a00,...) at rtrequest1_fib+0x1ad > rtinit(c4744a00,2,0,c4744a00,c06586c0,...) at rtinit+0x2d4 > in_ifscrub(c3e6ec00,c4744a00,c06586c0,c06582fc,e6518b38,...) at in_ifscrub+0xed > rip_ctlinput(0,c4744ab4,0,c4744a00,c3e6ec00,...) at rip_ctlinput+0x49 > pfctlinput(0,c4744ab4,80206910,8842,e6518bb0,...) at pfctlinput+0x3b > if_down(c3e6ec00,18f,c07ece44,63a,c3e6ec00,...) at if_down+0x36 > ifhwioctl(c4756900,c07bfdc8,c47569a4,c07bfdc8,c064ded0,...) at ifhwioctl+0x2f9 > ifioctl(c412e7a8,80206910,c477f440,c4756900,80206910,...) at ifioctl+0x301 > soo_ioctl(c4016d20,80206910,c477f440,c4111d00,c4756900,...) at soo_ioctl+0x397 > kern_ioctl(c4756900,3,80206910,c477f440,c477f440,...) at kern_ioctl+0x1dd > ioctl(c4756900,e6518cf8,c,c063bd0b,c0646070,...) at ioctl+0x12f > syscall(e6518d38) at syscall+0x283 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28370063, esp = > 0xbfbfe77c, ebp = 0xbfbfe7e8 --- > > > > > <118>Stopping moused. > <118>Stopping powerd. > <118>Stopping devd. > <118>Writing entropy file: > <118>. > <118>. > <118>Dec 8 15:08:04 syslogd: exiting on signal 15 > panic: _rw_wlock_hard: recursing but non-recursive rw radix node head > @ /usr/src/sys/net/route.c:937 > > cpuid = 0 > KDB: enter: panic > exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ > /usr/src/sys/net/route.c:1019 > exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) > locked @ /usr/src/sys/net/route.c:937 > exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ > /usr/src/sys/net/route.c:1019 > exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) > locked @ /usr/src/sys/net/route.c:937 > > > -- > Paul > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From mike at sentex.net Mon Dec 8 08:21:26 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Dec 8 08:21:33 2008 Subject: uart vs sio differences ? Message-ID: <200812081621.mB8GLMxB041498@lava.sentex.ca> Hi, We are in the process of migrating one of our embedded apps to use uart by default instead of sio in RELENG_7 in prep for the day when sio eventually disappears. (The same problems we are having happen as well on HEAD, so I am posting here). Unfortunately, the application doesnt want to work with uart with puc backed devices, but still works with sio. Stranger still, the app works with the uart driver when uart attaches to the built in com port on the isa bus. However, its uart devices when its connected to a PUC backed serial card where the problems happen. e.g. when the uart driver attaches as so, puc0: port 0xe520-0xe53f,0xe540-0xe55f mem 0xa0005000-0xa0005fff,0xa0006000-0xa0006fff irq 15 at device 17.0 on pci0 puc0: [FILTER] uart0: <16950 or compatible> on puc0 uart0: [FILTER] uart1: <16950 or compatible> on puc0 uart1: [FILTER] uart2: <16950 or compatible> on puc0 uart2: [FILTER] uart3: <16950 or compatible> on puc0 uart3: [FILTER] the applications does not work. When its the sio driver, it works as expected. Not sure if thats an issue of the larger buffers of the 16950 vs 16650? i.e. sio sees it as a plain old 16550 vs uart seeing it as a 16950 puc0: port 0xe520-0xe53f,0xe540-0xe55f mem 0xa0005000-0xa0005fff,0xa0006000-0xa0006fff irq 15 at device 17.0 on pci0 puc0: [FILTER] sio1 on puc0 sio1: type 16550A sio1: [FILTER] sio2 on puc0 sio2: type 16550A sio2: [FILTER] sio3 on puc0 sio3: type 16550A sio3: [FILTER] sio4 on puc0 sio4: type 16550A sio4: [FILTER] Unfortunately, we only control the FreeBSD side of things and the other end of the serial connection is a windows app we dont control. Everything seems to work ok from our side, but the other side which we dont control seems to be missing some things we are sending it and vice versa. However, if I use something like minicom or cu, I see 2 way communication just fine and I can transfer data back and forth just fine. Is it possible some defaults are different from sio to uart that our app might not be setting properly when opening up the port ? The open routine is below static int open_dev(struct dev *dev) { struct termios t; int val; cur_state.carrier = 0; if (cur_state.num_trans == 0) { cur_state.startup = time(0); } TRY_OPEN_AGAIN: dev->fd = open(dev->name, O_RDWR); if (dev->fd >= 0) { if (debug) { syslog(LOG_LOCAL1 | LOG_DEBUG, "(%s) %s:%d: open_dev", dev->name, __FILE__, __LINE__); } if (tcgetattr(dev->fd, &t) >= 0) { t.c_ispeed = dev->speed; t.c_ospeed = dev->speed; t.c_lflag &= ~(ICANON | ISIG | IEXTEN | ECHO | ECHOE | ECHOK | ECHOKE | ECHONL | ECHOCTL | ECHOPRT | ALTWERASE | NOFLSH | TOSTOP | FLUSHO | PENDIN | NOKERNINFO | EXTPROC); t.c_iflag &= ~(ISTRIP | ICRNL | INLCR | IGNCR | IXON | IXOFF | IXANY | IMAXBEL | IGNBRK | BRKINT | INPCK | IGNPAR | PARM RK); t.c_oflag &= ~(OPOST | ONLCR | OCRNL | OXTABS | ONOEOT | ONOCR | ONLRET); t.c_cflag &= ~(CSIZE | CSTOPB | PARENB | CCTS_OFLOW | CRTS_IFLOW | CDTR_IFLOW | CDSR_OFLOW | CCAR_OFLOW); t.c_cflag |= (CS8); t.c_cc[VMIN] = 1; t.c_cc[VTIME] = 0; tcsetattr(dev->fd, TCSANOW, &t); val = fcntl(dev->fd, F_GETFL, 0); if (val >= 0) { fcntl(dev->fd, F_SETFL, val | O_NONBLOCK); } } else { tcflush(dev->fd, TCIOFLUSH); close(dev->fd); dev->fd = -1; } } else { if (errno == EINTR) goto TRY_OPEN_AGAIN; syslog(LOG_LOCAL1 | LOG_DEBUG, "(%s) open_dev errno=%d %s", dev->name, errno, strerror(errno)); } return dev->fd; } ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From xcllnt at mac.com Mon Dec 8 10:49:52 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Dec 8 10:49:59 2008 Subject: uart vs sio differences ? In-Reply-To: <200812081621.mB8GLMxB041498@lava.sentex.ca> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> Message-ID: On Dec 8, 2008, at 8:21 AM, Mike Tancsa wrote: > Unfortunately, we only control the FreeBSD side of things and the > other end of the serial connection is a windows app we dont > control. Everything seems to work ok from our side, but the other > side which we dont control seems to be missing some things we are > sending it and vice versa. It looks to me that flow-control is disabled, is that right? Not only does uart(4) make use of the larger buffer of the hardware, it's also more efficient under puc(4) than sio(4) is because of the use of the serdev I/F. It's possible that the receiver can not keep up when uart(4) is used. A serial line analyzer should tell you more... FYI, -- Marcel Moolenaar xcllnt@mac.com From mike at sentex.net Mon Dec 8 11:06:53 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Dec 8 11:07:00 2008 Subject: uart vs sio differences ? In-Reply-To: References: <200812081621.mB8GLMxB041498@lava.sentex.ca> Message-ID: <200812081906.mB8J6oha042222@lava.sentex.ca> At 01:49 PM 12/8/2008, Marcel Moolenaar wrote: >On Dec 8, 2008, at 8:21 AM, Mike Tancsa wrote: > >>Unfortunately, we only control the FreeBSD side of things and the >>other end of the serial connection is a windows app we dont >>control. Everything seems to work ok from our side, but the other >>side which we dont control seems to be missing some things we are >>sending it and vice versa. > >It looks to me that flow-control is disabled, is that right? > >Not only does uart(4) make use of the larger buffer of the >hardware, it's also more efficient under puc(4) than sio(4) >is because of the use of the serdev I/F. It's possible that >the receiver can not keep up when uart(4) is used. A serial >line analyzer should tell you more... Hi, Yes, flow control is supposed to be disabled. When we hook up a serial line analyzer, the behaviour is rather odd. We only use 1200bps, so I dont think its a speed issue. Also, as part of the protocol, we poll the other side. We send a 3 byte poll, which the Windows side always sees, and it sends us back a 1 byte answer, which we see fine. However, when the Windows side has "something to say", it will send a different 1 byte response (which we get) and then the data, which is approximately 100 to 200 bytes which we only get about 30 bytes of. ---Mike From xcllnt at mac.com Mon Dec 8 11:18:11 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Dec 8 11:18:17 2008 Subject: uart vs sio differences ? In-Reply-To: <200812081906.mB8J6oha042222@lava.sentex.ca> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> Message-ID: On Dec 8, 2008, at 11:06 AM, Mike Tancsa wrote: > At 01:49 PM 12/8/2008, Marcel Moolenaar wrote: > >> On Dec 8, 2008, at 8:21 AM, Mike Tancsa wrote: >> >>> Unfortunately, we only control the FreeBSD side of things and the >>> other end of the serial connection is a windows app we dont >>> control. Everything seems to work ok from our side, but the other >>> side which we dont control seems to be missing some things we are >>> sending it and vice versa. >> >> It looks to me that flow-control is disabled, is that right? >> >> Not only does uart(4) make use of the larger buffer of the >> hardware, it's also more efficient under puc(4) than sio(4) >> is because of the use of the serdev I/F. It's possible that >> the receiver can not keep up when uart(4) is used. A serial >> line analyzer should tell you more... > > Hi, > Yes, flow control is supposed to be disabled. When we hook > up a serial line analyzer, the behaviour is rather odd. We only use > 1200bps, so I dont think its a speed issue. Also, as part of the > protocol, we poll the other side. We send a 3 byte poll, which the > Windows side always sees, and it sends us back a 1 byte answer, > which we see fine. However, when the Windows side has "something to > say", it will send a different 1 byte response (which we get) and > then the data, which is approximately 100 to 200 bytes which we only > get about 30 bytes of. I see, so the FreeBSD box with uart(4) is missing data, not the Windows machine, right? Do you know if you get the first 30 bytes or the last 30 bytes or some mix? -- Marcel Moolenaar xcllnt@mac.com From bahamasfranks at gmail.com Mon Dec 8 11:27:06 2008 From: bahamasfranks at gmail.com (Steve Franks) Date: Mon Dec 8 11:37:13 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <20081206023016.GF22093@cdnetworks.co.kr> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> Message-ID: <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> Hi, Test: seems my L1E is not appearing. pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) [steve@dynstant ~]$ sudo kldload if_ale kldload: can't load if_ale: File exists [steve@dynstant ~]$ uname -a FreeBSD dynstant 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Dec 5 13:41:49 MST 2008 root@dynstant:/usr/obj/usr/src/sys/TILDE i386 I'm happy to poke around things if anyone can give me some guidance about what to test... Device is L1E embedded on the PCI-e bus on my motherboard....I suspect that is the problem. Thanks, Steve On Fri, Dec 5, 2008 at 7:30 PM, Pyun YongHyeon wrote: > On Fri, Dec 05, 2008 at 06:00:06PM +0300, Boris Samorodov wrote: > > Pyun YongHyeon writes: > > > On Wed, Nov 05, 2008 at 10:35:58AM +0900, To Jan Henrik Sylvester wrote: > > > > On Tue, Nov 04, 2008 at 10:36:21PM +0100, Jan Henrik Sylvester wrote: > > > > > Pyun YongHyeon wrote: > > > > > >On Mon, Nov 03, 2008 at 07:49:34PM +0100, Jan Henrik Sylvester wrote: > > > > > > > >Pyun YongHyeon writes: > > > > > > > >> http://people.freebsd.org/~yongari/ale/if_ale.c > > > > > > > > > > > > > > I got an Eee PC 1000H, too, with 7.1-BETA2 and just used scp to copy > > > > > > > with 11.5MB/s -- much better than wlan for big files. Great! > > > > > > > > > > > > > > > > > > >Thanks for testing! > > > > > > > > > > I was happy too early. Now I keep getting these: > > > > > ale0: DMA read error! -- resetting > > > > > ale0: could not disable Tx/Rx MAC(0x00000008)! > > > > > > FYI: Fix committed to HEAD(r185577). > > > > Works fine for me at EEEPC-1000. Good rate (~10MB/s), no interface > > UP/DOWN, no messages. Big thank you! > > > > No problem. Thanks for testing! > > -- > Regards, > Pyun YongHyeon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From kmacy at freebsd.org Mon Dec 8 11:51:19 2008 From: kmacy at freebsd.org (Kip Macy) Date: Mon Dec 8 11:51:26 2008 Subject: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head In-Reply-To: <3c1674c90812080730k7f5cc57cqcd41c574cc46ae3d@mail.gmail.com> References: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> <3c1674c90812080730k7f5cc57cqcd41c574cc46ae3d@mail.gmail.com> Message-ID: <3c1674c90812081151x9aef0eek256c69df3929f8ae@mail.gmail.com> Please try the following patch: http://www.fsmware.com/freebsd/rnh_lock_recursion.diff Thanks, Kip On Mon, Dec 8, 2008 at 7:30 AM, Kip Macy wrote: > Will post a fix this afternoon. > > Thanks, > Kip > > On Mon, Dec 8, 2008 at 6:58 AM, Paul B. Mahol wrote: >> I got panic, after pressing shutdown button: >> >> FreeBSD dhcppc1 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Dec 8 12:39:23 CET 2008 >> root@dhcppc1:/usr/obj/usr/src/sys/KERNEL i386 >> >> db:1:lockinfo> show locks >> db:1:locks> show alllocks >> Process 994 (wpa_supplicant) thread 0xc4756900 (100112) >> db:1:alllocks> show lockedvnods >> Locked vnodes >> db:0:kdb.enter.panic> show pcpu >> cpuid = 0 >> curthread = 0xc4756900: pid 994 "wpa_supplicant" >> curpcb = 0xe6518d90 >> fpcurthread = none >> idlethread = 0xc3d0ab40: pid 10 "idle: cpu0" >> APIC ID = 0 >> currentldt = 0x50 >> spin locks held: >> db:0:kdb.enter.panic> bt >> Tracing pid 994 tid 100112 td 0xc4756900 >> kdb_enter(c06181da,c06181da,c0617bc2,e6518868,0,...) at kdb_enter+0x3a >> panic(c0617bc2,c0603f55,c061e0eb,c0627193,3a9,...) at panic+0x136 >> _rw_wlock_hard(c3e53280,c4756900,c0627193,3a9,0,...) at _rw_wlock_hard+0x66 >> _rw_wlock(c3e53280,c0627193,3a9,c061da2b,3,...) at _rw_wlock+0xae >> rtrequest1_fib(2,e6518920,0,0,0,...) at rtrequest1_fib+0x92 >> rtrequest_fib(2,c59b2500,0,0,20405,...) at rtrequest_fib+0x5e >> rt_fixdelete(c59c10f0,c4124e10,22,c4124e10,c4124e74,...) at rt_fixdelete+0x51 >> rn_walktree_from(c3e53200,e6518a54,c47e8370,c054fa60,c4124e10,...) at >> rn_walktree_from+0xd6 >> rtrequest1_fib(2,e6518a20,e6518a50,0,c4744a00,...) at rtrequest1_fib+0x1ad >> rtinit(c4744a00,2,0,c4744a00,c06586c0,...) at rtinit+0x2d4 >> in_ifscrub(c3e6ec00,c4744a00,c06586c0,c06582fc,e6518b38,...) at in_ifscrub+0xed >> rip_ctlinput(0,c4744ab4,0,c4744a00,c3e6ec00,...) at rip_ctlinput+0x49 >> pfctlinput(0,c4744ab4,80206910,8842,e6518bb0,...) at pfctlinput+0x3b >> if_down(c3e6ec00,18f,c07ece44,63a,c3e6ec00,...) at if_down+0x36 >> ifhwioctl(c4756900,c07bfdc8,c47569a4,c07bfdc8,c064ded0,...) at ifhwioctl+0x2f9 >> ifioctl(c412e7a8,80206910,c477f440,c4756900,80206910,...) at ifioctl+0x301 >> soo_ioctl(c4016d20,80206910,c477f440,c4111d00,c4756900,...) at soo_ioctl+0x397 >> kern_ioctl(c4756900,3,80206910,c477f440,c477f440,...) at kern_ioctl+0x1dd >> ioctl(c4756900,e6518cf8,c,c063bd0b,c0646070,...) at ioctl+0x12f >> syscall(e6518d38) at syscall+0x283 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28370063, esp = >> 0xbfbfe77c, ebp = 0xbfbfe7e8 --- >> >> >> >> >> <118>Stopping moused. >> <118>Stopping powerd. >> <118>Stopping devd. >> <118>Writing entropy file: >> <118>. >> <118>. >> <118>Dec 8 15:08:04 syslogd: exiting on signal 15 >> panic: _rw_wlock_hard: recursing but non-recursive rw radix node head >> @ /usr/src/sys/net/route.c:937 >> >> cpuid = 0 >> KDB: enter: panic >> exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ >> /usr/src/sys/net/route.c:1019 >> exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) >> locked @ /usr/src/sys/net/route.c:937 >> exclusive sleep mutex rtentry (rtentry) r = 0 (0xc4124e74) locked @ >> /usr/src/sys/net/route.c:1019 >> exclusive rw radix node head (radix node head) r = 0 (0xc3e53280) >> locked @ /usr/src/sys/net/route.c:937 >> >> >> -- >> Paul >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > > > -- > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From gavin.atkinson at ury.york.ac.uk Mon Dec 8 11:54:03 2008 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Mon Dec 8 11:54:11 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> Message-ID: <1228766037.27498.6.camel@buffy.york.ac.uk> On Mon, 2008-12-08 at 12:27 -0700, Steve Franks wrote: > Hi, > > Test: seems my L1E is not appearing. > > > pcib1: irq 16 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.1 on pci0 > pci2: on pcib2 > pci2: at device 0.0 (no driver attached) > > [steve@dynstant ~]$ sudo kldload if_ale > kldload: can't load if_ale: File exists > > [steve@dynstant ~]$ uname -a > FreeBSD dynstant 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Dec 5 > 13:41:49 MST 2008 root@dynstant:/usr/obj/usr/src/sys/TILDE i386 > > I'm happy to poke around things if anyone can give me some guidance > about what to test... > > Device is L1E embedded on the PCI-e bus on my motherboard....I suspect > that is the problem. Firstly: The output of "pciconf -lcv" relating to the device in question would be essential. Gavin From mike at sentex.net Mon Dec 8 12:49:20 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Dec 8 12:49:29 2008 Subject: uart vs sio differences ? In-Reply-To: References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> Message-ID: <200812082049.mB8KnHSN042710@lava.sentex.ca> At 02:18 PM 12/8/2008, Marcel Moolenaar wrote: >I see, so the FreeBSD box with uart(4) is missing data, >not the Windows machine, right? Hi, Correct. The FreeBSD box never gets the full data, nor do we see it on the "protocol analyzer". Our analyzer is just a special serial cable that copies the data from both sides to the monitor program (a dos app) on another machine. >Do you know if you get the first 30 bytes or the last 30 >bytes or some mix? Just checked, and we get the first 31 bytes each time. Is it possible the larger fifo buffer of the 16950 is holding onto the data too long ? The sio sees it as a plain old 16550, but the uart driver sees it as the 16950 that it is. ---Mike From onemda at gmail.com Mon Dec 8 13:02:06 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Dec 8 13:02:13 2008 Subject: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head In-Reply-To: <3c1674c90812081151x9aef0eek256c69df3929f8ae@mail.gmail.com> References: <3a142e750812080658r645dc1c4sdd612585fe9ad7d6@mail.gmail.com> <3c1674c90812080730k7f5cc57cqcd41c574cc46ae3d@mail.gmail.com> <3c1674c90812081151x9aef0eek256c69df3929f8ae@mail.gmail.com> Message-ID: <3a142e750812081302x2fd8bfcbqa61ea663f6786751@mail.gmail.com> On 12/8/08, Kip Macy wrote: > Please try the following patch: > > http://www.fsmware.com/freebsd/rnh_lock_recursion.diff > > Thanks, > Kip Fixed. Thanks. -- Paul From xcllnt at mac.com Mon Dec 8 13:02:20 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Dec 8 13:02:26 2008 Subject: uart vs sio differences ? In-Reply-To: <200812082049.mB8KnHSN042710@lava.sentex.ca> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> Message-ID: <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> On Dec 8, 2008, at 12:49 PM, Mike Tancsa wrote: > At 02:18 PM 12/8/2008, Marcel Moolenaar wrote: > >> I see, so the FreeBSD box with uart(4) is missing data, >> not the Windows machine, right? > > Hi, > Correct. The FreeBSD box never gets the full data, nor do we > see it on the "protocol analyzer". Our analyzer is just a special > serial cable that copies the data from both sides to the monitor > program (a dos app) on another machine. Interesting. If it never shows up on the analyzer, then doesn't that indicate that it was never sent? Put differently: doesn't that indicate that the transmitter stops sending, and not that the receiver stops receiving? >> Do you know if you get the first 30 bytes or the last 30 >> bytes or some mix? > > > Just checked, and we get the first 31 bytes each time. Ok. Could you check if any of RTS/CTS, DTR/DSR or DCD toggles after about 30 characters? If the analyzer also just gets the 30 characters, then maybe the receiver signaled the transmitter to stop (think of the 16950 as having HW flow-control enabled and doing it on its own, without knowledge of the kernel). > Is it possible the larger fifo buffer of the 16950 is holding onto > the data too long ? The sio sees it as a plain old 16550, but the > uart driver sees it as the 16950 that it is. The 16950 has a 128-byte FIFO, so even if it holds on to data too long, I would expect to receive at least 128 bytes of data... -- Marcel Moolenaar xcllnt@mac.com From josh.carroll at gmail.com Mon Dec 8 13:23:18 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Mon Dec 8 13:23:25 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> Message-ID: <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> > Device is L1E embedded on the PCI-e bus on my motherboard....I suspect > that is the problem. > > Thanks, > Steve Which motherboard? I have an Asus P5Q Pro, and it's being recognized properly on RELENG_7_1: % grep ale /var/run/dmesg.boot ale0: port 0xdc00-0xdc7f mem 0xfeac0000-0xfeafffff irq 17 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. miibus0: on ale0 ale0: Ethernet address: 00:23:54:31:7f:5b ale0: [FILTER] relevant pciconf -lv output: ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' class = network subclass = ethernet iperf (ale0 as -s): [ 3] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec iperf (ale0 as -c): [ 3] 0.0-10.0 sec 1.08 GBytes 931 Mbits/sec So all seems well here. Josh From nealhogan at gmail.com Mon Dec 8 13:50:23 2008 From: nealhogan at gmail.com (Neal Hogan) Date: Mon Dec 8 13:50:31 2008 Subject: boot hang with 7.1BETA2 (12/08) an no wifi Message-ID: Hi, I'm new to fBSD and recently installed 7.0 on my HP pavillion ze4400 (multiboot w/ XP). It appeared to work fine. I had it on there for several weeks and was just snooping around. Well, I attempted to upgrade to 7.1 prerelease. I used *freebsd-update upgrade -r 7.1-BETA2* and it seemed to work. However, when I reboot the system is hung after the the following line: pci1: on pcib1. I reboot with ACPI disabled and it boot fine. Below is my dmesg. Also, my wifi card doesn't work and I don't see it in the dmesg. The same was true of 7.0. This computer is older than my interest in *BSD. So, I don't know what card it has. Note that it works under XP. Thanks. Copyright (c) 1992-2008 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 7.1-PRERELEASE-p1 #0: Mon Nov 24 11:49:24 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: mobile AMD Athlon(tm) XP2400+ (1788.94-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383f9ff AMD Features=0xc0480800 real memory = 468647936 (446 MB) avail memory = 444547072 (423 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Using invalid BIOS IRQ 5 from 0.10.INTA for link 0x6 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xe0000000-0xefffffff,0xd0100000-0xd010ffff irq 10 at device 5.0 on pci1 ohci0: mem 0xd0006000-0xd0006fff irq 9 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered pcm0: port 0x8400-0x84ff mem 0xd0007000-0xd0007fff irq 5 at device 6.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 8.0 (no driver attached) pci0: at device 9.0 (no driver attached) cbb0: mem 0x80000000-0x80000fff irq 5 at device 10.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: mem 0xd0009000-0xd00097ff,0xd0000000-0xd0003fff irq 10 at device 12.0 on pci0 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:0d:9d:71:9e:43:0c:6a fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:0d:9d:43:0c:6a fwe0: Ethernet address: 02:0d:9d:43:0c:6a fwip0: on firewire0 fwip0: Firewire address: 00:0d:9d:71:9e:43:0c:6a @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12c0000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8080-0x808f at device 16.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 17.0 (no driver attached) sis0: port 0x8c00-0x8cff mem 0xd000a000-0xd000afff irq 11 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:0d:9d:43:2b:a7 sis0: [ITHREAD] cpu0 on motherboard powernow0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcf7ff,0xdb000-0xdbfff,0xdc000-0xdffff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FILTER] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) ums0: on uhub0 ums0: 16 buttons and Z dir. umass0: on uhub0 Timecounter "TSC" frequency 1788940177 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 95396MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 246MB (503808 512 byte sectors: 64H 32S/T 246C) Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 56 files 2 WARNING: /var was not properly dismounted -- www.nealhogan.net From mike at sentex.net Mon Dec 8 14:39:30 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Dec 8 14:39:37 2008 Subject: uart vs sio differences ? In-Reply-To: <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> Message-ID: <200812082239.mB8MdRhb043206@lava.sentex.ca> At 04:02 PM 12/8/2008, Marcel Moolenaar wrote: >On Dec 8, 2008, at 12:49 PM, Mike Tancsa wrote: > >>At 02:18 PM 12/8/2008, Marcel Moolenaar wrote: >> >>>I see, so the FreeBSD box with uart(4) is missing data, >>>not the Windows machine, right? >> >>Hi, >> Correct. The FreeBSD box never gets the full data, nor do we >>see it on the "protocol analyzer". Our analyzer is just a special >>serial cable that copies the data from both sides to the monitor >>program (a dos app) on another machine. > >Interesting. If it never shows up on the analyzer, then >doesn't that indicate that it was never sent? >Put differently: doesn't that indicate that the transmitter >stops sending, and not that the receiver stops receiving? What it appears to be is that as long as data is coming in, even at 1200bps, the ioctl FIONREAD returns zero and an actual read does not return any data until there is either a pause in the data coming in or possibly when we do a xmit/write at which point the accumulated data is available for us to read. We dont know if this is due to the hardware fifo or something in the driver itself. >>>Do you know if you get the first 30 bytes or the last 30 >>>bytes or some mix? >> >> >>Just checked, and we get the first 31 bytes each time. > >Ok. > >Could you check if any of RTS/CTS, DTR/DSR or DCD toggles >after about 30 characters? I am not sure if the DOS software we use reliably sees that. We have a fancier windows app that might be more accurate. ---Mike >If the analyzer also just gets the 30 characters, then maybe >the receiver signaled the transmitter to stop (think of the >16950 as having HW flow-control enabled and doing it on its >own, without knowledge of the kernel). > >> Is it possible the larger fifo buffer of the 16950 is holding onto >>the data too long ? The sio sees it as a plain old 16550, but the >>uart driver sees it as the 16950 that it is. > >The 16950 has a 128-byte FIFO, so even if it holds on to >data too long, I would expect to receive at least 128 >bytes of data... >-- >Marcel Moolenaar >xcllnt@mac.com > > From nakaji at jp.freebsd.org Mon Dec 8 14:47:43 2008 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Mon Dec 8 14:47:53 2008 Subject: Fatal trap 12: page fault while in kernel mode In-Reply-To: <863ah2qivi.fsf@ra333.heimat.gr.jp> (NAKAJI Hiroyuki's message of "Sat, 06 Dec 2008 08:53:21 +0900") References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> <863ah2qivi.fsf@ra333.heimat.gr.jp> Message-ID: <86iqpu2sjc.fsf@ra333.heimat.gr.jp> >>>>> In <863ah2qivi.fsf@ra333.heimat.gr.jp> >>>>> NAKAJI Hiroyuki wrote: > So, what I have to do are three: > 1. Full upgrade to the latest kernel and userland (world) > 2. Observe whether a panic occurs, and > 3. When panic, save the crash dump and get full bt with kgdb > I hope it will not reach to the step three. Thanks. Unfortunately, I faced to "db> " on my serial console. db> bt Tracing pid 964 tid 100131 td 0xc49876c0 svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_internal+ 0x575 svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_start+0x10 fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0xc, esp = 0x33, ebp = 0 --- db> call doadump Physical memory: 1010 MB Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 Dump complete = 0xf db> bt Tracing pid 964 tid 100131 td 0xc49876c0 svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_internal+ 0x575 svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_start+0x10 fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0xc, esp = 0x33, ebp = 0 --- db> reset And then, I used kgdb. # kgdb /boot/kernel/kernel.symbols vmcore.9 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0a57a75 stack pointer = 0x28:0xe6861c44 frame pointer = 0x28:0xe6861cec code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 964 (nfsd: service) Physical memory: 1010 MB Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/mga.ko...Reading symbols from /boot/kernel/mga.ko.symbols...done. done. Loaded symbols for /boot/kernel/mga.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from /boot/kernel/logo_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/logo_saver.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc04c2a69 in db_fncall (dummy1=-1059812576, dummy2=0, dummy3=-1067505768, dummy4=0xe68619d8 "?:i?\2008'?") at /usr/src/sys/ddb/db_command.c:548 #2 0xc04c2e61 in db_command (last_cmdp=0xc0d3e85c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04c2fba in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04c4dfd in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc08a2456 in kdb_trap (type=12, code=0, tf=0xe6861c04) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc0b8059f in trap_fatal (frame=0xe6861c04, eva=0) at /usr/src/sys/i386/i386/trap.c:920 #7 0xc0b80860 in trap_pfault (frame=0xe6861c04, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:842 #8 0xc0b8126a in trap (frame=0xe6861c04) at /usr/src/sys/i386/i386/trap.c:522 #9 0xc0b652cb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc0a57a75 in svc_run_internal (pool=0xc44f2780, ismaster=0) at /usr/src/sys/rpc/svc.c:787 #11 0xc0a57ff0 in svc_thread_start (arg=0xc44f2780) at /usr/src/sys/rpc/svc.c:1188 #12 0xc0850793 in fork_exit (callout=0xc0a57fe0 , arg=0xc44f2780, frame=0xe6861d38) at /usr/src/sys/kern/kern_fork.c:821 #13 0xc0b65340 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) In addition, # addr2line -e /boot/kernel/kernel.symbols 0xc0a57a75 /usr/src/sys/rpc/svc.c:787 Any help is appreciated. Thanks. -- NAKAJI Hiroyuki From kmacy at freebsd.org Mon Dec 8 14:49:51 2008 From: kmacy at freebsd.org (Kip Macy) Date: Mon Dec 8 14:49:58 2008 Subject: Fatal trap 12: page fault while in kernel mode In-Reply-To: <86iqpu2sjc.fsf@ra333.heimat.gr.jp> References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> <863ah2qivi.fsf@ra333.heimat.gr.jp> <86iqpu2sjc.fsf@ra333.heimat.gr.jp> Message-ID: <3c1674c90812081449r7b8ef242lce478da3d2d7a968@mail.gmail.com> Recently - starting when? Thanks, Kip On Mon, Dec 8, 2008 at 2:47 PM, NAKAJI Hiroyuki wrote: >>>>>> In <863ah2qivi.fsf@ra333.heimat.gr.jp> >>>>>> NAKAJI Hiroyuki wrote: > >> So, what I have to do are three: > >> 1. Full upgrade to the latest kernel and userland (world) >> 2. Observe whether a panic occurs, and >> 3. When panic, save the crash dump and get full bt with kgdb > >> I hope it will not reach to the step three. Thanks. > > Unfortunately, I faced to "db> " on my serial console. > > db> bt > Tracing pid 964 tid 100131 td 0xc49876c0 > svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_internal+ > 0x575 > svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_start+0x10 > fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0xc, esp = 0x33, ebp = 0 --- > db> call doadump > Physical memory: 1010 MB > Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 > Dump complete > = 0xf > db> bt > Tracing pid 964 tid 100131 td 0xc49876c0 > svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_internal+ > 0x575 > svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_start+0x10 > fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0xc, esp = 0x33, ebp = 0 --- > db> reset > > And then, I used kgdb. > > # kgdb /boot/kernel/kernel.symbols vmcore.9 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0a57a75 > stack pointer = 0x28:0xe6861c44 > frame pointer = 0x28:0xe6861cec > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 964 (nfsd: service) > Physical memory: 1010 MB > Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 > > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linprocfs.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/smbus.ko > Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/aio.ko > Reading symbols from /boot/kernel/mga.ko...Reading symbols from /boot/kernel/mga.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/mga.ko > Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/drm.ko > Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/atapicam.ko > Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/nullfs.ko > Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from /boot/kernel/logo_saver.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/logo_saver.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc04c2a69 in db_fncall (dummy1=-1059812576, dummy2=0, dummy3=-1067505768, > dummy4=0xe68619d8 "?:i?\2008'?") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04c2e61 in db_command (last_cmdp=0xc0d3e85c, cmd_table=0x0, dopager=1) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04c2fba in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0xc04c4dfd in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 > #5 0xc08a2456 in kdb_trap (type=12, code=0, tf=0xe6861c04) > at /usr/src/sys/kern/subr_kdb.c:534 > #6 0xc0b8059f in trap_fatal (frame=0xe6861c04, eva=0) > at /usr/src/sys/i386/i386/trap.c:920 > #7 0xc0b80860 in trap_pfault (frame=0xe6861c04, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:842 > #8 0xc0b8126a in trap (frame=0xe6861c04) at /usr/src/sys/i386/i386/trap.c:522 > #9 0xc0b652cb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #10 0xc0a57a75 in svc_run_internal (pool=0xc44f2780, ismaster=0) > at /usr/src/sys/rpc/svc.c:787 > #11 0xc0a57ff0 in svc_thread_start (arg=0xc44f2780) > at /usr/src/sys/rpc/svc.c:1188 > #12 0xc0850793 in fork_exit (callout=0xc0a57fe0 , > arg=0xc44f2780, frame=0xe6861d38) at /usr/src/sys/kern/kern_fork.c:821 > #13 0xc0b65340 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 > (kgdb) > > In addition, > > # addr2line -e /boot/kernel/kernel.symbols 0xc0a57a75 > /usr/src/sys/rpc/svc.c:787 > > Any help is appreciated. Thanks. > -- > NAKAJI Hiroyuki > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis From sobomax at FreeBSD.org Mon Dec 8 14:51:14 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Dec 8 14:51:21 2008 Subject: Enhancing cdboot [patch for review] Message-ID: <493DA269.2070805@FreeBSD.org> Hi, Below please find patch that enhances cdboot with two compile-time options: 1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce any messages except "Loading, please wait..." and it also passes RBX_MUTE flag to the next stage to silence it as well. This is intended for custom installations where end-user is not required to see any messages or interfere with the boot process. 2. CDBOOT_PROMPT. When this option is enabled the cdboot behaves like windows xp or vista cd loader, that is it reads MBR from the first hard drive in the system and if the MBR is bootable (i.e. drive has some other operating system installed on it) then it presents user with "Press any key to boot from CD" prompt and waits 20 seconds. If key is not pressed then the control is passed to the MBR, otherwise CD is booted. This is intended for installation CD to allow unattended mode and also helps when installation CD is unintentionally left in the drive of the machine that is set to boot off CD. Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff -Maxim From sobomax at sippysoft.com Mon Dec 8 14:51:15 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon Dec 8 15:04:49 2008 Subject: Enhancing cdboot [patch for review] Message-ID: <493DA258.7010001@sippysoft.com> Hi, Below please find patch that enhances cdboot with two compile-time options: 1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce any messages except "Loading, please wait..." and it also passes RBX_MUTE flag to the next stage to silence it as well. This is intended for custom installations where end-user is not required to see any messages or interfere with the boot process. 2. CDBOOT_PROMPT. When this option is enabled the cdboot behaves like windows xp or vista cd loader, that is it reads MBR from the first hard drive in the system and if the MBR is bootable (i.e. drive has some other operating system installed on it) then it presents user with "Press any key to boot from CD" prompt and waits 20 seconds. If key is not pressed then the control is passed to the MBR, otherwise CD is booted. This is intended for installation CD to allow unattended mode and also helps when installation CD is unintentionally left in the drive of the machine that is set to boot off CD. Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff -Maxim From sam at freebsd.org Mon Dec 8 15:14:31 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Dec 8 15:14:50 2008 Subject: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample In-Reply-To: <1228739237.1860.21.camel@localhost> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> Message-ID: <493DA15D.7080109@freebsd.org> Vladimir Grebenschikov wrote: > * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: > >> Author: sam >> Date: Sun Nov 30 19:06:35 2008 >> New Revision: 185482 >> URL: http://svn.freebsd.org/changeset/base/185482 >> >> Log: >> Major overhaul: >> o eliminate private state indexed by 802.11 rate codes; use the hal's >> rate tables directly to get the same info >> o calculate a mask of operational rates to optimize lookups and checks >> (instead of using for loops and similar) >> o optimize size bin operations >> o ignore rates marked as "do not use" in the hal phy tables >> o fix bug that caused upshifting to break in 11g once the rate dropped >> below 11Mb/s >> o add more intelligent multi-rate tx schedules >> o add support for 1/2 and 1/4 width channels >> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console >> (needs to go up to a user app) >> o export more tuning knobs via sysctls (still a couple of magic constants) >> > > Looks like, after that commit, I can't use if_ath loaded as module any > more: > > # kldload /boot/kernel/ath_rate.ko > kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory > # dmesg | tail -n1 > link_elf: symbol ath_hal_computetxtime undefined > # > > Yes, I've read UPDATING entry 20081130. > But I have no ath_hal entry in my kernel config, > I've loaded ath as KLDs. > > How to fix that problem ? > > > Try the attached change. Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: sample.diff Type: text/x-patch Size: 351 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081208/1aa62b14/sample-0001.bin From sam at freebsd.org Mon Dec 8 15:14:32 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Dec 8 15:14:50 2008 Subject: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample In-Reply-To: <493D1436.3030606@quis.cx> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> <493D1436.3030606@quis.cx> Message-ID: <493DA171.5050402@freebsd.org> Jille Timmermans wrote: > Vladimir Grebenschikov wrote: >> * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: >> >>> Author: sam >>> Date: Sun Nov 30 19:06:35 2008 >>> New Revision: 185482 >>> URL: http://svn.freebsd.org/changeset/base/185482 >>> >>> Log: >>> Major overhaul: >>> o eliminate private state indexed by 802.11 rate codes; use the hal's >>> rate tables directly to get the same info >>> o calculate a mask of operational rates to optimize lookups and >>> checks >>> (instead of using for loops and similar) >>> o optimize size bin operations >>> o ignore rates marked as "do not use" in the hal phy tables >>> o fix bug that caused upshifting to break in 11g once the rate >>> dropped >>> below 11Mb/s >>> o add more intelligent multi-rate tx schedules >>> o add support for 1/2 and 1/4 width channels >>> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to >>> the console >>> (needs to go up to a user app) >>> o export more tuning knobs via sysctls (still a couple of magic >>> constants) >>> >> >> Looks like, after that commit, I can't use if_ath loaded as module any >> more: >> >> # kldload /boot/kernel/ath_rate.ko >> kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory >> # dmesg | tail -n1 link_elf: symbol ath_hal_computetxtime undefined >> # >> >> Yes, I've read UPDATING entry 20081130. >> But I have no ath_hal entry in my kernel config, I've loaded ath as >> KLDs. >> >> How to fix that problem ? >> > I have the same problem if I load it with kernel modules. > If I compile it into my kernel (with ath, ath_hal and that option > (can't remember it for now)) my system paniced during boot. > I can't get a coredump, but I will try getting a stacktrace with ddb > tonight. > > My Atheros (2413 iirc) wasn't usable before the import (did some > printf's during boot, but I couldn't get ath0 showing up in ifconfig) > I am willing to help debugging if needed. Where is the PR? Sam From sam at freebsd.org Mon Dec 8 15:14:32 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Dec 8 15:14:51 2008 Subject: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample In-Reply-To: <1228740002.1860.26.camel@localhost> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> <493D1436.3030606@quis.cx> <1228740002.1860.26.camel@localhost> Message-ID: <493DA27A.2070100@freebsd.org> ath's rate control module is bound using symbols so only one of these modules can ever be used at a time. A module dependency is used to auto-load the rate control module hence the fixed name. At the time this code was written it was felt the overhead to use indirect function calls and the like was too significant. Now folks may not care in which case you could use some sort of registration-style mechanism to allow runtime selection of the rate control algorithm. Fee free to supply patches. OTOH sample is so vastly superior to the other 2 algorithms that I almost removed the others recently. Sam Vladimir Grebenschikov wrote: > On Mon, 2008-12-08 at 13:33 +0100, Jille Timmermans wrote: > > after > cd /sys/modules/ath_rate_amrr > make all > make install > kldload /boot/kernel/ath_rate .ko > > It works now, but why three directories in sys/modules tree make > same .ko object: > > # fgrep ath /sys/modules/Makefile > ath \ > ath_rate_amrr \ > ath_rate_onoe \ > ath_rate_sample \ > # fgrep KMOD /sys/modules/ath_rate*/Makefile > /sys/modules/ath_rate_amrr/Makefile:KMOD= ath_rate > /sys/modules/ath_rate_onoe/Makefile:KMOD= ath_rate > /sys/modules/ath_rate_sample/Makefile:KMOD= ath_rate > # > > Looks like one overwrites another. What is right behaviour ? > > >> Vladimir Grebenschikov wrote: >> >>> * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: >>> >>> >>>> Author: sam >>>> Date: Sun Nov 30 19:06:35 2008 >>>> New Revision: 185482 >>>> URL: http://svn.freebsd.org/changeset/base/185482 >>>> >>>> Log: >>>> Major overhaul: >>>> o eliminate private state indexed by 802.11 rate codes; use the hal's >>>> rate tables directly to get the same info >>>> o calculate a mask of operational rates to optimize lookups and checks >>>> (instead of using for loops and similar) >>>> o optimize size bin operations >>>> o ignore rates marked as "do not use" in the hal phy tables >>>> o fix bug that caused upshifting to break in 11g once the rate dropped >>>> below 11Mb/s >>>> o add more intelligent multi-rate tx schedules >>>> o add support for 1/2 and 1/4 width channels >>>> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console >>>> (needs to go up to a user app) >>>> o export more tuning knobs via sysctls (still a couple of magic constants) >>>> >>>> >>> Looks like, after that commit, I can't use if_ath loaded as module any >>> more: >>> >>> # kldload /boot/kernel/ath_rate.ko >>> kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory >>> # dmesg | tail -n1 >>> link_elf: symbol ath_hal_computetxtime undefined >>> # >>> >>> Yes, I've read UPDATING entry 20081130. >>> But I have no ath_hal entry in my kernel config, >>> I've loaded ath as KLDs. >>> >>> How to fix that problem ? >>> >>> >> I have the same problem if I load it with kernel modules. >> If I compile it into my kernel (with ath, ath_hal and that option (can't >> remember it for now)) my system paniced during boot. >> I can't get a coredump, but I will try getting a stacktrace with ddb >> tonight. >> >> My Atheros (2413 iirc) wasn't usable before the import (did some >> printf's during boot, but I couldn't get ath0 showing up in ifconfig) >> I am willing to help debugging if needed. >> >> -- Jille >> From rizzo at iet.unipi.it Mon Dec 8 15:46:20 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Dec 8 15:46:27 2008 Subject: Enhancing cdboot [patch for review] In-Reply-To: <493DA269.2070805@FreeBSD.org> References: <493DA269.2070805@FreeBSD.org> Message-ID: <20081208235119.GA46608@onelab2.iet.unipi.it> On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: > Hi, > > Below please find patch that enhances cdboot with two compile-time options: ... > Any comments/suggestions are appreciated. If there are no objections I > would like to commit the change. The long-term goal is to make > CDBOOT_PROMPT default mode for installation CD. > > http://sobomax.sippysoft.com/~sobomax/cdboot.diff Looks good. Some comments: 1. since there is plenty of space in the cdboot sector, why don't you make the two option always compiled in, controlling which one to activate through flags in the bootsector itself, to be set patching the binary sector itself using a mechanism similar to boot0cfg. Of course you cannot alter a cdrom after you burn it, but it makes it easier to build CDs with one or the other defaults, patching cdboot or the iso image itself before creating/burning it. 2. in fact, the 'silent' option could be disabled at runtime by pressing some key (e.g. adding a short wait loop before proceeding; if this is meant for custom, unattended CDs the extra delay should not matter much); 3. one nitpick -- in one of the first chunks you replace $start with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, so why don't you always use the same ? Also in terms of relocation size, wouldn't it be the case of hardwiring the size of the cd boot sector: - mov $((end_init - start)/2),%cx + mov 1024,%cx 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S cheers luigi From bahamasfranks at gmail.com Mon Dec 8 15:54:02 2008 From: bahamasfranks at gmail.com (Steve Franks) Date: Mon Dec 8 16:11:08 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <1228766037.27498.6.camel@buffy.york.ac.uk> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <1228766037.27498.6.camel@buffy.york.ac.uk> Message-ID: <539c60b90812081554u228dfc0eud2f03796a2208a32@mail.gmail.com> > Firstly: The output of "pciconf -lcv" relating to the device in > question would be essential. [steve@dynstant ~/projects]$ sudo pciconf -lcv none1@pci0:2:0:0: class=0x020000 card=0x28001565 chip=0x20481969 rev=0xa0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'L2 Fast Ethernet 10/100 Base-T Controller' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[48] = MSI supports 1 message, 64 bit cap 10[58] = PCI-Express 1 endpoint Well, it seems someone is not telling the truth here! pciconf reports L2, whereas the manufacturer said L1E. Guess I got rev'd on. Thanks anyways, y'all. Steve From pyunyh at gmail.com Mon Dec 8 16:17:57 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Dec 8 16:18:04 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <539c60b90812081554u228dfc0eud2f03796a2208a32@mail.gmail.com> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <1228766037.27498.6.camel@buffy.york.ac.uk> <539c60b90812081554u228dfc0eud2f03796a2208a32@mail.gmail.com> Message-ID: <20081209001749.GA33723@cdnetworks.co.kr> On Mon, Dec 08, 2008 at 04:54:01PM -0700, Steve Franks wrote: > > Firstly: The output of "pciconf -lcv" relating to the device in > > question would be essential. > > [steve@dynstant ~/projects]$ sudo pciconf -lcv > none1@pci0:2:0:0: class=0x020000 card=0x28001565 chip=0x20481969 > rev=0xa0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > device = 'L2 Fast Ethernet 10/100 Base-T Controller' > class = network > subclass = ethernet > cap 01[40] = powerspec 2 supports D0 D3 current D0 > cap 05[48] = MSI supports 1 message, 64 bit > cap 10[58] = PCI-Express 1 endpoint > > Well, it seems someone is not telling the truth here! pciconf Yeah, you should use ae(4) for this controller. > reports L2, whereas the manufacturer said L1E. Guess I got rev'd on. > > Thanks anyways, y'all. > > Steve -- Regards, Pyun YongHyeon From sobomax at FreeBSD.org Mon Dec 8 16:29:32 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Dec 8 16:29:46 2008 Subject: Enhancing cdboot [patch for review] In-Reply-To: <20081208235119.GA46608@onelab2.iet.unipi.it> References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> Message-ID: <493DBBD0.5080705@FreeBSD.org> Luigi Rizzo wrote: > On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: >> Hi, >> >> Below please find patch that enhances cdboot with two compile-time options: > ... >> Any comments/suggestions are appreciated. If there are no objections I >> would like to commit the change. The long-term goal is to make >> CDBOOT_PROMPT default mode for installation CD. >> >> http://sobomax.sippysoft.com/~sobomax/cdboot.diff > > Looks good. Some comments: Thank you for the review and comments. Please see my answers below. > 1. since there is plenty of space in the cdboot sector, why don't you > make the two option always compiled in, controlling which one to > activate through flags in the bootsector itself, to be set > patching the binary sector itself using a mechanism similar to > boot0cfg. > Of course you cannot alter a cdrom after you burn it, > but it makes it easier to build CDs with one or the other defaults, > patching cdboot or the iso image itself before creating/burning it. > > 2. in fact, the 'silent' option could be disabled at runtime by > pressing some key (e.g. adding a short wait loop before proceeding; > if this is meant for custom, unattended CDs the extra delay should not > matter much); Good idea, I will see if I can put that in. In fact this behavior should have to be optional as well, since one of the uses for the "silent" option here is to provide tamper-resistant boot process on custom hardware. > 3. one nitpick -- in one of the first chunks you replace $start > with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, > so why don't you always use the same ? No, they are not the same. $LOAD is address where BIOS loads boot sector, which is 0x7c00 by default (you can configure it when building CD-ROM, which is why it's an option). On the other hand, $start is address where code is compiled to be located, which is 0x0600. > Also in terms of relocation size, wouldn't it be the case of > hardwiring the size of the cd boot sector: > > - mov $((end_init - start)/2),%cx > + mov 1024,%cx Well, I don't see the reason to hardwire this. CDROM boot code can be of different size (within certain limits of course, to be selected when building ISO), it's not limited to fixed number of sectors like boot[012]. > 4. another nitpick -- the value you pass in %si to the MBR does not > seem to point to anything useful. As discussed about boot0.S and > the followup in the mailing lists, there seems to be no standard > but at least some MBR expect %si to point to a partition entry, > so you should probably initialize one in a way similar way to that > used by boot0.S Hmm, maybe I misunderstood it then. What do you mean by "point to partition entry exactly"? Right now it points to the beginning on MBR. -Maxim From alexbestms at math.uni-muenster.de Mon Dec 8 16:38:25 2008 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Mon Dec 8 16:38:34 2008 Subject: ath cannot connect using WEP Message-ID: this issue got resolved in one of the recent changes to svn. cheers. From conrads at cox.net Mon Dec 8 17:10:28 2008 From: conrads at cox.net (Conrad J. Sabatier) Date: Mon Dec 8 17:10:37 2008 Subject: i give up In-Reply-To: <1228746983.27498.1.camel@buffy.york.ac.uk> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> <20081206190754.6c2bbd70@serene.no-ip.org> <1228746983.27498.1.camel@buffy.york.ac.uk> Message-ID: <20081208191031.0e0699d8@serene.no-ip.org> On Mon, 08 Dec 2008 14:36:23 +0000 Gavin Atkinson wrote: > On Sat, 2008-12-06 at 19:07 -0600, Conrad J. Sabatier wrote: > > I'm continuing to hold out hope that I can provide the missing bits > > of the puzzle that will lead to a solution. But I've already > > passed along everything I could get from Windows Vista's System > > Information tool, Linux's lspci command, and FreeBSD's pciconf and > > dmesg. I don't know what more I can provide at this point. > > You could perhaps provide it again? I've still not seen it. > > > As another poster suggested, it's possible there's a bug/typo in the > > patches Soren sent me, although they all apply quite cleanly to > > every successive version of current I've tried them on. So...I'm > > at a loss at this point. It really is frustrating. > > > > I'm no fan of either Windows or Linux, but at least they do > > recognize my hardware. So I'm stuck for the time being. > > > > If anyone's interested, I'll repost or mail directly to them all the > > pertinent info I can gather. Just say the word and it shall be > > done. > > Please. > > Gavin Thank you for your interest. I'm currently running under Linux (Ubuntu) as I write this, so I've attached the output of Linux's dmesg as well as "lspci" using various options. I'll post later (I'm going out to a meeting shortly) from FreeBSD and provide the output from dmesg and pciconf (and anything else you may suggest). I no longer have Windows Vista installed at all, so I can't offer anything from that (not that it would probably be terribly useful anyway). :-) It's PCI device 00:9.0 that seems to be causing all the trouble, if that's anything of a timesaver for you. Thanks again very much. It really would be so great to find a resolution to this problem so I can go back to enjoying the full use of my machine under FreeBSD. -- Conrad J. Sabatier -------------- next part -------------- A non-text attachment was scrubbed... Name: linux.dmesg Type: application/octet-stream Size: 58135 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081209/f46b67a3/linux-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: linux.lspci.vmm Type: application/octet-stream Size: 3979 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081209/f46b67a3/linux.lspci-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: linux.lspci.vvxxx Type: application/octet-stream Size: 48351 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081209/f46b67a3/linux.lspci-0003.obj From keramida at ceid.upatras.gr Mon Dec 8 17:29:41 2008 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Mon Dec 8 17:29:54 2008 Subject: Enhancing cdboot [patch for review] In-Reply-To: <493DBBD0.5080705@FreeBSD.org> (Maxim Sobolev's message of "Mon, 08 Dec 2008 16:29:04 -0800") References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> <493DBBD0.5080705@FreeBSD.org> Message-ID: <87oczmjfuv.fsf@kobe.laptop> On Mon, 08 Dec 2008 16:29:04 -0800, Maxim Sobolev wrote: > Luigi Rizzo wrote: >> On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: >>> Hi, >>> Below please find patch that enhances cdboot with two compile-time options: >> ... >>> Any comments/suggestions are appreciated. If there are no objections I >>> would like to commit the change. The long-term goal is to make >>> CDBOOT_PROMPT default mode for installation CD. >>> >>> http://sobomax.sippysoft.com/~sobomax/cdboot.diff >> >> Looks good. Some comments: > > Thank you for the review and comments. Please see my answers below. > >> 1. since there is plenty of space in the cdboot sector, why don't you >> make the two option always compiled in, controlling which one to >> activate through flags in the bootsector itself, to be set >> patching the binary sector itself using a mechanism similar to >> boot0cfg. >> Of course you cannot alter a cdrom after you burn it, >> but it makes it easier to build CDs with one or the other defaults, >> patching cdboot or the iso image itself before creating/burning it. >> >> 2. in fact, the 'silent' option could be disabled at runtime by >> pressing some key (e.g. adding a short wait loop before proceeding; >> if this is meant for custom, unattended CDs the extra delay should not >> matter much); > > Good idea, I will see if I can put that in. In fact this behavior should > have to be optional as well, since one of the uses for the "silent" > option here is to provide tamper-resistant boot process on custom > hardware. Nice pair of features :-) If there are no pressing space constraints maybe we can build both options in by default, but still make them opt-out when necessary? With a bit of makefile glue we can make it possible to compile with an `src.conf' that includes: WITH_CDBOOT_SILENT=1 WITHOUT_CDBOOT_PROMPT=1 This way the defaults can include support for both options, but we can conditionally compile *out* the bits that are not needed for some custom installation. Something like this can define one or both of these options in CFLAGS, depending on what `src.conf' contains: # When CDBOOT_SILENT is set, the cdboot doesn't produce any messages except # "Loading, please wait..." and it also passes RBX_MUTE flag to the next # stage to silence it as well. This is intended for custom installations # where end-user is not required to see any messages or interfere with the # boot process. .if ${MK_CDBOOT_SILENT} != "no" CFLAGS+= -DCDBOOT_SILENT .endif # When CDBOOT_PROMPT is enabled the cdboot behaves like windows xp or vista # cd loader, that is it reads MBR from the first hard drive in the system # and if the MBR is bootable (i.e. drive has some other operating system # installed on it) then it presents user with "Press any key to boot from # CD" prompt and waits for 20 seconds. If key is not pressed then the # control is passed to the MBR, otherwise CD is booted. This is intended for # installation CD to allow unattended mode and also helps when installation # CD has been unintentionally left in the drive of the machine that is set # to boot off CD. .if ${MK_CDBOOT_PROMPT} != "no" CFLAGS+= -DCDBOOT_PROMPT .endif The defaults for ${MK_CDBOOT_XXX} will have to be explicitly set in `src/share/mk/bsd.own.mk', near line 281: 281 # 282 # MK_* options which default to "yes". 283 # 284 .for var in \ ... But that shouldn't be a problem, AFAICT :-) From jackie at boolome.com Mon Dec 8 17:49:07 2008 From: jackie at boolome.com (boolome) Date: Mon Dec 8 17:49:14 2008 Subject: make buildworld failed! In-Reply-To: <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> Message-ID: <1228787330.13158.0.camel@www.boolome.cn> ? 2008-12-08?? 01:55 -0800?Garrett Cooper??? > On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: > [snip] > > Looks like your source tree is incomplete. > -Garrett But have cvsup the latest source tree ! From rizzo at iet.unipi.it Mon Dec 8 19:39:57 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Dec 8 19:40:10 2008 Subject: Enhancing cdboot [patch for review] In-Reply-To: <493DBBD0.5080705@FreeBSD.org> References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> <493DBBD0.5080705@FreeBSD.org> Message-ID: <20081209034456.GA54569@onelab2.iet.unipi.it> On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote: > Luigi Rizzo wrote: ... > >4. another nitpick -- the value you pass in %si to the MBR does not > > seem to point to anything useful. As discussed about boot0.S and > > the followup in the mailing lists, there seems to be no standard > > but at least some MBR expect %si to point to a partition entry, > > so you should probably initialize one in a way similar way to that > > used by boot0.S > > Hmm, maybe I misunderstood it then. What do you mean by "point to > partition entry exactly"? Right now it points to the beginning on MBR. ok, so here is what I know. Even though there is no standard, at least ldlinux.sys and perhaps other bootloaders expect %si to point to a 16-byte record containing the partition descriptor (same structure as one of the 4 records at 0x1be in the MBR) for the partition they were loaded from. ldlinux.sys uses this info to "relocate": it knows the location of the other sectors of ldlinux.sys relative to the beginning of the partition, and uses the start-of-partition from the record at %si to compute these locations in terms of absolute disk positions. Note that in principle a MBR does not need this info -- even if it is a multi-sector boot code such as boot0ext, it may well assume to be located at offset 0. On the other hand if the code on the MBR uses %si, then you should set the entry so that at least the starting CHS and LBA info point to the first sector on disk, i.e. CHS=0,0,1 and LBA=0. In practical terms -- make %si point to a 16-byte area of memory containing all 0's except for the byte representing the sector number for the start of the partition. See the code in a recent sys/boot/i386/boot0/boot0.S which gives some details on this. cheers luigi From sam at freebsd.org Mon Dec 8 19:48:41 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Dec 8 19:48:48 2008 Subject: svn commit: r185482 - head/sys/dev/ath/ath_rate/sample In-Reply-To: <493DA15D.7080109@freebsd.org> References: <200811301906.mAUJ6Z30099035@svn.freebsd.org> <1228739237.1860.21.camel@localhost> <493DA15D.7080109@freebsd.org> Message-ID: <493DEA94.2060900@freebsd.org> Sam Leffler wrote: > Vladimir Grebenschikov wrote: >> * On Sun, 2008-11-30 at 19:06 +0000, Sam Leffler wrote: >> >>> Author: sam >>> Date: Sun Nov 30 19:06:35 2008 >>> New Revision: 185482 >>> URL: http://svn.freebsd.org/changeset/base/185482 >>> >>> Log: >>> Major overhaul: >>> o eliminate private state indexed by 802.11 rate codes; use the hal's >>> rate tables directly to get the same info >>> o calculate a mask of operational rates to optimize lookups and >>> checks >>> (instead of using for loops and similar) >>> o optimize size bin operations >>> o ignore rates marked as "do not use" in the hal phy tables >>> o fix bug that caused upshifting to break in 11g once the rate >>> dropped >>> below 11Mb/s >>> o add more intelligent multi-rate tx schedules >>> o add support for 1/2 and 1/4 width channels >>> o add dev.ath.X.sample_stats sysctl to dump runtime statistics to >>> the console >>> (needs to go up to a user app) >>> o export more tuning knobs via sysctls (still a couple of magic >>> constants) >>> >> >> Looks like, after that commit, I can't use if_ath loaded as module any >> more: >> >> # kldload /boot/kernel/ath_rate.ko >> kldload: can't load /boot/kernel/ath_rate.ko: No such file or directory >> # dmesg | tail -n1 link_elf: symbol ath_hal_computetxtime undefined >> # >> >> Yes, I've read UPDATING entry 20081130. >> But I have no ath_hal entry in my kernel config, I've loaded ath as >> KLDs. >> >> How to fix that problem ? >> >> >> > Try the attached change. > Never mind this; you'll have to build ath into the kernel until I can sort out how to fix the module(s). Sam From sobomax at FreeBSD.org Mon Dec 8 20:49:10 2008 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Dec 8 20:49:16 2008 Subject: Enhancing cdboot [patch for review] In-Reply-To: <20081209034456.GA54569@onelab2.iet.unipi.it> References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> <493DBBD0.5080705@FreeBSD.org> <20081209034456.GA54569@onelab2.iet.unipi.it> Message-ID: <493DF8A3.6070905@FreeBSD.org> Luigi Rizzo wrote: > On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote: >> Luigi Rizzo wrote: > ... >>> 4. another nitpick -- the value you pass in %si to the MBR does not >>> seem to point to anything useful. As discussed about boot0.S and >>> the followup in the mailing lists, there seems to be no standard >>> but at least some MBR expect %si to point to a partition entry, >>> so you should probably initialize one in a way similar way to that >>> used by boot0.S >> Hmm, maybe I misunderstood it then. What do you mean by "point to >> partition entry exactly"? Right now it points to the beginning on MBR. > > ok, so here is what I know. > > Even though there is no standard, at least ldlinux.sys and perhaps > other bootloaders expect %si to point to a 16-byte record containing > the partition descriptor (same structure as one of the 4 records > at 0x1be in the MBR) for the partition they were loaded from. > > ldlinux.sys uses this info to "relocate": it knows the location of the > other sectors of ldlinux.sys relative to the beginning of the partition, > and uses the start-of-partition from the record at %si to compute > these locations in terms of absolute disk positions. > > Note that in principle a MBR does not need this info -- even if it > is a multi-sector boot code such as boot0ext, it may well assume to > be located at offset 0. > > On the other hand if the code on the MBR uses %si, then you should > set the entry so that at least the starting CHS and LBA info point > to the first sector on disk, i.e. CHS=0,0,1 and LBA=0. > > In practical terms -- make %si point to a 16-byte area of memory > containing all 0's except for the byte representing the sector > number for the start of the partition. > See the code in a recent sys/boot/i386/boot0/boot0.S which gives > some details on this. I see, thank you for the explanation. It looks like it only makes sense for multi-stage boot loaders, when the stage has been loaded from some location within the disk and it needs some clue to determine where it has came from. In this case we simply emulate BIOS loading MBR, and from what I've read here MBR code should make no assumptions with regard to %si, so that I would just set it to zero. Do you think it could create any issues? -Maxim From subbsd at gmail.com Mon Dec 8 21:51:24 2008 From: subbsd at gmail.com (Ole Vole) Date: Mon Dec 8 21:51:31 2008 Subject: setfib not ready ? Message-ID: <200812090851.36669.subbsd@gmail.com> Hello maillist, i want looking for multiple route table in HEAD. So, i try setfib -F 1 route add default 127.0.0.1 setfib -F 1 netstat -rn but it return: setfib: 1: invalid FIB (max 0) (setfib -F 0 work correct- with netstat -rn print my default route table) sysctl: oid 'net.fibs' is read only for sysctl -w net.fibs=2 however in the case seting net.fibs at loader stage (loader.conf) it not change something for adding route table. Is setfib(2) not ready for testing yet ? From thompsa at FreeBSD.org Mon Dec 8 21:57:03 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Dec 8 21:57:10 2008 Subject: setfib not ready ? In-Reply-To: <200812090851.36669.subbsd@gmail.com> References: <200812090851.36669.subbsd@gmail.com> Message-ID: <20081209055656.GC44675@citylink.fud.org.nz> On Tue, Dec 09, 2008 at 08:51:36AM +0300, Ole Vole wrote: > Hello maillist, > > i want looking for multiple route table in HEAD. So, i try > > setfib -F 1 route add default 127.0.0.1 > setfib -F 1 netstat -rn > but it return: > setfib: 1: invalid FIB (max 0) > > (setfib -F 0 work correct- with netstat -rn print my default route table) > > sysctl: oid 'net.fibs' is read only for > > sysctl -w net.fibs=2 > however in the case seting net.fibs at loader stage (loader.conf) it not > change something for adding route table. > > Is setfib(2) not ready for testing yet ? You can only use loader.conf to set the numbre of fibs to a lower number than is compiled in to your kernel, use "options ROUTETABLES=2" in your kernel config instead (or more than 2 if needed). Andrew From jackie at boolome.com Mon Dec 8 23:37:51 2008 From: jackie at boolome.com (boolome) Date: Mon Dec 8 23:37:58 2008 Subject: heads up : can not buildworld go on Message-ID: <1228808252.58600.1.camel@www.boolome.cn> cvsup to latest source tree ! m -lnvpair -luutil -lutil zfs_main.o(.text+0x15a): In function `unallow_callback': : undefined reference to `zfs_perm_remove' zfs_main.o(.text+0xa59): In function `unshare_unmount_path': : undefined reference to `zfs_unshareall_bypath' zfs_main.o(.text+0x125b): In function `share_mount_one': : undefined reference to `zfs_is_shared_smb' zfs_main.o(.text+0x13ba): In function `share_mount_one': : undefined reference to `zfs_share_smb' zfs_main.o(.text+0x1404): In function `share_mount_one': : undefined reference to `zfs_shareall' zfs_main.o(.text+0x1572): In function `upgrade_set_callback': : undefined reference to `zfs_spa_version' zfs_main.o(.text+0x16d1): In function `upgrade_set_callback': : undefined reference to `zpool_stage_history' zfs_main.o(.text+0x195a): In function `get_callback': : undefined reference to `zprop_print_one_property' zfs_main.o(.text+0x1a56): In function `get_callback': : undefined reference to `zprop_print_one_property' zfs_main.o(.text+0x2725): In function `usage': : undefined reference to `zfs_deleg_permissions' zfs_main.o(.text+0x28d2): In function `usage': : undefined reference to `zprop_iter' zfs_main.o(.text+0x2a27): In function `main': : undefined reference to `zpool_set_history_str' zfs_main.o(.text+0x2a3c): In function `main': : undefined reference to `zpool_stage_history' zfs_main.o(.text+0x42ae): In function `zfs_do_rename': : undefined reference to `zfs_create_ancestors' zfs_main.o(.text+0x45b8): In function `zfs_do_list': : undefined reference to `zprop_get_list' zfs_main.o(.text+0x4616): In function `zfs_do_list': : undefined reference to `zprop_free_list' zfs_main.o(.text+0x5052): In function `zfs_do_get': : undefined reference to `zprop_get_list' zfs_main.o(.text+0x50cf): In function `zfs_do_get': : undefined reference to `zprop_free_list' zfs_main.o(.text+0x50f3): In function `zfs_do_get': : undefined reference to `zprop_free_list' zfs_main.o(.text+0x5973): In function `zfs_do_create': : undefined reference to `zpool_get_prop_int' zfs_main.o(.text+0x5a3f): In function `zfs_do_create': : undefined reference to `zfs_dataset_exists' zfs_main.o(.text+0x5a5d): In function `zfs_do_create': : undefined reference to `zfs_create_ancestors' zfs_main.o(.text+0x5ccd): In function `zfs_do_clone': : undefined reference to `zfs_dataset_exists' zfs_main.o(.text+0x5ce9): In function `zfs_do_clone': : undefined reference to `zfs_create_ancestors' zfs_main.o(.text+0x628e): In function `parse_allow_args': : undefined reference to `zfs_build_perms' zfs_main.o(.text+0x6479): In function `zfs_do_allow': : undefined reference to `zfs_perm_set' zfs_main.o(.text+0x6573): In function `zfs_do_allow': : undefined reference to `zfs_perm_get' zfs_main.o(.text+0x67fe): In function `zfs_do_allow': : undefined reference to `zfs_free_allows' zfs_main.o(.text+0x6d4c): In function `unshare_unmount': : undefined reference to `zfs_unshareall_bypath' zfs_main.o(.text+0x7332): In function `unshare_unmount': : undefined reference to `zfs_unshareall' zfs_iter.o(.text+0x17b): In function `zfs_callback': : undefined reference to `zfs_get_pool_handle' zfs_iter.o(.text+0x193): In function `zfs_callback': : undefined reference to `zpool_get_prop_int' *** Error code 1 Stop in /usr/src/cddl/sbin/zfs. *** Error code 1 Stop in /usr/src/cddl/sbin. *** Error code 1 Stop in /usr/src/cddl. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From nakaji at jp.freebsd.org Tue Dec 9 01:32:52 2008 From: nakaji at jp.freebsd.org (NAKAJI Hiroyuki) Date: Tue Dec 9 01:32:59 2008 Subject: Fatal trap 12: page fault while in kernel mode In-Reply-To: <3c1674c90812081449r7b8ef242lce478da3d2d7a968@mail.gmail.com> (Kip Macy's message of "Mon, 8 Dec 2008 14:49:50 -0800") References: <87zljb8nw6.fsf@roddy.4407.kankyo-u.ac.jp> <3a142e750812050613w4e9155bat950f03716aa58beb@mail.gmail.com> <863ah2qivi.fsf@ra333.heimat.gr.jp> <86iqpu2sjc.fsf@ra333.heimat.gr.jp> <3c1674c90812081449r7b8ef242lce478da3d2d7a968@mail.gmail.com> Message-ID: <864p1d3d8u.fsf@ra333.heimat.gr.jp> >>>>> In <3c1674c90812081449r7b8ef242lce478da3d2d7a968@mail.gmail.com> >>>>> "Kip Macy" wrote: > Recently - starting when? I noticed that panics since late November. But I forgot the day. My last update of the world was in October. Thanks. > On Mon, Dec 8, 2008 at 2:47 PM, NAKAJI Hiroyuki wrote: > >>>>>> In <863ah2qivi.fsf@ra333.heimat.gr.jp> > >>>>>> NAKAJI Hiroyuki wrote: > > > >> So, what I have to do are three: > > > >> 1. Full upgrade to the latest kernel and userland (world) > >> 2. Observe whether a panic occurs, and > >> 3. When panic, save the crash dump and get full bt with kgdb > > > >> I hope it will not reach to the step three. Thanks. > > > > Unfortunately, I faced to "db> " on my serial console. > > > > db> bt > > Tracing pid 964 tid 100131 td 0xc49876c0 > > svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_internal+ > > 0x575 > > svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_start+0x10 > > fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip = 0xc, esp = 0x33, ebp = 0 --- > > db> call doadump > > Physical memory: 1010 MB > > Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 > > Dump complete > > = 0xf > > db> bt > > Tracing pid 964 tid 100131 td 0xc49876c0 > > svc_run_internal(e6861d24,c0850793,c44f2780,e6861d38,1,...) at svc_run_internal+ > > 0x575 > > svc_thread_start(c44f2780,e6861d38,1,0,4836bd14,...) at svc_thread_start+0x10 > > fork_exit(c0a57fe0,c44f2780,e6861d38) at fork_exit+0x93 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip = 0xc, esp = 0x33, ebp = 0 --- > > db> reset > > > > And then, I used kgdb. > > > > # kgdb /boot/kernel/kernel.symbols vmcore.9 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i386-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x0 > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc0a57a75 > > stack pointer = 0x28:0xe6861c44 > > frame pointer = 0x28:0xe6861cec > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 964 (nfsd: service) > > Physical memory: 1010 MB > > Dumping 250 MB: 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 > > > > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/linprocfs.ko > > Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/linux.ko > > Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/smbus.ko > > Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/aio.ko > > Reading symbols from /boot/kernel/mga.ko...Reading symbols from /boot/kernel/mga.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/mga.ko > > Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/drm.ko > > Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/atapicam.ko > > Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/nullfs.ko > > Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from /boot/kernel/logo_saver.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/logo_saver.ko > > #0 doadump () at pcpu.h:246 > > 246 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) bt > > #0 doadump () at pcpu.h:246 > > #1 0xc04c2a69 in db_fncall (dummy1=-1059812576, dummy2=0, dummy3=-1067505768, > > dummy4=0xe68619d8 "?:i?\2008'?") at /usr/src/sys/ddb/db_command.c:548 > > #2 0xc04c2e61 in db_command (last_cmdp=0xc0d3e85c, cmd_table=0x0, dopager=1) > > at /usr/src/sys/ddb/db_command.c:445 > > #3 0xc04c2fba in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > > #4 0xc04c4dfd in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 > > #5 0xc08a2456 in kdb_trap (type=12, code=0, tf=0xe6861c04) > > at /usr/src/sys/kern/subr_kdb.c:534 > > #6 0xc0b8059f in trap_fatal (frame=0xe6861c04, eva=0) > > at /usr/src/sys/i386/i386/trap.c:920 > > #7 0xc0b80860 in trap_pfault (frame=0xe6861c04, usermode=0, eva=0) > > at /usr/src/sys/i386/i386/trap.c:842 > > #8 0xc0b8126a in trap (frame=0xe6861c04) at /usr/src/sys/i386/i386/trap.c:522 > > #9 0xc0b652cb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > > #10 0xc0a57a75 in svc_run_internal (pool=0xc44f2780, ismaster=0) > > at /usr/src/sys/rpc/svc.c:787 > > #11 0xc0a57ff0 in svc_thread_start (arg=0xc44f2780) > > at /usr/src/sys/rpc/svc.c:1188 > > #12 0xc0850793 in fork_exit (callout=0xc0a57fe0 , > > arg=0xc44f2780, frame=0xe6861d38) at /usr/src/sys/kern/kern_fork.c:821 > > #13 0xc0b65340 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 > > (kgdb) > > > > In addition, > > > > # addr2line -e /boot/kernel/kernel.symbols 0xc0a57a75 > > /usr/src/sys/rpc/svc.c:787 > > > > Any help is appreciated. Thanks. > > -- > > NAKAJI Hiroyuki > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > -- > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis -- NAKAJI Hiroyuki From mattik at bigpond.net.au Tue Dec 9 02:59:53 2008 From: mattik at bigpond.net.au (matti k) Date: Tue Dec 9 03:00:01 2008 Subject: em(4) not sending/receiving data in recent current ? In-Reply-To: <20081207223009.GA27635@macbook.catpipe.net> References: <20081207223009.GA27635@macbook.catpipe.net> Message-ID: On 08/12/2008, at 9:30 AM, Phil Regnauld wrote: > Hi all, > > I recently upgraded a system (Dell Vostro desktop) running > 8.0-CURRENT/amd64 from July to -current from a few days ago, > and em(4) stopped working. > > By this I mean: > > - em0 probes and attaches correctly > - link is detected > - sending any data to/from the host simply fails I have this same issue with fxp(4) on i386, last updated 2 days ago. I noticed a missing include was restored to sys/dev/e1000/if_em.c and presume that has fixed em(4)? Doesn't help with fxp(4) though ... I tried. Would appreciate any help getting networking going again. Cheers, Matti From yanefbsd at gmail.com Tue Dec 9 04:47:25 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Tue Dec 9 04:47:32 2008 Subject: make buildworld failed! In-Reply-To: <1228787330.13158.0.camel@www.boolome.cn> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> Message-ID: <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> On Dec 8, 2008, at 5:48 PM, boolome wrote: > ? 2008-12-08?? 01:55 -0800?Garrett Cooper??? >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: >> [snip] >> >> Looks like your source tree is incomplete. >> -Garrett > > But have cvsup the latest source tree ! It's not necessarily your fault though. What cvsup server are you using and did you interrupt it during an update? -Garrett From elias at artx.ru Tue Dec 9 06:36:36 2008 From: elias at artx.ru (Ilya Orehov) Date: Tue Dec 9 06:36:43 2008 Subject: "interrupt storm..."; seems associated with an0 NIC In-Reply-To: <20081205.120056.255409238.imp@bsdimp.com> References: <20081205174838.GA22652@albert.catwhisker.org> <20081205.120056.255409238.imp@bsdimp.com> Message-ID: <20081209141908.GA15845@artx.ru> +------- M. Warner Losh, 2008-12-05 ------- | Thanks. Grump. Will have to back out and try again. Hello! I see storm too, but with 32-bit cards. Thinkpad 600X, two cardbus cards: xl0 and ath0. Since pccbb.c 1.176 and pccbb_pci.c 1.30 after rebooting with card(s) inserted or inserting any card I see "interrupt storm...throttling..." messages about 1 per second. Laptop remains usable, cards working. Storm don't stop even if I eject all cards. During storm, vmstat -i shows rate ~500 on cbb. No messages appeared if laptop rebooted without cards (until any card inserted). Later revisions ( pccbb.c 1.178 and pccbb_pci.c 1.31) didn't bring any visible changes. But this hack helped. No storm detected, vmstat -i shows rate 0 or 1 on cbb. diff -up xxx/pccbb_pci.c ./pccbb_pci.c --- xxx/pccbb_pci.c 2008-12-06 11:56:00.000000000 +0300 +++ ./pccbb_pci.c 2008-12-09 14:08:03.000000000 +0300 @@ -689,6 +689,7 @@ cbb_pci_filt(void *arg) struct cbb_softc *sc = arg; uint32_t sockevent; int retval = FILTER_STRAY; + int ack = 0; /* * Read the socket event. Sometimes, the theory goes, the PCI @@ -722,6 +723,7 @@ cbb_pci_filt(void *arg) sc->cardok = 0; cbb_disable_func_intr(sc); wakeup(&sc->intrhand); + ack = 1; } /* * If we get a power interrupt, wakeup anybody that might @@ -732,7 +734,10 @@ cbb_pci_filt(void *arg) cbb_set(sc, CBB_SOCKET_EVENT, CBB_SOCKET_EVENT_POWER); sc->powerintr++; wakeup((void *)&sc->powerintr); + ack = 1; } + if (!ack) + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); retval = FILTER_HANDLED; } /* Do you need dmesg or some other info? regards, Ilya. | | Warner | _______________________________________________ | freebsd-current@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-current | To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" | +----------------------------- From mike at sentex.net Tue Dec 9 06:57:24 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 9 06:57:33 2008 Subject: uart vs sio differences ? In-Reply-To: <7.1.0.9.0.20081208173515.13f62e88@sentex.net> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> Message-ID: <200812091457.mB9EvLSD047534@lava.sentex.ca> At 05:39 PM 12/8/2008, Mike Tancsa wrote: >What it appears to be is that as long as data is coming in, even at >1200bps, the ioctl FIONREAD returns zero and an actual read does not >return any data until there is either a pause in the data coming in >or possibly when we do a xmit/write at which point the accumulated >data is available for us to read. > >We dont know if this is due to the hardware fifo or something in the >driver itself. OK, I think we found the issue! http://www.freebsd.org/cgi/query-pr.cgi?pr=121421 Not sure if the semantics are exactly right, but adding hint.uart.0.flags="0x100" hint.uart.1.flags="0x100" hint.uart.2.flags="0x100" hint.uart.3.flags="0x100" to device.hints fixed the issue! The next question-- is there a way to do this with the ucom driver as well ? We are seeing the same issue with it. ---Mike From imp at bsdimp.com Tue Dec 9 08:30:42 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Dec 9 08:31:04 2008 Subject: "interrupt storm..."; seems associated with an0 NIC In-Reply-To: <20081209141908.GA15845@artx.ru> References: <20081205174838.GA22652@albert.catwhisker.org> <20081205.120056.255409238.imp@bsdimp.com> <20081209141908.GA15845@artx.ru> Message-ID: <20081209.092739.35219831.imp@bsdimp.com> In message: <20081209141908.GA15845@artx.ru> Ilya Orehov writes: : +------- M. Warner Losh, 2008-12-05 ------- : | Thanks. Grump. Will have to back out and try again. : : Hello! : : I see storm too, but with 32-bit cards. : : Thinkpad 600X, two cardbus cards: xl0 and ath0. : : Since pccbb.c 1.176 and pccbb_pci.c 1.30 : after rebooting with card(s) inserted or inserting any card : I see "interrupt storm...throttling..." messages about 1 per second. : Laptop remains usable, cards working. : Storm don't stop even if I eject all cards. : During storm, vmstat -i shows rate ~500 on cbb. : No messages appeared if laptop rebooted without cards : (until any card inserted). : : Later revisions ( pccbb.c 1.178 and pccbb_pci.c 1.31) : didn't bring any visible changes. : : But this hack helped. : No storm detected, vmstat -i shows rate 0 or 1 on cbb. : : diff -up xxx/pccbb_pci.c ./pccbb_pci.c : --- xxx/pccbb_pci.c 2008-12-06 11:56:00.000000000 +0300 : +++ ./pccbb_pci.c 2008-12-09 14:08:03.000000000 +0300 : @@ -689,6 +689,7 @@ cbb_pci_filt(void *arg) : struct cbb_softc *sc = arg; : uint32_t sockevent; : int retval = FILTER_STRAY; : + int ack = 0; : : /* : * Read the socket event. Sometimes, the theory goes, the PCI : @@ -722,6 +723,7 @@ cbb_pci_filt(void *arg) : sc->cardok = 0; : cbb_disable_func_intr(sc); : wakeup(&sc->intrhand); : + ack = 1; : } : /* : * If we get a power interrupt, wakeup anybody that might : @@ -732,7 +734,10 @@ cbb_pci_filt(void *arg) : cbb_set(sc, CBB_SOCKET_EVENT, CBB_SOCKET_EVENT_POWER); : sc->powerintr++; : wakeup((void *)&sc->powerintr); : + ack = 1; : } : + if (!ack) : + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); : retval = FILTER_HANDLED; : } : /* : : Do you need dmesg or some other info? Can you please do the following: + if (!ack) { + printf("Need to ack %#x\n", sockevent); + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); + } And let me know what it says? Warner From ler at lerctr.org Tue Dec 9 08:37:03 2008 From: ler at lerctr.org (Larry Rosenman) Date: Tue Dec 9 08:37:10 2008 Subject: Why does host and dig show a ; as \;? Message-ID: <004901c95a1c$5c6b2680$15417380$@org> Why does the host command, dig, and a named_db.dump all show a ; as \; in a TXT record? This confuses folks like me that are trying to verify DK and DKIM TXT records. Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From mike at sentex.net Tue Dec 9 08:56:56 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 9 08:57:03 2008 Subject: uart vs sio differences ? In-Reply-To: <200812091457.mB9EvLSD047534@lava.sentex.ca> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> Message-ID: <200812091656.mB9Gusd7048089@lava.sentex.ca> At 09:57 AM 12/9/2008, Mike Tancsa wrote: >The next question-- is there a way to do this with the ucom driver >as well ? We are seeing the same issue with it. Not sure if its the "best" way to do it, but http://lists.freebsd.org/pipermail/freebsd-usb/2008-December/005817.html seems to fix it for our app. ---Mike From scottl at samsco.org Tue Dec 9 09:42:02 2008 From: scottl at samsco.org (Scott Long) Date: Tue Dec 9 09:42:08 2008 Subject: uart vs sio differences ? In-Reply-To: <493EA759.4000504@samsco.org> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> Message-ID: <493EADE6.60508@samsco.org> Scott Long wrote: > Mike Tancsa wrote: >> At 05:39 PM 12/8/2008, Mike Tancsa wrote: >> >>> What it appears to be is that as long as data is coming in, even at >>> 1200bps, the ioctl FIONREAD returns zero and an actual read does not >>> return any data until there is either a pause in the data coming in >>> or possibly when we do a xmit/write at which point the accumulated >>> data is available for us to read. >>> >>> We dont know if this is due to the hardware fifo or something in the >>> driver itself. >> >> OK, I think we found the issue! >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=121421 >> >> Not sure if the semantics are exactly right, but adding >> >> hint.uart.0.flags="0x100" >> hint.uart.1.flags="0x100" >> hint.uart.2.flags="0x100" >> hint.uart.3.flags="0x100" >> >> to device.hints fixed the issue! >> >> The next question-- is there a way to do this with the ucom driver as >> well ? We are seeing the same issue with it. >> >> ---Mike > > It's pretty sad that the uart driver can't keep up with the 16550 at > full FIFO depth, though I can see exactly why. Even though the driver > will normally use a fast interrupt handler, that handler does nothing > but schedule the sio swi thread. Well, I shouldn't say that that's the > only thing it does; it also does a spinwait on a home-rolled semaphore > with the swi thread, something that I'm not sure I understand. Maybe > the author thought that there was a risk of missed wakeups of the swi? > > That aside, I think what needs to happen is for the driver to use the > interrupt handler to pull the bytes out of the hardware and into an > internal lockless ring buffer, then schedule the swi to process the ring > buffer. I'll see if I can come up with some code for this today. Not > sure if the same can be done for ucom since the USB stack below it > presents a lot more complications and overhead. > > Scott > Bah, that's what I get for reading code before I'm awake. The uart driver does do exactly what I suggest it should. It has a 384 byte ring buffer, which should be more than enough. So I wonder if the spin-wait on the swi semaphore is what is killing it, though. Scott From scottl at samsco.org Tue Dec 9 09:50:09 2008 From: scottl at samsco.org (Scott Long) Date: Tue Dec 9 09:50:17 2008 Subject: uart vs sio differences ? In-Reply-To: <200812091457.mB9EvLSD047534@lava.sentex.ca> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> Message-ID: <493EA759.4000504@samsco.org> Mike Tancsa wrote: > At 05:39 PM 12/8/2008, Mike Tancsa wrote: > >> What it appears to be is that as long as data is coming in, even at >> 1200bps, the ioctl FIONREAD returns zero and an actual read does not >> return any data until there is either a pause in the data coming in or >> possibly when we do a xmit/write at which point the accumulated data >> is available for us to read. >> >> We dont know if this is due to the hardware fifo or something in the >> driver itself. > > OK, I think we found the issue! > > http://www.freebsd.org/cgi/query-pr.cgi?pr=121421 > > Not sure if the semantics are exactly right, but adding > > hint.uart.0.flags="0x100" > hint.uart.1.flags="0x100" > hint.uart.2.flags="0x100" > hint.uart.3.flags="0x100" > > to device.hints fixed the issue! > > The next question-- is there a way to do this with the ucom driver as > well ? We are seeing the same issue with it. > > ---Mike It's pretty sad that the uart driver can't keep up with the 16550 at full FIFO depth, though I can see exactly why. Even though the driver will normally use a fast interrupt handler, that handler does nothing but schedule the sio swi thread. Well, I shouldn't say that that's the only thing it does; it also does a spinwait on a home-rolled semaphore with the swi thread, something that I'm not sure I understand. Maybe the author thought that there was a risk of missed wakeups of the swi? That aside, I think what needs to happen is for the driver to use the interrupt handler to pull the bytes out of the hardware and into an internal lockless ring buffer, then schedule the swi to process the ring buffer. I'll see if I can come up with some code for this today. Not sure if the same can be done for ucom since the USB stack below it presents a lot more complications and overhead. Scott From xcllnt at mac.com Tue Dec 9 10:13:32 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Dec 9 10:13:43 2008 Subject: uart vs sio differences ? In-Reply-To: <493EA759.4000504@samsco.org> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> Message-ID: <0E8F5AD4-A139-413E-A760-A1BEDDF44BAA@mac.com> On Dec 9, 2008, at 9:14 AM, Scott Long wrote: > That aside, I think what needs to happen is for the driver to use the > interrupt handler to pull the bytes out of the hardware and into an > internal lockless ring buffer, then schedule the swi to process the > ring > buffer. The uart(4) driver is exactly doing what you describe. -- Marcel Moolenaar xcllnt@mac.com From david at catwhisker.org Tue Dec 9 11:14:31 2008 From: david at catwhisker.org (David Wolfskill) Date: Tue Dec 9 11:14:39 2008 Subject: NFS (& amd?) dysfunction descending a hierarchy In-Reply-To: <20081203001538.GC96383@bunrab.catwhisker.org> References: <20081203001538.GC96383@bunrab.catwhisker.org> Message-ID: <20081209190110.GW60731@albert.catwhisker.org> On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote: > I seem to have a fairly- (though not deterministly so) reproducible > mode of failure with an NFS-mounted directory hierarchy: An attempt to > traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm > -fr") will fail to "visit" some subdirectories, typically apparently > acting as if the subdirectories in question do not actually exist > (despite the names having been returned in the output of a previous > readdir()). > ... I was able to reproduce the external symptoms of the failure running CURRENT as of yesterday, using "rm -fr" of a copy of a recent /usr/ports hierachy on an NFS-mounted file system as a test case. However, I believe the mechanism may be a bit different -- while still being other than what I would expect. One aspect in which the externally-observable symptoms were different (under CURRENT, vs. RELENG_7) is that under CURRENT, once the error condition occurred, the NFS client machine was in a state where it merely kept repeating nfs server pid848@fbsd-build:/volume: not responding until I logged in as root & rebooted it. Here's a cut/paste of the kdump from the ktrace of the amd(8) process under CURRENT, showing where the master amd(8) process (pid 848) forks a child (4126) to try the unmount: 848 amd 1228846258.722953 CALL gettimeofday(0x8078e48,0) 848 amd 1228846258.722964 RET gettimeofday 0 848 amd 1228846258.722982 CALL sigprocmask(SIG_BLOCK,0xbfbfeaec,0xbfbfeadc) 848 amd 1228846258.722993 RET sigprocmask 0 848 amd 1228846258.723003 CALL fork 848 amd 1228846258.730250 RET fork 4126/0x101e 848 amd 1228846258.730405 CALL sigprocmask(SIG_SETMASK,0xbfbfeadc,0) 4126 amd 1228846258.730252 RET fork 0 4126 amd 1228846258.730456 CALL getpid 4126 amd 1228846258.730467 RET getpid 4126/0x101e 4126 amd 1228846258.730493 CALL unmount(0x2825f340,0) 848 amd 1228846258.730422 RET sigprocmask 0 848 amd 1228846258.730595 CALL gettimeofday(0x8078e48,0) 848 amd 1228846258.730608 RET gettimeofday 0 ... 848 amd 1228846258.914814 CALL sigprocmask(SIG_SETMASK,0xbfbfeba0,0) 848 amd 1228846258.914826 RET sigprocmask 0 848 amd 1228846258.914838 CALL select(0x400,0xbfbfec40,0,0,0xbfbfecd8) 4126 amd 1228846259.090428 RET unmount 0 4126 amd 1228846259.090492 CALL sigprocmask(SIG_BLOCK,0x2809b080,0xbfbfea0c) 4126 amd 1228846259.090505 RET sigprocmask 0 4126 amd 1228846259.090518 CALL sigprocmask(SIG_SETMASK,0x2809b090,0) 4126 amd 1228846259.090530 RET sigprocmask 0 4126 amd 1228846259.090545 CALL sigprocmask(SIG_BLOCK,0x2809b080,0xbfbfe9dc) 4126 amd 1228846259.090556 RET sigprocmask 0 4126 amd 1228846259.090576 CALL sigprocmask(SIG_SETMASK,0x2809b090,0) 4126 amd 1228846259.090587 RET sigprocmask 0 4126 amd 1228846259.090605 CALL exit(0) 848 amd 1228846259.091248 RET select -1 errno 4 Interrupted system call 848 amd 1228846259.091277 PSIG SIGCHLD caught handler=0x805e090 mask=0x0 code=0x0 848 amd 1228846259.091298 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG,0) 848 amd 1228846259.091329 RET wait4 4126/0x101e 848 amd 1228846259.091342 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG,0) 848 amd 1228846259.091352 RET wait4 -1 errno 10 No child processes 848 amd 1228846259.091365 CALL sigprocmask(SIG_SETMASK,0x80795bc,0) 848 amd 1228846259.091377 RET sigprocmask 0 848 amd 1228846259.091390 CALL sigprocmask(SIG_BLOCK,0x80792c4,0) 848 amd 1228846259.091401 RET sigprocmask 0 848 amd 1228846259.091411 CALL gettimeofday(0x8078e48,0) 848 amd 1228846259.091422 RET gettimeofday 0 Note that while the child didn't get EBUSY (as it does under RELENG_7) -- indeed, the unmount call appears to have returned 0 -- the master amd(8) process looks to be seeing "errno 4 Interrupted system call." And here's a relevent part of the kdump from the "rm -fr" -- I had kdump spit out Epoch timestamps with each in order to make correlation easier: 4121 rm 1228846258.736266 CALL unlink(0x2821c148) 4121 rm 1228846258.736281 NAMI "distinfo" 4121 rm 1228846258.738329 RET unlink 0 4121 rm 1228846258.738379 CALL unlink(0x2821c1b8) 4121 rm 1228846258.738401 NAMI "pkg-descr" 4121 rm 1228846258.739963 RET unlink 0 4121 rm 1228846258.739982 CALL open(0x28178b6b,O_RDONLY,0) 4121 rm 1228846258.740002 NAMI ".." 4121 rm 1228846258.740541 RET open 4 4121 rm 1228846258.740558 CALL fstat(0x4,0xbfbfe96c) 4121 rm 1228846258.740579 STRU struct stat {dev=67174155, ino=22674937, mode=drwxr-xr-x , nlink=114, uid=9874, gid=929, rdev=0, atime=1228846258.184514000, stime =1228846258.779501000, ctime=1228846258.779501000, birthtime=-1, size=12288, blksize=4096, blocks=24, flags=0x0 } 4121 rm 1228846258.740593 RET fstat 0 4121 rm 1228846258.740608 CALL fchdir(0x4) 4121 rm 1228846258.740626 RET fchdir 0 4121 rm 1228846258.740641 CALL close(0x4) 4121 rm 1228846258.740976 RET close 0 4121 rm 1228846258.740991 CALL rmdir(0x2821c538) 4121 rm 1228846258.741007 NAMI "dnscheck" 4121 rm 1228846258.741764 RET rmdir 0 4121 rm 1228846258.741783 CALL stat(0x2821d028,0xbfbfe900) 4121 rm 1228846258.741799 NAMI "dnsdoctor" 4121 rm 1228846258.742050 STRU struct stat {dev=67174155, ino=2519891, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555712, ctime=1228845836.981842000, birthtime=-1, size=4096, blksize=4096, blocks=8, flags=0x0 } 4121 rm 1228846258.742066 RET stat 0 4121 rm 1228846258.742080 CALL open(0x2821d028,O_NONBLOCK,0x28200000) 4121 rm 1228846258.742097 NAMI "dnsdoctor" 4121 rm 1228846258.742419 RET open 4 4121 rm 1228846258.742435 CALL fstat(0x4,0xbfbfe6a0) 4121 rm 1228846258.742452 STRU struct stat {dev=67174155, ino=2519891, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555712, ctime=1228845836.981842000, birthtime=-1, size=4096, blksize=4096, blocks=8, flags=0x0 } 4121 rm 1228846258.742465 RET fstat 0 4121 rm 1228846258.742480 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 4121 rm 1228846258.742495 RET fcntl 0 4121 rm 1228846258.742516 CALL fstatfs(0x4,0xbfbfe700) 4121 rm 1228846258.742792 RET fstatfs -1 errno 2 No such file or directory 4121 rm 1228846258.742809 CALL close(0x4) 4121 rm 1228846258.743187 RET close 0 4121 rm 1228846258.743203 CALL stat(0x2821d098,0xbfbfe900) 4121 rm 1228846258.743219 NAMI "dnsflood" 4121 rm 1228846258.743544 STRU struct stat {dev=67174155, ino=2519892, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555712, ctime=1228845836.978868000, birthtime=-1, size=4096, blksize=4096, blocks=8, flags=0x0 } 4121 rm 1228846258.743559 RET stat 0 4121 rm 1228846258.743574 CALL open(0x2821d098,O_NONBLOCK,0x28200000) 4121 rm 1228846258.743590 NAMI "dnsflood" 4121 rm 1228846258.743792 RET open 4 4121 rm 1228846258.743809 CALL fstat(0x4,0xbfbfe6a0) 4121 rm 1228846258.743826 STRU struct stat {dev=67174155, ino=2519892, mode=drwxr-xr-x , nlink=3, uid=9874, gid=929, rdev=0, atime=1228844788, stime=1227555712, ctime=1228845836.978868000, birthtime=-1, size=4096, blksize=4096, blocks=8, flags=0x0 } 4121 rm 1228846258.743840 RET fstat 0 4121 rm 1228846258.743854 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 4121 rm 1228846258.743867 RET fcntl 0 4121 rm 1228846258.743882 CALL fstatfs(0x4,0xbfbfe700) 4121 rm 1228846258.744008 RET fstatfs -1 errno 2 No such file or directory 4121 rm 1228846258.744022 CALL close(0x4) 4121 rm 1228846258.744411 RET close 0 [I included a moderate amount of successful processing near the beginning of that excerpt, so folks could see the pattern.] In contrast, here are the similar kdump excerpts from RELENG_7: 702 amd 1228774660.297858 CALL gettimeofday(0x807ad48,0) 702 amd 1228774660.297864 RET gettimeofday 0 702 amd 1228774660.297872 CALL sigprocmask(SIG_BLOCK,0xbfbfeaec,0xbfbfeadc) 702 amd 1228774660.297878 RET sigprocmask 0 702 amd 1228774660.297883 CALL fork 702 amd 1228774660.302658 RET fork 16840/0x41c8 16840 amd 1228774660.302660 RET fork 0 702 amd 1228774660.302689 CALL sigprocmask(SIG_SETMASK,0xbfbfeadc,0) 16840 amd 1228774660.302707 CALL getpid 16840 amd 1228774660.302725 RET getpid 16840/0x41c8 702 amd 1228774660.302715 RET sigprocmask 0 702 amd 1228774660.302746 CALL gettimeofday(0x807ad48,0) 16840 amd 1228774660.302753 CALL unmount(0x2837d310,0) 702 amd 1228774660.302753 RET gettimeofday 0 ... 702 amd 1228774660.417933 CALL select(0x400,0xbfbfec40,0,0,0xbfbfecd8) 16840 amd 1228774660.434632 RET unmount -1 errno 16 Device busy 16840 amd 1228774660.434684 CALL sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfea0c) 16840 amd 1228774660.434691 RET sigprocmask 0 16840 amd 1228774660.434699 CALL sigprocmask(SIG_SETMASK,0x28097c10,0) 16840 amd 1228774660.434705 RET sigprocmask 0 16840 amd 1228774660.434713 CALL sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfe9dc) 16840 amd 1228774660.434718 RET sigprocmask 0 16840 amd 1228774660.434729 CALL sigprocmask(SIG_SETMASK,0x28097c10,0) 16840 amd 1228774660.434734 RET sigprocmask 0 16840 amd 1228774660.434745 CALL exit(0x10) 702 amd 1228774660.435214 RET select -1 errno 4 Interrupted system call 702 amd 1228774660.435227 PSIG SIGCHLD caught handler=0x805de20 mask=0x0 code=0x0 702 amd 1228774660.435237 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG,0) 702 amd 1228774660.435255 RET wait4 16840/0x41c8 702 amd 1228774660.435296 CALL wait4(0xffffffff,0xbfbfe83c,WNOHANG,0) 702 amd 1228774660.435302 RET wait4 -1 errno 10 No child processes 702 amd 1228774660.435307 CALL sigprocmask(SIG_SETMASK,0x807ba7c,0) 702 amd 1228774660.435312 RET sigprocmask 0 702 amd 1228774660.435317 CALL sigprocmask(SIG_BLOCK,0x807b784,0) 702 amd 1228774660.435323 RET sigprocmask 0 and: 16835 rm 1228774660.305162 CALL open(0x2816280b,O_RDONLY,0) 16835 rm 1228774660.305173 NAMI ".." 16835 rm 1228774660.305626 RET open 4 16835 rm 1228774660.305634 CALL fstat(0x4,0xbfbfe93c) 16835 rm 1228774660.305644 STRU struct stat {dev=50396945, ino=29713037, mode=drwxr-xr-x , nlink=91, uid=9874, gid=929, rdev=0, atime=1228774657.877477000, stime= 1228774660.314260000, ctime=1228774660.314260000, birthtime=0, size=20480, blksize=4096, blocks=40, flags=0x0 } 16835 rm 1228774660.305651 RET fstat 0 16835 rm 1228774660.305658 CALL fchdir(0x4) 16835 rm 1228774660.305667 RET fchdir 0 16835 rm 1228774660.305674 CALL close(0x4) 16835 rm 1228774660.305824 RET close 0 16835 rm 1228774660.305831 CALL rmdir(0x2821afe8) 16835 rm 1228774660.305838 NAMI "p-interp" 16835 rm 1228774660.306498 RET rmdir 0 16835 rm 1228774660.306513 CALL stat(0x28218b48,0xbfbfe8cc) 16835 rm 1228774660.306519 NAMI "pcemu" 16835 rm 1228774660.306756 STRU struct stat {dev=50396945, ino=8465981, mode=drwxr-xr-x , nlink=5, uid=9874, gid=929, rdev=0, atime=1228772282, stime=1227555736, ctime=1228773351.399184000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 } 16835 rm 1228774660.306764 RET stat 0 16835 rm 1228774660.306770 CALL open(0x28218b48,O_NONBLOCK,0x1) 16835 rm 1228774660.306776 NAMI "pcemu" 16835 rm 1228774660.307003 RET open 4 16835 rm 1228774660.307010 CALL fstat(0x4,0xbfbfe8cc) 16835 rm 1228774660.307018 STRU struct stat {dev=50396945, ino=8465981, mode=drwxr-xr-x , nlink=5, uid=9874, gid=929, rdev=0, atime=1228772282, stime=1227555736, ctime=1228773351.399184000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 } 16835 rm 1228774660.307025 RET fstat 0 16835 rm 1228774660.307031 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 16835 rm 1228774660.307039 RET fcntl 0 16835 rm 1228774660.307049 CALL fstatfs(0x4,0xbfbfe6f4) 16835 rm 1228774660.307294 RET fstatfs -1 errno 2 No such file or directory 16835 rm 1228774660.307302 CALL close(0x4) 16835 rm 1228774660.307549 RET close 0 16835 rm 1228774660.307557 CALL stat(0x28218b98,0xbfbfe8cc) 16835 rm 1228774660.307563 NAMI "pearpc" 16835 rm 1228774660.307759 STRU struct stat {dev=50396945, ino=27094159, mode=drwxr-xr-x , nlink=4, uid=9874, gid=929, rdev=0, atime=1228772282, stime=1227555736, ctime=1228773351.390236000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 } 16835 rm 1228774660.307767 RET stat 0 16835 rm 1228774660.307772 CALL open(0x28218b98,O_NONBLOCK,0x1) 16835 rm 1228774660.307779 NAMI "pearpc" 16835 rm 1228774660.308000 RET open 4 16835 rm 1228774660.308007 CALL fstat(0x4,0xbfbfe8cc) 16835 rm 1228774660.308015 STRU struct stat {dev=50396945, ino=27094159, mode=drwxr-xr-x , nlink=4, uid=9874, gid=929, rdev=0, atime=1228772282, stime=1227555736, ctime=1228773351.390236000, birthtime=0, size=4096, blksize=4096, blocks=8, flags=0x0 } 16835 rm 1228774660.308021 RET fstat 0 16835 rm 1228774660.308026 CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 16835 rm 1228774660.308032 RET fcntl 0 16835 rm 1228774660.308038 CALL fstatfs(0x4,0xbfbfe6f4) 16835 rm 1228774660.308101 RET fstatfs -1 errno 2 No such file or directory 16835 rm 1228774660.308108 CALL close(0x4) 16835 rm 1228774660.308350 RET close 0 So either way, the user-level program attempting the directory hierarchy traversal can be coded to be very careful, yet still receive a rude surprise -- the system saying that a file that the program had already opened (and still has opened) does not exist. How rude! :-{ I'll be very happy to test suggested patches, whether intended to fix the problem or merely facilitate diagnosis. That said, it shouldn't be difficult to reproduce this -- I did it with a copy of /usr/ports; a colleague has reported doing so with a copy of /usr/src (though I haven't witnessed that). Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081209/340bd551/attachment.pgp From mike at sentex.net Tue Dec 9 11:20:36 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Dec 9 11:20:43 2008 Subject: uart vs sio differences ? In-Reply-To: <493EA759.4000504@samsco.org> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> Message-ID: <200812091920.mB9JKWD1048771@lava.sentex.ca> At 12:14 PM 12/9/2008, Scott Long wrote: buffer. I'll see if I can come up with some code for this today. Not >sure if the same can be done for ucom since the USB stack below it >presents a lot more complications and overhead. Hi Scott, It seems to work in the USB case if I reduce the receive and xmit buffers. Do you know if there are any nasty unintended side effects of doing this ? I did the follow simple hack to the driver to get our app to work. --- sys/dev/usb/uftdi.c.orig 2008-12-09 11:47:02.000000000 -0500 +++ sys/dev/usb/uftdi.c 2008-12-09 11:47:05.000000000 -0500 @@ -198,6 +198,7 @@ usb_interface_descriptor_t *id; usb_endpoint_descriptor_t *ed; int i; + unsigned int ivar; usbd_status err; struct ucom_softc *ucom = &sc->sc_ucom; DPRINTFN(10,("\nuftdi_attach: sc=%p\n", sc)); @@ -353,11 +354,27 @@ ucom->sc_portno = FTDI_PIT_SIOA; else ucom->sc_portno = FTDI_PIT_SIOA + id->bInterfaceNumber; - /* bulkin, bulkout set above */ - ucom->sc_ibufsize = UFTDIIBUFSIZE; - ucom->sc_obufsize = UFTDIOBUFSIZE - sc->sc_hdrlen; - ucom->sc_ibufsizepad = UFTDIIBUFSIZE; + /* For certain low speed / timing sensitive applications having the buffers too large causes + data to be stuck in the queue too long. By adding a tuneable, users can lower the buffer + size to what works for their application + */ + + if (!resource_int_value( + "uftdi", device_get_unit(ucom->sc_dev), "buffersize", &ivar) && (ivar > sc->sc_hdrlen && ivar <= UFTDIIBUFSIZE) ) { + ucom->sc_ibufsize = ivar; + ucom->sc_obufsize = ivar - sc->sc_hdrlen; + ucom->sc_ibufsizepad = ivar;; + device_printf(ucom->sc_dev, "Setting buffers to %d\n",ivar); + } + else + { + ucom->sc_ibufsize = UFTDIIBUFSIZE; + ucom->sc_obufsize = UFTDIOBUFSIZE - sc->sc_hdrlen; + ucom->sc_ibufsizepad = UFTDIIBUFSIZE; + device_printf(ucom->sc_dev, "Setting buffers to default of %d\n",UFTDIIBUFSIZE); + + } ucom->sc_opkthdrlen = sc->sc_hdrlen; ---Mike From elias at artx.ru Tue Dec 9 11:24:46 2008 From: elias at artx.ru (Ilya Orehov) Date: Tue Dec 9 11:24:55 2008 Subject: "interrupt storm..."; seems associated with an0 NIC In-Reply-To: <20081209.092739.35219831.imp@bsdimp.com> References: <20081205174838.GA22652@albert.catwhisker.org> <20081205.120056.255409238.imp@bsdimp.com> <20081209141908.GA15845@artx.ru> <20081209.092739.35219831.imp@bsdimp.com> Message-ID: <20081209192439.GA16703@artx.ru> +------- M. Warner Losh, 2008-12-09 ------- | In message: <20081209141908.GA15845@artx.ru> | Ilya Orehov writes: | : +------- M. Warner Losh, 2008-12-05 ------- | : | Thanks. Grump. Will have to back out and try again. | : | : Hello! | : | : I see storm too, but with 32-bit cards. | : | : Thinkpad 600X, two cardbus cards: xl0 and ath0. | : | : Since pccbb.c 1.176 and pccbb_pci.c 1.30 | : after rebooting with card(s) inserted or inserting any card | : I see "interrupt storm...throttling..." messages about 1 per second. | : Laptop remains usable, cards working. | : Storm don't stop even if I eject all cards. | : During storm, vmstat -i shows rate ~500 on cbb. | : No messages appeared if laptop rebooted without cards | : (until any card inserted). | : | : Later revisions ( pccbb.c 1.178 and pccbb_pci.c 1.31) | : didn't bring any visible changes. | : | : But this hack helped. | : No storm detected, vmstat -i shows rate 0 or 1 on cbb. | : | : diff -up xxx/pccbb_pci.c ./pccbb_pci.c | : --- xxx/pccbb_pci.c 2008-12-06 11:56:00.000000000 +0300 | : +++ ./pccbb_pci.c 2008-12-09 14:08:03.000000000 +0300 | : @@ -689,6 +689,7 @@ cbb_pci_filt(void *arg) | : struct cbb_softc *sc = arg; | : uint32_t sockevent; | : int retval = FILTER_STRAY; | : + int ack = 0; | : | : /* | : * Read the socket event. Sometimes, the theory goes, the PCI | : @@ -722,6 +723,7 @@ cbb_pci_filt(void *arg) | : sc->cardok = 0; | : cbb_disable_func_intr(sc); | : wakeup(&sc->intrhand); | : + ack = 1; | : } | : /* | : * If we get a power interrupt, wakeup anybody that might | : @@ -732,7 +734,10 @@ cbb_pci_filt(void *arg) | : cbb_set(sc, CBB_SOCKET_EVENT, CBB_SOCKET_EVENT_POWER); | : sc->powerintr++; | : wakeup((void *)&sc->powerintr); | : + ack = 1; | : } | : + if (!ack) | : + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); | : retval = FILTER_HANDLED; | : } | : /* | : | : Do you need dmesg or some other info? | | Can you please do the following: | | + if (!ack) { | + printf("Need to ack %#x\n", sockevent); | + cbb_set(sc, CBB_SOCKET_EVENT, sockevent); | + } | | And let me know what it says? Recompiled, rebooted with xl0 - message printed only once after xl0 initialization: "Need to ack 0x1" Then I ejected xl0 - no message. When the card was inserted back, same message appeared. ... ad0: 57231MB at ata0-master UDMA33 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 miibus0: on xl0 tdkphy0: PHY 0 on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [ITHREAD] Need to ack 0x1 acd0: CDROM at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s2a WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: command never completed! tdkphy0: detached miibus0: detached xl0: detached Need to ack 0x1 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 miibus0: on xl0 tdkphy0: PHY 0 on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [ITHREAD] xl0: link state changed to DOWN xl0: link state changed to UP regards, Ilya. | | Warner | +----------------------------- -------------- next part -------------- Copyright (c) 1992-2008 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 8.0-CURRENT #13: Tue Dec 9 21:34:37 MSK 2008 elias@.......ru:/usr/src/sys/i386/compile/TB Preloaded elf kernel "/boot/kernel/kernel" at 0xc09ee000. Preloaded elf module "/boot/kernel/snd_csa.ko" at 0xc09ee174. Preloaded elf module "/boot/kernel/sound.ko" at 0xc09ee220. Preloaded elf module "/boot/kernel/ng_ubt.ko" at 0xc09ee2cc. Preloaded elf module "/boot/kernel/netgraph.ko" at 0xc09ee378. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc09ee428. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 498274309 Hz CPU: Intel Pentium III (498.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff Instruction TLB: 4 KB pages, 4-way set associative, 32 entries Instruction TLB: 4 MB pages, fully associative, 2 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries 2nd-level cache: 256 KB, 8-way set associative, 32 byte line size 1st-level instruction cache: 16 KB, 4-way set associative, 32 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 16 KB, 4-way set associative, 32 byte line size real memory = 268238848 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000000fb4dfff, 250777600 bytes (61225 pages) avail memory = 253173760 (241 MB) bios32: Found BIOS32 Service Directory header at 0xc00fd800 bios32: Entry = 0xfd820 (c00fd820) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x0 pnpbios: Found PnP BIOS data at 0xc00fe700 pnpbios: Entry = f0000:e724 Rev = 1.0 pnpbios: Event flag at 415 Other BIOS signatures found: snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 ath_rate: version 1.9 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: null: random: ACPI: RSDP @ 0x0xfd6e0/0x0014 (v 0 IBM ) ACPI: RSDT @ 0x0xffd0000/0x0028 (v 1 IBM TP600X 0x00000001 0x00000000) ACPI: FACP @ 0x0xffd0100/0x0074 (v 1 IBM TP600X 0x00000001 0x00000000) ACPI: DSDT @ 0x0xffd0200/0xAF9E (v 1 IBM TP600X 0x00000102 MSFT 0x0100000C) ACPI: FACS @ 0x0xffdf000/0x0040 npx0: INT 16 interface acpi0: on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x80003b40 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISA0.PIRQ -> bus 0 dev 1 func 0 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.CBS0.CBUS -> bus 0 dev 2 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.CBS1.CBUS -> bus 0 dev 2 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.PM00.X3DB -> bus 0 dev 7 func 3 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc1c5f000 pa 0x1000 atpic: Programming IRQ9 as level/low acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.IDE0.X140 -> bus 0 dev 7 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.DOCK.IDE1.X140 -> bus 0 dev 0 func 1 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ff00000 (3) failed ACPI timer: 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/5 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xef08-0xef0b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.7.INTD at func 2: 11 ACPI: Found matching pin for 0.2.INTA at func 0: 11 ACPI: Found matching pin for 0.2.INTB at func 1: 11 ACPI: Found matching pin for 0.3.INTA at func 0: 11 ACPI: Found matching pin for 0.6.INTA at func 0: 11 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x7190, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0xa210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0x40000000, size 26, enabled found-> vendor=0x8086, dev=0x7191, revid=0x03 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x88 (34000 ns), maxlat=0x00 (0 ns) found-> vendor=0x104c, dev=0xac1b, revid=0x03 domain=0, bus=0, slot=2, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50103000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.LNKA:0) pcib0: slot 2 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x104c, dev=0xac1b, revid=0x03 domain=0, bus=0, slot=2, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=b, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50102000, size 12, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.LNKB:0) pcib0: slot 2 INTB routed to irq 11 via \\_SB_.LNKB found-> vendor=0x11c1, dev=0x0449, revid=0x01 domain=0, bus=0, slot=3, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x8290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0xfc (63000 ns), maxlat=0x0e (3500 ns) intpin=a, irq=11 powerspec 2 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50101000, size 8, enabled map[14]: type I/O Port, range 32, base 0x4500, size 3, enabled map[18]: type I/O Port, range 32, base 0x4400, size 8, enabled pcib0: matched entry for 0.3.INTA (src \\_SB_.LNKC:0) pcib0: slot 3 INTA routed to irq 11 via \\_SB_.LNKC found-> vendor=0x1013, dev=0x6003, revid=0x01 domain=0, bus=0, slot=6, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x18 (6000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50100000, size 12, enabled map[14]: type Memory, range 32, base 0x50000000, size 20, enabled pcib0: matched entry for 0.6.INTA (src \\_SB_.LNKA:0) pcib0: slot 6 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x8086, dev=0x7110, revid=0x02 domain=0, bus=0, slot=7, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7111, revid=0x01 domain=0, bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x30 (1440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type I/O Port, range 32, base 0xfcf0, size 4, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 domain=0, bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x30 (1440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type I/O Port, range 32, base 0x4000, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD:0) pcib0: slot 7 INTD routed to irq 11 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7113, revid=0x03 domain=0, bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[90]: type I/O Port, range 32, base 0xefa0, size 4, enabled agp0: on hostb0 hostb0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0x40000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0x70000000-0xdfffffff pcib1: prefetched decode 0xe0000000-0xf7ffffff ACPI: Found matching pin for 1.0.INTA at func 0: 11 pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x10c8, dev=0x0006, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x10 (4000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 25, enabled pcib1: requested memory range 0xe0000000-0xe1ffffff: good map[14]: type Memory, range 32, base 0x70000000, size 22, enabled pcib1: requested memory range 0x70000000-0x703fffff: good map[18]: type Memory, range 32, base 0x70400000, size 20, enabled pcib1: requested memory range 0x70400000-0x704fffff: good pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \\_SB_.LNKA vgapci0: mem 0xe0000000-0xe1ffffff,0x70000000-0x703fffff,0x70400000-0x704fffff irq 11 at device 0.0 on pci1 cbb0: mem 0x50103000-0x50103fff irq 11 at device 2.0 on pci0 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50103000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xac1b104c 0x02100007 0x06070003 0x0082a808 0x10: 0x50103000 0x020000a0 0xb0040200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740010b 0x40: 0x01301014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00449069 0x00000000 0x80818080 0x00001000 0x90: 0x416602c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e110001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: mem 0x50102000-0x50102fff irq 11 at device 2.1 on pci0 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50102000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: [FILTER] cbb1: PCI Configuration space: 0x00: 0xac1b104c 0x02100007 0x06070003 0x0082a808 0x10: 0x50102000 0x020000a0 0xb0070500 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740020b 0x40: 0x01301014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0044b069 0x00000000 0x80818080 0x00001000 0x90: 0x416602c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e110001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 pci0: at device 3.0 (no driver attached) csa0: mem 0x50100000-0x50100fff,0x50000000-0x500fffff irq 11 at device 6.0 on pci0 csa: card is Thinkpad 600X/A20/T20 csa0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50100000 csa0: Reserved 0x100000 bytes for rid 0x14 type 3 at 0x50000000 csa0: [GIANT-LOCKED] csa0: [ITHREAD] pcm0: on csa0 pcm0: pcm0: Codec features headphone, 20 bit DAC, 18 bit ADC, 6 bit master volume, Crystal Semi 3D Stereo Enhancement pcm0: Primary codec extended features AMAP pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap f813000, 1000; 0xc1fed000 -> f813000 pcm0: sndbuf_setmap f814000, 1000; 0xc1fee000 -> f814000 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfcf0-0xfcff at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfcf0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=51 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x04 lsb=0x7f msb=0x7f ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 ata1: [MPSAFE] ata1: [ITHREAD] uhci0: port 0x4000-0x401f irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x4000 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_tz3: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0045 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0045 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 atrtc0: port 0x70-0x73 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) battery0: on acpi0 acpi_acad0: on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0xef10 ex_isa_identify() pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcbfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x3bc ppc0: cannot reserve I/O port range ppc0: failed to probe at port 0x3bc-0x3c3 irq 7 on isa0 sn0: not probed (disabled) uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: fast interrupt uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 uart2: not probed (disabled) uart3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 498274309 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default lo0: bpf attached ata0: identify ch->devices=00000001 battery0: battery initialization start acpi_acad0: acline initialization start system power profile changed to 'economy' acpi_acad0: Off Line acpi_acad0: acline initialization done, tried 1 times ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting Pacpi_tz1: _AC0: temperature 43.8 >= setpoint 33.5 IO4 on PIIX4 chipacpi_tz1: switched from NONE to _AC0: 43.8C ad0: setting UDMA33 on PIIX4 chip ad0: 57231MB at ata0-master UDMA33 ad0: 117210240 sectors [124032C/15H/63S] 16 sectors/interrupt 1 depth queue ata1: identify ch->devices=00010000 GEOM: new disk ad0 map[10]: type I/O Port, range 32, base 0, size 6, port disabled found-> vendor=0x10b7, dev=0x5057, revid=0x00 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 xl0: Reserved 0x40 bytes for rid 0x10 type 4 at 0x1000 cbb1: Opening I/O: 0x1000-0x103f xl0: using port I/O xl0: media options word: 40 xl0: found MII/AUTO miibus0: on xl0 tdkphy0: PHY 0 on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 3 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [MPSAFE] xl0: [ITHREAD] ata1-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire battery0: battery initialization done, tried 1 times Need to ack 0x1 acd0: setting PIO4 on PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 4134KB/s (4134KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream acd0: Writes: acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc Trying to mount root from ufs:/dev/ad0s2a ct_to_ts([2008-12-09 21:42:31]) = 1228858951.000000000 start_init: trying /sbin/init WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() splash: image decoder found: snake_saver xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: command never completed! tdkphy0: detached miibus0: detached xl0: detached Need to ack 0x1 map[10]: type I/O Port, range 32, base 0, size 6, port disabled found-> vendor=0x10b7, dev=0x5057, revid=0x00 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 xl0: Reserved 0x40 bytes for rid 0x10 type 4 at 0x1000 cbb1: Opening I/O: 0x1000-0x103f xl0: using port I/O xl0: media options word: 40 xl0: found MII/AUTO miibus0: on xl0 tdkphy0: PHY 0 on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 3 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [MPSAFE] xl0: [ITHREAD] xl0: link state changed to DOWN system power profile changed to 'performance' acpi_acad0: On Line xl0: link state changed to UP From dimitry at andric.com Tue Dec 9 11:42:05 2008 From: dimitry at andric.com (Dimitry Andric) Date: Tue Dec 9 11:42:12 2008 Subject: Why does host and dig show a ; as \;? In-Reply-To: <004901c95a1c$5c6b2680$15417380$@org> References: <004901c95a1c$5c6b2680$15417380$@org> Message-ID: <493ECA0D.7090901@andric.com> On 2008-12-09 17:36, Larry Rosenman wrote: > Why does the host command, dig, and a named_db.dump all show a ; as \; in a > TXT record? AFAICS the semicolon is a comment character in BIND software (at least in all config files and so on), and therefore it needs to be escaped. From imp at bsdimp.com Tue Dec 9 11:49:03 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Dec 9 11:49:10 2008 Subject: "interrupt storm..."; seems associated with an0 NIC In-Reply-To: <20081209192439.GA16703@artx.ru> References: <20081209141908.GA15845@artx.ru> <20081209.092739.35219831.imp@bsdimp.com> <20081209192439.GA16703@artx.ru> Message-ID: <20081209.124743.-201314317.imp@bsdimp.com> In message: <20081209192439.GA16703@artx.ru> Ilya Orehov writes: : Need to ack 0x1 What happens if you also print the current mask register? CBB_SOCKET_MASK? Warner From ler at lerctr.org Tue Dec 9 11:49:31 2008 From: ler at lerctr.org (Larry Rosenman) Date: Tue Dec 9 11:49:38 2008 Subject: Why does host and dig show a ; as \;? In-Reply-To: <493ECA0D.7090901@andric.com> References: <004901c95a1c$5c6b2680$15417380$@org> <493ECA0D.7090901@andric.com> Message-ID: On Tue, 9 Dec 2008, Dimitry Andric wrote: > On 2008-12-09 17:36, Larry Rosenman wrote: >> Why does the host command, dig, and a named_db.dump all show a ; as \; in a >> TXT record? > > AFAICS the semicolon is a comment character in BIND software (at least > in all config files and so on), and therefore it needs to be escaped. > This is in the responses as shown: $ host -t txt blueprint._domainkey.lombardi.com blueprint._domainkey.lombardi.com descriptive text "v=DKIM1\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCkAwTHQf0339ugaLhgZWCfGWvgzB92PrD03kpk/RsFv5novZZT0QnL2zVXyBFHe2BjbVrfOl9oF33A3hniVrt89iz3dhZD9NWiYsBZl5qYhTfNe7Ia8ZeBb+PuswQnEWG5/aFmkAoDj2L6RHUJlAyjDo4dxCbqnDiFUiV4BqMQQIDAQAB\;" But the actual record does NOT have the \ in it. This was confusing to me. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From scottl at samsco.org Tue Dec 9 12:33:42 2008 From: scottl at samsco.org (Scott Long) Date: Tue Dec 9 12:33:49 2008 Subject: uart vs sio differences ? In-Reply-To: <0E8F5AD4-A139-413E-A760-A1BEDDF44BAA@mac.com> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> <0E8F5AD4-A139-413E-A760-A1BEDDF44BAA@mac.com> Message-ID: <493ED621.5010006@samsco.org> Marcel Moolenaar wrote: > > On Dec 9, 2008, at 9:14 AM, Scott Long wrote: > >> That aside, I think what needs to happen is for the driver to use the >> interrupt handler to pull the bytes out of the hardware and into an >> internal lockless ring buffer, then schedule the swi to process the ring >> buffer. > > The uart(4) driver is exactly doing what you describe. > Yup, my mistake. However, I think that the semaphore spinwait in uart_sched_softih() is the source of the problems here. Imagine a a timeline scenario like this (in 8-CURRENT): CPU0 CPU1 irq4 uart_intr() UART_RECEIVE() uart_sched_softih() check ttypend swi_sched() uart_swi uart_tty_intr() clear ttypend tty_lock() irq4 uart_intr() UART_RECEIVE() uart_sched_softih() check ttypend swi_sched() irq4 uart_intr() UART_RECEIVE() uart_sched_softif() check ttypend With FreeBSD 6 and 7, it's even worse because Giant can be contended on before ttypend is cleared. But in either case, what you've effectively done here is created a home-rolled spinlock that comes after a sleep lock, so the time-critical interrupt handler is now slaved to the slow swi handler, completely defeating the benefits of having a fast handler (and also defeating WITNESS checks against this kind of problem). You really don't need the home-rolled semaphore. You already atomically read and write the variable, so you can just have uart_tty_intr() continue to loop around to check if it changes. Or since you already have a nice lockless ring buffer, you could just extend it also store each pending flag update. Scott From elias at artx.ru Tue Dec 9 12:44:07 2008 From: elias at artx.ru (Ilya Orehov) Date: Tue Dec 9 12:44:13 2008 Subject: "interrupt storm..."; seems associated with an0 NIC In-Reply-To: <20081209.124743.-201314317.imp@bsdimp.com> References: <20081209141908.GA15845@artx.ru> <20081209.092739.35219831.imp@bsdimp.com> <20081209192439.GA16703@artx.ru> <20081209.124743.-201314317.imp@bsdimp.com> Message-ID: <20081209204404.GA17018@artx.ru> +------- M. Warner Losh, 2008-12-09 ------- | In message: <20081209192439.GA16703@artx.ru> | Ilya Orehov writes: | : Need to ack 0x1 | | What happens if you also print the current mask register? CBB_SOCKET_MASK? Rebooted with xl0 card inserted, first time (after initialization) mask=7, after eject/insert xl0 mask=1. ... xl0: Ethernet address: 00:60:08:d2:38:56 xl0: [ITHREAD] Need to ack 0x1, mask=00000007 acd0: CDROM at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s2a WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: command never completed! tdkphy0: detached miibus0: detached xl0: detached Need to ack 0x1, mask=00000001 xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 miibus0: on xl0 ... Rebooted once more, without card. After card (xl0) inserted, mask=1. Rebooted with same card inserted in second slot. First time (after initialization) mask=7, after eject/insert into same slot xl0 mask=1, after eject card was inserted into first slot, mask=1, code was: if (!ack) { mask = cbb_get(sc, CBB_SOCKET_MASK); printf("Need to ack %#x, mask=%08x\n", sockevent, mask); cbb_set(sc, CBB_SOCKET_EVENT, sockevent); } regards, Ilya. | | Warner | +----------------------------- From xcllnt at mac.com Tue Dec 9 12:44:42 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Dec 9 12:44:49 2008 Subject: uart vs sio differences ? In-Reply-To: <493ED621.5010006@samsco.org> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> <0E8F5AD4-A139-413E-A760-A1BEDDF44BAA@mac.com> <493ED621.5010006@samsco.org> Message-ID: <30BECC4D-DD91-4C13-8F0B-5A2AE59DFC5D@mac.com> On Dec 9, 2008, at 12:33 PM, Scott Long wrote: > > Yup, my mistake. However, I think that the semaphore spinwait in > uart_sched_softih() is the source of the problems here. It's not a semaphore spinwait. It's just an atomic operation: 1. read old, 2. calculate new from old, 3. atomic_cmpset(old, new) 4. goto 1 if 3 fails. The loop iterates only if ttypend got changed between 1 and 3. There's no spinwaiting and no semaphore-like behaviour. FYI, -- Marcel Moolenaar xcllnt@mac.com From imp at bsdimp.com Tue Dec 9 13:18:43 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Dec 9 13:18:50 2008 Subject: "interrupt storm..."; seems associated with an0 NIC In-Reply-To: <20081209204404.GA17018@artx.ru> References: <20081209192439.GA16703@artx.ru> <20081209.124743.-201314317.imp@bsdimp.com> <20081209204404.GA17018@artx.ru> Message-ID: <20081209.141616.2139790010.imp@bsdimp.com> Thanks! This helps a lot. The fact that xl works also is an important hint for me for another problem I'm chasing... does this patch cause the printfs we've added to not be hit? Warner Index: pccbb.c =================================================================== --- pccbb.c (revision 185750) +++ pccbb.c (working copy) @@ -514,7 +514,7 @@ * a chance to run. */ mtx_lock(&sc->mtx); - cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD | CBB_SOCKET_MASK_CSTS); + cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD); msleep(&sc->intrhand, &sc->mtx, 0, "-", 0); err = 0; while (err != EWOULDBLOCK && In message: <20081209204404.GA17018@artx.ru> Ilya Orehov writes: : +------- M. Warner Losh, 2008-12-09 ------- : | In message: <20081209192439.GA16703@artx.ru> : | Ilya Orehov writes: : | : Need to ack 0x1 : | : | What happens if you also print the current mask register? CBB_SOCKET_MASK? : : Rebooted with xl0 card inserted, : first time (after initialization) mask=7, : after eject/insert xl0 mask=1. : : ... : xl0: Ethernet address: 00:60:08:d2:38:56 : xl0: [ITHREAD] : Need to ack 0x1, mask=00000007 : acd0: CDROM at ata1-master PIO4 : Trying to mount root from ufs:/dev/ad0s2a : WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() : xl0: reset didn't complete : xl0: command never completed! : xl0: command never completed! : xl0: command never completed! : tdkphy0: detached : miibus0: detached : xl0: detached : Need to ack 0x1, mask=00000001 : xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 : miibus0: on xl0 : ... : : Rebooted once more, without card. : After card (xl0) inserted, mask=1. : : Rebooted with same card inserted in second slot. : First time (after initialization) mask=7, : after eject/insert into same slot xl0 mask=1, : after eject card was inserted into first slot, mask=1, : : code was: : if (!ack) { : mask = cbb_get(sc, CBB_SOCKET_MASK); : printf("Need to ack %#x, mask=%08x\n", sockevent, mask); : cbb_set(sc, CBB_SOCKET_EVENT, sockevent); : } : : regards, : Ilya. : : : | : | Warner : | : +----------------------------- : : From jhb at freebsd.org Tue Dec 9 13:26:10 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Dec 9 13:26:21 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> Message-ID: <200812091602.10850.jhb@freebsd.org> On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: > On 12/5/08, John Baldwin wrote: > > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: > >> On 12/5/08, John Baldwin wrote: > >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: > >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: > >> >> > On 11/19/08, John Baldwin wrote: > >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and enable > >> > shared > >> >> > > lookups. The changes to cd9660_lookup() mirror similar changes to > >> >> > > ufs_lookup() to use static variables for local data rather than > >> >> > > abusing > >> >> > > i-node members of the parent directory. I've done some light > >> >> > > testing > >> >> > > of > >> >> > > this, but not super-strenuous. This patch also includes simple > >> >> > > locking > >> >> for > >> >> > > the iconv support in the kernel. That locking uses an sx lock to > >> >> serialize > >> >> > > open and close of translator tables and the associated refcount. > >> >> > > Actual > >> >> > > conversions do not need any locks, however as the mount holds a > >> > reference > >> >> on > >> >> > > the table. > >> >> > > > >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch > >> >> > > > >> >> > > >> >> > With this patch I'm unable to kldunload libiconv.ko once it is > >> >> > loaded. > >> >> > And trying to kldunload libiconv.ko will make any next > >> >> kldload/kldstat/kldunload > >> >> > to fail waiting forever(livelock). > >> >> > > >> >> > Regression were not encountered while only cd9660.ko were kldloaded. > >> >> > >> >> So this is actually due to a bug in the module code. If you have two > >> > modules > >> >> like this: > >> >> > >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); > >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); > >> >> > >> >> The SI_* constants ensure that foo's module handler is called before > > bar's > >> >> > >> >> module handler for MOD_LOAD. However, we don't enforce a reverse order > >> >> (bar > >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events is > >> >> random > >> >> and has no relation to the SI_* constants. :( > >> >> > >> >> What is happening here is that one of the 'bar' modules in libiconv.ko > >> >> is > >> >> getting unloaded after 'foo' gets unloaded and using a destroyed lock > > (you > >> >> > >> >> get a panic if you run with INVARIANTS). > >> > > >> > So this should now be fixed with this commit. If you could verify that > >> > iconv > >> > works ok with the latest kern_module.c I would appreciate it. > >> > > >> > Author: jhb > >> > Date: Fri Dec 5 16:47:30 2008 > >> > New Revision: 185642 > >> > URL: http://svn.freebsd.org/changeset/base/185642 > >> > > >> > Log: > >> > When the SYSINIT() to load a module invokes the MOD_LOAD event > >> > successfully, > >> > move that module to the head of the associated linker file's list of > >> > modules. > >> > The end result is that once all the modules are loaded, they are > >> > sorted > > in > >> > the reverse of their load order. This causes the kernel linker to > > invoke > >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order that > >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD events > >> > that > >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored in > >> > the > >> > same > >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and MOD_UNLOAD > >> > events. > >> > > >> > MFC after: 1 month > >> > > >> > -- > >> > John Baldwin > >> > > >> > >> Yes it works, I tried hard multiple times kldload/kldunload > >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, > >> but without success. > >> > >> FYI following LORs happened: > >> > >> lock order reversal: > >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 > >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 > >> 3rd 0xc4322bdc isofs (isofs) @ > >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 > > > > This LOR should be addressed in the latest cd9660 locking patches. > > > > -- > > John Baldwin > > > > Oh, why I did not checked new version? > > Yes that LOR have gone, but when doing "ll -R" first time on /mnt > I got following messages from kernel: > > RRIP without PX field? x ~ 50 times. > > I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... The RRIP stuff is all done in cd9660_vget_internal() under an exclusive lock. It could be a property of the ISO image. "PX" holds permissions (owner, etc.). Do you get the same messages w/o the patch with the same ISO image / CD? -- John Baldwin From david at catwhisker.org Tue Dec 9 15:01:35 2008 From: david at catwhisker.org (David Wolfskill) Date: Tue Dec 9 15:01:42 2008 Subject: Laptop w/ dark screen & no (working) keyboard Message-ID: <20081209230134.GC60731@albert.catwhisker.org> This would be a freshly-built CURRENT; sources as of around 0330 hrs. US/Pacific this morning. Breaking into the debugger (Ctl+Atl+Esc), I see on the serial console: KDB: enter: manual escape to debugger [thread pid 12 tid 100020 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 12 tid 100020 td 0xc4e766c0 kdb_enter(c0b6de50,c0ba2bbb,1,0,1,...) at kdb_enter+0x3a scgetc(c0cf5fd0,0,c0ba2ae5,26b,c085148c,...) at scgetc+0x53f sckbdevent(c4de0300,0,c0e874a0,c4dac880,c4a78c64,...) at sckbdevent+0x224 kbdmux_intr(c4de0300,0,c4dac898,c4e6a7c0,c4dac898,...) at kbdmux_intr+0x2b kbdmux_kbd_intr(c4de0300,1,c0bb8e10,54,c4e6a7dc,...) at kbdmux_kbd_intr+0x25 taskqueue_run(c4e6a7c0,c4a78cc8,c07f14e5,0,0,...) at taskqueue_run+0x10b taskqueue_swi_giant_run(0,0,c0bb0715,46d,c4dac038,...) at taskqueue_swi_giant_run+0x13 intr_event_execute_handlers(c4d677ec,c4dac000,c0bb0715,4dd,c4dac070,...) at intr_event_execute_handlers+0x125 ithread_loop(c4e749d0,c4a78d38,c0bb0490,32d,c4d677ec,...) at ithread_loop+0x9f fork_exit(c07f20c0,c4e749d0,c4a78d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4a78d70, ebp = 0 --- db> show locks exclusive sleep mutex Giant (Giant) r = 1 (0xc0cf5fd0) locked @ /usr/src/sys/dev/kbdmux/kbdmux.c:1044 db> Anything else I can try to extract from this that might be useful? Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081209/5b9af0b7/attachment.pgp From onemda at gmail.com Tue Dec 9 15:15:09 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Dec 9 15:15:18 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <200812091602.10850.jhb@freebsd.org> References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> Message-ID: <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> On 12/9/08, John Baldwin wrote: > On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: >> On 12/5/08, John Baldwin wrote: >> > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >> >> On 12/5/08, John Baldwin wrote: >> >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >> >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >> >> >> > On 11/19/08, John Baldwin wrote: >> >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and >> >> >> > > enable >> >> > shared >> >> >> > > lookups. The changes to cd9660_lookup() mirror similar changes >> >> >> > > to >> >> >> > > ufs_lookup() to use static variables for local data rather than >> >> >> > > abusing >> >> >> > > i-node members of the parent directory. I've done some light >> >> >> > > testing >> >> >> > > of >> >> >> > > this, but not super-strenuous. This patch also includes simple >> >> >> > > locking >> >> >> for >> >> >> > > the iconv support in the kernel. That locking uses an sx lock >> >> >> > > to >> >> >> serialize >> >> >> > > open and close of translator tables and the associated refcount. >> >> >> > > Actual >> >> >> > > conversions do not need any locks, however as the mount holds a >> >> > reference >> >> >> on >> >> >> > > the table. >> >> >> > > >> >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >> >> >> > > >> >> >> > >> >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >> >> >> > loaded. >> >> >> > And trying to kldunload libiconv.ko will make any next >> >> >> kldload/kldstat/kldunload >> >> >> > to fail waiting forever(livelock). >> >> >> > >> >> >> > Regression were not encountered while only cd9660.ko were >> >> >> > kldloaded. >> >> >> >> >> >> So this is actually due to a bug in the module code. If you have >> >> >> two >> >> > modules >> >> >> like this: >> >> >> >> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >> >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >> >> >> >> >> >> The SI_* constants ensure that foo's module handler is called before >> > bar's >> >> >> >> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse > order >> >> >> (bar >> >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events >> >> >> is >> >> >> random >> >> >> and has no relation to the SI_* constants. :( >> >> >> >> >> >> What is happening here is that one of the 'bar' modules in >> >> >> libiconv.ko >> >> >> is >> >> >> getting unloaded after 'foo' gets unloaded and using a destroyed >> >> >> lock >> > (you >> >> >> >> >> >> get a panic if you run with INVARIANTS). >> >> > >> >> > So this should now be fixed with this commit. If you could verify >> >> > that >> >> > iconv >> >> > works ok with the latest kern_module.c I would appreciate it. >> >> > >> >> > Author: jhb >> >> > Date: Fri Dec 5 16:47:30 2008 >> >> > New Revision: 185642 >> >> > URL: http://svn.freebsd.org/changeset/base/185642 >> >> > >> >> > Log: >> >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >> >> > successfully, >> >> > move that module to the head of the associated linker file's list >> >> > of >> >> > modules. >> >> > The end result is that once all the modules are loaded, they are >> >> > sorted >> > in >> >> > the reverse of their load order. This causes the kernel linker to >> > invoke >> >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order > that >> >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD > events >> >> > that >> >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored in >> >> > the >> >> > same >> >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and > MOD_UNLOAD >> >> > events. >> >> > >> >> > MFC after: 1 month >> >> > >> >> > -- >> >> > John Baldwin >> >> > >> >> >> >> Yes it works, I tried hard multiple times kldload/kldunload >> >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >> >> but without success. >> >> >> >> FYI following LORs happened: >> >> >> >> lock order reversal: >> >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >> >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >> >> 3rd 0xc4322bdc isofs (isofs) @ >> >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 >> > >> > This LOR should be addressed in the latest cd9660 locking patches. >> > >> > -- >> > John Baldwin >> > >> >> Oh, why I did not checked new version? >> >> Yes that LOR have gone, but when doing "ll -R" first time on /mnt >> I got following messages from kernel: >> >> RRIP without PX field? x ~ 50 times. >> >> I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... > > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive > lock. > It could be a property of the ISO image. "PX" holds permissions (owner, > etc.). Do you get the same messages w/o the patch with the same ISO image / > CD? > > -- > John Baldwin > No I do not, but I may try other CDs I have many of them, including FreeBSD one. If it is irrelevant than it should not be displayed. -- Paul From onemda at gmail.com Tue Dec 9 15:16:45 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Dec 9 15:16:54 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> Message-ID: <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> On 12/10/08, Paul B. Mahol wrote: > On 12/9/08, John Baldwin wrote: >> On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: >>> On 12/5/08, John Baldwin wrote: >>> > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >>> >> On 12/5/08, John Baldwin wrote: >>> >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >>> >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >>> >> >> > On 11/19/08, John Baldwin wrote: >>> >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and >>> >> >> > > enable >>> >> > shared >>> >> >> > > lookups. The changes to cd9660_lookup() mirror similar changes >>> >> >> > > to >>> >> >> > > ufs_lookup() to use static variables for local data rather than >>> >> >> > > abusing >>> >> >> > > i-node members of the parent directory. I've done some light >>> >> >> > > testing >>> >> >> > > of >>> >> >> > > this, but not super-strenuous. This patch also includes simple >>> >> >> > > locking >>> >> >> for >>> >> >> > > the iconv support in the kernel. That locking uses an sx lock >>> >> >> > > to >>> >> >> serialize >>> >> >> > > open and close of translator tables and the associated >>> >> >> > > refcount. >>> >> >> > > Actual >>> >> >> > > conversions do not need any locks, however as the mount holds a >>> >> > reference >>> >> >> on >>> >> >> > > the table. >>> >> >> > > >>> >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >>> >> >> > > >>> >> >> > >>> >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >>> >> >> > loaded. >>> >> >> > And trying to kldunload libiconv.ko will make any next >>> >> >> kldload/kldstat/kldunload >>> >> >> > to fail waiting forever(livelock). >>> >> >> > >>> >> >> > Regression were not encountered while only cd9660.ko were >>> >> >> > kldloaded. >>> >> >> >>> >> >> So this is actually due to a bug in the module code. If you have >>> >> >> two >>> >> > modules >>> >> >> like this: >>> >> >> >>> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >>> >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >>> >> >> >>> >> >> The SI_* constants ensure that foo's module handler is called >>> >> >> before >>> > bar's >>> >> >> >>> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse >> order >>> >> >> (bar >>> >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events >>> >> >> is >>> >> >> random >>> >> >> and has no relation to the SI_* constants. :( >>> >> >> >>> >> >> What is happening here is that one of the 'bar' modules in >>> >> >> libiconv.ko >>> >> >> is >>> >> >> getting unloaded after 'foo' gets unloaded and using a destroyed >>> >> >> lock >>> > (you >>> >> >> >>> >> >> get a panic if you run with INVARIANTS). >>> >> > >>> >> > So this should now be fixed with this commit. If you could verify >>> >> > that >>> >> > iconv >>> >> > works ok with the latest kern_module.c I would appreciate it. >>> >> > >>> >> > Author: jhb >>> >> > Date: Fri Dec 5 16:47:30 2008 >>> >> > New Revision: 185642 >>> >> > URL: http://svn.freebsd.org/changeset/base/185642 >>> >> > >>> >> > Log: >>> >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >>> >> > successfully, >>> >> > move that module to the head of the associated linker file's list >>> >> > of >>> >> > modules. >>> >> > The end result is that once all the modules are loaded, they are >>> >> > sorted >>> > in >>> >> > the reverse of their load order. This causes the kernel linker to >>> > invoke >>> >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order >> that >>> >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD >> events >>> >> > that >>> >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored >>> >> > in >>> >> > the >>> >> > same >>> >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and >> MOD_UNLOAD >>> >> > events. >>> >> > >>> >> > MFC after: 1 month >>> >> > >>> >> > -- >>> >> > John Baldwin >>> >> > >>> >> >>> >> Yes it works, I tried hard multiple times kldload/kldunload >>> >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >>> >> but without success. >>> >> >>> >> FYI following LORs happened: >>> >> >>> >> lock order reversal: >>> >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >>> >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >>> >> 3rd 0xc4322bdc isofs (isofs) @ >>> >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 >>> > >>> > This LOR should be addressed in the latest cd9660 locking patches. >>> > >>> > -- >>> > John Baldwin >>> > >>> >>> Oh, why I did not checked new version? >>> >>> Yes that LOR have gone, but when doing "ll -R" first time on /mnt >>> I got following messages from kernel: >>> >>> RRIP without PX field? x ~ 50 times. >>> >>> I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... >> >> The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >> lock. >> It could be a property of the ISO image. "PX" holds permissions (owner, >> etc.). Do you get the same messages w/o the patch with the same ISO image >> / >> CD? >> >> -- >> John Baldwin >> > > No I do not, but I may try other CDs I have many of them, including FreeBSD s/Yes I do. Its to late here ... > one. > If it is irrelevant than it should not be displayed. -- Paul From david at catwhisker.org Tue Dec 9 15:22:10 2008 From: david at catwhisker.org (David Wolfskill) Date: Tue Dec 9 15:22:17 2008 Subject: Laptop w/ dark screen & no (working) keyboard In-Reply-To: <20081209230134.GC60731@albert.catwhisker.org> References: <20081209230134.GC60731@albert.catwhisker.org> Message-ID: <20081209232209.GD60731@albert.catwhisker.org> After a reboot -- which exhibited the same symptoms initially: login: lock order reversal: 1st 0xc55bfad0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:424 2nd 0xd8d3fc50 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc52d337c ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:545 KDB: stack backtrace: db_trace_self_wrapper(c0bb77be,c4bbb40c,c0851645,4,c0bb2cb1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bb2cb1,c4d21810,c4d24e18,c4bbb468,...) at kdb_backtrace+0x29 _witness_debugger(c0bba487,c52d337c,c0bade76,c4d24e18,c0bd8a13,...) at _witness_debugger+0x25 witness_checkorder(c52d337c,9,c0bd8a13,221,0,...) at witness_checkorder+0x839 __lockmgr_args(c52d337c,80100,c52d3398,0,0,...) at __lockmgr_args+0x797 ffs_lock(c4bbb578,c0e35ee0,c55860a4,80100,c52d3324,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cbf480,c4bbb578,c4bbb598,c0cd3400,c52d3324,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c52d3324,80100,c0bd8a13,221,c4d55800,...) at _vn_lock+0x5e ffs_snapshot(c51c0a00,c53029c0,c0bda378,15e,3,...) at ffs_snapshot+0x1527 ffs_mount(c51c0a00,c5586000,c0bc0c2b,3dc,c4e8ac80,...) at ffs_mount+0x146f vfs_donmount(c5586000,211000,c52fdb00,c52fdb00,201000,...) at vfs_donmount+0x1312 nmount(c5586000,c4bbbcf8,c,c4bbbd38,c0c9b790,...) at nmount+0xbe syscall(c4bbbd38) at syscall+0x2a3 -- I got involved in some other things, when I happened to see (on the serial console): Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6c9b, esp = 0xbfbfeb1c, ebp = 0xbfbfee78 --- info: [drm] Setting GART location based on new memory map info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm0: [MPSAFE] drm0: [ITHREAD] lock order reversal: 1st 0xd8d3fc50 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 2nd 0xc4f9f01c snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:794 KDB: stack backtrace: db_trace_self_wrapper(c0bb77be,c4bbb40c,c0851645,4,c0bb2cb1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bb2cb1,c4d21810,c4d25638,c4bbb468,...) at kdb_backtrace+0x29 _witness_debugger(c0bba46e,c4f9f01c,c0bd8a75,c4d25638,c0bd8a13,...) at _witness_debugger+0x25 witness_checkorder(c4f9f01c,9,c0bd8a13,31a,c55bfaec,...) at witness_checkorder+0x839 __lockmgr_args(c4f9f01c,80400,c55bfaec,0,0,...) at __lockmgr_args+0x797 ffs_lock(c4bbb578,0,0,80400,c55bfa78,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0cbf480,c4bbb578,c211a614,c0cd3400,c55bfa78,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c55bfa78,80400,c0bd8a13,31a,0,...) at _vn_lock+0x5e ffs_snapshot(c51c0a00,c53029c0,c0bda378,15e,3,...) at ffs_snapshot+0x28c6 ffs_mount(c51c0a00,c5586000,c0bc0c2b,3dc,c4e8ac80,...) at ffs_mount+0x146f vfs_donmount(c5586000,211000,c52fdb00,c52fdb00,201000,...) at vfs_donmount+0x1312 nmount(c5586000,c4bbbcf8,c,c4bbbd38,c0c9b790,...) at nmount+0xbe syscall(c4bbbd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e6c9b, esp = 0xbfbfeb1c, ebp = 0xbfbfee78 --- FreeBSD/i386 (Amnesiac) (ttyu0) login: [end of cut/paste] and the screen lit up. :-} Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081209/cdfcf096/attachment.pgp From onemda at gmail.com Tue Dec 9 15:56:05 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Dec 9 15:56:12 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> Message-ID: <3a142e750812091556x682008dagb8e1e867d0bdca79@mail.gmail.com> On 12/10/08, Paul B. Mahol wrote: > On 12/10/08, Paul B. Mahol wrote: >> On 12/9/08, John Baldwin wrote: >>> On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: >>>> On 12/5/08, John Baldwin wrote: >>>> > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >>>> >> On 12/5/08, John Baldwin wrote: >>>> >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >>>> >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >>>> >> >> > On 11/19/08, John Baldwin wrote: >>>> >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and >>>> >> >> > > enable >>>> >> > shared >>>> >> >> > > lookups. The changes to cd9660_lookup() mirror similar >>>> >> >> > > changes >>>> >> >> > > to >>>> >> >> > > ufs_lookup() to use static variables for local data rather >>>> >> >> > > than >>>> >> >> > > abusing >>>> >> >> > > i-node members of the parent directory. I've done some light >>>> >> >> > > testing >>>> >> >> > > of >>>> >> >> > > this, but not super-strenuous. This patch also includes >>>> >> >> > > simple >>>> >> >> > > locking >>>> >> >> for >>>> >> >> > > the iconv support in the kernel. That locking uses an sx lock >>>> >> >> > > to >>>> >> >> serialize >>>> >> >> > > open and close of translator tables and the associated >>>> >> >> > > refcount. >>>> >> >> > > Actual >>>> >> >> > > conversions do not need any locks, however as the mount holds >>>> >> >> > > a >>>> >> > reference >>>> >> >> on >>>> >> >> > > the table. >>>> >> >> > > >>>> >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >>>> >> >> > > >>>> >> >> > >>>> >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >>>> >> >> > loaded. >>>> >> >> > And trying to kldunload libiconv.ko will make any next >>>> >> >> kldload/kldstat/kldunload >>>> >> >> > to fail waiting forever(livelock). >>>> >> >> > >>>> >> >> > Regression were not encountered while only cd9660.ko were >>>> >> >> > kldloaded. >>>> >> >> >>>> >> >> So this is actually due to a bug in the module code. If you have >>>> >> >> two >>>> >> > modules >>>> >> >> like this: >>>> >> >> >>>> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >>>> >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >>>> >> >> >>>> >> >> The SI_* constants ensure that foo's module handler is called >>>> >> >> before >>>> > bar's >>>> >> >> >>>> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse >>> order >>>> >> >> (bar >>>> >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events >>>> >> >> is >>>> >> >> random >>>> >> >> and has no relation to the SI_* constants. :( >>>> >> >> >>>> >> >> What is happening here is that one of the 'bar' modules in >>>> >> >> libiconv.ko >>>> >> >> is >>>> >> >> getting unloaded after 'foo' gets unloaded and using a destroyed >>>> >> >> lock >>>> > (you >>>> >> >> >>>> >> >> get a panic if you run with INVARIANTS). >>>> >> > >>>> >> > So this should now be fixed with this commit. If you could verify >>>> >> > that >>>> >> > iconv >>>> >> > works ok with the latest kern_module.c I would appreciate it. >>>> >> > >>>> >> > Author: jhb >>>> >> > Date: Fri Dec 5 16:47:30 2008 >>>> >> > New Revision: 185642 >>>> >> > URL: http://svn.freebsd.org/changeset/base/185642 >>>> >> > >>>> >> > Log: >>>> >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >>>> >> > successfully, >>>> >> > move that module to the head of the associated linker file's list >>>> >> > of >>>> >> > modules. >>>> >> > The end result is that once all the modules are loaded, they are >>>> >> > sorted >>>> > in >>>> >> > the reverse of their load order. This causes the kernel linker >>>> >> > to >>>> > invoke >>>> >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order >>> that >>>> >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD >>> events >>>> >> > that >>>> >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored >>>> >> > in >>>> >> > the >>>> >> > same >>>> >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and >>> MOD_UNLOAD >>>> >> > events. >>>> >> > >>>> >> > MFC after: 1 month >>>> >> > >>>> >> > -- >>>> >> > John Baldwin >>>> >> > >>>> >> >>>> >> Yes it works, I tried hard multiple times kldload/kldunload >>>> >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >>>> >> but without success. >>>> >> >>>> >> FYI following LORs happened: >>>> >> >>>> >> lock order reversal: >>>> >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >>>> >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >>>> >> 3rd 0xc4322bdc isofs (isofs) @ >>>> >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 >>>> > >>>> > This LOR should be addressed in the latest cd9660 locking patches. >>>> > >>>> > -- >>>> > John Baldwin >>>> > >>>> >>>> Oh, why I did not checked new version? >>>> >>>> Yes that LOR have gone, but when doing "ll -R" first time on /mnt >>>> I got following messages from kernel: >>>> >>>> RRIP without PX field? x ~ 50 times. >>>> >>>> I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... >>> >>> The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >>> lock. >>> It could be a property of the ISO image. "PX" holds permissions (owner, >>> etc.). Do you get the same messages w/o the patch with the same ISO >>> image >>> / >>> CD? >>> >>> -- >>> John Baldwin >>> >> >> No I do not, but I may try other CDs I have many of them, including >> FreeBSD FreeBSD snapshot CD have same "issue". It doesnt appear always (I mean I do not count vfs cache) maybe disabling SMP and PREEMPTION will silent it. > s/Yes I do. Its to late here ... > >> one. >> If it is irrelevant than it should not be displayed. -- Paul From onemda at gmail.com Tue Dec 9 16:28:16 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Dec 9 16:28:23 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> <3a142e750812091515u3f2e5807j3652f2cc3551a3b2@mail.gmail.com> <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> Message-ID: <3a142e750812091628l69034673sa2e11e71ba0bdad4@mail.gmail.com> On 12/10/08, Paul B. Mahol wrote: > On 12/10/08, Paul B. Mahol wrote: >> On 12/9/08, John Baldwin wrote: >>> On Friday 05 December 2008 04:54:23 pm Paul B. Mahol wrote: >>>> On 12/5/08, John Baldwin wrote: >>>> > On Friday 05 December 2008 03:56:31 pm Paul B. Mahol wrote: >>>> >> On 12/5/08, John Baldwin wrote: >>>> >> > On Thursday 20 November 2008 05:47:28 pm John Baldwin wrote: >>>> >> >> On Thursday 20 November 2008 04:30:57 pm Paul B. Mahol wrote: >>>> >> >> > On 11/19/08, John Baldwin wrote: >>>> >> >> > > This is a relatively simple patch to mark cd9660 MPSAFE and >>>> >> >> > > enable >>>> >> > shared >>>> >> >> > > lookups. The changes to cd9660_lookup() mirror similar >>>> >> >> > > changes >>>> >> >> > > to >>>> >> >> > > ufs_lookup() to use static variables for local data rather >>>> >> >> > > than >>>> >> >> > > abusing >>>> >> >> > > i-node members of the parent directory. I've done some light >>>> >> >> > > testing >>>> >> >> > > of >>>> >> >> > > this, but not super-strenuous. This patch also includes >>>> >> >> > > simple >>>> >> >> > > locking >>>> >> >> for >>>> >> >> > > the iconv support in the kernel. That locking uses an sx lock >>>> >> >> > > to >>>> >> >> serialize >>>> >> >> > > open and close of translator tables and the associated >>>> >> >> > > refcount. >>>> >> >> > > Actual >>>> >> >> > > conversions do not need any locks, however as the mount holds >>>> >> >> > > a >>>> >> > reference >>>> >> >> on >>>> >> >> > > the table. >>>> >> >> > > >>>> >> >> > > http://www.FreeBSD.org/~jhb/patches/cd9660_mpsafe.patch >>>> >> >> > > >>>> >> >> > >>>> >> >> > With this patch I'm unable to kldunload libiconv.ko once it is >>>> >> >> > loaded. >>>> >> >> > And trying to kldunload libiconv.ko will make any next >>>> >> >> kldload/kldstat/kldunload >>>> >> >> > to fail waiting forever(livelock). >>>> >> >> > >>>> >> >> > Regression were not encountered while only cd9660.ko were >>>> >> >> > kldloaded. >>>> >> >> >>>> >> >> So this is actually due to a bug in the module code. If you have >>>> >> >> two >>>> >> > modules >>>> >> >> like this: >>>> >> >> >>>> >> >> DECLARE_MODULE(foo, SI_SUB_DRIVERS, SI_ORDER_FIRST); >>>> >> >> DECLARE_MODULE(bar, SI_SUB_DRIVERS, SI_ORDER_SECOND); >>>> >> >> >>>> >> >> The SI_* constants ensure that foo's module handler is called >>>> >> >> before >>>> > bar's >>>> >> >> >>>> >> >> module handler for MOD_LOAD. However, we don't enforce a reverse >>> order >>>> >> >> (bar >>>> >> >> then foo) for MOD_UNLOAD. In fact, the order of MOD_UNLOAD events >>>> >> >> is >>>> >> >> random >>>> >> >> and has no relation to the SI_* constants. :( >>>> >> >> >>>> >> >> What is happening here is that one of the 'bar' modules in >>>> >> >> libiconv.ko >>>> >> >> is >>>> >> >> getting unloaded after 'foo' gets unloaded and using a destroyed >>>> >> >> lock >>>> > (you >>>> >> >> >>>> >> >> get a panic if you run with INVARIANTS). >>>> >> > >>>> >> > So this should now be fixed with this commit. If you could verify >>>> >> > that >>>> >> > iconv >>>> >> > works ok with the latest kern_module.c I would appreciate it. >>>> >> > >>>> >> > Author: jhb >>>> >> > Date: Fri Dec 5 16:47:30 2008 >>>> >> > New Revision: 185642 >>>> >> > URL: http://svn.freebsd.org/changeset/base/185642 >>>> >> > >>>> >> > Log: >>>> >> > When the SYSINIT() to load a module invokes the MOD_LOAD event >>>> >> > successfully, >>>> >> > move that module to the head of the associated linker file's list >>>> >> > of >>>> >> > modules. >>>> >> > The end result is that once all the modules are loaded, they are >>>> >> > sorted >>>> > in >>>> >> > the reverse of their load order. This causes the kernel linker >>>> >> > to >>>> > invoke >>>> >> > the MOD_QUIESCE and MOD_UNLOAD events in the reverse of the order >>> that >>>> >> > MOD_LOAD was invoked. This means that the ordering of MOD_LOAD >>> events >>>> >> > that >>>> >> > is set by the SI_* paramters to DECLARE_MODULE() are now honored >>>> >> > in >>>> >> > the >>>> >> > same >>>> >> > order they would be for SYSUNINIT() for the MOD_QUIESCE and >>> MOD_UNLOAD >>>> >> > events. >>>> >> > >>>> >> > MFC after: 1 month >>>> >> > >>>> >> > -- >>>> >> > John Baldwin >>>> >> > >>>> >> >>>> >> Yes it works, I tried hard multiple times kldload/kldunload >>>> >> {libiconv,cd9660,cd9660_iconv in various order} to livelock/panic it, >>>> >> but without success. >>>> >> >>>> >> FYI following LORs happened: >>>> >> >>>> >> lock order reversal: >>>> >> 1st 0xc4322ce8 isofs (isofs) @ /usr/src/sys/kern/vfs_lookup.c:442 >>>> >> 2nd 0xd7d8d740 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 >>>> >> 3rd 0xc4322bdc isofs (isofs) @ >>>> >> /usr/src/sys/modules/cd9660/../../fs/cd9660/cd9660_vfsops.c:694 >>>> > >>>> > This LOR should be addressed in the latest cd9660 locking patches. >>>> > >>>> > -- >>>> > John Baldwin >>>> > >>>> >>>> Oh, why I did not checked new version? >>>> >>>> Yes that LOR have gone, but when doing "ll -R" first time on /mnt >>>> I got following messages from kernel: >>>> >>>> RRIP without PX field? x ~ 50 times. >>>> >>>> I see you changed LK_EXCLUSIVE to flags, and with MPSAFE .... >>> >>> The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >>> lock. >>> It could be a property of the ISO image. "PX" holds permissions (owner, >>> etc.). Do you get the same messages w/o the patch with the same ISO >>> image >>> / >>> CD? >>> >>> -- >>> John Baldwin >>> >> >> No I do not, but I may try other CDs I have many of them, including >> FreeBSD > s/Yes I do. Its to late here ... Ignore that reply. cd9660.ko without patch doesnt have this issue. cd9660.ko with cd9660_mpsafe.patch have this issue, on every CD I tried. -- Paul From jackie at boolome.com Tue Dec 9 16:38:43 2008 From: jackie at boolome.com (boolome) Date: Tue Dec 9 16:38:50 2008 Subject: make buildworld failed! In-Reply-To: <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> Message-ID: <1228869506.1255.3.camel@www.boolome.cn> ? 2008-12-09?? 03:18 -0800?Garrett Cooper??? > On Dec 8, 2008, at 5:48 PM, boolome wrote: > > > ? 2008-12-08?? 01:55 -0800?Garrett Cooper??? > >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: > >> [snip] > >> > >> Looks like your source tree is incomplete. > >> -Garrett > > > > But have cvsup the latest source tree ! > > It's not necessarily your fault though. What cvsup server are you > using and did you interrupt it during an update? > -Garrett The cvsup server is cvsup.freebsd.org . During an update ,I did not interrupt it. But when I got to that dir executed :make obj && make depend && make ,successed.. Is the soure tree's problem ? By the way I 'am using a custom kernel . From mike at jellydonut.org Tue Dec 9 22:11:56 2008 From: mike at jellydonut.org (Michael Proto) Date: Tue Dec 9 22:12:03 2008 Subject: behavioral change of "read" builtin for sh on 8-CURRENT Message-ID: <1de79840812092149t4d212027o2c908635419fa838@mail.gmail.com> I've noticed a behavioral difference of the "read" builtin statement within /bin/sh on CURRENT and I'm hoping someone can point me in the right direction on how to restore the old behavior. I have a /bin/sh script that accepts input for IP address information: #!/bin/sh set -x DEFINT=vr0 DEFIP=192.168.0.1 DEFMASK=255.255.255.0 read -p "Enter network interface [$DEFINT]: " -t 5 INT read -p "Enter IP address [$DEFIP]: " -t 5 IP read -p "Enter netmask [$DEFMASK]: " -t 5 MASK echo ${INT:=$DEFINT} : ${IP:=$DEFIP}/${MASK:=$DEFMASK} This script waits for terminal input for each of the above variables (INT, IP, MASK) and defaults to a script-provided value if no input is entered in 5 seconds for each variable. On 6.x and 7.x if I simply hit Enter at the prompt (and don't provide any input) no value is assigned to the variable so my INT, IP, and MASK variables are set to null and the parameter substitution of the DEF* variables works as expected. On 8-CURRENT if I hit Enter with no input at the prompt the system seems to recognize the newline as input and continues to sit there until I hit Enter again. When I do this there appears to be a strange unprintable value assigned to the INT, IP, and MASK variables yet the variable subsitution doesn't work correctly. The man page on sh lists the following behavior for read: read [-p prompt] [-t timeout] [-er] variable ... The prompt is printed if the -p option is specified and the stan- dard input is a terminal. Then a line is read from the standard input. The trailing newline is deleted from the line and the line is split as described in the section on White Space Splitting (Field Splitting) above, and the pieces are assigned to the variables in order. If there are more pieces than variables, the remaining pieces (along with the characters in IFS that sepa- rated them) are assigned to the last variable. If there are more variables than pieces, the remaining variables are assigned the null string. As I interpret this, read should delete the trailing newline and assign a null value since there is is no "input" before the newline. Then the variable substitution should take over and assign the DEF* variables appropriately. 6 and 7 follow this but 8 does not. Here's the output of the script (with set -x) to help show what I'm seeing. This is on 6 and 7: + DEFINT=vr0 + DEFIP=192.168.0.1 + DEFMASK=255.255.255.0 + read -p Enter network interface [vr0]: -t 5 INT Enter network interface [vr0]: + read -p Enter IP address [192.168.0.1]: -t 5 IP Enter IP address [192.168.0.1]: + read -p Enter netmask [255.255.255.0]: -t 5 MASK Enter netmask [255.255.255.0]: + echo vr0 : 192.168.0.1/255.255.255.0 vr0 : 192.168.0.1/255.255.255.0 And this is what I see with 8: + DEFINT=vr0 + DEFIP=192.168.0.1 + DEFMASK=255.255.255.0 + read -p Enter network interface [vr0]: -t 5 INT Enter network interface [vr0]: + read -p Enter IP address [192.168.0.1]: -t 5 IP Enter IP address [192.168.0.1]: + read -p Enter netmask [255.255.255.0]: -t 5 MASK Enter netmask [255.255.255.0]: /: cho /: Strange that the "echo" statement is missing the first "e" character in the debug output. Even stranger on 8-CURRENT, if I *do* enter input before the newline (say I change the IP address or the network interface), the first character is not echoed back to the screen but is still saved to the variable. Here's an example when I run the script and provide input at each prompt: + DEFINT=vr0 + DEFIP=192.168.0.1 + DEFMASK=255.255.255.0 + read -p Enter network interface [vr0]: -t 5 INT Enter network interface [vr0]: r0 + read -p Enter IP address [192.168.0.1]: -t 5 IP Enter IP address [192.168.0.1]: 92.168.0.1 + read -p Enter netmask [255.255.255.0]: -t 5 MASK Enter netmask [255.255.255.0]: 55.255.255.0 + echo br0 : 192.168.0.1/255.255.255.0 br0 : 192.168.0.1/255.255.255.0 + echo ifconfig br0 inet 192.168.0.1 netmask 255.255.255.0 Notice that when I'm prompted, the first character doesn't echo but is still saved in the variable. Does anyone else see this same behavior? Any ideas on how to reset it back to how it works in STABLE? I'm not doing anything special with IFS so I'm stumped on how to troubleshoot this. Thanks, Proto From qingli at FreeBSD.org Tue Dec 9 23:40:53 2008 From: qingli at FreeBSD.org (Qing Li) Date: Tue Dec 9 23:41:05 2008 Subject: last call for L2/L3 rewrite code review Message-ID: <200812100740.mBA7eqjO034924@freefall.freebsd.org> As you know the L2+L3 rewrite project (aka arp-v2) for both ARP and ND6 has been active for quite some time now. In a nutshell, the work removes the L2 tables (ARP and ND6) from the L3 routing table. This redesign simplifies the routing code and completely eliminates the route cloning concept. I discussed about this work at BSDCan 2007 and again at the recent devsummit at Google. I have requested code review and feedback since last May. It's becoming increasingly difficult to maintain a separate branch (p4 or svn) due to the high volume of new features' related commits. The integration and unit testing efforts increase in complexity by the week. We (Julian, Sam, Kip, Robert and I) discussed about a possible commit timeframe during the devsummit. And it seems now is as good as any because we all have overcommitted ourselves, and frankly speaking unless the feature is fully committed, getting the thorough code review and broader testing is simply unrealistic. I have been running the new arp-v2 kernel as a regular production machine on a daily basis, however, I am certain my testing is insufficient, which is another good reason to get the feature into the official -current tree. Putting a closure on this work will allow me to focus on developing additional networking features and completing my other backlog tasks for the project. Although the code will continue to evolve, on the other hand, the code is stable enough that I believe it is ready for general (-CURRENT) consumption. I would like to commit the code within a week if not sooner. Again, I would like to ask for your review and feedback. Flaming is fine, which I prefer getting the flames now rather than later. Quite a few developers have contributed to this project in the past: Glebius Smirnoff, Luigi Rizzo, Alessandro Cerri, and Andre Oppermann. And most recently: - Kip Macy revised the locking code completely, thus completing the last piece of the puzzle, Kip has also been conducting active functional testing - Sam Leffler has helped me improving/refactoring the code, and provided valuable reviews - Julian Elischer setup the perforce tree for me and has helped me maintaining that branch The latest patch that is generated out of Perforce without Kip Macy's locking modification is at http://people.freebsd.org/~qingli/arp-v2-p4-diff The complete P4 project tree is located at //depot/projects/arp-v2 The full project sits in the svn branch that is located at svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 Once this code is fully committed into -CURRENT, I will be on standby to fix any arp/nd6 related bugs. Kip Macy will be on standby to fix any locking related issues. Kip will also be acting as my backup when I'd be out partying. Thanks, -- Qing mailto: qingli@freebsd.org From rea-fbsd at codelabs.ru Tue Dec 9 23:55:55 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Dec 9 23:56:03 2008 Subject: Why does host and dig show a ; as \;? In-Reply-To: References: <004901c95a1c$5c6b2680$15417380$@org> <493ECA0D.7090901@andric.com> Message-ID: Larry, good day. Tue, Dec 09, 2008 at 01:49:27PM -0600, Larry Rosenman wrote: > On Tue, 9 Dec 2008, Dimitry Andric wrote: > > On 2008-12-09 17:36, Larry Rosenman wrote: > >> Why does the host command, dig, and a named_db.dump all show a ; as \; in a > >> TXT record? > > > > AFAICS the semicolon is a comment character in BIND software (at least > > in all config files and so on), and therefore it needs to be escaped. It doesn't need to be escaped inside strings themselves, at least there is no reason to have comments inside strings and BIND itself treats ';' inside strings as ordinary characters. But BIND's internal helper txt_totext does the escaping: ----- lib/dns/rdata.c /* double quote, semi-colon, backslash */ if (*sp == 0x22 || *sp == 0x3b || *sp == 0x5c) { if (tl < 2) return (ISC_R_NOSPACE); *tp++ = '\\'; tl--; } ----- And BIND understands both escaped and unescaped semicolons inside strings in zone files -- it treats both of them in a same way. I don't have access to BIND's CVSWeb interface, so I can not trace the origin of semicolon escaping, but I feel that historically BIND treated semicolons inside strings as the plain symbols and this remained so to be backwards-compatible. And escaping in the BIND's output is the stricter form of string formatting. However, for example, our Russian TLD registrars are suggesting to avoid escapes inside strings if it is possible. Don't know why -- it is just a recipe without explanation. I am CC'ing Doug Barton, who maintains BIND for FreeBSD. Doug, is there any requirement for escaping the semicolons inside strings? I am failing to find it in http://www.ietf.org/rfc/rfc1035.txt: it talks about semicolons, but not about escaping and there seems to be no proper BNF notation for DNS zone files. Am I missing something? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081210/36c2a9a3/attachment.pgp From dfr at rabson.org Wed Dec 10 00:29:01 2008 From: dfr at rabson.org (Doug Rabson) Date: Wed Dec 10 00:29:09 2008 Subject: Problems with zfsboot loader if raidz present on any drive In-Reply-To: References: <200812070319.18461.ken@mthelicon.com><66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> <200812071217.20500.ken@mthelicon.com> Message-ID: On 9 Dec 2008, at 23:54, Paul Wootton wrote: >> -----Original Message----- >> From: owner-freebsd-hackers@freebsd.org >> [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Pegasus Mc >> Cleaft >> Sent: 07 December 2008 12:17 >> To: Doug Rabson >> Cc: hackers@freebsd.org; current@freebsd.org >> Subject: Re: Problems with zfsboot loader if raidz present on any >> drive >> >> On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: >> On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: >>>> Hello Hackers, >>>> >>>> Recently and friend and I have been trying to get the new >>>> gptzfsboot working on our machines and ran into a interesting >>>> problem. >>>> >>>> Initially I was building the world without the environment >>>> variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of >>>> course, didnt work very well. Every time the machine booted, it >>>> would throw 2 lines after the pin-wheel and then reboot. I >>>> couldent read what the lines were it went so fast. >>>> >>>> My friend had a bit more luck and got his machine working OK with >>>> a single drive and later a mirror drive added. >>>> >>>> I added the environment variable and rebuilt everything and >>>> installed. This time, I could see the bios drives and a further 2 >>>> lines of ZFS something and a reboot... >>>> >>>> No matter what I tried, I couldent get the machine to boot up to >>>> a point where I could try and fix the problem, so I started >>>> pulling devices out and found the following: If there is a raidz >>>> pool on any drive (not necessarily the one that you are trying to >>>> boot from) the loader dies and reboots the machine. My friend, as >>>> an experiment created 3 gpt partitions (in addition to the single >>>> partition that he had been previously booted from) on his single >>>> drive and made a raidz pool for testing. His machine showed the >>>> same condition as mine, however he was able to capture the message >>>> before the machine >>>> rebooted: >>>> >>>> >>>> ZFS: can only boot from disk or mirror vdevs >>>> >>>> ZFS: inconsistent nvlist contents >>> >>> The zfsboot code in current doesn't support raidz or raidz2. I have >>> been working on adding that support but its not ready yet. The code >>> works in my test harness but crashes instantly when I put it in the >>> boot code :(. I should have time to finish debugging it soon. >> >> Hi Doug, >> >> In my haste to put a message to the group, I didnt do a very good > job >> of explaining or give what platform I was working with. >> >> I set up a single disk pool with the gptzfsboot code on it as a boot > drive. >> My idea was to have a single disk boot (and after it boots and I can >> kill the UFS drive I am currently booting from) convert it to a >> mirror. But I have 6 other drives in the machine that I have as a >> raidz > for my /usr/home, et al. >> >> If the 6 raidz drives are present at boot time, the machine starts > to >> cyclic reboot just after the pin-wheel. >> >> The machine I am working on is running FBSD8.0-Current as of > midnight >> 7/12/2008 and the platform is AMD64. >> >> If I can help test in any way I would be more than happy to try, or >> provide any information necessary.. >> >> ~Peg > > Hi Doug, > I was working with Peg on this over the weekend. > I think I have a patch for this - see > http://www.freebsd.org/cgi/query-pr.cgi?pr=129539 > The problem was that we were not checking the return code from > vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c > > > Joao, > Do you want to try the attached patch? It seems to have fixed the > problem, > at least on mine and Peg's machine. This looks like the right fix. I will commit something similar to this today. From bzeeb-lists at lists.zabbadoz.net Wed Dec 10 01:28:48 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Dec 10 01:28:55 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <200812100740.mBA7eqjO034924@freefall.freebsd.org> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> Message-ID: <20081210090429.G97918@maildrop.int.zabbadoz.net> On Wed, 10 Dec 2008, Qing Li wrote: Hi, > It's becoming increasingly difficult to maintain a separate > branch (p4 or svn) due to the high volume of new features' > related commits. The integration and unit testing efforts > increase in complexity by the week. [..] > I would like to commit the code within > a week if not sooner. I think waiting another few days would be good, so end of the weekend or something seems realistic, but not so before. The reason I am asking is that people are still seeing panics from the rnh locking and aren't even able to boot machines. Mixng route locking bugs with this rewrite will be painful. As I hope that the rnh bugs will be solved within 2-3 days things would be good for getting this monster in:) > The complete P4 project tree is located at > > //depot/projects/arp-v2 > > The full project sits in the svn branch that is located at > > svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 Which of the two is the one to track the next days or are you going to keep them in sync? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From kmacy at freebsd.org Wed Dec 10 01:30:36 2008 From: kmacy at freebsd.org (Kip Macy) Date: Wed Dec 10 01:30:48 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <20081210090429.G97918@maildrop.int.zabbadoz.net> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <20081210090429.G97918@maildrop.int.zabbadoz.net> Message-ID: <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> > The reason I am asking is that people are still seeing panics from > the rnh locking and aren't even able to boot machines. I have not seen this. Please tell me where this occurs. > Mixng route > locking bugs with this rewrite will be painful. As I hope that the > rnh bugs will be solved within 2-3 days things would be good for > getting this monster in:) To the best of my knowledge, the few bugs that have occurred have been fixed within a day of them being reported. >> svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 > > Which of the two is the one to track the next days or are you going to > keep them in sync? > The svn branch will be the one that is kept up to date with all fixes. I will be IFC'ing in to it once a day. Thanks, Kip From james-freebsd-current at jrv.org Wed Dec 10 01:53:52 2008 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Wed Dec 10 01:54:05 2008 Subject: Is FreeBSD -CURRENT sata port multiplier support functional yet? Message-ID: <493F887D.7000705@jrv.org> Is FreeBSD -CURRENT sata port multiplier support functional yet? I just tried the 8.0-CURRENT-200812-amd64-dvd1.iso snapshot on a Dell 435MT (Core i7) with a generic Silicon Image 3132 card (three different cards actually) and two Sans Digital eSATA enclosures that were tested to work OK with a Macintosh before & after the FreeBSD test. It appears the port multiplier is detected but that FreeBSD is not able to probe the disks behind the port multiplier. ata2 below has the port multiplier enclosure attached. There are disks in the 0 and 1 slots in the enclosure. The disk in slot 0 is detected by the 3132 option ROM. The enclosure and all slots work fine on a Macintosh with the Silicon Image drivers. The boot disk on ata4 is on an Intel chip. atapci0: port 0xcc00-0xcc7f mem 0xfbcffc00-0xfbcffc7f,0xfbcf8000-0xfbcfbfff irq 16 at device 0.0 on pci2 atapci0: Reserved 0x80 bytes for rid 0x20 type 4 at 0xcc00 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x80 bytes for rid 0x10 type 3 at 0xfbcffc00 atapci0: Reserved 0x4000 bytes for rid 0x18 type 3 at 0xfbcf8000 ata2: on atapci0 ata2: channel HW reset timeout ata2: SATA connect status=00000000 ata2: phy reset found no device ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: channel HW reset timeout ata3: SATA connect status=00000000 ata3: phy reset found no device ata3: [MPSAFE] ata3: [ITHREAD] ... ata2: identify ch->devices=00000000 ata3: identify ch->devices=00000000 ata4: identify ch->devices=00000001 firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ata2: CONNECT requested ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 476940MB at ata4-master SATA300 ad8: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad8 spa_config_load:92[1]: Cannot open /boot/zfs/zpool.cache. ZFS filesystem version 13 zvol_init:1167[1]: ZVOL Initialized. ZFS storage pool version 13 ata2: CONNECTED ata2: channel HW reset time=0ms ata2: SATA connect time=0ms ata2: siiprb_issue_cmd time=530ms status=00050000 ata2: SIGNATURE=96690101 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: SiI 3726 r1706 Portmultiplier with 5 ports ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: p0: connect time 0ms ata2: siiprb_issue_cmd time=0ms status=00010000 ata2: p0: SIGNATURE=ffffffff ata2: error writing PM port ata2: p1: writing ATA_SC_DET_RESET failed ata2: error writing PM port ata2: p2: writing ATA_SC_DET_RESET failed ata2: error writing PM port ata2: p3: writing ATA_SC_DET_RESET failed ata2: error writing PM port ata2: p4: writing ATA_SC_DET_RESET failed ata2: siiprb_reset devices=00008000 ata2: identify ch->devices=00008000 (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ad8: Intel check1 failed From elias at artx.ru Wed Dec 10 02:19:36 2008 From: elias at artx.ru (Ilya Orehov) Date: Wed Dec 10 02:19:44 2008 Subject: "interrupt storm..."; seems associated with an0 NIC In-Reply-To: <20081209.141616.2139790010.imp@bsdimp.com> References: <20081209192439.GA16703@artx.ru> <20081209.124743.-201314317.imp@bsdimp.com> <20081209204404.GA17018@artx.ru> <20081209.141616.2139790010.imp@bsdimp.com> Message-ID: <20081210101933.GA19248@artx.ru> +------- M. Warner Losh, 2008-12-09 ------- | Thanks! This helps a lot. The fact that xl works also is an | important hint for me for another problem I'm chasing... | | does this patch cause the printfs we've added to not be hit? With patch printf still hit, but in different places, and mask is different now: 6 during startup (later then without patch), and 0 or 6 after card insertion. Tried (insert/eject) several times, sequence hardly repeatable, but maybe it depends on timings : if card inserted quickly after eject, mask=0. That puzzled me, so I went to single user. In single user, if rebooted without card: card inserted -> no message, card ejected -> "Need to ack 0x1, mask=00000006" In single user too: card inserted -> no message, IP set with ifconfig xl0 -> "Need to ack 0x1, mask=00000006" card ejected -> no message Then i reverted patch to check in single user: Reboot without card, single user. Card inserted -> "Need to ack 0x1, mask=00000001" IP set with ifconfig -> no message card ejected -> no message Reboot with card, Card initialized -> "Need to ack 0x1, mask=00000007" regards, Ilya. | | Warner | | Index: pccbb.c | =================================================================== | --- pccbb.c (revision 185750) | +++ pccbb.c (working copy) | @@ -514,7 +514,7 @@ | * a chance to run. | */ | mtx_lock(&sc->mtx); | - cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD | CBB_SOCKET_MASK_CSTS); | + cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD); | msleep(&sc->intrhand, &sc->mtx, 0, "-", 0); | err = 0; | while (err != EWOULDBLOCK && | | | In message: <20081209204404.GA17018@artx.ru> | Ilya Orehov writes: | : +------- M. Warner Losh, 2008-12-09 ------- | : | In message: <20081209192439.GA16703@artx.ru> | : | Ilya Orehov writes: | : | : Need to ack 0x1 | : | | : | What happens if you also print the current mask register? CBB_SOCKET_MASK? | : | : Rebooted with xl0 card inserted, | : first time (after initialization) mask=7, | : after eject/insert xl0 mask=1. | : | : ... | : xl0: Ethernet address: 00:60:08:d2:38:56 | : xl0: [ITHREAD] | : Need to ack 0x1, mask=00000007 | : acd0: CDROM at ata1-master PIO4 | : Trying to mount root from ufs:/dev/ad0s2a | : WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() | : xl0: reset didn't complete | : xl0: command never completed! | : xl0: command never completed! | : xl0: command never completed! | : tdkphy0: detached | : miibus0: detached | : xl0: detached | : Need to ack 0x1, mask=00000001 | : xl0: <3Com 3c575TX Fast Etherlink XL> port 0x1000-0x103f irq 11 at device 0.0 on cardbus1 | : miibus0: on xl0 | : ... | : | : Rebooted once more, without card. | : After card (xl0) inserted, mask=1. | : | : Rebooted with same card inserted in second slot. | : First time (after initialization) mask=7, | : after eject/insert into same slot xl0 mask=1, | : after eject card was inserted into first slot, mask=1, | : | : code was: | : if (!ack) { | : mask = cbb_get(sc, CBB_SOCKET_MASK); | : printf("Need to ack %#x, mask=%08x\n", sockevent, mask); | : cbb_set(sc, CBB_SOCKET_EVENT, sockevent); | : } | : | : regards, | : Ilya. | : | : | : | | : | Warner | : | | : +----------------------------- | : | : | +----------------------------- From zec at icir.org Wed Dec 10 02:21:20 2008 From: zec at icir.org (Marko Zec) Date: Wed Dec 10 02:21:36 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> <20081210090429.G97918@maildrop.int.zabbadoz.net> <3c1674c90812100130y5433403akc68f72a5086b921c@mail.gmail.com> Message-ID: <200812101109.14851.zec@icir.org> On Wednesday 10 December 2008 10:30:35 Kip Macy wrote: > > The reason I am asking is that people are still seeing panics from > > the rnh locking and aren't even able to boot machines. > > I have not seen this. Please tell me where this occurs. I had a machine with defaultrouter from /etc/rc.conf pointing to a gateway which wasn't directly reachable, so the machine would panic before going multiuser. Nevertheless I can confirm that your change 185849 just resolved this issue, thanks a lot for a quick fix! Marko > > Mixng route > > locking bugs with this rewrite will be painful. As I hope that the > > rnh bugs will be solved within 2-3 days things would be good for > > getting this monster in:) > > To the best of my knowledge, the few bugs that have occurred have > been fixed within a day of them being reported. > > >> svn+ssh://svn.freebsd.org/base/projects/arpv2_merge_1 > > > > Which of the two is the one to track the next days or are you going > > to keep them in sync? > > The svn branch will be the one that is kept up to date with all > fixes. I will be IFC'ing in to it once a day. > > Thanks, > Kip > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" From sos at freebsd.org Wed Dec 10 02:44:32 2008 From: sos at freebsd.org (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Wed Dec 10 02:44:46 2008 Subject: Is FreeBSD -CURRENT sata port multiplier support functional yet? In-Reply-To: <493F887D.7000705@jrv.org> References: <493F887D.7000705@jrv.org> Message-ID: <226981FE-F27C-4C5F-8112-90213E45E99A@freebsd.org> On 10Dec, 2008, at 10:14 , James R. Van Artsdalen wrote: > Is FreeBSD -CURRENT sata port multiplier support functional yet? > > I just tried the 8.0-CURRENT-200812-amd64-dvd1.iso snapshot on a Dell > 435MT (Core i7) with a generic Silicon Image 3132 card (three > different > cards actually) and two Sans Digital eSATA enclosures that were tested > to work OK with a Macintosh before & after the FreeBSD test. > > It appears the port multiplier is detected but that FreeBSD is not > able > to probe the disks behind the port multiplier. I works in some setups but not all, seems PM's even with the same ID and revision are not created equal, so we still have the fine mess to find out things as we did in the old days. I have a setup with SiI chips that works with one PM but fails on 2 others, all three PM's use the same chip (ID and rev), go figure :) I'll get it fixed eventually, but spare time is sparse -S?ren From sos at freebsd.org Wed Dec 10 02:44:34 2008 From: sos at freebsd.org (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Wed Dec 10 02:44:46 2008 Subject: i give up In-Reply-To: <20081206190754.6c2bbd70@serene.no-ip.org> References: <20081128234155.0221e263@serene.no-ip.org> <4930D7CE.4080909@psg.com> <20081202220643.72eb52a3@serene.no-ip.org> <20081203151537.GA1045@phenom.cordula.ws> <20081206190754.6c2bbd70@serene.no-ip.org> Message-ID: <237FB18B-DACD-45F9-85DF-E214A33FDE5F@freebsd.org> On 7Dec, 2008, at 2:07 , Conrad J. Sabatier wrote: > > As another poster suggested, it's possible there's a bug/typo in the > patches Soren sent me, although they all apply quite cleanly to every > successive version of current I've tried them on. So...I'm at a loss > at this point. It really is frustrating. > In fact it seems there is a typo in that patch, you need to use the ATA_NFORCE_MCP77_A8 device ID instead of the ATA_NFORCE_MCP77_A1 in the patch to match your HW. However, you should have been able to tell that pretty quickly by looking at the ID's you sent back when and the patch ;) Anyhow there is just that much I can do in situations like this, I only have limitted time and cannot possibly attend to all the problems I get in my inbox in a timely manner, sorry. "life sucks - and then you die" -S?ren From channa.kad at gmail.com Wed Dec 10 04:16:16 2008 From: channa.kad at gmail.com (Channa) Date: Wed Dec 10 04:16:23 2008 Subject: jtmalloc performance Vs ptmalloc Message-ID: <515c64960812100416x306eacbdic3872bc8bc2244b7@mail.gmail.com> Hi, I tried to execute the benchmark test malloc-test to compare the ptmalloc performance and jemalloc performance. jemalloc seems to performance better than ptmalloc under following conditions. - If memory requests are less than 3840Bytes jemalloc is faster than ptmalloc Jemalloc: # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread -1086325424 adjusted timing: 0.893323 seconds for 10000000 requests of 1024 bytes. Thread -1090519728 adjusted timing: 0.893581 seconds for 10000000 requests of 1024 bytes. Thread -1082131120 adjusted timing: 0.983221 seconds for 10000000 requests of 1024 bytes. Thread -1088422576 adjusted timing: 1.346636 seconds for 10000000 requests of 1024 bytes. Thread -1084228272 adjusted timing: 1.394940 seconds for 10000000 requests of 1024 bytes. Ptmalloc: # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread -1208353904 adjusted timing: 2.427992 seconds for 10000000 requests of 1024 bytes. Thread -1239823472 adjusted timing: 2.474918 seconds for 10000000 requests of 1024 bytes. Thread -1218843760 adjusted timing: 2.394854 seconds for 10000000 requests of 1024 bytes. Thread -1250313328 adjusted timing: 3.695654 seconds for 10000000 requests of 1024 bytes. Thread -1229333616 adjusted timing: 5.081604 seconds for 10000000 requests of 1024 bytes. - If memory requests are page aligned i.e large allocations jemalloc is slower than ptmalloc. jemalloc: # ./malloc-test 9300 10000000 5 Starting test with 5 threads... Thread -1077936816 adjusted timing: 4.648531 seconds for 10000000 requests of 9300 bytes. Thread -1086325424 adjusted timing: 4.837230 seconds for 10000000 requests of 9300 bytes. Thread -1080033968 adjusted timing: 4.978933 seconds for 10000000 requests of 9300 bytes. Thread -1084228272 adjusted timing: 7.029323 seconds for 10000000 requests of 9300 bytes. Thread -1082131120 adjusted timing: 7.075402 seconds for 10000000 requests of 9300 bytes. Ptmalloc: # ./malloc-test_glib 9300 10000000 5 Starting test with 5 threads... Thread -1229083760 adjusted timing: 2.860437 seconds for 10000000 requests of 9300 bytes. Thread -1250063472 adjusted timing: 3.254859 seconds for 10000000 requests of 9300 bytes. Thread -1218593904 adjusted timing: 4.334052 seconds for 10000000 requests of 9300 bytes. Thread -1208104048 adjusted timing: 4.139268 seconds for 10000000 requests of 9300 bytes. Thread -1239573616 adjusted timing: 5.396595 seconds for 10000000 requests of 9300 bytes. So jemalloc takes more time for Large allocations than ptmalloc. For Huge allocations freater than 1MB again jemalloc is faster than ptmalloc. i tested this on 4 CPU intel x86 machine. Could you please tell me if there is any method to increase the performance for Large allocations.? I tried to increase the bins by setting the PAGE_SHIFT to 13 that time the performance of jemalloc was better for allocations till 7936. As per my analysis using bins for all allocations less than 1MB reduces the time taken but which may not be correct. I am trying to modify the Large allocations to increase the performance, Could you suggest some ideas. Thanks in Advance, Channa From CQG00620 at nifty.ne.jp Wed Dec 10 04:56:28 2008 From: CQG00620 at nifty.ne.jp (WATANABE Kazuhiro) Date: Wed Dec 10 04:56:36 2008 Subject: [patch] de(4) has not worked on 8-current since Feb 13 Message-ID: <20081210125627.25732615CD@mail.asahi-net.or.jp> Hi, all. My de(4) NICs has not worked on 8-current since Feb 13. I've tried to checkout the 8-current source tree from the CVS repository with a number of "-D" options and re-compiled it. As a result a kernel which is made from sources with "cvs checkout -D '2008-02-12 00:00 UTC' src" works well with the de(4) NICs. But with '2008-02-13 00:00 UTC' and the later date, the kernel cannot send data from the NICs. Receiving data are fine. For example: $ scp other_host:/boot/kernel/kernel . Password: kernel 100% 4717KB 943.5KB/s 00:05 $ scp /boot/kernel/kernel other_host: Password: kernel 1% 192KB 0.0KB/s - stalled -^CKilled by signal 2. $ The latest 8-current has the same problem. And these NICs works well on 7.0-RELEASE. To resolve the problem, I have to restore a change which was commited to sys/i386/i386/busdma_machdep.c revision 1.91. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/busdma_machdep.c#rev1.91 Here is a patch. But I don't know the meaning of this :-( --- sys/i386/i386/busdma_machdep.c.orig 2008-12-08 20:33:16.000000000 +0900 +++ sys/i386/i386/busdma_machdep.c 2008-12-08 21:24:43.000000000 +0900 @@ -585,7 +585,7 @@ * Count the number of bounce pages * needed in order to complete this transfer */ - vaddr = (vm_offset_t)buf; + vaddr = trunc_page((vm_offset_t)buf); vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { @@ -594,7 +594,7 @@ run_filter(dmat, paddr) != 0) { map->pagesneeded++; } - vaddr += (PAGE_SIZE - ((vm_offset_t)vaddr & PAGE_MASK)); + vaddr += PAGE_SIZE; } CTR1(KTR_BUSDMA, "pagesneeded= %d\n", map->pagesneeded); } I've tested the patch on the latest 8-current with the following NICs. * SMC EtherPower10/100 $ uname -a FreeBSD aries.sign.local 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Tue Dec 9 15:03:24 JST 2008 nabe@capricorn:/FreeBSD/obj/pc98/HEAD/pc98/FreeBSD/HEAD/src/sys/LEFTEYE pc98 $ dmesg | grep '^de[0-9]' de0: port 0x6000-0x607f mem 0x20410000-0x2041007f irq 3 at device 13.0 on pci0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0 de0: WARNING: using obsoleted if_watchdog interface de0: Ethernet address: 00:00:c0:xx:xx:xx de0: [ITHREAD] * Corega FastEther PCI-TX $ uname -a FreeBSD scorpio.sign.local 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Tue Dec 9 15:01:10 JST 2008 nabe@capricorn:/FreeBSD/obj/i386/HEAD/FreeBSD/HEAD/src/sys/GENERIC i386 $ dmesg | grep '^de[0-9]' de0: port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 11 at device 15.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: WARNING: using obsoleted if_watchdog interface de0: Ethernet address: 00:00:f4:xx:xx:xx de0: [ITHREAD] --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From bsam at ipt.ru Wed Dec 10 05:47:37 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Dec 10 05:47:44 2008 Subject: Timeda 8-multiport adapter: only 2 ports available Message-ID: <92804393@bb.ipt.ru> Hi All, I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): ----- puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 vendor = 'Timedia Technology Co Ltd' device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' class = simple comms subclass = UART ----- Here is a verbose dmesg: ----- puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 puc0: [FILTER] uart4: <16550 or compatible> on puc0 uart4: [FILTER] uart4: fast interrupt uart5: <16550 or compatible> on puc0 uart5: [FILTER] uart5: fast interrupt ----- devinfo -rv: ----- pci5 puc0 pnpinfo vendor=0x1409 device=0x7168 subvendor=0x1409 subdevice=0x4066 class=0x070002 at slot=2 function=0 I/O ports: 0xe080-0xe087 0xe400-0xe407 0xe480-0xe487 0xe800-0xe807 0xe880-0xe88f 0xec00-0xec1f uart4 puc0 I/O port mapping: 60416-60423 puc0 port numbers: 1 uart5 puc0 I/O port mapping: 60424-60431 puc0 port numbers: 2 ----- The system: ----- FreeBSD host.ipt.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Fri Dec 5 14:58:48 MSK 2008 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST i386 ----- Well, I need other ports. SOS! ;-) WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From paul at fletchermoorland.co.uk Tue Dec 9 16:33:46 2008 From: paul at fletchermoorland.co.uk (Paul Wootton) Date: Wed Dec 10 06:03:57 2008 Subject: Problems with zfsboot loader if raidz present on any drive In-Reply-To: <200812071217.20500.ken@mthelicon.com> References: <200812070319.18461.ken@mthelicon.com><66BF33BA-EC11-446F-9DE7-15395F293FE2@rabson.org> <200812071217.20500.ken@mthelicon.com> Message-ID: >-----Original Message----- >From: owner-freebsd-hackers@freebsd.org >[mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Pegasus Mc >Cleaft >Sent: 07 December 2008 12:17 > To: Doug Rabson > Cc: hackers@freebsd.org; current@freebsd.org > Subject: Re: Problems with zfsboot loader if raidz present on any >drive > > On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: > On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: > > > Hello Hackers, > > > > > > Recently and friend and I have been trying to get the new > > > gptzfsboot working on our machines and ran into a interesting > > > problem. > > > > > > Initially I was building the world without the environment > > > variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of > > > course, didnt work very well. Every time the machine booted, it > > > would throw 2 lines after the pin-wheel and then reboot. I > > > couldent read what the lines were it went so fast. > > > > > > My friend had a bit more luck and got his machine working OK with > > > a single drive and later a mirror drive added. > > > > > > I added the environment variable and rebuilt everything and > > > installed. This time, I could see the bios drives and a further 2 > > > lines of ZFS something and a reboot... > > > > > > No matter what I tried, I couldent get the machine to boot up to > > > a point where I could try and fix the problem, so I started > > > pulling devices out and found the following: If there is a raidz > > > pool on any drive (not necessarily the one that you are trying to > > > boot from) the loader dies and reboots the machine. My friend, as > > > an experiment created 3 gpt partitions (in addition to the single > > > partition that he had been previously booted from) on his single > > > drive and made a raidz pool for testing. His machine showed the > > > same condition as mine, however he was able to capture the message > > > before the machine > > > rebooted: > > > > > > > > > ZFS: can only boot from disk or mirror vdevs > > > > > > ZFS: inconsistent nvlist contents > > > > The zfsboot code in current doesn't support raidz or raidz2. I have > > been working on adding that support but its not ready yet. The code > > works in my test harness but crashes instantly when I put it in the > > boot code :(. I should have time to finish debugging it soon. > > Hi Doug, > > In my haste to put a message to the group, I didnt do a very good job > of explaining or give what platform I was working with. > > I set up a single disk pool with the gptzfsboot code on it as a boot drive. > My idea was to have a single disk boot (and after it boots and I can > kill the UFS drive I am currently booting from) convert it to a > mirror. But I have 6 other drives in the machine that I have as a raidz for my /usr/home, et al. > > If the 6 raidz drives are present at boot time, the machine starts to > cyclic reboot just after the pin-wheel. > > The machine I am working on is running FBSD8.0-Current as of midnight > 7/12/2008 and the platform is AMD64. > > If I can help test in any way I would be more than happy to try, or > provide any information necessary.. > > ~Peg Hi Doug, I was working with Peg on this over the weekend. I think I have a patch for this - see http://www.freebsd.org/cgi/query-pr.cgi?pr=129539 The problem was that we were not checking the return code from vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c Joao, Do you want to try the attached patch? It seems to have fixed the problem, at least on mine and Peg's machine. Cheers Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: zfsimpl.c.patch Type: application/octet-stream Size: 792 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081210/a9fd1481/zfsimpl.c.obj From levitchd at insightbb.com Wed Dec 10 01:25:44 2008 From: levitchd at insightbb.com (Darrel) Date: Wed Dec 10 06:13:36 2008 Subject: $FreeBSD: www/en/handbook/Makefile,v 1.9 2002/06/27 19:55:40 nik Exp $ Message-ID: <493F84A4.1060103@insightbb.com> (66) @ 3:18:42> uname -a FreeBSD freebsd7.levitch.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Dec 7 16:19:00 EST 2008 darrel1@freebsd7.levitch.org:/usr/obj/usr/src/sys/D amd64 how to install /usr/doc and /usr/www on this local machine? packet filter is implemented on this network. sincerely, darrel From bsam at ipt.ru Wed Dec 10 06:13:50 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Dec 10 06:13:57 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <92804393@bb.ipt.ru> (Boris Samorodov's message of "Wed\, 10 Dec 2008 16\:47\:34 +0300") References: <92804393@bb.ipt.ru> Message-ID: <26722819@bb.ipt.ru> Boris Samorodov writes: > I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): > ----- > puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 > vendor = 'Timedia Technology Co Ltd' > device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' Actually the card is 4066, while 4037 (according to pucdata.c) is indeed a dual-port card. May be the card is wrongly interpreted by the OS? > class = simple comms > subclass = UART > ----- > > Here is a verbose dmesg: > ----- > puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 > puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 > puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 > puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 > puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 > puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 > puc0: [FILTER] > uart4: <16550 or compatible> on puc0 > uart4: [FILTER] > uart4: fast interrupt > uart5: <16550 or compatible> on puc0 > uart5: [FILTER] > uart5: fast interrupt > ----- > > devinfo -rv: > ----- > pci5 > puc0 pnpinfo vendor=0x1409 device=0x7168 subvendor=0x1409 subdevice=0x4066 class=0x070002 at slot=2 function=0 > I/O ports: > 0xe080-0xe087 > 0xe400-0xe407 > 0xe480-0xe487 > 0xe800-0xe807 > 0xe880-0xe88f > 0xec00-0xec1f > uart4 > puc0 I/O port mapping: > 60416-60423 > puc0 port numbers: > 1 > uart5 > puc0 I/O port mapping: > 60424-60431 > puc0 port numbers: > 2 > ----- > > The system: > ----- > FreeBSD host.ipt.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Fri Dec 5 14:58:48 MSK 2008 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST i386 > ----- > > Well, I need other ports. SOS! ;-) WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From rea-fbsd at codelabs.ru Wed Dec 10 07:38:03 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Dec 10 07:38:09 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <26722819@bb.ipt.ru> References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> Message-ID: Boris, good day. Wed, Dec 10, 2008 at 05:13:48PM +0300, Boris Samorodov wrote: > Boris Samorodov writes: > > > I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): > > ----- > > puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 > > vendor = 'Timedia Technology Co Ltd' > > device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' > > Actually the card is 4066, while 4037 (according to pucdata.c) is indeed > a dual-port card. May be the card is wrongly interpreted by the OS? pciconf just don't know about 4066, so is prints what it has in the database. This is irrelevant to the driver -- it discovers the correct chip with 8 ports: > > puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 > > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 > > puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 > > puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 > > puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 > > puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 > > puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 > > puc0: [FILTER] > > uart4: <16550 or compatible> on puc0 > > uart4: [FILTER] > > uart4: fast interrupt > > uart5: <16550 or compatible> on puc0 > > uart5: [FILTER] > > uart5: fast interrupt > > ----- Judging by this output, the 6 ports that got their reservations at dev/pci/pci.c are the ones that aren't recognized by uart. You may need to add trace printfs to uart_puc_probe (uart_bus_puc.c) and to uart_bus_probe (uart_core.c), just around the register resource allocator. This should show what devices are passed to the probe routines and which are rejected. Be sure to include 'rid' values to your debug output to get the idea what ports we're speaking about. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081210/45616414/attachment.pgp From bsam at ipt.ru Wed Dec 10 08:19:44 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Dec 10 08:19:52 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: (Eygene Ryabinkin's message of "Wed\, 10 Dec 2008 18\:38\:00 +0300") References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> Message-ID: <39207585@bb.ipt.ru> Hello Eygene, Eygene Ryabinkin writes: > Boris, good day. > Wed, Dec 10, 2008 at 05:13:48PM +0300, Boris Samorodov wrote: >> Boris Samorodov writes: >> >> > I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): >> > ----- >> > puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 >> > vendor = 'Timedia Technology Co Ltd' >> > device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' >> >> Actually the card is 4066, while 4037 (according to pucdata.c) is indeed >> a dual-port card. May be the card is wrongly interpreted by the OS? > > pciconf just don't know about 4066, so is prints what it has in the > database. This is irrelevant to the driver -- it discovers the correct > chip with 8 ports: > >> > puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 >> > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 >> > puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 >> > puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 >> > puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 >> > puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 >> > puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 >> > puc0: [FILTER] >> > uart4: <16550 or compatible> on puc0 >> > uart4: [FILTER] >> > uart4: fast interrupt >> > uart5: <16550 or compatible> on puc0 >> > uart5: [FILTER] >> > uart5: fast interrupt >> > ----- > > Judging by this output, the 6 ports that got their reservations at > dev/pci/pci.c are the ones that aren't recognized by uart. You may need Thanks for your explanation. > to add trace printfs to uart_puc_probe (uart_bus_puc.c) and to > uart_bus_probe (uart_core.c), just around the register resource > allocator. This should show what devices are passed to the probe > routines and which are rejected. Be sure to include 'rid' values to > your debug output to get the idea what ports we're speaking about. I wish I can. :-( Can you give me an example / forward to howto or like? Thanks. BTW, our mailservers don't like each other: ----- 2008-12-10 18:39:07 1LAR9W-000Ka0-VK H=0.mx.codelabs.ru [144.206.177.45] sender verify fail for : response to "MAIL FROM:<>" from 0.mx.codelabs.ru [144.206.177.45] was: 550 failed ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From rmacklem at uoguelph.ca Wed Dec 10 08:47:02 2008 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Wed Dec 10 08:47:14 2008 Subject: NFS (& amd?) dysfunction descending a hierarchy In-Reply-To: <20081209190110.GW60731@albert.catwhisker.org> References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> Message-ID: On Tue, 9 Dec 2008, David Wolfskill wrote: > On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote: >> I seem to have a fairly- (though not deterministly so) reproducible >> mode of failure with an NFS-mounted directory hierarchy: An attempt to >> traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm >> -fr") will fail to "visit" some subdirectories, typically apparently >> acting as if the subdirectories in question do not actually exist >> (despite the names having been returned in the output of a previous >> readdir()). >> ... > > I was able to reproduce the external symptoms of the failure running > CURRENT as of yesterday, using "rm -fr" of a copy of a recent > /usr/ports hierachy on an NFS-mounted file system as a test case. > However, I believe the mechanism may be a bit different -- while > still being other than what I would expect. > > One aspect in which the externally-observable symptoms were different > (under CURRENT, vs. RELENG_7) is that under CURRENT, once the error > condition occurred, the NFS client machine was in a state where it > merely kept repeating > > nfs server pid848@fbsd-build:/volume: not responding > > until I logged in as root & rebooted it. > The different behaviour for -CURRENT could be the newer RPC layer that was recently introduced, but that doesn't explain the basic problem. All I can think of is to ask the obvious question. "Are you using interruptible or soft mounts?" If so, switch to hard mounts and see if the problem goes away. (imho, neither interruptible nor soft mounts are a good idea. You can use a forced dismount if there is a crashed NFS server that isn't coming back anytime soon.) If you are getting this with hard mounts, I'm afraid I have no idea what the problem is, rick. From rdivacky at freebsd.org Wed Dec 10 08:48:34 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed Dec 10 08:48:42 2008 Subject: [PANIC]: rw_lock panic in in_pcballoc() in r185864 Message-ID: <20081210164345.GA32188@freebsd.org> Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1a4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0528cc9 stack pointer = 0x28:0xc3e77ba8 frame pointer = 0x28:0xc3e77bcc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 160 (ifconfig) Physical memory: 978 MB Dumping 46 MB: 31 15 Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel /snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/s ound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc045c834 in db_fncall (dummy1=-1008240272, dummy2=0, dummy3=0, dummy4=0xc3e7793c "\001") at ../../../ddb/db_command.c:548 #2 0xc045cbaf in db_command (last_cmdp=0xc076765c, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:445 #3 0xc045ce36 in db_command_loop () at ../../../ddb/db_command.c:498 #4 0xc045ec9f in db_trap (type=12, code=0) at ../../../ddb/db_main.c:229 #5 0xc055966a in kdb_trap (type=12, code=0, tf=0xc3e77b68) at ../../../kern/subr_kdb.c:534 #6 0xc06d7a1a in trap_fatal (frame=0xc3e77b68, eva=420) at ../../../i386/i386/trap.c:920 #7 0xc06d7daa in trap_pfault (frame=0xc3e77b68, usermode=0, eva=420) at ../../../i386/i386/trap.c:842 #8 0xc06d883c in trap (frame=0xc3e77b68) at ../../../i386/i386/trap.c:522 #9 0xc06bd28b in calltrap () at ../../../i386/i386/exception.s:165 #10 0xc0528cc9 in _rw_wlock_hard (rw=0xc45a00a4, tid=3293569600, file=0x0, line=0) at ../../../kern/kern_rwlock.c:616 #11 0xc05eae42 in in_pcballoc (so=0xc459e000, pcbinfo=0xc0794b40) at ../../../netinet/in_pcb.c:238 #12 0xc060b403 in udp_attach (so=0xc459e000, proto=0, td=0xc44fe240) at ../../../netinet/udp_usrreq.c:1131 #13 0xc0586df5 in socreate (dom=2, aso=0xc3e77c6c, type=2, proto=0, #14 0xc058d974 in socket (td=0xc44fe240, uap=0xc3e77cf8) ---Type to continue, or q to quit---Dec 10 17:29:23 witten log in: ROOT LOGIN (root) ON ttyv1 at ../../../kern/uipc_syscalls.c:178 #15 0xc06d8010 in syscall (frame=0xc3e77d38) at ../../../i386/i386/trap.c:1076 #16 0xc06bd320 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #17 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) p *pcbinfo $2 = {ipi_listhead = 0xc0794b24, ipi_count = 1, ipi_hashbase = 0xc42fe000, ipi_hashmask = 127, ipi_porthashbase = 0xc42fce00, ipi_porthashmask = 127, ipi_lastport = 0, ipi_lastlow = 0, ipi_lasthi = 0, ipi_zone = 0xc1471360, ipi_gencnt = 0, ipi_lock = {lock_object = {lo_name = 0xc0713b87 "udp", lo_flags = 69926928, lo_data = 0, lo_witness = 0x0}, rw_lock = 3293569600}, ipi_pspare = { (kgdb) p *pcbinfo->ipi_zone $4 = {uz_name = 0xc0716712 "udpcb", uz_lock = 0xc147ed88, uz_keg = 0xc147ed80, uz_link = {le_next = 0x0, le_prev = 0xc147eda8}, uz_full_bucket = {lh_first = 0x0}, uz_free_bucket = {lh_first = 0x0}, uz_ctor = 0, uz_dtor = 0, uz_init = 0, uz_fini = 0, uz_allocs = 0, uz_frees = 0, uz_fails = 0, uz_fills = 0, uz_count = 23, uz_cpu = {{ uc_freebucket = 0x0, uc_allocbucket = 0x0, uc_allocs = 0, uc_frees = 0}}} the code tries to rw_rwlock() the inp->inp_lock, the inp is allocated from an UMA zone which has no constructor and in the in_pcballoc() the rwlock is never initialized. I believe that's why it crashes can someone confirm/fix that? thnx roman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081210/f3db0fa7/attachment.pgp From david at catwhisker.org Wed Dec 10 08:50:23 2008 From: david at catwhisker.org (David Wolfskill) Date: Wed Dec 10 08:50:35 2008 Subject: NFS (& amd?) dysfunction descending a hierarchy In-Reply-To: References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> Message-ID: <20081210165022.GJ60731@albert.catwhisker.org> On Wed, Dec 10, 2008 at 11:30:26AM -0500, Rick Macklem wrote: >... > The different behaviour for -CURRENT could be the newer RPC layer that > was recently introduced, but that doesn't explain the basic problem. OK. > All I can think of is to ask the obvious question. "Are you using > interruptible or soft mounts?" If so, switch to hard mounts and see > if the problem goes away. (imho, neither interruptible nor soft mounts > are a good idea. You can use a forced dismount if there is a crashed > NFS server that isn't coming back anytime soon.) From examination of /etc/amd* -- I don't see how to get mount(8) or amq(8) to report it -- it appears that we are using interruptible mounts, as we always have. The point is that the behavior has changed in an unexpected way. And I'm not so sure that the use of a forced dismount is generally available, as it would require logging in to the NFS client first, which may be difficult if the NFS server hosting non-root home directories is failing to respond and direct root login via ssh(1) is not permitted (as is the default). > If you are getting this with hard mounts, I'm afraid I have no idea > what the problem is, rick. What concerns me is that even if the attempted unmount gets EBUSY, the user-level process descending the directory hierarchy is getting ENOENT trying to issue fstatfs() against an open file descriptor. I'm having trouble figuring out any way that makes any sense. Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081210/88a384f2/attachment.pgp From kostikbel at gmail.com Wed Dec 10 09:06:27 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Dec 10 09:06:42 2008 Subject: NFS (& amd?) dysfunction descending a hierarchy In-Reply-To: <20081210165022.GJ60731@albert.catwhisker.org> References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> <20081210165022.GJ60731@albert.catwhisker.org> Message-ID: <20081210170620.GS2038@deviant.kiev.zoral.com.ua> On Wed, Dec 10, 2008 at 08:50:22AM -0800, David Wolfskill wrote: > On Wed, Dec 10, 2008 at 11:30:26AM -0500, Rick Macklem wrote: > >... > > The different behaviour for -CURRENT could be the newer RPC layer that > > was recently introduced, but that doesn't explain the basic problem. > > OK. > > > All I can think of is to ask the obvious question. "Are you using > > interruptible or soft mounts?" If so, switch to hard mounts and see > > if the problem goes away. (imho, neither interruptible nor soft mounts > > are a good idea. You can use a forced dismount if there is a crashed > > NFS server that isn't coming back anytime soon.) > > From examination of /etc/amd* -- I don't see how to get mount(8) or > amq(8) to report it -- it appears that we are using interruptible > mounts, as we always have. > > The point is that the behavior has changed in an unexpected way. And > I'm not so sure that the use of a forced dismount is generally > available, as it would require logging in to the NFS client first, which > may be difficult if the NFS server hosting non-root home directories is > failing to respond and direct root login via ssh(1) is not permitted (as > is the default). > > > If you are getting this with hard mounts, I'm afraid I have no idea > > what the problem is, rick. > > What concerns me is that even if the attempted unmount gets EBUSY, the > user-level process descending the directory hierarchy is getting ENOENT > trying to issue fstatfs() against an open file descriptor. > > I'm having trouble figuring out any way that makes any sense. Basically, the problem is that NFS uses shared lookup, and this allows for the bug where several negative namecache entries are created for non-existent node. Then this node gets created, removing only the first negative namecache entry. For some reasons, vnode is reclaimed; amd' tasting of unmount is a good reason for vnode to be reclaimed. Now, you have existing path and a negative cache entry. This was reported by Peter Holm first, I listed relevant revisions that should fix this in previous mail. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081210/f50acb49/attachment.pgp From onemda at gmail.com Wed Dec 10 09:22:45 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Dec 10 09:22:52 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <200812091602.10850.jhb@freebsd.org> References: <200811191510.53793.jhb@FreeBSD.org> <200812051608.50120.jhb@freebsd.org> <3a142e750812051354n747bcbcayb31d8d5f4cc15098@mail.gmail.com> <200812091602.10850.jhb@freebsd.org> Message-ID: <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> On 12/9/08, John Baldwin wrote: > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive > lock. > It could be a property of the ISO image. "PX" holds permissions (owner, > etc.). Do you get the same messages w/o the patch with the same ISO image / > CD? > > -- > John Baldwin > I searched little for this message and found kern/63446 PR interesting comment: Caused by cd9660_vnops.c rev. 1.77. VOP_READDIR returns bogus d_fileno, VFS_VGET on this value returns bogus vnode with zeroed attributes. I think that whatever locking is done is done wrong. -- Paul From jhb at freebsd.org Wed Dec 10 10:53:26 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Dec 10 10:53:58 2008 Subject: Enhancing cdboot [patch for review] In-Reply-To: <20081208235119.GA46608@onelab2.iet.unipi.it> References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> Message-ID: <200812101331.24182.jhb@freebsd.org> On Monday 08 December 2008 06:51:19 pm Luigi Rizzo wrote: > On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: > > Hi, > > > > Below please find patch that enhances cdboot with two compile-time options: > ... > > Any comments/suggestions are appreciated. If there are no objections I > > would like to commit the change. The long-term goal is to make > > CDBOOT_PROMPT default mode for installation CD. > > > > http://sobomax.sippysoft.com/~sobomax/cdboot.diff > > Looks good. Some comments: > 1. since there is plenty of space in the cdboot sector, why don't you > make the two option always compiled in, controlling which one to > activate through flags in the bootsector itself, to be set > patching the binary sector itself using a mechanism similar to > boot0cfg. > Of course you cannot alter a cdrom after you burn it, > but it makes it easier to build CDs with one or the other defaults, > patching cdboot or the iso image itself before creating/burning it. I don't think this is very useful because CDs are read-only. You can just as easily build a different cdboot rather than having to write some custom cdbootcfg util to patch the binary. > 2. in fact, the 'silent' option could be disabled at runtime by > pressing some key (e.g. adding a short wait loop before proceeding; > if this is meant for custom, unattended CDs the extra delay should not > matter much); I don't imagine anyone will know to press a key to get verbose messages, and the CD boot process is quick enough you would have to add an artificial delay to it to allow for the keypress. > 3. one nitpick -- in one of the first chunks you replace $start > with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, > so why don't you always use the same ? No, because he relocates it, $start is now the relocated address, but the BIOS loads it at LOAD which is now != $start. > Also in terms of relocation size, wouldn't it be the case of > hardwiring the size of the cd boot sector: > > - mov $((end_init - start)/2),%cx > + mov 1024,%cx I prefer the existing code to make sure and copy the full boot loader, whatever it's size is. Maxim, My only comment is to please make the new block comment match the style of the existing block comments by having '#\n' lines before and after. -- John Baldwin From jhb at freebsd.org Wed Dec 10 10:53:26 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Dec 10 10:54:09 2008 Subject: Enhancing cdboot [patch for review] In-Reply-To: <20081208235119.GA46608@onelab2.iet.unipi.it> References: <493DA269.2070805@FreeBSD.org> <20081208235119.GA46608@onelab2.iet.unipi.it> Message-ID: <200812101331.24182.jhb@freebsd.org> On Monday 08 December 2008 06:51:19 pm Luigi Rizzo wrote: > On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: > > Hi, > > > > Below please find patch that enhances cdboot with two compile-time options: > ... > > Any comments/suggestions are appreciated. If there are no objections I > > would like to commit the change. The long-term goal is to make > > CDBOOT_PROMPT default mode for installation CD. > > > > http://sobomax.sippysoft.com/~sobomax/cdboot.diff > > Looks good. Some comments: > 1. since there is plenty of space in the cdboot sector, why don't you > make the two option always compiled in, controlling which one to > activate through flags in the bootsector itself, to be set > patching the binary sector itself using a mechanism similar to > boot0cfg. > Of course you cannot alter a cdrom after you burn it, > but it makes it easier to build CDs with one or the other defaults, > patching cdboot or the iso image itself before creating/burning it. I don't think this is very useful because CDs are read-only. You can just as easily build a different cdboot rather than having to write some custom cdbootcfg util to patch the binary. > 2. in fact, the 'silent' option could be disabled at runtime by > pressing some key (e.g. adding a short wait loop before proceeding; > if this is meant for custom, unattended CDs the extra delay should not > matter much); I don't imagine anyone will know to press a key to get verbose messages, and the CD boot process is quick enough you would have to add an artificial delay to it to allow for the keypress. > 3. one nitpick -- in one of the first chunks you replace $start > with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, > so why don't you always use the same ? No, because he relocates it, $start is now the relocated address, but the BIOS loads it at LOAD which is now != $start. > Also in terms of relocation size, wouldn't it be the case of > hardwiring the size of the cd boot sector: > > - mov $((end_init - start)/2),%cx > + mov 1024,%cx I prefer the existing code to make sure and copy the full boot loader, whatever it's size is. Maxim, My only comment is to please make the new block comment match the style of the existing block comments by having '#\n' lines before and after. -- John Baldwin From citrin at citrin.ru Wed Dec 10 10:58:42 2008 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Wed Dec 10 10:58:49 2008 Subject: svn commit: r185756 - head/sys/dev/re In-Reply-To: <200812080248.mB82mfV9043154@svn.freebsd.org> References: <200812080248.mB82mfV9043154@svn.freebsd.org> Message-ID: <4940115F.7080004@citrin.ru> Pyun YongHyeon wrote: > Author: yongari > Date: Mon Dec 8 02:48:41 2008 > New Revision: 185756 > URL: http://svn.freebsd.org/changeset/base/185756 > > Log: > Reduce spin wait time consumed in GMII register access routines. > Waiting for 1ms for each GMII register access looks overkill and it > may also decrease overall performance of driver because re(4) > invokes mii_tick for every hz. > > Tested by: rpaulo > > Modified: > head/sys/dev/re/if_re.c > > Modified: head/sys/dev/re/if_re.c > ============================================================================== > --- head/sys/dev/re/if_re.c Mon Dec 8 02:38:13 2008 (r185755) > +++ head/sys/dev/re/if_re.c Mon Dec 8 02:48:41 2008 (r185756) > @@ -417,13 +417,12 @@ re_gmii_readreg(device_t dev, int phy, i > } > > CSR_WRITE_4(sc, RL_PHYAR, reg << 16); > - DELAY(1000); > > for (i = 0; i < RL_TIMEOUT; i++) { > + DELAY(30); > rval = CSR_READ_4(sc, RL_PHYAR); > if (rval & RL_PHYAR_BUSY) > break; > - DELAY(100); > } > > if (i == RL_TIMEOUT) { > @@ -445,13 +444,12 @@ re_gmii_writereg(device_t dev, int phy, > > CSR_WRITE_4(sc, RL_PHYAR, (reg << 16) | > (data & RL_PHYAR_PHYDATA) | RL_PHYAR_BUSY); > - DELAY(1000); > > for (i = 0; i < RL_TIMEOUT; i++) { > + DELAY(30); > rval = CSR_READ_4(sc, RL_PHYAR); > if (!(rval & RL_PHYAR_BUSY)) > break; > - DELAY(100); > } > > if (i == RL_TIMEOUT) { After this commit I see in logs errors: Dec 10 21:37:42 citrin kernel: re0: PHY read failed Dec 10 21:38:05 citrin last message repeated 3 times Dec 10 21:38:44 citrin last message repeated 3 times Dec 10 21:38:44 citrin kernel: re0: link state changed to DOWN Dec 10 21:38:45 citrin kernel: re0: link state changed to UP Dec 10 21:38:55 citrin kernel: re0: PHY read failed Dec 10 21:39:38 citrin last message repeated 3 times Dec 10 21:39:38 citrin kernel: re0: link state changed to DOWN Dec 10 21:39:39 citrin kernel: re0: link state changed to UP Dec 10 21:40:09 citrin kernel: re0: PHY read failed Dec 10 21:40:21 citrin kernel: re0: PHY read failed Dec 10 21:41:03 citrin kernel: re0: PHY read failed I tried to revert this patch - errors disappeared. HW: re0@pci0:2:5:0: class=0x020000 card=0xe0001458 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 from dmesg: re0: port 0xa000-0xa0ff mem 0xe1000000-0xe10000ff irq 21 at device 5.0 on pci2 re0: Chip rev. 0x18000000 re0: MAC rev. 0x00000000 -- Anton Yuzhaninov From rwatson at FreeBSD.org Wed Dec 10 11:23:49 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Dec 10 11:23:56 2008 Subject: [PANIC]: rw_lock panic in in_pcballoc() in r185864 In-Reply-To: <20081210164345.GA32188@freebsd.org> References: <20081210164345.GA32188@freebsd.org> Message-ID: On Wed, 10 Dec 2008, Roman Divacky wrote: > #9 0xc06bd28b in calltrap () at ../../../i386/i386/exception.s:165 > #10 0xc0528cc9 in _rw_wlock_hard (rw=0xc45a00a4, tid=3293569600, file=0x0, > line=0) at ../../../kern/kern_rwlock.c:616 > #11 0xc05eae42 in in_pcballoc (so=0xc459e000, pcbinfo=0xc0794b40) > at ../../../netinet/in_pcb.c:238 > #12 0xc060b403 in udp_attach (so=0xc459e000, proto=0, td=0xc44fe240) > at ../../../netinet/udp_usrreq.c:1131 > #13 0xc0586df5 in socreate (dom=2, aso=0xc3e77c6c, type=2, proto=0, > #14 0xc058d974 in socket (td=0xc44fe240, uap=0xc3e77cf8) > ---Type to continue, or q to quit---Dec 10 17:29:23 witten log > in: ROOT LOGIN (root) ON ttyv1 > > at ../../../kern/uipc_syscalls.c:178 > #15 0xc06d8010 in syscall (frame=0xc3e77d38) at ../../../i386/i386/trap.c:1076 > #16 0xc06bd320 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 > #17 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > (kgdb) p *pcbinfo > $2 = {ipi_listhead = 0xc0794b24, ipi_count = 1, ipi_hashbase = 0xc42fe000, > ipi_hashmask = 127, ipi_porthashbase = 0xc42fce00, ipi_porthashmask = 127, > ipi_lastport = 0, ipi_lastlow = 0, ipi_lasthi = 0, ipi_zone = 0xc1471360, > ipi_gencnt = 0, ipi_lock = {lock_object = {lo_name = 0xc0713b87 "udp", > lo_flags = 69926928, lo_data = 0, lo_witness = 0x0}, > rw_lock = 3293569600}, ipi_pspare = { > (kgdb) p *pcbinfo->ipi_zone > $4 = {uz_name = 0xc0716712 "udpcb", uz_lock = 0xc147ed88, > uz_keg = 0xc147ed80, uz_link = {le_next = 0x0, le_prev = 0xc147eda8}, > uz_full_bucket = {lh_first = 0x0}, uz_free_bucket = {lh_first = 0x0}, > uz_ctor = 0, uz_dtor = 0, uz_init = 0, uz_fini = 0, uz_allocs = 0, > uz_frees = 0, uz_fails = 0, uz_fills = 0, uz_count = 23, uz_cpu = {{ > uc_freebucket = 0x0, uc_allocbucket = 0x0, uc_allocs = 0, > uc_frees = 0}}} > > the code tries to rw_rwlock() the inp->inp_lock, the inp is allocated from > an UMA zone which has no constructor and in the in_pcballoc() the rwlock is > never initialized. I believe that's why it crashes > > can someone confirm/fix that? Hmm. I disagree with the diagnosis, although clearly there's a problem here of some sort since panicking is, well, bad. Each protocol using the inpcb framework provides its own UMA zone and is responsible for initializing the lock on the inpcb when memory is first pulled into the cache. For UDP, that occurs in udp_inpcb_init(), the init function passed into uma_zcreate() in udp_init(). Notice that when in_pcballoc() zeroes the inpcb, it stops at inp_zero_size, which is before inp_lock, and since the inpcb zone for UDP is set to be a no-free zone, there's no INP lock destroy. So, given that this code has worked for quite a long time for many people, this really raises two questions: (1) how reproduceable is this and at what point does it kick in during the boot/runtime, and (2) when did this start happening in terms of updating your source? Robert N M Watson Computer Laboratory University of Cambridge From jhb at freebsd.org Wed Dec 10 11:58:03 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Dec 10 11:58:15 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> References: <200811191510.53793.jhb@FreeBSD.org> <200812091602.10850.jhb@freebsd.org> <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> Message-ID: <200812101450.04638.jhb@freebsd.org> On Wednesday 10 December 2008 12:22:43 pm Paul B. Mahol wrote: > On 12/9/08, John Baldwin wrote: > > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive > > lock. > > It could be a property of the ISO image. "PX" holds permissions (owner, > > etc.). Do you get the same messages w/o the patch with the same ISO image / > > CD? > > > > -- > > John Baldwin > > > > I searched little for this message and found kern/63446 PR interesting comment: > > Caused by cd9660_vnops.c rev. 1.77. VOP_READDIR returns bogus > d_fileno, VFS_VGET on this value returns bogus vnode with zeroed attributes. > > I think that whatever locking is done is done wrong. That issue isn't a locking issue, it's an issue with VOP_READDIR() using a different meaning for i-node numbers than VFS_VGET(), and would happen regardless of any Giant or vnode locking. -- John Baldwin From jhb at freebsd.org Wed Dec 10 11:58:08 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Dec 10 11:58:16 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <3a142e750812091628l69034673sa2e11e71ba0bdad4@mail.gmail.com> References: <200811191510.53793.jhb@FreeBSD.org> <3a142e750812091516n6bb0880ewb298314e9ba296c@mail.gmail.com> <3a142e750812091628l69034673sa2e11e71ba0bdad4@mail.gmail.com> Message-ID: <200812101450.47191.jhb@freebsd.org> On Tuesday 09 December 2008 07:28:14 pm Paul B. Mahol wrote: > On 12/10/08, Paul B. Mahol wrote: > > On 12/10/08, Paul B. Mahol wrote: > >> On 12/9/08, John Baldwin wrote: > >>> The RRIP stuff is all done in cd9660_vget_internal() under an exclusive > >>> lock. > >>> It could be a property of the ISO image. "PX" holds permissions (owner, > >>> etc.). Do you get the same messages w/o the patch with the same ISO > >>> image > >>> / > >>> CD? > >>> > >>> -- > >>> John Baldwin > >>> > >> > >> No I do not, but I may try other CDs I have many of them, including > >> FreeBSD > > s/Yes I do. Its to late here ... > Ignore that reply. > > cd9660.ko without patch doesnt have this issue. > cd9660.ko with cd9660_mpsafe.patch have this issue, on every CD I tried. Ok, I will try to reproduce this locally. -- John Baldwin From jhb at freebsd.org Wed Dec 10 12:45:31 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Dec 10 12:45:37 2008 Subject: [patch] de(4) has not worked on 8-current since Feb 13 In-Reply-To: <20081210125627.25732615CD@mail.asahi-net.or.jp> References: <20081210125627.25732615CD@mail.asahi-net.or.jp> Message-ID: <200812101539.26031.jhb@freebsd.org> On Wednesday 10 December 2008 07:56:25 am WATANABE Kazuhiro wrote: > Hi, all. > > My de(4) NICs has not worked on 8-current since Feb 13. Try this patch to de(4) instead. It removes the alignment requirement for TX buffers since the 4-byte alignment is only required for RX. Index: if_de.c =================================================================== --- if_de.c (revision 185867) +++ if_de.c (working copy) @@ -4491,7 +4491,8 @@ /* Allocate memory for a single descriptor ring. */ static int tulip_busdma_allocring(device_t dev, tulip_softc_t * const sc, size_t count, - bus_size_t maxsize, int nsegs, tulip_ringinfo_t *ri, const char *name) + bus_size_t alignment, bus_size_t maxsize, int nsegs, tulip_ringinfo_t *ri, + const char *name) { size_t size; int error, i; @@ -4527,7 +4528,7 @@ } /* Allocate a tag for the data buffers. */ - error = bus_dma_tag_create(NULL, 4, 0, + error = bus_dma_tag_create(NULL, alignment, 0, BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, maxsize, nsegs, TULIP_DATA_PER_DESC, 0, NULL, NULL, &ri->ri_data_tag); if (error) { @@ -4586,8 +4587,8 @@ /* * Allocate space and dmamap for transmit ring. */ - error = tulip_busdma_allocring(dev, sc, TULIP_TXDESCS, TULIP_DATA_PER_DESC, - TULIP_MAX_TXSEG, &sc->tulip_txinfo, "transmit"); + error = tulip_busdma_allocring(dev, sc, 1, TULIP_TXDESCS, + TULIP_DATA_PER_DESC, TULIP_MAX_TXSEG, &sc->tulip_txinfo, "transmit"); if (error) return (error); @@ -4598,7 +4599,7 @@ * a waste in practice though as an ethernet frame can easily fit * in TULIP_RX_BUFLEN bytes. */ - error = tulip_busdma_allocring(dev, sc, TULIP_RXDESCS, MCLBYTES, 1, + error = tulip_busdma_allocring(dev, sc, 4, TULIP_RXDESCS, MCLBYTES, 1, &sc->tulip_rxinfo, "receive"); if (error) return (error); -- John Baldwin From keramida at freebsd.org Wed Dec 10 13:27:42 2008 From: keramida at freebsd.org (Giorgos Keramidas) Date: Wed Dec 10 13:27:49 2008 Subject: behavioral change of "read" builtin for sh on 8-CURRENT In-Reply-To: <1de79840812092149t4d212027o2c908635419fa838@mail.gmail.com> (Michael Proto's message of "Wed, 10 Dec 2008 00:49:58 -0500") References: <1de79840812092149t4d212027o2c908635419fa838@mail.gmail.com> Message-ID: <87zlj390vw.fsf@kobe.laptop> Hi Michael, This looks like a bug in 8.0-CURRENT. Can you please file a bug report and include the text you sent below? On Wed, 10 Dec 2008 00:49:58 -0500, "Michael Proto" wrote: > I've noticed a behavioral difference of the "read" builtin statement within > /bin/sh on CURRENT and I'm hoping someone can point me in the right > direction on how to restore the old behavior. > > I have a /bin/sh script that accepts input for IP address information: > > #!/bin/sh > set -x > DEFINT=vr0 > DEFIP=192.168.0.1 > DEFMASK=255.255.255.0 > read -p "Enter network interface [$DEFINT]: " -t 5 INT > read -p "Enter IP address [$DEFIP]: " -t 5 IP > read -p "Enter netmask [$DEFMASK]: " -t 5 MASK > echo ${INT:=$DEFINT} : ${IP:=$DEFIP}/${MASK:=$DEFMASK} > > This script waits for terminal input for each of the above variables (INT, > IP, MASK) and defaults to a script-provided value if no input is entered in > 5 seconds for each variable. On 6.x and 7.x if I simply hit Enter at the > prompt (and don't provide any input) no value is assigned to the variable so > my INT, IP, and MASK variables are set to null and the parameter > substitution of the DEF* variables works as expected. > > On 8-CURRENT if I hit Enter with no input at the prompt the system seems to > recognize the newline as input and continues to sit there until I hit Enter > again. When I do this there appears to be a strange unprintable value > assigned to the INT, IP, and MASK variables yet the variable subsitution > doesn't work correctly. > > The man page on sh lists the following behavior for read: > > read [-p prompt] [-t timeout] [-er] variable ... > The prompt is printed if the -p option is specified and the > stan- > dard input is a terminal. Then a line is read from the > standard > input. The trailing newline is deleted from the line and the > line is split as described in the section on White Space > Splitting (Field Splitting) above, and the pieces are assigned > to > the variables in order. If there are more pieces than > variables, > the remaining pieces (along with the characters in IFS that > sepa- > rated them) are assigned to the last variable. If there are > more > variables than pieces, the remaining variables are assigned the > null string. > > > As I interpret this, read should delete the trailing newline and assign a > null value since there is is no "input" before the newline. Then the > variable substitution should take over and assign the DEF* variables > appropriately. 6 and 7 follow this but 8 does not. > > Here's the output of the script (with set -x) to help show what I'm seeing. > > This is on 6 and 7: > > + DEFINT=vr0 > + DEFIP=192.168.0.1 > + DEFMASK=255.255.255.0 > + read -p Enter network interface [vr0]: -t 5 INT > Enter network interface [vr0]: > + read -p Enter IP address [192.168.0.1]: -t 5 IP > Enter IP address [192.168.0.1]: > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > Enter netmask [255.255.255.0]: > + echo vr0 : 192.168.0.1/255.255.255.0 > vr0 : 192.168.0.1/255.255.255.0 > > > And this is what I see with 8: > > + DEFINT=vr0 > + DEFIP=192.168.0.1 > + DEFMASK=255.255.255.0 > + read -p Enter network interface [vr0]: -t 5 INT > Enter network interface [vr0]: > + read -p Enter IP address [192.168.0.1]: -t 5 IP > Enter IP address [192.168.0.1]: > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > Enter netmask [255.255.255.0]: > /: cho > /: > > Strange that the "echo" statement is missing the first "e" character in the > debug output. > > Even stranger on 8-CURRENT, if I *do* enter input before the newline (say I > change the IP address or the network interface), the first character is not > echoed back to the screen but is still saved to the variable. Here's an > example when I run the script and provide input at each prompt: > > + DEFINT=vr0 > + DEFIP=192.168.0.1 > + DEFMASK=255.255.255.0 > + read -p Enter network interface [vr0]: -t 5 INT > Enter network interface [vr0]: r0 > + read -p Enter IP address [192.168.0.1]: -t 5 IP > Enter IP address [192.168.0.1]: 92.168.0.1 > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > Enter netmask [255.255.255.0]: 55.255.255.0 > + echo br0 : 192.168.0.1/255.255.255.0 > br0 : 192.168.0.1/255.255.255.0 > + echo ifconfig br0 inet 192.168.0.1 netmask 255.255.255.0 > > Notice that when I'm prompted, the first character doesn't echo but is still > saved in the variable. > > > Does anyone else see this same behavior? Any ideas on how to reset it back > to how it works in STABLE? I'm not doing anything special with IFS so I'm > stumped on how to troubleshoot this. > > > > Thanks, > Proto > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > -- From uspoerlein at gmail.com Wed Dec 10 13:28:25 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Wed Dec 10 13:28:32 2008 Subject: ZFS backup advice Message-ID: <20081210212821.GF1494@roadrunner.spoerlein.net> Servus, I'm looking for advice on setting up a ZFS based hard disk backup solution. Given a large set of data, with perhaps 500MB data changes per day and two 1 TB disks, which option would you prefer and why: A) Separate ZFS pools on both disk. Using zfs send|recv to transfer snapshots every 2-3 days, taking the "backup" pool offline in the time in between (to keep the disk safe from surges, etc). or B) One ZFS mirror pool across both disk, resilvering the second half every 2-3 days and then detaching it again. Right now I'm favouring option A, as I can selectively "backup" part of the pool (excluding /usr/obj for example, though it is <10% of total capacity, so not a strong point), can use compression on the backup-pool and can potentially keep more snapshots on it than on the live pool. It should also be faster than resilvering the mirror every other day. I'd use B, iff ZFS is able to "self-heal" defective sectors on one mirror half, even if it is not fully resilvered. Does anyone know if this is possible? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From admin at lissyara.su Wed Dec 10 13:41:38 2008 From: admin at lissyara.su (Alex Keda) Date: Wed Dec 10 13:41:46 2008 Subject: bge && route problem Message-ID: <4940378F.9040701@lissyara.su> before last update (2 days ago) I have problem: when many packets run over interface - network inaccessible - no ping, nothing not works. frequently I see problem when update source three with fast cvsup mirror. But - no problem with slow mirror. if I down/up interface - all OK short time - 20-30 seconds. After last update, problem still, but, system hang after ifconfig bge0 down && ifconfig bge0 up & I cannot correct shutdown - only reset. when system hang, 1 process get all cpu resources: ps -auxww | grep rout root 1545 100,0 0,0 2704 912 ?? R 0:21 0:00,73 route add default 192.168.250.254 ps -auxww | grep ifconf root 1569 0,0 0,1 7912 1392 v1 L 0:22 0:00,00 ifconfig bge0 down root 1572 0,0 0,1 7912 1392 v1 L 0:23 0:00,00 ifconfig bge0 down root 1575 0,0 0,1 7912 1392 v1 L 0:23 0:00,00 ifconfig bge0 down root 1578 0,0 0,1 7912 1392 v1 L 0:23 0:00,00 ifconfig bge0 down network unrecheable if, before first ifconfig bge0 down && ifconfig bge0 up & I connect to network with ssh|another tcp services - system hang later 5-10 seconds after down/up interface acer# uname -a FreeBSD acer.lissyara.int.otradno.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Dec 8 23:41:04 MSK 2008 lissyara@acer.lissyara.int.otradno.ru:/usr/obj/usr/src/sys/color-console amd64 acer# acer# ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1f:29:89:38:f3 inet 192.168.250.1 netmask 0xffffff00 broadcast 192.168.250.255 media: Ethernet autoselect (100baseTX ) status: active acer# acer# dmesg | grep bge bge0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16 miibus0: on bge0 bge0: Ethernet address: 00:1f:29:89:38:f3 bge0: [ITHREAD] acer# bge0@pci0:16:0:0: class=0x020000 card=0x30c2103c chip=0x171314e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetLink BCM5906M Fast Ethernet PCIe' class = network subclass = ethernet From rdivacky at FreeBSD.org Wed Dec 10 13:47:36 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Wed Dec 10 13:47:44 2008 Subject: [PANIC]: rw_lock panic in in_pcballoc() in r185864 In-Reply-To: References: <20081210164345.GA32188@freebsd.org> Message-ID: <20081210214248.GA69246@freebsd.org> On Wed, Dec 10, 2008 at 07:23:49PM +0000, Robert Watson wrote: > On Wed, 10 Dec 2008, Roman Divacky wrote: > > >#9 0xc06bd28b in calltrap () at ../../../i386/i386/exception.s:165 > >#10 0xc0528cc9 in _rw_wlock_hard (rw=0xc45a00a4, tid=3293569600, file=0x0, > > line=0) at ../../../kern/kern_rwlock.c:616 > >#11 0xc05eae42 in in_pcballoc (so=0xc459e000, pcbinfo=0xc0794b40) > > at ../../../netinet/in_pcb.c:238 > >#12 0xc060b403 in udp_attach (so=0xc459e000, proto=0, td=0xc44fe240) > > at ../../../netinet/udp_usrreq.c:1131 > >#13 0xc0586df5 in socreate (dom=2, aso=0xc3e77c6c, type=2, proto=0, > >#14 0xc058d974 in socket (td=0xc44fe240, uap=0xc3e77cf8) > >---Type to continue, or q to quit---Dec 10 17:29:23 > >witten log > >in: ROOT LOGIN (root) ON ttyv1 > > > > at ../../../kern/uipc_syscalls.c:178 > >#15 0xc06d8010 in syscall (frame=0xc3e77d38) at > >../../../i386/i386/trap.c:1076 > >#16 0xc06bd320 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 > >#17 0x00000033 in ?? () > >Previous frame inner to this frame (corrupt stack?) > > > >(kgdb) p *pcbinfo > >$2 = {ipi_listhead = 0xc0794b24, ipi_count = 1, ipi_hashbase = 0xc42fe000, > > ipi_hashmask = 127, ipi_porthashbase = 0xc42fce00, ipi_porthashmask = 127, > > ipi_lastport = 0, ipi_lastlow = 0, ipi_lasthi = 0, ipi_zone = 0xc1471360, > > ipi_gencnt = 0, ipi_lock = {lock_object = {lo_name = 0xc0713b87 "udp", > > lo_flags = 69926928, lo_data = 0, lo_witness = 0x0}, > > rw_lock = 3293569600}, ipi_pspare = { > >(kgdb) p *pcbinfo->ipi_zone > >$4 = {uz_name = 0xc0716712 "udpcb", uz_lock = 0xc147ed88, > > uz_keg = 0xc147ed80, uz_link = {le_next = 0x0, le_prev = 0xc147eda8}, > > uz_full_bucket = {lh_first = 0x0}, uz_free_bucket = {lh_first = 0x0}, > > uz_ctor = 0, uz_dtor = 0, uz_init = 0, uz_fini = 0, uz_allocs = 0, > > uz_frees = 0, uz_fails = 0, uz_fills = 0, uz_count = 23, uz_cpu = {{ > > uc_freebucket = 0x0, uc_allocbucket = 0x0, uc_allocs = 0, > > uc_frees = 0}}} > > > >the code tries to rw_rwlock() the inp->inp_lock, the inp is allocated from > >an UMA zone which has no constructor and in the in_pcballoc() the rwlock > >is never initialized. I believe that's why it crashes > > > >can someone confirm/fix that? > > Hmm. I disagree with the diagnosis, although clearly there's a problem > here of some sort since panicking is, well, bad. Each protocol using the > inpcb framework provides its own UMA zone and is responsible for > initializing the lock on the inpcb when memory is first pulled into the > cache. For UDP, that occurs in udp_inpcb_init(), the init function passed > into uma_zcreate() in udp_init(). Notice that when in_pcballoc() zeroes > the inpcb, it stops at inp_zero_size, which is before inp_lock, and since > the inpcb zone for UDP is set to be a no-free zone, there's no INP lock > destroy. hm... I wondered how it could work before that.... anyway, I got this crash > So, given that this code has worked for quite a long time for many people, > this really raises two questions: (1) how reproduceable is this and at what > point does it kick in during the boot/runtime, and (2) when did this start > happening in terms of updating your source? ad (1): I get this on every boot when dhcp kicks in (it uses udp I believe) ie. 100% reproducible ad (2): Mon Dec 8 23:02:27 CET 2008 kernel (svn up-dated at most 10 minutes before that) works 100% ok I have the crash dump and the kernel at hand so I can do basically anything you ask me to do :) anything I can provide? thnx roman From jille at quis.cx Wed Dec 10 14:14:03 2008 From: jille at quis.cx (Jille Timmermans) Date: Wed Dec 10 14:14:11 2008 Subject: Panic when loading if_ath Message-ID: <49403F27.3020605@quis.cx> Hello list, A panic with if_ath (Atheros 2413) root /sys/modules/ath_rate_amrr# make root /sys/modules/ath_rate_amrr# make install root ~# kldload if_ath warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xc43cc748 frame pointer = 0x28:0xc43cc75c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current_process = 993 (kldload) trap number = 12 panic: page fault cpuid = 0 [dump] [reboot] WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x5bbfe499 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0684c37 stack pointer = 0x28:0xc4364a5c frame pointer = 0x28:0xc4364c28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 136 (ifconfig) trap number = 12 panic: page fault cpuid = 0 [a few crashes later, when it comes to mind to get a backtrace] root ~# kldload ath_rate root ~# kldload if_ath ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] [panic] uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at ar5212Attach+0x211 ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at ath_hal_attach+0x56 ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, ...) at ath_pci_attach+0x332 device_attach([snip]) at device_attach+0x36f device_probe_and_attach([snip) at ...+0x43 pci_driver_added([snip]) at +0x104 devclass_add_driver([snip]) at +0xe8 driver_module_handler([snip]) at +0x79 module_register_init() linker_load_module() kern_kldload() (Please don't tell me you want any of that snips.) Any extra information I can provide to you ? I am willing to help debugging / crashing. -- Jille From marius at nuenneri.ch Wed Dec 10 14:15:45 2008 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Wed Dec 10 14:16:18 2008 Subject: DTrace probes for geom_kern, geom_io and geom_event In-Reply-To: References: Message-ID: current CC'ed, maybe there are some people interested in DTrace that don't read geom. On Thu, Dec 4, 2008 at 9:41 PM, Marius N?nnerich wrote: > Hi, > > I wrote a bunch of DTrace probes for the core geom files mentioned in > the subject. The patch for current is available at > http://nuenneri.ch/freebsd/geom_probes.patch > > Anyone interested in testing them? Just apply the patch, add options > KDTRACE_HOOKS to your kernel and build it like this: > # make WITH_CTF=1 KERNCONF=YOURKERNEL buildkernel installkernel > > After reboot you can > # kldload dtraceall > and see the new probes with > # dtrace -lP geom > > A sample script: > #!/usr/sbin/dtrace -s > #pragma D option quiet > > geom::: > { > @geom[execname, probemod, probefunc, probename] = count(); > @geom_all[execname, probemod, probefunc, probename] = count(); > } > > tick-10sec > { > normalize(@geom, 10) > printa("%@8u %@8u %12s %s:%s:%s\n", @geom_all, @geom); > printf("\n"); > clear(@geom); > } > > This is hand copied. You can chmod 755 and run it. > > I'm not sure how to handle the opt_kdtrace.h case in geom.h, see patch line 842. > Any comments on the patch? > > @phk: Are you interested in committing this when there are no > complaints? Are you interested in more probes? After some tips from Alexander Leidinger I updated the patch, new version here: http://nuenneri.ch/freebsd/geom_probes2.patch There are some questions I'd like to discuss: 1. I wrote the SDT_PROBE_DEFINEs right before the function definition, I know this violates the usual style as that stuff would normally belong to the top of the file. I think in this case it would be worthwhile to break with this tradition 2. Should I use the full function name for the probes (with the g_ prefix) even though it's defined under the provider geom 3. Should there be a probe for every switch case in g_io_check? I think this won't work with the fall-through that is used right now 4. Alexander proposed to change the module name kern to core. I'm not sure about this as kern refers to the filename, like io and event do 5. I'm thinking about defining a G_TRACE macro for SDT_PROBE(geom, ...) 6. Does anybody know of a way to probe functions with varargs properly? Like g_trace 7. What about g_bioq_(un)lock functions, I just added one probe for it, I do not really see a point in adding entry and return probes (they are there with FBT anyway). This is consistent with g_topology_lock etc. What about making macros of the two functions like g_topology_lock 8. What about adding macros for (un)locking other locks like g_eventlock, so one could add probes and trace them 9. Writing hundreds of entry and return probes is boring, especially as there is the FBT provider. Maybe it's possible to give the FBT probes better names like geom:io:g_io_schedule_down:entry instead of fbt:kernel:g_io_schedule:entry. Every FBT probe has a provider of fbt und module of kernel right now. One also has to define the argument types which I think FBT figures out by itself. If this would work we could concentrate on adding SDT probes to interesting places inside of functions or macros Bye Marius From sam at freebsd.org Wed Dec 10 14:34:55 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Dec 10 14:35:03 2008 Subject: Panic when loading if_ath In-Reply-To: <49403F27.3020605@quis.cx> References: <49403F27.3020605@quis.cx> Message-ID: <4940440E.9050805@freebsd.org> Jille Timmermans wrote: > Hello list, > > A panic with if_ath (Atheros 2413) > > root /sys/modules/ath_rate_amrr# make > root /sys/modules/ath_rate_amrr# make install > root ~# kldload if_ath > warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file > ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 > ath0: [ITHREAD] > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xc43cc748 > frame pointer = 0x28:0xc43cc75c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current_process = 993 (kldload) > trap number = 12 > panic: page fault > cpuid = 0 > > [dump] > [reboot] > WARNING: /tmp was not properly dismounted > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x5bbfe499 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0684c37 > stack pointer = 0x28:0xc4364a5c > frame pointer = 0x28:0xc4364c28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 136 (ifconfig) > trap number = 12 > panic: page fault > cpuid = 0 > > [a few crashes later, when it comes to mind to get a backtrace] > root ~# kldload ath_rate > root ~# kldload if_ath > ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 > ath0: [ITHREAD] > [panic] > uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 > ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at ar5212Attach+0x211 > ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at > ath_hal_attach+0x56 > ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e > ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, ...) at > ath_pci_attach+0x332 > device_attach([snip]) at device_attach+0x36f > device_probe_and_attach([snip) at ...+0x43 > pci_driver_added([snip]) at +0x104 > devclass_add_driver([snip]) at +0xe8 > driver_module_handler([snip]) at +0x79 > module_register_init() > linker_load_module() > kern_kldload() > > (Please don't tell me you want any of that snips.) > > Any extra information I can provide to you ? > I am willing to help debugging / crashing. > > Try building the driver into the kernel. Also use sample and not amrr. Sam From rwatson at FreeBSD.org Wed Dec 10 14:58:15 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Dec 10 14:58:21 2008 Subject: [PANIC]: rw_lock panic in in_pcballoc() in r185864 In-Reply-To: <20081210214248.GA69246@freebsd.org> References: <20081210164345.GA32188@freebsd.org> <20081210214248.GA69246@freebsd.org> Message-ID: On Wed, 10 Dec 2008, Roman Divacky wrote: > hm... I wondered how it could work before that.... anyway, I got this crash Well, nothing says it still works that way, that's just the theory :-). >> So, given that this code has worked for quite a long time for many people, >> this really raises two questions: (1) how reproduceable is this and at what >> point does it kick in during the boot/runtime, and (2) when did this start >> happening in terms of updating your source? > > ad (1): I get this on every boot when dhcp kicks in (it uses udp I believe) > ie. 100% reproducible > > ad (2): Mon Dec 8 23:02:27 CET 2008 kernel (svn up-dated at most 10 minutes > before that) works 100% ok > > I have the crash dump and the kernel at hand so I can do basically anything > you ask me to do :) anything I can provide? Well, to be honest, the easiest thing to do may be to play the binary search game to narrow down the point where the problem starts a bit more. There are a few kinds of things that might lead to this problem -- perhaps we (I?) mucked up initialization of the inpcb with recent changes, or a virtualization-related change tripped something up, or a locking/scheduler change or such. The other thing that would be helpful is a dump of *inp so that we can see what state inp_lock is in. Robert N M Watson Computer Laboratory University of Cambridge From onemda at gmail.com Wed Dec 10 15:54:23 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Dec 10 15:54:29 2008 Subject: [PATCH] MPSAFE/LOOKUP_SHARED cd9660 In-Reply-To: <200812101450.04638.jhb@freebsd.org> References: <200811191510.53793.jhb@FreeBSD.org> <200812091602.10850.jhb@freebsd.org> <3a142e750812100922m553be9c6sdcd81d98c81c7ab4@mail.gmail.com> <200812101450.04638.jhb@freebsd.org> Message-ID: <3a142e750812101554o656347f9w42c7486db4fc4a9e@mail.gmail.com> On 12/10/08, John Baldwin wrote: > On Wednesday 10 December 2008 12:22:43 pm Paul B. Mahol wrote: >> On 12/9/08, John Baldwin wrote: >> > The RRIP stuff is all done in cd9660_vget_internal() under an exclusive >> > lock. >> > It could be a property of the ISO image. "PX" holds permissions (owner, >> > etc.). Do you get the same messages w/o the patch with the same ISO > image / >> > CD? >> > >> > -- >> > John Baldwin >> > >> >> I searched little for this message and found kern/63446 PR interesting > comment: >> >> Caused by cd9660_vnops.c rev. 1.77. VOP_READDIR returns bogus >> d_fileno, VFS_VGET on this value returns bogus vnode with zeroed > attributes. >> >> I think that whatever locking is done is done wrong. > > That issue isn't a locking issue, it's an issue with VOP_READDIR() using a > different meaning for i-node numbers than VFS_VGET(), and would happen > regardless of any Giant or vnode locking. Yes, I know that that issue/PR doesnt have anything to do with locking. But displaying bogus messages and still having functional cd9660 for general use means that something is not correctly locked. -- Paul From bsam at ipt.ru Wed Dec 10 16:02:48 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Dec 10 16:02:55 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: (Eygene Ryabinkin's message of "Wed\, 10 Dec 2008 18\:38\:00 +0300") References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> Message-ID: <26719629@bb.ipt.ru> Eygene Ryabinkin writes: > Boris, good day. > > Wed, Dec 10, 2008 at 05:13:48PM +0300, Boris Samorodov wrote: >> Boris Samorodov writes: >> >> > I've got a Sunix PCI Serial 8-channel Multiport adapter (Timedia chipset): >> > ----- >> > puc0@pci0:5:2:0: class=0x070002 card=0x40661409 chip=0x71681409 rev=0x01 hdr=0x00 >> > vendor = 'Timedia Technology Co Ltd' >> > device = '40371409 PCI / ISA Asynchronous UART Signal Chips Solution' >> >> Actually the card is 4066, while 4037 (according to pucdata.c) is indeed >> a dual-port card. May be the card is wrongly interpreted by the OS? > > pciconf just don't know about 4066, so is prints what it has in the > database. This is irrelevant to the driver -- it discovers the correct > chip with 8 ports: > >> > puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 >> > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 >> > puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 >> > puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 >> > puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 >> > puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 >> > puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 >> > puc0: [FILTER] >> > uart4: <16550 or compatible> on puc0 >> > uart4: [FILTER] >> > uart4: fast interrupt >> > uart5: <16550 or compatible> on puc0 >> > uart5: [FILTER] >> > uart5: fast interrupt >> > ----- > > Judging by this output, the 6 ports that got their reservations at > dev/pci/pci.c are the ones that aren't recognized by uart. You may need > to add trace printfs to uart_puc_probe (uart_bus_puc.c) and to > uart_bus_probe (uart_core.c), just around the register resource > allocator. This should show what devices are passed to the probe > routines and which are rejected. Be sure to include 'rid' values to > your debug output to get the idea what ports we're speaking about. Seems that just the same card should work: http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html I've added some diagnistic. But 'rid' is not what you want, I guess: ----- puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 puc0: [FILTER] uart4: uart_puc_probe: type = 1, error = 0 uart4: uart_puc_probe: probing for uart bus uart4: uart_bus_probe: Entering uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 ns8250_probe: no errors, exiting ns8250_bus_probe:656: continue ns8250_bus_probe:664: continue ns8250_bus_probe:749: Reset FIFOs ns8250_bus_probe:752: FIFO count=16 ns8250_bus_probe:792: no errors, exiting uart4: uart_bus_probe: Uart probe returned 0 uart4: uart_bus_probe: exiting uart4: uart_puc_probe: type = 1, error = 0 uart4: uart_puc_probe: probing for uart bus uart4: uart_bus_probe: Entering uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 ns8250_probe: no errors, exiting ns8250_bus_probe:656: continue ns8250_bus_probe:664: continue ns8250_bus_probe:749: Reset FIFOs ns8250_bus_probe:752: FIFO count=16 ns8250_bus_probe:792: no errors, exiting uart4: uart_bus_probe: Uart probe returned 0 uart4: uart_bus_probe: exiting uart4: <16550 or compatible> on puc0 uart4: [FILTER] uart4: fast interrupt uart5: uart_puc_probe: type = 1, error = 0 uart5: uart_puc_probe: probing for uart bus uart5: uart_bus_probe: Entering uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 ns8250_probe: no errors, exiting ns8250_bus_probe:656: continue ns8250_bus_probe:664: continue ns8250_bus_probe:749: Reset FIFOs ns8250_bus_probe:752: FIFO count=16 ns8250_bus_probe:792: no errors, exiting uart5: uart_bus_probe: Uart probe returned 0 uart5: uart_bus_probe: exiting uart5: uart_puc_probe: type = 1, error = 0 uart5: uart_puc_probe: probing for uart bus uart5: uart_bus_probe: Entering uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 ns8250_probe: no errors, exiting ns8250_bus_probe:656: continue ns8250_bus_probe:664: continue ns8250_bus_probe:749: Reset FIFOs ns8250_bus_probe:752: FIFO count=16 ns8250_bus_probe:792: no errors, exiting uart5: uart_bus_probe: Uart probe returned 0 uart5: uart_bus_probe: exiting uart5: <16550 or compatible> on puc0 uart5: [FILTER] uart5: fast interrupt uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting uart6: uart_puc_probe: type = 1, error = 0 uart6: uart_puc_probe: probing for uart bus uart6: uart_bus_probe: Entering uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 ns8250_probe: got MCR wrong register, exiting with ENXIO ns8250_bus_probe:645: error at ns8250_probe(), exiting, returning 6 uart6: uart_bus_probe: Uart probe returned 6 uart6: uart_bus_probe: exiting ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From jille at quis.cx Wed Dec 10 16:29:00 2008 From: jille at quis.cx (Jille Timmermans) Date: Wed Dec 10 16:29:07 2008 Subject: Panic when loading if_ath In-Reply-To: <4940440E.9050805@freebsd.org> References: <49403F27.3020605@quis.cx> <4940440E.9050805@freebsd.org> Message-ID: <49405EC7.8080906@quis.cx> Sam Leffler schreef: > Jille Timmermans wrote: >> Hello list, >> >> A panic with if_ath (Atheros 2413) >> >> root /sys/modules/ath_rate_amrr# make >> root /sys/modules/ath_rate_amrr# make install >> root ~# kldload if_ath >> warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file >> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >> pci5 >> ath0: [ITHREAD] >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x0 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0x0 >> stack pointer = 0x28:0xc43cc748 >> frame pointer = 0x28:0xc43cc75c >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current_process = 993 (kldload) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> >> [dump] >> [reboot] >> WARNING: /tmp was not properly dismounted >> WARNING: /usr was not properly dismounted >> WARNING: /var was not properly dismounted >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x5bbfe499 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc0684c37 >> stack pointer = 0x28:0xc4364a5c >> frame pointer = 0x28:0xc4364c28 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 136 (ifconfig) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> >> [a few crashes later, when it comes to mind to get a backtrace] >> root ~# kldload ath_rate >> root ~# kldload if_ath >> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >> pci5 >> ath0: [ITHREAD] >> [panic] >> uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 >> ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >> ar5212Attach+0x211 >> ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >> ath_hal_attach+0x56 >> ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e >> ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, ...) at >> ath_pci_attach+0x332 >> device_attach([snip]) at device_attach+0x36f >> device_probe_and_attach([snip) at ...+0x43 >> pci_driver_added([snip]) at +0x104 >> devclass_add_driver([snip]) at +0xe8 >> driver_module_handler([snip]) at +0x79 >> module_register_init() >> linker_load_module() >> kern_kldload() >> >> (Please don't tell me you want any of that snips.) >> >> Any extra information I can provide to you ? >> I am willing to help debugging / crashing. >> >> > Try building the driver into the kernel. Also use sample and not amrr. root ~# cd /sys/modules/ath_rate_sample root /sys/modules/ath_rate_sample# make root /sys/modules/ath_rate_sample# make install root /sys/modules/ath_rate_sample# kldload if_ath link_elf: symbol ath_hal_computetxtime undefined KLD if_ath.ko: depends on ath_rate - not available kldload: can't load if_ath: No such file or directory root /sys/modules/ath_rate_sample# kldload ath_rate link_elf: symbol ath_hal_computetxtime undefined kldload: can't load ath_rate: No such file or directory I'll try compiling it in. -- Jille > > Sam > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From sam at freebsd.org Wed Dec 10 16:45:52 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Dec 10 16:45:59 2008 Subject: Panic when loading if_ath In-Reply-To: <49405EC7.8080906@quis.cx> References: <49403F27.3020605@quis.cx> <4940440E.9050805@freebsd.org> <49405EC7.8080906@quis.cx> Message-ID: <494062BE.5050202@freebsd.org> Jille Timmermans wrote: > Sam Leffler schreef: > >> Jille Timmermans wrote: >> >>> Hello list, >>> >>> A panic with if_ath (Atheros 2413) >>> >>> root /sys/modules/ath_rate_amrr# make >>> root /sys/modules/ath_rate_amrr# make install >>> root ~# kldload if_ath >>> warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file >>> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >>> pci5 >>> ath0: [ITHREAD] >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x0 >>> fault code = supervisor read, page not present >>> instruction pointer = 0x20:0x0 >>> stack pointer = 0x28:0xc43cc748 >>> frame pointer = 0x28:0xc43cc75c >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, def32 1, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current_process = 993 (kldload) >>> trap number = 12 >>> panic: page fault >>> cpuid = 0 >>> >>> [dump] >>> [reboot] >>> WARNING: /tmp was not properly dismounted >>> WARNING: /usr was not properly dismounted >>> WARNING: /var was not properly dismounted >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x5bbfe499 >>> fault code = supervisor read, page not present >>> instruction pointer = 0x20:0xc0684c37 >>> stack pointer = 0x28:0xc4364a5c >>> frame pointer = 0x28:0xc4364c28 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, def32 1, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 136 (ifconfig) >>> trap number = 12 >>> panic: page fault >>> cpuid = 0 >>> >>> [a few crashes later, when it comes to mind to get a backtrace] >>> root ~# kldload ath_rate >>> root ~# kldload if_ath >>> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >>> pci5 >>> ath0: [ITHREAD] >>> [panic] >>> uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 >>> ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >>> ar5212Attach+0x211 >>> ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >>> ath_hal_attach+0x56 >>> ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e >>> ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, ...) at >>> ath_pci_attach+0x332 >>> device_attach([snip]) at device_attach+0x36f >>> device_probe_and_attach([snip) at ...+0x43 >>> pci_driver_added([snip]) at +0x104 >>> devclass_add_driver([snip]) at +0xe8 >>> driver_module_handler([snip]) at +0x79 >>> module_register_init() >>> linker_load_module() >>> kern_kldload() >>> >>> (Please don't tell me you want any of that snips.) >>> >>> Any extra information I can provide to you ? >>> I am willing to help debugging / crashing. >>> >>> >>> >> Try building the driver into the kernel. Also use sample and not amrr. >> > root ~# cd /sys/modules/ath_rate_sample > root /sys/modules/ath_rate_sample# make > root /sys/modules/ath_rate_sample# make install > root /sys/modules/ath_rate_sample# kldload if_ath > link_elf: symbol ath_hal_computetxtime undefined > KLD if_ath.ko: depends on ath_rate - not available > kldload: can't load if_ath: No such file or directory > root /sys/modules/ath_rate_sample# kldload ath_rate > link_elf: symbol ath_hal_computetxtime undefined > kldload: can't load ath_rate: No such file or directory > > I'll try compiling it in. > > I know module building is broken; I posted recently to just build things into the kernel. I've got a possible solution in p4 in the sam_vap branch if you want to try it. I removed the ath_rate_* modules and just smooshed the code into the ath module so we go from (ath+ath_hal+ath_rate) to just (ath). Right now I want to see if your problem is in the module mess, ath_rate_amrr, or something else. I tested 2413 w/ the driver built into the kernel so I'm guessing it's amrr which I may just nuke entirely (along with onoe). Sam From tinderbox at freebsd.org Wed Dec 10 16:56:17 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Dec 10 16:56:30 2008 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20081211005613.F115073039@freebsd-current.sentex.ca> TB --- 2008-12-10 22:52:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-10 22:52:52 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-12-10 22:52:52 - cleaning the object tree TB --- 2008-12-10 22:53:27 - cvsupping the source tree TB --- 2008-12-10 22:53:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-12-10 22:53:35 - building world TB --- 2008-12-10 22:53:35 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-10 22:53:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-10 22:53:35 - TARGET=ia64 TB --- 2008-12-10 22:53:35 - TARGET_ARCH=ia64 TB --- 2008-12-10 22:53:35 - TZ=UTC TB --- 2008-12-10 22:53:35 - __MAKE_CONF=/dev/null TB --- 2008-12-10 22:53:35 - cd /src TB --- 2008-12-10 22:53:35 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 10 22:53:36 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 11 00:40:46 UTC 2008 TB --- 2008-12-11 00:40:46 - generating LINT kernel config TB --- 2008-12-11 00:40:46 - cd /src/sys/ia64/conf TB --- 2008-12-11 00:40:46 - /usr/bin/make -B LINT TB --- 2008-12-11 00:40:46 - building LINT kernel TB --- 2008-12-11 00:40:46 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-11 00:40:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-11 00:40:46 - TARGET=ia64 TB --- 2008-12-11 00:40:46 - TARGET_ARCH=ia64 TB --- 2008-12-11 00:40:46 - TZ=UTC TB --- 2008-12-11 00:40:46 - __MAKE_CONF=/dev/null TB --- 2008-12-11 00:40:46 - cd /src TB --- 2008-12-11 00:40:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 11 00:40:46 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/kern/vfs_aio.c:2633: error: dereferencing pointer to incomplete type /src/sys/kern/vfs_aio.c: In function 'freebsd32_olio_listio': /src/sys/kern/vfs_aio.c:2859: error: storage size of 'osig' isn't known cc1: warnings being treated as errors /src/sys/kern/vfs_aio.c:2859: warning: unused variable 'osig' /src/sys/kern/vfs_aio.c: In function 'freebsd32_lio_listio': /src/sys/kern/vfs_aio.c:2904: error: storage size of 'sig32' isn't known /src/sys/kern/vfs_aio.c:2904: warning: unused variable 'sig32' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-11 00:56:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-11 00:56:13 - ERROR: failed to build lint kernel TB --- 2008-12-11 00:56:13 - 6055.20 user 427.31 system 7401.26 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From xcllnt at mac.com Wed Dec 10 17:00:29 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Dec 10 17:00:36 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <26719629@bb.ipt.ru> References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> Message-ID: <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> On Dec 10, 2008, at 4:02 PM, Boris Samorodov wrote: > Seems that just the same card should work: > http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html > > I've added some diagnistic. But 'rid' is not what you want, I guess: The RID is fine. It should always be 0. * > uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: no errors, exiting * > uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: no errors, exiting * > uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: no errors, exiting * > uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: no errors, exiting * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO * > uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > ns8250_probe: got MCR wrong register, exiting with ENXIO It looks like the mapping is wrong. That is, uart(4) gets to probe 8 ports but rejects 6. I would add debugging information to puc(4) and in particular to where resources are assigned to ports so that we can see what the BAR and offsets within the BAR are for each port. FYI, -- Marcel Moolenaar xcllnt@mac.com From bzeeb-lists at lists.zabbadoz.net Wed Dec 10 17:06:47 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Dec 10 17:06:54 2008 Subject: [head tinderbox] failure on ia64/ia64 In-Reply-To: <20081211005613.F115073039@freebsd-current.sentex.ca> References: <20081211005613.F115073039@freebsd-current.sentex.ca> Message-ID: <20081211010452.M97918@maildrop.int.zabbadoz.net> On Wed, 10 Dec 2008, FreeBSD Tinderbox wrote: > [...] > /src/sys/kern/vfs_aio.c:2633: error: dereferencing pointer to incomplete type > /src/sys/kern/vfs_aio.c: In function 'freebsd32_olio_listio': > /src/sys/kern/vfs_aio.c:2859: error: storage size of 'osig' isn't known > cc1: warnings being treated as errors > /src/sys/kern/vfs_aio.c:2859: warning: unused variable 'osig' > /src/sys/kern/vfs_aio.c: In function 'freebsd32_lio_listio': > /src/sys/kern/vfs_aio.c:2904: error: storage size of 'sig32' isn't known > /src/sys/kern/vfs_aio.c:2904: warning: unused variable 'sig32' > *** Error code 1 This should be fixed with r185898 and be gone witht he next round of tb runs. -- Bjoern A. Zeeb The greatest risk is not taking one. From josh.carroll at gmail.com Wed Dec 10 17:45:58 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Wed Dec 10 17:46:04 2008 Subject: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet In-Reply-To: <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> References: <490F47BE.9080205@janh.de> <20081104015235.GC98154@cdnetworks.co.kr> <4910C055.8000505@janh.de> <20081105013558.GA99795@cdnetworks.co.kr> <20081203090658.GJ9639@cdnetworks.co.kr> <37502393@bb.ipt.ru> <20081206023016.GF22093@cdnetworks.co.kr> <539c60b90812081127s4ffb509fnea9d44d4298da666@mail.gmail.com> <8cb6106e0812081252j2b0c8e78g4dcecf8d3770c269@mail.gmail.com> Message-ID: <8cb6106e0812101745l54b23a08k7fbeddeb605f88ea@mail.gmail.com> > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 > rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > class = network > subclass = ethernet > > iperf (ale0 as -s): [ 3] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec > iperf (ale0 as -c): [ 3] 0.0-10.0 sec 1.08 GBytes 931 Mbits/sec > > So all seems well here. Well, I spoke too soon. Overall gigE throughput wise and day to day activities (NAT'd 20 Mbit FiOS) were fine. Tonight, however, I went to watch a 720p video (~4 Mbps bitrate or less) on my Popcorn Hour over NFS which has worked fine in the past. It was extremely "jerky" and unwatchable. Figuring perhaps the Popcorn Hour had an issue, I fired up an NFS server on another box and the video streamed just fine. I then rebooted this box and threw in a trusty old PCI em(4) card, and all is well. I tried playing with these two sysctl knobs for ale0: dev.ale.0.int_rx_mod and dev.ale.0.int_tx_mod I tried setting both to 0 and both to higher numbers on the documented scale (10000 I believe), neither of which helped. I imagine since what I want here is a "smoother" transmission, setting int_tx_mod to 0 is what would have the most effect, but the video still was not playable with it set to 0. I've since disabled the ale0 interface in the BIOS and I'm using the em(4) for now. Is there another knob for ale I should try adjusting? Thanks, Josh From channa.kad at gmail.com Wed Dec 10 21:19:47 2008 From: channa.kad at gmail.com (Channa) Date: Wed Dec 10 21:19:55 2008 Subject: jemalloc performance Vs ptmalloc Message-ID: <515c64960812102119l5e7fb629n1a7e4b551e2c1ab5@mail.gmail.com> Hi, Sorry there was a spell mistake in the prev post. I tried to execute the benchmark test malloc-test to compare the ptmalloc performance and jemalloc performance. jemalloc seems to performance better than ptmalloc under following conditions. - If memory requests are less than 3840Bytes jemalloc is faster than ptmalloc Jemalloc: # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread -1086325424 adjusted timing: 0.893323 seconds for 10000000 requests of 1024 bytes. Thread -1090519728 adjusted timing: 0.893581 seconds for 10000000 requests of 1024 bytes. Thread -1082131120 adjusted timing: 0.983221 seconds for 10000000 requests of 1024 bytes. Thread -1088422576 adjusted timing: 1.346636 seconds for 10000000 requests of 1024 bytes. Thread -1084228272 adjusted timing: 1.394940 seconds for 10000000 requests of 1024 bytes. Ptmalloc: # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread -1208353904 adjusted timing: 2.427992 seconds for 10000000 requests of 1024 bytes. Thread -1239823472 adjusted timing: 2.474918 seconds for 10000000 requests of 1024 bytes. Thread -1218843760 adjusted timing: 2.394854 seconds for 10000000 requests of 1024 bytes. Thread -1250313328 adjusted timing: 3.695654 seconds for 10000000 requests of 1024 bytes. Thread -1229333616 adjusted timing: 5.081604 seconds for 10000000 requests of 1024 bytes. - If memory requests are page aligned i.e large allocations jemalloc is slower than ptmalloc. jemalloc: # ./malloc-test 9300 10000000 5 Starting test with 5 threads... Thread -1077936816 adjusted timing: 4.648531 seconds for 10000000 requests of 9300 bytes. Thread -1086325424 adjusted timing: 4.837230 seconds for 10000000 requests of 9300 bytes. Thread -1080033968 adjusted timing: 4.978933 seconds for 10000000 requests of 9300 bytes. Thread -1084228272 adjusted timing: 7.029323 seconds for 10000000 requests of 9300 bytes. Thread -1082131120 adjusted timing: 7.075402 seconds for 10000000 requests of 9300 bytes. Ptmalloc: # ./malloc-test_glib 9300 10000000 5 Starting test with 5 threads... Thread -1229083760 adjusted timing: 2.860437 seconds for 10000000 requests of 9300 bytes. Thread -1250063472 adjusted timing: 3.254859 seconds for 10000000 requests of 9300 bytes. Thread -1218593904 adjusted timing: 4.334052 seconds for 10000000 requests of 9300 bytes. Thread -1208104048 adjusted timing: 4.139268 seconds for 10000000 requests of 9300 bytes. Thread -1239573616 adjusted timing: 5.396595 seconds for 10000000 requests of 9300 bytes. So jemalloc takes more time for Large allocations than ptmalloc. For Huge allocations freater than 1MB again jemalloc is faster than ptmalloc. i tested this on 4 CPU intel x86 machine. Could you please tell me if there is any method to increase the performance for Large allocations.? I tried to increase the bins by setting the PAGE_SHIFT to 13 that time the performance of jemalloc was better for allocations till 7936. As per my analysis using bins for all allocations less than 1MB reduces the time taken but which may not be correct. I am trying to modify the Large allocations to increase the performance, Could you suggest some ideas. Thanks in Advance, Channa From mike at jellydonut.org Wed Dec 10 21:23:06 2008 From: mike at jellydonut.org (Michael Proto) Date: Wed Dec 10 21:23:18 2008 Subject: behavioral change of "read" builtin for sh on 8-CURRENT In-Reply-To: <87zlj390vw.fsf@kobe.laptop> References: <1de79840812092149t4d212027o2c908635419fa838@mail.gmail.com> <87zlj390vw.fsf@kobe.laptop> Message-ID: <1de79840812102123p2144fb37hc9a0b2c958061c34@mail.gmail.com> Thanks! PR 129566 filed on this issue. -Proto On Wed, Dec 10, 2008 at 4:27 PM, Giorgos Keramidas wrote: > Hi Michael, > > This looks like a bug in 8.0-CURRENT. > > Can you please file a bug report and include the text you sent below? > > On Wed, 10 Dec 2008 00:49:58 -0500, "Michael Proto" > wrote: > > I've noticed a behavioral difference of the "read" builtin statement > within > > /bin/sh on CURRENT and I'm hoping someone can point me in the right > > direction on how to restore the old behavior. > > > > I have a /bin/sh script that accepts input for IP address information: > > > > #!/bin/sh > > set -x > > DEFINT=vr0 > > DEFIP=192.168.0.1 > > DEFMASK=255.255.255.0 > > read -p "Enter network interface [$DEFINT]: " -t 5 INT > > read -p "Enter IP address [$DEFIP]: " -t 5 IP > > read -p "Enter netmask [$DEFMASK]: " -t 5 MASK > > echo ${INT:=$DEFINT} : ${IP:=$DEFIP}/${MASK:=$DEFMASK} > > > > This script waits for terminal input for each of the above variables > (INT, > > IP, MASK) and defaults to a script-provided value if no input is entered > in > > 5 seconds for each variable. On 6.x and 7.x if I simply hit Enter at the > > prompt (and don't provide any input) no value is assigned to the variable > so > > my INT, IP, and MASK variables are set to null and the parameter > > substitution of the DEF* variables works as expected. > > > > On 8-CURRENT if I hit Enter with no input at the prompt the system seems > to > > recognize the newline as input and continues to sit there until I hit > Enter > > again. When I do this there appears to be a strange unprintable value > > assigned to the INT, IP, and MASK variables yet the variable subsitution > > doesn't work correctly. > > > > The man page on sh lists the following behavior for read: > > > > read [-p prompt] [-t timeout] [-er] variable ... > > The prompt is printed if the -p option is specified and the > > stan- > > dard input is a terminal. Then a line is read from the > > standard > > input. The trailing newline is deleted from the line and > the > > line is split as described in the section on White Space > > Splitting (Field Splitting) above, and the pieces are > assigned > > to > > the variables in order. If there are more pieces than > > variables, > > the remaining pieces (along with the characters in IFS that > > sepa- > > rated them) are assigned to the last variable. If there are > > more > > variables than pieces, the remaining variables are assigned > the > > null string. > > > > > > As I interpret this, read should delete the trailing newline and assign a > > null value since there is is no "input" before the newline. Then the > > variable substitution should take over and assign the DEF* variables > > appropriately. 6 and 7 follow this but 8 does not. > > > > Here's the output of the script (with set -x) to help show what I'm > seeing. > > > > This is on 6 and 7: > > > > + DEFINT=vr0 > > + DEFIP=192.168.0.1 > > + DEFMASK=255.255.255.0 > > + read -p Enter network interface [vr0]: -t 5 INT > > Enter network interface [vr0]: > > + read -p Enter IP address [192.168.0.1]: -t 5 IP > > Enter IP address [192.168.0.1]: > > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > > Enter netmask [255.255.255.0]: > > + echo vr0 : 192.168.0.1/255.255.255.0 > > vr0 : 192.168.0.1/255.255.255.0 > > > > > > And this is what I see with 8: > > > > + DEFINT=vr0 > > + DEFIP=192.168.0.1 > > + DEFMASK=255.255.255.0 > > + read -p Enter network interface [vr0]: -t 5 INT > > Enter network interface [vr0]: > > + read -p Enter IP address [192.168.0.1]: -t 5 IP > > Enter IP address [192.168.0.1]: > > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > > Enter netmask [255.255.255.0]: > > /: cho > > /: > > > > Strange that the "echo" statement is missing the first "e" character in > the > > debug output. > > > > Even stranger on 8-CURRENT, if I *do* enter input before the newline (say > I > > change the IP address or the network interface), the first character is > not > > echoed back to the screen but is still saved to the variable. Here's an > > example when I run the script and provide input at each prompt: > > > > + DEFINT=vr0 > > + DEFIP=192.168.0.1 > > + DEFMASK=255.255.255.0 > > + read -p Enter network interface [vr0]: -t 5 INT > > Enter network interface [vr0]: r0 > > + read -p Enter IP address [192.168.0.1]: -t 5 IP > > Enter IP address [192.168.0.1]: 92.168.0.1 > > + read -p Enter netmask [255.255.255.0]: -t 5 MASK > > Enter netmask [255.255.255.0]: 55.255.255.0 > > + echo br0 : 192.168.0.1/255.255.255.0 > > br0 : 192.168.0.1/255.255.255.0 > > + echo ifconfig br0 inet 192.168.0.1 netmask 255.255.255.0 > > > > Notice that when I'm prompted, the first character doesn't echo but is > still > > saved in the variable. > > > > > > Does anyone else see this same behavior? Any ideas on how to reset it > back > > to how it works in STABLE? I'm not doing anything special with IFS so I'm > > stumped on how to troubleshoot this. > > > > > > > > Thanks, > > Proto > > _______________________________________________ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > > > > -- > From randy at psg.com Wed Dec 10 21:35:03 2008 From: randy at psg.com (Randy Bush) Date: Wed Dec 10 21:35:10 2008 Subject: panic: sleeping thread & bufwrite: buffer is not busy??? Message-ID: <4940A685.7040608@psg.com> i386 soekris 5501 current as of Dec 11 00:27 gmt Unread portion of the kernel message buffer: Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock panic: sleeping thread panic: bufwrite: buffer is not busy??? Uptime: 2m1s Physical memory: 503 MB #0 doadump () at pcpu.h:246 #1 0xc0571f33 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc05720f7 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc06fc75c in ffs_bufwrite (bp=0xc2937e20) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1786 #4 0xc05c7250 in vfs_bio_awrite (bp=0xc2937e20) at buf.h:385 #5 0xc05cfee0 in vop_stdfsync (ap=0xc2a89b34) at /usr/src/sys/kern/vfs_default.c:479 #6 0xc0520ad3 in devfs_fsync (ap=0xc2a89b34) at /usr/src/sys/fs/devfs/devfs_vnops.c:485 #7 0xc074e50e in VOP_FSYNC_APV (vop=0xc07cc800, a=0xc2a89b34) at vnode_if.c:1007 #8 0xc06fd0a2 in ffs_sync (mp=0xc2e33c80, waitfor=2, td=0xc2c28480) at vnode_if.h:529 #9 0xc05e0803 in sync (td=0xc2c28480, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:149 #10 0xc0571ad2 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:312 #11 0xc05720f7 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:576 #12 0xc059ec81 in propagate_priority (td=0xc2e696c0) at /usr/src/sys/kern/subr_turnstile.c:222 #13 0xc059f551 in turnstile_wait (ts=0xc2c0ee10, owner=0xc2e696c0, queue=Variable "queue" is not available.) at /usr/src/sys/kern/subr_turnstile.c:738 #14 0xc0570c73 in _rw_wlock_hard (rw=0xc2cdcd80, tid=3267527808, file=0x0, line=0) at /usr/src/sys/kern/kern_rwlock.c:705 #15 0xc06bdcb6 in in6_mtutimo (rock=0xc2cdcd00) at /usr/src/sys/netinet6/in6_rmx.c:437 #16 0xc0580f77 in softclock (arg=0xc07ffbe0) at /usr/src/sys/kern/kern_timeout.c:398 #17 0xc055790a in intr_event_execute_handlers (p=0xc2c257ec, ie=0xc2c22400) at /usr/src/sys/kern/kern_intr.c:1134 #18 0xc0558933 in ithread_loop (arg=0xc2c07ba0) at /usr/src/sys/kern/kern_intr.c:1147 #19 0xc0555cb6 in fork_exit (callout=0xc05588d0 , arg=0xc2c07ba0, frame=0xc2a89d38) at /usr/src/sys/kern/kern_fork.c:821 #20 0xc0730a50 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 From rea-fbsd at codelabs.ru Thu Dec 11 00:50:27 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Dec 11 00:50:34 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> Message-ID: Marcel, Boris, good day. Wed, Dec 10, 2008 at 05:00:24PM -0800, Marcel Moolenaar wrote: > > Seems that just the same card should work: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html > > > > I've added some diagnistic. But 'rid' is not what you want, I guess: > > The RID is fine. It should always be 0. Seems like a dumb question, but nevertheless. What I don't understand is the following: BAR to port mapping for the Timedia is tricky, it mixes BARs and offsets for the different ports (you should know this, since you wrote the support ;)). But in uart_bus_probe you're passing rid = 0 and it is used for resource allocation and consequently the same rid is used for all ports (at least I read the code in this way). But puc_get_bar() uses calculated rid values, but does essentially the same thing: resource allocation via bus_alloc_resource(). And sc->sc_bas is initialized from the obtained sc->sc_rres (inside uart_bus_probe) and it is subsequently used for ns8250_probe() that is failing. I see that uart_bus_pci.c calls uart_bus_probe() with the actual rid. It does not mean that puc code should do the same, but ... Boris, could you please add the line ----- printf("%s: BAS, handle is 0x%lx, tag is 0x%x\n", __func__, (unsigned long)bas->bsh, (unsigned int)bas->bst); ----- to the beginning of ns8250_probe() and show the results. Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081211/004c47df/attachment.pgp From yanefbsd at gmail.com Thu Dec 11 01:40:42 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 11 01:40:49 2008 Subject: make buildworld failed! In-Reply-To: <1228869506.1255.3.camel@www.boolome.cn> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> <1228869506.1255.3.camel@www.boolome.cn> Message-ID: <7d6fde3d0812110140y44df387dg14f83c5483fe96ff@mail.gmail.com> On Tue, Dec 9, 2008 at 4:38 PM, boolome wrote: > ? 2008-12-09?? 03:18 -0800?Garrett Cooper??? >> On Dec 8, 2008, at 5:48 PM, boolome wrote: >> >> > ? 2008-12-08?? 01:55 -0800?Garrett Cooper??? >> >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: >> >> [snip] >> >> >> >> Looks like your source tree is incomplete. >> >> -Garrett >> > >> > But have cvsup the latest source tree ! >> >> It's not necessarily your fault though. What cvsup server are you >> using and did you interrupt it during an update? >> -Garrett > > The cvsup server is cvsup.freebsd.org . > > During an update ,I did not interrupt it. > > But when I got to that dir executed :make obj && make depend && > make ,successed.. > > Is the soure tree's problem ? > By the way I 'am using a custom kernel . Hmmm.. not sure. If I had logs I could help you out more, but unfortunately I don't ;(. I'd chock it up to a bad build environment or maybe just bad prebuilt objs. -Garrett From gary.jennejohn at freenet.de Thu Dec 11 03:09:12 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Dec 11 03:09:19 2008 Subject: svn commit: r185756 - head/sys/dev/re In-Reply-To: <4940115F.7080004@citrin.ru> References: <200812080248.mB82mfV9043154@svn.freebsd.org> <4940115F.7080004@citrin.ru> Message-ID: <20081211120908.57f99124@ernst.jennejohn.org> On Wed, 10 Dec 2008 21:58:39 +0300 Anton Yuzhaninov wrote: > Pyun YongHyeon wrote: > > Author: yongari > > Date: Mon Dec 8 02:48:41 2008 > > New Revision: 185756 > > URL: http://svn.freebsd.org/changeset/base/185756 > > > > Log: > > Reduce spin wait time consumed in GMII register access routines. > > Waiting for 1ms for each GMII register access looks overkill and it > > may also decrease overall performance of driver because re(4) > > invokes mii_tick for every hz. > > > > Tested by: rpaulo > > > > Modified: > > head/sys/dev/re/if_re.c > > > > Modified: head/sys/dev/re/if_re.c > > ============================================================================== > > --- head/sys/dev/re/if_re.c Mon Dec 8 02:38:13 2008 (r185755) > > +++ head/sys/dev/re/if_re.c Mon Dec 8 02:48:41 2008 (r185756) > > @@ -417,13 +417,12 @@ re_gmii_readreg(device_t dev, int phy, i > > } > > > > CSR_WRITE_4(sc, RL_PHYAR, reg << 16); > > - DELAY(1000); > > > > for (i = 0; i < RL_TIMEOUT; i++) { > > + DELAY(30); > > rval = CSR_READ_4(sc, RL_PHYAR); > > if (rval & RL_PHYAR_BUSY) > > break; > > - DELAY(100); > > } > > > > if (i == RL_TIMEOUT) { > > @@ -445,13 +444,12 @@ re_gmii_writereg(device_t dev, int phy, > > > > CSR_WRITE_4(sc, RL_PHYAR, (reg << 16) | > > (data & RL_PHYAR_PHYDATA) | RL_PHYAR_BUSY); > > - DELAY(1000); > > > > for (i = 0; i < RL_TIMEOUT; i++) { > > + DELAY(30); > > rval = CSR_READ_4(sc, RL_PHYAR); > > if (!(rval & RL_PHYAR_BUSY)) > > break; > > - DELAY(100); > > } > > > > if (i == RL_TIMEOUT) { > > After this commit I see in logs errors: > > Dec 10 21:37:42 citrin kernel: re0: PHY read failed > Dec 10 21:38:05 citrin last message repeated 3 times > Dec 10 21:38:44 citrin last message repeated 3 times > Dec 10 21:38:44 citrin kernel: re0: link state changed to DOWN > Dec 10 21:38:45 citrin kernel: re0: link state changed to UP > Dec 10 21:38:55 citrin kernel: re0: PHY read failed > Dec 10 21:39:38 citrin last message repeated 3 times > Dec 10 21:39:38 citrin kernel: re0: link state changed to DOWN > Dec 10 21:39:39 citrin kernel: re0: link state changed to UP > Dec 10 21:40:09 citrin kernel: re0: PHY read failed > Dec 10 21:40:21 citrin kernel: re0: PHY read failed > Dec 10 21:41:03 citrin kernel: re0: PHY read failed > > I tried to revert this patch - errors disappeared. > I was seeing these errors too, but disabling MSI made them disappear. --- Gary Jennejohn From Alexander at Leidinger.net Thu Dec 11 04:54:52 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Dec 11 04:54:59 2008 Subject: DTrace probes for geom_kern, geom_io and geom_event In-Reply-To: References: Message-ID: <20081211135438.52433nmj45ia112c@webmail.leidinger.net> Quoting Marius N?nnerich (from Wed, 10 Dec 2008 23:15:43 +0100): > After some tips from Alexander Leidinger I updated the patch, new > version here: > http://nuenneri.ch/freebsd/geom_probes2.patch Again: I just reviewed the patch, so I don't have the complete context of the functions, just what I see in the patch (-> high level dtrace review, not geom specific probe review). Still inconsistent locking probes. Lock is fired without the lock held, unlock is fired with the lock held. Both should IMHO be fired either with the lock held or without the lock held, but not with the current mix. g_new_bio/g_io_schedule_up: the return probe has the name "entry" in your patch. A msleep probe could give some more info (sometimes there are even zero arguments, but there are 3-5 things which could be interesting to know). Similar for tsleep (the time should be provided in the probe arguments too). I don't think we need "loop" probes. Given that g_trace is a debugging function and that dtrace is superior, I don't think you need to instrument g_trace with dtrace probes. g_topology_lock/unlock should provide the lock in the probe arguments. Again, see above, either both probes firing with the lock, or without the lock, but not mixed as it is. > There are some questions I'd like to discuss: > 2. Should I use the full function name for the probes (with the g_ > prefix) even though it's defined under the provider geom IMHO yes, it's more easy for the person grepping around, as "bioq" can be found in a lot of unrelated places, but "g_bioq_init" only in places where you want to know about. > 3. Should there be a probe for every switch case in g_io_check? I > think this won't work with the fall-through that is used right now IMHO at least in every code block which is doing something sensible. Dtrace is not expensive, having a lot of probes does not hurt (except maybe in a critical path). You could fire an read_not_permitted probe, or a write_not_permitted probe or whatever. This can be done additionally to the return probe. This way it's very easy to see if there's a permission problem, without the need to write errno checks in dtrace. If you have a lot of returns but only a handful of permission errors, it's better to have some specific probes which can be fired. Keep in mind dtrace is designed to be used to debug problems on production systems. > 4. Alexander proposed to change the module name kern to core. I'm not > sure about this as kern refers to the filename, like io and event do - core for kern - core_io for io (maybe) - core_event for event (maybe) This way you can use gmirror, graid3, ... later as module names and people/sysadmins without much GEOM knowledge don't have a problem to see distinguish with real GEOM core stuff and stuff in GEOM providers. > 7. What about g_bioq_(un)lock functions, I just added one probe for > it, I do not really see a point in adding entry and return probes > (they are there with FBT anyway). This is consistent with > g_topology_lock etc. What about making macros of the two functions > like g_topology_lock Regarding FBT: the advantage of the geom dtrace-provider is that you can tell to give everything for geom, while with with the fbt dtrace-provider you need to know the naming conventions in the kernel. So while you have in fbt the possibility to get access to the probes, the sysadmin which does not know much about GEOM can get a meaningful overview in case entry and return probes available in the geom dtrace-provider. A lot of places in the kernel do not have a naming convention like GEOM, so when we handle them (e.g. the linuxulator), we need to add entry/return probes so that sysadmins without knowledge about kernel internals can search for solutions of their problems. We should be consistent in our probe naming, else it's not easy to use dtrace. > 9. Writing hundreds of entry and return probes is boring, especially > as there is the FBT provider. Maybe it's possible to give the FBT > probes better names like geom:io:g_io_schedule_down:entry instead of > fbt:kernel:g_io_schedule:entry. Every FBT probe has a provider of fbt > und module of kernel right now. One also has to define the argument > types which I think FBT figures out by itself. If this would work we > could concentrate on adding SDT probes to interesting places inside of > functions or macros Both ways have good and bad parts. One argument against this is to stay synchronized with vendor code. Another one is complexity to handle this (currently the fbt part is automatic, I don't see a way to handle related stuff which is spread into several places to within the same namespace without introducing hints into different places which tells what belongs where). HTH, Alexander. -- "They shot him five times. But he's though." -- Santino Corleone, "Chapter 2", page 79 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From CQG00620 at nifty.ne.jp Thu Dec 11 05:00:58 2008 From: CQG00620 at nifty.ne.jp (WATANABE Kazuhiro) Date: Thu Dec 11 05:01:11 2008 Subject: [patch] de(4) has not worked on 8-current since Feb 13 In-Reply-To: <200812101539.26031.jhb@freebsd.org> References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <200812101539.26031.jhb@freebsd.org> Message-ID: <20081211130056.66F69590F5@mail.asahi-net.or.jp> Thanks for your quick reply. First, I restored busdma_machdep.c and applied your patch. Then I re-compiled a kernel and rebooted the system. Unfortunately it causes kernel panic when the system enters multi user mode. Here is an output of kgdb. $ kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Copyright (c) 1992-2008 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 8.0-CURRENT #6: Thu Dec 11 13:45:26 JST 2008 nabe@capricorn:/FreeBSD/obj/i386/HEAD/FreeBSD/HEAD/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (751.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 268435456 (256 MB) avail memory = 243986432 (232 MB) kbd1 at kbdmux0 ACPI Error (tbxfroot-0308): A valid RSDP was not found [20070320] ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xd4000000-0xd4ffffff,0xd6000000-0xd6000fff irq 11 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xd000-0xd01f irq 12 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered piix0: port 0x5000-0x500f at device 7.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 9.0 (no driver attached) xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xd800-0xd87f mem 0xd9000000-0xd900007f irq 12 at device 11.0 on pci0 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:04:xx:xx:xx xl0: [ITHREAD] pci0: at device 13.0 (no driver attached) de0: port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 11 at device 15.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.2 de0: WARNING: using obsoleted if_watchdog interface de0: Ethernet address: 00:00:f4:xx:xx:xx de0: [ITHREAD] cpu0 on motherboard smist0: on cpu0 device_attach: smist0 attach returned 6 pmtimer0 on isa0 atrtc0: at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0 atkbdc0: at port 0x60,0x64 irq 1 pnpid PNP0303 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] unknown: can't assign resources (memory) unknown: can't assign resources (port) uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 pnpid PNP0501 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) fdc1: at port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 pnpid PNP0700 on isa0 fdc1: [FILTER] ppc0: at port 0x378-0x37f irq 7 pnpid PNP0400 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 pnpid PNP0501 on isa0 uart1: [FILTER] orm0: at iomem 0xc0000-0xc97ff,0xcc000-0xcc7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0: No FDOUT register! unknown: can't assign resources (memory) unknown: can't assign resources (port) Timecounter "TSC" frequency 751707385 Hz quality 800 Timecounters tick every 1.000 msec ad0: 6194MB at ata0-master UDMA33 acd0: CDROM at ata0-slave PIO4 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s2a lock order reversal: 1st 0xc2951044 user map (user map) @ /FreeBSD/HEAD/src/sys/vm/vm_map.c:3115 2nd 0xc2ac87ac ufs (ufs) @ /FreeBSD/HEAD/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c0be23c3,c267b90c,c08729c5,4,c0bdd802,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bdd802,c2905728,c2909f78,c267b968,...) at kdb_backtrace+0x29 _witness_debugger(c0be50ba,c2ac87ac,c0bd88ba,c2909f78,c0bebfa9,...) at _witness_debugger+0x25 witness_checkorder(c2ac87ac,1,c0bebfa9,81f,0,...) at witness_checkorder+0x839 __lockmgr_args(c2ac87ac,200501,c2ac87c8,0,0,...) at __lockmgr_args+0x237 ffs_lock(c267ba78,c087276b,c0c083c6,200501,c2ac8754,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0ce88e0,c267ba78,c294ce24,c0cfc9c0,c2ac8754,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c2ac8754,200501,c0bebfa9,81f,4,...) at _vn_lock+0x5e vget(c2ac8754,200501,c294cd80,4b4,0,...) at vget+0xc9 vnode_pager_lock(c187d744,0,c0c0592a,127,c267bc18,...) at vnode_pager_lock+0x1e0 vm_fault(c2951000,80db000,2,8,80db460,...) at vm_fault+0x1df trap_pfault(5,0,c0c15785,2e7,c294ad34,...) at trap_pfault+0x118 trap(c267bd38) at trap+0x289 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. <118>/dev/ad0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ad0s2a: clean, 338407 free (4679 frags, 41716 blocks, 0.9% fragmentation) Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex network driver (de0) r = 0 (0xc2a3ec40) locked @ /FreeBSD/HEAD/src/sys/dev/de/if_de.c:3880 KDB: stack backtrace: db_trace_self_wrapper(c0be23c3,c2727a54,c08729c5,c0babaac,f28,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0babaac,f28,ffffffff,c0e71824,c2727a8c,...) at kdb_backtrace+0x29 _witness_debugger(c0be4685,c2727aa0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0c15785,c2a67480,c294a7ec,...) at witness_warn+0x1fd trap(c2727b2c) at trap+0x152 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0b11bd8, esp = 0xc2727b6c, ebp = 0xc2727b88 --- _bus_dmamap_count_pages(c2a46600,1533000,c2c2d000,7f0,1,...) at _bus_dmamap_count_pages+0x18 bus_dmamap_load_mbuf(c2a46600,1533000,c2beab00,c05ed570,c2720040,...) at bus_dmamap_load_mbuf+0xb4 tulip_rx_intr(c2a3ec40,4,c0babaac,e0f,0,...) at tulip_rx_intr+0x45c tulip_tx_intr(c2a3ec40,4,c0babaac,eba,c2a3e800,...) at tulip_tx_intr+0xf9 tulip_intr_handler(c2a3ec40,0,c0babaac,f28,c2a38cc0,...) at tulip_intr_handler+0x2a4 tulip_intr_normal(c2a3e800,0,0,0,c2947bb8,...) at tulip_intr_normal+0x3c intr_event_execute_handlers(c294a7ec,c2947b80,c0d35580,c2727cf8,c2947bf0,...) at intr_event_execute_handlers+0x125 ithread_loop(c2a615a0,c2727d38,c0bdaf6d,32d,c294a7ec,...) at ithread_loop+0x9f fork_exit(c0813920,c2a615a0,c2727d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2727d70, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1533008 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0b11bd8 stack pointer = 0x28:0xc2727b6c frame pointer = 0x28:0xc2727b88 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq11: de0) panic: from debugger cpuid = 0 Uptime: 24s Physical memory: 239 MB Dumping 32 MB: 17 1 #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc08338ce in boot (howto=260) at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:420 #2 0xc0833ba2 in panic (fmt=Variable "fmt" is not available. ) at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:576 #3 0xc04bd387 in db_panic (addr=Could not find the frame base for "db_panic". ) at /FreeBSD/HEAD/src/sys/ddb/db_command.c:478 #4 0xc04bd9b1 in db_command (last_cmdp=0xc0cfe0dc, cmd_table=0x0, dopager=1) at /FreeBSD/HEAD/src/sys/ddb/db_command.c:445 #5 0xc04bdb0a in db_command_loop () at /FreeBSD/HEAD/src/sys/ddb/db_command.c:498 #6 0xc04bf96d in db_trap (type=12, code=0) at /FreeBSD/HEAD/src/sys/ddb/db_main.c:229 #7 0xc08611b6 in kdb_trap (type=12, code=0, tf=0xc2727b2c) at /FreeBSD/HEAD/src/sys/kern/subr_kdb.c:534 #8 0xc0b3152f in trap_fatal (frame=0xc2727b2c, eva=22229000) at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:920 #9 0xc0b31e70 in trap (frame=0xc2727b2c) at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:318 #10 0xc0b162ab in calltrap () at /FreeBSD/HEAD/src/sys/i386/i386/exception.s:165 #11 0x01533008 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) list /FreeBSD/HEAD/src/sys/dev/de/if_de.c:3880 3875 static void 3876 tulip_intr_normal(void *arg) 3877 { 3878 tulip_softc_t * sc = (tulip_softc_t *) arg; 3879 3880 TULIP_LOCK(sc); 3881 #if defined(TULIP_DEBUG) 3882 sc->tulip_dbg.dbg_intrs++; 3883 #endif 3884 tulip_intr_handler(sc); (kgdb) At Wed, 10 Dec 2008 15:39:25 -0500, John Baldwin wrote: > On Wednesday 10 December 2008 07:56:25 am WATANABE Kazuhiro wrote: > > Hi, all. > > > > My de(4) NICs has not worked on 8-current since Feb 13. > > Try this patch to de(4) instead. It removes the alignment requirement for TX > buffers since the 4-byte alignment is only required for RX. > > Index: if_de.c > =================================================================== > --- if_de.c (revision 185867) > +++ if_de.c (working copy) > @@ -4491,7 +4491,8 @@ > /* Allocate memory for a single descriptor ring. */ > static int > tulip_busdma_allocring(device_t dev, tulip_softc_t * const sc, size_t count, > - bus_size_t maxsize, int nsegs, tulip_ringinfo_t *ri, const char *name) > + bus_size_t alignment, bus_size_t maxsize, int nsegs, tulip_ringinfo_t *ri, > + const char *name) > { > size_t size; > int error, i; > @@ -4527,7 +4528,7 @@ > } > > /* Allocate a tag for the data buffers. */ > - error = bus_dma_tag_create(NULL, 4, 0, > + error = bus_dma_tag_create(NULL, alignment, 0, > BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, > maxsize, nsegs, TULIP_DATA_PER_DESC, 0, NULL, NULL, &ri->ri_data_tag); > if (error) { > @@ -4586,8 +4587,8 @@ > /* > * Allocate space and dmamap for transmit ring. > */ > - error = tulip_busdma_allocring(dev, sc, TULIP_TXDESCS, TULIP_DATA_PER_DESC, > - TULIP_MAX_TXSEG, &sc->tulip_txinfo, "transmit"); > + error = tulip_busdma_allocring(dev, sc, 1, TULIP_TXDESCS, > + TULIP_DATA_PER_DESC, TULIP_MAX_TXSEG, &sc->tulip_txinfo, "transmit"); > if (error) > return (error); > > @@ -4598,7 +4599,7 @@ > * a waste in practice though as an ethernet frame can easily fit > * in TULIP_RX_BUFLEN bytes. > */ > - error = tulip_busdma_allocring(dev, sc, TULIP_RXDESCS, MCLBYTES, 1, > + error = tulip_busdma_allocring(dev, sc, 4, TULIP_RXDESCS, MCLBYTES, 1, > &sc->tulip_rxinfo, "receive"); > if (error) > return (error); --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From CQG00620 at nifty.ne.jp Thu Dec 11 05:00:58 2008 From: CQG00620 at nifty.ne.jp (WATANABE Kazuhiro) Date: Thu Dec 11 05:01:12 2008 Subject: [patch] de(4) has not worked on 8-current since Feb 13 In-Reply-To: <494019AB.3020505@samsco.org> References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <494019AB.3020505@samsco.org> Message-ID: <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> CC'ed to freebsd-current. At Wed, 10 Dec 2008 12:34:03 -0700, Scott Long wrote: > WATANABE Kazuhiro wrote: > > Hi, all. > > > > My de(4) NICs has not worked on 8-current since Feb 13. > > > > > > Can you define "not worked" a little better? Does it give errors, or > corrupt data, or appear to not transmit and/or receive? > > Scott Thanks for your reply. I should have written more details about the problem... On recent 8-current, my de(4) NICs cannot send any (almost all) data from it. * The system boots normally. * Probing/attaching the de(4) NICs are done successfully. * The system can receive data from the other hosts. For example the following command was finished normally in 14 seconds: $ /usr/bin/time scp other_host:/boot/kernel/kernel . Password: kernel 100% 4717KB 471.7KB/s 00:10 14.03 real 0.53 user 0.40 sys $ * The system cannot send any data to the other hosts. For example the following command was "stalled" and never finished (I interrupted the command after 5 minutes). None of the data were sent: $ /usr/bin/time scp /boot/kernel/kernel other_host: Password: kernel 1% 192KB 0.0KB/s - stalled -^CKilled by signal 2. 336.01 real 0.05 user 0.17 sys $ * The system doesn't show any error/warning messages. * I can "slogin" from the other hosts to the system, and some small amount of text output (ex. an output of "dmesg") are done successfully. But a bit large amount of text output are stopped after a few seconds. For example: $ ls -l /boot/kernel/kernel -r-xr-xr-x 1 root wheel 10975839 Dec 11 13:46 /boot/kernel/kernel $ hd /boot/kernel/kernel | head 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| 00000050 04 00 00 00 03 00 00 00 d4 00 00 00 d4 00 40 c0 |..............@.| 00000060 d4 00 40 c0 0d 00 00 00 0d 00 00 00 04 00 00 00 |..@.............| 00000070 01 00 00 00 01 00 00 00 00 00 00 00 00 00 40 c0 |..............@.| 00000080 00 00 40 c0 a0 ca 81 00 a0 ca 81 00 05 00 00 00 |..@.............| 00000090 00 10 00 00 01 00 00 00 a0 ca 81 00 a0 da c1 c0 |................| $ hd /boot/kernel/kernel 00000000 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF............| 00000010 02 00 03 00 01 00 00 00 e0 c5 46 c0 34 00 00 00 |..........F.4...| 00000020 58 22 92 00 00 00 00 00 34 00 20 00 05 00 28 00 |X"......4. ...(.| 00000030 23 00 20 00 06 00 00 00 34 00 00 00 34 00 40 c0 |#. .....4...4.@.| 00000040 34 00 40 c0 a0 00 00 00 a0 00 00 00 05 00 00 00 |4.@.............| (snip) 00005d90 0a 20 00 00 0b 00 00 00 00 00 00 00 70 15 00 00 |. ..........p...| 00005da0 ce 2a 00 00 36 23 00 00 c6 2a 00 00 0b 14 00 00 |.*..6#...*......| 00005db0 7c 03 00 00 b1 27 00 00 d9 1e 00 00 2e 15 00 00 ||....'..........| 00005dc0 00 00 00 00 6d 22 00 00 04 2a 00 00 72 23 00 00 |....m"...*..r#..| 00005dd0 00 00 00 00 00 00 00 00 d3 1f 00 00 00 00 00 00 |................| (Stopped here. 0x5de0 == 24032 bytes) --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From bsam at ipt.ru Thu Dec 11 06:16:56 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Dec 11 06:17:04 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> (Marcel Moolenaar's message of "Wed\, 10 Dec 2008 17\:00\:24 -0800") References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> Message-ID: <05268378@bb.ipt.ru> Marcel Moolenaar writes: > On Dec 10, 2008, at 4:02 PM, Boris Samorodov wrote: > >> Seems that just the same card should work: >> http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html >> >> I've added some diagnistic. But 'rid' is not what you want, I guess: > > The RID is fine. It should always be 0. > > * >> uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 > >> ns8250_probe: no errors, exiting > * >> uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: no errors, exiting > * >> uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: no errors, exiting > * >> uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: no errors, exiting > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > * >> uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 >> ns8250_probe: got MCR wrong register, exiting with ENXIO > > It looks like the mapping is wrong. That is, uart(4) gets to > probe 8 ports but rejects 6. I would add debugging information > to puc(4) and in particular to where resources are assigned > to ports so that we can see what the BAR and offsets within the > BAR are for each port. If I understand you correctly, here it is: ----- pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x1409, dev=0x7168, revid=0x01 domain=0, bus=5, slot=2, func=0 class=07-00-02, hdrtype=0x00, mfdev=0 cmdreg=0x0081, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type I/O Port, range 32, base 0xec00, size 5, enabled pcib5: requested I/O range 0xec00-0xec1f: in range map[14]: type I/O Port, range 32, base 0xe880, size 4, enabled pcib5: requested I/O range 0xe880-0xe88f: in range map[18]: type I/O Port, range 32, base 0xe800, size 3, enabled pcib5: requested I/O range 0xe800-0xe807: in range map[1c]: type I/O Port, range 32, base 0xe480, size 3, enabled pcib5: requested I/O range 0xe480-0xe487: in range map[20]: type I/O Port, range 32, base 0xe400, size 3, enabled pcib5: requested I/O range 0xe400-0xe407: in range map[24]: type I/O Port, range 32, base 0xe080, size 3, enabled pcib5: requested I/O range 0xe080-0xe087: in range pcib5: matched entry for 5.2.INTA pcib5: slot 2 INTA hardwired to IRQ 18 puc_config_timedia: entering with command 4 puc_config_timedia: command PUC_CFG_GET_NPORTS, result = 8, no errors, exiting puc_config_timedia: entering with command 1 puc_config_timedia: command PUC_CFG_GET_DESC, exiting puc_config_timedia: entering with command 4 puc_config_timedia: command PUC_CFG_GET_NPORTS, result = 8, no errors, exiting puc_config_timedia: entering with command 1 puc_config_timedia: command PUC_CFG_GET_DESC, exiting puc0: port 0xec00-0xec1f,0xe880-0xe88f,0xe800-0xe807,0xe480-0xe487,0xe400-0xe407,0xe080-0xe087 irq 18 at device 2.0 on pci5 puc_config_timedia: entering with command 4 puc_config_timedia: command PUC_CFG_GET_NPORTS, result = 8, no errors, exiting puc_config_timedia: entering with command 8 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 16, no errors, exiting puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xec00 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 16, no errors, exiting puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 8, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 20, no errors, exiting puc0: Reserved 0x10 bytes for rid 0x14 type 4 at 0xe880 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 20, no errors, exiting puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 8, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 24, no errors, exiting puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xe800 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 28, no errors, exiting puc0: Reserved 0x8 bytes for rid 0x1c type 4 at 0xe480 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 32, no errors, exiting puc0: Reserved 0x8 bytes for rid 0x20 type 4 at 0xe400 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 7 puc_config_timedia: command PUC_CFG_GET_TYPE, result = 1, no errors, exiting puc_config_timedia: entering with command 6 puc_config_timedia: command PUC_CFG_GET_RID, result = 36, no errors, exiting puc0: Reserved 0x8 bytes for rid 0x24 type 4 at 0xe080 puc_config_timedia: entering with command 5 puc_config_timedia: command PUC_CFG_GET_OFS, result = 0, no errors, exiting puc_config_timedia: entering with command 3 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 0 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc_config_timedia: entering with command 2 puc_config_timedia: command default, no (?) errors, exiting puc_config_timedia: error ENXIO, exiting puc0: [FILTER] ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From bsam at ipt.ru Thu Dec 11 06:36:29 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Dec 11 06:36:36 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: (Eygene Ryabinkin's message of "Thu\, 11 Dec 2008 11\:50\:24 +0300") References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> Message-ID: <94541668@bb.ipt.ru> Hello Eygene, Marcel and All, I've found some DOS/Linux docs/programs at the producers's site and unzipped them: ftp://ftp.ipt.ru/pub/sunix/ Eygene Ryabinkin writes: > Boris, could you please add the line > ----- > printf("%s: BAS, handle is 0x%lx, tag is 0x%x\n", __func__, > (unsigned long)bas->bsh, (unsigned int)bas->bst); > ----- > to the beginning of ns8250_probe() and show the results. Here it is: % dmesg | grep -A2 -B3 BAS ----- uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xec00, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 -- uart4: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xec00, tag is 0x0 ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 -- uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xec08, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 -- uart5: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xec08, tag is 0x0 ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe880, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe888, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe800, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe480, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe400, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart6: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0xe080, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x40 -- uart0: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0x3f8, tag is 0x0 ns8250_probe: got IIR register: 0x1 ns8250_probe: got MCR register: 0x0 -- uart0: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0x3f8, tag is 0x0 ns8250_probe: got IIR register: 0xc1 ns8250_probe: got MCR register: 0x8 -- uart1: /usr/src/sys/dev/uart/uart_core.c:374: continue with rid=0x0 ns8250_bus_probe: entering ns8250_probe: entering ns8250_probe: BAS, handle is 0x2f8, tag is 0x0 ns8250_probe: got IIR register: 0xff ns8250_probe: got wrong IIR register, exiting with ENXIO ----- Full verbose dmesg: ftp://ftp.ipt.ru/pub/sunix/dmesg.6.txt WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From bms at FreeBSD.org Thu Dec 11 08:21:23 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Dec 11 08:21:30 2008 Subject: Enhancing cdboot [patch for review] In-Reply-To: <493DA269.2070805@FreeBSD.org> References: <493DA269.2070805@FreeBSD.org> Message-ID: <49413DFF.9030004@FreeBSD.org> This sounds and looks cool, diff looks OK (haven't applied), Luigi's comments seem well thought out and expressed. cheers BMS From xcllnt at mac.com Thu Dec 11 08:40:54 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Dec 11 08:41:01 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> Message-ID: On Dec 11, 2008, at 12:50 AM, Eygene Ryabinkin wrote: > Marcel, Boris, good day. > > Wed, Dec 10, 2008 at 05:00:24PM -0800, Marcel Moolenaar wrote: >>> Seems that just the same card should work: >>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html >>> >>> I've added some diagnistic. But 'rid' is not what you want, I guess: >> >> The RID is fine. It should always be 0. > > Seems like a dumb question, but nevertheless. > > What I don't understand is the following: BAR to port mapping for > the Timedia is tricky, it mixes BARs and offsets for the different > ports (you should know this, since you wrote the support ;)). Correct (on both accounts :-) > But in uart_bus_probe you're passing rid = 0 and it is used for > resource > allocation and consequently the same rid is used for all ports (at > least > I read the code in this way). But puc_get_bar() uses calculated rid > values, but does essentially the same thing: resource allocation via > bus_alloc_resource(). And sc->sc_bas is initialized from the obtained > sc->sc_rres (inside uart_bus_probe) and it is subsequently used for > ns8250_probe() that is failing. > > I see that uart_bus_pci.c calls uart_bus_probe() with the actual rid. > It does not mean that puc code should do the same, but ... It could have been done that way, but such is not necessary. It would not have been a problem for uart to do it, as can be seen from uart_bus_pci.c, but it would have introduced some complexity for sio(4). We needed to support sio(4) at that time and I didn't want to touch sio(4) at all. Since puc(4) needs to maintain a mapping from the child's device_t to some internal data structure, it was trivial to have the child use RID 0 in all cases and have that mapped to the right bus tag and handle pair... FYI, -- Marcel Moolenaar xcllnt@mac.com From rea-fbsd at codelabs.ru Thu Dec 11 08:57:08 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Dec 11 08:57:15 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> Message-ID: <41fBYCE8+WXjiJ69CbLadytILOA@1kze6/ikh5UKbI80fwIBmcuwJuU> Marcel, Thu, Dec 11, 2008 at 08:40:53AM -0800, Marcel Moolenaar wrote: > Since > puc(4) needs to maintain a mapping from the child's device_t > to some internal data structure, it was trivial to have the > child use RID 0 in all cases and have that mapped to the > right bus tag and handle pair... Sorry for me being so dumb, but how it is done? Is 'dev' argument to the bus_alloc_resource() carries all specifics? Am I missing some documentation? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081211/5755e15c/attachment.pgp From xcllnt at mac.com Thu Dec 11 09:07:03 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Dec 11 09:07:10 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <94541668@bb.ipt.ru> References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> Message-ID: On Dec 11, 2008, at 6:36 AM, Boris Samorodov wrote: > Hello Eygene, Marcel and All, > > > I've found some DOS/Linux docs/programs at the producers's site > and unzipped them: > ftp://ftp.ipt.ru/pub/sunix/ > > > Eygene Ryabinkin writes: > >> Boris, could you please add the line >> ----- >> printf("%s: BAS, handle is 0x%lx, tag is 0x%x\n", __func__, >> (unsigned long)bas->bsh, (unsigned int)bas->bst); >> ----- >> to the beginning of ns8250_probe() and show the results. Good suggestion, Eygene! Summary: port 1: IO=0xec00; IIR=0x1, 0xc1; MCR=0x0, 0x8 port 2: IO=0xec08; IIR=0x1, 0xc1; MCR=0x0, 0x8 port 3: IO=0xe880; IIR=0x1; MCR=0x40 port 4: IO=0xe888; IIR=0x1; MCR=0x40 port 5: IO=0xe800; IIR=0x1; MCR=0x40 port 6: IO=0xe480; IIR=0x1; MCR=0x40 port 7: IO=0xe400; IIR=0x1; MCR=0x40 port 8: IO=0xe080; IIR=0x1; MCR=0x40 For ports 3-8, the MCR has a value that's not liked by uart(4). I think we need to know what that value means. Are the ports disabled? Are they in a non-standard mode? Is it just a non-standard status bit that's set and we should ignore it? etc... Boris: can you apply the following patch and see if uart(4) attaches to all ports? If yes, can you see if those ports actually work as well? Index: uart_dev_ns8250.c =================================================================== --- uart_dev_ns8250.c (revision 185784) +++ uart_dev_ns8250.c (working copy) @@ -241,7 +241,7 @@ if (val & 0x30) return (ENXIO); val = uart_getreg(bas, REG_MCR); - if (val & 0xe0) + if (val & 0xa0) return (ENXIO); return (0); Thanks. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Thu Dec 11 09:16:13 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Dec 11 09:16:21 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <41fBYCE8+WXjiJ69CbLadytILOA@1kze6/ikh5UKbI80fwIBmcuwJuU> References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <41fBYCE8+WXjiJ69CbLadytILOA@1kze6/ikh5UKbI80fwIBmcuwJuU> Message-ID: <10176E1D-54D5-4C57-9311-DE304250E2CE@mac.com> On Dec 11, 2008, at 8:57 AM, Eygene Ryabinkin wrote: > Marcel, > > Thu, Dec 11, 2008 at 08:40:53AM -0800, Marcel Moolenaar wrote: >> Since >> puc(4) needs to maintain a mapping from the child's device_t >> to some internal data structure, it was trivial to have the >> child use RID 0 in all cases and have that mapped to the >> right bus tag and handle pair... > > Sorry for me being so dumb, but how it is done? Is 'dev' argument > to the bus_alloc_resource() carries all specifics? Am I missing > some documentation? Ok, let's follow the trail where the child is uart(4) and the parent is puc(4). A driver calls bus_alloc_resource(). The first argument of which is the device_t of the /driver. bus_alloc_resource() is defined in sys/kern/subr_bus.c and is calls the KOBJ method with the same name. The BUS_ALLOC_RESOURCE method has the parent of the device as the first argument and the device itself (the child) as the second argument. The KOBJ method in this case resolves to puc_bus_alloc_resource() in sys/dev/puc.c. In that function you'll see a call to device_get_ivars(uartdev). This is how puc(4) gets the a pointer to the puc_port structure that corresponds to the uartdev. All the information is in the puc_port struct. Obviously, puc(4) has called device_set_ivars() first (see puc_bfe_attac()). FYI, -- Marcel Moolenaar xcllnt@mac.com From citrin at citrin.ru Thu Dec 11 09:24:12 2008 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Thu Dec 11 09:24:20 2008 Subject: svn commit: r185756 - head/sys/dev/re In-Reply-To: <20081211120908.57f99124@ernst.jennejohn.org> References: <200812080248.mB82mfV9043154@svn.freebsd.org> <4940115F.7080004@citrin.ru> <20081211120908.57f99124@ernst.jennejohn.org> Message-ID: <49414CB9.7060903@citrin.ru> Gary Jennejohn wrote: > On Wed, 10 Dec 2008 21:58:39 +0300 > Anton Yuzhaninov wrote: > >> Pyun YongHyeon wrote: >>> Author: yongari >>> Date: Mon Dec 8 02:48:41 2008 >>> New Revision: 185756 >>> URL: http://svn.freebsd.org/changeset/base/185756 >>> >>> Log: >>> Reduce spin wait time consumed in GMII register access routines. >>> Waiting for 1ms for each GMII register access looks overkill and it >>> may also decrease overall performance of driver because re(4) >>> invokes mii_tick for every hz. >>> >>> Tested by: rpaulo >>> >>> Modified: >>> head/sys/dev/re/if_re.c >>> >>> Modified: head/sys/dev/re/if_re.c >>> ============================================================================== >>> --- head/sys/dev/re/if_re.c Mon Dec 8 02:38:13 2008 (r185755) >>> +++ head/sys/dev/re/if_re.c Mon Dec 8 02:48:41 2008 (r185756) >>> @@ -417,13 +417,12 @@ re_gmii_readreg(device_t dev, int phy, i >>> } >>> >>> CSR_WRITE_4(sc, RL_PHYAR, reg << 16); >>> - DELAY(1000); >>> >>> for (i = 0; i < RL_TIMEOUT; i++) { >>> + DELAY(30); >>> rval = CSR_READ_4(sc, RL_PHYAR); >>> if (rval & RL_PHYAR_BUSY) >>> break; >>> - DELAY(100); >>> } >>> >>> if (i == RL_TIMEOUT) { >>> @@ -445,13 +444,12 @@ re_gmii_writereg(device_t dev, int phy, >>> >>> CSR_WRITE_4(sc, RL_PHYAR, (reg << 16) | >>> (data & RL_PHYAR_PHYDATA) | RL_PHYAR_BUSY); >>> - DELAY(1000); >>> >>> for (i = 0; i < RL_TIMEOUT; i++) { >>> + DELAY(30); >>> rval = CSR_READ_4(sc, RL_PHYAR); >>> if (!(rval & RL_PHYAR_BUSY)) >>> break; >>> - DELAY(100); >>> } >>> >>> if (i == RL_TIMEOUT) { >> After this commit I see in logs errors: >> >> Dec 10 21:37:42 citrin kernel: re0: PHY read failed >> Dec 10 21:38:05 citrin last message repeated 3 times >> Dec 10 21:38:44 citrin last message repeated 3 times >> Dec 10 21:38:44 citrin kernel: re0: link state changed to DOWN >> Dec 10 21:38:45 citrin kernel: re0: link state changed to UP >> Dec 10 21:38:55 citrin kernel: re0: PHY read failed >> Dec 10 21:39:38 citrin last message repeated 3 times >> Dec 10 21:39:38 citrin kernel: re0: link state changed to DOWN >> Dec 10 21:39:39 citrin kernel: re0: link state changed to UP >> Dec 10 21:40:09 citrin kernel: re0: PHY read failed >> Dec 10 21:40:21 citrin kernel: re0: PHY read failed >> Dec 10 21:41:03 citrin kernel: re0: PHY read failed >> >> I tried to revert this patch - errors disappeared. >> > > I was seeing these errors too, but disabling MSI made them disappear. 1. MSI don't used (seems to be not supported by this NIC or blacklisted). 2. Commit http://svn.freebsd.org/changeset/base/185896 fixes this errors. -- Anton Yuzhaninov From rdivacky at FreeBSD.org Thu Dec 11 09:45:14 2008 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Thu Dec 11 09:45:57 2008 Subject: [PANIC]: rw_lock panic in in_pcballoc() in r185864 In-Reply-To: References: <20081210164345.GA32188@freebsd.org> <20081210214248.GA69246@freebsd.org> Message-ID: <20081211174023.GA57297@freebsd.org> On Wed, Dec 10, 2008 at 10:58:14PM +0000, Robert Watson wrote: > > On Wed, 10 Dec 2008, Roman Divacky wrote: > > >hm... I wondered how it could work before that.... anyway, I got this crash > > Well, nothing says it still works that way, that's just the theory :-). > > >>So, given that this code has worked for quite a long time for many > >>people, this really raises two questions: (1) how reproduceable is this > >>and at what point does it kick in during the boot/runtime, and (2) when > >>did this start happening in terms of updating your source? > > > >ad (1): I get this on every boot when dhcp kicks in (it uses udp I > >believe) ie. 100% reproducible > > > >ad (2): Mon Dec 8 23:02:27 CET 2008 kernel (svn up-dated at most 10 > >minutes before that) works 100% ok > > > >I have the crash dump and the kernel at hand so I can do basically > >anything you ask me to do :) anything I can provide? > > Well, to be honest, the easiest thing to do may be to play the binary > search game to narrow down the point where the problem starts a bit more. > There are a few kinds of things that might lead to this problem -- perhaps > we (I?) mucked up initialization of the inpcb with recent changes, or a > virtualization-related change tripped something up, or a locking/scheduler > change or such. it's something between 185772 and 185864, dont you have any dhcp-enabled machine? if so.. can you reproduce that? > The other thing that would be helpful is a dump of *inp so that we can see > what state inp_lock is in. I foolishly deleted the kernel matching the vmcore, I'll try to do that tomorrow From bsam at ipt.ru Thu Dec 11 10:00:14 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Dec 11 10:00:22 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: (Marcel Moolenaar's message of "Thu\, 11 Dec 2008 09\:06\:56 -0800") References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> Message-ID: <48144979@bb.ipt.ru> Marcel Moolenaar writes: > Summary: > > port 1: IO=0xec00; IIR=0x1, 0xc1; MCR=0x0, 0x8 > port 2: IO=0xec08; IIR=0x1, 0xc1; MCR=0x0, 0x8 > port 3: IO=0xe880; IIR=0x1; MCR=0x40 > port 4: IO=0xe888; IIR=0x1; MCR=0x40 > port 5: IO=0xe800; IIR=0x1; MCR=0x40 > port 6: IO=0xe480; IIR=0x1; MCR=0x40 > port 7: IO=0xe400; IIR=0x1; MCR=0x40 > port 8: IO=0xe080; IIR=0x1; MCR=0x40 > > For ports 3-8, the MCR has a value that's not liked by > uart(4). I think we need to know what that value means. > Are the ports disabled? Are they in a non-standard > mode? Is it just a non-standard status bit that's set > and we should ignore it? etc... > > Boris: can you apply the following patch and see if > uart(4) attaches to all ports? If yes, can you see > if those ports actually work as well? All ports were attached. But ports 3-8 don't work as axpected. I see garbage when connecting via those ports. BTW, I'm not sure if it may help, but FYI: the card is made of two different chip types: SUN1889 (1-2 ports) and SUN1699 (3-8 ports). Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From bsam at ipt.ru Thu Dec 11 10:01:20 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Dec 11 10:01:27 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <48144979@bb.ipt.ru> (Boris Samorodov's message of "Thu\, 11 Dec 2008 21\:00\:12 +0300") References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> Message-ID: <82064913@bb.ipt.ru> Boris Samorodov writes: > All ports were attached. But ports 3-8 don't work as axpected. > I see garbage when connecting via those ports. The relevant part of dmesg: ftp://ftp.ipt.ru/pub/sunix/dmesg.7.txt WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From bms at FreeBSD.org Thu Dec 11 10:18:34 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Dec 11 10:18:45 2008 Subject: last call for L2/L3 rewrite code review In-Reply-To: <200812100740.mBA7eqjO034924@freefall.freebsd.org> References: <200812100740.mBA7eqjO034924@freefall.freebsd.org> Message-ID: <49415977.6010307@FreeBSD.org> Hi, Just skimming this I notice it uses the if_afdata[AF_INET] pointer purely for lltbl purposes; this clashes with the IGMPv3 code drop. Please look in the bms_netdev branch, where I introduce a 'struct ip_ifinfo' to make more general use of that slot. IGMPv3 needs to store per-interface state for AF_INET, so this slot really needs to be shared with other AF_INET stuff. Looks like it needs to be updated for VIMAGE also, hopefully others more familiar with this can help -- I am busy enough with non-programming activity as it is to get up to speed on this, although I have at least managed to print Julian's write-up... Other than that, it looks like a much needed improvement and we are all very grateful for our work on this. thanks BMS From pluknet at gmail.com Thu Dec 11 10:26:11 2008 From: pluknet at gmail.com (pluknet) Date: Thu Dec 11 10:26:17 2008 Subject: SATA CD fail. In-Reply-To: References: <5f67a8c40812041432y13793ee5k1d2526c9829dc16f@mail.gmail.com> Message-ID: 2008/12/5 pluknet : > 2008/12/5 Zaphod Beeblebrox : >> I've got an HP DL-360 1U here that has a slim SATA CDROM. I've (so far) >> tried booting FreeBSD-7.0-RELEASE and FreeBSD-7.1-BETA2. I've tried both >> rewritable media (my first choice) and write-once media. The kernel loads >> fine, but multiuser fails with "acd0: TIMEOUT - READ_BIG retrying" ... >> twice, followed by "timed out". > > I workarounded this by ejecting CD after kernel is loaded but before > probing media, then > installing from sysinstall via NFS from this CD inserted on nearby > with IDE CDROM computer. > [redirected from -stable] This issue was on recent CURRENT around November for me. And hey. After later cvsup to Dec 11 this problem disappeared. Now it boots with media injected in SATA DVD. acd0: DVDR at ata4-master SATA150 GEOM_LABEL: Label for provider acd0 is iso9660/STALKER_CS. -- wbr, pluknet From xcllnt at mac.com Thu Dec 11 10:29:39 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Dec 11 10:29:46 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <48144979@bb.ipt.ru> References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> Message-ID: <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> On Dec 11, 2008, at 10:00 AM, Boris Samorodov wrote: > Marcel Moolenaar writes: > >> Summary: >> >> port 1: IO=0xec00; IIR=0x1, 0xc1; MCR=0x0, 0x8 >> port 2: IO=0xec08; IIR=0x1, 0xc1; MCR=0x0, 0x8 >> port 3: IO=0xe880; IIR=0x1; MCR=0x40 >> port 4: IO=0xe888; IIR=0x1; MCR=0x40 >> port 5: IO=0xe800; IIR=0x1; MCR=0x40 >> port 6: IO=0xe480; IIR=0x1; MCR=0x40 >> port 7: IO=0xe400; IIR=0x1; MCR=0x40 >> port 8: IO=0xe080; IIR=0x1; MCR=0x40 >> >> For ports 3-8, the MCR has a value that's not liked by >> uart(4). I think we need to know what that value means. >> Are the ports disabled? Are they in a non-standard >> mode? Is it just a non-standard status bit that's set >> and we should ignore it? etc... >> >> Boris: can you apply the following patch and see if >> uart(4) attaches to all ports? If yes, can you see >> if those ports actually work as well? > > All ports were attached. But ports 3-8 don't work as axpected. > I see garbage when connecting via those ports. Ok, so it's more than just a non-standard status bit that can be ignored :-/ Unfortunately, I don't have any of their hardware, nor any documentation... -- Marcel Moolenaar xcllnt@mac.com From jille at quis.cx Thu Dec 11 10:32:29 2008 From: jille at quis.cx (Jille Timmermans) Date: Thu Dec 11 10:32:37 2008 Subject: Panic when loading if_ath In-Reply-To: <494062BE.5050202@freebsd.org> References: <49403F27.3020605@quis.cx> <4940440E.9050805@freebsd.org> <49405EC7.8080906@quis.cx> <494062BE.5050202@freebsd.org> Message-ID: <49415CB8.7040302@quis.cx> Sam Leffler schreef: > Jille Timmermans wrote: >> Sam Leffler schreef: >> >>> Jille Timmermans wrote: >>> >>>> Hello list, >>>> >>>> A panic with if_ath (Atheros 2413) >>>> >>>> root /sys/modules/ath_rate_amrr# make >>>> root /sys/modules/ath_rate_amrr# make install >>>> root ~# kldload if_ath >>>> warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints >>>> file >>>> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >>>> pci5 >>>> ath0: [ITHREAD] >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 0; apic id = 00 >>>> fault virtual address = 0x0 >>>> fault code = supervisor read, page not present >>>> instruction pointer = 0x20:0x0 >>>> stack pointer = 0x28:0xc43cc748 >>>> frame pointer = 0x28:0xc43cc75c >>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> = DPL 0, pres 1, def32 1, gran 1 >>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>> current_process = 993 (kldload) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 0 >>>> >>>> [dump] >>>> [reboot] >>>> WARNING: /tmp was not properly dismounted >>>> WARNING: /usr was not properly dismounted >>>> WARNING: /var was not properly dismounted >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 0; apic id = 00 >>>> fault virtual address = 0x5bbfe499 >>>> fault code = supervisor read, page not present >>>> instruction pointer = 0x20:0xc0684c37 >>>> stack pointer = 0x28:0xc4364a5c >>>> frame pointer = 0x28:0xc4364c28 >>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> = DPL 0, pres 1, def32 1, gran 1 >>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>> current process = 136 (ifconfig) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 0 >>>> >>>> [a few crashes later, when it comes to mind to get a backtrace] >>>> root ~# kldload ath_rate >>>> root ~# kldload if_ath >>>> ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on >>>> pci5 >>>> ath0: [ITHREAD] >>>> [panic] >>>> uart_z8530_class(c4ac5000, 0, 1, 1, c4390000, ...) at 0 >>>> ar5212Attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >>>> ar5212Attach+0x211 >>>> ath_hal_attach(1a, c48b0000, 1, c4389000, c437c8ec, ...) at >>>> ath_hal_attach+0x56 >>>> ath_attach(1a, c48b0000, 3, c437c940, ffffffff, ...) at ath_attach+0x9e >>>> ath_pci_attach(c46bb200, c4823854, c09fcf80, c099dc60, 80000000, >>>> ...) at >>>> ath_pci_attach+0x332 >>>> device_attach([snip]) at device_attach+0x36f >>>> device_probe_and_attach([snip) at ...+0x43 >>>> pci_driver_added([snip]) at +0x104 >>>> devclass_add_driver([snip]) at +0xe8 >>>> driver_module_handler([snip]) at +0x79 >>>> module_register_init() >>>> linker_load_module() >>>> kern_kldload() >>>> >>>> (Please don't tell me you want any of that snips.) >>>> >>>> Any extra information I can provide to you ? >>>> I am willing to help debugging / crashing. >>>> >>>> >>> Try building the driver into the kernel. Also use sample and not amrr. >>> >> root ~# cd /sys/modules/ath_rate_sample >> root /sys/modules/ath_rate_sample# make >> root /sys/modules/ath_rate_sample# make install >> root /sys/modules/ath_rate_sample# kldload if_ath >> link_elf: symbol ath_hal_computetxtime undefined >> KLD if_ath.ko: depends on ath_rate - not available >> kldload: can't load if_ath: No such file or directory >> root /sys/modules/ath_rate_sample# kldload ath_rate >> link_elf: symbol ath_hal_computetxtime undefined >> kldload: can't load ath_rate: No such file or directory >> >> I'll try compiling it in. >> >> > I know module building is broken; I posted recently to just build things > into the kernel. I've got a possible solution in p4 in the sam_vap > branch if you want to try it. I removed the ath_rate_* modules and just > smooshed the code into the ath module so we go from > (ath+ath_hal+ath_rate) to just (ath). > > Right now I want to see if your problem is in the module mess, > ath_rate_amrr, or something else. I tested 2413 w/ the driver built > into the kernel so I'm guessing it's amrr which I may just nuke entirely > (along with onoe). The built-in version panics as well (while booting). (Information of which I think it is relevant) ath0: mem 0xc9000000-0xc900ffff irq 18 at device 1.0 on pci5 ath0: [ITHREAD] Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x3 current process = 0 (swapper) trap number = 1 Uptime: 1s db> bt uart_z8530_class(c46da000, 0, 1, 1, c433c000, ...) at 0x3 ar5212Attach(1a, c48c9000, 1, c433c000, c437c8ec, ...) at ar5212Attach+0x70a ath_hal_attach(1a, c46c9000, 3, c10208b8, ffffffff, ...) at ath_hal_attach+0xbe kernel config entries: options AH_SUPPORT_AR5416 device ath device ath_hal device ath_rate_sample How can I get a kernel of your p4 source ? Can you provide me a diff against head or something alike ? -- Jille > > Sam > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From bsam at ipt.ru Thu Dec 11 10:40:18 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Dec 11 10:40:25 2008 Subject: Timeda 8-multiport adapter: only 2 ports available In-Reply-To: <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> (Marcel Moolenaar's message of "Thu\, 11 Dec 2008 10\:29\:37 -0800") References: <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <94541668@bb.ipt.ru> <48144979@bb.ipt.ru> <548CF0A3-1B07-49DA-A177-6EA85FD8CF2F@mac.com> Message-ID: <15982575@bb.ipt.ru> Marcel Moolenaar writes: > Unfortunately, I don't have any of their hardware, nor any > documentation... There is a linux driver code: ftp://ftp.ipt.ru/pub/sunix/golden_V1.08/golden/driver I know that's not much... Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From pluknet at gmail.com Thu Dec 11 10:41:25 2008 From: pluknet at gmail.com (pluknet) Date: Thu Dec 11 10:41:32 2008 Subject: LOR during boot (if_sis.c/kbdmux.c - Giant after non-sleepable) In-Reply-To: References: <48ED3D0F.6050209@cran.org.uk> Message-ID: 2008/10/9 Maksim Yevmenkin : > On 10/8/08, Bruce Cran wrote: >> During boot I pressed Scroll Lock at the wrong time and got a LOR. >> Switching between consoles became really slow once the system was running, >> taking a couple of seconds each time. >> I'm running -current from a few days ago. >> >> lock order reversal: (Giant after non-sleepable) >> 1st 0xc4283e84 sis0 (network driver) @ >> /usr/src/sys/dev/sis/if_sis.c:2106 >> 2nd 0xc0d0d430 Giant (Giant) @ >> /usr/src/sys/dev/kbdmux/kbdmux.c:1103 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0bc49d7,c3ee27f0,c0837e85,4,c0bc0367,...) >> at db_trace_self_wrapper+0x26 >> kdb_backtrace(4,c0bc0367,c0b9b6f1,c411d1a0,c3ee2848,...) >> at kdb_backtrace+0x29 >> _witness_debugger(c0bc728c,c0d0d430,c0be0869,c411d1a0,c0b9b6f1,...) >> at _witness_debugger+0x25 >> witness_checkorder(c0d0d430,9,c0b9b6f1,44f,0,...) at >> witness_checkorder+0x800 >> _mtx_lock_flags(c0d0d430,0,c0b9b6f1,44f,c4167d20,...) at >> _mtx_lock_flags+0xc4 >> kbdmux_ioctl(c4221b00,40044b13,c3ee28c8,100202,7,...) >> at kbdmux_ioctl+0x76e >> update_kbd_state(c0bc0367,c0bbaf86,2,c44b08c0,c0c577a0,...) >> at update_kbd_state+0x44 >> sc_cnputc(c0c577a0,73,c3ee2a94,5,73,...) at sc_cnputc+0x39 >> cnputc(73,c3ee2a94,c3ee2944,c082a2a1,c0be63cd,...) at >> cnputc+0x5f >> putcons(c0be63cd,c0bbaf86,1000001,c41d9d6d,c082a240,...) >> at putcons+0x17 >> putchar(73,c3ee2a94,c0d11900,1,c41d9d6f,...) at >> putchar+0x61 >> kvprintf(c0b668aa,c082a240,c3ee2a94,a,c3ee2ac0,...) at >> kvprintf+0xa27 >> printf(c0b668aa,c41d9d6c,0,c4283e00,c4283e00,...) at >> printf+0x4e >> device_print_prettyname(c4277c80,c4289800,c4283e00,c4283e00,c3ee2b24,...) >> at device_print_prettyname+0x4c >> device_printf(c4277c80,c0bab5be,f4,0,c06da240,...) at >> device_printf+0x12 >> sis_initl(c4283e84,0,c0bab5a0,83a,80206910,...) at >> sis_initl+0x99d >> sis_ioctl(c428cc00,80206910,c45ab740,628,c428cc00,...) at >> sis_ioctl+0xa8 >> ifhwioctl(c44b08c0,c452122c,c0e4d6d0,c44b0964,c0e4d6d0,...) >> at ifhwioctl+0x3eb >> ifioctl(c4555ab8,80206910,c45ab740,c44b08c0,80206910,...) >> at ifioctl+0x305 >> soo_ioctl(c449f3b8,80206910,c45ab740,c4169400,c44b08c0,...) >> at soo_ioctl+0x397 >> kern_ioctl(c44b08c0,5,80206910,c45ab740,8318c0,...) at >> kern_ioctl+0x1dd >> ioctl(c44b08c0,c3ee2cf8,c,c0bf8ba3,c0c9b110,...) at >> ioctl+0x134 >> syscall(c3ee2d38) at syscall+0x2a3 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281a9a23, esp = 0xbfbfe5bc, >> ebp = 0xbfbfe618 --- > > well, this particular lor is caused by the fact that sc_cnputc() wants > to muck around kbd state. i do not know syscons code very well, but > this looks rather strange to me. i really do not know why the function > that really should just put a char on screen wants to do something > with kbd. i see the code tries to deal with scroll lock, so that is > consistent with your report. > > kbdmux was recently changed to use Giant based locking (as an attempt > to work around other problems). when update_kbd_state() uses ioctl() > on kbd device, kbdmux will try to grab Giant. the whole thing was > started by device_printf() that is called from sis_initl() with > another mutex held. > > so, to me, sc_cnputc() is broken and should be fixed. > Just to confirm it still exists. A bit different LOR though. CURRENT from December. lock order reversal: (Giant after non-sleepable) 1st 0xc5e08074 vnode interlock (vnode interlock) @ /usr/src/sys/vm/vnode_pager.c:1201 2nd 0xc087f9d0 Giant (Giant) @ /usr/src/sys/dev/kbdmux/kbdmux.c:1103 KDB: stack backtrace: db_trace_self_wrapper(c07f3714,e7cc564c,c05d7425,4,c07eec87,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c07eec87,c54f50a8,c54f41a0,e7cc56a8,...) at kdb_backtrace+0x29 _witness_debugger(c07f639f,c087f9d0,c0807a3d,c54f41a0,c07df81e,...) at _witness_debugger+0x25 witness_checkorder(c087f9d0,9,c07df81e,44f,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c087f9d0,0,c07df81e,44f,e7cc5700,...) at _mtx_lock_flags+0xc4 kbdmux_ioctl(c5608600,40044b13,e7cc5728,100202,c083e324,...) at kbdmux_ioctl+0x76e update_kbd_state(c0589e3c,c5df3e10,4,c07eec87,c0831bc0,...) at update_kbd_state+0x44 sc_cnputc(c0831bc0,6c,e7cc58f4,5,6c,...) at sc_cnputc+0x39 cnputc(6c,e7cc58f4,e7cc57a4,c05c9871,c07fd19d,...) at cnputc+0x5f putcons(c07fd19d,c07eec87,100009a,c09bfd80,c05c9810,...) at putcons+0x17 putchar(6c,e7cc58f4,246,c07e9e46,c59b0900,...) at putchar+0x61 kvprintf(c07f633c,c05c9810,e7cc58f4,a,e7cc5920,...) at kvprintf+0x9e printf(c07f633c,0,c07f55e7,4e3,e7cc5944,...) at printf+0x4e witness_checkorder(c5e08058,9,c07fd19d,81f,0,...) at witness_checkorder+0x6a1 __lockmgr_args(c5e08058,200501,c5e08074,0,0,...) at __lockmgr_args+0x797 vop_stdlock(e7cc5a78,c05d71cb,c0810948,200501,c5e08000,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c5a2a000,e7cc5a78,c59b09a4,c0867bc0,c5e08000,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c5e08000,200501,c07fd19d,81f,4,...) at _vn_lock+0x5e vget(c5e08000,200501,c59b0900,4b2,0,...) at vget+0xc9 vnode_pager_lock(c5e1a744,0,c080df26,127,e7cc5c18,...) at vnode_pager_lock+0x1e0 vm_fault(c5b91000,281a0000,1,0,281a0000,...) at vm_fault+0x1df trap_pfault(5,0,c08195a4,2e7,c59b0900,...) at trap_pfault+0xf9 trap(e7cc5d38) at trap+0x289 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80496d0, esp = 0xbfbfec80, ebp = 0xbfbfed58 --- -- wbr, pluknet From rwatson at FreeBSD.org Thu Dec 11 11:08:55 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Dec 11 11:09:02 2008 Subject: [PANIC]: rw_lock panic in in_pcballoc() in r185864 In-Reply-To: <20081211174023.GA57297@freebsd.org> References: <20081210164345.GA32188@freebsd.org> <20081210214248.GA69246@freebsd.org> <20081211174023.GA57297@freebsd.org> Message-ID: On Thu, 11 Dec 2008, Roman Divacky wrote: >>> I have the crash dump and the kernel at hand so I can do basically >>> anything you ask me to do :) anything I can provide? >> >> Well, to be honest, the easiest thing to do may be to play the binary >> search game to narrow down the point where the problem starts a bit more. >> There are a few kinds of things that might lead to this problem -- perhaps >> we (I?) mucked up initialization of the inpcb with recent changes, or a >> virtualization-related change tripped something up, or a locking/scheduler >> change or such. > > it's something between 185772 and 185864, dont you have any dhcp-enabled > machine? if so.. can you reproduce that? I have several boxes, real and virtual, using DHCP and very recent (tm) kernels and no sign of this panic. That's why I think there's something going on here that's a bit more subtle. For example, we'd really like to know what in the rw_wlock() call got tripped over as a NULL pointer... >> The other thing that would be helpful is a dump of *inp so that we can see >> what state inp_lock is in. > > I foolishly deleted the kernel matching the vmcore, I'll try to do that > tomorrow OK. Once you get the panic, I think the most interesting questions have to do with the contents of *inp, *inp->inp_lock.lock_object, etc. It might also be interesting to know whether any UDP use triggers the panic, or just DHCP. You can test this by booting to single-user, configuring lo0 manually, and then doing "dig @127.0.0.1 ." or some other activity that triggers a UDP packet to be sent. Robert N M Watson Computer Laboratory University of Cambridge From ed at 80386.nl Thu Dec 11 11:32:01 2008 From: ed at 80386.nl (Ed Schouten) Date: Thu Dec 11 11:32:09 2008 Subject: LOR during boot (if_sis.c/kbdmux.c - Giant after non-sleepable) In-Reply-To: References: <48ED3D0F.6050209@cran.org.uk> Message-ID: <20081211193450.GF1176@hoeg.nl> Hello, * pluknet wrote: > lock order reversal: (Giant after non-sleepable) > 1st 0xc4283e84 sis0 (network driver) @ > /usr/src/sys/dev/sis/if_sis.c:2106 > 2nd 0xc0d0d430 Giant (Giant) @ > /usr/src/sys/dev/kbdmux/kbdmux.c:1103 This problem is probably related to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=127446 -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20081211/bd6a9887/attachment.pgp From olivier at gid0.org Thu Dec 11 11:43:13 2008 From: olivier at gid0.org (Olivier SMEDTS) Date: Thu Dec 11 11:43:21 2008 Subject: SATA CD fail. In-Reply-To: References: <5f67a8c40812041432y13793ee5k1d2526c9829dc16f@mail.gmail.com> Message-ID: <367b2c980812111112u4d5f59ct788c43fbdc64840e@mail.gmail.com> 2008/12/11 pluknet : > 2008/12/5 pluknet : >> 2008/12/5 Zaphod Beeblebrox : >>> I've got an HP DL-360 1U here that has a slim SATA CDROM. I've (so far) >>> tried booting FreeBSD-7.0-RELEASE and FreeBSD-7.1-BETA2. I've tried both >>> rewritable media (my first choice) and write-once media. The kernel loads >>> fine, but multiuser fails with "acd0: TIMEOUT - READ_BIG retrying" ... >>> twice, followed by "timed out". I've got the same issue with my SATA DVD-RW drive when trying tu burn a media. I can "burncd blank" but I have the same errors than you when trying to "burncd data image.iso fixate". I don't remember if I had problems installing 7.0-RELEASE with a CD-ROM on my computer 6 months ago. I use latest -CURRENT on amd64. >> I workarounded this by ejecting CD after kernel is loaded but before >> probing media, then >> installing from sysinstall via NFS from this CD inserted on nearby >> with IDE CDROM computer. >> > [redirected from -stable] > > This issue was on recent CURRENT around November for me. > And hey. After later cvsup to Dec 11 this problem disappeared. > Now it boots with media injected in SATA DVD. > > acd0: DVDR at ata4-master SATA150 > GEOM_LABEL: Label for provider acd0 is iso9660/STALKER_CS. > > -- > wbr, > pluknet > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From yanefbsd at gmail.com Thu Dec 11 12:36:03 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 11 12:36:10 2008 Subject: make buildworld failed! In-Reply-To: <20081211203220.GE150@atarininja.org> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> <1228869506.1255.3.camel@www.boolome.cn> <7d6fde3d0812110140y44df387dg14f83c5483fe96ff@mail.gmail.com> <20081211203220.GE150@atarininja.org> Message-ID: <7d6fde3d0812111236t1b234271xcd7cf0ad7db6b99d@mail.gmail.com> On Thu, Dec 11, 2008 at 12:32 PM, Wesley Shields wrote: > On Thu, Dec 11, 2008 at 01:40:40AM -0800, Garrett Cooper wrote: >> On Tue, Dec 9, 2008 at 4:38 PM, boolome wrote: >> > ?$B:_ 2008-12-09?$BFsE* 03:18 -0800?$B!$Garrett Cooper?$B> >> On Dec 8, 2008, at 5:48 PM, boolome wrote: >> >> >> >> > ?$B:_ 2008-12-08?$B0lE* 01:55 -0800?$B!$Garrett Cooper?$B> >> >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: >> >> >> [snip] >> >> >> >> >> >> Looks like your source tree is incomplete. >> >> >> -Garrett >> >> > >> >> > But have cvsup the latest source tree ! >> >> >> >> It's not necessarily your fault though. What cvsup server are you >> >> using and did you interrupt it during an update? >> >> -Garrett >> > >> > The cvsup server is cvsup.freebsd.org . >> > >> > During an update ,I did not interrupt it. >> > >> > But when I got to that dir executed :make obj && make depend && >> > make ,successed.. >> > >> > Is the soure tree's problem ? >> > By the way I 'am using a custom kernel . >> >> Hmmm.. not sure. If I had logs I could help you out more, but >> unfortunately I don't ;(. > > Unless I missed it the cause of the error is not in the logs provided. > Were you building in parallel? > >> I'd chock it up to a bad build environment or maybe just bad prebuilt objs. > > My money is on a broken kernel config. > > -- WXS Yeah, well either way we don't have enough data to say with absolute authority that "this is the root cause of the failure". A full log would have been incredibly helpful. And FWIW it looks like it was a bootstrap toolchain error (it failed running flex to bootstrap gcc). -Garrett From wxs at FreeBSD.org Thu Dec 11 12:48:30 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Thu Dec 11 12:48:37 2008 Subject: make buildworld failed! In-Reply-To: <7d6fde3d0812110140y44df387dg14f83c5483fe96ff@mail.gmail.com> References: <1228555830.1186.6.camel@www.boolome.cn> <7d6fde3d0812080155y22cc7c0bne1fa0094671355e4@mail.gmail.com> <1228787330.13158.0.camel@www.boolome.cn> <53DC39AE-EE1E-41DE-801D-45737249D93B@gmail.com> <1228869506.1255.3.camel@www.boolome.cn> <7d6fde3d0812110140y44df387dg14f83c5483fe96ff@mail.gmail.com> Message-ID: <20081211203220.GE150@atarininja.org> On Thu, Dec 11, 2008 at 01:40:40AM -0800, Garrett Cooper wrote: > On Tue, Dec 9, 2008 at 4:38 PM, boolome wrote: > > ?$B:_ 2008-12-09?$BFsE* 03:18 -0800?$B!$Garrett Cooper?$B >> On Dec 8, 2008, at 5:48 PM, boolome wrote: > >> > >> > ?$B:_ 2008-12-08?$B0lE* 01:55 -0800?$B!$Garrett Cooper?$B >> >> On Sat, Dec 6, 2008 at 1:30 AM, boolome wrote: > >> >> [snip] > >> >> > >> >> Looks like your source tree is incomplete. > >> >> -Garrett > >> > > >> > But have cvsup the latest source tree ! > >> > >> It's not necessarily your fault though. What cvsup server are you > >> using and did you interrupt it during an update? > >> -Garrett > > > > The cvsup server is cvsup.freebsd.org . > > > > During an update ,I did not interrupt it. > > > > But when I got to that dir executed :make obj && make depend && > > make ,successed.. > > > > Is the soure tree's problem ? > > By the way I 'am using a custom kernel . > > Hmmm.. not sure. If I had logs I could help you out more, but > unfortunately I don't ;(. Unless I missed it the cause of the error is not in the logs provided. Were you building in parallel? > I'd chock it up to a bad build environment or maybe just bad prebuilt objs. My money is on a broken kernel config. -- WXS From yanefbsd at gmail.com Thu Dec 11 12:53:40 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Dec 11 12:53:47 2008 Subject: [patch] de(4) has not worked on 8-current since Feb 13 In-Reply-To: <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> References: <20081210125627.25732615CD@mail.asahi-net.or.jp> <494019AB.3020505@samsco.org> <20081211130057.B53EE5D0A4@mail.asahi-net.or.jp> Message-ID: <7d6fde3d0812111253n4b8f7135n76e9cef63158943e@mail.gmail.com> On Thu, Dec 11, 2008 at 5:00 AM, WATANABE Kazuhiro wrote: > CC'ed to freebsd-current. > > At Wed, 10 Dec 2008 12:34:03 -0700, > Scott Long wrote: >> WATANABE Kazuhiro wrote: >> > Hi, all. >> > >> > My de(4) NICs has not worked on 8-current since Feb 13. >> > >> > >> >> Can you define "not worked" a little better? Does it give errors, or >> corrupt data, or appear to not transmit and/or receive? >> >> Scott > > Thanks for your reply. I should have written more details about the > problem... > > On recent 8-current, my de(4) NICs cannot send any (almost all) data > from it. > > * The system boots normally. > > * Probing/attaching the de(4) NICs are done successfully. > > * The system can receive data from the other hosts. For example the > following command was finished normally in 14 seconds: > > $ /usr/bin/time scp other_host:/boot/kernel/kernel . > Password: > kernel 100% 4717KB 471.7KB/s 00:10 > 14.03 real 0.53 user 0.40 sys > $ > > *