Re: xf86enableIO error (Feb 2005 Snapshots for FreeBSD available)
I got an io error "xf86EnableIO: Fatal to open /dev/io for extended I/O" when running "Xorg -configure". Has this snapshot been fixed this problem? Eitarou ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
In article <[EMAIL PROTECTED]> Warner Losh <[EMAIL PROTECTED]> writes: > > The following is the result when use SATA 200GB disk on pc98. It is > > clearly that recognizing a geometry fails. > > > > atapci0: port > > 0xc000-0xc00f,0x602c-0x602f,0x6030-0x6037,0x6028-0x602b,0x6020-0x6027 mem > > 0x20411000-0x204113ff irq 10 at device 17.0 on pci0 > > ad4: ATA-6 disk at ata2-master > > ad4: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B > > ad4: 16 secs/int, 1 depth queue, SATA150 > > > > BIOS Geometries: > > 1:1778 0..6008=6009 cylinders, 0..255=256 heads, 1..255=255 sectors > > Is this the geometry that the PC98 BIOS uses? Yes. --- TAKAHASHI Yoshihiro <[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: Feb 2005 Snapshots for FreeBSD available
On Tue, Feb 15, 2005 at 08:29:13AM -0800, Nate Lawson wrote: > >The snapshots on snapshots.[jp|se].freebsd.org are date-suffixed (however, > >those servers don't build snaps for all platforms). > > > > I'm talking hour/min./second, thanks. Both checkout code as of 00:00:00 GMT on the date the snapshot is built for. Sooner or later I may change .se to check it out as of 12:00:00 GMT instead, to provide some variety... Regards, -- wca pgpXSOf3VstTF.pgp Description: PGP signature
Re: Cross compiling
> I was just wondering whether it is posibl to build say a 4.11 kernel > on a 5.3 system - I'd like to have only one machine here on which I > maintain all the sources and buidl what i need, then I think you can > mount the /usr/obj file system and /usr/src and run the install stages > on other systems. Yes. I do this all the time. I never build in /usr/src or /usr/obj :-). One has to make sure that one has the right config to generate the compile tree with. I believe that the compilers are still compatable enough to allow this to happen. Building world can be done, but may require some hand steps. It has been a while since I've done this. > Also, can I build kernels for different architectures on a normal i386 box? Yes. See the recent cross compilation thread in freebsd-arch for details. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Save the Demon!
On Tue, 15 Feb 2005 11:46:07 -1000, Randy Bush <[EMAIL PROTECTED]> wrote: > > AFAIK, one of the main points of that logo competition is > > to do away with anything that could be interpreted in an > > religious way. > > this is sick. should it happen, i'll take up the penguin. Wow, if that's your take on it, then maybe you should. A logo isn't an OS. If someone somewhere can misinterpret Beastie, is it our fault or theirs? Here's the answer: it doesn't matter. A logo shouldn't, for whatever reason, good or bad, be part of anyone's decision on what OS to install. If supplementing Beastie with a different logo brings more users to FreeBSD, then it's a no-brainer. -- Jared Earle :: http://www.23x.net [EMAIL PROTECTED] :: There is no SPORK ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to make ipfw consider MAC-IP match?
Scot Hetzel <[EMAIL PROTECTED]> wrote: On Mon, 14 Feb 2005 23:58:03 +0300, Artem Kuchin <[EMAIL PROTECTED]> wrote: Hi! I have a table with ethernet (MAC) addresses matching IPs. It is used to build dhcp config file. But regardless of that any user can assign his neighbour ips while that pc is turned off and use it to access internet. The local ips are 192.168. and are behind natd. I am running 5.3-STABLE and have heard that ipfw2 can in someway use MAC addresses, but how do I setup ipfw in such a way that it allows certain IP only from one and only one MAC address? I hope you are getting my idea. You would add the following to the end of your IPFW rule for each IP Address you want to restrict. pass all from 192.168.0.10 to any mac any 10:20:30:40:50:60 Where "10:20:30:40:50:60" is the MAC addr for IP addr 192.168.0.10. I have tried static arp today and it seems like it works. As others mentions, it is possible SOMETIMES to change mac address of a nic, so static arp may fail as well as this firewall rule. So, i am wondering which method is better static arp entries or ipfw rules? Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gvinum or vinum in 5.3-STABLE
Aristedes Maniatis wrote: Sorry to butt in on your thread, but it seems relevant. I am having problems with gvinum under 5-STABLE and a RAID 0 array of two disks. The array works perfectly until reboot. Then, when the machine comes back up the plexes are marked as stale. Issuing these commands fixes the problem until the next reboot: Once the plexes are UP, issue a 'gvinum saveconfig'. Then try rebooting and see what happens. This has worked for me before with 5.3-R, and today with a recent 5.3-STABLE. Joe Koberg [EMAIL PROTECTED] gvinum setstate up storage.p0.s0 gvinum setstate up storage.p0.s1 Things I've tried: * Googling for answers * commenting out the fstab entry at boot and then manually mounting the partition after boot * inserting gvinum in /boot/loader.conf * copying the vinum script in /etc/rc.d/vinum and making a gvinum equivalent * trying to shutdown gvinum at shutdown time (but "gvinum stop" doesn't work) * fsck * rebuilding gvinum array Is there some shutdown procedure that should gracefully shutdown the RAID? There is a process which opens files on the RAID and runs continuously until shutdown. Could it be holding the RAID open too long and could this staleness? From what I can tell the staleness doesn't affect any data - everything is OK once brought up. Cheers Ari Maniatis On 14/02/2005, at 11:38 AM, Tristan wrote: Is gvinum ready for production use in a RAID5 config ? --> ish group pty ltd http://www.ish.com.au 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[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: Save the Demon!
> AFAIK, one of the main points of that logo competition is > to do away with anything that could be interpreted in an > religious way. this is sick. should it happen, i'll take up the penguin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gvinum or vinum in 5.3-STABLE
Sorry to butt in on your thread, but it seems relevant. I am having problems with gvinum under 5-STABLE and a RAID 0 array of two disks. The array works perfectly until reboot. Then, when the machine comes back up the plexes are marked as stale. Issuing these commands fixes the problem until the next reboot: gvinum setstate up storage.p0.s0 gvinum setstate up storage.p0.s1 Things I've tried: * Googling for answers * commenting out the fstab entry at boot and then manually mounting the partition after boot * inserting gvinum in /boot/loader.conf * copying the vinum script in /etc/rc.d/vinum and making a gvinum equivalent * trying to shutdown gvinum at shutdown time (but "gvinum stop" doesn't work) * fsck * rebuilding gvinum array Is there some shutdown procedure that should gracefully shutdown the RAID? There is a process which opens files on the RAID and runs continuously until shutdown. Could it be holding the RAID open too long and could this staleness? From what I can tell the staleness doesn't affect any data - everything is OK once brought up. Cheers Ari Maniatis On 14/02/2005, at 11:38 AM, Tristan wrote: Is gvinum ready for production use in a RAID5 config ? --> ish group pty ltd http://www.ish.com.au 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Cross compiling
On Tue, Feb 15, 2005 at 09:28:33PM +, Alex Burke wrote: > Hi, > > I was just wondering whether it is posibl to build say a 4.11 kernel > on a 5.3 system - I'd like to have only one machine here on which I > maintain all the sources and buidl what i need, then I think you can > mount the /usr/obj file system and /usr/src and run the install stages > on other systems. This will usually work (you need to make buildworld first before you make buildkernel), but sometimes it's not possible to build old-branch sources on a new branch (e.g. 4.x on 5.3). > Also, can I build kernels for different architectures on a normal i386 box? make buildworld TARGET_ARCH=whatever; make buildkernel TARGET_ARCH=whatever. Kris pgpCkJvJOOOsx.pgp Description: PGP signature
Cross compiling
Hi, I was just wondering whether it is posibl to build say a 4.11 kernel on a 5.3 system - I'd like to have only one machine here on which I maintain all the sources and buidl what i need, then I think you can mount the /usr/obj file system and /usr/src and run the install stages on other systems. Also, can I build kernels for different architectures on a normal i386 box? Thanks, Alex J Burke. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make buildworld for RELENG_5 failing on RELENG_5_3 in /usr/src/usr.sbin/syslogd, _PATH_LOG_PRIV not defined
Steve Hodgson wrote: On Tuesday 15 February 2005 14:02, Tuure Laurinolli wrote: Steve Hodgson wrote: On Sunday 16 January 2005 17:37, Kris Kennaway wrote: On Sun, Jan 16, 2005 at 02:22:05PM +, Steve Hodgson wrote: I'm getting the following error on a RELENG_5_3 box when trying to compile the RELENG_5 sources. I've been cvsupping now for about a week and continuing to get the same error when we get to syslogd. I get the same error updating RELENG_5_3 to RELENG_5. It's strange because the constant most certainly is defined in /usr/src/sys/sys/syslog.h. However, when I straced the make, it seemed that this file was never used. Instead it used syslog.h from my already installed system! On Tuesday 15 February 2005 14:02, Tuure Laurinolli wrote: Steve Hodgson wrote: On Sunday 16 January 2005 17:37, Kris Kennaway wrote: On Sun, Jan 16, 2005 at 02:22:05PM +, Steve Hodgson wrote: I'm getting the following error on a RELENG_5_3 box when trying to compile the RELENG_5 sources. I've been cvsupping now for about a week and continuing to get the same error when we get to syslogd. I get the same error updating RELENG_5_3 to RELENG_5. It's strange because the constant most certainly is defined in /usr/src/sys/sys/syslog.h. However, when I straced the make, it seemed that this file was never used. Instead it used syslog.h from my already installed system! In the end I traced this down to devel/ccache which I was using at the time. I had copied the lines from /usr/local/share/doc/ccache/make.conf into my own make.conf: I don't have anything like that in my make.conf, only the following: CPUTYPE?=p3 CFLAGS= -g -O -pipe COPTFLAGS= -O2 -pipe NO_LPR= true NO_X= true NOGAMES=true SUP_UPDATE= yes SUPFLAGS= -g -L 2 -Z SUPHOST=cvsup2.se.freebsd.org SUPFILE=/root/standard-supfile PORTSSUPFILE= /root/ports-supfile PERL_VER=5.8.6 PERL_VERSION=5.8.6 Can't recall why i didn't send-pr this one - probably because no one else has complained till now. Apparently I also don't have any time to look at it today, I guess I'll have to try to find some time tomorrow. I'll send-pr once I dig about it a bit more. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make buildworld for RELENG_5 failing on RELENG_5_3 in /usr/src/usr.sbin/syslogd, _PATH_LOG_PRIV not defined
On Tuesday 15 February 2005 14:02, Tuure Laurinolli wrote:
> Steve Hodgson wrote:
> > On Sunday 16 January 2005 17:37, Kris Kennaway wrote:
> >>On Sun, Jan 16, 2005 at 02:22:05PM +, Steve Hodgson wrote:
> >>>I'm getting the following error on a RELENG_5_3 box when trying to
> >>>compile the RELENG_5 sources. I've been cvsupping now for about a week
> >>>and continuing to get the same error when we get to syslogd.
>
> I get the same error updating RELENG_5_3 to RELENG_5. It's strange
> because the constant most certainly is defined in
> /usr/src/sys/sys/syslog.h. However, when I straced the make, it seemed
> that this file was never used. Instead it used syslog.h from my already
> installed system!
>
On Tuesday 15 February 2005 14:02, Tuure Laurinolli wrote:
> Steve Hodgson wrote:
> > On Sunday 16 January 2005 17:37, Kris Kennaway wrote:
> >>On Sun, Jan 16, 2005 at 02:22:05PM +, Steve Hodgson wrote:
> >>>I'm getting the following error on a RELENG_5_3 box when trying to
> >>>compile the RELENG_5 sources. I've been cvsupping now for about a week
> >>>and continuing to get the same error when we get to syslogd.
>
> I get the same error updating RELENG_5_3 to RELENG_5. It's strange
> because the constant most certainly is defined in
> /usr/src/sys/sys/syslog.h. However, when I straced the make, it seemed
> that this file was never used. Instead it used syslog.h from my already
> installed system!
>
In the end I traced this down to devel/ccache which I was using at the time. I
had copied the lines from /usr/local/share/doc/ccache/make.conf into my own
make.conf:
.if !defined(NOCCACHE)
.if ${.CURDIR:M/usr/src*}
CC=/usr/local/libexec/ccache/cc
CXX=/usr/local/libexec/ccache/c++
.else
CC=cc
CXX=c++
.endif
.else
CC=/usr/bin/cc
CXX=/usr/bin/c++
.endif
However the check on line 2 didn't appear to have the desired effect, so
instead of CC staying equal to "cc" and pulling in the buildworld cc and
headers, it used the system cc and headers. Of course I then tried NOCCACHE=1
without reading the code, which by definition will do the same thing (system
compiler and headers). In the end I commented all these lines out and
buildworld completed.
Can't recall why i didn't send-pr this one - probably because no one else has
complained till now.
Steve
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to make ipfw consider MAC-IP match?
On Mon, 14 Feb 2005 23:58:03 +0300, Artem Kuchin <[EMAIL PROTECTED]> wrote: > Hi! > > I have a table with ethernet (MAC) addresses matching IPs. It is > used to build dhcp config file. But regardless of that any user can > assign his neighbour ips while that pc is turned off and use it to > access internet. The local ips are 192.168. and are behind natd. > I am running 5.3-STABLE and have heard that ipfw2 can in someway > use MAC addresses, but how do I setup ipfw in such a way that > it allows certain IP only from one and only one MAC address? > I hope you are getting my idea. > You would add the following to the end of your IPFW rule for each IP Address you want to restrict. pass all from 192.168.0.10 to any mac any 10:20:30:40:50:60 Where "10:20:30:40:50:60" is the MAC addr for IP addr 192.168.0.10. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
From: Takahashi Yoshihiro <[EMAIL PROTECTED]> Subject: Re: UPDATE: ATA mkIII first official patches - please test! Date: Tue, 15 Feb 2005 21:08:05 +0900 (JST) > In article <[EMAIL PROTECTED]> > Søren Schmidt <[EMAIL PROTECTED]> writes: > > > >>>2. A geometry translation for pc98 is NOT enough. > > >>> > > >>> Currently, it works only under 4.3GB disk. > > > > Wrong, ATA mk3 does solve the problem but using the "current" geomtry > > set in the drives by the BIOS. However the code missed it in one place > > in ata-lowlevel.c when the code was moved there from ata-disk.c. > > This has been fixed and will be present in the next snapshot as I sadi > > earlier. > > > ATA-mkIII does NOT completely solve the problem. > > The word 54-58 of the IDENTIFY DEVICE parameter are valid only up to > ATA/ATAPI-5. They are obsolete parameters in ATA/ATAPI-6 and later. > So using them for a geometry translation has NO effect for recent > disks. That would explain why all the disks that I tried worked with the IDENTIFY DEVICE patches I posted elsewhere (from 1.6G to 120G). I don't have any ata6 disks. That's one mystery solved. :-) > The following is the result when use SATA 200GB disk on pc98. It is > clearly that recognizing a geometry fails. > > atapci0: port > 0xc000-0xc00f,0x602c-0x602f,0x6030-0x6037,0x6028-0x602b,0x6020-0x6027 mem > 0x20411000-0x204113ff irq 10 at device 17.0 on pci0 > ad4: ATA-6 disk at ata2-master > ad4: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B > ad4: 16 secs/int, 1 depth queue, SATA150 > > BIOS Geometries: > 1:1778 0..6008=6009 cylinders, 0..255=256 heads, 1..255=255 sectors Is this the geometry that the PC98 BIOS uses? Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feb 2005 Snapshots for FreeBSD available
> > I'm talking hour/min./second, thanks. > > > What it sounds like you really want is the CVS revision ID for every > file in the snapshot so that when someone reports a bug that you think > you might have fixed already, you can just point them to the correct > revision. Haven't you learned that vagueness and uncertainty is what > makes computers fun?? =-) If the snapshots were made with a checkout -D 'XX/XX/XX HH:MM:SS', then you'd have that knowledge implicitly by the date. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
I concur that the situation got much better with 5.3-Stable. What I experienced afterward occurred only under load. -Jonathan On Tue, 15 Feb 2005, Alan Jay wrote: > > -Original Message- > > On Tue, Feb 15, 2005 at 04:53:24PM -, Alan Jay wrote: > > > I had major problems installing with more than 4Gb but once I moved to > > stable > > > we seemed to have a stable platform when doing basic stuff - we have two > > > databases (mySQL) one is reasonably heavily used and one very extensively > > > used. > > > > Just to be clear, you're stating you had stability problems with > > 5.3-RELEASE and >4GB. But with 5.3-STABLE and >4GB you have a stable > > system. Correct? > > [Alan Jay] I could not install with RELEASE but could with Stable. > > Once installed and running we installed mySQL on the two machines one we > copied over a relatively simple database which ran fine without a problem. > > The second machine then had another mySQL database moved to it and it started > to fall over. After a number of tests we moved the first database off the > what had been working server and put the other database on it. At which point > that server which had been stable fell over! > > > > I think I agree wholeheartedly with your comments being a great supporter > > of > > > FreeBSD it is a shame that the AMD release is not as super as the other > > > versions we have used extensively. > > > > The problem is a major bug that has existed since FreeBSD ?3.0? was > > exposed very close to the 5.3 release cycle. This bug only causes a > > major problem with >4GB, thus few of us developers experienced it. > > [Most of us can't afford >4GB in our machines. Donations of 1GB DIMMs > > for FreeBSD developers are accepted by [EMAIL PROTECTED] > > [Alan Jay] I'll put them on my present list :) > > > Of course one reason many are moving to the AMD64 platform is to have > > >4GB RAM in the machine. We believe this bug has been fixed in > > 5.3-STABLE. But too few people are testing 5.3-STABLE and are using > > 5.3-RELEASE instead. This isn't helping us QA the issue so that we know > > all the corner cases are fixed in upcoming 5.4 release. > > [Alan Jay] Well the memory seemed to be stable on 5.3 STABLE with more than > 4Gb in our case 8Gb there seems to be some other problem at work here. > > > A recent 5.3-STABLE snapshot can be found as > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Feb_2005/5.3-STABLE-SNAP001- > > amd64-miniinst.iso > > and mirrors. > > > > -- > > -- David ([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: make buildworld for RELENG_5 failing on RELENG_5_3 in /usr/src/usr.sbin/syslogd, _PATH_LOG_PRIV not defined
Steve Hodgson wrote: On Sunday 16 January 2005 17:37, Kris Kennaway wrote: On Sun, Jan 16, 2005 at 02:22:05PM +, Steve Hodgson wrote: I'm getting the following error on a RELENG_5_3 box when trying to compile the RELENG_5 sources. I've been cvsupping now for about a week and continuing to get the same error when we get to syslogd. I get the same error updating RELENG_5_3 to RELENG_5. It's strange because the constant most certainly is defined in /usr/src/sys/sys/syslog.h. However, when I straced the make, it seemed that this file was never used. Instead it used syslog.h from my already installed system! This seems like a grave error in some makefile to me, will look further into it later today. anyone has any other ideas I guess I'll continue reattempting this. Are there any objections to doing a make installworld/installkernel on the results after applying my patches - will that bork my system, could it help in anyway? Looking at the CVS notes and the code itself, I don't think it should cause any problems - though this probably is a late notice anyway :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: Fatal trap 12: page fault while in kernel mode
Hello, This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM and a LSI 21320 rmpt(4) running at 160MB/s with a hardware RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on /da0/ I can *reproduce* this panic again and again: (I'm getting a dump now, let me fsck first) kernel conf & dmesg (boot -v) are at http://rafan.infor.org/tmp/236/ any suggestions are welcome. :) Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x88 fault code = supervisor read, page not present instruction pointer = 0x8:0x80235b0b stack pointer = 0x10:0xb1bd5a50 frame pointer = 0x10:0xb1bd5a70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 96 (pagedaemon) [thread 100114] Stopped at thread_fini+0xab: subl0x88(%ebx),%eax db> trace thread_fini() at thread_fini+0xab zone_drain() at zone_drain+0x22d zone_foreach() at zone_foreach+0x76 uma_reclaim() at uma_reclaim+0x15 vm_pageout_scan() at vm_pageout_scan+0x170 vm_pageout() at vm_pageout+0x38e fork_exit() at fork_exit+0xaa fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xb1bd5d00, rbp = 0 --- db> ps pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 615 ff00603348b8 b43b50000 568 615 000c082 (threaded) blogbench thread 0xff001e7ef000 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881fa40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d19c40][SLP] thread 0xff001c25d520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d37640][SLP] thread 0xff000881fcd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001ffa27b0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001b755520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a373640][SLP] thread 0xff0070700a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2d8b40][SLP] thread 0xff002c333cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f1c140][SLP] thread 0xff00462e0520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a104e40][SLP] thread 0xff0011002a40 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059594c80][SLP] thread 0xff006310f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a237740][SLP] thread 0xff003c731520 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff00087c1500][SLP] thread 0xff0033c33290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ee8e40][SLP] thread 0xff00635a7290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d86840][SLP] thread 0xff006ff7ccd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881f520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fbb440][SLP] thread 0xff006eff2520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a01640][SLP] thread 0xff004d176520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a069140][SLP] thread 0xff0048ded520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f9c540][SLP] thread 0xff003689f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d7c940][SLP] thread 0xff0052446cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f22d40][SLP] thread 0xff006eff2000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a6c140][SLP] thread 0xff0054121cd0 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059112500][SLP] thread 0xff00492bc000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a315440][SLP] thread 0xff003289ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ff1d40][SLP] thread 0xff0055b3ea40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fe2140][SLP] thread 0xff0055b3e000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x999d1340][SLP] thread 0xff003689f290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2bc040][SLP] thread 0xff000881f000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99bc8440][SLP] thread 0xff006ff7c000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c2ed40][SLP] thread 0xff003289b000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a0c0a40][SLP] thread 0xff003c731a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c9ec40][SLP] thread 0xff0009f50cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99b1c240][SLP] thread 0xff000dbd5cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a1fff40][SLP] thread 0xff003c9bdcd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d06440][SLP] thread 0xff003c9bd7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a202c40][SLP] thread 0xff006ac1ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a30c740][SLP] thread 0xff00342f4290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a00ee40][SLP] thread 0xff004819d290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99dc3440][SLP] thread 0xff005cd927b0 ksegrp 0xf
bonding interfaces on 5.3-stable SMP.
I'm having some problem with interface bonding on 5.3 stable. I used this before on 4.x without problems. I can't run 5.3-R becuase my SysKonnect nics panic the box when i load the drivers. (5.3-Stable fixed this). First off this is how i'm bonding nics. kldload ng_ether # create ngeth0 and bond sf2 and sf3 to it ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect sk0: ngeth0:lower lower many0 ngctl connect sk1: ngeth0:lower lower many1 ngctl connect sk2: ngeth0:lower lower many2 ngctl msg sk0: setpromisc 1 ngctl msg sk1: setpromisc 1 ngctl msg sk2: setpromisc 1 ngctl msg ngeth0: setautosrc 0 ngctl msg sk0: setautosrc 0 ngctl msg sk1: setautosrc 0 ngctl msg sk2: setautosrc 0 # bring up ngeth0 for sniffing duties ifconfig ngeth0 -arp up This works fine for a little while on a SMP kernel, then for what ever reason it stops working (could be mins or hours). Working meaning the ngeth0 nic stops seeing traffic. If I down and then up the ngeth0 nic it will start seeing traffic again. I'm not completely sure but i think it may be related to the SMP kernel. I've tried to duplicate this with GENERIC but i'm still testing. The main app this box is running is NTOP ver 3.1 (from ports). I'm also using the local pcap (not the one from ports). This also bring up a new question. Is this the correct way to do the interface bonding (for sniffing only)? I noticed ng_hub but i couldn't figure out how to make it work with ngeth0. If someone could give me a hand with that that would be great! :) Thanks! oh btw this is 5.3-STABLE FreeBSD 5.3-STABLE #1: Fri Feb 11 10:27:16 CST 2005 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: swapfile being eaten by unknown process
On Tue, Feb 15, 2005 at 04:11:31PM +, John wrote: > Another data point - I see this in my nightly security logs: > > swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 28190, size: 4096 > > maybe there's a bad block on the swap partition?? That's what this usually means, yes. Kris pgp2HBOAkujzL.pgp Description: PGP signature
Re: gvinum or vinum in 5.3-STABLE
On Tue, 15 Feb 2005, Tristan wrote: > On Mon, 14 Feb 2005 11:08:26 +1030 > Tristan <[EMAIL PROTECTED]> wrote: > > > > can anyone confirm what the preferred tool is > > in 5.3-STABLE, vinum or gvinum ? Is gvinum > > ready for production use in a RAID5 config ? > > Does this limitation still exist (from 5.3 ERRATA): > While some uncommon configurations, such as multiple vinum > drives on a disk, are not supported Yes. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to make ipfw consider MAC-IP match?
On Mon, Feb 14, 2005 at 04:18:47PM -0600, Chris Dillon wrote: > >(i did not undestrand, how i somebody can match mac and ip with > >static arp except that he actually get the physical NIC from > >somebody's computer). > > Because you can change the MAC address of your NIC to match someone > else's very easily. Here's how in FreeBSD: > > ifconfig fxp0 link 00:11:22:33:44:55 > > It's that easy... It's not that easy. Not all cards support MAC address change. And even if a card support this, it is not always possible to do this with ifconfig. -ip -- On a beautiful day like this it's hard to believe anyone can be unhappy -- but we will work on it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
> -Original Message- > On Tue, Feb 15, 2005 at 04:53:24PM -, Alan Jay wrote: > > I had major problems installing with more than 4Gb but once I moved to > stable > > we seemed to have a stable platform when doing basic stuff - we have two > > databases (mySQL) one is reasonably heavily used and one very extensively > > used. > > Just to be clear, you're stating you had stability problems with > 5.3-RELEASE and >4GB. But with 5.3-STABLE and >4GB you have a stable > system. Correct? [Alan Jay] I could not install with RELEASE but could with Stable. Once installed and running we installed mySQL on the two machines one we copied over a relatively simple database which ran fine without a problem. The second machine then had another mySQL database moved to it and it started to fall over. After a number of tests we moved the first database off the what had been working server and put the other database on it. At which point that server which had been stable fell over! > > I think I agree wholeheartedly with your comments being a great supporter > of > > FreeBSD it is a shame that the AMD release is not as super as the other > > versions we have used extensively. > > The problem is a major bug that has existed since FreeBSD ?3.0? was > exposed very close to the 5.3 release cycle. This bug only causes a > major problem with >4GB, thus few of us developers experienced it. > [Most of us can't afford >4GB in our machines. Donations of 1GB DIMMs > for FreeBSD developers are accepted by [EMAIL PROTECTED] [Alan Jay] I'll put them on my present list :) > Of course one reason many are moving to the AMD64 platform is to have > >4GB RAM in the machine. We believe this bug has been fixed in > 5.3-STABLE. But too few people are testing 5.3-STABLE and are using > 5.3-RELEASE instead. This isn't helping us QA the issue so that we know > all the corner cases are fixed in upcoming 5.4 release. [Alan Jay] Well the memory seemed to be stable on 5.3 STABLE with more than 4Gb in our case 8Gb there seems to be some other problem at work here. > A recent 5.3-STABLE snapshot can be found as > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Feb_2005/5.3-STABLE-SNAP001- > amd64-miniinst.iso > and mirrors. > > -- > -- David ([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: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
[ PLEASE don't top post - it losses context, and this is a Unix mailing list] On Tue, Feb 15, 2005 at 04:53:24PM -, Alan Jay wrote: > I had major problems installing with more than 4Gb but once I moved to stable > we seemed to have a stable platform when doing basic stuff - we have two > databases (mySQL) one is reasonably heavily used and one very extensively > used. Just to be clear, you're stating you had stability problems with 5.3-RELEASE and >4GB. But with 5.3-STABLE and >4GB you have a stable system. Correct? > I think I agree wholeheartedly with your comments being a great supporter of > FreeBSD it is a shame that the AMD release is not as super as the other > versions we have used extensively. The problem is a major bug that has existed since FreeBSD ?3.0? was exposed very close to the 5.3 release cycle. This bug only causes a major problem with >4GB, thus few of us developers experienced it. [Most of us can't afford >4GB in our machines. Donations of 1GB DIMMs for FreeBSD developers are accepted by [EMAIL PROTECTED] Of course one reason many are moving to the AMD64 platform is to have >4GB RAM in the machine. We believe this bug has been fixed in 5.3-STABLE. But too few people are testing 5.3-STABLE and are using 5.3-RELEASE instead. This isn't helping us QA the issue so that we know all the corner cases are fixed in upcoming 5.4 release. A recent 5.3-STABLE snapshot can be found as ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Feb_2005/5.3-STABLE-SNAP001-amd64-miniinst.iso and mirrors. -- -- David ([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: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
> > The >4GB problems with 5.3-RELEASE are a well known problem and affect > for i386 and amd64. It's pretty much fixed in the 5.3-STABLE stream, > but there are a few edge cases that I still need to fix which prevent me > from feeling good about turning it into a 5.3-R errata fix. It'll > definitely be fixed and fully working for 5.4-RELEASE next month. > > Scott Scott thanks for that update. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
Alan Jay wrote: Thanks Jonathan for this, can I ask the unmentionalble (which Linux implementation did you pick?). I had major problems installing with more than 4Gb but once I moved to stable we seemed to have a stable platform when doing basic stuff - we have two databases (mySQL) one is reasonably heavily used and one very extensively used. They sit on different servers to maximise performance. One worked perfectly for a couple of weeks while the other more extensive one repeatedly fell over. I think I agree wholeheartedly with your comments being a great supporter of FreeBSD it is a shame that the AMD release is not as super as the other versions we have used extensively. Thanks for your support. Regards ALan The >4GB problems with 5.3-RELEASE are a well known problem and affect for i386 and amd64. It's pretty much fixed in the 5.3-STABLE stream, but there are a few edge cases that I still need to fix which prevent me from feeling good about turning it into a 5.3-R errata fix. It'll definitely be fixed and fully working for 5.4-RELEASE next month. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
Thanks Jonathan for this, can I ask the unmentionalble (which Linux implementation did you pick?). I had major problems installing with more than 4Gb but once I moved to stable we seemed to have a stable platform when doing basic stuff - we have two databases (mySQL) one is reasonably heavily used and one very extensively used. They sit on different servers to maximise performance. One worked perfectly for a couple of weeks while the other more extensive one repeatedly fell over. I think I agree wholeheartedly with your comments being a great supporter of FreeBSD it is a shame that the AMD release is not as super as the other versions we have used extensively. Thanks for your support. Regards ALan > -Original Message- > From: Jonathan A. Dama [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 1:47 AM > To: Doug White > Cc: Alan Jay; freebsd-stable@freebsd.org; [EMAIL PROTECTED] > Subject: Re: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan > Motherboard > > We also have these boards, I've found them unusable under > FreeBSD/5.3-STABLE with 8GB of RAM--other qualities appear to work okay. > But I even saw some infrequent problems with 6GB. > > FreeBSD/amd64 is not in my opinion not actually a stable tier 1 quality > release under these configurations, too many problems remain--especially > in regards to ia32 emulation. > > Exigencies of the moment forced us to forgo further debugging and adopt > linux/amd64. (Sadly, some people actually have to get work done on their > hardware...) > > To anyone who wants to peg these problems on hardware, running linux these > machines have operated without fault while under a mix of high > computational and i/o load. moreover, the machines were tested > extensively using memtest+ in a controlled ambient temperature range from > 60F to 80F. > > This is a really lamentable situation. We've been a primarily FreeBSD > shop for 10 years now and for the past 4 years or so a pure FreeBSD shop. > Switching to linux on just these machines has been quite the headache but > I'm holding on to the hope that FreeBSD/amd64 will shape up. > > FYI, most of the positive reports I've seen regarding FreeBSD and this > motherboard are 2GB setups. In my own testing that arrangement worked > _very_ well. > > Addendum: The RAM timing is a bit marginal on the second processor. i.e., > RAM that runs fine under extensive memtest+ ing has trouble > doing 400MHz DDR on the Second Processor. We ended up running > it at 333MHz DDR > > -Jon > > > > On Mon, 14 Feb 2005, Doug White wrote: > > > On Mon, 14 Feb 2005, Alan Jay wrote: > > > > > I have FreeBSD 5.3 STABLE onto our new twin operteron Tyan Thunder K8S > Pro > > > S2882 with 8Gb of RAM and had a reasonably stable operation for a few > days we > > > installed a couple of databases one worked fine but the other kept on > causing > > > the server to crash. > > > > I'm about to gain access to an S2881, which is a similar board (different > > layout but same parts). > > > > > I have searched the archive and there were issues last year but I > couldn't > > > work out if these have been totally resolved? > > > > > > The adapter does work fine in low levels of loading but when pushed (it > is > > > connected to a Gigabit switch) it seems to be the cause of the reboot - > a what > > > appeared to be stable server with moderate Ethernet activity was fine > upping > > > the activity with a new service caused regular reboots. > > > > > > There is no console message at the point of reboot to help that we have > > > spotted. > > > > > > Hm, triple fault or other hardware reset. This usually indicates bad > > hardware. Have you tried swapping the RAM between the systems and seeing > > if the problem follows? An unrecoverable ECC fault can cause a reboot, > > along with strangeness caused by temperature/power supply/etc. Or the > > board could be Just Plain Bad. > > > > Considering you have one working machine, adn this is a very popular > > board, I don't think it s abasic problem with FreeBSD and this hardware. > > The worst thing reported is interrupt routing usually. > > > > -- > > Doug White| FreeBSD: The Power to Serve > > [EMAIL PROTECTED] | www.FreeBSD.org > > ___ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "[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: Feb 2005 Snapshots for FreeBSD available
Michael Nottebrock wrote: On Tuesday, 15. February 2005 17:41, Michael Nottebrock wrote: On Tuesday, 15. February 2005 17:29, Nate Lawson wrote: Michael Nottebrock wrote: On Tuesday, 15. February 2005 07:28, Nate Lawson wrote: Are there any tags for these? That may be too heavyweight but at least publishing the exact UTC date for the build would be good. That would help us track down in bug reports what code the user has, especially when it's from areas that are under active development. The snapshots on snapshots.[jp|se].freebsd.org are date-suffixed (however, those servers don't build snaps for all platforms). I'm talking hour/min./second, thanks. Well, the builds on jp are always generated from source of 15:00 UTC of that date. The se machine probably uses a fixed time as well, but I can't look it up at the moment (hardware troubles at the se site). And thinking about it, so probably does the snapbuilder which produces those snaps on ftp.freebsd.org ... Scott? :-) Yes, the lack of a published timestamp is an oversight in this experiment. I'm working on correcting it. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feb 2005 Snapshots for FreeBSD available
On Tuesday, 15. February 2005 17:41, Michael Nottebrock wrote: > On Tuesday, 15. February 2005 17:29, Nate Lawson wrote: > > Michael Nottebrock wrote: > > > On Tuesday, 15. February 2005 07:28, Nate Lawson wrote: > > >>Are there any tags for these? That may be too heavyweight but at least > > >>publishing the exact UTC date for the build would be good. That would > > >>help us track down in bug reports what code the user has, especially > > >>when it's from areas that are under active development. > > > > > > The snapshots on snapshots.[jp|se].freebsd.org are date-suffixed > > > (however, those servers don't build snaps for all platforms). > > > > I'm talking hour/min./second, thanks. > > Well, the builds on jp are always generated from source of 15:00 UTC of > that date. The se machine probably uses a fixed time as well, but I can't > look it up at the moment (hardware troubles at the se site). And thinking about it, so probably does the snapbuilder which produces those snaps on ftp.freebsd.org ... Scott? :-) -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpCiMnMUbSE3.pgp Description: PGP signature
RE: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
Thanks for this - the oddity is we have two identical machines and on one the problem occurred we then moved the application over to the other machines that had been working fine and it then exhibited the same symptoms - hence the query about the broadcom controller. I am hoping to so some further tests using the other Ethernet controller on the board if I can get it plugged in (unfortunately the machines are in a data center to which I don't have direct access). Thanks for the ideas. ALan > -Original Message- > From: Doug White [mailto:[EMAIL PROTECTED] > Sent: Monday, February 14, 2005 6:16 PM > To: Alan Jay > Cc: freebsd-stable@freebsd.org > Subject: Re: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan > Motherboard > > On Mon, 14 Feb 2005, Alan Jay wrote: > > > I have FreeBSD 5.3 STABLE onto our new twin operteron Tyan Thunder K8S Pro > > S2882 with 8Gb of RAM and had a reasonably stable operation for a few days > we > > installed a couple of databases one worked fine but the other kept on > causing > > the server to crash. > > I'm about to gain access to an S2881, which is a similar board (different > layout but same parts). > > > I have searched the archive and there were issues last year but I couldn't > > work out if these have been totally resolved? > > > > The adapter does work fine in low levels of loading but when pushed (it is > > connected to a Gigabit switch) it seems to be the cause of the reboot - a > what > > appeared to be stable server with moderate Ethernet activity was fine > upping > > the activity with a new service caused regular reboots. > > > > There is no console message at the point of reboot to help that we have > > spotted. > > > Hm, triple fault or other hardware reset. This usually indicates bad > hardware. Have you tried swapping the RAM between the systems and seeing > if the problem follows? An unrecoverable ECC fault can cause a reboot, > along with strangeness caused by temperature/power supply/etc. Or the > board could be Just Plain Bad. > > Considering you have one working machine, adn this is a very popular > board, I don't think it s abasic problem with FreeBSD and this hardware. > The worst thing reported is interrupt routing usually. > > -- > Doug White| FreeBSD: The Power to Serve > [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feb 2005 Snapshots for FreeBSD available
On Tuesday, 15. February 2005 17:29, Nate Lawson wrote: > Michael Nottebrock wrote: > > On Tuesday, 15. February 2005 07:28, Nate Lawson wrote: > >>Are there any tags for these? That may be too heavyweight but at least > >>publishing the exact UTC date for the build would be good. That would > >>help us track down in bug reports what code the user has, especially > >>when it's from areas that are under active development. > > > > The snapshots on snapshots.[jp|se].freebsd.org are date-suffixed > > (however, those servers don't build snaps for all platforms). > > I'm talking hour/min./second, thanks. Well, the builds on jp are always generated from source of 15:00 UTC of that date. The se machine probably uses a fixed time as well, but I can't look it up at the moment (hardware troubles at the se site). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0KQg38mtlv.pgp Description: PGP signature
Re: Feb 2005 Snapshots for FreeBSD available
Nate Lawson wrote: Michael Nottebrock wrote: On Tuesday, 15. February 2005 07:28, Nate Lawson wrote: Are there any tags for these? That may be too heavyweight but at least publishing the exact UTC date for the build would be good. That would help us track down in bug reports what code the user has, especially when it's from areas that are under active development. The snapshots on snapshots.[jp|se].freebsd.org are date-suffixed (however, those servers don't build snaps for all platforms). I'm talking hour/min./second, thanks. What it sounds like you really want is the CVS revision ID for every file in the snapshot so that when someone reports a bug that you think you might have fixed already, you can just point them to the correct revision. Haven't you learned that vagueness and uncertainty is what makes computers fun?? =-) Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: swapfile being eaten by unknown process
John <[EMAIL PROTECTED]> wrote: > Thanks for your input so far. Here is the output from top: > > last pid: 59737; load averages: 0.02, 0.03, 0.00up 1+18:32:57 > 15:16:36 > 82 processes: 1 running, 79 sleeping, 2 zombie > CPU states: 0.4% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.2% idle > Mem: 105M Active, 31M Inact, 61M Wired, 144K Cache, 33M Buf, 33M Free > Swap: 455M Total, 86M Used, 369M Free, 18% Inuse > > PID USERNAME WRITE FAULT TOTAL PERCENT COMMAND > 177 root 0 0 0 0 0 0 0.00% adjkerntz > 59693 www 0 0 0 0 0 0 0.00% > speedy_back > 59692 www 0 0 0 0 0 0 0.00% > speedy_back > 59663 www 0 0 0 0 0 0 0.00% > speedy_back > 59662 www 0 0 0 0 0 0 0.00% > speedy_back > 59658 www 0 0 0 0 0 0 0.00% > speedy_back > > [...] > > lots of other processes but all with 0s. occasionally I will see numbers > under > VCSW IVCSW READ but they just flash on then its back to 0 again. That looks pretty normal. In fact, it looks perfectly fine. There doesn't seem to be any significant paging activity, but maybe some processes have been swapped to disk (which is normal). Type "vmstat -w 5" and watch the output of the "po" (page out) and "sr" (scan rate) columns for, say, half a minute. If they're near zero most of the time, there is no paging activity, and you need not worry about RAM. Next, I'd suggest you type "ps -waxwum | less". That will dispay a list of processes sorted by memory usage (largest ones at the top). Check the top-10 or so for any processes that might be kill candidates. If in doubt, copy&paste the top-10 into a follow-up in this thread. > I need to > look up what those 2 processes are doing zombified. Zombie processes don't take up any memory (except for the entry in the process table, but that's just a few bytes), so they shouldn't cause any problem. > I think I just need more RAM, but I'd expect there to be none free before it > starts eating swap. Why with free RAM wouldn't my swap also be liberated? You do not need more RAM. At most, a little more swap space wouldn't hurt, but even that isn't strictly necessary, given that only 18% of your swap are in use. I'd start worrying if that number goes beyond 50%. FreeBSD tries to conserve RAM by swapping processes and pages to disk which haven't been used for a certain time. For example, on a system which runs X11, you'll see the text-mode gettys (those running one the syscons virtual consoles) being moved to swap. That's a good thing, because those processes aren't needed normally, so keeping them in RAM would be a waste of memory. If they're used one day, they're paged back into RAM pretty quickly. Also, when RAM begins to get full, FreeBSD starts paging more aggressively. If the situation clears up and RAM gets free again, those pages stay in swap until they're actually used. For those reasons (and others) it is normal that swap space is being used even though there is free RAM available. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feb 2005 Snapshots for FreeBSD available
Michael Nottebrock wrote: On Tuesday, 15. February 2005 07:28, Nate Lawson wrote: Are there any tags for these? That may be too heavyweight but at least publishing the exact UTC date for the build would be good. That would help us track down in bug reports what code the user has, especially when it's from areas that are under active development. The snapshots on snapshots.[jp|se].freebsd.org are date-suffixed (however, those servers don't build snaps for all platforms). I'm talking hour/min./second, thanks. -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: swapfile being eaten by unknown process
On Mon, 14 Feb 2005 22:35:55 -0600, Dan Nelson wrote > In the last episode (Feb 14), Kris Kennaway said: > > On Tue, Feb 15, 2005 at 01:30:42AM +, John wrote: > > > Is there a way of seeing *what* program/process is eating swap. > > > There are loads of ways of seeing that it is being eaten, but so > > > far haven't found a way of knowing what eats, so can't fix the > > > problem. Can anyone enlighten me? > > > > Use ps or top, and look for the process with the huge size. This is > > not foolproof, because a process can allocate memory without using it > > (e.g. rpc.statd), but it's a place to start. If you see a process > > that is both large, and paging to/from disk, that's a better > > indication. > > To see which processes are paging: run top, hit 'm' to switch modes, > and hit 'o' then 'fault' to sort the processes by how many page > faults they are doing. This isn't completely foolproof either, > since reads from mmap()ed files count as faults as well. > Another data point - I see this in my nightly security logs: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 28190, size: 4096 maybe there's a bad block on the swap partition?? -- lists'reiteration.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: swapfile being eaten by unknown process
On Mon, 14 Feb 2005 22:35:55 -0600, Dan Nelson wrote > In the last episode (Feb 14), Kris Kennaway said: > > On Tue, Feb 15, 2005 at 01:30:42AM +, John wrote: > > > Is there a way of seeing *what* program/process is eating swap. > > > There are loads of ways of seeing that it is being eaten, but so > > > far haven't found a way of knowing what eats, so can't fix the > > > problem. Can anyone enlighten me? > > > > Use ps or top, and look for the process with the huge size. This is > > not foolproof, because a process can allocate memory without using it > > (e.g. rpc.statd), but it's a place to start. If you see a process > > that is both large, and paging to/from disk, that's a better > > indication. > > To see which processes are paging: run top, hit 'm' to switch modes, > and hit 'o' then 'fault' to sort the processes by how many page > faults they are doing. This isn't completely foolproof either, > since reads from mmap()ed files count as faults as well. Hi Thanks for your input so far. Here is the output from top: last pid: 59737; load averages: 0.02, 0.03, 0.00up 1+18:32:57 15:16:36 82 processes: 1 running, 79 sleeping, 2 zombie CPU states: 0.4% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.2% idle Mem: 105M Active, 31M Inact, 61M Wired, 144K Cache, 33M Buf, 33M Free Swap: 455M Total, 86M Used, 369M Free, 18% Inuse PID USERNAME WRITE FAULT TOTAL PERCENT COMMAND 177 root 0 0 0 0 0 0 0.00% adjkerntz 59693 www 0 0 0 0 0 0 0.00% speedy_back 59692 www 0 0 0 0 0 0 0.00% speedy_back 59663 www 0 0 0 0 0 0 0.00% speedy_back 59662 www 0 0 0 0 0 0 0.00% speedy_back 59658 www 0 0 0 0 0 0 0.00% speedy_back 59657 www 0 0 0 0 0 0 0.00% speedy_back [...] lots of other processes but all with 0s. occasionally I will see numbers under VCSW IVCSW READ but they just flash on then its back to 0 again. I need to look up what those 2 processes are doing zombified. I think I just need more RAM, but I'd expect there to be none free before it starts eating swap. Why with free RAM wouldn't my swap also be liberated? cheers -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: Fatal trap 12: page fault while in kernel mode
Hello, This is a 5.3-RELEASE-p5/amd64 on IBM X236 (EM64T) with 2GB RAM and a LSI 21320 rmpt(4) running at 160MB/s with a hardware RAID (da0, da1). HTT is enabled. When I run benchmark/blogbench on /da0/ I can *reproduce* this panic again and again: (I'm getting a dump now, let me fsck first) kernel conf & dmesg (boot -v) are at http://rafan.infor.org/tmp/236/ any suggestions are welcome. :) Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 06 fault virtual address = 0x88 fault code = supervisor read, page not present instruction pointer = 0x8:0x80235b0b stack pointer = 0x10:0xb1bd5a50 frame pointer = 0x10:0xb1bd5a70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 96 (pagedaemon) [thread 100114] Stopped at thread_fini+0xab: subl0x88(%ebx),%eax db> trace thread_fini() at thread_fini+0xab zone_drain() at zone_drain+0x22d zone_foreach() at zone_foreach+0x76 uma_reclaim() at uma_reclaim+0x15 vm_pageout_scan() at vm_pageout_scan+0x170 vm_pageout() at vm_pageout+0x38e fork_exit() at fork_exit+0xaa fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xb1bd5d00, rbp = 0 --- db> ps pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 615 ff00603348b8 b43b50000 568 615 000c082 (threaded) blogbench thread 0xff001e7ef000 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881fa40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d19c40][SLP] thread 0xff001c25d520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d37640][SLP] thread 0xff000881fcd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001ffa27b0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff001b755520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a373640][SLP] thread 0xff0070700a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2d8b40][SLP] thread 0xff002c333cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f1c140][SLP] thread 0xff00462e0520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a104e40][SLP] thread 0xff0011002a40 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059594c80][SLP] thread 0xff006310f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a237740][SLP] thread 0xff003c731520 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff00087c1500][SLP] thread 0xff0033c33290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ee8e40][SLP] thread 0xff00635a7290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d86840][SLP] thread 0xff006ff7ccd0 ksegrp 0xff007b1fb4d0 [RUNQ] thread 0xff000881f520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fbb440][SLP] thread 0xff006eff2520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a01640][SLP] thread 0xff004d176520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a069140][SLP] thread 0xff0048ded520 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f9c540][SLP] thread 0xff003689f7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d7c940][SLP] thread 0xff0052446cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99f22d40][SLP] thread 0xff006eff2000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99a6c140][SLP] thread 0xff0054121cd0 ksegrp 0xff007b1fb4d0 [SLPQ ufs 0xff0059112500][SLP] thread 0xff00492bc000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a315440][SLP] thread 0xff003289ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99ff1d40][SLP] thread 0xff0055b3ea40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99fe2140][SLP] thread 0xff0055b3e000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x999d1340][SLP] thread 0xff003689f290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a2bc040][SLP] thread 0xff000881f000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99bc8440][SLP] thread 0xff006ff7c000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c2ed40][SLP] thread 0xff003289b000 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a0c0a40][SLP] thread 0xff003c731a40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99c9ec40][SLP] thread 0xff0009f50cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99b1c240][SLP] thread 0xff000dbd5cd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a1fff40][SLP] thread 0xff003c9bdcd0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99d06440][SLP] thread 0xff003c9bd7b0 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a202c40][SLP] thread 0xff006ac1ba40 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a30c740][SLP] thread 0xff00342f4290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x9a00ee40][SLP] thread 0xff004819d290 ksegrp 0xff007b1fb4d0 [SLPQ biord 0x99dc3440][
Re: Feb 2005 Snapshots for FreeBSD available
On Tuesday, 15. February 2005 07:28, Nate Lawson wrote: > Are there any tags for these? That may be too heavyweight but at least > publishing the exact UTC date for the build would be good. That would > help us track down in bug reports what code the user has, especially > when it's from areas that are under active development. The snapshots on snapshots.[jp|se].freebsd.org are date-suffixed (however, those servers don't build snaps for all platforms). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp1N1UQXgw7r.pgp Description: PGP signature
Re: How to make ipfw consider MAC-IP match?
Artem Kuchin wrote: Hi! I have a table with ethernet (MAC) addresses matching IPs. It is used to build dhcp config file. But regardless of that any user can assign his neighbour ips while that pc is turned off and use it to access internet. The local ips are 192.168. and are behind natd. I am running 5.3-STABLE and have heard that ipfw2 can in someway use MAC addresses, but how do I setup ipfw in such a way that I use Samba computer names for this. If user changes computer name, then he will not be able login to domain, and will not able do his job. I dont restrict very much access to Internet, just do accounting. It is easy modify my setup to use user names instead of computer names. Accounting is done with trafd and 2 or 3 shell scripts. Maybe you need something like this? If you wish, I can post my scripts. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
In article <[EMAIL PROTECTED]> Søren Schmidt <[EMAIL PROTECTED]> writes: > >>>2. A geometry translation for pc98 is NOT enough. > >>> > >>> Currently, it works only under 4.3GB disk. > > Wrong, ATA mk3 does solve the problem but using the "current" geomtry > set in the drives by the BIOS. However the code missed it in one place > in ata-lowlevel.c when the code was moved there from ata-disk.c. > This has been fixed and will be present in the next snapshot as I sadi > earlier. ATA-mkIII does NOT completely solve the problem. The word 54-58 of the IDENTIFY DEVICE parameter are valid only up to ATA/ATAPI-5. They are obsolete parameters in ATA/ATAPI-6 and later. So using them for a geometry translation has NO effect for recent disks. The following is the result when use SATA 200GB disk on pc98. It is clearly that recognizing a geometry fails. atapci0: port 0xc000-0xc00f,0x602c-0x602f,0x6030-0x6037,0x6028-0x602b,0x6020-0x6027 mem 0x20411000-0x204113ff irq 10 at device 17.0 on pci0 ad4: ATA-6 disk at ata2-master ad4: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, SATA150 BIOS Geometries: 1:1778 0..6008=6009 cylinders, 0..255=256 heads, 1..255=255 sectors --- TAKAHASHI Yoshihiro <[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: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
On Mon, Feb 14, 2005 at 05:47:27PM -0800, Jonathan A. Dama wrote: > FreeBSD/amd64 is not in my opinion not actually a stable tier 1 quality > release under these configurations, too many problems remain--especially > in regards to ia32 emulation. It is not required for a Tier-1 platform to have 32-bit support. Our UltraSparc platform does not have 32-bit support. Nor does any other of our 64-bit platforms. > We also have these boards, I've found them unusable under > FreeBSD/5.3-STABLE with 8GB of RAM--other qualities appear to work okay. > But I even saw some infrequent problems with 6GB. This problem is of course valid. > This is a really lamentable situation. We've been a primarily FreeBSD > shop for 10 years now and for the past 4 years or so a pure FreeBSD shop. > Switching to linux on just these machines has been quite the headache but > I'm holding on to the hope that FreeBSD/amd64 will shape up. FreeBSD/amd64 will only get better with your bug reports, testing, and feedback. I searched the GNATS PR database and only saw you've submitted 2 PR's for something we don't claim to really support (32-bit binaries on 64-bit OS). Please submit a PR for the Broadcom and 8GB issues. -- -- David ([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: atapci VIA 82C596B UDMA66 controller: problem for 5.X ?
Rob wrote: In this case there's only one harddisk and when I do # atacontrol mode 0 UDMA66 BIOSPIO I get lots of such lines: ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=20185375 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=20185375 ad0: FAILURE - WRITE_DMA status=51 error=84 LBA=20185375 I am wondering if building a kernel with the various debugging options turned on might help (see the developers handbook). If you can get a dump or trace then there is a good chance that one of the FreeBSD hackers on this list or -bugs can sort it! Transfer rates: outside: 102400 kbytes in 19.370328 sec = 5286 kbytes/sec middle:102400 kbytes in 19.378847 sec = 5284 kbytes/sec inside:102400 kbytes in 19.379687 sec = 5284 kbytes/sec Pretty low transfer rates, clearly not UDMA66! best wishes Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
