ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - on FreeBSD 6-STABLE
Hi After my previous email about the SETFEATURES SET TRANSFER MODE timeout on (msgid [EMAIL PROTECTED] , 17 March 14:18 GMT + 2 on freebsd-stable), I installed FreeBSD 6.1 BETA 4 and upgraded to a 6-STABLE kernel, running the box in 'safe' mode to do so. I now, however, get a slightly different error message: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly ad4: FAILURE - WRITE_DMA timed out LBA=32804495 (The address after LBA is not always the same) This is with ad4 as a Seagate ST320423A on a Promise PDC20262 UDMA66 controller. Any suggestions? Thanks, Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic in 6.1 - does no one care?
On Thu, Mar 23, 2006 at 11:22:37PM -0500, Surer Dink wrote: > All, > > Two days ago I reported a panic here > (http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023748.html) > on a freshly cvsuped releng_6 "generic" kernel. I have heard no > responses at all - does this mean I am posting in the wrong place, or > does no one care about 6.1? Surely you can think of a few other possibilities than those two, but just in case, here's another one for you: most developers are unfamiliar with the USB code, so understanding your panic requires specialized knowledge that few developers have. Please try to exercise patience, and file a PR so they can get to it in time. Kris pgp1LXq2pHWeA.pgp Description: PGP signature
Re: kernel panic in 6.1 - does no one care?
On Fri, Mar 24, 2006 at 01:31:05PM +0800, James Gallagher wrote: > I also wonder if this would be better reported on -current rather than > -stable as the concerned version, 6.1, is pre-release/Beta? Nope, that's not the way it works. -stable is for 4.X/5.X/6.X. -current is for -HEAD, e.g., that which will in time become 7.0. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic in 6.1 - does no one care?
On Thu, 23 Mar 2006 22:39:56 -0600, [EMAIL PROTECTED] (Mark Linimon) wrote: > On Thu, Mar 23, 2006 at 11:22:37PM -0500, Surer Dink wrote: >> Two days ago I reported a panic here >> > (http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023748.html) >> on a freshly cvsuped releng_6 "generic" kernel. I have heard no >> responses at all - does this mean I am posting in the wrong place, or >> does no one care about 6.1? > > Neither. It means that the volunteers are incredibly busy testing as > many things as they can for the simultaneous 5.5/6.1 release, and not > everything can be gotten to. > > mcl I also wonder if this would be better reported on -current rather than -stable as the concerned version, 6.1, is pre-release/Beta? James ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic in 6.1 - does no one care?
On Thu, Mar 23, 2006 at 11:22:37PM -0500, Surer Dink wrote: > Two days ago I reported a panic here > (http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023748.html) > on a freshly cvsuped releng_6 "generic" kernel. I have heard no > responses at all - does this mean I am posting in the wrong place, or > does no one care about 6.1? Neither. It means that the volunteers are incredibly busy testing as many things as they can for the simultaneous 5.5/6.1 release, and not everything can be gotten to. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel panic in 6.1 - does no one care?
All, Two days ago I reported a panic here (http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023748.html) on a freshly cvsuped releng_6 "generic" kernel. I have heard no responses at all - does this mean I am posting in the wrong place, or does no one care about 6.1? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
synaptics touchpad on hp nx6110
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, According to www.hp.com nx6110 has a synaptics touchpad. I have tried with an Ubuntu Live CD and detected correctly: mice: PS/2 mouse device common for all mice Synaptic Touchpad, model: 1 Firmware: 6.2 Sensor: 37 new absolute packet format Touchpad has extended capability bits -> multifinger detection -> palm detection -> pass-through port input: SysPS/2 Synaptics Touchpad on isa0060/serio4 serio: Synaptics passthrough port at isa0060/serio4/input6 ts: Compaq touchscreen protocol output Under FreeBSD 6.1-PRERELEASE it is detected as IntelliMouse even if I set hw.psm.synaptics_support=1: psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 60 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:, flags:0008, packet size:4 psm0: syncmask:08, syncbits:00 Is there any solution for this problem? Best, Laci - -- László Károly <[EMAIL PROTECTED]> Department of Altaic StudiesEgyetem str. 2. University of Szeged H-6722 Szeged, Hungary PGP/GnuPG key: 1024D/869D81C5 Fingerprint: 1E61 3205 8F5A 87E7 1269 3396 1C63 F9FF 869D 81C5 Encrypted e-mail preferred. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEI29rHGP5/4adgcURApjKAKCYaBG1gsq7fUZaZGrK1RLxDo4I7wCgpBK2 xA1EOycLTqObHqhc5agSKBw= =bjsl -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS)
:I thought one serious advantage to this situation for sequential read :mmap() is to madvise(MADV_DONTNEED) so that the pages don't have to :wait for the clock hands to reap them. On a large Solaris box I used :to have the non-pleasure of running the VM page scan rate was high, and :I suggested to the app vendor that proper use of mmap might reduce that :overhead. Admitedly the files in question were much smaller than the :available memory, but they were also not likely to be referenced again :before the memory had to be reclaimed forcibly by the VM system. : :Is that not the case? Is it better to let the VM system reclaim pages :as needed? : :Thanks, : :Gary madvise() should theoretically have that effect, but it isn't quite so simple a solution. Lets say you have, oh, your workstation, with 1GB of ram, and you run a program which runs several passes on a 900MB data set. Your X session, xterms, gnome, kde, etc etc etc all take around 300MB of working memory. Now that data set could fit into memory if portions of your UI were pushed out of memory. The question is not only how much of that data set should the kernel fit into memory, but which portions of that data set should the kernel fit into memory and whether the kernel should bump out other data (pieces of your UI) to make it fit. Scenario #1: If the kernel fits the whole 900MB data set into memory, the entire rest of the system would have to compete for the remaining 100MB of memory. Your UI would suck rocks. Scenario #2: If the kernel fits 700MB of the data set into memory, and the rest of the system (your UI, etc) is only using 300MB, and the kernel is using MADV_DONTNEED on pages it has already scanned, now your UI works fine but your data set processing program is continuously accessing the disk for all 900MB of data, on every pass, because the kernel is always only keeping the most recently accessed 700MB of the 900MB data set in memory. Scenario #3: Now lets say the kernel decides to keep just the first 700MB of the data set in memory, and not try to cache the last 200MB of the data set. Now your UI works fine, and your processing program runs FOUR TIMES FASTER because it only has to access the disk for the last 200MB of the 900MB data set. -- Now, which of these scenarios does madvise() cover? Does it cover scenario #1? Well, no. the madvise() call that the program makes has no clue whether you intend to play around with your UI every few minutes, or whether you intend to leave the room for 40 minutes. If the kernel guesses wrong, we wind up with one unhappy user. What about scenario #2? There the program decided to call madvise(), and the system dutifully reuses the pages, and you come back an hour later and your data processing program has only done 10 passes out of the 50 passes it needs to do on the data and you are PISSED. Ok. What about scenario #3? Oops. The program has no way of knowing how much memory you need for your UI to be 'happy'. No madvise() call of any sort will make you happy. Not only that, but the KERNEL has no way of knowing that your data processing program intends to make multiple passes on the data set, whether the working set is represented by one file or several files, and even the data processing program itself might not know (you might be running a script which runs a separate program for each pass on the same data set). So much for madvise(). So, no matter what, there will ALWAYS be an unhappy user somewhere. Lets take Mikhail's grep test as an example. If he runs it over and over again, should the kernel be 'optimized' to realize that the same data set is being scanned sequentially, over and over again, ignore the localized sequential nature of the data accesses, and just keep a dedicated portion of that data set in memory to reduce long term disk access? Should it keep the first 1.5GB, or the last 1.5GB, or perhaps it should slice the data set up and keep every other 256MB block? How does it figure out what to cache and when? What if the program suddenly starts accessing the data in a cacheable way? Maybe it should randomly throw some of the data away slowly in the hopes of 'adapting' to the access pattern, which would also require that it throw away most of the 'recently read' data far more quickly to make up for the data it isn't throwing away. Believe it or not, that actually works for certain types of problems, except then you get hung up in a situation where two subsystems are competing with each other for memory resources (like mail server verses web server), and the system is unable to cope as the relative load factors for the competing subsystems change. The problem becomes really complex really fast. This so
Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS)
> : time fgrep meowmeowmeow /home/oh.0.dump > : 2.167u 7.739s 1:25.21 11.6% 70+3701k 23663+0io 6pf+0w > : time fgrep --mmap meowmeowmeow /home/oh.0.dump > : 1.552u 7.109s 2:46.03 5.2% 18+1031k 156+0io 106327pf+0w > : > :Use a big enough file to bust the memory caching (oh.0.dump above is 2.9Gb), > > :I'm sure, you will have no problems reproducing this result. > > 106,000 page faults. How many pages is a 2.9GB file? If this is running > in 64-bit mode those would be 8K pages, right? So that would come to > around 380,000 pages. About 1:4. So, clearly the operating system > *IS* pre-faulting multiple pages. ... > > In anycase, this sort of test is not really a good poster child for how > to use mmap(). Nobody in their right mind uses mmap() on datasets that > they expect to be uncacheable and which are accessed sequentially. It's > just plain silly to use mmap() in that sort of circumstance. May be the OS needs "reclaim-behind" for the sequential case? This way you can mmap many many pages and use a much smaller pool of physical pages to back them. The idea is for the VM to reclaim pages N-k..N-1 when page N is accessed and allow the same process to reuse this page. Similar to read ahead, where the OS schedules read of page N+k, N+k+1.. when page N is accessed. May be even use TCP algorithms to adjust the backing buffer (window) size:-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS)
On Thu, Mar 23, 2006 at 03:16:11PM -0800, Matthew Dillon wrote: > In anycase, this sort of test is not really a good poster child for how > to use mmap(). Nobody in their right mind uses mmap() on datasets that > they expect to be uncacheable and which are accessed sequentially. It's > just plain silly to use mmap() in that sort of circumstance. This is > a trueism on ANY operating system, not just FreeBSD. The uncached > data set test (using unmount/mount and a dataset which fits into memory) > is a far more realistic test because it simulates the most common case > encountered by a system under load... the accessing of a reasonably sized > data set which happens to not be in the cache. I thought one serious advantage to this situation for sequential read mmap() is to madvise(MADV_DONTNEED) so that the pages don't have to wait for the clock hands to reap them. On a large Solaris box I used to have the non-pleasure of running the VM page scan rate was high, and I suggested to the app vendor that proper use of mmap might reduce that overhead. Admitedly the files in question were much smaller than the available memory, but they were also not likely to be referenced again before the memory had to be reclaimed forcibly by the VM system. Is that not the case? Is it better to let the VM system reclaim pages as needed? Thanks, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS)
:Yes, they both do work fine, but time gives very different stats for each. In :my experiments, the total CPU time is noticably less with mmap, but the :elapsed time is (much) greater. Here are results from FreeBSD-6.1/amd64 -- :notice the large number of page faults, because the system does not try to :preload file in the mmap case as it does in the read case: : : time fgrep meowmeowmeow /home/oh.0.dump : 2.167u 7.739s 1:25.21 11.6% 70+3701k 23663+0io 6pf+0w : time fgrep --mmap meowmeowmeow /home/oh.0.dump : 1.552u 7.109s 2:46.03 5.2% 18+1031k 156+0io 106327pf+0w : :Use a big enough file to bust the memory caching (oh.0.dump above is 2.9Gb), :I'm sure, you will have no problems reproducing this result. 106,000 page faults. How many pages is a 2.9GB file? If this is running in 64-bit mode those would be 8K pages, right? So that would come to around 380,000 pages. About 1:4. So, clearly the operating system *IS* pre-faulting multiple pages. Since I don't believe that a memory fault would be so inefficient as to account for 80 seconds of run time, it seems more likely to me that the problem is that the VM system is not issuing read-aheads. Not issuing read-aheads would easily account for the 80 seconds. It is possible that the kernel believes the VM system to be too loaded to issue read-aheads, as a consequence of your blowing out of the system caches. It is also possible that the read-ahead code is broken in FreeBSD. To determine which of the two is more likely, you have to run a smaller data set (like 600MB of data on a system with 1GB of ram), and use the unmount/mount trick to clear the cache before each grep test. If the time differential is still huge using the unmount/mount data set test as described above, then the VM system's read-ahead code is broken. If the time differential is tiny, however, then it's probably nothing more then the kernel interpreting your massive 2.9GB mmap as being too stressful on the VM system and disabling read-aheads for that reason. In anycase, this sort of test is not really a good poster child for how to use mmap(). Nobody in their right mind uses mmap() on datasets that they expect to be uncacheable and which are accessed sequentially. It's just plain silly to use mmap() in that sort of circumstance. This is a trueism on ANY operating system, not just FreeBSD. The uncached data set test (using unmount/mount and a dataset which fits into memory) is a far more realistic test because it simulates the most common case encountered by a system under load... the accessing of a reasonably sized data set which happens to not be in the cache. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nve timeout (and down) regression?
> Date: Thu, 23 Mar 2006 21:59:56 + (UTC) > From: "Bjoern A. Zeeb" <[EMAIL PROTECTED]> > > On Thu, 23 Mar 2006, JoaoBR wrote: > > > On Thursday 23 March 2006 15:59, Bjoern A. Zeeb wrote: > > > > nve did not worked on 6.0R (for me) but cvsup to stable resolved the case > > (for > > me) in end of dezember > > > > since a month or so with recent releng_6 the problem came back, timeouts and > > stopping rx/tx > > did you do more updates in the timeframe from december to about a > month ago? > > if the problem was gone and is back now any (exact) dates to narrow > down the timeframe where the problem came back would be very helpful. We have several identical systems and most are running fine. Mine is running RELENG_6 and was updated on 2/15 and I have no problem. Another system that was just updated last week (I don't have the exact time) is showing the problem. Another was built 1/21 and runs fine. Guess I'll try updating my 2/15 system and see if it has problems. Another thing that might be related is that the system having problems is plugged into a very inexpensive switch (Allied Telesyn), my system uses a Netgear FS108 and the third is connected to a Cisco 3548. I know that this is unlikely, but I thought that it was worth mentioning. All are claimed to be running 100-FD. Unfortunately, the one causing most of the problems is about 2000 miles away, so I have only limited access to that one. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nve timeout (and down) regression?
On Thursday 23 March 2006 18:59, Bjoern A. Zeeb wrote: > On Thu, 23 Mar 2006, JoaoBR wrote: > > On Thursday 23 March 2006 15:59, Bjoern A. Zeeb wrote: > > > > nve did not worked on 6.0R (for me) but cvsup to stable resolved the case > > (for me) in end of dezember > > > > since a month or so with recent releng_6 the problem came back, timeouts > > and stopping rx/tx > > did you do more updates in the timeframe from december to about a > month ago? > yes, aprox once a week since 6.0R release > if the problem was gone and is back now any (exact) dates to narrow > down the timeframe where the problem came back would be very helpful. I know but unfortunatly I didn't tracked it and what I said is the most exact I have, I just got something interesting, It seems the problem is not with media 100baseTX full-duplex (autoselect or set) but only with 100baseTX (autoselect or set) but I need to doublecheck if it is really the same MB João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Temperature monitoring in FreeBSD 4/5/6
O. Hartmann wrote: > O. Hartmann schrieb: > > Roland Smith schrieb: > >> On Thu, Mar 16, 2006 at 07:22:14PM -0500, Stephan Koenig wrote: > >>> Does anyone know of an easy way to get temperature information out of > >>> a Dell PowerEdge 1550/1650/1750/1850/2650/2850 running FreeBSD4/5/6? > >>> > >>> Something that has a very simple CLI that just outputs the temperature > >>> without any formatting, or a library/sysctl, would be ideal. > >> /usr/ports/sysutils/mbmon > >> > >> If you want an additional X frontend, try > >> > >> /usr/ports/sysutils/xmbmon > >> > >> Roland > > > > This port does not work for me on any DELL Optiplex GX270/280 and 820 > > around here. Especially on GX270/280 I tried every knob of the port I > > found without a positive result. > > > > Oliver > > > > It does also not work on ASUS A8N32-SLI due to an unsupported chipset. > O. On one machine where mbmon doesn't report anything useful lmmon does. HTH Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nve timeout (and down) regression?
On Thu, 23 Mar 2006, JoaoBR wrote: On Thursday 23 March 2006 15:59, Bjoern A. Zeeb wrote: nve did not worked on 6.0R (for me) but cvsup to stable resolved the case (for me) in end of dezember since a month or so with recent releng_6 the problem came back, timeouts and stopping rx/tx did you do more updates in the timeframe from december to about a month ago? if the problem was gone and is back now any (exact) dates to narrow down the timeframe where the problem came back would be very helpful. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pkgdb core dumb
On Thursday 23 March 2006 11:53, John Nielsen wrote: >I've seen this a number of times; it usually means a corrupt pkgdb. Rebuild >it from scratch (pkgdb -fu). If that fails or if you still get the error >afterwards, rebuild and reinstall portupgrade and ruby (without using >portupgrade in the process). Run 'pkgdb -fu' again after the reinstall. > >JN Thanks. I did a 'make deinstall' in the /usr/ports/sysutils/portupgrade directory, then ran 'make install clean'. After I did a 'pkgdb -fu', I was all set. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS)
четвер 23 березень 2006 15:48, Matthew Dillon Ви написали: > Well, I don't know about FreeBSD, but both grep cases work just fine on > DragonFly. Yes, they both do work fine, but time gives very different stats for each. In my experiments, the total CPU time is noticably less with mmap, but the elapsed time is (much) greater. Here are results from FreeBSD-6.1/amd64 -- notice the large number of page faults, because the system does not try to preload file in the mmap case as it does in the read case: time fgrep meowmeowmeow /home/oh.0.dump 2.167u 7.739s 1:25.21 11.6% 70+3701k 23663+0io 6pf+0w time fgrep --mmap meowmeowmeow /home/oh.0.dump 1.552u 7.109s 2:46.03 5.2% 18+1031k 156+0io 106327pf+0w Use a big enough file to bust the memory caching (oh.0.dump above is 2.9Gb), I'm sure, you will have no problems reproducing this result. > I can't test mzip.c because I don't see the compression > library you are calling (maybe that's a FreeBSD thing). The program uses -lz and -lbz2 -- both are parts of FreeBSD since before the unfortunate fork of DF. The following should work for you: make -f bsd.prog.mk LDADD="-lz -lbz2" PROG=mzip mzip Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS)
:Actually, I can not agree here -- quite the opposite seems true. When running :locally (no NFS involved) my compressor with the `-1' flag (fast, least :effective compression), the program easily compresses faster, than it can :read. : :The Opteron CPU is about 50% idle, *and so is the disk* producing only 15Mb/s. :I guess, despite the noise I raised on this subject a year ago, reading via :mmap continues to ignore the MADV_SEQUENTIONAL and has no other adaptability. : :Unlike read, which uses buffering, mmap-reading still does not pre-fault the :file's pieces in efficiently :-( : :Although the program was written to compress files, that are _likely_ still in :memory, when used with regular files, it exposes the lack of mmap :optimization. : :This should be even more obvious, if you time searching for a string in a :large file using grep vs. 'grep --mmap'. : :Yours, : : -mi : :http://aldan.algebra.com/~mi/mzip.c Well, I don't know about FreeBSD, but both grep cases work just fine on DragonFly. I can't test mzip.c because I don't see the compression library you are calling (maybe that's a FreeBSD thing). The results of the grep test ought to be similar for FreeBSD since the heuristic used by both OS's is the same. If they aren't, something might have gotten nerfed accidently in the FreeBSD tree. Here is the cache case test. mmap is clearly faster (though I would again caution that this should not be an implicit assumption since VM fault overheads can rival read() overheads, depending on the situation). The 'x1' file in all tests below is simply /usr/share/dict/words concactenated over and over again to produce a large file. crater# ls -la x1 -rw-r--r-- 1 root wheel 638228992 Mar 23 11:36 x1 [ machine has 1GB of ram ] crater# time grep --mmap asdfasf x1 1.000u 0.117s 0:01.11 100.0%10+40k 0+0io 0pf+0w crater# time grep --mmap asdfasf x1 0.976u 0.132s 0:01.13 97.3% 10+40k 0+0io 0pf+0w crater# time grep --mmap asdfasf x1 0.984u 0.140s 0:01.11 100.9%10+41k 0+0io 0pf+0w crater# time grep asdfasf x1 0.601u 0.781s 0:01.40 98.5% 10+42k 0+0io 0pf+0w crater# time grep asdfasf x1 0.507u 0.867s 0:01.39 97.8% 10+40k 0+0io 0pf+0w crater# time grep asdfasf x1 0.562u 0.812s 0:01.43 95.8% 10+41k 0+0io 0pf+0w crater# iostat 1 [ while grep is running, in order to test the cache case and verify that no I/O is occuring once the data has been cached ] The disk I/O case, which I can test by unmounting and remounting the partition containing the file in question, then running grep, seems to be well optimized on DragonFly. It should be similarly optimized on FreeBSD since the code that does this optimization is nearly the same. In my test, it is clear that the page-fault overhead in the uncached case is considerably greater then the copying overhead of a read(), though not by much. And I would expect that, too. test28# umount /home test28# mount /home test28# time grep asdfasdf /home/x1 0.382u 0.351s 0:10.23 7.1% 55+141k 42+0io 4pf+0w test28# umount /home test28# mount /home test28# time grep asdfasdf /home/x1 0.390u 0.367s 0:10.16 7.3% 48+123k 42+0io 0pf+0w test28# umount /home test28# mount /home test28# time grep --mmap asdfasdf /home/x1 0.539u 0.265s 0:10.53 7.5% 36+93k 42+0io 19518pf+0w test28# umount /home test28# mount /home test28# time grep --mmap asdfasdf /home/x1 0.617u 0.289s 0:10.47 8.5% 41+105k 42+0io 19518pf+0w test28# test28# iostat 1 during the test showed ~60MBytes/sec for all four tests Perhaps you should post specifics of the test you are running, as well as specifics of the results you are getting, such as the actual timing output instead of a human interpretation of the results. For that matter, being an opteron system, were you running the tests on a UP system or an SMP system? grep is a single-threaded so on a 2-cpu system it will show 50% cpu utilization since one cpu will be saturated and the other idle. With specifics, a FreeBSD person can try to reproduce your test results. A grep vs grep --mmap test is pretty straightforward and should be a good test of the VM read-ahead code, but there might always be some unknown circumstance specific to a machine configuration that is the cause of the problem. Repeatability and reproducability by third parties is important when diagnosing any problem. Insofar as MADV_SEQUENTIAL goes... you shouldn't need it on FreeBSD. Unless someone ripped it out since I committed it many years ago, which I doubt, FreeBSD's VM heuristic will figure out that the accesses are sequential and start issuing read-aheads. It should pre-fault, and it should do read-ahead. That isn't to say that there isn't a bug, just that everyone interested in the problem has to be able to reproduce it and help each other track down the source. Just making an
Re: 6.1 PRERELEASE kernel build error
- Original Message - From: Kris Kennaway <[EMAIL PROTECTED]> To: Casey Scott <[EMAIL PROTECTED]> Cc: freebsd-stable@freebsd.org, Kris Kennaway <[EMAIL PROTECTED]> Sent: Thursday, March 23, 2006 11:57:11 AM GMT-0800 Subject: Re: 6.1 PRERELEASE kernel build error On Thu, Mar 23, 2006 at 11:17:55AM -0800, Casey Scott wrote: > Sorry, I should have been more clear. I have already performed the > entire procedure specified in updating. The system is running the > new 6.1 binaries/kernel. > > After booting into the new environment, I removed /usr/obj. > At /usr/src, I did make buildkernel KERNCONF=XXX, and received the > error in question. Upon doing another buildworld, the buildkernel > succeeded. > >Something on your system is still stale. > >The error comes when you have an old compiler toolchain, and if you >completed the installworld with correct sources you have the new >compiler. > >Kris I figured as much. I'll go through everything again in a very detailed manner when I get the time. Thanks for the second opinion. Casey ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 PRERELEASE kernel build error
On Thu, Mar 23, 2006 at 11:17:55AM -0800, Casey Scott wrote: > Sorry, I should have been more clear. I have already performed the > entire procedure specified in updating. The system is running the > new 6.1 binaries/kernel. > > After booting into the new environment, I removed /usr/obj. > At /usr/src, I did make buildkernel KERNCONF=XXX, and received the > error in question. Upon doing another buildworld, the buildkernel > succeeded. Something on your system is still stale. The error comes when you have an old compiler toolchain, and if you completed the installworld with correct sources you have the new compiler. Kris pgpF48RcCLNEk.pgp Description: PGP signature
Re: ifconfig -am shows ...
On Thu, Mar 23, 2006 at 04:58:04PM +0200, husnu demir wrote: > Hi, > > my ifconfig -am command result is as follows; > > > em0: flags=8843 mtu 1500 > options=b > capabilities=5b > inet 10.0.10.114 netmask 0xfffc broadcast 10.0.10.115 > ether 00:04:23:c2:db:fc > media: Ethernet autoselect (1000baseSX ) > status: active > supported media: > media autoselect > media 1000baseSX > media 1000baseSX mediaopt full-duplex > > > > But I know that it is an LX card. The connection is working. Can it be > a cause of bottleneck for my network or just a small bug?? It's probably just a cosmetic bug. It looks like the driver doesn't know about LX media, but I'm guessing the PHYs have the same software and electrical interface so it shouldn't matter. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp4fNWuXgpVS.pgp Description: PGP signature
Re: nve timeout (and down) regression?
On Thursday 23 March 2006 15:59, Bjoern A. Zeeb wrote: > If you have collisions you have most likeely a duplex mismatch. > yep, but I set manually matching with the switch and tried other speeds, no change > If you read the code and I remember right the above change is a NOP. > anyway, resolved my case ... > > The timeouts have been there and are there. The difference with the > last commits is that a lot of people couldn't get the NIC working at > all before and now it works (somewhat) but there are timeouts from > time to time which for some people seem to auto-recover and for > others still get things 'stuck'. > nve did not worked on 6.0R (for me) but cvsup to stable resolved the case (for me) in end of dezember since a month or so with recent releng_6 the problem came back, timeouts and stopping rx/tx > The problem is to diagnose what everyone really has > - branch running (RELENG_6 or HEAD) releng_6 last cvsup from thi monday > - i386 or amd64 amd64 > - exact FreeBSD revisions for if_nve.c > - if using patches which > - pciconf -lv | grep -A4 ^nve nve0: port 0xd400-0xd407 mem 0xec00-0xec000fff irq 20 at device 5.0 on pci0 nve0: Ethernet address 00:04:61:98:97:d5 miibus0: on nve0 [EMAIL PROTECTED]:5:0: class=0x068000 card=0x100c1695 chip=0x00df10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Network Bus Enumerator' class= bridge > - which board > > - exact problems > * is the interface working at all the system after probing HW comes up with nve0 down nve0 up nve0 down João > * is it just stuck from time to time > * ... > > See http://www.freebsd.org/cgi/query-pr.cgi?pr=94524 for more > questions. You my want to submit a fllow up and add your description > with the answer to these questions there. -- Atenciosamente Infomatik Internet Technology (18)3551.8155 (18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new zoneinfo for 5.5-R?
In <[EMAIL PROTECTED]>, Steve Ames writes: >For us poor saps in Indiana... could we get a new zoneinfo port >prior to 5.5-R? Sorry, I've been unable to devote any attention at all to FreeBSD in the past three months or so. I'm hoping to clear the backlog soon, but I don't think that I'll be able to do it before the release as I had originally planned. You can always drop in the new tzdata files on your existing system. (I'm hoping at some point in the near future to create a port so that you don't have to update your system to get the latest tzdata.) -GAWollman -- Garrett A. Wollman| As the Constitution endures, persons in every [EMAIL PROTECTED] | generation can invoke its principles in their own Opinions not those| search for greater freedom. of MIT or CSAIL. | - A. Kennedy, Lawrence v. Texas, 539 U.S. 558 (2003) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 PRERELEASE kernel build error
- Original Message - From: Kris Kennaway <[EMAIL PROTECTED]> To: Casey Scott <[EMAIL PROTECTED]> Cc: Kris Kennaway <[EMAIL PROTECTED]>, freebsd-stable@freebsd.org Sent: Thursday, March 23, 2006 10:48:29 AM GMT-0800 Subject: Re: 6.1 PRERELEASE kernel build error On Thu, Mar 23, 2006 at 10:43:59AM -0800, Casey Scott wrote: > > - Original Message - > From: Kris Kennaway <[EMAIL PROTECTED]> > To: Casey Scott <[EMAIL PROTECTED]> > Cc: freebsd-stable@freebsd.org, Kris Kennaway <[EMAIL PROTECTED]> > Sent: Thursday, March 23, 2006 10:20:02 AM GMT-0800 > Subject: Re: 6.1 PRERELEASE kernel build error > > On Thu, Mar 23, 2006 at 08:25:35AM -0800, Casey Scott wrote: > > > > - Original Message - > > From: Kris Kennaway <[EMAIL PROTECTED]> > > To: Casey Scott <[EMAIL PROTECTED]> > > Cc: freebsd-stable@freebsd.org > > Sent: Thursday, March 23, 2006 0:27:30 AM GMT-0800 > > Subject: Re: 6.1 PRERELEASE kernel build error > > > > On Wed, Mar 22, 2006 at 10:27:56AM -0800, Casey Scott wrote: > > > I just upgraded 5.4 stable to 6.1 PRERELEASE via buildworld. I am trying > > > to build a kernel, and keep getting this error at "make". > > > > > > > > > .. > > > cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall > > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > > > -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. > > > -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf > > > -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd > > > -I../../../contrib/ngatm -I../../../dev/twa -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 > > > -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c > > > ../../../fs/devfs/devfs_vnops.c:1172: warning: redundant redeclaration of > > > 'devfs_ops_f' > > > ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of > > > 'devfs_ops_f' was here > > > ../../../fs/devfs/devfs_vnops.c:1183: warning: redundant redeclaration of > > > 'devfs_vnodeops' > > > ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of > > > 'devfs_vnodeops' was here > > > ../../../fs/devfs/devfs_vnops.c:1205: warning: redundant redeclaration of > > > 'devfs_specops' > > > ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of > > > 'devfs_specops' was here > > > *** Error code 1 > > > > > > > > > I even get that error building a kernel from the GENERIC config. I think > > > something is wonky with gcc. >Has anyone else seen this, or know what > > > could be causing it? > > > > > >You didn't follow the correct upgrade order - it's documented in the > > >handbook and in /usr/src/UPDATING. > > > > > >Kris > > > > > > Thanks for that info. I have the kernel built now. I noticed that it > > is built from the source in /usr/obj and not /usr/src. > > > >No, /usr/obj contains the results of your buildworld, it's not a > >second copy of the source. > > > > In 6.x, do we > > have to keep /usr/obj after installworld, or should installworld > > have updated /usr/src ? > > >You do not have to keep /usr/obj. > > > >Kris > > > >P.S. Please wrap your lines so that your emails may be easily read. > > > That's what I thought. However, when I rm -rf /usr/obj/, and try > to build the kernel again, I can the same error that I mentioned > at the beginning of the thread. If I buildworld again, and do a > make buildkernel KERNCONF=XXX, the build succeeds. > >Yes, because you removed it in the middle of your upgrade. According >to the directions, installworld comes late in the sequence. > >Kris Sorry, I should have been more clear. I have already performed the entire procedure specified in updating. The system is running the new 6.1 binaries/kernel. After booting into the new environment, I removed /usr/obj. At /usr/src, I did make buildkernel KERNCONF=XXX, and received the error in question. Upon doing another buildworld, the buildkernel succeeded. Casey ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS)
вівторок 21 березень 2006 17:48, Matthew Dillon Ви написали: > Reading via mmap() is very well optimized. Actually, I can not agree here -- quite the opposite seems true. When running locally (no NFS involved) my compressor with the `-1' flag (fast, least effective compression), the program easily compresses faster, than it can read. The Opteron CPU is about 50% idle, *and so is the disk* producing only 15Mb/s. I guess, despite the noise I raised on this subject a year ago, reading via mmap continues to ignore the MADV_SEQUENTIONAL and has no other adaptability. Unlike read, which uses buffering, mmap-reading still does not pre-fault the file's pieces in efficiently :-( Although the program was written to compress files, that are _likely_ still in memory, when used with regular files, it exposes the lack of mmap optimization. This should be even more obvious, if you time searching for a string in a large file using grep vs. 'grep --mmap'. Yours, -mi http://aldan.algebra.com/~mi/mzip.c ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nve timeout (and down) regression?
On Thu, 23 Mar 2006, JoaoBR wrote: Hi, The other patch cited in the message has never been made: diff -u -r1.7.2.4 if_nve.c --- if_nve.c9 Oct 2005 04:18:17 - 1.7.2.4 +++ if_nve.c27 Oct 2005 09:58:45 - @@ -727,7 +727,7 @@ DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init_rings - entry\n"); - sc->cur_rx = sc->cur_tx = sc->pending_rxs = sc->pending_txs = 0; + sc->cur_rx = sc->cur_tx = sc->pending_rxs = 0; and I did this part and my NIC is running, as I said still lot of collisions caused by it but it is running If you have collisions you have most likeely a duplex mismatch. If you read the code and I remember right the above change is a NOP. The timeouts have been there and are there. The difference with the last commits is that a lot of people couldn't get the NIC working at all before and now it works (somewhat) but there are timeouts from time to time which for some people seem to auto-recover and for others still get things 'stuck'. The problem is to diagnose what everyone really has - branch running (RELENG_6 or HEAD) - i386 or amd64 - exact FreeBSD revisions for if_nve.c - if using patches which - pciconf -lv | grep -A4 ^nve - which board - exact problems * is the interface working at all * is it just stuck from time to time * ... See http://www.freebsd.org/cgi/query-pr.cgi?pr=94524 for more questions. You my want to submit a fllow up and add your description with the answer to these questions there. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 PRERELEASE kernel build error
On Thu, Mar 23, 2006 at 10:43:59AM -0800, Casey Scott wrote: > > - Original Message - > From: Kris Kennaway <[EMAIL PROTECTED]> > To: Casey Scott <[EMAIL PROTECTED]> > Cc: freebsd-stable@freebsd.org, Kris Kennaway <[EMAIL PROTECTED]> > Sent: Thursday, March 23, 2006 10:20:02 AM GMT-0800 > Subject: Re: 6.1 PRERELEASE kernel build error > > On Thu, Mar 23, 2006 at 08:25:35AM -0800, Casey Scott wrote: > > > > - Original Message - > > From: Kris Kennaway <[EMAIL PROTECTED]> > > To: Casey Scott <[EMAIL PROTECTED]> > > Cc: freebsd-stable@freebsd.org > > Sent: Thursday, March 23, 2006 0:27:30 AM GMT-0800 > > Subject: Re: 6.1 PRERELEASE kernel build error > > > > On Wed, Mar 22, 2006 at 10:27:56AM -0800, Casey Scott wrote: > > > I just upgraded 5.4 stable to 6.1 PRERELEASE via buildworld. I am trying > > > to build a kernel, and keep getting this error at "make". > > > > > > > > > .. > > > cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall > > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > > > -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. > > > -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf > > > -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd > > > -I../../../contrib/ngatm -I../../../dev/twa -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 > > > -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c > > > ../../../fs/devfs/devfs_vnops.c:1172: warning: redundant redeclaration of > > > 'devfs_ops_f' > > > ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of > > > 'devfs_ops_f' was here > > > ../../../fs/devfs/devfs_vnops.c:1183: warning: redundant redeclaration of > > > 'devfs_vnodeops' > > > ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of > > > 'devfs_vnodeops' was here > > > ../../../fs/devfs/devfs_vnops.c:1205: warning: redundant redeclaration of > > > 'devfs_specops' > > > ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of > > > 'devfs_specops' was here > > > *** Error code 1 > > > > > > > > > I even get that error building a kernel from the GENERIC config. I think > > > something is wonky with gcc. >Has anyone else seen this, or know what > > > could be causing it? > > > > > >You didn't follow the correct upgrade order - it's documented in the > > >handbook and in /usr/src/UPDATING. > > > > > >Kris > > > > > > Thanks for that info. I have the kernel built now. I noticed that it > > is built from the source in /usr/obj and not /usr/src. > > > >No, /usr/obj contains the results of your buildworld, it's not a > >second copy of the source. > > > > In 6.x, do we > > have to keep /usr/obj after installworld, or should installworld > > have updated /usr/src ? > > >You do not have to keep /usr/obj. > > > >Kris > > > >P.S. Please wrap your lines so that your emails may be easily read. > > > That's what I thought. However, when I rm -rf /usr/obj/, and try > to build the kernel again, I can the same error that I mentioned > at the beginning of the thread. If I buildworld again, and do a > make buildkernel KERNCONF=XXX, the build succeeds. Yes, because you removed it in the middle of your upgrade. According to the directions, installworld comes late in the sequence. Kris pgpW0ba9j3GLI.pgp Description: PGP signature
Re: a place for configuration files
On Thu, Mar 23, 2006 at 10:24:04AM -0500, Vivek Khera wrote: > From: Vivek Khera <[EMAIL PROTECTED]> > Date: Thu, 23 Mar 2006 10:24:04 -0500 > To: freebsd-stable > X-Mailer: Apple Mail (2.746.3) > Subject: Re: a place for configuration files > > > On Mar 22, 2006, at 8:28 PM, Gary Kline wrote: > > > I think having a /usr/local/etc is "new" (past decade maybe), > > We've had /usr/local on Sun boxes since I can remember (started using > SunOS 2.x back in college) and administering 4.2BSD (not FreeBSD 4.2, > but 4.2BSD from Berkeley) on vaxen 'round about 1986-ish and we had / > usr/local for local (ie, not part of the base system) software. In > fact, it was actually a separate disk partition too. At more than one place where I've worked, /usr/local was a common NFS mount, which meant a lot less overhead for installing site-local packages. Depending on the number of servers you're managing, it can be quite a bit easier to do this (or use rsync/rdist) to have a common site-wide repository of local software, than to manage local packages, and their dependencies / upgrades across all servers. -- [EMAIL PROTECTED] http://jeffenstein.dyndns.org/ PGP mail preferred, key id 0x19C987F5 "It is our belief, however, that serious professional users will run out of things they can do with UNIX. They'll want a real system and will end up doing VMS when they get to be serious about programming." -- Ken Olsen, CEO of DEC, 1984 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 PRERELEASE kernel build error
- Original Message - From: Kris Kennaway <[EMAIL PROTECTED]> To: Casey Scott <[EMAIL PROTECTED]> Cc: freebsd-stable@freebsd.org, Kris Kennaway <[EMAIL PROTECTED]> Sent: Thursday, March 23, 2006 10:20:02 AM GMT-0800 Subject: Re: 6.1 PRERELEASE kernel build error On Thu, Mar 23, 2006 at 08:25:35AM -0800, Casey Scott wrote: > > - Original Message - > From: Kris Kennaway <[EMAIL PROTECTED]> > To: Casey Scott <[EMAIL PROTECTED]> > Cc: freebsd-stable@freebsd.org > Sent: Thursday, March 23, 2006 0:27:30 AM GMT-0800 > Subject: Re: 6.1 PRERELEASE kernel build error > > On Wed, Mar 22, 2006 at 10:27:56AM -0800, Casey Scott wrote: > > I just upgraded 5.4 stable to 6.1 PRERELEASE via buildworld. I am trying to > > build a kernel, and keep getting this error at "make". > > > > > > .. > > cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > > -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. > > -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf > > -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd > > -I../../../contrib/ngatm -I../../../dev/twa -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 > > -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c > > ../../../fs/devfs/devfs_vnops.c:1172: warning: redundant redeclaration of > > 'devfs_ops_f' > > ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of > > 'devfs_ops_f' was here > > ../../../fs/devfs/devfs_vnops.c:1183: warning: redundant redeclaration of > > 'devfs_vnodeops' > > ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of > > 'devfs_vnodeops' was here > > ../../../fs/devfs/devfs_vnops.c:1205: warning: redundant redeclaration of > > 'devfs_specops' > > ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of > > 'devfs_specops' was here > > *** Error code 1 > > > > > > I even get that error building a kernel from the GENERIC config. I think > > something is wonky with gcc. >Has anyone else seen this, or know what could > > be causing it? > > > >You didn't follow the correct upgrade order - it's documented in the > >handbook and in /usr/src/UPDATING. > > > >Kris > > > Thanks for that info. I have the kernel built now. I noticed that it > is built from the source in /usr/obj and not /usr/src. > >No, /usr/obj contains the results of your buildworld, it's not a >second copy of the source. > > In 6.x, do we > have to keep /usr/obj after installworld, or should installworld > have updated /usr/src ? >You do not have to keep /usr/obj. > >Kris > >P.S. Please wrap your lines so that your emails may be easily read. That's what I thought. However, when I rm -rf /usr/obj/, and try to build the kernel again, I can the same error that I mentioned at the beginning of the thread. If I buildworld again, and do a make buildkernel KERNCONF=XXX, the build succeeds. Casey ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nve timeout (and down) regression?
On Thursday 23 March 2006 15:29, Kevin Oberman wrote:
> I am a bit confused. The first addition of sc->pending_txs = 0; was
> MFC'ed back in December by obrien.
>
> Check around line 730 of if_nv.c (or whatever it's called in 6.0)
> sc->linkup = 0;
> sc->cur_rx = 0;
> sc->pending_rxs = 0;
> + sc->pending_txs = 0;
> This should mostly eliminate the problem.
>
this part actually is in the driver but nve still doing timeout and stop
imediatly rx/tx
> The other patch cited in the message has never been made:
> diff -u -r1.7.2.4 if_nve.c
> --- if_nve.c9 Oct 2005 04:18:17 - 1.7.2.4
> +++ if_nve.c27 Oct 2005 09:58:45 -
> @@ -727,7 +727,7 @@
>
> DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init_rings - entry\n");
>
> - sc->cur_rx = sc->cur_tx = sc->pending_rxs = sc->pending_txs = 0;
> + sc->cur_rx = sc->cur_tx = sc->pending_rxs = 0;
and I did this part and my NIC is running, as I said still lot of collisions
caused by it but it is running
João
> /* Initialise RX ring */
> for (i = 0; i < RX_RING_SIZE; i++) {
> struct nve_rx_desc *desc = sc->rx_desc + i;
>
>
> So sc->pending_txs should only be reset to zero only in nve_stop but not
> in nve_init_rings?
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
new zoneinfo for 5.5-R?
For us poor saps in Indiana... could we get a new zoneinfo port prior to 5.5-R? thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 on Dell 1850 with DRAC4 management card?
On Fri, Jan 06, 2006 at 01:57:17PM +, Scott Mitchell wrote: > Hi all, > > On to my next question about running 6.0 on a Dell PE1850, since it seems > that the RAID card will work just fine... > > I'm thinking about getting the machine with a DRAC4 remote management card. > This looks to be OS-independent (you can configure through the BIOS) so I > expect it will just work. I've seen various posts talking about how it > tends to take over the keyboard and render the real console inaccessible, > but there are workarounds for that. > > Does anyone have the console redirection working? I'd like to leave the > 'real' console (actually a USB keyboard attached to a KVM) active so the > machine is accessible to someone actually in the server room, but still be > able to get to the console remotely when necessary. The Dell docs imply > that you can just point a browser at the DRAC and fire up a new console, > but I'd like to hear from someone who's done this with FreeBSD! > > Apologies for all the dumb questions... I'd try all this stuff myself but > the hardware isn't here yet and has to go into production pretty quickly > once it arrives. All the similar machines in the building are already > running Windows and someone would object if I 'liberated' any of them :) Following up to myself for the benefit of the archives - I can confirm that the DRAC4 works very well with FreeBSD, and turns out to be quite a useful piece of kit. The DRAC attaches itself as a USB keyboard which on this system at least was probed as ukbd0, so I was able to install using the remote console (a Java applet downloaded from the DRAC's web server). The _really_ cool feature is the remote CD/floppy support - I was able to boot the 1850 off a 6.0 CD *in my local workstation* and do the entire install without ever going near it, so it could have been on the other side of the planet, not just in the next room. Pretty neat IMHO. After a bit of fiddling with kbdmux(4) and devd.conf I was able to get a second UDB keyboard on a KVM working as well. There are a few magic runes needed to boot single-user, but I expect all that to become a lot easier with the kbdmux(4) changes coming in 6.1. The DRAC can be configured to send out email alerts when interesting events happen - it will tell you when eg. RAID drives die and come back online, and I expect also when temperature limits etc. are reached. It also has console redirection to the serial ports, which I *believe* can also be reached via the telnet or SSH interface, but I haven't got around to setting that up yet (and rebooting the machine to tweak the BIOS now it's live would make me unpopular) Anyway, if you're buying a Dell server of any kind I can highly recommend getting one of these cards with it. Cheers, Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Non-boot on RELENG_6 1930 UTC source using XP's ntldr
I updated my system on 22 March with sources available on the mirrors at 11:30 PST and ended up with a system that wouldn't boot. It would get to the point that I chose FreeBSD using ntldr and it just stopped. The XP sytem used an older boot1 to boot FreeBSD. I could use the 6.0-Release CD fixit option to go back to the system update of 18 March. Since then, I have found that if I unload the 18 March kernel, load the 22 March kernel and boot, I get a btx dump. However, if you replace the old boot1 used by the ntldr with the one created by the new version of the OS, you can boot just fine. Kent -- Kent Stewart Richland, WA http://www.soyandina.com/ "I am Andean project". http://users.owt.com/kstewart/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
I have a similar crash from 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #1: Sun Mar 19 13:28: On Fri, Mar 17, 2006 at 09:01:05PM -0600, Vlad wrote: i > Ok, thanks for Joe's hint I was able to get stuff captured: > > # kgdb kernel.debug /var/crash/vmcore.0 ... > #9 0x8037ee2b in calltrap () at ../../../amd64/amd64/exception.S:168 > #10 0x8026d5f6 in propagate_priority (td=0xff003a5e94c0) > at ../../../kern/subr_turnstile.c:233 > #11 0x8026de2f in turnstile_wait (lock=0x805710c0, > owner=0x0) at ../../../kern/subr_turnstile.c:628 > #12 0x8023b4a9 in _mtx_lock_sleep (m=0x805710c0, > tid=18446742975234022368, opts=180, > file=0xfffe , My panic. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x808080f4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0513ff5 stack pointer = 0x28:0xda6e4c0c frame pointer = 0x28:0xda6e4c10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 3984 (sh) [thread pid 3984 tid 100242 ] Stopped at turnstile_setowner+0xd: movl0x74(%ecx),%eax db> bt Tracing pid 3984 tid 100242 td 0xc41fb780 turnstile_setowner(c41fe840,80808080,c07a5c58,c079f3e0,c41fb780) at turnstile_se towner+0xd turnstile_wait(c079f3e0,80808080) at turnstile_wait+0xa5 _mtx_lock_sleep(c079f3e0,c41fb780,0,c0674893,25e) at _mtx_lock_sleep+0xc4 _mtx_lock_flags(c079f3e0,0,c0674893,25e,c44b37f8) at _mtx_lock_flags+0x30 fork1(c41fb780,14,0,da6e4cd4,c41fb780) at fork1+0xb2a fork(c41fb780,da6e4d04,0,0,246) at fork+0x18 syscall(3b,3b,3b,0,8068000) at syscall+0x25f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (2, FreeBSD ELF32, fork), eip = 0x2813ca33, esp = 0xbfbfe5ec, ebp = 0xbfbfe608 - -- - [EMAIL PROTECTED] http://www.db.net/~db ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nve timeout (and down) regression?
I am a bit confused. The first addition of sc->pending_txs = 0; was
MFC'ed back in December by obrien.
Check around line 730 of if_nv.c (or whatever it's called in 6.0)
sc->linkup = 0;
sc->cur_rx = 0;
sc->pending_rxs = 0;
+ sc->pending_txs = 0;
This should mostly eliminate the problem.
The other patch cited in the message has never been made:
diff -u -r1.7.2.4 if_nve.c
--- if_nve.c9 Oct 2005 04:18:17 - 1.7.2.4
+++ if_nve.c27 Oct 2005 09:58:45 -
@@ -727,7 +727,7 @@
DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init_rings - entry\n");
- sc->cur_rx = sc->cur_tx = sc->pending_rxs = sc->pending_txs = 0;
+ sc->cur_rx = sc->cur_tx = sc->pending_rxs = 0;
/* Initialise RX ring */
for (i = 0; i < RX_RING_SIZE; i++) {
struct nve_rx_desc *desc = sc->rx_desc + i;
So sc->pending_txs should only be reset to zero only in nve_stop but not
in nve_init_rings?
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 PRERELEASE kernel build error
On Thu, Mar 23, 2006 at 08:25:35AM -0800, Casey Scott wrote: > > - Original Message - > From: Kris Kennaway <[EMAIL PROTECTED]> > To: Casey Scott <[EMAIL PROTECTED]> > Cc: freebsd-stable@freebsd.org > Sent: Thursday, March 23, 2006 0:27:30 AM GMT-0800 > Subject: Re: 6.1 PRERELEASE kernel build error > > On Wed, Mar 22, 2006 at 10:27:56AM -0800, Casey Scott wrote: > > I just upgraded 5.4 stable to 6.1 PRERELEASE via buildworld. I am trying to > > build a kernel, and keep getting this error at "make". > > > > > > .. > > cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > > -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. > > -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf > > -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd > > -I../../../contrib/ngatm -I../../../dev/twa -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 > > -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c > > ../../../fs/devfs/devfs_vnops.c:1172: warning: redundant redeclaration of > > 'devfs_ops_f' > > ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of > > 'devfs_ops_f' was here > > ../../../fs/devfs/devfs_vnops.c:1183: warning: redundant redeclaration of > > 'devfs_vnodeops' > > ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of > > 'devfs_vnodeops' was here > > ../../../fs/devfs/devfs_vnops.c:1205: warning: redundant redeclaration of > > 'devfs_specops' > > ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of > > 'devfs_specops' was here > > *** Error code 1 > > > > > > I even get that error building a kernel from the GENERIC config. I think > > something is wonky with gcc. >Has anyone else seen this, or know what could > > be causing it? > > > >You didn't follow the correct upgrade order - it's documented in the > >handbook and in /usr/src/UPDATING. > > > >Kris > > Thanks for that info. I have the kernel built now. I noticed that it > is built from the source in /usr/obj and not /usr/src. No, /usr/obj contains the results of your buildworld, it's not a second copy of the source. > In 6.x, do we > have to keep /usr/obj after installworld, or should installworld > have updated /usr/src ? You do not have to keep /usr/obj. Kris P.S. Please wrap your lines so that your emails may be easily read. pgpP9slLKBnjI.pgp Description: PGP signature
vmstat still stalls (Re: more weird bugs with mmap-ing via NFS)
вівторок 21 березень 2006 20:09, Matthew Dillon Ви написали: > 'vmstat 1' while the program is running would tell us if VM faults > are creating an issue. This problem -- vmstat and `systat -vm' occasionally stalling the entire system -- did not go away, it just became less frequent and severe. What is vmstat doing, that -- under heavy reading *in* of VN pages -- could freeze the entire system for a minute or so? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flushing "anonymous" buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)
середа 22 березень 2006 15:20, Matthew Dillon Ви написали: > The only real solution is to make the NFS client aware of the > restricted user id exported by the server by requiring that the > same uid be specified in the mount command the client uses to > mount the NFS partition. The NFS client would then use that user id > for all write I/O operations. What about different users accessing the same share from the same client? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nve timeout (and down) regression?
On recent releng_6 I have again nve timeouts and interface down status Yesterday I found this thread http://lists.freebsd.org/pipermail/freebsd-bugs/2005-October/015351.html and the change in if_nve.c resolved my problem still having lots of collisions coming from this NIC but it stays up and running now João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 on Dell 1850 with PERC4e/DC RAID?
On Thu, Jan 05, 2006 at 10:41:50PM +, Scott Mitchell wrote: > Hi all, > > I may be getting a new Dell PE1850 soon, to replace our ancient CVS server > (still running 4-STABLE). The new machine will ideally run 6.0 and have a > PERC4e/DC RAID card - the one with battery-backed cache. This is listed as > supported by amr(4), but I'm wondering how well it actually works in the > case of a disk failure. Will the driver tell me that disk has failed (a > syslog message would be enough) or will I have to make a daily trip into > the server room to check the front panel lights? Presumably it handles > hot-swapping a replacement drive OK? > > I found some posts mentioning some management/monitoring tools for these > controllers that were allegedly available from the www.lsilogic.com > website, but I can't find anything on there for FreeBSD. Do the Linux > tools work? Following up to myself for the benefit of the archives - I can confirm that the PERC4e in the PE1850 works perfectly with amr(4) under 6.0. I've been using the sysutils/megarc port for managing the adapter from FreeBSD. It has a truly awful user interface but allows you to do everything that the BIOS setup program does, so far as I can tell. For monitoring we're relying on the email alerts from the DRAC/4 management card also in the machine, which turn out to work very well. We actually had a disk failure on the machine already (one of the drives had apparently worked itself a bit loose in transit and decided to power itself off a few days after I put the machine in the rack). The DRAC sent out an email when the drive "died", it auto-rebuilt when shoved back into the slot properly, then another email from the DRAC when the rebuild was complete. I'm looking forward to the amr(4) performance improvements in 6.1 and being able to run the Linux megmgr tool (I think this is the one with the same user interface as the BIOS setup program). Cheers, Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: flushing "anonymous" buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)
:This doesn't work with modes like 446 (which allow writing by everyone :not in a particular group). It should work just fine. The client validated the creds as of the original operation (such as the mmap() or the original write()). Regardless of what happens after that, if the creds were valid when the original operation occured, then the server should allow the write. If the client supplies root creds for a later operation and the server translated that to mean 'write it if its possible to write without root creds' for exports whos roots were not mapped to root, it would actually conform better to the reality of the state of the file at the time the client originally performed the operation verses if the client provided the user creds of the original write. If the file were chmoded or chowned inbetween the original write and the actual I/O operation then it is arguable that the delayed write I/O should succeed rather then fail. :Doesn't that amount to significantly reducing the security of NFS? :ISTR the original reason for "nobody" was that it was trivial to fake :root so the server would map it to an account with (effectively) no :privileges. This change would give root on a client (file) privileges :equal to the union of every non-root user on the server. In :particular, it appears that the server can't tell if a file was opened :for read or write so a client could open a file for reading (getting a :valid FH) and then write to it (even though it couldn't have opened the :file for writing). : :-- :Peter Jeremy No, it has no effect on the security of NFS. With the exception of 'root' creds, the server trusts the client's creds, so there isn't going to be any real difference between the client supplying user creds verses the server translating root creds into some non-root user's creds. NFS has never been secure. The only reasonably secure method of exporting a NFS filesystem is to export an entire filesystem read-only. For any read-write export, NFS is only secure insofar as you assume that the client can then modify any file in the exported filesystem. The 'maproot' option is a bandaid at best, and not a very good one. For example, exporting subdirectories of a filesystem is not secure (and never was). It is fairly trivial for a client to supply file handles that are outside of the subdirectory tree that was exported. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pkgdb core dumb
On Thursday 23 March 2006 11:11, Kaveh Ahmadian wrote: > After a recent update, whenever I try to run the pkgdb (or any other > command that in turn calls pkgdb I get an error resulting in a core dump: > > [Updating the pkgdb in /var/db/pkg ... - 24 packages > found (-1 +2) (...).ruby18 in free(): error: chunk is already free > Abort (core dumped) I've seen this a number of times; it usually means a corrupt pkgdb. Rebuild it from scratch (pkgdb -fu). If that fails or if you still get the error afterwards, rebuild and reinstall portupgrade and ruby (without using portupgrade in the process). Run 'pkgdb -fu' again after the reinstall. JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with mpt
Matthew Jacob wrote: working on it over the next month Thank you for reply. Can i help somehow with this issue? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 PRERELEASE kernel build error
- Original Message - From: Kris Kennaway <[EMAIL PROTECTED]> To: Casey Scott <[EMAIL PROTECTED]> Cc: freebsd-stable@freebsd.org Sent: Thursday, March 23, 2006 0:27:30 AM GMT-0800 Subject: Re: 6.1 PRERELEASE kernel build error On Wed, Mar 22, 2006 at 10:27:56AM -0800, Casey Scott wrote: > I just upgraded 5.4 stable to 6.1 PRERELEASE via buildworld. I am trying to > build a kernel, and keep getting this error at "make". > > > .. > cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. > -I../../.. -I../../../contrib/altq -I../../../contrib/ipfilter > -I../../../contrib/pf -I../../../contrib/dev/ath > -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm > -I../../../dev/twa -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 > -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c > ../../../fs/devfs/devfs_vnops.c:1172: warning: redundant redeclaration of > 'devfs_ops_f' > ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of > 'devfs_ops_f' was here > ../../../fs/devfs/devfs_vnops.c:1183: warning: redundant redeclaration of > 'devfs_vnodeops' > ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of > 'devfs_vnodeops' was here > ../../../fs/devfs/devfs_vnops.c:1205: warning: redundant redeclaration of > 'devfs_specops' > ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of > 'devfs_specops' was here > *** Error code 1 > > > I even get that error building a kernel from the GENERIC config. I think > something is wonky with gcc. >Has anyone else seen this, or know what could > be causing it? > >You didn't follow the correct upgrade order - it's documented in the >handbook and in /usr/src/UPDATING. > >Kris Thanks for that info. I have the kernel built now. I noticed that it is built from the source in /usr/obj and not /usr/src. In 6.x, do we have to keep /usr/obj after installworld, or should installworld have updated /usr/src ? Casey ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pkgdb core dumb
After a recent update, whenever I try to run the pkgdb (or any other command that in turn calls pkgdb I get an error resulting in a core dump: [Updating the pkgdb in /var/db/pkg ... - 24 packages found (-1 +2) (...).ruby18 in free(): error: chunk is already free Abort (core dumped) Here is the output of pkg_version -v apache-2.0.50_3 < needs updating (port has 2.0.55_4) autoconf-2.59_2 = up-to-date with port automake-1.8.5_2< needs updating (port has 1.9.6) cvsup-without-gui-16.1h < needs updating (port has 16.1h_2) db42-4.2.52_3 < needs updating (port has 4.2.52_4) exim-4.42+27< needs updating (port has 4.60) expat-1.95.8< needs updating (port has 2.0.0_1) ezm3-1.2= up-to-date with port gettext-0.13.1_1< needs updating (port has 0.14.5_2) gmake-3.80_2= up-to-date with port help2man-1.33.1 < needs updating (port has 1.36.3) libiconv-1.9.2_1< needs updating (port has 1.9.2_2) libtool-1.5.8 < needs updating (port has 1.5.22_2) m4-1.4.1< needs updating (port has 1.4.4) mod_fcgid-0.80 < needs updating (port has 1.07) neon-0.24.7 < needs updating (port has 0.25.4_1) openssl-0.9.8a = up-to-date with port p5-gettext-1.01_4 < needs updating (port has 1.05_1) perl-5.8.8 = up-to-date with port portupgrade-20040701_3 < needs updating (port has 2.0.1_1,1) ruby-1.8.4_4,1 = up-to-date with port ruby18-bdb1-0.2.2 = up-to-date with port ruby18-gems-0.8.11 = up-to-date with port subversion-1.0.8< needs updating (port has 1.3.0_4) Should I also include the core dump? Thanks in advance. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: a place for configuration files
On Mar 22, 2006, at 8:28 PM, Gary Kline wrote: I think having a /usr/local/etc is "new" (past decade maybe), We've had /usr/local on Sun boxes since I can remember (started using SunOS 2.x back in college) and administering 4.2BSD (not FreeBSD 4.2, but 4.2BSD from Berkeley) on vaxen 'round about 1986-ish and we had / usr/local for local (ie, not part of the base system) software. In fact, it was actually a separate disk partition too. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ifconfig -am shows ...
Hi, my ifconfig -am command result is as follows; em0: flags=8843 mtu 1500 options=b capabilities=5b inet 10.0.10.114 netmask 0xfffc broadcast 10.0.10.115 ether 00:04:23:c2:db:fc media: Ethernet autoselect (1000baseSX ) status: active supported media: media autoselect media 1000baseSX media 1000baseSX mediaopt full-duplex But I know that it is an LX card. The connection is working. Can it be a cause of bottleneck for my network or just a small bug?? Thanks for advance. Husnu Demir. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A place for configuration files
On Thu, Mar 23, 2006 at 12:00 , the murky waters churned and seethed, the dark weeds parted and the water took on the sinister, shifting visage we recognize as [EMAIL PROTECTED] The great maw opened, and the following was heard: > Message: 1 > Date: Thu, 23 Mar 2006 02:06:07 +0100 > From: Andrzej Cuber <[EMAIL PROTECTED]> > Subject: a place for configuration files > To: freebsd-stable@freebsd.org > Hello Everyone, > for the last 5 years I was using Red Hat and Fedora Core > Linuxes. With the beginning of the current year I installed > FreeBSD Release 6 on one of my servers. It took me about a week > to setup the system but I am very happy with it now. > I build most of the stuff from the sources using ports. > What I found strange is that the configuration files of > different services are located in two different places. Most > configuration which was installed from the CD is located at > /etc but everything what I built from sources is located at > /usr/local/etc. Maybe this is the way it use to be on Unix based > systems. > In RedHat and Fedora distributions all configuration files > are located at /etc. I am very new to FreeBSD but I found it > difficult. After installing desired package I have to add it to > /etc/rc.conf in order to start it as a service and then I have > to look for configuration folder in /usr/local/etc. > Is there any reason why the configuration files are placed in > those different locations? > -- > pozdrawiam / best regards > Andrzej Cuber > +48 504 271-977 Once you get more familiar with BSD you will begin to appreciate the way it is done on BSD. One really nice thing is that by separating the OS and the user added 'local' programs, you can actually remake the / file system, reinstall the OS, and not lose any of you local applications or data. As another reply indicated rebuiling from sources will also let you reinstall the base OS, and the only thing you would have to do to make sure no drek is left over is to list the base directories by time created to find any old pieces and remove if needed. Another way that BSD differs it to have several file systems to start with while many recent Linux installations [which I've been called in to look at] seem to use the old MS approach of everything in one FS. With over 20 years of Unix experiences so far [on many platforms and at least 6 different CPU bases] I find the multiple FS'es, with each handling only certain functions, makes a recover in case of the rare crashes, much easier, and much faster. And faster means quicker client uptime. As I tell the customers when I get them back up in a hurry, "if you are down you aren't making money and if you aren't making money you can't pay me". They appreciate that approach, and I've changed some commercial OSes to use the FreeBSD approach to great success. Particularly when the data segments accumulated by the customer become quite huge. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Temperature monitoring in FreeBSD 4/5/6
O. Hartmann schrieb: > Roland Smith schrieb: >> On Thu, Mar 16, 2006 at 07:22:14PM -0500, Stephan Koenig wrote: >>> Does anyone know of an easy way to get temperature information out of >>> a Dell PowerEdge 1550/1650/1750/1850/2650/2850 running FreeBSD4/5/6? >>> >>> Something that has a very simple CLI that just outputs the temperature >>> without any formatting, or a library/sysctl, would be ideal. >> /usr/ports/sysutils/mbmon >> >> If you want an additional X frontend, try >> >> /usr/ports/sysutils/xmbmon >> >> Roland > > This port does not work for me on any DELL Optiplex GX270/280 and 820 > around here. Especially on GX270/280 I tried every knob of the port I > found without a positive result. > > Oliver > It does also not work on ASUS A8N32-SLI due to an unsupported chipset. O. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
strange deadlock and magic resurrection with RELENG_6
Hi, I'm using a recent RELENG_6 under I386/SMP (Athlon X2 4800+). dmesg output is under http://people.freebsd.org/~mr/dmesg.log.gz Root is on gmirror volume (2 SATA disks), a backup FS is on graid3 (5 firewire disks). This server acts as an bacula server. During backup with bacula I discovered an complete system freeze (no keyboard, nfs, disk...) after the following lines on the screen: ... ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=108916879 ad1: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=116030287 ad1: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=108911183 ad1: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=108378767 Since I could ping the system and after waiting a couple of hours in the hope the system would would resurrection by itself, I issued an flood-ping to this machine and voila, after getting the following lines: ... Limiting icmp ping response from 261 to 200 packets/sec Limiting icmp ping response from 283 to 200 packets/sec ... Anything went back to normality! This seems to me that we have an deadlock condition somewhere in the kernel. But how to debug this issue when anything is frozen? BTW: I've got the DMA errors in the past allready which seems to be an interaction between ata and some geom modules. See a former post from me regarding this issue. Maybe the same issue got fatal now after the latest gmirror/graid3 changes? Has anyone else seen this? Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 PRERELEASE kernel build error
On Wed, Mar 22, 2006 at 10:27:56AM -0800, Casey Scott wrote: > I just upgraded 5.4 stable to 6.1 PRERELEASE via buildworld. I am trying to > build a kernel, and keep getting this error at "make". > > > .. > cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. > -I../../.. -I../../../contrib/altq -I../../../contrib/ipfilter > -I../../../contrib/pf -I../../../contrib/dev/ath > -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm > -I../../../dev/twa -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 > -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c > ../../../fs/devfs/devfs_vnops.c:1172: warning: redundant redeclaration of > 'devfs_ops_f' > ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of > 'devfs_ops_f' was here > ../../../fs/devfs/devfs_vnops.c:1183: warning: redundant redeclaration of > 'devfs_vnodeops' > ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of > 'devfs_vnodeops' was here > ../../../fs/devfs/devfs_vnops.c:1205: warning: redundant redeclaration of > 'devfs_specops' > ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of > 'devfs_specops' was here > *** Error code 1 > > > I even get that error building a kernel from the GENERIC config. I think > something is wonky with gcc. Has anyone else seen this, or know what could be > causing it? You didn't follow the correct upgrade order - it's documented in the handbook and in /usr/src/UPDATING. Kris pgp3pgs8PE53C.pgp Description: PGP signature
6.1 PRERELEASE kernel build error
I just upgraded 5.4 stable to 6.1 PRERELEASE via buildworld. I am trying to build a kernel, and keep getting this error at "make". .. cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -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 -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c ../../../fs/devfs/devfs_vnops.c:1172: warning: redundant redeclaration of 'devfs_ops_f' ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of 'devfs_ops_f' was here ../../../fs/devfs/devfs_vnops.c:1183: warning: redundant redeclaration of 'devfs_vnodeops' ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of 'devfs_vnodeops' was here ../../../fs/devfs/devfs_vnops.c:1205: warning: redundant redeclaration of 'devfs_specops' ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of 'devfs_specops' was here *** Error code 1 I even get that error building a kernel from the GENERIC config. I think something is wonky with gcc. Has anyone else seen this, or know what could be causing it? TIA, Casey Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
