Re: Panic with amr and 5.4-PRERELEASE
On Wed, Mar 16, 2005 at 04:46:01PM +0100, Rutger Bevaart wrote: > > can't you get that information by using the combination of compat4x > package, the amrcontrol tool from E Moore? (see > http://people.freebsd.org/~emoore/MegaRAID_SCSI/). i've actually succeeded > in rebuilding a RAID on a Dell PE2850 using the MEGAMGR application which > provides the same GUI as the BIOS interface does. get the asci character > set of your terminal right (search google) and you can manage. > > there seems to be no sourcecode available of the amrcontrol tool that > allows a clean build unfortunately. > This amrcontrol tool was not available at the time I wrote amrstat.c, according to "Release History.txt" (I remember I didn't find anything on www.google.com/bsd). However, we will try it. Thanks for the information. Pierre David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.3 Buildworld Problems on AMD
I just installed a new box last week, and so far the only thing I can think of as being the problem is that this box is an AMD Sempron 2800. I've re-installed this box twice, and I've used different CD's. I cvsup'ed from my own local mirror, and from cvsup2.freebsd.org I installed another P4 box the same day, the same way, and it did a buildworld fine. It always breaks in the same place, AND when I go to manually build libmagic, it builds fine. Advice or fixes? --- error message --- cc -DHAVE_CONFIG_H -DCOMPILE_ONLY -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -o mkmagic /usr/src/lib/libmagic/../../contrib/file/apprentice.c /usr/src/lib/libmagic/../../contrib/file/funcs.c /usr/src/lib/libmagic/../../contrib/file/magic.c /usr/src/lib/libmagic/../../contrib/file/print.c /usr/obj/usr/src/i386/usr/bin/ld: cannot find -lc *** Error code 1 Stop in /usr/src/lib/libmagic. *** Error code 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NDIS problems in 5.4-PREREALEASE
Hi all, I was using NDIS for a (ath0) wifi 3Com OfficeConnect Wireless 108Mbps 11g XJACK PC Card under 5.3-stable I upgraded my src and hove now 5.4-PRERELEASE but now the card is not working well, when I ping to my gateway I get very high response times and I start to loose conection. the card acts like if there where a very poor signal, any idea of what could it be wrong? regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_5 and FAST_IPSEC limits
Hi,
> On Wed, 16 Mar 2005 10:17:14 -0800
> Sam Leffler <[EMAIL PROTECTED]> said:
sam> Note the change lacks any locking so if your SA db is changing there's a
sam> good chance you'll blow up.
Ah, yes. I forgot the fact that FAST_IPSEC is mpsafe.
How about this? This is againt sys/netipsec/key.c with my previous
patch applied.
Index: sys/netipsec/key.c
diff -u -p sys/netipsec/key.c.old sys/netipsec/key.c
--- sys/netipsec/key.c.old Thu Mar 17 03:52:18 2005
+++ sys/netipsec/key.c Thu Mar 17 04:01:50 2005
@@ -2408,6 +2408,7 @@ key_setspddump(errorp)
/* search SPD entry and get buffer size. */
cnt = 0;
+ SPTREE_LOCK();
for (dir = 0; dir < IPSEC_DIR_MAX; dir++) {
LIST_FOREACH(sp, &sptree[dir], chain) {
cnt++;
@@ -2415,6 +2416,7 @@ key_setspddump(errorp)
}
if (cnt == 0) {
+ SPTREE_UNLOCK();
*errorp = ENOENT;
return (NULL);
}
@@ -2426,6 +2428,7 @@ key_setspddump(errorp)
n = key_setdumpsp(sp, SADB_X_SPDDUMP, cnt, 0);
if (!n) {
+ SPTREE_UNLOCK();
*errorp = ENOBUFS;
m_freem(m);
return (NULL);
@@ -2438,6 +2441,7 @@ key_setspddump(errorp)
}
}
}
+ SPTREE_UNLOCK();
*errorp = 0;
return (m);
@@ -6572,6 +6576,7 @@ key_setdump(req_satype, errorp)
/* count sav entries to be sent to the userland. */
cnt = 0;
+ SAHTREE_LOCK();
LIST_FOREACH(sah, &sahtree, chain) {
if (req_satype != SADB_SATYPE_UNSPEC &&
proto != sah->saidx.proto)
@@ -6588,6 +6593,7 @@ key_setdump(req_satype, errorp)
}
if (cnt == 0) {
+ SAHTREE_UNLOCK();
*errorp = ENOENT;
return (NULL);
}
@@ -6601,6 +6607,7 @@ key_setdump(req_satype, errorp)
/* map proto to satype */
if ((satype = key_proto2satype(sah->saidx.proto)) == 0) {
+ SAHTREE_UNLOCK();
m_freem(m);
*errorp = EINVAL;
return (NULL);
@@ -6614,6 +6621,7 @@ key_setdump(req_satype, errorp)
n = key_setdumpsa(sav, SADB_DUMP, satype,
--cnt, 0);
if (!n) {
+ SAHTREE_UNLOCK();
m_freem(m);
*errorp = ENOBUFS;
return (NULL);
@@ -6626,6 +6634,7 @@ key_setdump(req_satype, errorp)
}
}
}
+ SAHTREE_UNLOCK();
if (!m) {
*errorp = EINVAL;
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic with amr and 5.4-PRERELEASE
Philippe PEGON wrote: Hi, I have a FreeBSD bi-processor box with amr device in FreeBSD 5.4-prerelease of this week. # uname -a FreeBSD sokaris2.u-strasbg.fr 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #3: Thu Mar 10 15:33:01 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOKARIS2 i386 Starting a program which continuously polls the state of the raid array (amrstat, see source attached), and making a buildworld at the same time triggers a kernel panic. The problem is fairly easy to reproduce. Features added in the SMP kernel : altq, KDB, DDB, GDB (see config file and dmesg output attached). The kernel is launched with ACPI disabled. A stack trace of the kernel panic and the result of a remote gdb follow. Thank you by advance for your help, Philippe PEGON For information, Scott Long has committed a patch for amr.c in current last sunday which solved this problem. And it's now MFCed in RELENG_5. -- Philippe PEGON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell PowerEdge 1855
On Wed, 16 Mar 2005, Robert Blayzor wrote: > I'd like to know if anyone has experience with the Dell PowerEdge 1855 > blade servers running on either FreeBSD_4 or FreeBSD_5. > > I'm looking to deploy several servers and I know that the 1850's will > run just fine. > > I have concerns over the PERC4/im and the ethernet controllers on the > 1855's. I assume since the 1855's have Intel Gig-E controllers they use > the em driver, which I've had good luck with in the past. Dell generally used Broadcom Ethernet chips, but the support is good for those as well. > Apparently the 1855's integrated RAID uses the LSI (mpt) driver. I've > heard mixed results on this with earlier versions of 4.x and 5.x, but > nothing in the latest releases, 4.10+ and 5.3. > > Can anyone share their experiences with performance and stability on > these machines? I haven't had problems with the mpt-based machine I have, but reportedly the driver doesn't handle certain error conditions. I believe a new driver or fixes are working their way thorugh the legalitites. I had problems with an IBM machine a while back and IM just Not Working, but I haven't tried it recently. -- 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: RELENG_5 and FAST_IPSEC limits
Hajimu UMEMOTO wrote: KAME/NetBSD does it throuth sysctl. Since sysctl API is slightly different between NetBSD and FreeBSD, I didn't merge it, yet. Please try attached patch. This is mainly taken from NetBSD. There is corresponding code in racoon, already. Please make sure to copy sys/netkey/key_var.h into /usr/include/netkey/ before recompiling racoon. Note the change lacks any locking so if your SA db is changing there's a good chance you'll blow up. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/71910 and IPFIREWALL_FORWARD_EXTENDED
Saulius Menkevicius wrote: Hello, I wonder if the config setting IPFIREWALL_FORWARD_EXTENDED was meant to fix kern/71910? Replying to myself. Oh well, it was mentioned in src/UPDATING. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CPUTYPE=pentium-m
On Tue, Mar 15, 2005 at 06:30:33PM -0600, Jon Noack wrote: > Jon Noack wrote: > Is it possible GCC compiled with CPUTYPE?=athlon-xp produces bad code? > I guess my BIOS writer could've been on crack, but the machine is rock > solid without CPUTYPE defined so I don't think it is a hardware > problem. Anything thing is possible, but I've been using CPUTYPE=athlon-mp (which is same as 'athlon-xp') for a LONG time on 4 different machines with no problems. Including one that also is set to use -O2. -- -- 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: NFS failure for bonnie++
> "Dan" == Dan Nelson <[EMAIL PROTECTED]> writes: Dan> In the last episode (Mar 16), David Gilbert said: >> I have two machines running 5.3-PRERELEASE (cvsup'd yesterday). >> They're dual opterons running amd64 code. One of them has 1.0T of >> disk mounted with gmirror, gconcat and ggate... and it exports this >> via nfs. >> >> The other is an nfs client. >> >> When I run bonnie++ -n 200 -s 4000 -u dgilbert on the server, it >> runs fine. When I run the same command on the client, it dies >> trying to delete the files. Dan> bonnie segfaults? No... bonnie++ says: [1:37:[EMAIL PROTECTED]:/usr/ports/benchmarks/bonnie++> bonnie++ -d /d/v0/tmp -s 2500 -n 20 -u dgilbert Using uid:101, gid:20. Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Directory not empty Cleaning up test directory after error. (and the Bonnie. directory still contains files) Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS failure for bonnie++
In the last episode (Mar 16), David Gilbert said: > I have two machines running 5.3-PRERELEASE (cvsup'd yesterday). > They're dual opterons running amd64 code. One of them has 1.0T of > disk mounted with gmirror, gconcat and ggate... and it exports this > via nfs. > > The other is an nfs client. > > When I run bonnie++ -n 200 -s 4000 -u dgilbert on the server, it runs > fine. When I run the same command on the client, it dies trying to > delete the files. bonnie segfaults? -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS failure for bonnie++
I have two machines running 5.3-PRERELEASE (cvsup'd yesterday). They're dual opterons running amd64 code. One of them has 1.0T of disk mounted with gmirror, gconcat and ggate... and it exports this via nfs. The other is an nfs client. When I run bonnie++ -n 200 -s 4000 -u dgilbert on the server, it runs fine. When I run the same command on the client, it dies trying to delete the files. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 3ware 3DM2 for FreeBSD 5 at amd64
Yes, there's 3DM2 for amd64 FreeBSD 5.3 available. Please see attached e-mail. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bill Putney > Sent: Wednesday, March 16, 2005 9:09 AM > To: freebsd-stable@freebsd.org > Subject: 3ware 3DM2 for FreeBSD 5 at amd64 > > > Any progress with a release of 3DM2 that will work under > FreeBSD 5.3 on > AMD64? > > Thanks, Bill > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > From: Vinod Kashyap [EMAIL PROTECTED] Sent: Thursday, February 17, 2005 11:04 AM To: [EMAIL PROTECTED] Subject: CLI and 3DM2 for amd64 CLI and 3DM2, the management tools for 3ware's 7xxx/8xxx and 9xxx controllers are now available for FreeBSD amd64, here: http://www.3ware.com/support/downloadnew.asp Please note that these are not official releases, and have not gone through exhaustive testing. However, they are expected to work satisfactorily. Please report any problems to 3ware support. Thanks, Vinod. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 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: RELENG_5 and FAST_IPSEC limits
Hi,
> On Tue, 15 Mar 2005 13:23:07 -0800
> Sam Leffler <[EMAIL PROTECTED]> said:
> We are running into a case where there are too many SAs, and doing a
> setkey -D would fail with a
>
> "recv: Resource temporarily unavailable"
>
> after displaying most of the associations.
>
> Is there a way to get around this, or is there a hard limit ?
>
> # setkey -D | grep ^172 | wc
> 186 3725096
>
> When the remotes are renegotiating, and there are a lot of tunnels in
> the state of mature and dying, this number can go up to 341, but not
> higher. This also seems to send racoon into a hung state that we then
> need to kill off and restart.
>
> It was suggested in a post that /usr/src/sys/net/raw_cb.h get changed from
>
>
> #define RAWSNDQ 8192
> #define RAWRCVQ 8192
>
> to something larger like
>
> #define RAWSNDQ 24576
> #define RAWRCVQ 24576
>
> If this is the underlying issue, will it work on its own, or are there
> other values that need to be tuned ? Will I need to recompile any
> userland apps (e.g. racoon, setkey) and are there any other values I
> would need to adjust
sam> Looks like you're hitting the limit on returning status information
sam> through a PF_KEY socket. FWIW this is not related to FAST_IPSEC; it's
sam> an issue with PF_KEY and is common to both IPsec implementations.
sam> Upping the raw socket buffer sizes should permit more information to be
sam> returned but you may always exceed this limit as you can create more
sam> SA's than can be reported in a single msg. Some groups have dealt with
sam> this by changing the PF_KEY api, e.g. to report an incomplete msg so the
sam> user-mode app can retrieve more data with additional reads. If upping
sam> the socket buffer limits doesn't help then you might search for patches.
KAME/NetBSD does it throuth sysctl. Since sysctl API is slightly
different between NetBSD and FreeBSD, I didn't merge it, yet.
Please try attached patch. This is mainly taken from NetBSD.
There is corresponding code in racoon, already. Please make sure to
copy sys/netkey/key_var.h into /usr/include/netkey/ before recompiling
racoon.
Sincerely,
Index: sys/netipsec/key.c
diff -u -p sys/netipsec/key.c.orig sys/netipsec/key.c
--- sys/netipsec/key.c.orig Mon Feb 28 05:34:43 2005
+++ sys/netipsec/key.c Thu Mar 17 00:44:24 2005
@@ -392,6 +392,7 @@ static int key_spdflush __P((struct sock
const struct sadb_msghdr *));
static int key_spddump __P((struct socket *, struct mbuf *,
const struct sadb_msghdr *));
+static struct mbuf *key_setspddump __P((int *));
static struct mbuf *key_setdumpsp __P((struct secpolicy *,
u_int8_t, u_int32_t, u_int32_t));
static u_int key_getspreqmsglen __P((struct secpolicy *));
@@ -483,6 +484,7 @@ static int key_flush __P((struct socket
const struct sadb_msghdr *));
static int key_dump __P((struct socket *, struct mbuf *,
const struct sadb_msghdr *));
+static struct mbuf *key_setdump __P((u_int8_t, int *));
static int key_promisc __P((struct socket *, struct mbuf *,
const struct sadb_msghdr *));
static int key_senderror __P((struct socket *, struct mbuf *, int));
@@ -2396,6 +2398,52 @@ key_spddump(so, m, mhp)
}
static struct mbuf *
+key_setspddump(errorp)
+ int *errorp;
+{
+ struct secpolicy *sp;
+ int cnt;
+ u_int dir;
+ struct mbuf *m, *n;
+
+ /* search SPD entry and get buffer size. */
+ cnt = 0;
+ for (dir = 0; dir < IPSEC_DIR_MAX; dir++) {
+ LIST_FOREACH(sp, &sptree[dir], chain) {
+ cnt++;
+ }
+ }
+
+ if (cnt == 0) {
+ *errorp = ENOENT;
+ return (NULL);
+ }
+
+ m = NULL;
+ for (dir = 0; dir < IPSEC_DIR_MAX; dir++) {
+ LIST_FOREACH(sp, &sptree[dir], chain) {
+ --cnt;
+ n = key_setdumpsp(sp, SADB_X_SPDDUMP, cnt, 0);
+
+ if (!n) {
+ *errorp = ENOBUFS;
+ m_freem(m);
+ return (NULL);
+ }
+ if (!m)
+ m = n;
+ else {
+ m->m_pkthdr.len += n->m_pkthdr.len;
+ m_cat(m, n);
+ }
+ }
+ }
+
+ *errorp = 0;
+ return (m);
+}
+
+static struct mbuf *
key_setdumpsp(sp, type, seq, pid)
struct secpolicy *sp;
u_int8_t type;
@@ -6502,6 +6550,98 @@ key_dump(so, m, mhp)
return 0;
}
+static struct mbuf *
+key_setdump(req_satype, errorp)
+ u_int8_t req_satype;
+ int *errorp;
+{
+ struct secashead *sah;
+ struct secasvar *sav;
+ u_int16_t proto;
+ u_int stateidx;
+ u_int8_t satype;
+ u_int8_t state;
+ int cnt;
+ struct mbuf *m, *n;
+
+ /* map satyp
3ware 3DM2 for FreeBSD 5 at amd64
Any progress with a release of 3DM2 that will work under FreeBSD 5.3 on AMD64? Thanks, Bill ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic with amr and 5.4-PRERELEASE
can't you get that information by using the combination of compat4x package, the amrcontrol tool from E Moore? (see http://people.freebsd.org/~emoore/MegaRAID_SCSI/). i've actually succeeded in rebuilding a RAID on a Dell PE2850 using the MEGAMGR application which provides the same GUI as the BIOS interface does. get the asci character set of your terminal right (search google) and you can manage. there seems to be no sourcecode available of the amrcontrol tool that allows a clean build unfortunately. On Tue, Mar 15, 2005 at 11:12:49AM +0100, Constant, Benjamin wrote: > > Fyi, > > The tool is working fine but doesn't show up rebuild state (just removed a > drive and card bios is showing up rebuild on hotspare). > I think it's coming from the driver as it doesn't say that logical device is > in rebuild state. > > [EMAIL PROTECTED]:~: dmesg | grep amrd0 > amrd0: on amr0 > amrd0: 35073MB (71829504 sectors) RAID 1 (degraded) > Mounting root from ufs:/dev/amrd0s1a > > [EMAIL PROTECTED]:~: ./amrstat -l0 > Drive 0:34.25 GB, RAID1 > degraded > You're right. The driver doesn't report the rebuild state. > > By the way, this tool seems promising, thanks for the effort! > Coupled with a simple perl script which periodically calls amrstat on all volumes, it has been proved very useful by the past. However, under heavy I/O load, the amr driver returns meaningful information. This is the reason why amrstat.c make a few attempts. Since this is only to send a mail for an alert, We ignore these "false positive". Pierre David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: save-entropy never exits
Giovanni P. Tirloni wrote: Hi, save-entropy never exists and eats all CPU. # uname -a FreeBSD srv-01 5.3-STABLE-SNAP001 FreeBSD 5.3-STABLE-SNAP001 #0: Sun Jan 30 03:57:47 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 # ps axl |grep entropy 2 14833 14832 0 8 0 1640 928 wait Is??0:00.03 /bin/sh -c /usr/libexec/save-entropy 2 14834 14833 263 128 0 1680 980 - R ?? 1884:17.36 /bin/sh /usr/libexec/save-entropy # uptime 11:56AM up 5 days, 19:14, 1 user, load averages: 1.00, 1.00, 1.00 [...] Sorry about replying to myself. I ran save-entropy by hand and it exits normally. This machine was running 5.2.1-RELEASE and had the same problem. I always had to kill it. I think it must be something related to the hardware but I'm not sure. -- Giovanni ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
save-entropy never exits
Hi, save-entropy never exists and eats all CPU. # uname -a FreeBSD srv-01 5.3-STABLE-SNAP001 FreeBSD 5.3-STABLE-SNAP001 #0: Sun Jan 30 03:57:47 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 # ps axl |grep entropy 2 14833 14832 0 8 0 1640 928 wait Is??0:00.03 /bin/sh -c /usr/libexec/save-entropy 2 14834 14833 263 128 0 1680 980 - R ?? 1884:17.36 /bin/sh /usr/libexec/save-entropy # uptime 11:56AM up 5 days, 19:14, 1 user, load averages: 1.00, 1.00, 1.00 # dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE-SNAP001 #0: Sun Jan 30 03:57:47 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD-K6tm w/ multimedia extensions (300.01-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x570 Stepping = 0 Features=0x8001bf AMD Features=0x400<> real memory = 96403456 (91 MB) avail memory = 84684800 (80 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 $PIR: No matching entry for 0.0.INTA agp0: mem 0xd000-0xd3ff at device 0.0 on pci0 atapci0: port 0x4000-0x400f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 14 at device 0.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xd5901000-0xd5901fff irq 9 at device 1.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib1: at device 2.0 on pci0 pci1: on pcib1 $PIR: ROUTE_INTERRUPT failed. pci1: at device 0.0 (no driver attached) xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd000-0xd07f mem 0xd590-0xd590007f irq 10 at device 10.0 on pci0 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:04:d9:a8:78 rl0: port 0xd400-0xd4ff mem 0xd5902000-0xd59020ff irq 12 at device 11.0 on pci0 miibus1: on rl0 rlphy0: on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:e0:7d:8c:32:47 xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xd800-0xd87f mem 0xd5903000-0xd590307f irq 5 at device 12.0 on pci0 miibus2: on xl1 xlphy1: <3Com internal media interface> on miibus2 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:10:5a:9f:df:89 pci0: at device 13.0 (no driver attached) cpu0 on motherboard orm0: at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 300012360 Hz quality 800 Timecounters tick every 10.000 msec ad0: 1222MB [2484/16/63] at ata0-master WDMA2 Mounting root from ufs:/dev/ad0s1a Does anyone have any idea about why it never exists and stays there eating all CPU ? -- Giovanni ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kern/71910 and IPFIREWALL_FORWARD_EXTENDED
Hello,
I wonder if the config setting IPFIREWALL_FORWARD_EXTENDED was meant to
fix kern/71910?
It adds #ifdef's around the following code in ip_output.c:
-8<-
/* Or forward to some other address? */
fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL);
if (fwd_tag) {
#ifndef IPFIREWALL_FORWARD_EXTENDED
if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) {
#endif
dst = (struct sockaddr_in *)&ro->ro_dst;
bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in));
m->m_flags |= M_SKIP_FIREWALL;
m_tag_delete(m, fwd_tag);
goto again;
#ifndef IPFIREWALL_FORWARD_EXTENDED
} else {
m_tag_delete(m, fwd_tag);
/* Continue. */
}
#endif
}
-8<-
Where the workaround for kern/71910 (at least it works for me) was:
-8<-
Index: ip_output.c
===
RCS file: /FreeBSD-CVS/src/sys/netinet/ip_output.c,v
retrieving revision 1.225.2.3
diff -u -b -r1.225.2.3 ip_output.c
--- ip_output.c 15 Sep 2004 15:07:09 - 1.225.2.3
+++ ip_output.c 19 Sep 2004 15:51:42 -
@@ -713,7 +713,7 @@
/* Or forward to some other address? */
fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL);
if (fwd_tag) {
- if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) {
+ if (!in_localaddr(ip->ip_dst)) {
dst = (struct sockaddr_in *)&ro->ro_dst;
bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in));
m->m_flags |= M_SKIP_FIREWALL;
-8<-
Thanks,
Respectfully,
Saulius Menkevicius
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Dell PowerEdge 1855
I'd like to know if anyone has experience with the Dell PowerEdge 1855 blade servers running on either FreeBSD_4 or FreeBSD_5. I'm looking to deploy several servers and I know that the 1850's will run just fine. I have concerns over the PERC4/im and the ethernet controllers on the 1855's. I assume since the 1855's have Intel Gig-E controllers they use the em driver, which I've had good luck with in the past. Apparently the 1855's integrated RAID uses the LSI (mpt) driver. I've heard mixed results on this with earlier versions of 4.x and 5.x, but nothing in the latest releases, 4.10+ and 5.3. Can anyone share their experiences with performance and stability on these machines? TIA -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 If at first you don't succeed, call it version 1.0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
