Re: Loosing spam fight
For purposes of making the subject less true, setting up greylisting with an optional tarpit for known baddies can be very effective. See Dan Langille's recent Onlamp article[1] or for that matter my tutorial[2] for how this is done using PF and spamd - this way it doesn't matter much which MTA(s) you use. [1] http://www.onlamp.com/pub/a/bsd/2007/01/18/greylisting-with-pf.html [2] http://home.nuug.no/~peter/pf/en/, with the specifics of spamd and greylisting starting at http://home.nuug.no/~peter/pf/en/spamd.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 'make depend' fails with 'device viapm'
Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > You're missing the iicbus, iicbb, and iicsmb drivers. Yeah, of course, thank you. Sorry. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 'make depend' fails with 'device viapm'
On Thu, Jan 25, 2007 at 05:08:55AM +0500, [EMAIL PROTECTED] wrote: > I've just updated the sources and tried to rebuild kernel with 'device viapm' > in kernel configuration file. 'make depend' fails: You're missing the iicbus, iicbb, and iicsmb drivers. Taken from my kernel config: ## Power management controllers / hardware monitoring ## device smbus ## SMBus support device viapm ## VIA PM -- for hardware monitoring device smb ## SMBus support device iicbus ## I2C bus support (needed for I2C) device iicbb ## I2C bit-banging driver device iicsmb ## SMBus over I2C bridge -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
'make depend' fails with 'device viapm'
I've just updated the sources and tried to rebuild kernel with 'device viapm' in kernel configuration file. 'make depend' fails: <..> awk -f ../../../tools/makeobjops.awk ../../../kern/device_if.m -h awk -f ../../../tools/makeobjops.awk ../../../kern/linker_if.m -h awk -f ../../../tools/makeobjops.awk ../../../dev/acpica/acpi_if.m -h rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=c3 -Wall -Wredundant- decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../ .. -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I. ./../../dev/ath -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KER NEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-stri ngs -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffrees tanding ../../../pci/viapm.c:55:22: iicbb_if.h: No such file or directory mkdep: compile failed *** Error code 1 My kernel configuration file: machine i386 cpu I686_CPU device isa device pci device agp device npx device io ident LOCALHOST options SCHED_4BSD options COMPAT_43 options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options SYSVSHM options SYSVMSG options SYSVSEM options INET device loop device bpf device ether device ppp options IPFIREWALL options FFS options PROCFS options PSEUDOFS options SOFTUPDATES options UFS_DIRHASH device random device mem device scbus device da device cd device pass device pty device atkbdc device atkbd device psm device vga device sc device ata device atadisk device atapicd options ATA_STATIC_ID device fdc device sio device miibus device vr device sound device snd_via8233 device smbus device smb device viapm device uhci device ehci device usb device ugen device ulpt device umass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lenovo X60 em workaround
On 1/24/07, Gavin Atkinson <[EMAIL PROTECTED]> wrote:
On Mon, 2007-01-22 at 10:30 -0800, Jack Vogel wrote:
> On 1/22/07, Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
> > Jack,
> >
> > On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote:
> > J> >> Since this was just seen, and the patch below validated as working I
> > J> >wanted
> > J> >> to send general email to capture this:
> > J> >>
> > J> >> The Lenovo X60 can have issues with long ping times, this is a KNOWN
> > J> >> hardware problem, and Intel is working with IBM/Lenovo, a final 'fix'
has
> > J> >> not been decided on yet. Nevertheless, the patch below will work, but
> > J> >> I do not want to check it in as its still temporary.
> > J> >>
> > J> >> Address questions to me,
> > J> >
> > J> >Okay, I have a question. Could you elaborate on just what the problem
is?
> > J> >(I mean, since it's KNOWN and all...) I'm just having a hard time
figuring
> > J> >out what problem could possibly be fixed by setting the RX interrupt
> > J> >delay timer to a non-zero value (especially since elsewhere in the em(4)
> > J> >source it says that doing so is a Bad Thing (tm)).
> > J>
> > J> saying its known to be a problem doesnt mean its cause is known :)
> > J> They discovered that setting this eliminated the problem, but we
> > J> immediately pointed out that this is, as you pointed out, a Bad
> > J> Thing on other hardware, so the investigation continues, there is
> > J> always a communication lag on these kind of things, so I dont know
> > J> if it has been resolved yet or not.
> > J>
> > J> I just dont think this patch will become the final way to solve this,
> > J> but we shall see :)
> >
> > Good to know that there is progress on this. Thanks! I will try the patch
> > on my Lenovo T60 notebook, where the problem is also present. AFAIK, it
> > is present on any Lenovo notebook with 82573 NIC.
> >
> > Can you please acknowledge that another bug with Lenovo + em(4) is known? I
> > mean the problem, that em(4) isn't initialized properly on kernel boot, if
> > the link is down. I have already reported this to you, and you said that
> > I probably have bad hardware. Since that time, I've found several similar
> > reports about Lenovo notebooks and em(4) driver in FreeBSD.
>
> Hey Gleb,
>
> Acknowledge... I can do better than that, I have a fix for this problem, and
> its not temporary. Here is the code change (not a patch, I'm very busy),
> its in hardware_init, should be obvious how to patch:
>
>/* Make sure we have a good EEPROM before we read from it */
> if (e1000_validate_nvm_checksum(&adapter->hw) < 0) {
> /*
> ** Some PCI-E parts fail the first check due to
> ** the link being in sleep state, call it again,
> ** if it fails a second time its a real issue.
> */
> if (e1000_validate_nvm_checksum(&adapter->hw) < 0) {
> device_printf(dev,
> "The EEPROM Checksum Is Not Valid\n");
> return (EIO);
> }
> }
>
> This is already checked into my code base at Intel, I've just been too
> busy to do anything with it, be my guest if you wish to check it in after
> testing...
Just to add another datapoint - and for the archives - this also appears
to fix an issue with the Toshiba Tecra M5L. The "EEPROM Checksum Is Not
Valid" message would appear on boot if there was no link on the
interface, although the interface would appear to work fine from then
on. With this patch, the message no longer appears.
I also have problems with connections to networks (only seen when
connected to 10 meg half duplex hubs) with long delays on some packets
(which I'm assuming is the issue that started this thread) - I haven't
been able to verify yet that either patch fixes that, though.
Nice to know its fixing more than expected.
Let me know about the last issue when you verify it.
Crises have me consumed at work right now, will try to get time to
commit by this weekend.
Jack
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
On Wed, 24 Jan 2007 22:51:07 +0100 Torfinn Ingolfsen <[EMAIL PROTECTED]> wrote: > On Wed, 24 Jan 2007 13:11:16 -0600 > ejc <[EMAIL PROTECTED]> wrote: > > rtld.c has changed a bit over time so here's a patch against the new > > file. > BTW, what is the reason this "hack" isn't included in the base kernel / > code? I suggested new patch. But no response:-(. SEE ALSO: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-January/019360.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
On Wednesday 24 January 2007 19:10, Alexandre Vasconcelos wrote: > Hello, > > Working setup: > - FreeBSD 6.2-PRERELEASE, firefox 2 and flash 7 patched with > rtld_dlsym_hack.diff, like suggested on Handbook. > > After 6.2-STABLE upgrade reaplying the rtld_dlsym_hack.diff fails: > > [EMAIL PROTECTED] src]# patch < rtld_dlsym_hack.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > > |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 > |+++ libexec/rtld-elf/rtld.cSun Oct 17 03:37:44 2004 > > -- > Patching file libexec/rtld-elf/rtld.c using Plan A... > Hunk #1 failed at 129. > Hunk #2 succeeded at 187 (offset 9 lines). > Hunk #3 succeeded at 1820 (offset 82 lines). > 1 out of 3 hunks failed--saving rejects to libexec/rtld-elf/rtld.c.rej > done > > And make fails: > > [EMAIL PROTECTED] rtld-elf]# make > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/i386/rtld_start.S > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/i386/reloc.c > cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD > -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic > -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c > /usr/src/libexec/rtld-elf/rtld.c > /usr/src/libexec/rtld-elf/rtld.c:189: error: `_dlsym' undeclared here > (not in a function) > /usr/src/libexec/rtld-elf/rtld.c:189: error: initializer element is not > constant > /usr/src/libexec/rtld-elf/rtld.c:189: error: (near initialization for > `exports[4]') > *** Error code 1 > > Stop in /usr/src/libexec/rtld-elf. > > > How to fix this? > Thanks, > Alex > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" Hello I had the same problem, I've patched the library myself but I don't know how to make a proper "patch file" so if you want, here's my patched one : http://fkraiem.free.fr/rtld.c Copy into /usr/src/libexec/rtld-elf and follow the instructions given in the handbook. -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
On Wed, 24 Jan 2007 13:11:16 -0600 ejc <[EMAIL PROTECTED]> wrote: > rtld.c has changed a bit over time so here's a patch against the new > file. BTW, what is the reason this "hack" isn't included in the base kernel / code? -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: System hang on laptop suspend/resume
On Wed, 24 Jan 2007 09:26:54 -0800 (PST) Stephen Casner <[EMAIL PROTECTED]> wrote: > Do you know, though, whether there is any way in NEWCARD to power down > the PC Card / Cardbus slot? I didn't see anything in the 6.2 release > note regarding changes in that area. Hmm, doesn't 'pccardc power ...' already do that? See 'man pccardc' for more info. HTH -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
Tobias Roth wrote: For your convenience: http://fsck.ch/rtld_dlsym_hack_new.diff or the attached file (if it makes it through). Thank you guys, for all responses. Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
On Wed, 24 Jan 2007 12:36:06 -0600
"Scot Hetzel" <[EMAIL PROTECTED]> wrote:
> On 1/24/07, Alexandre Vasconcelos
> <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] src]# patch < rtld_dlsym_hack.diff
> > Hmm... Looks like a unified diff to me...
> > The text leading up to this was:
> > --
> > |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004
> > |+++ libexec/rtld-elf/rtld.cSun Oct 17 03:37:44 2004
> > --
> > Patching file libexec/rtld-elf/rtld.c using Plan A...
> > Hunk #1 failed at 129.
> > Hunk #2 succeeded at 187 (offset 9 lines).
> > Hunk #3 succeeded at 1820 (offset 82 lines).
> > 1 out of 3 hunks failed--saving rejects to
> > libexec/rtld-elf/rtld.c.rej done
> >
> > And make fails:
> >
> :
> > How to fix this?
>
> Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to
> libexec/rtld-elf/rtld.c.
For your convenience: http://fsck.ch/rtld_dlsym_hack_new.diff
or the attached file (if it makes it through).
cheers,
Tobias
--- libexec/rtld-elf/rtld.c.orig Tue Jan 16 08:51:04 2007
+++ libexec/rtld-elf/rtld.c Wed Jan 24 19:43:57 2007
@@ -129,6 +129,7 @@
static void unlink_object(Obj_Entry *);
static void unload_object(Obj_Entry *);
static void unref_dag(Obj_Entry *);
+void *_dlsym(void *, const char *);
static void ref_dag(Obj_Entry *);
void r_debug_state(struct r_debug *, struct link_map *);
@@ -182,6 +183,7 @@
(func_ptr_type) &dlclose,
(func_ptr_type) &dlerror,
(func_ptr_type) &dlopen,
+(func_ptr_type) &_dlsym,
(func_ptr_type) &dlsym,
(func_ptr_type) &dladdr,
(func_ptr_type) &dllockinit,
@@ -1762,6 +1764,12 @@
trace_loaded_objects(obj);
wlock_release(rtld_bind_lock, lockstate);
exit(0);
+}
+
+void *
+_dlsym(void *handle, const char *name)
+{
+return dlsym(handle, name);
}
void *
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
On 1/24/07, Alexandre Vasconcelos
<[EMAIL PROTECTED]> wrote:
Scot Hetzel wrote:
> Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to
> libexec/rtld-elf/rtld.c.
Thanks for answering Scot, and sorry for ignorance.. how can I do it?
rtld.c has changed a bit over time so here's a patch against the new file.
Begin Patch
--- libexec/rtld-elf/rtld.c.origWed Jan 24 13:03:46 2007
+++ libexec/rtld-elf/rtld.c Wed Jan 24 13:04:43 2007
@@ -134,6 +134,7 @@
static void ref_dag(Obj_Entry *);
static void ld_utrace_log(int, void *, void *, size_t, int, const char *);
+void *_dlsym(void *, const char *);
void r_debug_state(struct r_debug *, struct link_map *);
/*
@@ -186,6 +187,7 @@
(func_ptr_type) &dlclose,
(func_ptr_type) &dlerror,
(func_ptr_type) &dlopen,
+(func_ptr_type) &_dlsym,
(func_ptr_type) &dlsym,
(func_ptr_type) &dladdr,
(func_ptr_type) &dllockinit,
@@ -1827,6 +1829,12 @@
trace_loaded_objects(obj);
wlock_release(rtld_bind_lock, lockstate);
exit(0);
+}
+
+void *
+_dlsym(void *handle, const char *name)
+{
+return dlsym(handle, name);
}
void *
End Patch
--
Eric
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
On 1/24/07, Alexandre Vasconcelos <[EMAIL PROTECTED]> wrote: Scot Hetzel wrote: > Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to > libexec/rtld-elf/rtld.c. Thanks for answering Scot, and sorry for ignorance.. how can I do it? Open /usr/src/libexec/rtld-elf/rtld.c.rej in one window, and /usr/src/libexec/rtld-elf/rtld.c in another window. Goto line 129 in /usr/src/libexec/rtld-elf/rtld.c and add the missing _dlsym information from the *.rej file. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp: unknown hardware address format
On Jan 24, 2007, at 4:32 AM, Ilia Gorstkin wrote: I'm having trouble with arp: arp: unknown hardware address format (0x4500) and arp: unknown hardware address format (0x4242) these messages fall on the console in a plenty. I do tcpdump -exn "arp[0]=0x45 and arp[1]=0": tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 68 bytes Please run "tcpdump -exxn -s 0 arp" to show the full packets including link-layer headers. You should be seeing a byte sequence more like: 0001 0800 0604 0001 ...followed by the sender's MAC address. This is from /usr/include/net/if_arp.h and means: ARPHRD_ETHER, ETHERTYPE_IP, hln=6, pln=4, ARPOP_REQUEST I don't know what 0x4500 means, but 0x4242 is: #define ETHERTYPE_PCS 0x4242 /* PCS Basic Block Protocol */ It seems more likely that you've got a hardware problem like a wacked out NIC or switch, or some really odd software bug... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
Scot Hetzel wrote: Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to libexec/rtld-elf/rtld.c. Thanks for answering Scot, and sorry for ignorance.. how can I do it? Thanks again, Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.2-STABLE and Flash 7 patch
On 1/24/07, Alexandre Vasconcelos <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] src]# patch < rtld_dlsym_hack.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 |+++ libexec/rtld-elf/rtld.cSun Oct 17 03:37:44 2004 -- Patching file libexec/rtld-elf/rtld.c using Plan A... Hunk #1 failed at 129. Hunk #2 succeeded at 187 (offset 9 lines). Hunk #3 succeeded at 1820 (offset 82 lines). 1 out of 3 hunks failed--saving rejects to libexec/rtld-elf/rtld.c.rej done And make fails: : How to fix this? Apply the missing patch hunk (vi libexec/rtld-elf/rtld.c.rej) to libexec/rtld-elf/rtld.c. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.2-STABLE and Flash 7 patch
Hello, Working setup: - FreeBSD 6.2-PRERELEASE, firefox 2 and flash 7 patched with rtld_dlsym_hack.diff, like suggested on Handbook. After 6.2-STABLE upgrade reaplying the rtld_dlsym_hack.diff fails: [EMAIL PROTECTED] src]# patch < rtld_dlsym_hack.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 |+++ libexec/rtld-elf/rtld.cSun Oct 17 03:37:44 2004 -- Patching file libexec/rtld-elf/rtld.c using Plan A... Hunk #1 failed at 129. Hunk #2 succeeded at 187 (offset 9 lines). Hunk #3 succeeded at 1820 (offset 82 lines). 1 out of 3 hunks failed--saving rejects to libexec/rtld-elf/rtld.c.rej done And make fails: [EMAIL PROTECTED] rtld-elf]# make cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/rtld_start.S cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/reloc.c cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/rtld.c /usr/src/libexec/rtld-elf/rtld.c:189: error: `_dlsym' undeclared here (not in a function) /usr/src/libexec/rtld-elf/rtld.c:189: error: initializer element is not constant /usr/src/libexec/rtld-elf/rtld.c:189: error: (near initialization for `exports[4]') *** Error code 1 Stop in /usr/src/libexec/rtld-elf. How to fix this? Thanks, Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Loosing spam fight
On 1/24/07, Gustavo Feijó <[EMAIL PROTECTED]> wrote:
Hi there,
I know it's not the right list to write to, but I'll still try a shot.
There is freebsd-isp@, as well :)
I'm running sendmail in my FreeBSD box and wish to block mails comming
from domains with no ptr configs.
Am I missing something?
My sendmail-rx.mc is like this
FEATURE(`access_db',`hash -T -o /etc/mail/access.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`ALIAS_FILE', `/etc/mail/aliases')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
FEATURE(`use_cw_file')dnl
FEATURE(`use_ct_file')dnl
FEATURE(`use_client_ptr')dnl
FEATURE(`delay_checks')dnl
dnl #
dnl # configuracoes de lista de spammers
dnl #
FEATURE(`dnsbl', `dul.dnsbl.sorbs.net', `"550 Mail from "
$`'&{client_addr} " refused - see http://www.dul.dnsbl.sorbs.net/";')
FEATURE(`dnsbl', `sbl.spamhaus.org', `"550 Mail from "
$`'&{client_addr} " refused - see http://www.spamhaus.org/sbl/";')
FEATURE(`dnsbl', `list.dsbl.org', `"550 Mail from " $`'&{client_addr}
" refused - see http://dsbl.org/";')
FEATURE(`dnsbl', `bl.spamcop.net', `"450 Mail from " $`'&{client_addr}
" refused - see http://spamcop.net/bl.shtml";')
dnl #
--
[]'s
chmod000
"Microsoft butterfly is their way of telling you their system has a
lot of @#$ bugs!"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Loosing spam fight
On Wed, 24 Jan 2007 15:03:06 -0200 "Gustavo Feijó" <[EMAIL PROTECTED]> wrote: > FEATURE(`dnsbl', `sbl.spamhaus.org', `"550 Mail from " Try replacing with 'zen.spamhaus.org'. Can't comment on the others. Are you only using RBLs for spam prevention? HTH, Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Loosing spam fight
Hi there,
I know it's not the right list to write to, but I'll still try a shot.
I'm running sendmail in my FreeBSD box and wish to block mails comming
from domains with no ptr configs.
Am I missing something?
My sendmail-rx.mc is like this
FEATURE(`access_db',`hash -T -o /etc/mail/access.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`ALIAS_FILE', `/etc/mail/aliases')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
FEATURE(`use_cw_file')dnl
FEATURE(`use_ct_file')dnl
FEATURE(`use_client_ptr')dnl
FEATURE(`delay_checks')dnl
dnl #
dnl # configuracoes de lista de spammers
dnl #
FEATURE(`dnsbl', `dul.dnsbl.sorbs.net', `"550 Mail from "
$`'&{client_addr} " refused - see http://www.dul.dnsbl.sorbs.net/";')
FEATURE(`dnsbl', `sbl.spamhaus.org', `"550 Mail from "
$`'&{client_addr} " refused - see http://www.spamhaus.org/sbl/";')
FEATURE(`dnsbl', `list.dsbl.org', `"550 Mail from " $`'&{client_addr}
" refused - see http://dsbl.org/";')
FEATURE(`dnsbl', `bl.spamcop.net', `"450 Mail from " $`'&{client_addr}
" refused - see http://spamcop.net/bl.shtml";')
dnl #
--
[]'s
chmod000
"Microsoft butterfly is their way of telling you their system has a
lot of @#$ bugs!"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: System hang on laptop suspend/resume
On Tue, 23 Jan 2007, Doug Barton wrote: My guess as to why you're not getting a response is that suspend/resume issues currently have no champion amongst FreeBSD developers, and therefore they are simply not being addressed. This is disappointing, but part of life in a volunteer project. Understood. Thanks for your reply. The first and only suggestion I have is to upgrade to 6.2 now that it's out, but that's just to make doubly sure your issue hasn't been solved (which is likely). Beyond that, carefully combing the archives of the -mobile, -stable, and -current lists for similar issues might lead to some things for you to try. I will do that. As I mentioned to another off-list responder, I have to admit that I hadn't noticed that 6.2 had been released. It seemed to be permanently stuck in beta. Indeed, the disk timeout seems like a bug that might have been fixed. Do you know, though, whether there is any way in NEWCARD to power down the PC Card / Cardbus slot? I didn't see anything in the 6.2 release note regarding changes in that area. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
arp: unknown hardware address format
Hi all! FreeBSD 6.2-release. I'm having trouble with arp: arp: unknown hardware address format (0x4500) and arp: unknown hardware address format (0x4242) these messages fall on the console in a plenty. I do tcpdump -exn "arp[0]=0x45 and arp[1]=0": tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 68 bytes 15:12:23.308179 00:02:55:53:46:13 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: truncated-arp 0x: 4500 0020 9f4e 4000 3f2f bfa1 c0a8 fc6b [EMAIL PROTECTED]/.k 0x0010: c0a8 5f02 2081 880b 8000 0023 .._# 0x0020: 2020 2020 .. 0x: 4500 0020 9f4e 4000 3f2f bfa1 c0a8 fc6b 0x0010: c0a8 5f02 2081 880b 8000 0023 0x0020: 2020 2020 15:12:23.428057 00:02:55:53:46:13 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: truncated-arp 0x: 4500 0020 9f4f 4000 3f2f bfa0 c0a8 fc6b [EMAIL PROTECTED]/.k 0x0010: c0a8 5f02 2081 880b 8000 0025 .._% 0x0020: 2020 2020 .. 0x: 4500 0020 9f4f 4000 3f2f bfa0 c0a8 fc6b 0x0010: c0a8 5f02 2081 880b 8000 0025 0x0020: 2020 2020 In the arp-table of my network there is not MAC-address 00:02:55:53:46:13. Where is it address from? How does it influence on safety? How to solve this problem? Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPSEC clarifications
Hi folks, I'm wondering if someone please could clarify some IPSec specific questions to me? IPSEC_FILTERGIF: What are the consequences when enabling this if one does use IPSEC (or FAST_IPSEC) w/o any GIF tunnels? Are there any or does IPSEC_FILTERGIF only influence packet flow with gif devices? NOTES says: # Set IPSEC_FILTERGIF to force packets coming through a gif tunnel # to be processed by any configured packet filtering (ipfw, ipf). # The default is that packets coming from a tunnel are _not_ processed; # they are assumed trusted. But I've found signs in the archives even while not using gif tunnels with IPSec packets are getting filtered with FILTERGIF option. I might be wrong about this. device enc: I haven't been aware of the fact that we already have such a device. There's a man page (man 4 enc) but it's not in NOTES or GENERIC. Is the enc(4) man page correct and up to date? Shouldn't there at least be a note in NOTES somewhere around the options FAST_IPSEC line with a hint for enc(4)? Is just compiling device enc into the kernel, using options FAST_IPSEC and passing (or blocking) traffic on interface enc0 using pf rules all one has to do? IPSEC / FAST_IPSEC: What is the (say) 'official' recommended option to use? Where are the differences, what are the consequences while using one or the other? Will both do the same w/o any consequences for the admin? I'm currently in the process of checking for migration to racoon2 and need to re-check every IPSec related setup. Thanks, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Firefox keeps beeping at me ...
Per olof Ljungmark skrev: Glenn Becker wrote: All - I've been away from FreeBSD for some time and have been updating my installation, getting used to the ways of portupgrade, etc. Have noticed that Firefox keeps emitting what sound like console beeps - I haven't established much of a pattern for these though it always happens when I close the app. Is there a way to kill these? Apologies in advance if this is a dopey question. Obviously more an annoyance than anything. perhaps -questions is more appropriate... Anyway, that makes two of us - mine beeps too - when sending and reading mails. No idea why though, sorry. Anyone? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" The beeping can be avoided by recompiling without the debug option. (I am clueless on how to disable it if debug is on though). Sorry for the crosspost-reply. /Nikolaj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-stable Digest, Vol 190, Issue 5
please unsubscribe On Wednesday 24 January 2007 13:00, [EMAIL PROTECTED] wrote: > org/mailman -- Met vriendelijke groet, Pieter Migo ___ MMB Holding MMB : +31 40 2333 5 25 ChartNet : +31 40 2333 5 33 Fibbs : +31 40 2333 5 32 TA.nl : +31 40 2333 5 31 Fax : +31 40 2811 7 94 Keizersgracht 16c 5611 GD Eindhoven Nederland MMB.nl ChartNet.nl TA.nl FiBBS.nl ___ DISCLAIMER: Aan dit bericht kunnen geen rechten worden ontleend. Dit bericht is uitsluitend bestemd voor de geadresseerde. Als u dit bericht per abuis hebt ontvangen, wordt u verzocht het te vernietigen en de afzender te informeren. Wij adviseren u om bij twijfel over de juistheid of de volledigheid van de e-mail contact met de afzender op te nemen. Nothing in this email shall bind the sender in any contract or obligation. This e-mail is for the intended addressee only. If you have received it in error then please delete it and notify the sender by return e-mail. In case of doubt about correctness or completeness of this e-mail please contact the sender. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-stable Digest, Vol 190, Issue 5
In response to Pieter Migo <[EMAIL PROTECTED]>: > please unsubscribe > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Bill Moran Collaborative Fusion Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver
Jeff Royle wrote: LI Xin wrote: Jeff Royle wrote: Jeff Royle wrote: I could use some advice on this issue I have had with my raid controller. I am not really running much on the system yet, postfix, Pf + pflogd, rlogind, ssh, bsnmp and ntpd. While I was just reading a file with less the system stopped responding. I thought it was the network interfaces but I was able to ping the interface. Once I plugged a monitor into the system I saw this (roughly): AAC0: COMMAND TIMEOUT AFTER X number of seconds Not good :) Reset of the system resolved the issue and it booted fine.Since the controller stopped responding nothing was recorded to my logs. Now I have to figure out how to prevent that from happening again. Basic run down on the system and some history... P4 3.2Ghz Asus P5MT-S MB 2 x 1GB DDR2 667 memory Adaptec 2130SLP Raid Controller + battery backup module 2 Segate Ultra320 73GB 15k RPM (mirrored) I have run this same system hardware testing 6.2-BETA3, RC-1 and RC-2 without this issue.I was using the driver released by Adaptec while testing the pre-release installs (http://www.adaptec.com/en-US/speed/raid/aac/unix/aacraid_freebsd6_drv_b11518_tgz.htm). You could say I am fairly confidient in the hardware itself. I have put this system through a lot of testing since BETA3. The 6.2 release kernel has not been customized all that much, I just pulled out all the drivers I would never use.To be safe I kept just about all scsi devices/card models still in as I continued my testing of 6.2 release. Right now I am going to try taking out aac and aacp then try the driver I used in my previous tests.However, since I have run a week without this issue it will be hard/impossible tell if this did anything to resolve it...I almost want a crash on the old driver :) So I need some advice... How best do I debug this issue? Thanks in advance for any direction you guys can offer me. Cheers, Jeff It appears the driver I was using in my pre-release testing is newer then the release driver. Stock driver in 6.2r dmesg: aac0: mem 0xfc60-0xfc7f,0xfc5ff000-0xfc5f irq 24 at device 1.0 on pci2 aac0: New comm. interface enabled aac0: Adaptec Raid Controller 2.0.0-1 aacp0: on aac0 Currently using: aacu0: mem 0xfc60-0xfc7f,0xfc5ff000-0xfc5f irq 24 at device 1.0 on pci2 aacu0: New comm. interface enabled aacu0: Adaptec Raid Controller 2.0.7-1 aacpu0: on aacu0 Going to continue testing with the newer driver. I have some preliminary work on merging the Adaptec driver: http://people.freebsd.org/~delphij/for_review/patch-aac-vendor-b11518 But one of the reviewers has advised me to request boarder testing, especially against old cards and CLI tools, so I have hold the commit for now. Cheers, Well the driver patched fine, no issues to report there. The speed performance is where I expected to see it while using bonnie and simple DD tests based on my previous testing. So far the issue I noted above with the TIMEOUT error has not shown itself again, time will tell I think on this one. However I have encountered a intermittent bug on boot. Sometimes, say every 5-10 boots the system will hang while probing the the scsi bus for the drives. Now I have seen this happen on the aacdu 2.0.7-1 binary driver I was using in my 6.2-RC 1 / 6.2-RC 2 testing once before. This problem is happening a fair bit more. Here is where it hangs... Hung dmesg output: -- snip --- orm0: at iomem 0xc-0xc7fff,0xc8000-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ppc0: parallel port not found. Timecounters tick every 1.000 msec acd0: CDRW at ata0-master UDMA33 aacd0: on aac0 aacd0: 69889MB (143132672 sectors) --- end snip --- The system does not continue on and probe the drives, as seen in a normal boot dmesg: --- snip --- sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ppc0: parallel port not found. Timecounters tick every 1.000 msec acd0: CDRW at ata0-master UDMA33 aacd0: on aac0 aacd0: 69889MB (143132672 sectors) pass0 at aacp0 bus 0 target 0 lun 0 pass0: Fixed unknown SCSI-3 device pass0: 3.300MB/s transfers pass1 at aacp0 bus 0 target 3 lun 0 pass1: Fixed unknown SCSI-3 device pass1: 3.300MB/s transfers SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/aacd0s1a -- end snip -- In a effort to resolve this I increased the scsi delay in the kernel from 5ms to 10ms options SCSI_DELAY=1 It *may* have helped on one of my reboot tests, I thought it was going to hang again but proceeded. However it definitely did not solve the issue. Once I am back in the office I will see if I can get some debug output for you. Cheers, Jeff Update --- The TIMEOUT error I think has been resolved using aac 2.0.7-1 patch. The system has never failed on any of my t
Re: bge Ierr rate increase from 5.3R -> 6.1R
> When dealing with Cisco<->othervendor, I've never seen auto-neg > work properly. One has to always hard set the speed and duplex > on both sides for it to work. Nowadays auto-neg almost always works for us, even for Fast Ethernet. We have Cisco-Extreme, Cisco-Juniper, Cisco-Cisco, Cisco-Riverstone and of course lots of Cisco-various hosts. Basically, things just work. We always use auto-neg for Gigabit Ethernet. 3-4 years ago the situation was different, and we always used to set speed/duplex. Not any more. Maybe you've been unlucky. Steinar Haug, Nethelp consulting, [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: Dummynet and simulating random delay
On Wed, Jan 24, 2007 at 06:10:21PM +1100, Peter Jeremy wrote: > On Tue, 2007-Jan-23 14:22:54 -0500, Andresen, Jason R. wrote: > >I have a project that requires me to simulate a link with varying but > >well defined delay. The link is guarenteed to deliver packets in > >order, so I wish to maintain that behavior with Dummynet. > > I don't think dummynet can do this in its current form. Based on actually dummynet never does reordering within a single pipe, even if you change the delay on the fly. But this said, you should explain "varying but well defined delay", because if you use TCP or similar as the source, then you have no control on when the userland write->tcp transmission delay anyways so the concept is a bit vague and probably not a meaningful experiment. And even in any common network (from switched ethernet to wireless to dsl...) you have some variance on the delay, ranging from a fraction of a millisecond to much larger values, due to queueing and/or protocol issues (e.g. MAC channel allocation) and/or switch/router/operating system issues. If your delay varies on a coarse timescale, you can just change the pipe's delay as needed, and once things have settled (because of the no-reordering) you know that your packets are delayed by exactly what you specify, plus the If you are interested in somewhat random delays (e.g. to model the effect of interfering traffic) you do just that - fire extra traffic to the same pipe, and then as a side effect of the queueing, your traffic will be subject to variable delays. Also keep in mind that the resolution of dummynet is 1/hz so it is in the order of 1 millisecond. cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atacontrol kernel crash (atausb?)
On Wed, Jan 24, 2007 at 12:54:51PM +0100, Hans Petter Selasky wrote: > On Wednesday 24 January 2007 12:38, Ed Schouten wrote: > > Hello, > > > > * Pietro Cerutti <[EMAIL PROTECTED]> wrote: > > > On 1/15/07, Hans Petter Selasky <[EMAIL PROTECTED]> wrote: > > > >No. What happens when you use/load "umass" and unload "atausb" ? > > > > > > Everything works nice with umass. It creates the da0 device node. > > > It just shows up these errors, as it always did... > > > GEOM: new disk da0 > > > da0 at umass-sim0 bus 0 target 0 lun 0 > > > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > > > da0: Serial Number > > > da0: 40.000MB/s transfers > > > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > > I had these messages with two other devices before, an MP3 player and a > > USB floppy drive. I fixed these errors by adding a quirk to > > /sys/cam/scsi/scsi_da.c. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 > > Instead of having all these quirks, isn't it possible that the SCSI layer can > auto-probe this? No - it is intended to fail on devices not supporting the commands. And the user should know if a drive has not been synced befor unplugging it from power. The SCSI Layer could ask if the device has a cache at least, but I this would likely just relocate the problem. Issuing unsupported commands should be harmless for any sane device, but often bad implemented devices just hang on unknown commands. IIRC umass specification has a way to distinguish reduced command set flash type from generic SCSI devices, by interpreting the subclass. That way umass could safely catch such commands. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: bge Ierr rate increase from 5.3R -> 6.1R
On Wed, Jan 24, 2007 at 03:25:37PM +0100, Robin Gruyters wrote: > Should this not be visible on the switch as well?!? > > Here some output from the interface on the server and from the switch > (Cisco) > > [development interface] > bge0: flags=8843 mtu 1500 > options=1b > ether 00:12:79:94:ed:12 > media: Ethernet autoselect (100baseTX ) > status: active > [/development interface] > > [switch] > FastEthernet0/3 is up, line protocol is up (connected) > Hardware is Fast Ethernet, address is 000e.84d0.de03 (bia 000e.84d0.de03) > Description: development > MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 100Mb/s > input flow-control is off, output flow-control is off > ARP type: ARPA, ARP Timeout 04:00:00 > Last input never, output 00:00:02, output hang never > Last clearing of "show interface" counters never > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 5 minute input rate 179000 bits/sec, 28 packets/sec > 5 minute output rate 56000 bits/sec, 24 packets/sec > 22823978 packets input, 4067576147 bytes, 0 no buffer > Received 13138 broadcasts (0 multicast) > 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored > 0 watchdog, 12929 multicast, 0 pause input > 0 input packets with dribble condition detected > 15673035 packets output, 3975127029 bytes, 0 underruns > 0 output errors, 0 collisions, 1 interface resets > 0 babbles, 0 late collision, 0 deferred > 0 lost carrier, 0 no carrier, 0 PAUSE output > 0 output buffer failures, 0 output buffers swapped out > [/switch] You've got a Cisco involved, so I doubt it. :-) I've seen many times in the past where one end of the link shows errors while the other end (in my experiences, Cisco Catalysts) shows none. When dealing with Cisco<->othervendor, I've never seen auto-neg work properly. One has to always hard set the speed and duplex on both sides for it to work. For example: I lease space in two co-location facilities, from different providers. Both providers use Cisco switches (different models), while we use HP ProCurves. In both facilities, we saw input errors on our ProCurve, while the providers saw absolutely no errors. Both sides were set to auto. The instant I had the providers set 100/full on their Ciscos and I set 100/FD on our ProCurves, the error counts completely disappeared. Set your Cisco configuration to use 100/full, and edit the ifconfig_bge0 line in rc.conf on your FreeBSD box to have "media 100baseTX mediaopt full-duplex", then reboot the FreeBSD box. If the problem continues, there may be faulty cabling, but usually errors on one direction are a sign of duplex mismatch. If after replacing the cabling the issue continues, then there's a chance the bge(4) driver may be obtaining statistics wrong for the particular chip revision being used (this is hearsay on my part; I'm just guessing...) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Supermicro X7DBR-8+ hang at boot
Rinat K. Nugaev wrote: В сообщении от 24 января 2007 13:35 [EMAIL PROTECTED] написал(a): On 1/23/07, Guy Helmer <[EMAIL PROTECTED]> wrote: Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ motherboard (dual Xeon 5130 CPUs on the Blackford chipset - http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cf m) hanging after printing the "Waiting 5 seconds for SCSI devices to settle" message. The hang doesn't always happen - sometimes we have to go through several reboot cycles for it to happen - but sometimes it happens with every reboot. For those who would suggest that this happens because I'm using Seagate drives, it happens even if we totally remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit ethernet NICs aren't found but the hang doesn't occur. 1.Boot in safe_mode 2.Rebuild kernel with SMP (options SMP) 3.Be Happy. Well, I was using SMP kernels... Jack Vogel's suggestion to set hint.apic.0.disabled=1 has resolved the hang on boot on my system. FreeBSD 7 (January 2007 snapshot) has been working for me as well, but I'm not ready to use that in production. Thanks, Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bge Ierr rate increase from 5.3R -> 6.1R
Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: Is there a fix for it already, or maybe a workaround? The problem was that the driver code was not properly obtaining error statistics from the Broadcom chip, thus errors _were_ (before the fix) not being calculated/accounted for. Now (after the fix) errors are being accounted for correctly. So the errors you see in your netstat output are probably real/ ccurate. I'll vote for a duplex-related problem or some naughty cabling. Should this not be visible on the switch as well?!? Here some output from the interface on the server and from the switch (Cisco) [development interface] bge0: flags=8843 mtu 1500 options=1b ether 00:12:79:94:ed:12 media: Ethernet autoselect (100baseTX ) status: active [/development interface] [switch] FastEthernet0/3 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 000e.84d0.de03 (bia 000e.84d0.de03) Description: development MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:02, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 179000 bits/sec, 28 packets/sec 5 minute output rate 56000 bits/sec, 24 packets/sec 22823978 packets input, 4067576147 bytes, 0 no buffer Received 13138 broadcasts (0 multicast) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 12929 multicast, 0 pause input 0 input packets with dribble condition detected 15673035 packets output, 3975127029 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out [/switch] Regards, Robin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bge Ierr rate increase from 5.3R -> 6.1R
On Wed, Jan 24, 2007 at 10:57:41AM +0100, Robin Gruyters wrote: > I have the same problem here. At the moment I only have two servers > upgraded from FreeBSD 5.4R to FreeBSD 6.1R and one to FreeBSD 6.2R. > > And here is the netstat -ni output from our development server: > > [netstat -ni] > NameMtu Ipkts Ierrs Opkts Oerrs Coll > ste0* 15000 0 0 0 0 > ste1* 15000 0 0 0 0 > ste2* 15000 0 0 0 0 > ste3* 15000 0 0 0 0 > bge015009866912 2114443 188352090 0 > bge015002004841 - 18833483- - > bge015001723393 - 1719554 - - > bge0150082 - 66 - - > bge0150019036813- 14796159- - > bge0150038709278- 35167554- - > bge015000 - 0 - - > bge01500621 - 0 - - > bge015001716- 0 - - > bge01500184 - 0 - - > bge0150052881 - 2336- - > bge1* 15000 0 0 0 0 > pflog 33208 0 0 0 0 > lo0 16384 0 516926240 0 > lo0 16384 6611- 6611- - > [...] > > Is there a fix for it already, or maybe a workaround? The problem was that the driver code was not properly obtaining error statistics from the Broadcom chip, thus errors _were_ (before the fix) not being calculated/accounted for. Now (after the fix) errors are being accounted for correctly. So the errors you see in your netstat output are probably real/ ccurate. I'll vote for a duplex-related problem or some naughty cabling. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
On Tue, Jan 23, 2007 at 09:57:06PM +0100, Dimitry Andric wrote: > Yes. The specific line in my rc.conf is: > > ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128" With that setup you should be able to just do: ipv6_defaultrouter="2001:7b8:2ff:146::1" ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 prefixlen 127" I know it doesn't solve the bug, but if you just need it working... :) Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgp5E6HMkfHzA.pgp Description: PGP signature
Re: Lenovo X60 em workaround
On Mon, 2007-01-22 at 10:30 -0800, Jack Vogel wrote:
> On 1/22/07, Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
> > Jack,
> >
> > On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote:
> > J> >> Since this was just seen, and the patch below validated as working I
> > J> >wanted
> > J> >> to send general email to capture this:
> > J> >>
> > J> >> The Lenovo X60 can have issues with long ping times, this is a KNOWN
> > J> >> hardware problem, and Intel is working with IBM/Lenovo, a final 'fix'
> > has
> > J> >> not been decided on yet. Nevertheless, the patch below will work, but
> > J> >> I do not want to check it in as its still temporary.
> > J> >>
> > J> >> Address questions to me,
> > J> >
> > J> >Okay, I have a question. Could you elaborate on just what the problem
> > is?
> > J> >(I mean, since it's KNOWN and all...) I'm just having a hard time
> > figuring
> > J> >out what problem could possibly be fixed by setting the RX interrupt
> > J> >delay timer to a non-zero value (especially since elsewhere in the em(4)
> > J> >source it says that doing so is a Bad Thing (tm)).
> > J>
> > J> saying its known to be a problem doesnt mean its cause is known :)
> > J> They discovered that setting this eliminated the problem, but we
> > J> immediately pointed out that this is, as you pointed out, a Bad
> > J> Thing on other hardware, so the investigation continues, there is
> > J> always a communication lag on these kind of things, so I dont know
> > J> if it has been resolved yet or not.
> > J>
> > J> I just dont think this patch will become the final way to solve this,
> > J> but we shall see :)
> >
> > Good to know that there is progress on this. Thanks! I will try the patch
> > on my Lenovo T60 notebook, where the problem is also present. AFAIK, it
> > is present on any Lenovo notebook with 82573 NIC.
> >
> > Can you please acknowledge that another bug with Lenovo + em(4) is known? I
> > mean the problem, that em(4) isn't initialized properly on kernel boot, if
> > the link is down. I have already reported this to you, and you said that
> > I probably have bad hardware. Since that time, I've found several similar
> > reports about Lenovo notebooks and em(4) driver in FreeBSD.
>
> Hey Gleb,
>
> Acknowledge... I can do better than that, I have a fix for this problem, and
> its not temporary. Here is the code change (not a patch, I'm very busy),
> its in hardware_init, should be obvious how to patch:
>
>/* Make sure we have a good EEPROM before we read from it */
> if (e1000_validate_nvm_checksum(&adapter->hw) < 0) {
> /*
> ** Some PCI-E parts fail the first check due to
> ** the link being in sleep state, call it again,
> ** if it fails a second time its a real issue.
> */
> if (e1000_validate_nvm_checksum(&adapter->hw) < 0) {
> device_printf(dev,
> "The EEPROM Checksum Is Not Valid\n");
> return (EIO);
> }
> }
>
> This is already checked into my code base at Intel, I've just been too
> busy to do anything with it, be my guest if you wish to check it in after
> testing...
Just to add another datapoint - and for the archives - this also appears
to fix an issue with the Toshiba Tecra M5L. The "EEPROM Checksum Is Not
Valid" message would appear on boot if there was no link on the
interface, although the interface would appear to work fine from then
on. With this patch, the message no longer appears.
I also have problems with connections to networks (only seen when
connected to 10 meg half duplex hubs) with long delays on some packets
(which I'm assuming is the issue that started this thread) - I haven't
been able to verify yet that either patch fixes that, though.
Gavin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atacontrol kernel crash (atausb?)
Hello, * Pietro Cerutti <[EMAIL PROTECTED]> wrote: > On 1/15/07, Hans Petter Selasky <[EMAIL PROTECTED]> wrote: > > > >No. What happens when you use/load "umass" and unload "atausb" ? > Everything works nice with umass. It creates the da0 device node. > It just shows up these errors, as it always did... > GEOM: new disk da0 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > da0: Serial Number > da0: 40.000MB/s transfers > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > status == 0x0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > status == 0x0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > status == 0x0 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > status == 0x0 I had these messages with two other devices before, an MP3 player and a USB floppy drive. I fixed these errors by adding a quirk to /sys/cam/scsi/scsi_da.c. http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/ pgpNY0N7rLW7C.pgp Description: PGP signature
Re: atacontrol kernel crash (atausb?)
On Wednesday 24 January 2007 12:38, Ed Schouten wrote: > Hello, > > * Pietro Cerutti <[EMAIL PROTECTED]> wrote: > > On 1/15/07, Hans Petter Selasky <[EMAIL PROTECTED]> wrote: > > >No. What happens when you use/load "umass" and unload "atausb" ? > > > > Everything works nice with umass. It creates the da0 device node. > > It just shows up these errors, as it always did... > > GEOM: new disk da0 > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > > da0: Serial Number > > da0: 40.000MB/s transfers > > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > status == 0x0 > > I had these messages with two other devices before, an MP3 player and a > USB floppy drive. I fixed these errors by adding a quirk to > /sys/cam/scsi/scsi_da.c. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 > http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 Instead of having all these quirks, isn't it possible that the SCSI layer can auto-probe this? --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-stable Digest, Vol 190, Issue 4
В сообщении от 24 января 2007 13:35 [EMAIL PROTECTED] написал(a): > On 1/23/07, Guy Helmer <[EMAIL PROTECTED]> wrote: > > Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ > > motherboard (dual Xeon 5130 CPUs on the Blackford chipset - > > http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cf > >m) hanging after printing the "Waiting 5 seconds for SCSI devices to > > settle" message. The hang doesn't always happen - sometimes we have to > > go through several reboot cycles for it to happen - but sometimes it > > happens with every reboot. For those who would suggest that this happens > > because I'm using Seagate drives, it happens even if we totally remove > > the SCSI drive (but leave the aic7902 SCSI interfaces enabled) and boot > > from a SATA disk. Using FreeBSD 6.1, the Intel gigabit ethernet NICs > > aren't found but the hang doesn't occur. 1.Boot in safe_mode 2.Rebuild kernel with SMP (options SMP) 3.Be Happy. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bge Ierr rate increase from 5.3R -> 6.1R
On 13 Dec 2006, at 19:30, Greg Eden wrote: On 13 Dec 2006, at 09:18, Gleb Smirnoff wrote: > D> > Greg Eden wrote: > D> >> Hello > D> >> > D> >> I recently updated two production servers from 5.3 to 6.1 via > D> >> cvsup and > D> >> buildworld. Since the upgrade I've seen an increase in the > number of > D> >> Input packet errors reported on the bge cards in on both boxes. > > In 5.3-RELEASE the bge(4) driver did not read the error count from the > chip at all. So errors were not accounted. Many thanks for clearing up the mystery I have the same problem here. At the moment I only have two servers upgraded from FreeBSD 5.4R to FreeBSD 6.1R and one to FreeBSD 6.2R. [FreeBSD 6.1R] Copyright (c) 1992-2006 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 6.1-RELEASE-p10 #1: Tue Oct 24 10:44:15 CEST 2006 [EMAIL PROTECTED]:/data/obj/data/src_6_1/sys/YIRDIS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x649d> AMD Features=0x2000 Logical CPUs per core: 2 real memory = 2147430400 (2047 MB) avail memory = 2100654080 (2003 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard ioapic3 irqs 72-95 on motherboard ioapic4 irqs 96-119 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci2: on pcib1 pcib2: at device 0.0 on pci2 pci3: on pcib2 bge0: mem 0xfdef-0xfdef irq 25 at device 1.0 on pci3 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:12:79:d7:bb:99 bge1: mem 0xfdee-0xfdee irq 26 at device 1.1 on pci3 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:12:79:d7:bb:98 pcib3: at device 0.2 on pci2 pci4: on pcib3 ciss0: port 0x4000-0x40ff mem 0xfdff-0xfdff1fff,0xfdf8-0xfdfb irq 51 at device 3.0 on pci4 ciss0: [GIANT-LOCKED] pcib4: at device 6.0 on pci0 pci5: on pcib4 pcib5: at device 0.0 on pci5 pci6: on pcib5 pcib6: at device 0.2 on pci5 pci10: on pcib6 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) pci0: at device 29.7 (no driver attached) pcib7: at device 30.0 on pci0 pci1: on pcib7 pci1: at device 3.0 (no driver attached) pci1: at device 4.0 (no driver attached) pci1: at device 4.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] pmtimer0 on isa0 orm0: at iomem 0xc-0xc7fff,0xc8000-0xcbfff,0xcc000-0xcd7ff,0xee000-0xe on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master PIO4 sa0 at ciss0 bus 33 target 5 lun 0 sa0: Removable Sequential Access SCSI-3 device sa0: 135.168MB/s transfers da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) da1 at ciss0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-0 device da1: 135.168MB/s transfers da1: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) da2 at ciss0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-0 device da2: 135.168MB/s transfers da2: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a bge1: link state changed to UP bge0: link state changed to UP [/FreeBSD 6.1R] [FreeBSD 6.2R] Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All right
Re: Audio (Record) not functioning... (record interrupt timeout)
Original-Nachricht Datum: Tue, 23 Jan 2007 18:16:13 -0500 Von: Ben Hacker Jr <[EMAIL PROTECTED]> An: Stable FBSD , questions FBSD Betreff: Audio (Record) not functioning... (record interrupt timeout) > Any help will be Greatly appreciated! I currently believe this is a > problem with the "snd_t4dwave" driver device" Hi Ben, I am experiencing similar problems with the snd_t4dwave driver, but with playback. Playback works for a few seconds, then it stops and the kernel also reports an interrupt timeout. Didn't find a solution yet I'm afraid. Regards, Jost Menke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
*** Click here to view our e-mail legal notice: http://www.mxit.co.za/pdfs/mxit_legal.pdf or call: +27 21 888 5000 *** Any progress on the BCE serdes driver? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conrad Burger Sent: 16 January 2007 08:53 PM To: Morten A. Middelthon; David Christensen Cc: freebsd-stable@freebsd.org; Roar Pettersen Subject: RE: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S) *** Click here to view our e-mail legal notice: http://www.mxit.co.za/pdfs/mxit_legal.pdf or call: +27 21 888 5000 *** If you have an alpha or beta version of the bce driver that supports serdes, please let me know and I'll start testing right away! Regards Conrad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Morten A. Middelthon Sent: 16 January 2007 08:56 AM To: David Christensen Cc: freebsd-stable@freebsd.org; Roar Pettersen Subject: Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S) On Mon, Jan 15, 2007 at 09:16:16AM -0800, David Christensen wrote: > > Hello Dave ! > > > > >Wed Nov 1 18:54:19 UTC 2006 > > > > > >Yes, the Linux bnx2 driver does support SerDes. I don't have the > > >bandwidth to tackle this feature until after the first of the year, > > >though a few other people have also considered looking into adding > > >the support. > > > > > > Any news or status report regarding support for this new > > network interface > > in FreeBSD ? > > I've copied Doug White who is working to add SerDes support to bce. I'm _really_ looking forward to getting SerDes support in the bce-driver :) -- Morten A. Middelthon Remember: Silly is a state of Mind, Stupid is a way of Life. -- Dave Butler ___ 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]"
