Re: dlfcn(3) spacing tweak
On Mon, Dec 05, 2022 at 06:42:00AM +, Jason McIntyre wrote: > On Sun, Dec 04, 2022 at 08:29:26PM -0500, Brad Smith wrote: > > After the RTLD_NOLOAD addition to the page the spacing looks kind of > > odd. Make the spacing look like RTLD_NOW / RTLD_LAZY above that. > > > > > > Index: dlfcn.3 > > === > > RCS file: /home/cvs/src/share/man/man3/dlfcn.3,v > > retrieving revision 1.32 > > diff -u -p -u -p -r1.32 dlfcn.3 > > --- dlfcn.3 20 Aug 2022 14:14:24 - 1.32 > > +++ dlfcn.3 5 Dec 2022 01:22:53 - > > @@ -126,7 +126,7 @@ then it is promoted to RTLD_GLOBAL. > > .Pp > > Additionally, the following flag may be ORed into the mode argument: > > .Pp > > -.Bl -tag -width "RTLD_NODELETE" -compact -offset indent > > +.Bl -tag -width "RTLD_NODELETE" -offset indent > > .It Sy RTLD_NODELETE > > Prevents unload of the loaded object on > > .Fn dlclose . > > > > hi. > > i've no issue with or without -compact, but you should adjust the > RTLD_GLOBAL/RTLD_LOCAL list to the same format. > > jmc Here goes. Index: dlfcn.3 === RCS file: /home/cvs/src/share/man/man3/dlfcn.3,v retrieving revision 1.32 diff -u -p -u -p -r1.32 dlfcn.3 --- dlfcn.3 20 Aug 2022 14:14:24 - 1.32 +++ dlfcn.3 5 Dec 2022 06:45:33 - @@ -109,7 +109,7 @@ This is the default value if resolution .Pp One of the following values may be used to specify symbol visibility: .Pp -.Bl -tag -width "RTLD_GLOBAL" -compact -offset indent +.Bl -tag -width "RTLD_GLOBAL" -offset indent .It Sy RTLD_GLOBAL The object's symbols and the symbols of its dependencies will be visible to other objects. @@ -126,7 +126,7 @@ then it is promoted to RTLD_GLOBAL. .Pp Additionally, the following flag may be ORed into the mode argument: .Pp -.Bl -tag -width "RTLD_NODELETE" -compact -offset indent +.Bl -tag -width "RTLD_NODELETE" -offset indent .It Sy RTLD_NODELETE Prevents unload of the loaded object on .Fn dlclose .
dlfcn(3) spacing tweak
After the RTLD_NOLOAD addition to the page the spacing looks kind of odd. Make the spacing look like RTLD_NOW / RTLD_LAZY above that. Index: dlfcn.3 === RCS file: /home/cvs/src/share/man/man3/dlfcn.3,v retrieving revision 1.32 diff -u -p -u -p -r1.32 dlfcn.3 --- dlfcn.3 20 Aug 2022 14:14:24 - 1.32 +++ dlfcn.3 5 Dec 2022 01:22:53 - @@ -126,7 +126,7 @@ then it is promoted to RTLD_GLOBAL. .Pp Additionally, the following flag may be ORed into the mode argument: .Pp -.Bl -tag -width "RTLD_NODELETE" -compact -offset indent +.Bl -tag -width "RTLD_NODELETE" -offset indent .It Sy RTLD_NODELETE Prevents unload of the loaded object on .Fn dlclose .
Re: Fix C++ namespace polution in stdio.h header
ping. On 10/15/2021 7:41 PM, Brad Smith wrote: The following diff fixes namespace polution with C++ in the stdio.h header. I was looking into a build issue when trying to build another program dependent on a new port I posted (spdlog). Peeking at one of it's headers I noticed a workaround for OpenBSD that doesn't work anyway. Fixing the stdio.h header, removing the workaround and it builds fine. // OpenBSD doesn't compile with :: before the fileno(..) #if defined(__OpenBSD__) int fd = fileno(f); #else int fd = ::fileno(f); #endif Fixing the stdio.h header also allows us to remove the only local patch we have for libc++, which upstream is not willing to accept as it is just working around the namespace polution which none of the other OS's supported have. diff --git a/libcxx/include/stdio.h b/libcxx/include/stdio.h index f84122034891f..b57268c264162 100644 --- a/libcxx/include/stdio.h +++ b/libcxx/include/stdio.h @@ -113,6 +113,8 @@ void perror(const char* s); #undef clearerr #undef feof #undef ferror +#undef putchar +#undef getchar #endif https://svnweb.freebsd.org/base/head/include/stdio.h?r1=210957=228875_format=u https://github.com/DragonFlyBSD/DragonFlyBSD/commit/513b6430389cd0d20fbc2e5aa62d9c5246729321 http://cvsweb.netbsd.org/bsdweb.cgi/src/include/stdio.h.diff?r1=1.86=1.87_with_tag=MAIN I had this run through a bulk ports build on i386 without any issues. Index: stdio.h === RCS file: /home/cvs/src/include/stdio.h,v retrieving revision 1.54 diff -u -p -u -p -r1.54 stdio.h --- stdio.h 11 Sep 2020 17:56:41 - 1.54 +++ stdio.h 12 Oct 2021 03:35:08 - @@ -395,13 +395,14 @@ static __inline int __sputc(int _c, FILE return (__swbuf(_c, _p)); } +extern int __isthreaded; + +#ifndef __cplusplus #define __sfeof(p) (((p)->_flags & __SEOF) != 0) #define __sferror(p)(((p)->_flags & __SERR) != 0) #define __sclearerr(p) ((void)((p)->_flags &= ~(__SERR|__SEOF))) #define __sfileno(p)((p)->_file) -extern int __isthreaded; - #define feof(p) (!__isthreaded ? __sfeof(p) : (feof)(p)) #define ferror(p) (!__isthreaded ? __sferror(p) : (ferror)(p)) #define clearerr(p) (!__isthreaded ? __sclearerr(p) : (clearerr)(p)) @@ -435,5 +436,6 @@ extern int __isthreaded; #define putchar(x) putc(x, stdout) #define getchar_unlocked()getc_unlocked(stdin) #define putchar_unlocked(c) putc_unlocked(c, stdout) +#endif /* __cplusplus */ #endif /* _STDIO_H_ */
[llvm-objdump] Left justify display of OpenBSD headers
This makes the header printing look the same as the GNU objdump. Index: llvm/tools/llvm-objdump/ELFDump.cpp === RCS file: /home/cvs/src/gnu/llvm/llvm/tools/llvm-objdump/ELFDump.cpp,v retrieving revision 1.2 diff -u -p -u -p -r1.2 ELFDump.cpp --- llvm/tools/llvm-objdump/ELFDump.cpp 14 Nov 2022 13:42:19 - 1.2 +++ llvm/tools/llvm-objdump/ELFDump.cpp 19 Nov 2022 09:47:16 - @@ -244,16 +244,16 @@ static void printProgramHeaders(const EL outs() << "NOTE "; break; case ELF::PT_OPENBSD_BOOTDATA: - outs() << "OPENBSD_BOOTDATA "; + outs() << "OPENBSD_BOOTDATA "; break; case ELF::PT_OPENBSD_MUTABLE: - outs() << "OPENBSD_MUTABLE "; + outs() << "OPENBSD_MUTABLE "; break; case ELF::PT_OPENBSD_RANDOMIZE: - outs() << "OPENBSD_RANDOMIZE "; + outs() << "OPENBSD_RANDOMIZE "; break; case ELF::PT_OPENBSD_WXNEEDED: - outs() << "OPENBSD_WXNEEDED "; + outs() << "OPENBSD_WXNEEDED "; break; case ELF::PT_PHDR: outs() << "PHDR ";
Recognize PT_OPENBSD_MUTABLE with LLVM's readobj / objdump
Recognize PT_OPENBSD_MUTABLE with LLVM's readobj / objdump. Index: llvm/llvm/tools/llvm-objdump/ELFDump.cpp === RCS file: /home/cvs/src/gnu/llvm/llvm/tools/llvm-objdump/ELFDump.cpp,v retrieving revision 1.1.1.3 diff -u -p -u -p -r1.1.1.3 ELFDump.cpp --- llvm/llvm/tools/llvm-objdump/ELFDump.cpp17 Dec 2021 12:23:42 - 1.1.1.3 +++ llvm/llvm/tools/llvm-objdump/ELFDump.cpp14 Nov 2022 01:32:11 - @@ -246,6 +246,9 @@ static void printProgramHeaders(const EL case ELF::PT_OPENBSD_BOOTDATA: outs() << "OPENBSD_BOOTDATA "; break; +case ELF::PT_OPENBSD_MUTABLE: + outs() << "OPENBSD_MUTABLE "; + break; case ELF::PT_OPENBSD_RANDOMIZE: outs() << "OPENBSD_RANDOMIZE "; break; Index: llvm/llvm/tools/llvm-readobj/ELFDumper.cpp === RCS file: /home/cvs/src/gnu/llvm/llvm/tools/llvm-readobj/ELFDumper.cpp,v retrieving revision 1.1.1.3 diff -u -p -u -p -r1.1.1.3 ELFDumper.cpp --- llvm/llvm/tools/llvm-readobj/ELFDumper.cpp 17 Dec 2021 12:23:42 - 1.1.1.3 +++ llvm/llvm/tools/llvm-readobj/ELFDumper.cpp 14 Nov 2022 01:12:39 - @@ -1369,6 +1369,7 @@ static StringRef segmentTypeToString(uns LLVM_READOBJ_ENUM_CASE(ELF, PT_GNU_RELRO); LLVM_READOBJ_ENUM_CASE(ELF, PT_GNU_PROPERTY); +LLVM_READOBJ_ENUM_CASE(ELF, PT_OPENBSD_MUTABLE); LLVM_READOBJ_ENUM_CASE(ELF, PT_OPENBSD_RANDOMIZE); LLVM_READOBJ_ENUM_CASE(ELF, PT_OPENBSD_WXNEEDED); LLVM_READOBJ_ENUM_CASE(ELF, PT_OPENBSD_BOOTDATA);
Fix C++ namespace polution in stdio.h header
The following diff fixes namespace polution with C++ in the stdio.h header. I was looking into a build issue when trying to build another program dependent on a new port I posted (spdlog). Peeking at one of it's headers I noticed a workaround for OpenBSD that doesn't work anyway. Fixing the stdio.h header, removing the workaround and it builds fine. // OpenBSD doesn't compile with :: before the fileno(..) #if defined(__OpenBSD__) int fd = fileno(f); #else int fd = ::fileno(f); #endif Fixing the stdio.h header also allows us to remove the only local patch we have for libc++, which upstream is not willing to accept as it is just working around the namespace polution which none of the other OS's supported have. diff --git a/libcxx/include/stdio.h b/libcxx/include/stdio.h index f84122034891f..b57268c264162 100644 --- a/libcxx/include/stdio.h +++ b/libcxx/include/stdio.h @@ -113,6 +113,8 @@ void perror(const char* s); #undef clearerr #undef feof #undef ferror +#undef putchar +#undef getchar #endif https://svnweb.freebsd.org/base/head/include/stdio.h?r1=210957=228875_format=u https://github.com/DragonFlyBSD/DragonFlyBSD/commit/513b6430389cd0d20fbc2e5aa62d9c5246729321 http://cvsweb.netbsd.org/bsdweb.cgi/src/include/stdio.h.diff?r1=1.86=1.87_with_tag=MAIN I had this run through a bulk ports build on i386 without any issues. Index: stdio.h === RCS file: /home/cvs/src/include/stdio.h,v retrieving revision 1.54 diff -u -p -u -p -r1.54 stdio.h --- stdio.h 11 Sep 2020 17:56:41 - 1.54 +++ stdio.h 12 Oct 2021 03:35:08 - @@ -395,13 +395,14 @@ static __inline int __sputc(int _c, FILE return (__swbuf(_c, _p)); } +extern int __isthreaded; + +#ifndef __cplusplus #define__sfeof(p) (((p)->_flags & __SEOF) != 0) #define__sferror(p)(((p)->_flags & __SERR) != 0) #define__sclearerr(p) ((void)((p)->_flags &= ~(__SERR|__SEOF))) #define__sfileno(p)((p)->_file) -extern int __isthreaded; - #define feof(p)(!__isthreaded ? __sfeof(p) : (feof)(p)) #define ferror(p) (!__isthreaded ? __sferror(p) : (ferror)(p)) #define clearerr(p)(!__isthreaded ? __sclearerr(p) : (clearerr)(p)) @@ -435,5 +436,6 @@ extern int __isthreaded; #defineputchar(x) putc(x, stdout) #define getchar_unlocked() getc_unlocked(stdin) #define putchar_unlocked(c)putc_unlocked(c, stdout) +#endif /* __cplusplus */ #endif /* _STDIO_H_ */
Re: uaq(4): aquantia usb ethernet driver
On 8/31/2021 8:46 PM, Jonathan Matthew wrote: Here's a driver for the Aquantia USB ethernet devices I just added to usbdevs. These are somewhat interesting because they theoretically go up to 5GbE and support jumbo frames (not implemented yet). While working on this I noticed that it doesn't receive 15-25% of the packets it should, even at very low packet rates, when connected to ehci(4) controllers. No such packet loss occurs with an xhci(4) controller. I'm not sure if this is a problem with our ehci driver or a poor hardware interaction. ok? uaq0 at uhub0 port 2 configuration 1 interface 0 "QNAP? Pacific?" rev 2.10/1.01 addr 2 uaq0: ver 3.1.6, address 24:5e:be:4d:9b:07 media: Ethernet autoselect (5000baseT full-duplex) When I first booted my system I found I couldn't get it to establish a link at anything above 1 Gbps. I unplugged the adapter, plugged it back into a Windows laptop to double check it would indeed work, which it did, and then plugged it back into the OpenBSD laptop. I noticed it was working as expected. Kinda weird. Appears to be working Ok so far and with IPv6 too.
Re: macppc: add ld.script for kernel, ofwboot
On Mon, May 10, 2021 at 09:49:24PM +0200, Mark Kettenis wrote:
> > Date: Mon, 10 May 2021 14:22:33 -0400
> > From: George Koehler
> >
> > On Fri, 7 May 2021 10:31:55 +0200 (CEST)
> > Mark Kettenis wrote:
> >
> > > Makes sense to me. It seems ldd always seems to require a little bit
> > > more coercion to produce non-standard binaries. We use linker scripts
> > > for the various EFI bootloaders as well.
> > >
> > > ok kettenis@
> >
> > My diff had an extra "pwd" in arch/macppc/stand/ofwboot/Makefile;
> > I deleted the "pwd" before committing it.
> >
> > > > -${PROG}: ${OBJS} ${LIBSA} ${LIBZ}
> > > > - ${LD} -nopie -znorelro -N -X -Ttext ${RELOC} -e ${ENTRY} -o
> > > > ${PROG} \
> > > > +${PROG}: ${OBJS} ${LIBSA} ${LIBZ} ld.script
> > > > + pwd
> > > > + ${LD} -nopie -znorelro -N -X -T ${.CURDIR}/ld.script -o ${PROG}
> > > > \
> > > > ${OBJS} ${LIBS}
> >
> > >From my experiments with lld 10, I believe that macppc is almost ready
> > to switch from ld.bfd to ld.lld. I know of 2 other problems:
> >
> > 1. ports/lang/gcc/8 needs USE_LLD = No, because lld 10 can't link
> > C++ code from gcc. (I have not yet checked lld 11.) lld had no
> > problem with Fortran ports built by gcc.
> >
> > 2. All instances of -Wl,-relax or -Wl,--relax in src or ports must
> > be deleted, because it is an unknown option to lld, but lld can
> > link large binaries without the option.
>
> Maybe just coordinate with Theo and the ports folks and move ahead.
Index: gnu/usr.bin/clang/Makefile.inc
===
RCS file: /home/cvs/src/gnu/usr.bin/clang/Makefile.inc,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 Makefile.inc
--- gnu/usr.bin/clang/Makefile.inc 19 May 2021 23:18:40 - 1.24
+++ gnu/usr.bin/clang/Makefile.inc 5 Jun 2021 03:40:20 -
@@ -77,7 +77,3 @@ DPADD+= ${.OBJDIR}/../lib${lib}/lib${lib
LDADD+=${.OBJDIR}/../lib${lib}/lib${lib}.a
.endfor
LDADD+=-Wl,--end-group
-
-.if ${MACHINE_ARCH} == "powerpc"
-LDADD+=-Wl,-relax
-.endif
Index: devel/clang-tools-extra/Makefile
===
RCS file: /home/cvs/ports/devel/clang-tools-extra/Makefile,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 Makefile
--- devel/clang-tools-extra/Makefile18 May 2021 06:19:48 - 1.16
+++ devel/clang-tools-extra/Makefile5 Jun 2021 03:32:01 -
@@ -67,11 +67,6 @@ CONFIGURE_ARGS +=-DCLANG_ENABLE_STATIC_
-DLLVM_INCLUDE_EXAMPLES=OFF \
-DLLVM_INCLUDE_TESTS=OFF
-.if ${MACHINE_ARCH} == "powerpc"
-CONFIGURE_ARGS += -DCMAKE_EXE_LINKER_FLAGS="-Wl,--relax"
-CONFIGURE_ARGS += -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--relax"
-.endif
-
GCC_VER = 8.4.0
.if ${MACHINE_ARCH} == "amd64"
GCC_CONFIG = x86_64-unknown-openbsd${OSREV}
Index: devel/llvm/Makefile
===
RCS file: /home/cvs/ports/devel/llvm/Makefile,v
retrieving revision 1.277
diff -u -p -u -p -r1.277 Makefile
--- devel/llvm/Makefile 22 May 2021 20:27:35 - 1.277
+++ devel/llvm/Makefile 5 Jun 2021 03:32:12 -
@@ -112,11 +112,6 @@ CXXFLAGS+= -mno-retpoline
CXXFLAGS+= -fomit-frame-pointer
.endif
-.if ${MACHINE_ARCH} == "powerpc"
-CONFIGURE_ARGS += -DCMAKE_EXE_LINKER_FLAGS="-Wl,-relax"
-CONFIGURE_ARGS += -DCMAKE_SHARED_LINKER_FLAGS="-Wl,-relax"
-.endif
-
TEST_TARGET = check check-clang
# XXX sync
Index: games/godot/Makefile
===
RCS file: /home/cvs/ports/games/godot/Makefile,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 Makefile
--- games/godot/Makefile3 May 2021 19:10:24 - 1.18
+++ games/godot/Makefile5 Jun 2021 03:32:32 -
@@ -76,11 +76,6 @@ LDFLAGS += -latomic
WANTLIB += atomic
.endif
-# Fix relocation overflows
-.if ${MACHINE_ARCH:Mpowerpc}
-LDFLAGS += -Wl,--relax
-.endif
-
post-extract:
cp -R ${FILESDIR}/sndio ${WRKDIST}/drivers
Index: games/scummvm/Makefile
===
RCS file: /home/cvs/ports/games/scummvm/Makefile,v
retrieving revision 1.88
diff -u -p -u -p -r1.88 Makefile
--- games/scummvm/Makefile 4 Jan 2021 17:43:02 - 1.88
+++ games/scummvm/Makefile 5 Jun 2021 03:32:48 -
@@ -40,11 +40,6 @@ LIB_DEPENDS= audio/fluidsynth \
CXXFLAGS+= -mxgot
.endif
-# Fix relocation overflows
-.if ${MACHINE_ARCH} == "powerpc"
-LDFLAGS+= -Wl,--relax
-.endif
-
CONFIGURE_STYLE=simple
CONFIGURE_ARGS+=--disable-alsa \
--disable-cloud \
Index: lang/gcc/8/Makefile
===
RCS file: /home/cvs/ports/lang/gcc/8/Makefile,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 Makefile
--- lang/gcc/8/Makefile 9 Feb 2021
Re: Thread Local Storage in clang
On 5/28/2021 10:55 AM, Chris Cappuccio wrote: I tried to compile librdkafka on OpenBSD 6.5 (clang 7.0.1) and clang compiled the __thread parts with some built-in mechanism. I upgraded the system to OpenBSD 6.9 and TLS is no longer supported by the in-tree clang. Was this intended to be turned off? Did the 6.5 version even work? Is Thread Local Storage support in clang desired in general or no? Marc Espie's clang presentation from July 2017 mentions that we do and that Mark Kettenis helped make it happen. I'm having a hard time finding much other discussion either way. It wasn't turned off. I merged the relevant bits upstream for 5.0.0 and nothing has changed in this area since. Sounds like there is something wrong with your system.
Re: patch: add support for RTLD_NODELETE
Seeing your e-mail reminded me that I had asked Philip about adding
support for RTLD_NOLOAD / RTLD_NODELETE last year after seeing instances
of their usage in the tree here and there.
- Forwarded message from Philip Guenther -
Date: Thu, 24 Sep 2020 23:19:27 -0700
From: Philip Guenther
To: Brad Smith
Subject: Re: dlopen & RTLD_NOLOAD / RTLD_NODELETE
User-Agent: Alpine 2.21 (BSO 202 2017-01-01)
On Sat, 19 Sep 2020, Brad Smith wrote:
> On 8/31/2020 12:24 AM, Philip Guenther wrote:
> > On Sun, 30 Aug 2020, Brad Smith wrote:
> > > Is there any chance that OpenBSD's dlopen() could have support for
> > > RTLD_NOLOAD / RTLD_NODELETE added? Specifically RTLD_NOLOAD as I've had
> > > a patch in MariaDB for ages to allow building on OpenBSD.
> > Sigh. The hard part is writing the regress.
>
> Is that a no?
The noload bits are completely untested.
Index: include/dlfcn.h
===
RCS file: /data/src/openbsd/src/include/dlfcn.h,v
retrieving revision 1.14
diff -u -p -r1.14 dlfcn.h
--- include/dlfcn.h 28 Nov 2017 17:19:47 - 1.14
+++ include/dlfcn.h 31 Aug 2020 00:55:55 -
@@ -42,6 +42,8 @@
#define RTLD_GLOBAL0x100
#define RTLD_LOCAL 0x000
#define RTLD_TRACE 0x200
+#define RTLD_NODELETE 0x400
+#define RTLD_NOLOAD0x800
/*
* Special handle arguments for dlsym().
Index: libexec/ld.so/dlfcn.c
===
RCS file: /data/src/openbsd/src/libexec/ld.so/dlfcn.c,v
retrieving revision 1.106
diff -u -p -r1.106 dlfcn.c
--- libexec/ld.so/dlfcn.c 4 Oct 2019 17:42:16 - 1.106
+++ libexec/ld.so/dlfcn.c 1 Sep 2020 05:04:40 -
@@ -46,6 +46,15 @@ static int _dl_real_close(void *handle);
static lock_cb *_dl_thread_fnc = NULL;
static elf_object_t *obj_from_addr(const void *addr);
+#define OK_FLAGS (0 \
+ | RTLD_TRACE\
+ | RTLD_LAZY \
+ | RTLD_NOW \
+ | RTLD_GLOBAL \
+ | RTLD_NODELETE \
+ | RTLD_NOLOAD \
+ )
+
void *
dlopen(const char *libname, int flags)
{
@@ -54,7 +63,7 @@ dlopen(const char *libname, int flags)
int failed = 0;
int obj_flags;
- if (flags & ~(RTLD_TRACE|RTLD_LAZY|RTLD_NOW|RTLD_GLOBAL)) {
+ if (flags & ~OK_FLAGS) {
_dl_errno = DL_INVALID_MODE;
return NULL;
}
@@ -79,7 +88,10 @@ dlopen(const char *libname, int flags)
_dl_loading_object = NULL;
obj_flags = (flags & RTLD_NOW ? DF_1_NOW : 0)
- | (flags & RTLD_GLOBAL ? DF_1_GLOBAL : 0);
+ | (flags & RTLD_GLOBAL ? DF_1_GLOBAL : 0)
+ | (flags & RTLD_NODELETE ? DF_1_NODELETE : 0)
+ | (flags & RTLD_NOLOAD ? DF_1_NOOPEN : 0)
+ ;
object = _dl_load_shlib(libname, _dl_objects, OBJTYPE_DLO, obj_flags);
if (object == 0) {
DL_DEB(("dlopen: failed to open %s\n", libname));
@@ -93,6 +105,10 @@ dlopen(const char *libname, int flags)
/* if opened but grpsym_vec has not been filled in */
if (object->grpsym_vec.len == 0)
_dl_cache_grpsym_list_setup(object);
+ if (flags & RTLD_NODELETE) {
+ object->obj_flags |= DF_1_NODELETE;
+ _dl_handle_nodelete(object);
+ }
goto loaded;
}
Index: libexec/ld.so/library.c
===
RCS file: /data/src/openbsd/src/libexec/ld.so/library.c,v
retrieving revision 1.85
diff -u -p -r1.85 library.c
--- libexec/ld.so/library.c 9 Dec 2019 22:15:15 - 1.85
+++ libexec/ld.so/library.c 31 Aug 2020 01:36:06 -
@@ -127,17 +127,14 @@ _dl_tryload_shlib(const char *libname, i
for (object = _dl_objects; object != NULL; object = object->next) {
if (object->dev == sb.st_dev &&
object->inode == sb.st_ino) {
- object->obj_flags |= flags & DF_1_GLOBAL;
_dl_close(libfile);
- if (_dl_loading_object == NULL)
- _dl_loading_object = object;
- if (object->load_object != _dl_objects &&
- object->load_object != _dl_loading_object) {
- _dl_link_grpref(object->load_object,
- _dl_loading_object);
- }
+ _dl_handle_already_loaded(object, flags);
return(object);
}
+ }
+ if (flags & DF_1_NOOPEN) {
+ _dl_close(libfile);
+ return NULL;
}
_dl_read(libfile, hbuf, sizeof(hbuf));
Index: libexec/ld.so/library_mquery.
Recognize bge(4) BCM57766 revs
Recognize bge(4) BCM5776 revs of chips..
unknown BCM57766 (0x57766000)
unknown BCM57766 (0x57766001)
Index: if_bge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.393
diff -u -p -u -p -r1.393 if_bge.c
--- if_bge.c12 Dec 2020 11:48:52 - 1.393
+++ if_bge.c24 Feb 2021 05:12:56 -
@@ -403,6 +403,8 @@ static const struct bge_revision {
{ BGE_CHIPID_BCM5906_A2, "BCM5906 A2" },
{ BGE_CHIPID_BCM57765_A0, "BCM57765 A0" },
{ BGE_CHIPID_BCM57765_B0, "BCM57765 B0" },
+ { BGE_CHIPID_BCM57766_A0, "BCM57766 A0" },
+ { BGE_CHIPID_BCM57766_A1, "BCM57766 A1" },
{ BGE_CHIPID_BCM57780_A0, "BCM57780 A0" },
{ BGE_CHIPID_BCM57780_A1, "BCM57780 A1" },
Index: if_bgereg.h
===
RCS file: /home/cvs/src/sys/dev/pci/if_bgereg.h,v
retrieving revision 1.131
diff -u -p -u -p -r1.131 if_bgereg.h
--- if_bgereg.h 18 Jun 2020 17:13:32 - 1.131
+++ if_bgereg.h 24 Feb 2021 05:13:38 -
@@ -310,6 +310,8 @@
#defineBGE_CHIPID_BCM5762_A0 0x05762000
#defineBGE_CHIPID_BCM57765_A0 0x57785000
#defineBGE_CHIPID_BCM57765_B0 0x57785100
+#defineBGE_CHIPID_BCM57766_A0 0x57766000
+#defineBGE_CHIPID_BCM57766_A1 0x57766001
/* shorthand one */
#defineBGE_ASICREV(x) ((x) >> 12)
Clang floating-point alignment on powerpc
It looks like after this went in which is included with 10 that this local
diff can be removed..
https://reviews.llvm.org/D71954
[PowerPC] Change default for unaligned FP access for older subtargets
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40554
Some CPU's trap to the kernel on unaligned floating point access and there are
kernels that do not handle the interrupt. The program then fails with a SIGBUS
according to the PR. This just switches the default for unaligned access to only
allow it on recent server CPUs that are known to allow this.
Index: llvm/lib/Target/PowerPC/PPCISelLowering.cpp
===
RCS file: /home/cvs/src/gnu/llvm/llvm/lib/Target/PowerPC/PPCISelLowering.cpp,v
retrieving revision 1.1.1.2
diff -u -p -u -p -r1.1.1.2 PPCISelLowering.cpp
--- llvm/lib/Target/PowerPC/PPCISelLowering.cpp 9 Aug 2020 15:50:15 -
1.1.1.2
+++ llvm/lib/Target/PowerPC/PPCISelLowering.cpp 11 Aug 2020 07:39:07 -
@@ -15299,14 +15299,6 @@ bool PPCTargetLowering::allowsMisaligned
if (VT == MVT::ppcf128)
return false;
- if (Subtarget.isTargetOpenBSD()) {
-// Traditional PowerPC does not support unaligned memory access
-// for floating-point and the OpenBSD kernel does not emulate
-// all possible floating-point load and store instructions.
-if (VT == MVT::f32 || VT == MVT::f64)
- return false;
- }
-
if (Fast)
*Fast = true;
Index: llvm/lib/Target/PowerPC/PPCSubtarget.h
===
RCS file: /home/cvs/src/gnu/llvm/llvm/lib/Target/PowerPC/PPCSubtarget.h,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 PPCSubtarget.h
--- llvm/lib/Target/PowerPC/PPCSubtarget.h 3 Aug 2020 14:30:25 -
1.1.1.1
+++ llvm/lib/Target/PowerPC/PPCSubtarget.h 11 Aug 2020 07:38:26 -
@@ -320,7 +320,6 @@ public:
bool isTargetELF() const { return TargetTriple.isOSBinFormatELF(); }
bool isTargetMachO() const { return TargetTriple.isOSBinFormatMachO(); }
bool isTargetLinux() const { return TargetTriple.isOSLinux(); }
- bool isTargetOpenBSD() const { return TargetTriple.isOSOpenBSD(); }
bool isDarwinABI() const { return isTargetMachO() || isDarwin(); }
bool isAIXABI() const { return TargetTriple.isOSAIX(); }
[Patch]: VA-API integration with xenocara
This is a rather large patch that moves my previously submitted VA-API ports into xenocara. For your convenience, I've inlined a diff that shows you all of the changes I made to existing files that you can easily read in your MUA. The xenocara patch also contains these changes and should be the only xenocara patch you need to apply. The patch to BSD.x11.dist is inlined in this email alone. I tried sending this email yesterday with the gzipped xenocara patch as an attachment, but it was apparently rejected from the mailing list. I've used xz to compress it instead and uploaded it to my google drive. Here is a link to download it instead: https://drive.google.com/open?id=1_Jwd08vteJzM0mm4sXI_zjAq2pNj3yIK Summary of Changes: - libva added to xenocara/lib/libva - vainfo added to xenocara/app/vainfo - intel-vaapi-driver added to xenocara/driver/intel-vaapi-driver - Mesa Makefile.bsd-wrapper updated to build with --enable-va flag - 3RDPARTY file updated to include libva, libva-utils, and intel-vaapi-driver - BSD.x11.dist updated to include /usr/X11R6/include/va/ (patch inlined here) Architectures Tested: amd64 Testing Instructions: 1. pkg_add xz 1. save xenocara-vaapi.patch.xz to /tmp 2. xz -d /tmp/xenocara-vaapi.patch.xz 3. cd /usr/xenocara 4. patch -p0 < /tmp/xenocara-vaapi.patch 5. Follow normal build instructions in README within the root of xenocara 6. Run vainfo. It should report available profiles and entrypoints for VA-API. Example of successful execution: libva info: VA-API version 1.6.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/X11R6/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_6 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.6 (libva 2.6.0.pre1) vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.4.0 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Simple: VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : VAEntrypointEncSliceLP VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileVP9Profile0: VAEntrypointVLD VAProfileVP9Profile0: VAEntrypointEncSlice VAProfileVP9Profile2: VAEntrypointVLD Inline diff for BSD.x11.dist: Index: BSD.x11.dist === RCS file: /cvs/src/etc/mtree/BSD.x11.dist,v retrieving revision 1.54 diff -u -p -u -p -r1.54 BSD.x11.dist --- BSD.x11.dist27 May 2019 07:03:11 - 1.54 +++ BSD.x11.dist18 Dec 2019 18:23:46 - @@ -87,6 +87,8 @@ .. pixman-1 .. +va +.. vulkan .. xcb List of existing xenocara files that have changed: brad-laptop$ grep -E '^Index: ' xenocara-vaapi.patch | grep -v 'app/vainfo' | grep -v 'lib/libva' | grep -v 'driver/intel-vaapi-driver' Index: 3RDPARTY Index: app/Makefile Index: driver/Makefile Index: lib/Makefile Index: lib/mesa/Makefile.bsd-wrapper Inline diffs for these files: Index: 3RDPARTY === RCS file: /cvs/xenocara/3RDPARTY,v retrieving revision 1.354 diff -u -p -u -p -r1.354 3RDPARTY --- 3RDPARTY12 Dec 2019 06:08:12 - 1.354 +++ 3RDPARTY18 Dec 2019 19:32:09 - @@ -1,5 +1,17 @@ # $OpenBSD: 3RDPARTY,v 1.354 2019/12/12 06:08:12 matthieu
Question(s) about HID devices
I'm trying to add support for Xbox One Controllers to OpenBSD.
It looks as though I can fairly easily get the device to attach as a uhid
device, but I believe the device requires some special initialization data
sent to it before it will actually begin functioning.
That being said, I'm pretty sure that the answer is not to continue adding
special cases within uhidev.c - it feels weird already that there is Xbox
360 controller code inside there to me, to be honest.
My question is this: If I create a new driver that attaches after uhidev,
will software expecting a standard HID gamepad work, or will they not work
because they haven't been taught about my new, special driver?
If a new driver isn't the answer, and it must remain a uhidev device - is
there a standard approach to something like this? Should I just break out
the Xbox Controller code into a new file and call out to it from the
uhidev.{match,attach,detach,etc..}?
Should Gamepads be exposed via wsmux like keyboards and mice instead?
Thanks,
netstart diff for aggr(4) handling
Shouldn't aggr(4) be handled in the same manner as trunk(4)? Index: netstart === RCS file: /home/cvs/src/etc/netstart,v retrieving revision 1.200 diff -u -p -u -p -r1.200 netstart --- netstart29 Aug 2018 11:30:48 - 1.200 +++ netstart17 Oct 2019 20:45:29 - @@ -300,12 +300,12 @@ vifscreate # Configure all the non-loopback interfaces which we know about, but # do not start interfaces which must be delayed. Refer to hostname.if(5) -ifmstart "" "trunk svlan vlan carp pppoe tun tap gif etherip gre egre mobileip pflow" +ifmstart "" "aggr trunk svlan vlan carp pppoe tun tap gif etherip gre egre mobileip pflow" # The trunk interfaces need to come up first in this list. # The (s)vlan interfaces need to come up after trunk. # Configure all the carp interfaces which we know about before default route. -ifmstart "trunk svlan vlan carp pppoe" +ifmstart "aggr trunk svlan vlan carp pppoe" # Set default routes for IPv4 and IPv6. defaultroute
66.html diff - Use MACHINE_ARCH consistently
Fix the release notes to use MACHINE_ARCH consistently instead of some random MACHINE mixed in. Index: 66.html === RCS file: /home/cvs/www/66.html,v retrieving revision 1.49 diff -u -p -u -p -r1.49 66.html --- 66.html 6 Oct 2019 01:13:44 - 1.49 +++ 66.html 17 Oct 2019 20:41:53 - @@ -81,14 +81,14 @@ to 6.6. Fixed support for amd64 machines with greater than 1023GB physical memory. https://man.openbsd.org/drm.4;>drm(4) updates. -The octeon platform is now using +The mips64 architecture is now using https://man.openbsd.org/clang-local.1;>clang(1) as the base system compiler. The powerpc architecture is now provided with https://man.openbsd.org/clang.1;>clang(1), in - addition to aarch64, amd64, armv7, i386, mips64el, sparc64. + addition to aarch64, amd64, arm, i386, mips64el, sparc64. Disabled https://man.openbsd.org/gcc.1;>gcc in - base on armv7 and i386. + base on arm and i386. Prevented https://man.openbsd.org/dhclient.8;>dhclient(8) from repeatedly obtaining a new lease when the mtu is given in a lease.
alc(4): formatting fixes
Various formatting fixes for alc(4).
Index: if_alc.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_alc.c,v
retrieving revision 1.48
diff -u -p -u -p -r1.48 if_alc.c
--- if_alc.c6 May 2019 07:44:00 - 1.48
+++ if_alc.c20 May 2019 22:56:31 -
@@ -297,6 +297,7 @@ alc_mii_writereg_816x(struct device *dev
if ((v & MDIO_OP_BUSY) == 0)
break;
}
+
if (i == 0)
printf("%s: phy write timeout: phy %d, reg %d\n",
sc->sc_dev.dv_xname, phy, reg);
@@ -342,7 +343,6 @@ alc_miibus_statchg(struct device *dev)
reg |= MAC_CFG_TX_ENB | MAC_CFG_RX_ENB;
CSR_WRITE_4(sc, ALC_MAC_CFG, reg);
}
-
alc_aspm(sc, 0, IFM_SUBTYPE(mii->mii_media_active));
alc_dsp_fixup(sc, IFM_SUBTYPE(mii->mii_media_active));
}
@@ -397,14 +397,14 @@ alc_miiext_writereg(struct alc_softc *sc
int i;
CSR_WRITE_4(sc, ALC_EXT_MDIO, EXT_MDIO_REG(reg) |
- EXT_MDIO_DEVADDR(devaddr));
+ EXT_MDIO_DEVADDR(devaddr));
if ((sc->alc_flags & ALC_FLAG_LINK) != 0)
clk = MDIO_CLK_25_128;
else
clk = MDIO_CLK_25_4;
CSR_WRITE_4(sc, ALC_MDIO, MDIO_OP_EXECUTE | MDIO_OP_WRITE |
- ((val & MDIO_DATA_MASK) << MDIO_DATA_SHIFT) |
- MDIO_SUP_PREAMBLE | clk | MDIO_MODE_EXT);
+ ((val & MDIO_DATA_MASK) << MDIO_DATA_SHIFT) |
+ MDIO_SUP_PREAMBLE | clk | MDIO_MODE_EXT);
for (i = ALC_PHY_TIMEOUT; i > 0; i--) {
DELAY(5);
v = CSR_READ_4(sc, ALC_MDIO);
@@ -662,7 +662,7 @@ alc_get_macaddr_816x(struct alc_softc *s
if (reloaded == 0) {
reg = CSR_READ_4(sc, ALC_EEPROM_LD);
if ((reg & (EEPROM_LD_EEPROM_EXIST |
- EEPROM_LD_FLASH_EXIST)) != 0) {
+ EEPROM_LD_FLASH_EXIST)) != 0) {
for (i = 100; i > 0; i--) {
reg = CSR_READ_4(sc, ALC_EEPROM_LD);
if ((reg & (EEPROM_LD_PROGRESS |
@@ -672,7 +672,7 @@ alc_get_macaddr_816x(struct alc_softc *s
}
if (i != 0) {
CSR_WRITE_4(sc, ALC_EEPROM_LD, reg |
- EEPROM_LD_START);
+ EEPROM_LD_START);
for (i = 100; i > 0; i--) {
DELAY(1000);
reg = CSR_READ_4(sc, ALC_EEPROM_LD);
@@ -710,10 +710,10 @@ alc_disable_l0s_l1(struct alc_softc *sc)
/* Another magic from vendor. */
pmcfg = CSR_READ_4(sc, ALC_PM_CFG);
pmcfg &= ~(PM_CFG_L1_ENTRY_TIMER_MASK | PM_CFG_CLK_SWH_L1 |
- PM_CFG_ASPM_L0S_ENB | PM_CFG_ASPM_L1_ENB |
PM_CFG_MAC_ASPM_CHK |
- PM_CFG_SERDES_PD_EX_L1);
- pmcfg |= PM_CFG_SERDES_BUDS_RX_L1_ENB |
PM_CFG_SERDES_PLL_L1_ENB |
- PM_CFG_SERDES_L1_ENB;
+ PM_CFG_ASPM_L0S_ENB | PM_CFG_ASPM_L1_ENB |
+ PM_CFG_MAC_ASPM_CHK | PM_CFG_SERDES_PD_EX_L1);
+ pmcfg |= PM_CFG_SERDES_BUDS_RX_L1_ENB |
+ PM_CFG_SERDES_PLL_L1_ENB | PM_CFG_SERDES_L1_ENB;
CSR_WRITE_4(sc, ALC_PM_CFG, pmcfg);
}
}
@@ -1059,9 +1059,9 @@ alc_aspm_816x(struct alc_softc *sc, int
PM_CFG_MAC_ASPM_CHK | PM_CFG_HOTRST);
if (AR816X_REV(sc->alc_rev) <= AR816X_REV_A1 &&
(sc->alc_rev & 0x01) != 0)
- pmcfg |= PM_CFG_SERDES_L1_ENB | PM_CFG_SERDES_PLL_L1_ENB;
+ pmcfg |= PM_CFG_SERDES_L1_ENB | PM_CFG_SERDES_PLL_L1_ENB;
if ((sc->alc_flags & ALC_FLAG_LINK) != 0) {
- /* Link up, enable both L0s, L1s. */
+ /* Link up, enable both L0s, L1s. */
pmcfg |= PM_CFG_ASPM_L0S_ENB | PM_CFG_ASPM_L1_ENB |
PM_CFG_MAC_ASPM_CHK;
} else {
@@ -1085,14 +1085,15 @@ alc_init_pcie(struct alc_softc *sc, int
val = CSR_READ_4(sc, ALC_PEX_UNC_ERR_SEV);
val &= ~(PEX_UNC_ERR_SEV_DLP | PEX_UNC_ERR_SEV_FCP);
CSR_WRITE_4(sc, ALC_PEX_UNC_ERR_SEV, val);
+
if ((sc->alc_flags & ALC_FLAG_AR816X_FAMILY) == 0) {
CSR_WRITE_4(sc, ALC_LTSSM_ID_CFG,
- CSR_READ_4(sc, ALC_LTSSM_ID_CFG) & ~LTSSM_ID_WRO_ENB);
+ CSR_READ_4(sc, ALC_LTSSM_ID_CFG) & ~LTSSM_ID_WRO_ENB);
CSR_WRITE_4(sc, ALC_PCIE_PHYMISC,
- CSR_READ_4(sc, ALC_PCIE_PHYMISC) |
- PCIE_PHYMISC_FORCE_RCV_DET);
- if (sc->sc_product == PCI_PRODUCT_ATTANSIC_L2C_1 &&
- sc->alc_rev == ATHEROS_AR8152_B_V10) {
+ CSR_READ_4(sc, ALC_PCIE_PHYMISC) |
+
jme(4): jme_start() use JME_MAXTXSEGS when checking available TX descs
jme_start() should be checking if JME_MAXTXSEGS TX descs are available
instead of just the 1 reserved descriptor (JME_TXD_RSVD).
Index: if_jme.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_jme.c,v
retrieving revision 1.51
diff -u -p -u -p -r1.51 if_jme.c
--- if_jme.c29 Mar 2019 17:25:44 - 1.51
+++ if_jme.c14 Apr 2019 17:44:12 -
@@ -1213,7 +1213,7 @@ jme_start(struct ifnet *ifp)
* Check number of available TX descs, always
* leave JME_TXD_RSVD free TX descs.
*/
- if (sc->jme_cdata.jme_tx_cnt + JME_TXD_RSVD >
+ if (sc->jme_cdata.jme_tx_cnt + JME_MAXTXSEGS + JME_TXD_RSVD >=
JME_TX_RING_CNT - JME_TXD_RSVD) {
ifq_set_oactive(>if_snd);
break;
Re: ftp(1) rewrite
On 06/01/15 18:29, Stuart Henderson wrote: On 2015/06/02 00:09, Dmitrij D. Czarkoff wrote: Ted Unangst said: Stuart Henderson wrote: Sorry, it's not good enough to replace ftp(1) for system use without ftp. Like it or not, ports fetches need FTP and can't really rely on installing something for ports to do that. It's not obvious to me why this would be the case. The ports tree already depends on various external programs to extract xz, cab, etc. Fetching files happens really early, before dependencies are processed. And the program used to fetch is meant to be user-overridable. One important thing is missing from this discussion: what exactly is wrong with ftp(1)? The code isto put it nicelyrather dated ;-) Ever run into the fact that ftp(1) can get stuck during certain operations if you hit Ctrl-C and you have to kill -9 the process? That is absolutely ridiculous. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Patch to OpenSSL 014 patch
Here's one other small error in another patch file. This patch is here:
http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/014_openssl.patch
rbt@teal:~/Downloads$ diff -u 014_openssl.patch 014_openssl.patch.rbt
--- 014_openssl.patch 2015-03-26 14:04:15.316496714 -0400
+++ 014_openssl.patch.rbt 2015-03-26 14:05:57.456498632 -0400
@@ -6,7 +6,7 @@
Apply patch using:
-cat 014_openssl.patch.sig | (cd /usr/src patch -p0)
+cat 014_openssl.patch | (cd /usr/src patch -p0)
Then build and install libcrypto and libssl
Thanks,
Brad
OpenBSD 5.4 errata 14, August 9, 2014:
This patch contains backported fixes for OpenSSL issues.
Refer to https://www.openssl.org/news/secadv_20140806.txt
Apply patch using:
cat 014_openssl.patch.sig | (cd /usr/src patch -p0)
Then build and install libcrypto and libssl
cd /usr/src/lib/libssl/crypto
make obj
make
make install
cd /usr/src/lib/libssl/ssl
make obj
make
make install
Then restart services which depend on OpenSSL.
Index: lib/libssl/src/crypto/asn1/a_object.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_object.c,v
retrieving revision 1.9
diff -u -p -r1.9 a_object.c
--- lib/libssl/src/crypto/asn1/a_object.c 3 Nov 2011 02:34:32 - 1.9
+++ lib/libssl/src/crypto/asn1/a_object.c 8 Aug 2014 14:02:03 -
@@ -283,17 +283,29 @@ err:
ASN1err(ASN1_F_D2I_ASN1_OBJECT,i);
return(NULL);
}
+
ASN1_OBJECT *c2i_ASN1_OBJECT(ASN1_OBJECT **a, const unsigned char **pp,
long len)
{
ASN1_OBJECT *ret=NULL;
const unsigned char *p;
unsigned char *data;
- int i;
- /* Sanity check OID encoding: can't have leading 0x80 in
- * subidentifiers, see: X.690 8.19.2
+ int i, length;
+
+ /* Sanity check OID encoding.
+ * Need at least one content octet.
+ * MSB must be clear in the last octet.
+ * can't have leading 0x80 in subidentifiers, see: X.690 8.19.2
*/
- for (i = 0, p = *pp; i len; i++, p++)
+ if (len = 0 || len INT_MAX || pp == NULL || (p = *pp) == NULL ||
+ p[len - 1] 0x80)
+ {
+ ASN1err(ASN1_F_C2I_ASN1_OBJECT,ASN1_R_INVALID_OBJECT_ENCODING);
+ return NULL;
+ }
+ /* Now 0 len = INT_MAX, so the cast is safe. */
+ length = (int)len;
+ for (i = 0; i length; i++, p++)
{
if (*p == 0x80 (!i || !(p[-1] 0x80)))
{
@@ -316,23 +328,23 @@ ASN1_OBJECT *c2i_ASN1_OBJECT(ASN1_OBJECT
data = (unsigned char *)ret-data;
ret-data = NULL;
/* once detached we can change it */
- if ((data == NULL) || (ret-length len))
+ if ((data == NULL) || (ret-length length))
{
ret-length=0;
if (data != NULL) OPENSSL_free(data);
- data=(unsigned char *)OPENSSL_malloc(len ? (int)len : 1);
+ data=(unsigned char *)OPENSSL_malloc(length);
if (data == NULL)
{ i=ERR_R_MALLOC_FAILURE; goto err; }
ret-flags|=ASN1_OBJECT_FLAG_DYNAMIC_DATA;
}
- memcpy(data,p,(int)len);
+ memcpy(data,p,length);
/* reattach data to object, after which it remains const */
ret-data =data;
- ret-length=(int)len;
+ ret-length=length;
ret-sn=NULL;
ret-ln=NULL;
/* ret-flags=ASN1_OBJECT_FLAG_DYNAMIC; we know it is dynamic */
- p+=len;
+ p+=length;
if (a != NULL) (*a)=ret;
*pp=p;
Index: lib/libssl/src/crypto/ec/ec_lib.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/ec/ec_lib.c,v
retrieving revision 1.6
diff -u -p -r1.6 ec_lib.c
--- lib/libssl/src/crypto/ec/ec_lib.c 13 Oct 2012 21:25:13 - 1.6
+++ lib/libssl/src/crypto/ec/ec_lib.c 8 Aug 2014 14:02:03 -
@@ -942,7 +942,7 @@ int EC_POINT_dbl(const EC_GROUP *group,
int EC_POINT_invert(const EC_GROUP *group, EC_POINT *a, BN_CTX *ctx)
{
- if (group-meth-dbl == 0)
+ if (group-meth-invert == 0)
{
ECerr(EC_F_EC_POINT_INVERT, ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED);
return 0;
Index: lib/libssl/src/crypto/ec/ecp_smpl.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/ec/ecp_smpl.c,v
retrieving revision 1.5
diff -u -p -r1.5 ecp_smpl.c
--- lib/libssl/src/crypto/ec/ecp_smpl.c 13 Oct 2012 21:25:13 - 1.5
+++ lib/libssl/src/crypto/ec/ecp_smpl.c 8 Aug 2014 14:02:03 -
@@ -1181,9 +1181,8 @@ int ec_GFp_simple_make_affine(const EC_G
int ec_GFp_simple_points_make_affine(const EC_GROUP *group, size_t num, EC_POINT *points[], BN_CTX *ctx)
{
BN_CTX *new_ctx = NULL;
- BIGNUM *tmp0, *tmp1;
- size_t pow2 = 0;
- BIGNUM **heap = NULL;
+ BIGNUM *tmp, *tmp_Z;
+ BIGNUM **prod_Z = NULL;
size_t i;
int ret = 0;
@@ -1198,124 +1197,104 @@ int ec_GFp_simple_points_make_affine(con
}
BN_CTX_start(ctx);
- tmp0 = BN_CTX_get(ctx);
- tmp1 = BN_CTX_get(ctx);
- if (tmp0 == NULL || tmp1 == NULL) goto err;
-
- /* Before converting the individual points, compute inverses of all Z values.
- * Modular inversion is rather slow, but luckily we can do with a single
- * explicit inversion, plus about 3 multiplications per input value.
- */
-
- pow2 = 1;
- while (num pow2)
- pow2 = 1
Small patch to 5.4 OpenSSL patch
Hey tech,
This is a patch for:
http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/016_openssl.patch
The closing parenthesis was left off.
Thanks,
Brad
rbt@teal:~/Downloads$ cat openbsd_5.4_016_openssl.patch
--- 016_openssl.patch 2015-03-26 13:48:44.776479245 -0400
+++ 016_openssl.patch.rbt 2015-03-26 13:49:38.800480259 -0400
@@ -5,7 +5,7 @@
Apply patch using:
- cat 016_openssl.patch | (cd /usr/src patch -p0
+ cat 016_openssl.patch | (cd /usr/src patch -p0)
Then build and install libssl
OpenBSD 5.4 errata 16, Oct 20, 2014
Two remotely triggerable memory leaks in OpenSSL can lead to a denial of
service in server applications.
Apply patch using:
cat 016_openssl.patch | (cd /usr/src patch -p0
Then build and install libssl
cd /usr/src/lib/libssl/ssl
make obj
make
make install
Index: lib/libssl/src/ssl/d1_srtp.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/d1_srtp.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 d1_srtp.c
--- lib/libssl/src/ssl/d1_srtp.c 13 Oct 2012 21:23:49 - 1.1.1.1
+++ lib/libssl/src/ssl/d1_srtp.c 17 Oct 2014 19:57:51 -
@@ -213,6 +213,7 @@ static int ssl_ctx_make_profiles(const c
else
{
SSLerr(SSL_F_SSL_CTX_MAKE_PROFILES,SSL_R_SRTP_UNKNOWN_PROTECTION_PROFILE);
+ sk_SRTP_PROTECTION_PROFILE_free(profiles);
return 1;
}
Index: lib/libssl/src/ssl/t1_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/t1_lib.c,v
retrieving revision 1.12.8.2
diff -u -p -r1.12.8.2 t1_lib.c
--- lib/libssl/src/ssl/t1_lib.c 9 Aug 2014 16:54:58 - 1.12.8.2
+++ lib/libssl/src/ssl/t1_lib.c 17 Oct 2014 19:56:17 -
@@ -2188,8 +2188,10 @@ static int tls_decrypt_ticket(SSL *s, co
HMAC_Update(hctx, etick, eticklen);
HMAC_Final(hctx, tick_hmac, NULL);
HMAC_CTX_cleanup(hctx);
- if (timingsafe_bcmp(tick_hmac, etick + eticklen, mlen))
+ if (timingsafe_bcmp(tick_hmac, etick + eticklen, mlen)) {
+ EVP_CIPHER_CTX_cleanup(ctx);
return 2;
+ }
/* Attempt to decrypt session data */
/* Move p after IV to start of encrypted ticket, update length */
p = etick + 16 + EVP_CIPHER_CTX_iv_length(ctx);
016_openssl.patch.rbt
Description: Binary data
--- 016_openssl.patch 2015-03-26 13:48:44.776479245 -0400
+++ 016_openssl.patch.rbt 2015-03-26 13:49:38.800480259 -0400
@@ -5,7 +5,7 @@
Apply patch using:
- cat 016_openssl.patch | (cd /usr/src patch -p0
+ cat 016_openssl.patch | (cd /usr/src patch -p0)
Then build and install libssl
Re: iwm(4): fix multicast receive
On 02/19/15 12:01, Stefan Sperling wrote: This fixes IPv6 autoconf over iwm for me. iwm users please test. Does the trick for me. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: LibreSSL Windows port status update
On 12/01/14 01:10, Dongsheng Song wrote: Cool ! I can see you do lot's of update on select-poll conversions. The code become more and more complex since you want it works more general. Can we use simply WSAPoll[1] instead ? -- #ifdef _WIN32 #define poll WSAPoll #endif -- [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms741669%28v=vs.85%29.aspx There is a URL posted at the bottom of that page that points out how it is broken and should not be used. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Unbound 1.5.0
So Unbound 1.5.0 has been released.. http://comstyle.com/unbound/unbound.tar.gz Just looking for some testing of what I have preped for import. I have provided a tarball instead of a diff because of some dir additions. Any other testers? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Missing include in sys/ipc.h
On 09/20/14 15:34, Philip Guenther wrote: On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sat, 20 Sep 2014 18:15:31 + From: Miod Vallat m...@online.fr shmctl(2)/shmget(2)/shmat(2) all document #include sys/types.h #include sys/ipc.h #include sys/shm.h as a requirement for calling these functions. That was my first thought, but according to http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_ipc.h.html ``The sys/ipc.h header shall define the uid_t, gid_t, mode_t and key_t types as described in sys/types.h'', which is currently not the case. Unfortunately it doesn't allow us to make everything in sys/types.h available though. So simply including sys/types.h from sys/ipc.h isn't the right solution. No, it does permit us to just #include sys/types.h, because POSIX reserves the *_t namespace in all its headers, and that's all that sys/types.h exports. We've tried to do more minimal #including/exporting generally, but SysV IPC is enough of a corner that just pulling in sys/types.h from sys/ipc.h is fine by me. ping. Discussion died out. Can we please move this issue forward? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: em(4) fix for Intel I218 chip
On 12/10/14 3:53 PM, Claudio Jeker wrote: This seems to be enough to help em(4) in modern laptops like the X240 to no longer generate watchdog timeouts on high throughput. This should only affect I218 but tests on different em(4) devices would not hurt. Chunk #3 is within the ICH8/IGP3 workaround, that shouldn't be changed like that. But the rest works for the i218. I can now actually use the Ethernet interface on my T440s. It was too unreliable under more or less any load. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: em(4) fix for Intel I218 chip
On 13/10/14 5:09 PM, Claudio Jeker wrote: On Mon, Oct 13, 2014 at 01:50:45PM -0400, Brad wrote: On 12/10/14 3:53 PM, Claudio Jeker wrote: This seems to be enough to help em(4) in modern laptops like the X240 to no longer generate watchdog timeouts on high throughput. This should only affect I218 but tests on different em(4) devices would not hurt. Chunk #3 is within the ICH8/IGP3 workaround, that shouldn't be changed like that. But the rest works for the i218. I can now actually use the Ethernet interface on my T440s. It was too unreliable under more or less any load. Yeah, but that chunk should be commited no the less. The FreeBSD version does not have the duplicated line and it seems like a bad merge to me. But that is not how the code is in the FreeBSD driver and does not match the behavior used everywhere else in the driver as is. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: pppoe(4), add example for ipv6
On 07/10/14 10:03 PM, Stuart Henderson wrote: Since it's non-obvious how to setup pppoe for v6 now that link-local addresses are no longer configured by default, I think we should have something in the manual. Any comments/objections/suggestions for a better way to do this? This doesn't make any sense. IPv6CP configures the link local address. Having to do something like this is illogical and counter intuitive. I agree it should be documented per se but the current behavior is just plain stupid. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: call for testing: MSI for msk(4)
On 31/12/13 12:06 AM, Brad Smith wrote: On 16/05/13 5:55 PM, Jérémie Courrèges-Anglas wrote: Hi, I've been using msk(4) with MSI on my laptop since a few days, with no apparent problem. mskc0 at pci2 dev 0 function 0 Marvell Yukon 88E8040 rev 0x13, Yukon-2 FE+ rev. A0 (0x0): msi msk0 at mskc0 port A: address 00:24:54:xx:xx:xx eephy0 at msk0 phy 0: 88E3016 10/100 PHY, rev. 0 Other systems all seem to use MSI, but it would be cool if people with different chips could test it. Any other msk(4) users? It has also been tested with EC 8052/EC Ultra 8058 controllers and working. I don't see any indication of any issues or errata regarding MSI operation in either of the FreeBSD or Linux drivers. Fast Ethernet controller.. mskc0 at pci3 dev 0 function 0 Marvell Yukon 88E8036 rev 0x16, Yukon-2 FE rev. A1 (0x1): msi msk0 at mskc0 port A: address 00:13:a9:fa:5a:52 eephy0 at msk0 phy 0: 88E3082 10/100 PHY, rev. 3 Gigabit controllers.. mskc0 at pci3 dev 0 function 0 Marvell Yukon 88E8058 rev 0x13, Yukon-2 EC Ultra rev. B0 (0x3): msi msk0 at mskc0 port A: address 00:1b:63:ad:0b:ee eephy0 at msk0 phy 0: 88E1149 Gigabit PHY, rev. 1 mskc0 at pci2 dev 0 function 0 Marvell Yukon 88E8053 rev 0x20, Yukon-2 EC rev. A3 (0x2): msi msk0 at mskc0 port A: address 00:50:43:00:7b:46 eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 mskc0 at pci3 dev 0 function 0 Marvell Yukon 88E8052 rev 0x21, Yukon-2 EC rev. A3 (0x2): msi msk0 at mskc0 port A: address 00:18:f3:6c:44:da eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 At this point I'd like to see this commited for wider spread testng and if anything does come up as usual it can be reverted. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
re(4): Don't allow reception of jumbo frames with chips that cannot support it
At the moment our re(4) driver will allow the reception of Jumbo frames
with chips that don't have support in the driver. Although I haven't
been able to reproduce this in theory it could be possible to cause
the kernel to crash with such hardware under the right conditions.
OK?
Index: re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.149
diff -u -p -u -p -r1.149 re.c
--- re.c13 Mar 2014 13:11:30 - 1.149
+++ re.c19 Mar 2014 16:36:20 -
@@ -1900,8 +1919,12 @@ re_init(struct ifnet *ifp)
* For 8169 gigE NICs, set the max allowed RX packet
* size so we can receive jumbo frames.
*/
- if (sc-sc_hwrev != RL_HWREV_8139CPLUS)
- CSR_WRITE_2(sc, RL_MAXRXPKTLEN, 16383);
+ if (sc-sc_hwrev != RL_HWREV_8139CPLUS) {
+ if (sc-rl_flags RL_FLAG_PCIE)
+ CSR_WRITE_2(sc, RL_MAXRXPKTLEN, RE_RX_DESC_BUFLEN);
+ else
+ CSR_WRITE_2(sc, RL_MAXRXPKTLEN, 16383);
+ }
mii_mediachg(sc-sc_mii);
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
dc(4): Remove redundant dc_stop / dc_reset calls
Remove redundant dc_stop() / dc_reset() calls from dc_intr() and dc_watchdog()
which dc_init() already takes care of.
OK?
Index: ic/dc.c
===
RCS file: /home/cvs/src/sys/dev/ic/dc.c,v
retrieving revision 1.134
diff -u -p -u -p -r1.134 dc.c
--- ic/dc.c 22 Jul 2014 13:12:11 - 1.134
+++ ic/dc.c 9 Sep 2014 16:54:03 -
@@ -2481,10 +2481,8 @@ dc_intr(void *arg)
}
}
- if (status DC_ISR_BUS_ERR) {
- dc_reset(sc);
+ if (status DC_ISR_BUS_ERR)
dc_init(sc);
- }
}
/* Re-enable interrupts. */
@@ -2986,8 +2984,6 @@ dc_watchdog(struct ifnet *ifp)
ifp-if_oerrors++;
printf(%s: watchdog timeout\n, sc-sc_dev.dv_xname);
- dc_stop(sc, 0);
- dc_reset(sc);
dc_init(sc);
if (IFQ_IS_EMPTY(ifp-if_snd) == 0)
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: sparc64: fledgling QEMU support
On 09/09/14 2:20 PM, Mark Cave-Ayland wrote: Hi all, Following up from my posts at the beginning of the summer, I'm pleased to announce that as of today, qemu-system-sparc64 built from QEMU git master will successfully install OpenBSD from an .iso and boot back into it in serial mode with its default sun4u emulation: $ ./qemu-system-sparc64 -cdrom install55.iso -boot d -nographic OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: ---- Welcome to OpenBIOS v1.1 built on Aug 26 2014 12:48 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 4829 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.3 .. Jumping to entry point 0010 for type 0001... switching to new context: entry point 0x10 stack 0xffe8aa09 OpenBSD BOOT 1.6 Trying bsd... open /pci@1fe,0/pci-ata@5/ide1@2200/cdrom@0:f/etc/random.seed: No such file or directory Booting /pci@1fe,0/pci-ata@5/ide1@2200/cdrom@0:f/bsd 3901336@0x100+6248@0x13b8798+3261984@0x180+932320@0x1b1c620 symbols @ 0xffc5a300 119 start=0x100 Unexpected client interface exception: -1 console is /pci@1fe,0/ebus@3/su Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5 (RAMDISK) #153: Tue Mar 4 15:12:10 MST 2014 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK real mem = 134217728 (128MB) avail mem = 122011648 (116MB) mainbus0 at root: OpenBiosTeam,OpenBIOS cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 100 MHz cpu0: physical 256K instruction (64 b/l), 16K data (32 b/l), 256K external (64 b/l) psycho0 at mainbus0: SUNW,sabre, impl 0, version 0, ign 7c0 psycho0: bus range 0-2, PCI bus 0 psycho0: dvma map c000-dfff pci0 at psycho0 ppb0 at pci0 dev 1 function 0 Sun Simba rev 0x11 pci1 at ppb0 bus 1 ppb1 at pci0 dev 1 function 1 Sun Simba rev 0x11 pci2 at ppb1 bus 2 unknown vendor 0x1234 product 0x (class display subclass VGA, rev 0x00) at pci0 dev 2 function 0 not configured ebus0 at pci0 dev 3 function 0 Sun PCIO EBus2 rev 0x01 fdthree at ebus0 addr 0- not configured com0 at ebus0 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo com0: console kb_ps2 at ebus0 addr 60-67 not configured Realtek 8029 rev 0x00 at pci0 dev 4 function 0 not configured pciide0 at pci0 dev 5 function 0 CMD Technology PCI0646 rev 0x07: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7d4 for native-PCI interrupt pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 2.1. ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 prtc0 at mainbus0 softraid0 at root scsibus1 at softraid0: 256 targets bootpath: /pci@1fe,0/pci-ata@5,0/ide1@2200,0/cdrom@0,0:f root on rd0a swap on rd0b dump on rd0b unix-gettod:interpret: exception -13 caught interpret h# 01c099fc unix-gettod failed with error ffed WARNING: bad date in battery clock -- CHECK AND RESET THE DATE! erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/sparc64 5.5 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? I At any prompt except password prompts you can escape to a shell by typing '!'. Default answers are shown in []'s and are selected by pressing RETURN. You can exit this program at any time by pressing Control-C, but this can leave your system in an inconsistent state. Terminal type? [sun] System hostname? (short form, e.g. 'foo') openbsd Available network interfaces are: vlan0. Which network interface do you wish to configure? (or 'done') [vlan0] done DNS domain name? (e.g. 'bar.com') [my.domain] DNS nameservers? (IP address list or 'none') [none] Password for root account? (will not echo) Password for root account? (again) Start sshd(8) by default? [yes] Start ntpd(8) by default? [no] Do you expect to run the X Window System? [no] Setup a user? (enter a lower-case loginname, or 'no') [no] ... etc. There are still some issues with the device tree to work out; in particular NVRAM and networking (I'd guess that the OpenBSD sparc64 kernel doesn't contain the Realtek device driver so at some point I'll need to create a virtual hme device) but it's good enough to install/boot an OS on different hardware for testing - what could be more fun than that? The Realtek hardware in that dmesg is an NE2000 PCI adapter which the sparc64 kernel config indeed does not have a driver for at the very moment, although it could be added. Having a QEMU driver for the Happy Meal MAC would provide the best level of compatibility with other OS's as that is what comes with a lot of Sun
Re: re(4) feature flags additions and changes
On 05/09/14 2:24 AM, Jonathan Gray wrote: On Tue, Sep 02, 2014 at 07:20:30AM -0400, Brad Smith wrote: On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote: Add some feature flags and store in the softc the various max Jumbo frame sizes for the different generations of chips. No behavioral change. Tested with.. re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800) re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G (0x4c00) OK? Fix a typo with RL_FLAG_HWIM. Why not leave the assignment of sc_hwrev in re.c and stash the product as sc_product or some such? I had been considering that as well. I'll do that as what I had was bugging me. case RL_HWREV_8168C: case RL_HWREV_8168CP: - case RL_HWREV_8168DP: - sc-rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE | - RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | - RL_FLAG_HWIM | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD; - /* -* These controllers support jumbo frame but it seems -* that enabling it requires touching additional magic -* registers. Depending on MAC revisions some -* controllers need to disable checksum offload. So -* disable jumbo frame until I have better idea what -* it really requires to make it support. -* RTL8168C/CP : supports up to 6KB jumbo frame. -* RTL8111C/CP : supports up to 9KB jumbo frame. -*/ - sc-rl_flags |= RL_FLAG_NOJUMBO; + sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR | + RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | + RL_FLAG_AUTOPAD | RL_FLAG_JUMBOV2 | RL_FLAG_WOL_MANLINK; + sc-rl_max_mtu = RL_JUMBO_MTU_6K; break; Assuming the goal is the sync these flags with the FreeBSD driver this misses: It's to get as close as possible more or less. case RL_HWREV_8168C: if (sc-rl_macrev == 0x0020) sc-rl_flags |= RL_FLAG_MACSLEEP; /* FALLTHROUGH */ case RL_HWREV_8168CP: macrev is not sc_hwrev but is read from the same RL_TXCFG register with a different mask (0x0070). I'll see about adding that in later. I haven't seen anyone mentioning any issues with re(4) that might be attributed to the lack of code to kick the controller out of deep sleep mode so it isn't a priority. The other flags and jumbo values all seem to match FreeBSD from a quick comparison. @@ -957,8 +981,8 @@ re_attach(struct rl_softc *sc, const cha ifp-if_ioctl = re_ioctl; ifp-if_start = re_start; ifp-if_watchdog = re_watchdog; - if ((sc-rl_flags RL_FLAG_NOJUMBO) == 0) - ifp-if_hardmtu = RL_JUMBO_MTU; + if ((sc-rl_flags RL_FLAG_JUMBOV2) == 0) + ifp-if_hardmtu = sc-rl_max_mtu; IFQ_SET_MAXLEN(ifp-if_snd, RL_TX_QLEN); IFQ_SET_READY(ifp-if_snd); Anything with RL_FLAG_JUMBOV2 won't do jumbos, because the relevant code for this isn't there at the moment? Basically, yes. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: re(4) feature flags additions and changes
On Tue, Sep 02, 2014 at 07:20:30AM -0400, Brad Smith wrote:
On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote:
Add some feature flags and store in the softc the various max Jumbo frame
sizes
for the different generations of chips. No behavioral change.
Tested with..
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D
(0x2800)
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G
(0x4c00)
OK?
Fix a typo with RL_FLAG_HWIM.
So store the PCI id in the sc_product field instead. The CardBus bit is not
strictly necessary but I'd rather be consistent for both bus frontends for
now especially if I happen to use this field for anything else in the future.
Index: pci/if_re_pci.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 if_re_pci.c
--- pci/if_re_pci.c 22 Jul 2014 13:12:11 - 1.41
+++ pci/if_re_pci.c 5 Sep 2014 18:20:49 -
@@ -197,6 +197,8 @@ re_pci_attach(struct device *parent, str
CSR_WRITE_1(sc, RL_EECMD, RL_EEMODE_OFF);
}
+ sc-sc_product = PCI_PRODUCT(pa-pa_id);
+
/* Call bus-independent attach routine */
if (re_attach(sc, intrstr)) {
pci_intr_disestablish(pc, psc-sc_ih);
Index: cardbus/if_re_cardbus.c
===
RCS file: /home/cvs/src/sys/dev/cardbus/if_re_cardbus.c,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 if_re_cardbus.c
--- cardbus/if_re_cardbus.c 11 Aug 2014 12:45:45 - 1.24
+++ cardbus/if_re_cardbus.c 5 Sep 2014 18:19:48 -
@@ -152,6 +152,8 @@ re_cardbus_attach(struct device *parent,
}
snprintf(intrstr, sizeof(intrstr), irq %d, ca-ca_intrline);
+ sc-sc_product = PCI_PRODUCT(ca-ca_id);
+
/* Call bus-independent (common) attach routine */
if (re_attach(sc, intrstr)) {
cardbus_intr_disestablish(ct-ct_cc, ct-ct_cf, csc-sc_ih);
Index: ic/re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.155
diff -u -p -u -p -r1.155 re.c
--- ic/re.c 22 Jul 2014 13:12:12 - 1.155
+++ ic/re.c 5 Sep 2014 18:26:19 -
@@ -144,6 +144,7 @@
#include dev/pci/pcireg.h
#include dev/pci/pcivar.h
+#include dev/pci/pcidevs.h
#include dev/ic/rtl81x9reg.h
#include dev/ic/revar.h
@@ -578,7 +579,7 @@ re_iff(struct rl_softc *sc)
* parts. This means we have to write the hash pattern in reverse
* order for those devices.
*/
- if (sc-rl_flags RL_FLAG_INVMAR) {
+ if (sc-rl_flags RL_FLAG_PCIE) {
CSR_WRITE_4(sc, RL_MAR0, swap32(hashes[1]));
CSR_WRITE_4(sc, RL_MAR4, swap32(hashes[0]));
} else {
@@ -604,7 +605,7 @@ re_reset(struct rl_softc *sc)
if (i == RL_TIMEOUT)
printf(%s: reset never completed!\n, sc-sc_dev.dv_xname);
- if (sc-rl_flags RL_FLAG_MACLDPS)
+ if (sc-rl_flags RL_FLAG_MACRESET)
CSR_WRITE_1(sc, RL_LDPS, 1);
}
@@ -639,13 +640,14 @@ re_attach(struct rl_softc *sc, const cha
switch (sc-sc_hwrev) {
case RL_HWREV_8139CPLUS:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_FASTETHER | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8100E:
case RL_HWREV_8100E_SPIN2:
case RL_HWREV_8101E:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8103E:
sc-rl_flags |= RL_FLAG_MACSLEEP;
@@ -653,70 +655,103 @@ re_attach(struct rl_softc *sc, const cha
case RL_HWREV_8102E:
case RL_HWREV_8102EL:
case RL_HWREV_8102EL_SPIN1:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 |
- RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
+ RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_FASTETHER |
+ RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8401E:
- case RL_HWREV_8402:
case RL_HWREV_8105E:
case RL_HWREV_8105E_SPIN1:
case RL_HWREV_8106E:
- sc-rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
- RL_FLAG_PHYWAKE_PM | RL_FLAG_PAR | RL_FLAG_DESCV2 |
- RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD |
- RL_FLAG_NOJUMBO;
+ sc-rl_flags |= RL_FLAG_PHYWAKE
re(4) feature flags additions and changes
Add some feature flags and store in the softc the various max Jumbo frame sizes
for the different generations of chips. No behavioral change.
Tested with..
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800)
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G (0x4c00)
OK?
Index: pci/if_re_pci.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 if_re_pci.c
--- pci/if_re_pci.c 22 Jul 2014 13:12:11 - 1.41
+++ pci/if_re_pci.c 20 Aug 2014 02:06:34 -
@@ -197,6 +197,23 @@ re_pci_attach(struct device *parent, str
CSR_WRITE_1(sc, RL_EECMD, RL_EEMODE_OFF);
}
+ sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
+
+ switch (sc-sc_hwrev) {
+ case RL_HWREV_8168GU:
+ if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_REALTEK_RT8101E) {
+ /* RTL8106EUS */
+ sc-rl_flags |= RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
+ } else {
+ sc-rl_flags |= RL_FLAG_JUMBOV2 | RL_FLAG_WOL_MANLINK;
+ sc-rl_max_mtu = RL_JUMBO_MTU_9K;
+ }
+ break;
+ default:
+ break;
+ }
+
/* Call bus-independent attach routine */
if (re_attach(sc, intrstr)) {
pci_intr_disestablish(pc, psc-sc_ih);
Index: cardbus/if_re_cardbus.c
===
RCS file: /home/cvs/src/sys/dev/cardbus/if_re_cardbus.c,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 if_re_cardbus.c
--- cardbus/if_re_cardbus.c 11 Aug 2014 12:45:45 - 1.24
+++ cardbus/if_re_cardbus.c 24 Aug 2014 23:09:04 -
@@ -152,6 +152,8 @@ re_cardbus_attach(struct device *parent,
}
snprintf(intrstr, sizeof(intrstr), irq %d, ca-ca_intrline);
+ sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
+
/* Call bus-independent (common) attach routine */
if (re_attach(sc, intrstr)) {
cardbus_intr_disestablish(ct-ct_cc, ct-ct_cf, csc-sc_ih);
Index: ic/re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.155
diff -u -p -u -p -r1.155 re.c
--- ic/re.c 22 Jul 2014 13:12:12 - 1.155
+++ ic/re.c 24 Aug 2014 23:09:05 -
@@ -578,7 +578,7 @@ re_iff(struct rl_softc *sc)
* parts. This means we have to write the hash pattern in reverse
* order for those devices.
*/
- if (sc-rl_flags RL_FLAG_INVMAR) {
+ if (sc-rl_flags RL_FLAG_PCIE) {
CSR_WRITE_4(sc, RL_MAR0, swap32(hashes[1]));
CSR_WRITE_4(sc, RL_MAR4, swap32(hashes[0]));
} else {
@@ -604,7 +604,7 @@ re_reset(struct rl_softc *sc)
if (i == RL_TIMEOUT)
printf(%s: reset never completed!\n, sc-sc_dev.dv_xname);
- if (sc-rl_flags RL_FLAG_MACLDPS)
+ if (sc-rl_flags RL_FLAG_MACRESET)
CSR_WRITE_1(sc, RL_LDPS, 1);
}
@@ -635,17 +635,16 @@ re_attach(struct rl_softc *sc, const cha
const struct re_revision *rr;
const char *re_name = NULL;
- sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
-
switch (sc-sc_hwrev) {
case RL_HWREV_8139CPLUS:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_FASTETHER | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8100E:
case RL_HWREV_8100E_SPIN2:
case RL_HWREV_8101E:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8103E:
sc-rl_flags |= RL_FLAG_MACSLEEP;
@@ -653,70 +652,94 @@ re_attach(struct rl_softc *sc, const cha
case RL_HWREV_8102E:
case RL_HWREV_8102EL:
case RL_HWREV_8102EL_SPIN1:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 |
- RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
+ RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_FASTETHER |
+ RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8401E:
- case RL_HWREV_8402:
case RL_HWREV_8105E:
case RL_HWREV_8105E_SPIN1:
case RL_HWREV_8106E:
- sc-rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
- RL_FLAG_PHYWAKE_PM | RL_FLAG_PAR | RL_FLAG_DESCV2 |
-
Re: re(4) feature flags additions and changes
On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote:
Add some feature flags and store in the softc the various max Jumbo frame
sizes
for the different generations of chips. No behavioral change.
Tested with..
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800)
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G (0x4c00)
OK?
Fix a typo with RL_FLAG_HWIM.
Index: pci/if_re_pci.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 if_re_pci.c
--- pci/if_re_pci.c 22 Jul 2014 13:12:11 - 1.41
+++ pci/if_re_pci.c 20 Aug 2014 02:06:34 -
@@ -197,6 +197,23 @@ re_pci_attach(struct device *parent, str
CSR_WRITE_1(sc, RL_EECMD, RL_EEMODE_OFF);
}
+ sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
+
+ switch (sc-sc_hwrev) {
+ case RL_HWREV_8168GU:
+ if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_REALTEK_RT8101E) {
+ /* RTL8106EUS */
+ sc-rl_flags |= RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
+ } else {
+ sc-rl_flags |= RL_FLAG_JUMBOV2 | RL_FLAG_WOL_MANLINK;
+ sc-rl_max_mtu = RL_JUMBO_MTU_9K;
+ }
+ break;
+ default:
+ break;
+ }
+
/* Call bus-independent attach routine */
if (re_attach(sc, intrstr)) {
pci_intr_disestablish(pc, psc-sc_ih);
Index: cardbus/if_re_cardbus.c
===
RCS file: /home/cvs/src/sys/dev/cardbus/if_re_cardbus.c,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 if_re_cardbus.c
--- cardbus/if_re_cardbus.c 11 Aug 2014 12:45:45 - 1.24
+++ cardbus/if_re_cardbus.c 24 Aug 2014 23:09:04 -
@@ -152,6 +152,8 @@ re_cardbus_attach(struct device *parent,
}
snprintf(intrstr, sizeof(intrstr), irq %d, ca-ca_intrline);
+ sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
+
/* Call bus-independent (common) attach routine */
if (re_attach(sc, intrstr)) {
cardbus_intr_disestablish(ct-ct_cc, ct-ct_cf, csc-sc_ih);
Index: ic/re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.155
diff -u -p -u -p -r1.155 re.c
--- ic/re.c 22 Jul 2014 13:12:12 - 1.155
+++ ic/re.c 24 Aug 2014 23:09:05 -
@@ -578,7 +578,7 @@ re_iff(struct rl_softc *sc)
* parts. This means we have to write the hash pattern in reverse
* order for those devices.
*/
- if (sc-rl_flags RL_FLAG_INVMAR) {
+ if (sc-rl_flags RL_FLAG_PCIE) {
CSR_WRITE_4(sc, RL_MAR0, swap32(hashes[1]));
CSR_WRITE_4(sc, RL_MAR4, swap32(hashes[0]));
} else {
@@ -604,7 +604,7 @@ re_reset(struct rl_softc *sc)
if (i == RL_TIMEOUT)
printf(%s: reset never completed!\n, sc-sc_dev.dv_xname);
- if (sc-rl_flags RL_FLAG_MACLDPS)
+ if (sc-rl_flags RL_FLAG_MACRESET)
CSR_WRITE_1(sc, RL_LDPS, 1);
}
@@ -635,17 +635,16 @@ re_attach(struct rl_softc *sc, const cha
const struct re_revision *rr;
const char *re_name = NULL;
- sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
-
switch (sc-sc_hwrev) {
case RL_HWREV_8139CPLUS:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_FASTETHER | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8100E:
case RL_HWREV_8100E_SPIN2:
case RL_HWREV_8101E:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8103E:
sc-rl_flags |= RL_FLAG_MACSLEEP;
@@ -653,70 +652,94 @@ re_attach(struct rl_softc *sc, const cha
case RL_HWREV_8102E:
case RL_HWREV_8102EL:
case RL_HWREV_8102EL_SPIN1:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 |
- RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
+ RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_FASTETHER |
+ RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8401E:
- case RL_HWREV_8402:
case RL_HWREV_8105E:
case RL_HWREV_8105E_SPIN1:
case RL_HWREV_8106E:
- sc-rl_flags |= RL_FLAG_INVMAR
Re: re(4) feature flags additions and changes
On Tue, Sep 02, 2014 at 09:03:34PM +1000, Jonathan Gray wrote: On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote: Add some feature flags and store in the softc the various max Jumbo frame sizes for the different generations of chips. No behavioral change. Tested with.. re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800) re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G (0x4c00) OK? This would be a much easier diff to read if you didn't change the names of a whole bunch of flags. Changed.. RL_FLAG_MACLDPS - RL_FLAG_MACRESET. Removed.. RL_FLAG_INVMAR, RL_FLAG_NOJUMBO. Added.. RL_FLAG_FASTETHER, RL_FLAG_CMDSTOP_WAIT_TXQ, RL_FLAG_JUMBOV2, RL_FLAG_WOL_MANLINK, RL_FLAG_WAIT_TXPOLL, RL_FLAG_WOLRXENB. +#defineRL_FLAG_HWIM0x00800 +#defineRL_FLAG_MACSLEEP0x0800 This is obviously wrong. A typo. Fixed. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: bge(4) Jumbo support for newer chipsets
On Wed, Aug 27, 2014 at 02:25:27AM -0400, Brad Smith wrote:
Looking for some testing of the following diff to add Jumbo support for the
BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766
chipsets.
Here is an updated diff with bge_rxrinfo() being fixed.
Index: if_bge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.360
diff -u -p -u -p -r1.360 if_bge.c
--- if_bge.c26 Aug 2014 11:01:21 - 1.360
+++ if_bge.c2 Sep 2014 01:50:30 -
@@ -1117,10 +1117,10 @@ bge_newbuf(struct bge_softc *sc, int i)
struct mbuf *m;
int error;
- m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+ m = MCLGETI(NULL, M_DONTWAIT, NULL, sc-bge_rx_std_len);
if (!m)
return (ENOBUFS);
- m-m_len = m-m_pkthdr.len = MCLBYTES;
+ m-m_len = m-m_pkthdr.len = sc-bge_rx_std_len;
if (!(sc-bge_flags BGE_RX_ALIGNBUG))
m_adj(m, ETHER_ALIGN);
@@ -1241,8 +1241,8 @@ bge_init_rx_ring_std(struct bge_softc *s
return (0);
for (i = 0; i BGE_STD_RX_RING_CNT; i++) {
- if (bus_dmamap_create(sc-bge_dmatag, MCLBYTES, 1, MCLBYTES, 0,
- BUS_DMA_NOWAIT | BUS_DMA_ALLOCNOW,
+ if (bus_dmamap_create(sc-bge_dmatag, sc-bge_rx_std_len, 1,
+ sc-bge_rx_std_len, 0, BUS_DMA_NOWAIT | BUS_DMA_ALLOCNOW,
sc-bge_cdata.bge_rx_std_map[i]) != 0) {
printf(%s: unable to create dmamap for slot %d\n,
sc-bge_dev.dv_xname, i);
@@ -1485,6 +1485,7 @@ bge_init_tx_ring(struct bge_softc *sc)
{
int i;
bus_dmamap_t dmamap;
+ bus_size_t txsegsz, txmaxsegsz;
struct txdmamap_pool_entry *dma;
if (sc-bge_flags BGE_TXRING_VALID)
@@ -1504,11 +1505,18 @@ bge_init_tx_ring(struct bge_softc *sc)
if (BGE_CHIPREV(sc-bge_chipid) == BGE_CHIPREV_5700_BX)
bge_writembx(sc, BGE_MBX_TX_NIC_PROD0_LO, 0);
+ if (BGE_IS_JUMBO_CAPABLE(sc)) {
+ txsegsz = 4096;
+ txmaxsegsz = BGE_JLEN;
+ } else {
+ txsegsz = MCLBYTES;
+ txmaxsegsz = MCLBYTES;
+ }
+
SLIST_INIT(sc-txdma_list);
for (i = 0; i BGE_TX_RING_CNT; i++) {
- if (bus_dmamap_create(sc-bge_dmatag, BGE_JLEN,
- BGE_NTXSEG, BGE_JLEN, 0, BUS_DMA_NOWAIT,
- dmamap))
+ if (bus_dmamap_create(sc-bge_dmatag, txmaxsegsz,
+ BGE_NTXSEG, txsegsz, 0, BUS_DMA_NOWAIT, dmamap))
return (ENOBUFS);
if (dmamap == NULL)
panic(dmamap NULL in bge_init_tx_ring);
@@ -2001,7 +2009,7 @@ bge_blockinit(struct bge_softc *sc)
* using this ring (i.e. once we set the MTU
* high enough to require it).
*/
- if (BGE_IS_JUMBO_CAPABLE(sc)) {
+ if (sc-bge_flags BGE_JUMBO_RING) {
rcb = sc-bge_rdata-bge_info.bge_jumbo_rx_rcb;
BGE_HOSTADDR(rcb-bge_hostaddr,
BGE_RING_DMA_ADDR(sc, bge_rx_jumbo_ring));
@@ -2065,7 +2073,7 @@ bge_blockinit(struct bge_softc *sc)
* to work around HW bugs.
*/
CSR_WRITE_4(sc, BGE_RBDI_STD_REPL_THRESH, 8);
- if (BGE_IS_JUMBO_CAPABLE(sc))
+ if (sc-bge_flags BGE_JUMBO_RING)
CSR_WRITE_4(sc, BGE_RBDI_JUMBO_REPL_THRESH, 8);
if (BGE_IS_5717_PLUS(sc)) {
@@ -2699,7 +2707,8 @@ bge_attach(struct device *parent, struct
case BGE_ASICREV_BCM5719:
case BGE_ASICREV_BCM5720:
sc-bge_flags |= BGE_5717_PLUS | BGE_5755_PLUS | BGE_575X_PLUS |
- BGE_5705_PLUS;
+ BGE_5705_PLUS | BGE_JUMBO_CAPABLE | BGE_JUMBO_RING |
+ BGE_JUMBO_FRAME;
if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5719 ||
BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5720) {
/*
@@ -2707,6 +2716,13 @@ bge_attach(struct device *parent, struct
* of TXMBUF available space.
*/
sc-bge_flags |= BGE_RDMA_BUG;
+
+ if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5719
+ sc-bge_chipid == BGE_CHIPID_BCM5719_A0) {
+ /* Jumbo frame on BCM5719 A0 does not work. */
+ sc-bge_flags = ~(BGE_JUMBO_CAPABLE |
+ BGE_JUMBO_RING | BGE_JUMBO_FRAME);
+ }
}
break;
case BGE_ASICREV_BCM5755:
@@ -2721,12 +2737,12 @@ bge_attach(struct device *parent, struct
case BGE_ASICREV_BCM5701:
case BGE_ASICREV_BCM5703:
case BGE_ASICREV_BCM5704:
- sc-bge_flags
bge(4) Jumbo support for newer chipsets
Looking for some testing of the following diff to add Jumbo support for the
BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766
chipsets.
Index: if_bge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.360
diff -u -p -u -p -r1.360 if_bge.c
--- if_bge.c26 Aug 2014 11:01:21 - 1.360
+++ if_bge.c27 Aug 2014 00:48:45 -
@@ -1117,10 +1117,10 @@ bge_newbuf(struct bge_softc *sc, int i)
struct mbuf *m;
int error;
- m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+ m = MCLGETI(NULL, M_DONTWAIT, NULL, sc-bge_rx_std_len);
if (!m)
return (ENOBUFS);
- m-m_len = m-m_pkthdr.len = MCLBYTES;
+ m-m_len = m-m_pkthdr.len = sc-bge_rx_std_len;
if (!(sc-bge_flags BGE_RX_ALIGNBUG))
m_adj(m, ETHER_ALIGN);
@@ -1241,8 +1241,8 @@ bge_init_rx_ring_std(struct bge_softc *s
return (0);
for (i = 0; i BGE_STD_RX_RING_CNT; i++) {
- if (bus_dmamap_create(sc-bge_dmatag, MCLBYTES, 1, MCLBYTES, 0,
- BUS_DMA_NOWAIT | BUS_DMA_ALLOCNOW,
+ if (bus_dmamap_create(sc-bge_dmatag, sc-bge_rx_std_len, 1,
+ sc-bge_rx_std_len, 0, BUS_DMA_NOWAIT | BUS_DMA_ALLOCNOW,
sc-bge_cdata.bge_rx_std_map[i]) != 0) {
printf(%s: unable to create dmamap for slot %d\n,
sc-bge_dev.dv_xname, i);
@@ -1485,6 +1485,7 @@ bge_init_tx_ring(struct bge_softc *sc)
{
int i;
bus_dmamap_t dmamap;
+ bus_size_t txsegsz, txmaxsegsz;
struct txdmamap_pool_entry *dma;
if (sc-bge_flags BGE_TXRING_VALID)
@@ -1504,11 +1505,18 @@ bge_init_tx_ring(struct bge_softc *sc)
if (BGE_CHIPREV(sc-bge_chipid) == BGE_CHIPREV_5700_BX)
bge_writembx(sc, BGE_MBX_TX_NIC_PROD0_LO, 0);
+ if (BGE_IS_JUMBO_CAPABLE(sc)) {
+ txsegsz = 4096;
+ txmaxsegsz = BGE_JLEN;
+ } else {
+ txsegsz = MCLBYTES;
+ txmaxsegsz = MCLBYTES;
+ }
+
SLIST_INIT(sc-txdma_list);
for (i = 0; i BGE_TX_RING_CNT; i++) {
- if (bus_dmamap_create(sc-bge_dmatag, BGE_JLEN,
- BGE_NTXSEG, BGE_JLEN, 0, BUS_DMA_NOWAIT,
- dmamap))
+ if (bus_dmamap_create(sc-bge_dmatag, txmaxsegsz,
+ BGE_NTXSEG, txsegsz, 0, BUS_DMA_NOWAIT, dmamap))
return (ENOBUFS);
if (dmamap == NULL)
panic(dmamap NULL in bge_init_tx_ring);
@@ -2001,7 +2009,7 @@ bge_blockinit(struct bge_softc *sc)
* using this ring (i.e. once we set the MTU
* high enough to require it).
*/
- if (BGE_IS_JUMBO_CAPABLE(sc)) {
+ if (sc-bge_flags BGE_JUMBO_RING) {
rcb = sc-bge_rdata-bge_info.bge_jumbo_rx_rcb;
BGE_HOSTADDR(rcb-bge_hostaddr,
BGE_RING_DMA_ADDR(sc, bge_rx_jumbo_ring));
@@ -2065,7 +2073,7 @@ bge_blockinit(struct bge_softc *sc)
* to work around HW bugs.
*/
CSR_WRITE_4(sc, BGE_RBDI_STD_REPL_THRESH, 8);
- if (BGE_IS_JUMBO_CAPABLE(sc))
+ if (sc-bge_flags BGE_JUMBO_RING)
CSR_WRITE_4(sc, BGE_RBDI_JUMBO_REPL_THRESH, 8);
if (BGE_IS_5717_PLUS(sc)) {
@@ -2699,7 +2707,8 @@ bge_attach(struct device *parent, struct
case BGE_ASICREV_BCM5719:
case BGE_ASICREV_BCM5720:
sc-bge_flags |= BGE_5717_PLUS | BGE_5755_PLUS | BGE_575X_PLUS |
- BGE_5705_PLUS;
+ BGE_5705_PLUS | BGE_JUMBO_CAPABLE | BGE_JUMBO_RING |
+ BGE_JUMBO_FRAME;
if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5719 ||
BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5720) {
/*
@@ -2707,6 +2716,13 @@ bge_attach(struct device *parent, struct
* of TXMBUF available space.
*/
sc-bge_flags |= BGE_RDMA_BUG;
+
+ if (BGE_ASICREV(sc-bge_chipid) == BGE_ASICREV_BCM5719
+ sc-bge_chipid == BGE_CHIPID_BCM5719_A0) {
+ /* Jumbo frame on BCM5719 A0 does not work. */
+ sc-bge_flags = ~(BGE_JUMBO_CAPABLE |
+ BGE_JUMBO_RING | BGE_JUMBO_FRAME);
+ }
}
break;
case BGE_ASICREV_BCM5755:
@@ -2721,12 +2737,12 @@ bge_attach(struct device *parent, struct
case BGE_ASICREV_BCM5701:
case BGE_ASICREV_BCM5703:
case BGE_ASICREV_BCM5704:
- sc-bge_flags |= BGE_5700_FAMILY | BGE_JUMBO_CAPABLE;
+ sc-bge_flags |= BGE_5700_FAMILY | BGE_JUMBO_CAPABLE |
BGE_JUMBO_RING;
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On 20/08/14 8:03 PM, David Gwynne wrote: sthen@ says this is likely a bit optimistic. while most of our drivers unconditionally configure their max mru, there's some stupid ones that still interpret the configured mtu as a what the mru should be. dlg oce(4) and ix(4) need to be fixed. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
On 18/08/14 6:24 PM, David Gwynne wrote: On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote: i think i'll try to find the sk at work and wire it up. its just annoying cos im pretty sure its sr optics with sc connectors. thanks for testing. how's this one? Only running regular MTU traffic so far but the NIC at least works and beating on it I haven't seen any noticeable issues so far. I'll see if I can do some test with Jumbos a little later on today. sk0 902019 2 25619 sk0 1500 Link 00:00:5a:98:b9:c0 29810991 0 23786214 0 0 skc0 at pci0 dev 5 function 0 Schneider Koch SK-98xx rev 0x13, GEnesis (0x0): ivec 0x784 sk0 at skc0 port A: address 00:00:5a:98:b9:c0 brgphy0 at sk0 phy 1: BCM5400 1000baseT PHY, rev. 7 Some minor cosmetic issues I noticed while diff'ing the two revisions of the diff... m-m_len = m-m_pkthdr.len = SK_JLEN; has spaces instead of a tab and the whitespace after if_rxr_ioctl(). -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
On 19/08/14 2:43 PM, Stuart Henderson wrote: From what I remember from last attempt to convert sk(4) to MCLGETI, there were problems which only showed up under load (possibly also involved NFS, I don't remember for sure) - I probably used netrate with something like netblast 11.22.33.44 12345 1 30 to generate a bunch of packets over it quickly, and tcpbench to generate high bandwidth use. The first diff he sent out didn't work at all. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
On 19/08/14 2:19 PM, Brad Smith wrote: On 18/08/14 6:24 PM, David Gwynne wrote: On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote: i think i'll try to find the sk at work and wire it up. its just annoying cos im pretty sure its sr optics with sc connectors. thanks for testing. how's this one? Only running regular MTU traffic so far but the NIC at least works and beating on it I haven't seen any noticeable issues so far. I'll see if I can do some test with Jumbos a little later on today. sk0 902019 2 25619 sk0 1500 Link 00:00:5a:98:b9:c0 29810991 0 23786214 0 0 skc0 at pci0 dev 5 function 0 Schneider Koch SK-98xx rev 0x13, GEnesis (0x0): ivec 0x784 sk0 at skc0 port A: address 00:00:5a:98:b9:c0 brgphy0 at sk0 phy 1: BCM5400 1000baseT PHY, rev. 7 Some minor cosmetic issues I noticed while diff'ing the two revisions of the diff... m-m_len = m-m_pkthdr.len = SK_JLEN; has spaces instead of a tab and the whitespace after if_rxr_ioctl(). Running either netrate or tcpbench targetted at the test system and its still working Ok. No packet loss. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
On 18/08/14 6:24 PM, David Gwynne wrote:
On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote:
i think i'll try to find the sk at work and wire it up. its just annoying cos
im pretty sure its sr optics with sc connectors.
thanks for testing.
how's this one?
I'll look into testing it later on tonight or tomorrow.
Index: if_sk.c
===
RCS file: /cvs/src/sys/dev/pci/if_sk.c,v
retrieving revision 1.170
diff -u -p -r1.170 if_sk.c
--- if_sk.c 22 Jul 2014 13:12:11 - 1.170
+++ if_sk.c 18 Aug 2014 21:57:14 -
@@ -153,12 +153,10 @@ void sk_watchdog(struct ifnet *);
int sk_ifmedia_upd(struct ifnet *);
void sk_ifmedia_sts(struct ifnet *, struct ifmediareq *);
void skc_reset(struct sk_softc *);
-int sk_newbuf(struct sk_if_softc *, int, struct mbuf *, bus_dmamap_t);
-int sk_alloc_jumbo_mem(struct sk_if_softc *);
-void *sk_jalloc(struct sk_if_softc *);
-void sk_jfree(caddr_t, u_int, void *);
+int sk_newbuf(struct sk_if_softc *);
int sk_reset(struct sk_if_softc *);
int sk_init_rx_ring(struct sk_if_softc *);
+void sk_fill_rx_ring(struct sk_if_softc *);
int sk_init_tx_ring(struct sk_if_softc *);
int sk_xmac_miibus_readreg(struct device *, int, int);
@@ -547,21 +545,29 @@ sk_init_rx_ring(struct sk_if_softc *sc_i
rd-sk_rx_ring[i].sk_next = htole32(SK_RX_RING_ADDR(sc_if,
nexti));
}
- for (i = 0; i SK_RX_RING_CNT; i++) {
- if (sk_newbuf(sc_if, i, NULL,
- sc_if-sk_cdata.sk_rx_jumbo_map) == ENOBUFS) {
- printf(%s: failed alloc of %dth mbuf\n,
- sc_if-sk_dev.dv_xname, i);
- return (ENOBUFS);
- }
- }
-
sc_if-sk_cdata.sk_rx_prod = 0;
sc_if-sk_cdata.sk_rx_cons = 0;
+ if_rxr_init(sc_if-sk_cdata.sk_rx_ring, 2, SK_RX_RING_CNT);
+
+ sk_fill_rx_ring(sc_if);
+
return (0);
}
+void
+sk_fill_rx_ring(struct sk_if_softc *sc_if)
+{
+ struct if_rxring *rxr = sc_if-sk_cdata.sk_rx_ring;
+ u_int slots;
+
+ for (slots = if_rxr_get(rxr, SK_RX_RING_CNT); slots 0; slots--) {
+ if (sk_newbuf(sc_if) == ENOBUFS)
+ break;
+ }
+ if_rxr_put(rxr, slots);
+}
+
int
sk_init_tx_ring(struct sk_if_softc *sc_if)
{
@@ -609,199 +615,49 @@ sk_init_tx_ring(struct sk_if_softc *sc_i
}
int
-sk_newbuf(struct sk_if_softc *sc_if, int i, struct mbuf *m,
- bus_dmamap_t dmamap)
+sk_newbuf(struct sk_if_softc *sc_if)
{
- struct mbuf *m_new = NULL;
+ struct mbuf *m;
struct sk_chain *c;
struct sk_rx_desc *r;
+ bus_dmamap_tdmamap;
+ u_int prod;
+ int error;
- if (m == NULL) {
- caddr_t buf = NULL;
-
- MGETHDR(m_new, M_DONTWAIT, MT_DATA);
- if (m_new == NULL)
- return (ENOBUFS);
-
- /* Allocate the jumbo buffer */
- buf = sk_jalloc(sc_if);
- if (buf == NULL) {
- m_freem(m_new);
- DPRINTFN(1, (%s jumbo allocation failed -- packet
- dropped!\n, sc_if-arpcom.ac_if.if_xname));
- return (ENOBUFS);
- }
-
- /* Attach the buffer to the mbuf */
- m_new-m_len = m_new-m_pkthdr.len = SK_JLEN;
- MEXTADD(m_new, buf, SK_JLEN, 0, sk_jfree, sc_if);
- } else {
- /*
-* We're re-using a previously allocated mbuf;
-* be sure to re-init pointers and lengths to
-* default values.
-*/
- m_new = m;
- m_new-m_len = m_new-m_pkthdr.len = SK_JLEN;
- m_new-m_data = m_new-m_ext.ext_buf;
- }
- m_adj(m_new, ETHER_ALIGN);
-
- c = sc_if-sk_cdata.sk_rx_chain[i];
- r = c-sk_desc;
- c-sk_mbuf = m_new;
- r-sk_data_lo = htole32(dmamap-dm_segs[0].ds_addr +
- (((vaddr_t)m_new-m_data
- - (vaddr_t)sc_if-sk_cdata.sk_jumbo_buf)));
- r-sk_ctl = htole32(SK_JLEN | SK_RXSTAT);
-
- SK_CDRXSYNC(sc_if, i, BUS_DMASYNC_PREWRITE|BUS_DMASYNC_PREREAD);
+ m = MCLGETI(NULL, M_DONTWAIT, NULL, SK_JLEN);
+ if (m == NULL)
+ return (ENOBUFS);
- return (0);
-}
+m-m_len = m-m_pkthdr.len = SK_JLEN;
+ m_adj(m, ETHER_ALIGN);
-/*
- * Memory management for jumbo frames.
- */
+ prod = sc_if-sk_cdata.sk_rx_prod;
+ dmamap = sc_if-sk_cdata.sk_rx_map[prod];
-int
-sk_alloc_jumbo_mem(struct sk_if_softc *sc_if)
-{
- struct sk_softc *sc = sc_if-sk_softc;
- caddr_t ptr, kva;
- bus_dma_segment_t seg;
- int i, rseg, state, error;
- struct sk_jpool_entry *entry;
-
Re: jumbo support for bnx(4)
On 13/08/14 6:42 AM, David Gwynne wrote:
ive had this for 2 years or so. updated to current again.
its been tested on the following:
bnx0 at pci4 dev 0 function 0 Broadcom BCM5708 rev 0x12: apic 8 int 16
bnx1 at pci13 dev 0 function 0 Broadcom BCM5708 rev 0x12: apic 8 int 16
bnx0: address 00:1e:4f:1b:26:53
brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
bnx1: address 00:1e:4f:1b:26:51
brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6
itd be nice to get tests on other variants.
ok?
This is exactly the same diff that was posted in the past
and it wouldn't be any less broken on the BCM5709 chipsets
now.
Index: if_bnx.c
===
RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.107
diff -u -p -r1.107 if_bnx.c
--- if_bnx.c18 Jul 2014 07:11:04 - 1.107
+++ if_bnx.c13 Aug 2014 10:40:24 -
@@ -848,6 +848,8 @@ bnx_attachhook(void *xsc)
sc-bnx_rx_ticks = 18;
#endif
+ sc-mbuf_alloc_size = BNX_MAX_JUMBO_MRU;
+
/* Update statistics once every second. */
sc-bnx_stats_ticks = 100 0x00;
@@ -878,6 +880,7 @@ bnx_attachhook(void *xsc)
ifp-if_ioctl = bnx_ioctl;
ifp-if_start = bnx_start;
ifp-if_watchdog = bnx_watchdog;
+ ifp-if_hardmtu = BNX_MAX_JUMBO_MTU;
IFQ_SET_MAXLEN(ifp-if_snd, USABLE_TX_BD - 1);
IFQ_SET_READY(ifp-if_snd);
bcopy(sc-eaddr, sc-arpcom.ac_enaddr, ETHER_ADDR_LEN);
@@ -890,8 +893,6 @@ bnx_attachhook(void *xsc)
ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING;
#endif
- sc-mbuf_alloc_size = BNX_MAX_MRU;
-
printf(%s: address %s\n, sc-bnx_dev.dv_xname,
ether_sprintf(sc-arpcom.ac_enaddr));
@@ -2647,8 +2648,8 @@ bnx_dma_alloc(struct bnx_softc *sc)
* Create DMA maps for the Rx buffer mbufs.
*/
for (i = 0; i TOTAL_RX_BD; i++) {
- if (bus_dmamap_create(sc-bnx_dmatag, BNX_MAX_MRU,
- BNX_MAX_SEGMENTS, BNX_MAX_MRU, 0, BUS_DMA_NOWAIT,
+ if (bus_dmamap_create(sc-bnx_dmatag, sc-mbuf_alloc_size,
+ 1, sc-mbuf_alloc_size, 0, BUS_DMA_NOWAIT,
sc-rx_mbuf_map[i])) {
printf(: Could not create Rx mbuf %d DMA map!\n, i);
rc = ENOMEM;
@@ -3663,10 +3664,10 @@ bnx_get_buf(struct bnx_softc *sc, u_int1
*prod_bseq);
/* This is a new mbuf allocation. */
- m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+ m = MCLGETI(NULL, M_DONTWAIT, NULL, sc-mbuf_alloc_size);
if (!m)
return (0);
- m-m_len = m-m_pkthdr.len = MCLBYTES;
+ m-m_len = m-m_pkthdr.len = sc-mbuf_alloc_size;
/* the chip aligns the ip header for us, no need to m_adj */
/* Map the mbuf cluster into device memory. */
@@ -3979,6 +3980,16 @@ bnx_init_rx_context(struct bnx_softc *sc
REG_WR(sc, BNX_MQ_MAP_L2_5, val | BNX_MQ_MAP_L2_5_ARM);
}
+ CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, 0);
+
+ /* Configure the rx_bd and page chain mbuf cluster size. */
+ val = (sc-mbuf_alloc_size 16);
+ CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, val);
+
+ /* Configure the context reserved for jumbo support. */
+ CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_RBDC_KEY,
+ BNX_L2CTX_RX_RBDC_JUMBO_KEY);
+
/* Point the hardware to the first page in the chain. */
val = (u_int32_t)((u_int64_t)sc-rx_bd_chain_paddr[0] 32);
CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_NX_BDHADDR_HI, val);
@@ -4746,7 +4757,7 @@ bnx_init(void *xsc)
bnx_set_mac_addr(sc);
/* Calculate and program the Ethernet MRU size. */
- ether_mtu = BNX_MAX_STD_ETHER_MTU_VLAN;
+ ether_mtu = BNX_MAX_JUMBO_ETHER_MTU;
DBPRINT(sc, BNX_INFO, %s(): setting MRU = %d\n,
__FUNCTION__, ether_mtu);
@@ -5134,7 +5145,7 @@ bnx_ioctl(struct ifnet *ifp, u_long comm
case SIOCGIFRXR:
error = if_rxr_ioctl((struct if_rxrinfo *)ifr-ifr_data,
- NULL, MCLBYTES, sc-rx_ring);
+ NULL, sc-mbuf_alloc_size, sc-rx_ring);
break;
default:
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: jumbo support for bnx(4)
On 14/08/14 5:09 PM, Brad Smith wrote: On 13/08/14 6:42 AM, David Gwynne wrote: ive had this for 2 years or so. updated to current again. its been tested on the following: bnx0 at pci4 dev 0 function 0 Broadcom BCM5708 rev 0x12: apic 8 int 16 bnx1 at pci13 dev 0 function 0 Broadcom BCM5708 rev 0x12: apic 8 int 16 bnx0: address 00:1e:4f:1b:26:53 brgphy0 at bnx0 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6 bnx1: address 00:1e:4f:1b:26:51 brgphy1 at bnx1 phy 1: BCM5708C 10/100/1000baseT PHY, rev. 6 itd be nice to get tests on other variants. ok? This is exactly the same diff that was posted in the past and it wouldn't be any less broken on the BCM5709 chipsets now. Since someone said I should say what I did in a clearer manner.. Since the diff has not changed and was broken when it was originally posted then it will still be broken now. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: network autoconfig
On 13/07/14 2:16 PM, frantisek holop wrote: hmm, on Sun, Jul 13, 2014 at 05:37:51PM +0200, Denis Fondras said that from the user's PoV, there shouldn't be more needed than ifconfig if inet autoconf ifconfig if inet6 autoconf aka inet/inet6 autoconf in hostname.if. I'm curious to see what will come out of it as I cannot envision any added value of these autoconf compared to dhclient. sounds like a great place to deal with wifi networks. That comment doesn't even make any sense. Wifi networks are not magic unicorns. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: network autoconfig
On 13/07/14 4:22 PM, frantisek holop wrote: hmm, on Sun, Jul 13, 2014 at 02:21:06PM -0400, Brad Smith said that On 13/07/14 2:16 PM, frantisek holop wrote: hmm, on Sun, Jul 13, 2014 at 05:37:51PM +0200, Denis Fondras said that from the user's PoV, there shouldn't be more needed than ifconfig if inet autoconf ifconfig if inet6 autoconf aka inet/inet6 autoconf in hostname.if. I'm curious to see what will come out of it as I cannot envision any added value of these autoconf compared to dhclient. sounds like a great place to deal with wifi networks. That comment doesn't even make any sense. Wifi networks are not magic unicorns. that little userland daemon, let's call it autoconfd could have a privsepped part doing scans and could make a decision how to set up the wifi interface before dhclient is called. i can dream, can't i? This isn't a do everything command line parameter. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
On 12/07/14 4:32 AM, David Gwynne wrote: how about this? Now it attaches without error but tcpdump shows no traffic coming in at all and there is regular traffic on the segment from spanning tree, CARP, RA, etc. $ vmstat -iz interrupt total rate schizo0:pci_a 00 schizo0:ue 00 schizo0:ce 00 schizo0:safari 00 pcfiic0 00 power0 00 com0 530 com100 autri0 00 ohci0 00 ohci1 00 pciide0 13184 ohci2 00 ohci3 00 ehci0 00 skc050 schizo1:pci_b 00 schizo1:ue 00 schizo1:ce 00 schizo1:safari 00 bge0 9693 clock 30714 99 Total 33059 107 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
On 10/07/14 1:33 AM, David Gwynne wrote: this is an update of if_sk.c r1.151, which tried to introduce mclgeti. it updates it to use the if_rxring accounting. does anyone have one they can test this on? it also saves about 2k on amd64. Doesn't work at all. skc0 at pci0 dev 5 function 0 Schneider Koch SK-98xx rev 0x13, GEnesis (0x0): ivec 0x784 sk0 at skc0 port A: address 00:00:5a:98:b9:c0 skc0: unable to create rx DMA map 1, error = 0 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: AI_ADDRCONFIG
On Wed, Apr 23, 2014 at 08:09:06AM -0400, Simon Perreault wrote: (I sent this diff to ??ric Faurot on the 12th, but received no reply.) Tech, While everyone's having fun removing code from OpenSSL, I decided to add some to libasr. I implemented AI_ADDRCONFIG, a getaddrinfo() flag defined in RFC 2553/3493. Basically, it tells getaddrinfo() to skip IPvX lookups when there are no IPvX addresses configured on any interface. It is present on most other OSes. Tons of software out there have to play Autoconf games to cope with its absence (which, on OpenBSD, predates libasr if I'm not mistaken). Noteworthy: - I call getifaddrs() from getaddrinfo_run_async(). This should not block, so no need to change the state machine. - I added AI_ADDRCONFIG to the default hints, like glibc does, and as was specified in RFC 2553. (RFC 3493 says nothing about default flags.) ok? comments? Great! I had been asking Eric about this. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: em(4): Don't count RX overruns and missed packets as input errros
On Fri, Feb 07, 2014 at 06:15:44AM -0500, Brad Smith wrote:
On Tue, Jan 28, 2014 at 02:08:09AM -0500, Brad Smith wrote:
On Tue, Jan 28, 2014 at 01:21:46PM +1000, David Gwynne wrote:
On 26 Jan 2014, at 11:31 am, Brad Smith b...@comstyle.com wrote:
On 31/12/13 5:50 AM, Mike Belopuhov wrote:
On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote:
On 31/12/13 3:14 AM, Mark Kettenis wrote:
Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith b...@comstyle.com
Don't count RX overruns and missed packets as inputs errors. They're
expected to increment when using MCLGETI.
OK?
These may be expected, but they're still packets that were not
received. And it is useful to know about these, for example when
debugging TCP performance issues.
Well do we want to keep just the missed packets or both? Part of the
diff was inspired by this commit when I was looking at what counters
were incrementing..
for bge(4)..
revision 1.334
date: 2013/06/06 00:05:30; author: dlg; state: Exp; lines: +2 -4;
dont count rx ring overruns as input errors. with MCLGETI controlling
the
ring we expect to run out of rx descriptors as a matter of course,
its not
an error.
ok mikeb@
it does screws up statistics big time. does mpc counter follow
rx_overruns?
why did we add them up both previously?
Yes, it does. I can't say why exactly but before MCLGETI for most
environments
it was unlikely to have RX overruns.
its not obvious?
rx rings are usually massively over provisioned. eg, my myx has 512
entries in its
rx ring. however, its interrupt mitigation is currently configured for
approximately
16k interrupts a second. if you're sustaining 1m pps, then you can divide
that by the
interrupt rate to figure out the average usage of the rx ring. so 1000 /
16 is about
60-65 descriptors per interrupt. 512 is roughly an order of magnitude
more than what
you need for that workload.
if you were hitting the ring limits before MCLGETI, then that means you
dont have
enough cpu to process the pps. increasing the ring size would make it
worse cos you'd
spend more time freeing mbufs because you were too far behind on the pps
you could
deal with.
Ya, I don't know why I ultimately said I can't say why exactly as I was
thinking about
what you said regaring having a lot of buffers allocated and that's why I
said it was
unlikely to have RX overruns.
Since this was changed for bge(4) then the other drivers using MCLGETI
should be changed
as well if there is consensus about not adding the RX overruns to the
interfaces input
errors counter. But I think kettenis has a point as well that this
information is useful
its just we don't have any way of exposing that info to userland.
Ok, so I looked at the other drivers using MCLGETI and there are a few others
also
counting FIFO overruns towards input errors.
ping.
Index: arch/socppc/dev/if_tsec.c
===
RCS file: /home/cvs/src/sys/arch/socppc/dev/if_tsec.c,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 if_tsec.c
--- arch/socppc/dev/if_tsec.c 29 Nov 2012 21:10:31 - 1.29
+++ arch/socppc/dev/if_tsec.c 28 Jan 2014 05:16:24 -
@@ -779,7 +779,6 @@ tsec_errintr(void *arg)
*/
tsec_rx_proc(sc);
tsec_write(sc, TSEC_RSTAT, TSEC_RSTAT_QHLT);
- ifp-if_ierrors++;
}
return (1);
Index: dev/pci/if_se.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_se.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 if_se.c
--- dev/pci/if_se.c 28 Dec 2013 03:34:54 - 1.9
+++ dev/pci/if_se.c 28 Jan 2014 04:49:53 -
@@ -939,7 +939,8 @@ se_rxeof(struct se_softc *sc)
printf(%s: rx error %b\n,
ifp-if_xname, rxstat, RX_ERR_BITS);
se_discard_rxbuf(sc, i);
- ifp-if_ierrors++;
+ if ((rxstat RDS_OVRUN) == 0)
+ ifp-if_ierrors++;
continue;
}
Index: dev/pci/if_sis.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_sis.c,v
retrieving revision 1.115
diff -u -p -u -p -r1.115 if_sis.c
--- dev/pci/if_sis.c 28 Dec 2013 03:34:54 - 1.115
+++ dev/pci/if_sis.c 28 Jan 2014 04:51:53 -
@@ -1378,7 +1378,8 @@ sis_rxeof(struct sis_softc *sc)
total_len = (ETHER_MAX_DIX_LEN - ETHER_CRC_LEN))
rxstat = ~SIS_RXSTAT_GIANT;
if (SIS_RXSTAT_ERROR(rxstat)) {
- ifp-if_ierrors
Re: em(4): Don't count RX overruns and missed packets as input errros
On Tue, Feb 11, 2014 at 07:43:51PM +0100, Mark Kettenis wrote: Date: Tue, 11 Feb 2014 13:30:47 -0500 From: Brad Smith b...@comstyle.com Index: arch/socppc/dev/if_tsec.c === RCS file: /home/cvs/src/sys/arch/socppc/dev/if_tsec.c,v retrieving revision 1.29 diff -u -p -u -p -r1.29 if_tsec.c --- arch/socppc/dev/if_tsec.c 29 Nov 2012 21:10:31 - 1.29 +++ arch/socppc/dev/if_tsec.c 28 Jan 2014 05:16:24 - @@ -779,7 +779,6 @@ tsec_errintr(void *arg) */ tsec_rx_proc(sc); tsec_write(sc, TSEC_RSTAT, TSEC_RSTAT_QHLT); - ifp-if_ierrors++; } return (1); This one doesn't seem right. This is the only place where the driver actually increases if_ierrors. Being the only place input errors are incremented is irrelevant. Its being incremented because the particular error is a FIFO overrun. I also still fundamentally disagree with the direction. I you guys really want to make a distinction between packets dropped because we're out of descriptors and packets that were not correctly received for other reasons, add a counter for that first and then change the drivers. I don't necessarily disagree with what you have said. I think we should have some additional counters to deal with some of the counters we are lumping into error counters. Since we can't seem to come to any consensus about how to deal with this I'm going to revert the bge(4) commit in question. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: em(4): Don't count RX overruns and missed packets as input errros
On Tue, Jan 28, 2014 at 02:08:09AM -0500, Brad Smith wrote:
On Tue, Jan 28, 2014 at 01:21:46PM +1000, David Gwynne wrote:
On 26 Jan 2014, at 11:31 am, Brad Smith b...@comstyle.com wrote:
On 31/12/13 5:50 AM, Mike Belopuhov wrote:
On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote:
On 31/12/13 3:14 AM, Mark Kettenis wrote:
Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith b...@comstyle.com
Don't count RX overruns and missed packets as inputs errors. They're
expected to increment when using MCLGETI.
OK?
These may be expected, but they're still packets that were not
received. And it is useful to know about these, for example when
debugging TCP performance issues.
Well do we want to keep just the missed packets or both? Part of the
diff was inspired by this commit when I was looking at what counters
were incrementing..
for bge(4)..
revision 1.334
date: 2013/06/06 00:05:30; author: dlg; state: Exp; lines: +2 -4;
dont count rx ring overruns as input errors. with MCLGETI controlling
the
ring we expect to run out of rx descriptors as a matter of course, its
not
an error.
ok mikeb@
it does screws up statistics big time. does mpc counter follow
rx_overruns?
why did we add them up both previously?
Yes, it does. I can't say why exactly but before MCLGETI for most
environments
it was unlikely to have RX overruns.
its not obvious?
rx rings are usually massively over provisioned. eg, my myx has 512 entries
in its
rx ring. however, its interrupt mitigation is currently configured for
approximately
16k interrupts a second. if you're sustaining 1m pps, then you can divide
that by the
interrupt rate to figure out the average usage of the rx ring. so 1000 / 16
is about
60-65 descriptors per interrupt. 512 is roughly an order of magnitude more
than what
you need for that workload.
if you were hitting the ring limits before MCLGETI, then that means you
dont have
enough cpu to process the pps. increasing the ring size would make it worse
cos you'd
spend more time freeing mbufs because you were too far behind on the pps
you could
deal with.
Ya, I don't know why I ultimately said I can't say why exactly as I was
thinking about
what you said regaring having a lot of buffers allocated and that's why I
said it was
unlikely to have RX overruns.
Since this was changed for bge(4) then the other drivers using MCLGETI should
be changed
as well if there is consensus about not adding the RX overruns to the
interfaces input
errors counter. But I think kettenis has a point as well that this
information is useful
its just we don't have any way of exposing that info to userland.
Ok, so I looked at the other drivers using MCLGETI and there are a few others
also
counting FIFO overruns towards input errors.
Index: arch/socppc/dev/if_tsec.c
===
RCS file: /home/cvs/src/sys/arch/socppc/dev/if_tsec.c,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 if_tsec.c
--- arch/socppc/dev/if_tsec.c 29 Nov 2012 21:10:31 - 1.29
+++ arch/socppc/dev/if_tsec.c 28 Jan 2014 05:16:24 -
@@ -779,7 +779,6 @@ tsec_errintr(void *arg)
*/
tsec_rx_proc(sc);
tsec_write(sc, TSEC_RSTAT, TSEC_RSTAT_QHLT);
- ifp-if_ierrors++;
}
return (1);
Index: dev/pci/if_se.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_se.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 if_se.c
--- dev/pci/if_se.c 28 Dec 2013 03:34:54 - 1.9
+++ dev/pci/if_se.c 28 Jan 2014 04:49:53 -
@@ -939,7 +939,8 @@ se_rxeof(struct se_softc *sc)
printf(%s: rx error %b\n,
ifp-if_xname, rxstat, RX_ERR_BITS);
se_discard_rxbuf(sc, i);
- ifp-if_ierrors++;
+ if ((rxstat RDS_OVRUN) == 0)
+ ifp-if_ierrors++;
continue;
}
Index: dev/pci/if_sis.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_sis.c,v
retrieving revision 1.115
diff -u -p -u -p -r1.115 if_sis.c
--- dev/pci/if_sis.c28 Dec 2013 03:34:54 - 1.115
+++ dev/pci/if_sis.c28 Jan 2014 04:51:53 -
@@ -1378,7 +1378,8 @@ sis_rxeof(struct sis_softc *sc)
total_len = (ETHER_MAX_DIX_LEN - ETHER_CRC_LEN))
rxstat = ~SIS_RXSTAT_GIANT;
if (SIS_RXSTAT_ERROR(rxstat)) {
- ifp-if_ierrors++;
+ if ((rxstat SIS_RXSTAT_OVERRUN) == 0)
+ ifp-if_ierrors++;
if (rxstat
Re: problem with gethostbyaddr() on OBSD 5.4?
On 31/01/14 7:17 PM, IMAP List Administration wrote: Hello Folks, I run a Postfix MTA on OpenBSD. Recently I migrated the server from OBSD v5.3 to v5.4. Soon afterwards I noticed postfix was falsely rejecting mails based on a FCrDNS (forward-confirmed reverse DNS) test. FCrDNS means the DNS configuration of a connecting client is tested for forward and reverse DNS consistency. I first suspected a change in Postfix, but the developer (Wietse Venema) ruled out any changes to this Postfix functionality. Further investigation shows that gethostbyaddr() behaves differently on OBSD 5.3 and 5.4. The problem seems to manifest itself when the DNS configuration of a client is non-trivial, e.g., when there are multiple PTR records, or when there is a CNAME record which must be resolved before a PTR lookup can be performed. I tested using a slightly modified Postfix utility (gethostbyaddr.c) which I attach below. On OBSD 5.4 this program returns correct results for trivial DNS client configurations, but host address not found for non-trivial ones. On OBSD 5.3 the program returns correct results in all cases. As far as I can tell, the two OBSD systems are configured identically. For example, /etc/resolv.conf has the same lookup order (lookup file bind), and the same nameserver. DNS tools such as host, dig, or Net::DNS return correct results. Here are some examples of IP-addresses that illustrate the problem: 195.234.50.30 72.26.200.202 96.47.67.46 173.231.138.204 To summarize, gethostbyaddr() on OBSD 5.4 does not seem to be behaving properly and not as it did on 5.3. Can anyone confirm this? Yes, I can reproduce the issue here even with -current. The resolver was replaced with the 5.4 release with a from scratch implementation so it isn't surprising there are some bugs lurking in the code that wouldn't be found until it has gone through more real world testing. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: bge(4): IPv6 checksum offload
On 27/01/14 3:30 PM, Christian Weisgerber wrote:
Some bge(4) chips support IPv6 TCP checksum transmit offload.
Unfortunately, I have no idea which. My best guess is that this
is symmetrical with the receive offload capability:
if (BGE_IS_5755_PLUS(sc))
mode |= BGE_RXMODE_IPV6_ENABLE;
After taking a look around at the various datasheets I was
going to propose more or less the same diff. The only difference
I had was moving it outside of the if (sc-bge_chipid !=
BGE_CHIPID_BCM5700_B0) check as 5755 and newer ASICs are
newer than the BCM5700 anyway.
So here is an experimental patch to enable it on 5755 and later
chips. Courageous people who use both IPv6 and bge(4) might want
to try it. If you do, please let me know about success and failure
and what chip.
$ dmesg | grep ^bge
bge0 at pci2 dev 0 function 0 Broadcom BCM5761 rev 0x10, BCM5761 A1
(0x5761100)
That's one that works.
I have also verified that UDP checksum offload is indeed broken as
the comment in the driver claims. For both IPv4 and IPv6, some
packets with checksum 0 are generated.
Index: if_bge.c
===
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.346
diff -u -p -r1.346 if_bge.c
--- if_bge.c30 Dec 2013 18:47:45 - 1.346
+++ if_bge.c27 Jan 2014 19:43:18 -
@@ -2942,8 +2942,11 @@ bge_attach(struct device *parent, struct
* offloading is enabled. Generating UDP checksum value 0 is
* a violation of RFC 768.
*/
- if (sc-bge_chipid != BGE_CHIPID_BCM5700_B0)
+ if (sc-bge_chipid != BGE_CHIPID_BCM5700_B0) {
ifp-if_capabilities |= IFCAP_CSUM_IPv4 | IFCAP_CSUM_TCPv4;
+ if (BGE_IS_5755_PLUS(sc))
+ ifp-if_capabilities |= IFCAP_CSUM_TCPv6;
+ }
if (BGE_IS_JUMBO_CAPABLE(sc))
ifp-if_hardmtu = BGE_JUMBO_MTU;
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: em(4): Don't count RX overruns and missed packets as input errros
On Tue, Jan 28, 2014 at 01:21:46PM +1000, David Gwynne wrote: On 26 Jan 2014, at 11:31 am, Brad Smith b...@comstyle.com wrote: On 31/12/13 5:50 AM, Mike Belopuhov wrote: On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote: On 31/12/13 3:14 AM, Mark Kettenis wrote: Date: Tue, 31 Dec 2013 01:28:04 -0500 From: Brad Smith b...@comstyle.com Don't count RX overruns and missed packets as inputs errors. They're expected to increment when using MCLGETI. OK? These may be expected, but they're still packets that were not received. And it is useful to know about these, for example when debugging TCP performance issues. Well do we want to keep just the missed packets or both? Part of the diff was inspired by this commit when I was looking at what counters were incrementing.. for bge(4).. revision 1.334 date: 2013/06/06 00:05:30; author: dlg; state: Exp; lines: +2 -4; dont count rx ring overruns as input errors. with MCLGETI controlling the ring we expect to run out of rx descriptors as a matter of course, its not an error. ok mikeb@ it does screws up statistics big time. does mpc counter follow rx_overruns? why did we add them up both previously? Yes, it does. I can't say why exactly but before MCLGETI for most environments it was unlikely to have RX overruns. its not obvious? rx rings are usually massively over provisioned. eg, my myx has 512 entries in its rx ring. however, its interrupt mitigation is currently configured for approximately 16k interrupts a second. if you're sustaining 1m pps, then you can divide that by the interrupt rate to figure out the average usage of the rx ring. so 1000 / 16 is about 60-65 descriptors per interrupt. 512 is roughly an order of magnitude more than what you need for that workload. if you were hitting the ring limits before MCLGETI, then that means you dont have enough cpu to process the pps. increasing the ring size would make it worse cos you'd spend more time freeing mbufs because you were too far behind on the pps you could deal with. Ya, I don't know why I ultimately said I can't say why exactly as I was thinking about what you said regaring having a lot of buffers allocated and that's why I said it was unlikely to have RX overruns. Since this was changed for bge(4) then the other drivers using MCLGETI should be changed as well if there is consensus about not adding the RX overruns to the interfaces input errors counter. But I think kettenis has a point as well that this information is useful its just we don't have any way of exposing that info to userland. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: em(4): Don't count RX overruns and missed packets as input errros
On 31/12/13 5:50 AM, Mike Belopuhov wrote: On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote: On 31/12/13 3:14 AM, Mark Kettenis wrote: Date: Tue, 31 Dec 2013 01:28:04 -0500 From: Brad Smith b...@comstyle.com Don't count RX overruns and missed packets as inputs errors. They're expected to increment when using MCLGETI. OK? These may be expected, but they're still packets that were not received. And it is useful to know about these, for example when debugging TCP performance issues. Well do we want to keep just the missed packets or both? Part of the diff was inspired by this commit when I was looking at what counters were incrementing.. for bge(4).. revision 1.334 date: 2013/06/06 00:05:30; author: dlg; state: Exp; lines: +2 -4; dont count rx ring overruns as input errors. with MCLGETI controlling the ring we expect to run out of rx descriptors as a matter of course, its not an error. ok mikeb@ it does screws up statistics big time. does mpc counter follow rx_overruns? why did we add them up both previously? Yes, it does. I can't say why exactly but before MCLGETI for most environments it was unlikely to have RX overruns. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: rc default PF ruleset too restrictive for DHCPv6
On Sun, Jan 19, 2014 at 04:10:21AM +0100, Claudio Jeker wrote:
On Sat, Jan 18, 2014 at 09:57:26PM -0500, Brad wrote:
On Thu, Jan 09, 2014 at 03:55:44PM -0500, Brad Smith wrote:
The default PF ruleset as setup by rc is too restrictive. Have the default
ruleset allow for DHCPv6.
Anyone?
Looks good to me. OK claudio@
Question: should we add the same for inet as well since dhclient may use
a normal udp socket in some cases?
Untested on the v4 side but how about something like the following?
Index: rc
===
RCS file: /home/cvs/src/etc/rc,v
retrieving revision 1.419
diff -u -p -u -p -r1.419 rc
--- rc 3 Jan 2014 23:24:19 - 1.419
+++ rc 19 Jan 2014 08:32:17 -
@@ -325,11 +325,15 @@ if [ X${pf} != XNO ]; then
RULES=$RULES\npass in proto tcp from any to any port 22 keep state
RULES=$RULES\npass out proto { tcp, udp } from any to any port 53 keep
state
RULES=$RULES\npass out inet proto icmp all icmp-type echoreq keep
state
+ RULES=$RULES\npass out inet proto udp from any port bootpc to any port
bootps
+ RULES=$RULES\npass in inet proto udp from any port bootps to any port
bootpc
if ifconfig lo0 inet6 /dev/null 21; then
RULES=$RULES\npass out inet6 proto icmp6 all icmp6-type
neighbrsol
RULES=$RULES\npass in inet6 proto icmp6 all icmp6-type
neighbradv
RULES=$RULES\npass out inet6 proto icmp6 all icmp6-type
routersol
RULES=$RULES\npass in inet6 proto icmp6 all icmp6-type
routeradv
+ RULES=$RULES\npass out inet6 proto udp from any port
dhcpv6-client to any port dhcpv6-server
+ RULES=$RULES\npass in inet6 proto udp from any port
dhcpv6-server to any port dhcpv6-client
fi
RULES=$RULES\npass proto carp keep state (no-sync)
case `sysctl vfs.mounts.nfs 2/dev/null` in
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: rc default PF ruleset too restrictive for DHCPv6
On Thu, Jan 09, 2014 at 03:55:44PM -0500, Brad Smith wrote:
The default PF ruleset as setup by rc is too restrictive. Have the default
ruleset allow for DHCPv6.
Anyone?
Index: rc
===
RCS file: /home/cvs/src/etc/rc,v
retrieving revision 1.419
diff -u -p -u -p -r1.419 rc
--- rc3 Jan 2014 23:24:19 - 1.419
+++ rc9 Jan 2014 20:47:07 -
@@ -330,6 +330,8 @@ if [ X${pf} != XNO ]; then
RULES=$RULES\npass in inet6 proto icmp6 all icmp6-type
neighbradv
RULES=$RULES\npass out inet6 proto icmp6 all icmp6-type
routersol
RULES=$RULES\npass in inet6 proto icmp6 all icmp6-type
routeradv
+ RULES=$RULES\npass out inet6 proto udp from any port
dhcpv6-client to any port dhcpv6-server
+ RULES=$RULES\npass in inet6 proto udp from any port
dhcpv6-server to any port dhcpv6-client
fi
RULES=$RULES\npass proto carp keep state (no-sync)
case `sysctl vfs.mounts.nfs 2/dev/null` in
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: rc default PF ruleset too restrictive for DHCPv6
On Sun, Jan 19, 2014 at 04:10:21AM +0100, Claudio Jeker wrote: On Sat, Jan 18, 2014 at 09:57:26PM -0500, Brad wrote: On Thu, Jan 09, 2014 at 03:55:44PM -0500, Brad Smith wrote: The default PF ruleset as setup by rc is too restrictive. Have the default ruleset allow for DHCPv6. Anyone? Looks good to me. OK claudio@ Question: should we add the same for inet as well since dhclient may use a normal udp socket in some cases? Curious, under what conditions is this possible? A particular client implementation? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: top(1) interactive commands after SIGWINCH
On 13/01/14 12:04 PM, Stuart Henderson wrote: If anyone is interested in looking at a signal problem in top, here's a small but annoying bug.. - run top in an xterm - resize the window - try to use an interactive command that takes an argument, e.g. s or g (doesn't happen with commands like S or H that work immediately) Often, pressing the command key just refreshes the screen, it takes multiple attempts for the command to take effect (sometimes just a couple, sometimes loads of attempts). This happens whether you resize the window or not. Seemingly the longer top is running the longer I have to hold down the key to have top respond. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Patch: pcidevs for new intel host bridge and radeon gpu
On 10/01/14 4:05 PM, mark rowland wrote: The entry for intel product 0x0a04 was not in the right spot, new diff: --- /usr/src/sys/dev/pci/pcidevsWed Jan 8 23:52:05 2014 +++ pcidevs Fri Jan 10 21:54:24 2014 @@ -1293,7 +1293,7 @@ product ATI RADEON_X700_PCIE_S0x5e6d Radeon X700 PCIE Sec product ATI RADEON_X700_SE0x5e4f Radeon X700 SE product ATI RADEON_X700_SE_S 0x5e6f Radeon X700 SE Sec -product ATI RADEON_HD8670A 0x6600 Radeon HD 8670A +product ATI RADEON_HD8670A_HD8750M 0x6600 Radeon HD 8670A/8750M product ATI RADEON_HD8730M0x6601 Radeon HD 8730M product ATI OLAND_1 0x6602 Oland product ATI OLAND_2 0x6603 Oland @@ -2836,6 +2836,7 @@ product INTEL 80960RM 0x0962 i960 RM product INTEL 80960RN 0x0964 i960 RN product INTEL CORE4G_D_ULT_GT10x0a02 HD Graphics +product INTEL CORE4G_HB_1 0x0a04 Core 4G Host product INTEL CORE4G_M_ULT_GT10x0a06 HD Graphics product INTEL CORE4G_S_ULT_GT10x0a0a HD Graphics product INTEL CORE4G_R_ULT_GT1_1 0x0a0b HD Graphics @@ -2853,7 +2854,7 @@ product INTEL CORE4G_R_ULT_GT3_2 0x0a2e Iris Graphics 5100 product INTEL D2000_IGD 0x0be1 Atom D2000/N2000 Video product INTEL D2000_HB0x0bf5 Atom D2000/N2000 Host -product INTEL CORE4G_HB0x0c00 Core 4G Host +product INTEL CORE4G_HB_2 0x0c00 Core 4G Host product INTEL CORE4G_PCIE_1 0x0c01 Core 4G PCIE product INTEL CORE4G_D_SDV_GT10x0c02 HD Graphics product INTEL CORE4G_PCIE_2 0x0c05 Core 4G PCIE I didn't bother changing the Radeon entry. There are more than enough PCI ids in similar situations with a single id representing multiple devices from a marketing perspective and with different names/models and so forth. The entry as is gives us a good enough idea of what it is. The relevant drivers that might use the entry will do the right thing whether it prints all the relevant devices supported or not ;) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: em(4): Don't count RX overruns and missed packets as input errros
On 31/12/13 3:14 AM, Mark Kettenis wrote: Date: Tue, 31 Dec 2013 01:28:04 -0500 From: Brad Smith b...@comstyle.com Don't count RX overruns and missed packets as inputs errors. They're expected to increment when using MCLGETI. OK? These may be expected, but they're still packets that were not received. And it is useful to know about these, for example when debugging TCP performance issues. Well do we want to keep just the missed packets or both? Part of the diff was inspired by this commit when I was looking at what counters were incrementing.. for bge(4).. revision 1.334 date: 2013/06/06 00:05:30; author: dlg; state: Exp; lines: +2 -4; dont count rx ring overruns as input errors. with MCLGETI controlling the ring we expect to run out of rx descriptors as a matter of course, its not an error. ok mikeb@ Index: if_em.c === RCS file: /cvs/src/sys/dev/pci/if_em.c,v retrieving revision 1.275 diff -u -p -u -p -r1.275 if_em.c --- if_em.c 28 Dec 2013 03:34:54 - 1.275 +++ if_em.c 31 Dec 2013 06:03:55 - @@ -3246,9 +3248,9 @@ em_update_stats_counters(struct em_softc sc-stats.rxerrc + sc-stats.crcerrs + sc-stats.algnerrc + - sc-stats.ruc + sc-stats.roc + - sc-stats.mpc + sc-stats.cexterr + - sc-rx_overruns; + sc-stats.ruc + + sc-stats.roc + + sc-stats.cexterr; /* Tx Errors */ ifp-if_oerrors = sc-stats.ecol + sc-stats.latecol + -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: re(4): tedu some unused code
On Tue, Dec 31, 2013 at 09:55:54AM -0800, Chris Cappuccio wrote:
Brad Smith [b...@comstyle.com] wrote:
tedu some unused code. it has never been enabled and will not be; to
deal with a hardware defect for rare boards. unmaintained, untested, etc.
want to get rid of it.
Comments? OK?
If RE_DIAG wasn't being compiled in, then it should be removed. The BUGS
section of re(4) needs to be updated to reflect the fact that the driver
does not detect this condition.
Good idea especially since it has never been enabled so the driver
has never been able to detect this defective hardware.
Index: sys/dev/ic/re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.146
diff -u -p -r1.146 re.c
--- sys/dev/ic/re.c 25 Oct 2013 22:48:10 - 1.146
+++ sys/dev/ic/re.c 31 Dec 2013 00:49:27 -
@@ -197,10 +197,6 @@ void re_setup_intr(struct rl_softc *, in
intre_wol(struct ifnet*, int);
#endif
-#ifdef RE_DIAG
-intre_diag(struct rl_softc *);
-#endif
-
struct cfdriver re_cd = {
0, re, DV_IFNET
};
@@ -615,190 +611,6 @@ re_reset(struct rl_softc *sc)
CSR_WRITE_1(sc, RL_LDPS, 1);
}
-#ifdef RE_DIAG
-
-/*
- * The following routine is designed to test for a defect on some
- * 32-bit 8169 cards. Some of these NICs have the REQ64# and ACK64#
- * lines connected to the bus, however for a 32-bit only card, they
- * should be pulled high. The result of this defect is that the
- * NIC will not work right if you plug it into a 64-bit slot: DMA
- * operations will be done with 64-bit transfers, which will fail
- * because the 64-bit data lines aren't connected.
- *
- * There's no way to work around this (short of talking a soldering
- * iron to the board), however we can detect it. The method we use
- * here is to put the NIC into digital loopback mode, set the receiver
- * to promiscuous mode, and then try to send a frame. We then compare
- * the frame data we sent to what was received. If the data matches,
- * then the NIC is working correctly, otherwise we know the user has
- * a defective NIC which has been mistakenly plugged into a 64-bit PCI
- * slot. In the latter case, there's no way the NIC can work correctly,
- * so we print out a message on the console and abort the device attach.
- */
-
-int
-re_diag(struct rl_softc *sc)
-{
- struct ifnet*ifp = sc-sc_arpcom.ac_if;
- struct mbuf *m0;
- struct ether_header *eh;
- struct rl_rxsoft*rxs;
- struct rl_desc *cur_rx;
- bus_dmamap_tdmamap;
- u_int16_t status;
- u_int32_t rxstat;
- int total_len, i, s, error = 0, phyaddr;
- u_int8_tdst[] = { 0x00, 'h', 'e', 'l', 'l', 'o' };
- u_int8_tsrc[] = { 0x00, 'w', 'o', 'r', 'l', 'd' };
-
- DPRINTF((inside re_diag\n));
- /* Allocate a single mbuf */
-
- MGETHDR(m0, M_DONTWAIT, MT_DATA);
- if (m0 == NULL)
- return (ENOBUFS);
-
- /*
-* Initialize the NIC in test mode. This sets the chip up
-* so that it can send and receive frames, but performs the
-* following special functions:
-* - Puts receiver in promiscuous mode
-* - Enables digital loopback mode
-* - Leaves interrupts turned off
-*/
-
- ifp-if_flags |= IFF_PROMISC;
- sc-rl_testmode = 1;
- re_reset(sc);
- re_init(ifp);
- sc-rl_flags |= RL_FLAG_LINK;
- if (sc-sc_hwrev == RL_HWREV_8139CPLUS)
- phyaddr = 0;
- else
- phyaddr = 1;
-
- re_miibus_writereg((struct device *)sc, phyaddr, MII_BMCR,
- BMCR_RESET);
- for (i = 0; i RL_TIMEOUT; i++) {
- status = re_miibus_readreg((struct device *)sc,
- phyaddr, MII_BMCR);
- if (!(status BMCR_RESET))
- break;
- }
-
- re_miibus_writereg((struct device *)sc, phyaddr, MII_BMCR,
- BMCR_LOOP);
- CSR_WRITE_2(sc, RL_ISR, RL_INTRS);
-
- DELAY(10);
-
- /* Put some data in the mbuf */
-
- eh = mtod(m0, struct ether_header *);
- bcopy ((char *)dst, eh-ether_dhost, ETHER_ADDR_LEN);
- bcopy ((char *)src, eh-ether_shost, ETHER_ADDR_LEN);
- eh-ether_type = htons(ETHERTYPE_IP);
- m0-m_pkthdr.len = m0-m_len = ETHER_MIN_LEN - ETHER_CRC_LEN;
-
- /*
-* Queue the packet, start transmission.
-*/
-
- CSR_WRITE_2(sc, RL_ISR, 0x);
- s = splnet();
- IFQ_ENQUEUE(ifp-if_snd, m0, NULL, error);
- re_start(ifp);
- splx(s);
- m0 = NULL;
-
- DPRINTF((re_diag: transmission started\n));
-
- /* Wait for it to propagate through the chip */
-
- DELAY(10);
- for (i = 0; i RL_TIMEOUT; i++) {
- status
Re: em(4): Don't count RX overruns and missed packets as input errros
On 31/12/13 5:50 AM, Mike Belopuhov wrote: On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote: On 31/12/13 3:14 AM, Mark Kettenis wrote: Date: Tue, 31 Dec 2013 01:28:04 -0500 From: Brad Smith b...@comstyle.com Don't count RX overruns and missed packets as inputs errors. They're expected to increment when using MCLGETI. OK? These may be expected, but they're still packets that were not received. And it is useful to know about these, for example when debugging TCP performance issues. Well do we want to keep just the missed packets or both? Part of the diff was inspired by this commit when I was looking at what counters were incrementing.. for bge(4).. revision 1.334 date: 2013/06/06 00:05:30; author: dlg; state: Exp; lines: +2 -4; dont count rx ring overruns as input errors. with MCLGETI controlling the ring we expect to run out of rx descriptors as a matter of course, its not an error. ok mikeb@ it does screws up statistics big time. does mpc counter follow rx_overruns? why did we add them up both previously? .e.g. em0: Missed Packets = 1925 em0: RX overruns = 267 em0: Good Packets Rcvd = 22279749 this already wasn't being counted but for reference.. em0: Receive No Buffers = 24382 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: call for testing: MSI for msk(4)
On 16/05/13 5:55 PM, Jérémie Courrèges-Anglas wrote: Hi, I've been using msk(4) with MSI on my laptop since a few days, with no apparent problem. mskc0 at pci2 dev 0 function 0 Marvell Yukon 88E8040 rev 0x13, Yukon-2 FE+ rev. A0 (0x0): msi msk0 at mskc0 port A: address 00:24:54:xx:xx:xx eephy0 at msk0 phy 0: 88E3016 10/100 PHY, rev. 0 Other systems all seem to use MSI, but it would be cool if people with different chips could test it. Any other msk(4) users? It has also been tested with EC 8052/EC Ultra 8058 controllers and working. I don't see any indication of any issues or errata regarding MSI operation in either of the FreeBSD or Linux drivers. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
re(4): tedu some unused code
tedu some unused code. it has never been enabled and will not be; to
deal with a hardware defect for rare boards. unmaintained, untested, etc.
want to get rid of it.
Comments? OK?
Index: re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.146
diff -u -p -r1.146 re.c
--- re.c25 Oct 2013 22:48:10 - 1.146
+++ re.c31 Dec 2013 00:49:27 -
@@ -197,10 +197,6 @@ void re_setup_intr(struct rl_softc *, in
intre_wol(struct ifnet*, int);
#endif
-#ifdef RE_DIAG
-intre_diag(struct rl_softc *);
-#endif
-
struct cfdriver re_cd = {
0, re, DV_IFNET
};
@@ -615,190 +611,6 @@ re_reset(struct rl_softc *sc)
CSR_WRITE_1(sc, RL_LDPS, 1);
}
-#ifdef RE_DIAG
-
-/*
- * The following routine is designed to test for a defect on some
- * 32-bit 8169 cards. Some of these NICs have the REQ64# and ACK64#
- * lines connected to the bus, however for a 32-bit only card, they
- * should be pulled high. The result of this defect is that the
- * NIC will not work right if you plug it into a 64-bit slot: DMA
- * operations will be done with 64-bit transfers, which will fail
- * because the 64-bit data lines aren't connected.
- *
- * There's no way to work around this (short of talking a soldering
- * iron to the board), however we can detect it. The method we use
- * here is to put the NIC into digital loopback mode, set the receiver
- * to promiscuous mode, and then try to send a frame. We then compare
- * the frame data we sent to what was received. If the data matches,
- * then the NIC is working correctly, otherwise we know the user has
- * a defective NIC which has been mistakenly plugged into a 64-bit PCI
- * slot. In the latter case, there's no way the NIC can work correctly,
- * so we print out a message on the console and abort the device attach.
- */
-
-int
-re_diag(struct rl_softc *sc)
-{
- struct ifnet*ifp = sc-sc_arpcom.ac_if;
- struct mbuf *m0;
- struct ether_header *eh;
- struct rl_rxsoft*rxs;
- struct rl_desc *cur_rx;
- bus_dmamap_tdmamap;
- u_int16_t status;
- u_int32_t rxstat;
- int total_len, i, s, error = 0, phyaddr;
- u_int8_tdst[] = { 0x00, 'h', 'e', 'l', 'l', 'o' };
- u_int8_tsrc[] = { 0x00, 'w', 'o', 'r', 'l', 'd' };
-
- DPRINTF((inside re_diag\n));
- /* Allocate a single mbuf */
-
- MGETHDR(m0, M_DONTWAIT, MT_DATA);
- if (m0 == NULL)
- return (ENOBUFS);
-
- /*
-* Initialize the NIC in test mode. This sets the chip up
-* so that it can send and receive frames, but performs the
-* following special functions:
-* - Puts receiver in promiscuous mode
-* - Enables digital loopback mode
-* - Leaves interrupts turned off
-*/
-
- ifp-if_flags |= IFF_PROMISC;
- sc-rl_testmode = 1;
- re_reset(sc);
- re_init(ifp);
- sc-rl_flags |= RL_FLAG_LINK;
- if (sc-sc_hwrev == RL_HWREV_8139CPLUS)
- phyaddr = 0;
- else
- phyaddr = 1;
-
- re_miibus_writereg((struct device *)sc, phyaddr, MII_BMCR,
- BMCR_RESET);
- for (i = 0; i RL_TIMEOUT; i++) {
- status = re_miibus_readreg((struct device *)sc,
- phyaddr, MII_BMCR);
- if (!(status BMCR_RESET))
- break;
- }
-
- re_miibus_writereg((struct device *)sc, phyaddr, MII_BMCR,
- BMCR_LOOP);
- CSR_WRITE_2(sc, RL_ISR, RL_INTRS);
-
- DELAY(10);
-
- /* Put some data in the mbuf */
-
- eh = mtod(m0, struct ether_header *);
- bcopy ((char *)dst, eh-ether_dhost, ETHER_ADDR_LEN);
- bcopy ((char *)src, eh-ether_shost, ETHER_ADDR_LEN);
- eh-ether_type = htons(ETHERTYPE_IP);
- m0-m_pkthdr.len = m0-m_len = ETHER_MIN_LEN - ETHER_CRC_LEN;
-
- /*
-* Queue the packet, start transmission.
-*/
-
- CSR_WRITE_2(sc, RL_ISR, 0x);
- s = splnet();
- IFQ_ENQUEUE(ifp-if_snd, m0, NULL, error);
- re_start(ifp);
- splx(s);
- m0 = NULL;
-
- DPRINTF((re_diag: transmission started\n));
-
- /* Wait for it to propagate through the chip */
-
- DELAY(10);
- for (i = 0; i RL_TIMEOUT; i++) {
- status = CSR_READ_2(sc, RL_ISR);
- CSR_WRITE_2(sc, RL_ISR, status);
- if ((status (RL_ISR_TIMEOUT_EXPIRED|RL_ISR_RX_OK)) ==
- (RL_ISR_TIMEOUT_EXPIRED|RL_ISR_RX_OK))
- break;
- DELAY(10);
- }
- if (i == RL_TIMEOUT) {
- printf(%s: diagnostic failed, failed to receive packet
- in loopback mode\n, sc-sc_dev.dv_xname);
- error =
em(4): Don't count RX overruns and missed packets as input errros
Don't count RX overruns and missed packets as inputs errors. They're expected to increment when using MCLGETI. OK? Index: if_em.c === RCS file: /cvs/src/sys/dev/pci/if_em.c,v retrieving revision 1.275 diff -u -p -u -p -r1.275 if_em.c --- if_em.c 28 Dec 2013 03:34:54 - 1.275 +++ if_em.c 31 Dec 2013 06:03:55 - @@ -3246,9 +3248,9 @@ em_update_stats_counters(struct em_softc sc-stats.rxerrc + sc-stats.crcerrs + sc-stats.algnerrc + - sc-stats.ruc + sc-stats.roc + - sc-stats.mpc + sc-stats.cexterr + - sc-rx_overruns; + sc-stats.ruc + + sc-stats.roc + + sc-stats.cexterr; /* Tx Errors */ ifp-if_oerrors = sc-stats.ecol + sc-stats.latecol + -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
rgephy(4): Always use RL_GMEDIASTAT for reading link/media status for re(4) PHY
This moves rgephy(4) back to using RL_GMEDIASTAT to read the link/media
status for re(4) attached Realtek PHY as was done before rev 1.25. rev
1.25 was to add support for external rgephy(4) attached to other MAC
such as nfe(4), but the PHY Specific Status register doesn't seem to
work properly with some integrated PHY with re(4).
Tested with..
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5
and some newer PHY where this was problematic but existing 8169 PHY
rev board combos are affected too.
From FreeBSD and matches what the Linux driver does.
Index: rgephy.c
===
RCS file: /home/cvs/src/sys/dev/mii/rgephy.c,v
retrieving revision 1.30
diff -u -p -r1.30 rgephy.c
--- rgephy.c28 May 2013 09:46:06 - 1.30
+++ rgephy.c19 Dec 2013 11:13:54 -
@@ -145,6 +145,9 @@ rgephy_service(struct mii_softc *sc, str
{
struct ifmedia_entry *ife = mii-mii_media.ifm_cur;
int anar, reg, speed, gig = 0;
+ char *devname;
+
+ devname = sc-mii_dev.dv_parent-dv_cfdata-cf_driver-cd_name;
switch (cmd) {
case MII_POLLSTAT:
@@ -249,7 +252,7 @@ setit:
* need to restart the autonegotiation process. Read
* the BMSR twice in case it's latched.
*/
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
reg = PHY_READ(sc, RL_GMEDIASTAT);
if (reg RL_GMEDIASTAT_LINK) {
sc-mii_ticks = 0;
@@ -298,13 +301,15 @@ rgephy_status(struct mii_softc *sc)
{
struct mii_data *mii = sc-mii_pdata;
int bmsr, bmcr, gtsr;
+ char *devname;
+
+ devname = sc-mii_dev.dv_parent-dv_cfdata-cf_driver-cd_name;
mii-mii_media_status = IFM_AVALID;
mii-mii_media_active = IFM_ETHER;
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
bmsr = PHY_READ(sc, RL_GMEDIASTAT);
-
if (bmsr RL_GMEDIASTAT_LINK)
mii-mii_media_status |= IFM_ACTIVE;
} else {
@@ -328,7 +333,7 @@ rgephy_status(struct mii_softc *sc)
}
}
- if (sc-mii_rev 2) {
+ if (strcmp(devname, re) == 0) {
bmsr = PHY_READ(sc, RL_GMEDIASTAT);
if (bmsr RL_GMEDIASTAT_1000MBPS)
mii-mii_media_active |= IFM_1000_T;
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: LLVM warning in sys/uvm/uvm_map.c
On Tue, Dec 03, 2013 at 06:48:11PM -0500, Brad Smith wrote:
An unused function in the UVM code. #if 0 it out for now.
uvm_map.c:171:14: error: unused function 'uvm_mapentry_freecmp'
[-Werror,-Wunused-function]
uvm_map.c:353:1: error: unused function 'uvm_mapentry_freecmp'
[-Werror,-Wunused-function]
OK?
Index: uvm_map.c
===
RCS file: /home/cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.163
diff -u -p -r1.163 uvm_map.c
--- uvm_map.c 21 Sep 2013 10:01:27 - 1.163
+++ uvm_map.c 3 Dec 2013 23:27:50 -
@@ -168,8 +168,10 @@ static __inline void uvm_mapent_copy(st
struct vm_map_entry*);
static intuvm_mapentry_addrcmp(struct vm_map_entry*,
struct vm_map_entry*);
+#if 0
static intuvm_mapentry_freecmp(struct vm_map_entry*,
struct vm_map_entry*);
+#endif
void uvm_mapent_free_insert(struct vm_map*,
struct uvm_addr_state*, struct vm_map_entry*);
void uvm_mapent_free_remove(struct vm_map*,
@@ -349,12 +351,14 @@ uvm_mapentry_addrcmp(struct vm_map_entry
* tree will be considered during 'any address' allocations.
*/
+#if 0
static __inline int
uvm_mapentry_freecmp(struct vm_map_entry *e1, struct vm_map_entry *e2)
{
int cmp = e1-fspace e2-fspace ? -1 : e1-fspace e2-fspace;
return cmp ? cmp : uvm_mapentry_addrcmp(e1, e2);
}
+#endif
/*
* Copy mapentry.
So which one will it be?
Index: uvm_map.c
===
RCS file: /home/cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.163
diff -u -p -r1.163 uvm_map.c
--- uvm_map.c 21 Sep 2013 10:01:27 - 1.163
+++ uvm_map.c 7 Dec 2013 01:45:17 -
@@ -349,7 +349,7 @@ uvm_mapentry_addrcmp(struct vm_map_entry
* tree will be considered during 'any address' allocations.
*/
-static __inline int
+__unused static __inline int
uvm_mapentry_freecmp(struct vm_map_entry *e1, struct vm_map_entry *e2)
{
int cmp = e1-fspace e2-fspace ? -1 : e1-fspace e2-fspace;
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: LLVM warning in sys/compat/linux/linux_misc.c
On 28/11/13 10:05 PM, Brad Smith wrote:
Remove unsigned comparison 0.
../../../../compat/linux/linux_misc.c:1531:24: error: comparison of unsigned
expression 0 is always false [-Werror,-Wtautological-compare]
Comments? OK?
ping.
Index: linux_misc.c
===
RCS file: /home/cvs/src/sys/compat/linux/linux_misc.c,v
retrieving revision 1.83
diff -u -p -r1.83 linux_misc.c
--- linux_misc.c25 Oct 2013 05:10:03 - 1.83
+++ linux_misc.c29 Nov 2013 02:32:48 -
@@ -1657,7 +1657,7 @@ linux_sys_prctl(struct proc *p, void *v,
switch (SCARG(uap, option)) {
case LINUX_PR_SET_PDEATHSIG:
- if (SCARG(uap, arg2) 0 || SCARG(uap, arg2) = LINUX__NSIG)
+ if (SCARG(uap, arg2) = LINUX__NSIG)
return (EINVAL);
ed-pdeath_signal = SCARG(uap, arg2);
break;
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: cdce / cdce / urndis ioctl handling clean up
On 02/12/13 6:28 PM, Brad Smith wrote:
Some clean up to the cdce / cdcef and urndis ioctl handlers to bring things
in line with the other Ethernet drivers. no functional change.
OK?
ping.
Index: if_cdce.c
===
RCS file: /home/cvs/src/sys/dev/usb/if_cdce.c,v
retrieving revision 1.57
diff -u -p -r1.57 if_cdce.c
--- if_cdce.c 15 Nov 2013 10:17:39 - 1.57
+++ if_cdce.c 17 Nov 2013 05:31:47 -
@@ -528,23 +528,24 @@ cdce_ioctl(struct ifnet *ifp, u_long com
switch(command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- cdce_init(sc);
- switch (ifa-ifa_addr-sa_family) {
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
+ cdce_init(sc);
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-cdce_arpcom, ifa);
- break;
- }
+#endif
break;
case SIOCSIFFLAGS:
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_flags IFF_RUNNING))
+ if (ifp-if_flags IFF_RUNNING)
+ error = ENETRESET;
+ else
cdce_init(sc);
} else {
if (ifp-if_flags IFF_RUNNING)
cdce_stop(sc);
}
- error = 0;
break;
default:
@@ -579,9 +580,6 @@ cdce_init(void *xsc)
struct cdce_chain *c;
usbd_status err;
int s, i;
-
- if (ifp-if_flags IFF_RUNNING)
- return;
s = splnet();
Index: if_cdcef.c
===
RCS file: /home/cvs/src/sys/dev/usb/if_cdcef.c,v
retrieving revision 1.31
diff -u -p -r1.31 if_cdcef.c
--- if_cdcef.c 11 Nov 2013 10:09:40 - 1.31
+++ if_cdcef.c 20 Nov 2013 03:06:34 -
@@ -477,23 +477,24 @@ cdcef_ioctl(struct ifnet *ifp, u_long co
switch (command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- cdcef_init(sc);
- switch (ifa-ifa_addr-sa_family) {
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
+ cdcef_init(sc);
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-sc_arpcom, ifa);
- break;
- }
+#endif
break;
case SIOCSIFFLAGS:
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_flags IFF_RUNNING))
+ if (ifp-if_flags IFF_RUNNING)
+ error = ENETRESET;
+ else
cdcef_init(sc);
} else {
if (ifp-if_flags IFF_RUNNING)
cdcef_stop(sc);
}
- error = 0;
break;
default:
@@ -528,10 +529,9 @@ cdcef_watchdog(struct ifnet *ifp)
void
cdcef_init(struct cdcef_softc *sc)
{
- int s;
struct ifnet*ifp = GET_IFP(sc);
- if (ifp-if_flags IFF_RUNNING)
- return;
+ int s;
+
s = splnet();
ifp-if_flags |= IFF_RUNNING;
Index: if_urndis.c
===
RCS file: /home/cvs/src/sys/dev/usb/if_urndis.c,v
retrieving revision 1.43
diff -u -p -r1.43 if_urndis.c
--- if_urndis.c 15 Nov 2013 10:17:39 - 1.43
+++ if_urndis.c 20 Nov 2013 03:10:53 -
@@ -985,13 +985,9 @@ urndis_tx_list_init(struct urndis_softc
int
urndis_ioctl(struct ifnet *ifp, u_long command, caddr_t data)
{
- struct urndis_softc *sc;
- struct ifaddr *ifa;
- int s, error;
-
- sc = ifp-if_softc;
- ifa = (struct ifaddr *)data;
- error = 0;
+ struct urndis_softc *sc = ifp-if_softc;
+ struct ifaddr *ifa = (struct ifaddr *)data;
+ int s, error = 0;
if (usbd_is_dying(sc-sc_udev))
return (EIO);
@@ -1001,24 +997,24 @@ urndis_ioctl(struct ifnet *ifp, u_long c
switch(command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- urndis_init(sc);
-
- switch (ifa-ifa_addr-sa_family) {
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
+ urndis_init(sc);
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-sc_arpcom, ifa);
- break;
- }
+#endif
break;
case SIOCSIFFLAGS:
if (ifp-if_flags IFF_UP
Re: LLVM warning in sys/uvm/uvm_map.c
On 06/12/13 11:39 PM, Ted Unangst wrote: On Fri, Dec 06, 2013 at 20:47, Brad Smith wrote: On Tue, Dec 03, 2013 at 06:48:11PM -0500, Brad Smith wrote: An unused function in the UVM code. #if 0 it out for now. uvm_map.c:171:14: error: unused function 'uvm_mapentry_freecmp' [-Werror,-Wunused-function] uvm_map.c:353:1: error: unused function 'uvm_mapentry_freecmp' [-Werror,-Wunused-function] I haven't looked yet to convince myself that we aren't supposed to be calling this function somewhere. Having an unused function isn't hurting us, I don't think there's a rush here. The function isn't being called anywhere in the tree. You're missing the point. The kernel builds with -Werror. I wouldn't care about these warnings if it didn't. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: LLVM warning in dev/ic/uhci.c
On Wed, Dec 04, 2013 at 05:04:13PM +0100, Mark Kettenis wrote:
Date: Wed, 4 Dec 2013 12:53:20 +0100
From: Joerg Sonnenberger jo...@britannica.bec.de
On Wed, Dec 04, 2013 at 12:24:50PM +0100, Mark Kettenis wrote:
Sorry, but I disagree with LLVM here. It shouldn't complain about
static inline functions.
Then mark them as unused, just like you would with a static variable you
insist on keeping.
Thanks Joerg, that might work.
Brad, does LLVM like the diff below? Note this changes ohci.c not
uhci.c since I happened to have some uncommtted changes in the latter
that I didn't want to touch.
Index: ohci.c
===
RCS file: /cvs/src/sys/dev/usb/ohci.c,v
retrieving revision 1.116
diff -u -p -r1.116 ohci.c
--- ohci.c9 Nov 2013 08:46:05 - 1.116
+++ ohci.c4 Dec 2013 16:01:42 -
@@ -189,21 +189,21 @@ voidohci_dump_itds(struct ohci_soft_it
#define OWRITE4(sc, r, x) \
do { OBARR(sc); bus_space_write_4((sc)-iot, (sc)-ioh, (r), (x)); } while
(0)
-static __inline u_int8_t
+__unused static __inline u_int8_t
OREAD1(struct ohci_softc *sc, bus_size_t r)
{
OBARR(sc);
return bus_space_read_1(sc-iot, sc-ioh, r);
}
-static __inline u_int16_t
+__unused static __inline u_int16_t
OREAD2(struct ohci_softc *sc, bus_size_t r)
{
OBARR(sc);
return bus_space_read_2(sc-iot, sc-ioh, r);
}
-static __inline u_int32_t
+__unused static __inline u_int32_t
OREAD4(struct ohci_softc *sc, bus_size_t r)
{
OBARR(sc);
Yes, this does indeed silence the warning. So you want something like the
following?
Index: ohci.c
===
RCS file: /home/cvs/src/sys/dev/usb/ohci.c,v
retrieving revision 1.116
diff -u -p -r1.116 ohci.c
--- ohci.c 9 Nov 2013 08:46:05 - 1.116
+++ ohci.c 5 Dec 2013 20:41:53 -
@@ -189,21 +189,21 @@ void ohci_dump_itds(struct ohci_soft_it
#define OWRITE4(sc, r, x) \
do { OBARR(sc); bus_space_write_4((sc)-iot, (sc)-ioh, (r), (x)); } while (0)
-static __inline u_int8_t
+__unused static __inline u_int8_t
OREAD1(struct ohci_softc *sc, bus_size_t r)
{
OBARR(sc);
return bus_space_read_1(sc-iot, sc-ioh, r);
}
-static __inline u_int16_t
+__unused static __inline u_int16_t
OREAD2(struct ohci_softc *sc, bus_size_t r)
{
OBARR(sc);
return bus_space_read_2(sc-iot, sc-ioh, r);
}
-static __inline u_int32_t
+__unused static __inline u_int32_t
OREAD4(struct ohci_softc *sc, bus_size_t r)
{
OBARR(sc);
Index: uhci.c
===
RCS file: /home/cvs/src/sys/dev/usb/uhci.c,v
retrieving revision 1.104
diff -u -p -r1.104 uhci.c
--- uhci.c 9 Nov 2013 08:46:05 - 1.104
+++ uhci.c 5 Dec 2013 20:42:24 -
@@ -238,21 +238,21 @@ void uhci_dump(void);
do { UBARR(sc); bus_space_write_4((sc)-iot, (sc)-ioh, (r), (x)); \
} while (/*CONSTCOND*/0)
-static __inline u_int8_t
+__unused static __inline u_int8_t
UREAD1(struct uhci_softc *sc, bus_size_t r)
{
UBARR(sc);
return bus_space_read_1(sc-iot, sc-ioh, r);
}
-static __inline u_int16_t
+__unused static __inline u_int16_t
UREAD2(struct uhci_softc *sc, bus_size_t r)
{
UBARR(sc);
return bus_space_read_2(sc-iot, sc-ioh, r);
}
-static __inline u_int32_t
+__unused static __inline u_int32_t
UREAD4(struct uhci_softc *sc, bus_size_t r)
{
UBARR(sc);
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: LLVM warning in dev/pci/if_wpi.c
On Tue, Dec 03, 2013 at 08:31:13PM -0500, Brad Smith wrote:
An unused function in wpi(4). #if 0 out the function for now.
if_wpi.c:510:1: error: unused function 'wpi_mem_write'
[-Werror,-Wunused-function]
OK?
Index: if_wpi.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_wpi.c,v
retrieving revision 1.116
diff -u -p -r1.116 if_wpi.c
--- if_wpi.c 28 Nov 2013 20:07:32 - 1.116
+++ if_wpi.c 4 Dec 2013 00:55:43 -
@@ -506,6 +506,7 @@ wpi_mem_read(struct wpi_softc *sc, uint3
return WPI_READ(sc, WPI_MEM_RDATA);
}
+#if 0
static __inline void
wpi_mem_write(struct wpi_softc *sc, uint32_t addr, uint32_t data)
{
@@ -513,6 +514,7 @@ wpi_mem_write(struct wpi_softc *sc, uint
WPI_BARRIER_WRITE(sc);
WPI_WRITE(sc, WPI_MEM_WDATA, data);
}
+#endif
static __inline void
wpi_mem_read_region_4(struct wpi_softc *sc, uint32_t addr, uint32_t *data,
I'm guessing kettenis will probably want something like this instead.
OK?
Index: if_wpi.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_wpi.c,v
retrieving revision 1.116
diff -u -p -r1.116 if_wpi.c
--- if_wpi.c28 Nov 2013 20:07:32 - 1.116
+++ if_wpi.c5 Dec 2013 20:58:49 -
@@ -506,7 +506,7 @@ wpi_mem_read(struct wpi_softc *sc, uint3
return WPI_READ(sc, WPI_MEM_RDATA);
}
-static __inline void
+__unused static __inline void
wpi_mem_write(struct wpi_softc *sc, uint32_t addr, uint32_t data)
{
WPI_WRITE(sc, WPI_MEM_WADDR, addr);
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in dev/ic/aic79xx.c
This is unused within the aic79xx code. aic79xx.c:93:20: error: unused variable 'num_chip_names' [-Werror,-Wunused-const-variable] OK? Index: aic79xx.c === RCS file: /home/cvs/src/sys/dev/ic/aic79xx.c,v retrieving revision 1.51 diff -u -p -r1.51 aic79xx.c --- aic79xx.c 30 May 2013 16:15:02 - 1.51 +++ aic79xx.c 3 Dec 2013 22:21:40 - @@ -90,7 +90,6 @@ char *ahd_chip_names[] = aic7902, aic7901A }; -static const u_int num_chip_names = NUM_ELEMENTS(ahd_chip_names); /* * Hardware error codes. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
LLVM warning in dev/ic/atw.c
The bit of code that calls this function is #if 0'd out so leave the function
there but #if 0 it out as well.
atw.c:3021:1: error: unused function 'atw_hw_decrypted'
[-Werror,-Wunused-function]
OK?
Index: atw.c
===
RCS file: /home/cvs/src/sys/dev/ic/atw.c,v
retrieving revision 1.78
diff -u -p -r1.78 atw.c
--- atw.c 26 Nov 2013 09:50:32 - 1.78
+++ atw.c 3 Dec 2013 22:30:22 -
@@ -3017,6 +3017,7 @@ atw_linkintr(struct atw_softc *sc, u_int
}
}
+#if 0
static __inline int
atw_hw_decrypted(struct atw_softc *sc, struct ieee80211_frame *wh)
{
@@ -3026,6 +3027,7 @@ atw_hw_decrypted(struct atw_softc *sc, s
return 0;
return (sc-sc_wepctl ATW_WEPCTL_WEPRXBYP) == 0;
}
+#endif
/*
* atw_rxintr:
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in dev/ic/uhci.c
Put UREAD4 under #ifdef UHCI_DEBUG as it is only used by a function
for debugging which is also under UHCI_DEBUG.
uhci.c:256:1: error: unused function 'UREAD4' [-Werror,-Wunused-function]
OK?
Index: uhci.c
===
RCS file: /home/cvs/src/sys/dev/usb/uhci.c,v
retrieving revision 1.104
diff -u -p -r1.104 uhci.c
--- uhci.c 9 Nov 2013 08:46:05 - 1.104
+++ uhci.c 3 Dec 2013 22:50:28 -
@@ -252,12 +252,14 @@ UREAD2(struct uhci_softc *sc, bus_size_t
return bus_space_read_2(sc-iot, sc-ioh, r);
}
+#ifdef UHCI_DEBUG
static __inline u_int32_t
UREAD4(struct uhci_softc *sc, bus_size_t r)
{
UBARR(sc);
return bus_space_read_4(sc-iot, sc-ioh, r);
}
+#endif
#define UHCICMD(sc, cmd) UWRITE2(sc, UHCI_CMD, cmd)
#define UHCISTS(sc) UREAD2(sc, UHCI_STS)
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in dev/ic/ohci.c
Some unused functions in ohci(4). #if 0 them out to appease the warnings but
keep the code around in case it will be used at some point in the future.
ohci.c:193:1: error: unused function 'OREAD1' [-Werror,-Wunused-function]
ohci.c:200:1: error: unused function 'OREAD2' [-Werror,-Wunused-function]
OK?
Index: ohci.c
===
RCS file: /home/cvs/src/sys/dev/usb/ohci.c,v
retrieving revision 1.116
diff -u -p -r1.116 ohci.c
--- ohci.c 9 Nov 2013 08:46:05 - 1.116
+++ ohci.c 3 Dec 2013 22:52:01 -
@@ -189,6 +189,7 @@ voidohci_dump_itds(struct ohci_soft_it
#define OWRITE4(sc, r, x) \
do { OBARR(sc); bus_space_write_4((sc)-iot, (sc)-ioh, (r), (x)); } while (0)
+#if 0
static __inline u_int8_t
OREAD1(struct ohci_softc *sc, bus_size_t r)
{
@@ -202,6 +203,7 @@ OREAD2(struct ohci_softc *sc, bus_size_t
OBARR(sc);
return bus_space_read_2(sc-iot, sc-ioh, r);
}
+#endif
static __inline u_int32_t
OREAD4(struct ohci_softc *sc, bus_size_t r)
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in amd64/amd64/amd64errata.c and i386 version too
The relvent code using amd64_errata_set4 is #if 0'd out so do the same
to the variable.
amd64errata.c:103:22: error: unused variable 'amd64_errata_set4'
[-Werror,-Wunused-const-variable]
OK?
Index: amd64/amd64/amd64errata.c
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/amd64errata.c,v
retrieving revision 1.5
diff -u -p -r1.5 amd64errata.c
--- amd64/amd64/amd64errata.c 21 May 2013 21:12:17 - 1.5
+++ amd64/amd64/amd64errata.c 3 Dec 2013 23:38:59 -
@@ -100,10 +100,12 @@ static const uint8_t amd64_errata_set3[]
JH_E1, DH_E3, OINK
};
+#if 0
static const uint8_t amd64_errata_set4[] = {
SH_C0, SH_CG, DH_CG, CH_CG, SH_D0, DH_D0, CH_D0, JH_E1,
DH_E3, SH_E4, BH_E4, SH_E5, DH_E6, JH_E6, OINK
};
+#endif
static const uint8_t amd64_errata_set5[] = {
SH_B3, OINK
Index: i386/i386/amd64errata.c
===
RCS file: /home/cvs/src/sys/arch/i386/i386/amd64errata.c,v
retrieving revision 1.5
diff -u -p -r1.5 amd64errata.c
--- i386/i386/amd64errata.c 21 May 2013 21:12:17 - 1.5
+++ i386/i386/amd64errata.c 3 Dec 2013 23:39:40 -
@@ -100,10 +100,12 @@ static const uint8_t amd64_errata_set3[]
JH_E1, DH_E3, OINK
};
+#if 0
static const uint8_t amd64_errata_set4[] = {
SH_C0, SH_CG, DH_CG, CH_CG, SH_D0, DH_D0, CH_D0, JH_E1,
DH_E3, SH_E4, BH_E4, SH_E5, DH_E6, JH_E6, OINK
};
+#endif
static const uint8_t amd64_errata_set5[] = {
SH_B3, OINK
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in sys/uvm/uvm_map.c
An unused function in the UVM code. #if 0 it out for now.
uvm_map.c:171:14: error: unused function 'uvm_mapentry_freecmp'
[-Werror,-Wunused-function]
uvm_map.c:353:1: error: unused function 'uvm_mapentry_freecmp'
[-Werror,-Wunused-function]
OK?
Index: uvm_map.c
===
RCS file: /home/cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.163
diff -u -p -r1.163 uvm_map.c
--- uvm_map.c 21 Sep 2013 10:01:27 - 1.163
+++ uvm_map.c 3 Dec 2013 23:27:50 -
@@ -168,8 +168,10 @@ static __inline voiduvm_mapent_copy(st
struct vm_map_entry*);
static int uvm_mapentry_addrcmp(struct vm_map_entry*,
struct vm_map_entry*);
+#if 0
static int uvm_mapentry_freecmp(struct vm_map_entry*,
struct vm_map_entry*);
+#endif
voiduvm_mapent_free_insert(struct vm_map*,
struct uvm_addr_state*, struct vm_map_entry*);
voiduvm_mapent_free_remove(struct vm_map*,
@@ -349,12 +351,14 @@ uvm_mapentry_addrcmp(struct vm_map_entry
* tree will be considered during 'any address' allocations.
*/
+#if 0
static __inline int
uvm_mapentry_freecmp(struct vm_map_entry *e1, struct vm_map_entry *e2)
{
int cmp = e1-fspace e2-fspace ? -1 : e1-fspace e2-fspace;
return cmp ? cmp : uvm_mapentry_addrcmp(e1, e2);
}
+#endif
/*
* Copy mapentry.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in net/net80211/ieee80211_output.c
ieee80211_edca_table is unused within the code so just #if 0 it out for
but but keeping it around for future reference in case it ever becomes
useful.
ieee80211_output.c:311:5: error: unused variable 'ieee80211_edca_table'
[-Werror,-Wunused-const-variable]
OK?
Index: ieee80211_output.c
===
RCS file: /home/cvs/src/sys/net80211/ieee80211_output.c,v
retrieving revision 1.88
diff -u -p -r1.88 ieee80211_output.c
--- ieee80211_output.c 17 Jul 2010 16:30:01 - 1.88
+++ ieee80211_output.c 3 Dec 2013 23:20:22 -
@@ -306,6 +306,7 @@ ieee80211_mgmt_output(struct ifnet *ifp,
* 11G 15* 1023(*) aCWmin(1)
* Turbo A/G 7 1023(Atheros proprietary mode)
*/
+#if 0
static const struct ieee80211_edca_ac_params
ieee80211_edca_table[IEEE80211_MODE_MAX][EDCA_NUM_AC] = {
[IEEE80211_MODE_11B] = {
@@ -333,6 +334,7 @@ static const struct ieee80211_edca_ac_pa
[EDCA_AC_VO] = { 2, 2, 1, 47 }
}
};
+#endif
#ifndef IEEE80211_STA_ONLY
static const struct ieee80211_edca_ac_params
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in dev/pci/drm/i915/i915_drv.c
The ValleyView PCI ids are #ifdef notyet in the table which references these
structs so
stick these under #ifdef notyet too until the ids are enabled.
i915_drv.c:288:39: error: unused variable 'intel_valleyview_m_info'
[-Werror,-Wunused-const-variable]
i915_drv.c:297:39: error: unused variable 'intel_valleyview_d_info'
[-Werror,-Wunused-const-variable]
OK?
Index: i915_drv.c
===
RCS file: /home/cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.54
diff -u -p -r1.54 i915_drv.c
--- i915_drv.c 1 Dec 2013 13:53:52 - 1.54
+++ i915_drv.c 4 Dec 2013 01:20:10 -
@@ -285,6 +285,7 @@ static const struct intel_device_info in
.has_force_wake = 1,
};
+#ifdef notyet
static const struct intel_device_info intel_valleyview_m_info = {
.gen = 7, .is_mobile = 1,
.need_gfx_hws = 1, .has_hotplug = 1,
@@ -302,6 +303,7 @@ static const struct intel_device_info in
.has_blt_ring = 1,
.is_valleyview = 1,
};
+#endif
static const struct intel_device_info intel_haswell_d_info = {
.is_haswell = 1, .gen = 7,
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in dev/pci/if_wpi.c
An unused function in wpi(4). #if 0 out the function for now.
if_wpi.c:510:1: error: unused function 'wpi_mem_write'
[-Werror,-Wunused-function]
OK?
Index: if_wpi.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_wpi.c,v
retrieving revision 1.116
diff -u -p -r1.116 if_wpi.c
--- if_wpi.c28 Nov 2013 20:07:32 - 1.116
+++ if_wpi.c4 Dec 2013 00:55:43 -
@@ -506,6 +506,7 @@ wpi_mem_read(struct wpi_softc *sc, uint3
return WPI_READ(sc, WPI_MEM_RDATA);
}
+#if 0
static __inline void
wpi_mem_write(struct wpi_softc *sc, uint32_t addr, uint32_t data)
{
@@ -513,6 +514,7 @@ wpi_mem_write(struct wpi_softc *sc, uint
WPI_BARRIER_WRITE(sc);
WPI_WRITE(sc, WPI_MEM_WDATA, data);
}
+#endif
static __inline void
wpi_mem_read_region_4(struct wpi_softc *sc, uint32_t addr, uint32_t *data,
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: txp(4) 3Com 3XP Typhoon/Sidewinder diff needs testing
On 02/12/13 7:36 AM, Mike Belopuhov wrote: On 2 December 2013 03:07, Brad Smith b...@comstyle.com wrote: Here is a diff for the txp(4) 3Com 3XP Typhoon/Sidewinder driver to clean up and update the receive filter / ioctl handling code to be in line with the other drivers. Anyone with hw and able to test? OK? as long as you're just moving stuff around, it should be fine. i doubt you'll find people with such ancient and rather rare hardware. I've already done the first 40 - 50 odd drivers. I'm down to the drivers of hardware that is somewhat rare or on other not so common archs and I'd like to finish the rest. i might have also missed why are you doing that. is it to have if_iff and call all this stuff from the ether_ioctl? Well it is to do a bunch of things but its all in the same bits of code. After taking a look at a lot of the drivers over time I noticed a lot of inconsistencies and a handful of bugs. Drivers have been ported from FreeBSD/NetBSD as well as drivers written for OpenBSD but there was/has been a variety of ways of handling certain bits like promiscuous mode handling whether its in the ioctl handler or separated out to a separate function or within the function which is essentially for multicast handling. Also some drivers have/had bugs; for example udav(4) where once promisc mode was flipped on the hardware was always stuck in all multicast mode even after promisc mode was disabled or there are a variety of drivers once IFF_ALLMULTI is flipped on that the driver has no way of coming out of all multicast mode since the driver doesn't clear the flag properly. So the idea is to have consistent ioctl handling between all of the drivers. Put all the receive filter handling bits in one spot and have the drivers handle things in a consistent manner. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
jme(4) fixes for jme_encap(), fixes crashing under load
Here is a diff to fix a few issues with jme_encap(). I noticed some issues with
jme_encap() as it was ported from DragonFly. I had fixed similar issues with
age(4) and alc(4), also originating from DragonFly. Maybe age/alc took
inspiration
from jme when being ported from DragonFly?
- Remove the maximum DMA segments handling bits as it is unused between
DragonFly and OpenBSD.
- Fix error handling for bus_dmamap_load_mbuf() so as to not try unloading
a DMA map that had not already been loaded.
- Clean up the DMA chain defragmenting path to remove unwanted printfs and
simplify things a bit.
- Have jme_encap() check the number of mapped DMA segments against the TX
ring to see if it'll fit as do most of the driver nowadays.
- Remove the KASSERT's that shouldn't be there.
- Simplify the dummy descriptor handling to be closer to the FreeBSD
driver since unlike the DragonFly driver this orinated from our
driver always uses the 64-bit dummy descriptor.
- If the ring was full make sure to IF_PREPEND() the packet back on
the queue since it wasn't transmitted.
Tested by com...@daknet.org and vigdis+o...@chown.me and myself.
OK?
Index: if_jme.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_jme.c,v
retrieving revision 1.32
diff -u -p -r1.32 if_jme.c
--- if_jme.c3 Nov 2013 23:27:33 - 1.32
+++ if_jme.c28 Nov 2013 19:38:12 -
@@ -1044,48 +1044,36 @@ jme_encap(struct jme_softc *sc, struct m
struct jme_txdesc *txd;
struct jme_desc *desc;
struct mbuf *m;
- int maxsegs;
int error, i, prod;
uint32_t cflags;
prod = sc-jme_cdata.jme_tx_prod;
txd = sc-jme_cdata.jme_txdesc[prod];
- maxsegs = (JME_TX_RING_CNT - sc-jme_cdata.jme_tx_cnt) -
- (JME_TXD_RSVD + 1);
- if (maxsegs JME_MAXTXSEGS)
- maxsegs = JME_MAXTXSEGS;
- if (maxsegs (sc-jme_txd_spare - 1))
- panic(%s: not enough segments %d, sc-sc_dev.dv_xname,
- maxsegs);
-
error = bus_dmamap_load_mbuf(sc-sc_dmat, txd-tx_dmamap,
*m_head, BUS_DMA_NOWAIT);
+ if (error != 0 error != EFBIG)
+ goto drop;
if (error != 0) {
- bus_dmamap_unload(sc-sc_dmat, txd-tx_dmamap);
- error = EFBIG;
- }
- if (error == EFBIG) {
if (m_defrag(*m_head, M_DONTWAIT)) {
- printf(%s: can't defrag TX mbuf\n,
- sc-sc_dev.dv_xname);
- m_freem(*m_head);
- *m_head = NULL;
- return (ENOBUFS);
- }
- error = bus_dmamap_load_mbuf(sc-sc_dmat,
-txd-tx_dmamap, *m_head,
-BUS_DMA_NOWAIT);
- if (error != 0) {
- printf(%s: could not load defragged TX mbuf\n,
- sc-sc_dev.dv_xname);
- m_freem(*m_head);
- *m_head = NULL;
- return (error);
- }
- } else if (error) {
- printf(%s: could not load TX mbuf\n, sc-sc_dev.dv_xname);
- return (error);
+ error = ENOBUFS;
+ goto drop;
+ }
+ error = bus_dmamap_load_mbuf(sc-sc_dmat, txd-tx_dmamap,
+*m_head, BUS_DMA_NOWAIT);
+ if (error != 0)
+ goto drop;
+ }
+
+ /*
+* Check descriptor overrun. Leave one free descriptor.
+* Since we always use 64bit address mode for transmitting,
+* each Tx request requires one more dummy descriptor.
+*/
+ if (sc-jme_cdata.jme_tx_cnt + txd-tx_dmamap-dm_nsegs + JME_TXD_RSVD
+ JME_TX_RING_CNT - JME_TXD_RSVD) {
+ bus_dmamap_unload(sc-sc_dmat, txd-tx_dmamap);
+ return (ENOBUFS);
}
m = *m_head;
@@ -1113,7 +1101,6 @@ jme_encap(struct jme_softc *sc, struct m
desc-addr_hi = htole32(m-m_pkthdr.len);
desc-addr_lo = 0;
sc-jme_cdata.jme_tx_cnt++;
- KASSERT(sc-jme_cdata.jme_tx_cnt JME_TX_RING_CNT - JME_TXD_RSVD);
JME_DESC_INC(prod, JME_TX_RING_CNT);
for (i = 0; i txd-tx_dmamap-dm_nsegs; i++) {
desc = sc-jme_rdata.jme_tx_ring[prod];
@@ -1123,10 +1110,7 @@ jme_encap(struct jme_softc *sc, struct m
htole32(JME_ADDR_HI(txd-tx_dmamap-dm_segs[i].ds_addr));
desc-addr_lo =
htole32(JME_ADDR_LO(txd-tx_dmamap-dm_segs[i].ds_addr));
-
sc-jme_cdata.jme_tx_cnt++;
- KASSERT(sc-jme_cdata.jme_tx_cnt =
-JME_TX_RING_CNT - JME_TXD_RSVD);
JME_DESC_INC(prod, JME_TX_RING_CNT);
}
pcn(4) receive filter / ioctl handling fixes/updating
Here is a diff to clean up and and fix up the receive filter and
ioctl handling code to be in line with the other drivers. Also fixes
being not able to bring the interface out of all multicast mode once
the range or promisc mode has been removed/disabled.
Tested with QEMU and VMware's pcn(4) adapters.
OK?
Index: if_pcn.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_pcn.c,v
retrieving revision 1.28
diff -u -p -r1.28 if_pcn.c
--- if_pcn.c26 Nov 2013 09:50:33 - 1.28
+++ if_pcn.c2 Dec 2013 00:34:05 -
@@ -1057,31 +1057,24 @@ pcn_ioctl(struct ifnet *ifp, u_long cmd,
switch (cmd) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
-
- switch (ifa-ifa_addr-sa_family) {
-#ifdef INET
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
pcn_init(ifp);
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-sc_arpcom, ifa);
- break;
#endif
- default:
- pcn_init(ifp);
- break;
- }
break;
case SIOCSIFFLAGS:
- /*
-* If interface is marked up and not running, then start it.
-* If it is marked down and running, stop it.
-* XXX If it's up then re-initialize it. This is so flags
-* such as IFF_PROMISC are handled.
-*/
- if (ifp-if_flags IFF_UP)
- pcn_init(ifp);
- else if (ifp-if_flags IFF_RUNNING)
- pcn_stop(ifp, 1);
+ if (ifp-if_flags IFF_UP) {
+ if (ifp-if_flags IFF_RUNNING)
+ error = ENETRESET;
+ else
+ pcn_init(ifp);
+ } else {
+ if (ifp-if_flags IFF_RUNNING)
+ pcn_stop(ifp, 1);
+ }
break;
case SIOCSIFMEDIA:
@@ -1570,10 +1563,6 @@ pcn_init(struct ifnet *ifp)
/* Initialize MODE for the initialization block. */
sc-sc_mode = 0;
- if (ifp-if_flags IFF_PROMISC)
- sc-sc_mode |= LE_C15_PROM;
- if ((ifp-if_flags IFF_BROADCAST) == 0)
- sc-sc_mode |= LE_C15_DRCVBC;
/*
* If we have MII, simply select MII in the MODE register,
@@ -1593,6 +1582,9 @@ pcn_init(struct ifnet *ifp)
pcn_bcr_read(sc, LE_BCR32) | LE_B32_DANAS);
}
+ /* Set the multicast filter in the init block. */
+ pcn_set_filter(sc);
+
/*
* Set the Tx and Rx descriptor ring addresses in the init
* block, the TLEN and RLEN other fields of the init block
@@ -1610,9 +1602,6 @@ pcn_init(struct ifnet *ifp)
sc-sc_initblock.init_padr[1] = htole32(enaddr[4] |
(enaddr[5] 8));
- /* Set the multicast filter in the init block. */
- pcn_set_filter(sc);
-
/* Initialize CSR3. */
pcn_csr_write(sc, LE_CSR3, LE_C3_MISSM|LE_C3_IDONM|LE_C3_DXSUFLO);
@@ -1835,46 +1824,43 @@ pcn_set_filter(struct pcn_softc *sc)
struct ether_multistep step;
uint32_t crc;
- /*
-* Set up the multicast address filter by passing all multicast
-* addresses through a CRC generator, and then using the high
-* order 6 bits as an index into the 64-bit logical address
-* filter. The high order bits select the word, while the rest
-* of the bits select the bit within the word.
-*/
-
- if (ifp-if_flags IFF_ALLMULTI || ifp-if_flags IFF_PROMISC ||
- ac-ac_multirangecnt 0)
- goto allmulti;
-
- sc-sc_initblock.init_ladrf[0] =
- sc-sc_initblock.init_ladrf[1] =
- sc-sc_initblock.init_ladrf[2] =
- sc-sc_initblock.init_ladrf[3] = 0;
-
- ETHER_FIRST_MULTI(step, ac, enm);
- while (enm != NULL) {
- crc = ether_crc32_le(enm-enm_addrlo, ETHER_ADDR_LEN);
-
- /* Just want the 6 most significant bits. */
- crc = 26;
-
- /* Set the corresponding bit in the filter. */
- sc-sc_initblock.init_ladrf[crc 4] |=
- htole16(1 (crc 0xf));
+ ifp-if_flags = ~IFF_ALLMULTI;
- ETHER_NEXT_MULTI(step, enm);
- }
+ if (ifp-if_flags IFF_PROMISC || ac-ac_multirangecnt 0) {
+ ifp-if_flags |= IFF_ALLMULTI;
+ if (ifp-if_flags IFF_PROMISC)
+ sc-sc_mode |= LE_C15_PROM;
+ sc-sc_initblock.init_ladrf[0] =
+ sc-sc_initblock.init_ladrf[1] =
+ sc-sc_initblock.init_ladrf[2] =
+ sc-sc_initblock.init_ladrf[3] = 0x;
+ } else {
+
tl(4) ThunderLAN diff needs testing
Here is a diff for the tl(4) ThunderLAN driver to clean up and update the
receive filter / ioctl handling code to be in line with the other drivers.
I also want to try reinstating the hash filter and get that working properly.
Anyone with hw and able to test? OK?
Index: if_tl.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_tl.c,v
retrieving revision 1.57
diff -u -p -r1.57 if_tl.c
--- if_tl.c 26 Nov 2013 09:50:33 - 1.57
+++ if_tl.c 2 Dec 2013 01:17:00 -
@@ -277,10 +277,8 @@ void tl_miibus_writereg(struct device *,
void tl_miibus_statchg(struct device *);
void tl_setmode(struct tl_softc *, int);
-#if 0
int tl_calchash(caddr_t);
-#endif
-void tl_setmulti(struct tl_softc *);
+void tl_iff(struct tl_softc *);
void tl_setfilt(struct tl_softc *, caddr_t, int);
void tl_softreset(struct tl_softc *, int);
void tl_hardreset(struct device *);
@@ -744,7 +742,6 @@ tl_setmode(struct tl_softc *sc, int medi
}
}
-#if 0
/*
* Calculate the hash of a MAC address for programming the multicast hash
* table. This hash is simply the address split into 6-bit chunks
@@ -763,7 +760,6 @@ tl_calchash(caddr_t addr)
(addr[2] ^ addr[5]);
return ((t 18) ^ (t 12) ^ (t 6) ^ t) 0x3f;
}
-#endif
/*
* The ThunderLAN has a perfect MAC address filter in addition to
@@ -801,36 +797,41 @@ tl_setfilt(struct tl_softc *sc, caddr_t
* update the multicast filter.
*/
void
-tl_setmulti(struct tl_softc *sc)
+tl_iff(struct tl_softc *sc)
{
- struct ifnet*ifp;
- u_int32_t hashes[2] = { 0, 0 };
- int h;
- struct arpcom *ac = sc-arpcom;
+ struct ifnet*ifp = sc-arpcom.ac_if;
+ struct arpcom *ac = sc-arpcom;
struct ether_multistep step;
struct ether_multi *enm;
- ifp = sc-arpcom.ac_if;
-
- tl_dio_write32(sc, TL_HASH1, 0);
- tl_dio_write32(sc, TL_HASH2, 0);
+ u_int32_t hashes[2];
+ int h = 0;
+ tl_dio_clrbit(sc, TL_NETCMD, (TL_CMD_CAF | TL_CMD_NOBRX));
+ bzero(hashes, sizeof(hashes));
ifp-if_flags = ~IFF_ALLMULTI;
- ETHER_FIRST_MULTI(step, ac, enm);
- h = 0;
- while (enm != NULL) {
- h++;
- ETHER_NEXT_MULTI(step, enm);
- }
- if (h) {
- hashes[0] = hashes[1] = 0x;
+
+ if (ifp-if_flags IFF_PROMISC || ac-ac_multirangecnt 0) {
ifp-if_flags |= IFF_ALLMULTI;
- } else
- hashes[0] = hashes[1] = 0x;
+ if (ifp-if_flags IFF_PROMISC)
+ tl_dio_setbit(sc, TL_NETCMD, TL_CMD_CAF);
+ else
+ hashes[0] = hashes[1] = 0x;
+ } else {
+ ETHER_FIRST_MULTI(step, ac, enm);
+ while (enm != NULL) {
+ h = tl_calchash(enm-enm_addrlo);
+
+ if (h 32)
+ hashes[0] |= (1 h);
+ else
+ hashes[1] |= (1 (h - 32));
+
+ ETHER_NEXT_MULTI(step, enm);
+ }
+ }
tl_dio_write32(sc, TL_HASH1, hashes[0]);
tl_dio_write32(sc, TL_HASH2, hashes[1]);
-
- return;
}
/*
@@ -1569,29 +1570,13 @@ tl_init(void *xsc)
/* Set PCI burst size */
tl_dio_write8(sc, TL_BSIZEREG, TL_RXBURST_16LONG|TL_TXBURST_16LONG);
- /*
-* Set 'capture all frames' bit for promiscuous mode.
-*/
- if (ifp-if_flags IFF_PROMISC)
- tl_dio_setbit(sc, TL_NETCMD, TL_CMD_CAF);
- else
- tl_dio_clrbit(sc, TL_NETCMD, TL_CMD_CAF);
-
- /*
-* Set capture broadcast bit to capture broadcast frames.
-*/
- if (ifp-if_flags IFF_BROADCAST)
- tl_dio_clrbit(sc, TL_NETCMD, TL_CMD_NOBRX);
- else
- tl_dio_setbit(sc, TL_NETCMD, TL_CMD_NOBRX);
-
tl_dio_write16(sc, TL_MAXRX, MCLBYTES);
/* Init our MAC address */
tl_setfilt(sc, (caddr_t)sc-arpcom.ac_enaddr, 0);
- /* Init multicast filter, if needed. */
- tl_setmulti(sc);
+ /* Program promiscuous mode and multicast filters. */
+ tl_iff(sc);
/* Init circular RX list. */
if (tl_list_rx_init(sc) == ENOBUFS) {
@@ -1688,40 +1673,24 @@ tl_ioctl(struct ifnet *ifp, u_long comma
switch(command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- switch (ifa-ifa_addr-sa_family) {
-#ifdef INET
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
tl_init(sc);
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-arpcom, ifa);
- break;
-#endif /* INET */
- default:
-
sf(4) Starfire diff needs testing
Here is a diff for the sf(4) Starfire driver to clean up and update the
receive filter / ioctl handling code to be in line with the other drivers.
Anyone with hw and able to test? OK?
Index: aic6915.c
===
RCS file: /home/cvs/src/sys/dev/ic/aic6915.c,v
retrieving revision 1.11
diff -u -p -r1.11 aic6915.c
--- aic6915.c 26 Nov 2013 09:50:32 - 1.11
+++ aic6915.c 1 Dec 2013 00:48:16 -
@@ -89,7 +89,7 @@ void sf_macreset(struct sf_softc *);
void sf_rxdrain(struct sf_softc *);
intsf_add_rxbuf(struct sf_softc *, int);
uint8_tsf_read_eeprom(struct sf_softc *, int);
-void sf_set_filter(struct sf_softc *);
+void sf_iff(struct sf_softc *);
intsf_mii_read(struct device *, int, int);
void sf_mii_write(struct device *, int, int, int);
@@ -532,19 +532,14 @@ sf_ioctl(struct ifnet *ifp, u_long cmd,
case SIOCSIFFLAGS:
if (ifp-if_flags IFF_UP) {
- if (ifp-if_flags IFF_RUNNING
- ((ifp-if_flags ^ sc-sc_flags)
-IFF_PROMISC)) {
- sf_set_filter(sc);
- } else {
- if (!(ifp-if_flags IFF_RUNNING))
- sf_init(ifp);
- }
+ if (ifp-if_flags IFF_RUNNING)
+ error = ENETRESET;
+ else
+ sf_init(ifp);
} else {
if (ifp-if_flags IFF_RUNNING)
sf_stop(ifp, 1);
}
- sc-sc_flags = ifp-if_flags;
break;
case SIOCGIFMEDIA:
@@ -558,7 +553,7 @@ sf_ioctl(struct ifnet *ifp, u_long cmd,
if (error == ENETRESET) {
if (ifp-if_flags IFF_RUNNING)
- sf_set_filter(sc);
+ sf_iff(sc);
error = 0;
}
@@ -1087,10 +1082,9 @@ sf_init(struct ifnet *ifp)
RDC_RxBurstSize(4));/* default */
/*
-* Set the receive filter.
+* Program promiscuous mode and multicast filters.
*/
- sc-sc_RxAddressFilteringCtl = 0;
- sf_set_filter(sc);
+ sf_iff(sc);
/*
* Set MacConfig1. When we set the media, MacConfig1 will
@@ -1293,85 +1287,65 @@ sf_set_filter_hash(struct sf_softc *sc,
}
/*
- * sf_set_filter:
+ * sf_iff:
*
* Set the Starfire receive filter.
*/
void
-sf_set_filter(struct sf_softc *sc)
+sf_iff(struct sf_softc *sc)
{
struct arpcom *ac = sc-sc_arpcom;
struct ifnet *ifp = sc-sc_arpcom.ac_if;
struct ether_multi *enm;
struct ether_multistep step;
+ uint32_t filterctl;
int i;
- /* Start by clearing the perfect and hash tables. */
+ filterctl = sf_funcreg_read(sc, SF_RxAddressFilteringCtl);
+ filterctl = ~(RAFC_PassBroadcast | RAFC_PromiscuousMode |
+ RAFC_PerfectFilteringMode(3) | RAFC_HashFilteringMode(3));
+ ifp-if_flags = ~IFF_ALLMULTI;
+
+ /* Clear the perfect and hash tables. */
for (i = 0; i SF_PERFECT_SIZE; i += sizeof(uint32_t))
sf_genreg_write(sc, SF_PERFECT_BASE + i, 0);
-
for (i = 0; i SF_HASH_SIZE; i += sizeof(uint32_t))
sf_genreg_write(sc, SF_HASH_BASE + i, 0);
/*
-* Clear the perfect and hash mode bits.
-*/
- sc-sc_RxAddressFilteringCtl =
- ~(RAFC_PerfectFilteringMode(3) | RAFC_HashFilteringMode(3));
-
- if (ifp-if_flags IFF_BROADCAST)
- sc-sc_RxAddressFilteringCtl |= RAFC_PassBroadcast;
- else
- sc-sc_RxAddressFilteringCtl = ~RAFC_PassBroadcast;
-
- if (ifp-if_flags IFF_PROMISC) {
- sc-sc_RxAddressFilteringCtl |= RAFC_PromiscuousMode;
- goto allmulti;
- } else
- sc-sc_RxAddressFilteringCtl = ~RAFC_PromiscuousMode;
-
- /*
-* Set normal perfect filtering mode.
+* Always accept broadcast frames.
*/
- sc-sc_RxAddressFilteringCtl |= RAFC_PerfectFilteringMode(1);
+ filterctl |= RAFC_PassBroadcast;
- /*
-* First, write the station address to the perfect filter
-* table.
-*/
- sf_set_filter_perfect(sc, 0, LLADDR(ifp-if_sadl));
+ if (ifp-if_flags IFF_PROMISC || ac-ac_multirangecnt 0) {
+ ifp-if_flags |= IFF_ALLMULTI;
+ filterctl |= RAFC_PassMulticast;
+ if (ifp-if_flags IFF_PROMISC)
+ filterctl |= RAFC_PromiscuousMode;
+ } else {
+ /*
+* Set hash only multicast dest, match regardless of VLAN ID.
+*/
+ filterctl |= RAFC_HashFilteringMode(2);
- if (ac-ac_multirangecnt 0)
- goto
nge(4) DP83820 / DP83821 diff needs testing
Here is a diff for the sf(4) Starfire driver to clean up and update the
receive filter / ioctl handling code to be in line with the other drivers.
Anyone with hw and able to test? OK?
Index: if_nge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_nge.c,v
retrieving revision 1.78
diff -u -p -r1.78 if_nge.c
--- if_nge.c26 Nov 2013 09:50:33 - 1.78
+++ if_nge.c2 Dec 2013 01:42:46 -
@@ -173,7 +173,7 @@ int nge_miibus_readreg(struct device *,
void nge_miibus_writereg(struct device *, int, int, int);
void nge_miibus_statchg(struct device *);
-void nge_setmulti(struct nge_softc *);
+void nge_iff(struct nge_softc *);
void nge_reset(struct nge_softc *);
int nge_list_rx_init(struct nge_softc *);
int nge_list_tx_init(struct nge_softc *);
@@ -577,7 +577,7 @@ nge_miibus_statchg(struct device *dev)
}
void
-nge_setmulti(struct nge_softc *sc)
+nge_iff(struct nge_softc *sc)
{
struct arpcom *ac = sc-arpcom;
struct ifnet*ifp = ac-ac_if;
@@ -1491,7 +1491,6 @@ nge_intr(void *arg)
if (status NGE_ISR_SYSERR) {
nge_reset(sc);
- ifp-if_flags = ~IFF_RUNNING;
nge_init(sc);
}
@@ -1650,9 +1649,6 @@ nge_init(void *xsc)
u_int32_t txcfg, rxcfg;
int s, media;
- if (ifp-if_flags IFF_RUNNING)
- return;
-
s = splnet();
/*
@@ -1688,32 +1684,9 @@ nge_init(void *xsc)
nge_list_tx_init(sc);
/*
-* For the NatSemi chip, we have to explicitly enable the
-* reception of ARP frames, as well as turn on the 'perfect
-* match' filter where we store the station address, otherwise
-* we won't receive unicasts meant for this host.
-*/
- NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_ARP);
- NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_PERFECT);
-
-/* If we want promiscuous mode, set the allframes bit. */
- if (ifp-if_flags IFF_PROMISC)
- NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_ALLPHYS);
- else
- NGE_CLRBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_ALLPHYS);
-
- /*
-* Set the capture broadcast bit to capture broadcast frames.
-*/
- if (ifp-if_flags IFF_BROADCAST)
- NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_BROAD);
- else
- NGE_CLRBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_BROAD);
-
- /*
-* Load the multicast filter.
+* Program promiscuous mode and multicast filters.
*/
- nge_setmulti(sc);
+ nge_iff(sc);
/* Turn the receive filter on */
NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_ENABLE);
@@ -1969,7 +1942,6 @@ nge_ioctl(struct ifnet *ifp, u_long comm
struct nge_softc*sc = ifp-if_softc;
struct ifaddr *ifa = (struct ifaddr *) data;
struct ifreq*ifr = (struct ifreq *) data;
- struct mii_data *mii;
int s, error = 0;
s = splnet();
@@ -1977,45 +1949,25 @@ nge_ioctl(struct ifnet *ifp, u_long comm
switch(command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- switch (ifa-ifa_addr-sa_family) {
-#ifdef INET
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
nge_init(sc);
+
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-arpcom, ifa);
- break;
-#endif /* INET */
- default:
- nge_init(sc);
- break;
-}
+#endif
break;
case SIOCSIFFLAGS:
if (ifp-if_flags IFF_UP) {
- if (ifp-if_flags IFF_RUNNING
- ifp-if_flags IFF_PROMISC
- !(sc-nge_if_flags IFF_PROMISC)) {
- NGE_SETBIT(sc, NGE_RXFILT_CTL,
- NGE_RXFILTCTL_ALLPHYS|
- NGE_RXFILTCTL_ALLMULTI);
- } else if (ifp-if_flags IFF_RUNNING
- !(ifp-if_flags IFF_PROMISC)
- sc-nge_if_flags IFF_PROMISC) {
- NGE_CLRBIT(sc, NGE_RXFILT_CTL,
- NGE_RXFILTCTL_ALLPHYS);
- if (!(ifp-if_flags IFF_ALLMULTI))
- NGE_CLRBIT(sc, NGE_RXFILT_CTL,
- NGE_RXFILTCTL_ALLMULTI);
- } else {
- ifp-if_flags = ~IFF_RUNNING;
+ if (ifp-if_flags IFF_RUNNING)
+ error = ENETRESET;
+
mtd(4) Myson MTD800/MTD803/MTD891 diff needs testing
Here is a diff for the mtd(4) Myson MTD800/MTD803/MTD891 driver to clean up
and update the receive filter / ioctl handling code to be in line with the
other drivers.
Anyone with hw and able to test? OK?
Index: mtd8xx.c
===
RCS file: /home/cvs/src/sys/dev/ic/mtd8xx.c,v
retrieving revision 1.21
diff -u -p -r1.21 mtd8xx.c
--- mtd8xx.c26 Nov 2013 09:50:33 - 1.21
+++ mtd8xx.c2 Dec 2013 01:34:24 -
@@ -68,7 +68,7 @@ static u_int32_t mtd_mii_command(struct
static int mtd_miibus_readreg(struct device *, int, int);
static void mtd_miibus_writereg(struct device *, int, int, int);
static void mtd_miibus_statchg(struct device *);
-static void mtd_setmulti(struct mtd_softc *);
+void mtd_iff(struct mtd_softc *);
static int mtd_encap(struct mtd_softc *, struct mbuf *, u_int32_t *);
static int mtd_list_rx_init(struct mtd_softc *);
@@ -313,42 +313,45 @@ mtd_miibus_statchg(struct device *self)
void
-mtd_setmulti(struct mtd_softc *sc)
+mtd_iff(struct mtd_softc *sc)
{
struct arpcom *ac = sc-sc_arpcom;
struct ifnet *ifp = sc-sc_arpcom.ac_if;
- u_int32_t rxfilt, crc, hash[2] = { 0, 0 };
struct ether_multistep step;
struct ether_multi *enm;
- int mcnt = 0;
+ u_int32_t rxfilt, crc, hash[2];
- if (ac-ac_multirangecnt 0)
- ifp-if_flags |= IFF_ALLMULTI;
+ rxfilt = CSR_READ_4(MTD_TCRRCR);
+ rxfilt = ~(RCR_AB | RCR_AM | RCR_PROM);
+ ifp-if_flags = ~IFF_ALLMULTI;
+
+ /*
+* Always accept broadcast frames.
+*/
+ rxfilt |= RCR_AB;
- rxfilt = CSR_READ_4(MTD_TCRRCR) ~RCR_AM;
- if (ifp-if_flags (IFF_ALLMULTI | IFF_PROMISC)) {
+ if (ifp-if_flags IFF_PROMISC || ac-ac_multirangecnt 0) {
+ ifp-if_flags |= IFF_ALLMULTI;
rxfilt |= RCR_AM;
- CSR_WRITE_4(MTD_TCRRCR, rxfilt);
- CSR_WRITE_4(MTD_MAR0, 0x);
- CSR_WRITE_4(MTD_MAR4, 0x);
- return;
- }
+ if (ifp-if_flags IFF_PROMISC)
+ rxfilt |= RCR_PROM;
+ hash[0] = hash[1] = 0x;
+ } else {
+ rxfilt |= RCR_AM;
+ /* Program new filter. */
+ bzero(hash, sizeof(hash));
+
+ ETHER_FIRST_MULTI(step, sc-sc_arpcom, enm);
+ while (enm != NULL) {
+ crc = ether_crc32_be(enm-enm_addrlo,
+ ETHER_ADDR_LEN) 26;
+
+ hash[crc 5] |= 1 (crc 0xf);
- /* First, zot all the existing hash bits. */
- CSR_WRITE_4(MTD_MAR0, 0);
- CSR_WRITE_4(MTD_MAR4, 0);
-
- /* Now program new ones. */
- ETHER_FIRST_MULTI(step, ac, enm);
- while (enm != NULL) {
- crc = ether_crc32_be(enm-enm_addrlo, ETHER_ADDR_LEN) 26;
- hash[crc 5] |= 1 (crc 0xf);
- ++mcnt;
- ETHER_NEXT_MULTI(step, enm);
+ ETHER_NEXT_MULTI(step, enm);
+ }
}
- if (mcnt)
- rxfilt |= RCR_AM;
CSR_WRITE_4(MTD_MAR0, hash[0]);
CSR_WRITE_4(MTD_MAR4, hash[1]);
CSR_WRITE_4(MTD_TCRRCR, rxfilt);
@@ -584,37 +587,39 @@ mtd_ioctl(struct ifnet *ifp, u_long comm
switch (command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- mtd_init(ifp);
- switch (ifa-ifa_addr-sa_family) {
+ if (!(ifp-if_flags IFF_RUNNING))
+ mtd_init(ifp);
+
#ifdef INET
- case AF_INET:
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-sc_arpcom, ifa);
- break;
-#endif /* INET */
- }
+#endif
break;
case SIOCSIFFLAGS:
- if (ifp-if_flags IFF_UP)
- mtd_init(ifp);
- else {
+ if (ifp-if_flags IFF_UP) {
+ if (ifp-if_flags IFF_RUNNING)
+ error = ENETRESET;
+ else
+ mtd_init(ifp);
+ } else {
if (ifp-if_flags IFF_RUNNING)
mtd_stop(ifp);
}
- error = 0;
break;
case SIOCGIFMEDIA:
case SIOCSIFMEDIA:
error = ifmedia_ioctl(ifp, ifr, sc-sc_mii.mii_media, command);
break;
+
default:
error = ether_ioctl(ifp, sc-sc_arpcom, command, data);
}
if (error == ENETRESET) {
if (ifp-if_flags IFF_RUNNING)
- mtd_setmulti(sc);
+ mtd_iff(sc);
error = 0;
}
@@ -646,17 +651,8 @@ mtd_init(struct ifnet *ifp)
CSR_SETBIT(MTD_TCRRCR,
Re: nge(4) DP83820 / DP83821 diff needs testing
On 01/12/13 8:45 PM, Brad Smith wrote:
Here is a diff for the sf(4) Starfire driver to clean up and update the
receive filter / ioctl handling code to be in line with the other drivers.
Oops. Should have said..
Here is a diff for the nge(4) DP83820 / DP83821 driver to clean up and
update the receive filter / ioctl handling code to be in line with the
other drivers.
Anyone with hw and able to test? OK?
Index: if_nge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_nge.c,v
retrieving revision 1.78
diff -u -p -r1.78 if_nge.c
--- if_nge.c26 Nov 2013 09:50:33 - 1.78
+++ if_nge.c2 Dec 2013 01:42:46 -
@@ -173,7 +173,7 @@ int nge_miibus_readreg(struct device *,
void nge_miibus_writereg(struct device *, int, int, int);
void nge_miibus_statchg(struct device *);
-void nge_setmulti(struct nge_softc *);
+void nge_iff(struct nge_softc *);
void nge_reset(struct nge_softc *);
int nge_list_rx_init(struct nge_softc *);
int nge_list_tx_init(struct nge_softc *);
@@ -577,7 +577,7 @@ nge_miibus_statchg(struct device *dev)
}
void
-nge_setmulti(struct nge_softc *sc)
+nge_iff(struct nge_softc *sc)
{
struct arpcom *ac = sc-arpcom;
struct ifnet*ifp = ac-ac_if;
@@ -1491,7 +1491,6 @@ nge_intr(void *arg)
if (status NGE_ISR_SYSERR) {
nge_reset(sc);
- ifp-if_flags = ~IFF_RUNNING;
nge_init(sc);
}
@@ -1650,9 +1649,6 @@ nge_init(void *xsc)
u_int32_t txcfg, rxcfg;
int s, media;
- if (ifp-if_flags IFF_RUNNING)
- return;
-
s = splnet();
/*
@@ -1688,32 +1684,9 @@ nge_init(void *xsc)
nge_list_tx_init(sc);
/*
-* For the NatSemi chip, we have to explicitly enable the
-* reception of ARP frames, as well as turn on the 'perfect
-* match' filter where we store the station address, otherwise
-* we won't receive unicasts meant for this host.
-*/
- NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_ARP);
- NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_PERFECT);
-
-/* If we want promiscuous mode, set the allframes bit. */
- if (ifp-if_flags IFF_PROMISC)
- NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_ALLPHYS);
- else
- NGE_CLRBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_ALLPHYS);
-
- /*
-* Set the capture broadcast bit to capture broadcast frames.
-*/
- if (ifp-if_flags IFF_BROADCAST)
- NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_BROAD);
- else
- NGE_CLRBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_BROAD);
-
- /*
-* Load the multicast filter.
+* Program promiscuous mode and multicast filters.
*/
- nge_setmulti(sc);
+ nge_iff(sc);
/* Turn the receive filter on */
NGE_SETBIT(sc, NGE_RXFILT_CTL, NGE_RXFILTCTL_ENABLE);
@@ -1969,7 +1942,6 @@ nge_ioctl(struct ifnet *ifp, u_long comm
struct nge_softc*sc = ifp-if_softc;
struct ifaddr *ifa = (struct ifaddr *) data;
struct ifreq*ifr = (struct ifreq *) data;
- struct mii_data *mii;
int s, error = 0;
s = splnet();
@@ -1977,45 +1949,25 @@ nge_ioctl(struct ifnet *ifp, u_long comm
switch(command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- switch (ifa-ifa_addr-sa_family) {
-#ifdef INET
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
nge_init(sc);
+
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-arpcom, ifa);
- break;
-#endif /* INET */
- default:
- nge_init(sc);
- break;
-}
+#endif
break;
case SIOCSIFFLAGS:
if (ifp-if_flags IFF_UP) {
- if (ifp-if_flags IFF_RUNNING
- ifp-if_flags IFF_PROMISC
- !(sc-nge_if_flags IFF_PROMISC)) {
- NGE_SETBIT(sc, NGE_RXFILT_CTL,
- NGE_RXFILTCTL_ALLPHYS|
- NGE_RXFILTCTL_ALLMULTI);
- } else if (ifp-if_flags IFF_RUNNING
- !(ifp-if_flags IFF_PROMISC)
- sc-nge_if_flags IFF_PROMISC) {
- NGE_CLRBIT(sc, NGE_RXFILT_CTL,
- NGE_RXFILTCTL_ALLPHYS);
- if (!(ifp-if_flags IFF_ALLMULTI))
- NGE_CLRBIT(sc, NGE_RXFILT_CTL
bce(4) Broadcom BCM4401 diff needs testing
Here is a diff for the bce(4) Broadcom BCM4401 driver to clean up and update
the receive filter / ioctl handling code to be in line with the other drivers.
Anyone with hw and able to test? OK?
Index: if_bce.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bce.c,v
retrieving revision 1.37
diff -u -p -r1.37 if_bce.c
--- if_bce.c21 Aug 2013 05:21:43 - 1.37
+++ if_bce.c9 Sep 2013 18:31:22 -
@@ -146,7 +146,7 @@ voidbce_add_mac(struct bce_softc *, u_i
void bce_add_rxbuf(struct bce_softc *, int);
void bce_stop(struct ifnet *);
void bce_reset(struct bce_softc *);
-void bce_set_filter(struct ifnet *);
+void bce_iff(struct ifnet *);
intbce_mii_read(struct device *, int, int);
void bce_mii_write(struct device *, int, int, int);
void bce_statchg(struct device *);
@@ -473,28 +473,24 @@ bce_ioctl(struct ifnet *ifp, u_long cmd,
switch (cmd) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
-
- switch (ifa-ifa_addr-sa_family) {
-#ifdef INET
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
bce_init(ifp);
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-bce_ac, ifa);
- break;
-#endif /* INET */
- default:
- bce_init(ifp);
- break;
- }
+#endif
break;
case SIOCSIFFLAGS:
- if (ifp-if_flags IFF_UP)
+ if (ifp-if_flags IFF_UP) {
if (ifp-if_flags IFF_RUNNING)
- bce_set_filter(ifp);
+ error = ENETRESET;
else
bce_init(ifp);
- else if (ifp-if_flags IFF_RUNNING)
- bce_stop(ifp);
+ } else {
+ if (ifp-if_flags IFF_RUNNING)
+ bce_stop(ifp);
+ }
break;
case SIOCSIFMEDIA:
@@ -508,7 +504,7 @@ bce_ioctl(struct ifnet *ifp, u_long cmd,
if (error == ENETRESET) {
if (ifp-if_flags IFF_RUNNING)
- bce_set_filter(ifp);
+ bce_iff(ifp);
error = 0;
}
@@ -871,8 +867,8 @@ bce_init(struct ifnet *ifp)
/* setup DMA interrupt control */
bus_space_write_4(sc-bce_btag, sc-bce_bhandle, BCE_DMAI_CTL, 1
24);/* MAGIC */
- /* setup packet filter */
- bce_set_filter(ifp);
+ /* program promiscuous mode and multicast filters */
+ bce_iff(ifp);
/* set max frame length, account for possible VLAN tag */
bus_space_write_4(sc-bce_btag, sc-bce_bhandle, BCE_RX_MAX,
@@ -1198,51 +1194,35 @@ bce_reset(struct bce_softc *sc)
/* Set up the receive filter. */
void
-bce_set_filter(struct ifnet *ifp)
+bce_iff(struct ifnet *ifp)
{
struct bce_softc *sc = ifp-if_softc;
+ struct arpcom *ac = sc-bce_ac;
+ u_int32_t rxctl;
- if (ifp-if_flags IFF_PROMISC) {
- ifp-if_flags |= IFF_ALLMULTI;
- bus_space_write_4(sc-bce_btag, sc-bce_bhandle, BCE_RX_CTL,
- bus_space_read_4(sc-bce_btag, sc-bce_bhandle, BCE_RX_CTL)
- | ERC_PE);
- } else {
- ifp-if_flags = ~IFF_ALLMULTI;
-
- /* turn off promiscuous */
- bus_space_write_4(sc-bce_btag, sc-bce_bhandle, BCE_RX_CTL,
- bus_space_read_4(sc-bce_btag, sc-bce_bhandle,
- BCE_RX_CTL) ~ERC_PE);
+ rxctl = bus_space_read_4(sc-bce_btag, sc-bce_bhandle, BCE_RX_CTL);
+ rxctl = ~(ERC_AM | ERC_DB | ERC_PE);
+ ifp-if_flags |= IFF_ALLMULTI;
- /* enable/disable broadcast */
- if (ifp-if_flags IFF_BROADCAST)
- bus_space_write_4(sc-bce_btag, sc-bce_bhandle,
- BCE_RX_CTL, bus_space_read_4(sc-bce_btag,
- sc-bce_bhandle, BCE_RX_CTL) ~ERC_DB);
- else
- bus_space_write_4(sc-bce_btag, sc-bce_bhandle,
- BCE_RX_CTL, bus_space_read_4(sc-bce_btag,
- sc-bce_bhandle, BCE_RX_CTL) | ERC_DB);
-
- /* disable the filter */
- bus_space_write_4(sc-bce_btag, sc-bce_bhandle, BCE_FILT_CTL,
- 0);
+ /* disable the filter */
+ bus_space_write_4(sc-bce_btag, sc-bce_bhandle, BCE_FILT_CTL, 0);
- /* add our own address */
- bce_add_mac(sc, sc-bce_ac.ac_enaddr, 0);
+ /* add our own address */
+ bce_add_mac(sc, ac-ac_enaddr, 0);
- /* for now accept all multicast */
- bus_space_write_4(sc-bce_btag, sc-bce_bhandle, BCE_RX_CTL,
-
epic(4) SMC 83C170 diff needs testing
Here is a diff for the epic(4) SMC 83C170 driver to clean up and update the
receive filter / ioctl handling code to be in line with the other drivers.
Anyone with hw and able to test? OK?
Index: smc83c170.c
===
RCS file: /home/cvs/src/sys/dev/ic/smc83c170.c,v
retrieving revision 1.16
diff -u -p -r1.16 smc83c170.c
--- smc83c170.c 26 Nov 2013 09:50:33 - 1.16
+++ smc83c170.c 1 Dec 2013 01:12:31 -
@@ -84,7 +84,7 @@ void epic_reset(struct epic_softc *);
void epic_rxdrain(struct epic_softc *);
intepic_add_rxbuf(struct epic_softc *, int);
void epic_read_eeprom(struct epic_softc *, int, int, u_int16_t *);
-void epic_set_mchash(struct epic_softc *);
+void epic_iff(struct epic_softc *);
void epic_fixup_clock_source(struct epic_softc *);
intepic_mii_read(struct device *, int, int);
void epic_mii_write(struct device *, int, int, int);
@@ -536,31 +536,24 @@ epic_ioctl(struct ifnet *ifp, u_long cmd
switch (cmd) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
-
- switch (ifa-ifa_addr-sa_family) {
-#ifdef INET
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
epic_init(ifp);
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-sc_arpcom, ifa);
- break;
#endif
- default:
- epic_init(ifp);
- break;
- }
break;
case SIOCSIFFLAGS:
- /*
-* If interface is marked up and not running, then start it.
-* If it is marked down and running, stop it.
-* XXX If it's up then re-initialize it. This is so flags
-* such as IFF_PROMISC are handled.
-*/
- if (ifp-if_flags IFF_UP)
- epic_init(ifp);
- else if (ifp-if_flags IFF_RUNNING)
- epic_stop(ifp, 1);
+ if (ifp-if_flags IFF_UP) {
+ if (ifp-if_flags IFF_RUNNING)
+ error = ENETRESET;
+ else
+ epic_init(ifp);
+ } else {
+ if (ifp-if_flags IFF_RUNNING)
+ epic_stop(ifp, 1);
+ }
break;
case SIOCSIFMEDIA:
@@ -575,7 +568,7 @@ epic_ioctl(struct ifnet *ifp, u_long cmd
if (error == ENETRESET) {
if (ifp-if_flags IFF_RUNNING) {
mii_pollstat(sc-sc_mii);
- epic_set_mchash(sc);
+ epic_iff(sc);
}
error = 0;
}
@@ -974,8 +967,8 @@ epic_init(struct ifnet *ifp)
/* Set the current media. */
epic_mediachange(ifp);
- /* Set up the multicast hash table. */
- epic_set_mchash(sc);
+ /* Program promiscuous mode and multicast filters. */
+ epic_iff(sc);
/*
* Initialize the transmit descriptor ring. txlast is initialized
@@ -1260,7 +1253,7 @@ epic_add_rxbuf(struct epic_softc *sc, in
* NOTE: We rely on a recently-updated mii_media_active here!
*/
void
-epic_set_mchash(struct epic_softc *sc)
+epic_iff(struct epic_softc *sc)
{
struct arpcom *ac = sc-sc_arpcom;
struct ifnet *ifp = sc-sc_arpcom.ac_if;
@@ -1268,47 +1261,38 @@ epic_set_mchash(struct epic_softc *sc)
struct ether_multistep step;
u_int32_t hash, mchash[4];
- /*
-* Set up the multicast address filter by passing all multicast
-* addresses through a CRC generator, and then using the low-order
-* 6 bits as an index into the 64 bit multicast hash table (only
-* the lower 16 bits of each 32 bit multicast hash register are
-* valid). The high order bits select the register, while the
-* rest of the bits select the bit within the register.
-*/
-
- if (ifp-if_flags IFF_PROMISC)
- goto allmulti;
-
- if (IFM_SUBTYPE(sc-sc_mii.mii_media_active) == IFM_10_T) {
- /* XXX hardware bug in 10Mbps mode. */
- goto allmulti;
- }
+ ifp-if_flags = ~IFF_ALLMULTI;
- if (ac-ac_multirangecnt 0)
- goto allmulti;
+ if (ifp-if_flags IFF_PROMISC || ac-ac_multirangecnt 0 ||
+ IFM_SUBTYPE(sc-sc_mii.mii_media_active) == IFM_10_T) {
+ ifp-if_flags |= IFF_ALLMULTI;
+ mchash[0] = mchash[1] = mchash[2] = mchash[3] = 0x;
+ } else {
+ mchash[0] = mchash[1] = mchash[2] = mchash[3] = 0;
- mchash[0] = mchash[1] = mchash[2] = mchash[3] = 0;
+ /*
+* Set up the multicast address filter by passing all
+* multicast addresses through a CRC generator,
txp(4) 3Com 3XP Typhoon/Sidewinder diff needs testing
Here is a diff for the txp(4) 3Com 3XP Typhoon/Sidewinder driver to clean up
and update the receive filter / ioctl handling code to be in line with the
other drivers.
Anyone with hw and able to test? OK?
Index: if_txp.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_txp.c,v
retrieving revision 1.108
diff -u -p -r1.108 if_txp.c
--- if_txp.c26 Nov 2013 09:50:33 - 1.108
+++ if_txp.c2 Dec 2013 02:04:44 -
@@ -103,7 +103,7 @@ int txp_download_fw_section(struct txp_s
int txp_alloc_rings(struct txp_softc *);
void txp_dma_free(struct txp_softc *, struct txp_dma_alloc *);
int txp_dma_malloc(struct txp_softc *, bus_size_t, struct txp_dma_alloc *,
int);
-void txp_set_filter(struct txp_softc *);
+void txp_iff(struct txp_softc *);
int txp_cmd_desc_numfree(struct txp_softc *);
int txp_command(struct txp_softc *, u_int16_t, u_int16_t, u_int32_t,
@@ -1184,22 +1184,21 @@ txp_ioctl(struct ifnet *ifp, u_long comm
switch(command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- switch (ifa-ifa_addr-sa_family) {
-#ifdef INET
- case AF_INET:
+ if (!(ifp-if_flags IFF_RUNNING))
txp_init(sc);
+
+#ifdef INET
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-sc_arpcom, ifa);
- break;
-#endif /* INET */
- default:
- txp_init(sc);
- break;
- }
+#endif
break;
case SIOCSIFFLAGS:
if (ifp-if_flags IFF_UP) {
- txp_init(sc);
+ if (ifp-if_flags IFF_RUNNING)
+ error = ENETRESET;
+ else
+ txp_init(sc);
} else {
if (ifp-if_flags IFF_RUNNING)
txp_stop(sc);
@@ -1217,7 +1216,7 @@ txp_ioctl(struct ifnet *ifp, u_long comm
if (error == ENETRESET) {
if (ifp-if_flags IFF_RUNNING)
- txp_set_filter(sc);
+ txp_iff(sc);
error = 0;
}
@@ -1235,7 +1234,8 @@ txp_init(struct txp_softc *sc)
s = splnet();
- txp_set_filter(sc);
+ /* Program promiscuous mode and multicast filters. */
+ txp_iff(sc);
txp_command(sc, TXP_CMD_TX_ENABLE, 0, 0, 0, NULL, NULL, NULL, 1);
txp_command(sc, TXP_CMD_RX_ENABLE, 0, 0, 0, NULL, NULL, NULL, 1);
@@ -1843,51 +1843,46 @@ txp_show_descriptor(void *d)
}
void
-txp_set_filter(struct txp_softc *sc)
+txp_iff(struct txp_softc *sc)
{
struct arpcom *ac = sc-sc_arpcom;
struct ifnet *ifp = sc-sc_arpcom.ac_if;
- u_int32_t hashbit, hash[2];
- u_int16_t filter;
- int mcnt = 0;
struct ether_multi *enm;
struct ether_multistep step;
+ u_int32_t hashbit, hash[2];
+ u_int16_t filter;
- if (ifp-if_flags IFF_PROMISC) {
- filter = TXP_RXFILT_PROMISC;
- goto setit;
- }
-
- if (ac-ac_multirangecnt 0)
- ifp-if_flags |= IFF_ALLMULTI;
-
- filter = TXP_RXFILT_DIRECT;
+ bzero(hash, sizeof(hash));
+ ifp-if_flags = ~IFF_ALLMULTI;
- if (ifp-if_flags IFF_BROADCAST)
- filter |= TXP_RXFILT_BROADCAST;
+ /*
+* Always accept broadcast packets.
+* Always accept frames destined to our station address.
+*/
+ filter = TXP_RXFILT_BROADCAST | TXP_RXFILT_DIRECT;
- if (ifp-if_flags IFF_ALLMULTI)
- filter |= TXP_RXFILT_ALLMULTI;
- else {
- hash[0] = hash[1] = 0;
+ if (ifp-if_flags IFF_PROMISC || ac-ac_multirangecnt 0) {
+ ifp-if_flags |= IFF_ALLMULTI;
+ if (ifp-if_flags IFF_PROMISC)
+ filter |= TXP_RXFILT_PROMISC;
+ else
+ filter |= TXP_RXFILT_ALLMULTI;
+ } else {
+ filter |= TXP_RXFILT_HASHMULTI;
ETHER_FIRST_MULTI(step, ac, enm);
while (enm != NULL) {
- mcnt++;
hashbit = (u_int16_t)(ether_crc32_be(enm-enm_addrlo,
ETHER_ADDR_LEN) (64 - 1));
+
hash[hashbit / 32] |= (1 hashbit % 32);
- ETHER_NEXT_MULTI(step, enm);
- }
- if (mcnt 0) {
- filter |= TXP_RXFILT_HASHMULTI;
- txp_command(sc, TXP_CMD_MCAST_HASH_MASK_WRITE,
- 2, hash[0], hash[1], NULL, NULL, NULL, 0);
+ ETHER_NEXT_MULTI(step, enm);
}
}
-setit:
+ txp_command(sc, TXP_CMD_MCAST_HASH_MASK_WRITE,
+ 2, hash[0], hash[1], NULL, NULL, NULL, 0);
cue(4) CATC USB-EL1201A diff needs testing
Here is a diff for the cue(4) CATC USB-EL1201A driver to clean up and update
the receive filter / ioctl handling code to be in line with the other drivers.
Anyone with hw and able to test? OK?
Index: if_cue.c
===
RCS file: /home/cvs/src/sys/dev/usb/if_cue.c,v
retrieving revision 1.64
diff -u -p -r1.64 if_cue.c
--- if_cue.c15 Nov 2013 10:17:39 - 1.64
+++ if_cue.c17 Nov 2013 20:26:19 -
@@ -139,7 +139,7 @@ void cue_init(void *);
void cue_stop(struct cue_softc *);
void cue_watchdog(struct ifnet *);
-void cue_setmulti(struct cue_softc *);
+void cue_iff(struct cue_softc *);
void cue_reset(struct cue_softc *);
int cue_csr_read_1(struct cue_softc *, int);
@@ -340,52 +340,50 @@ cue_getmac(struct cue_softc *sc, void *b
#define CUE_BITS 9
void
-cue_setmulti(struct cue_softc *sc)
+cue_iff(struct cue_softc *sc)
{
+ struct ifnet*ifp = GET_IFP(sc);
struct arpcom *ac = sc-arpcom;
- struct ifnet*ifp;
struct ether_multi *enm;
struct ether_multistep step;
u_int32_t h, i;
- ifp = GET_IFP(sc);
-
- DPRINTFN(2,(%s: cue_setmulti if_flags=0x%x\n,
+ DPRINTFN(2,(%s: cue_iff if_flags=0x%x\n,
sc-cue_dev.dv_xname, ifp-if_flags));
+ CUE_CLRBIT(sc, CUE_ETHCTL, CUE_ETHCTL_PROMISC);
+ ifp-if_flags = ~IFF_ALLMULTI;
+
if (ifp-if_flags IFF_PROMISC || ac-ac_multirangecnt 0) {
ifp-if_flags |= IFF_ALLMULTI;
+ if (ifp-if_flags IFF_PROMISC)
+ CUE_SETBIT(sc, CUE_ETHCTL, CUE_ETHCTL_PROMISC);
for (i = 0; i CUE_MCAST_TABLE_LEN; i++)
sc-cue_mctab[i] = 0xFF;
- cue_mem(sc, CUE_CMD_WRITESRAM, CUE_MCAST_TABLE_ADDR,
- sc-cue_mctab, CUE_MCAST_TABLE_LEN);
- return;
- }
+ } else {
+ /* first, zot all the existing hash bits */
+ for (i = 0; i CUE_MCAST_TABLE_LEN; i++)
+ sc-cue_mctab[i] = 0;
- /* first, zot all the existing hash bits */
- for (i = 0; i CUE_MCAST_TABLE_LEN; i++)
- sc-cue_mctab[i] = 0;
-
- /* now program new ones */
- ETHER_FIRST_MULTI(step, ac, enm);
- while (enm != NULL) {
- h = ether_crc32_le(enm-enm_addrlo, ETHER_ADDR_LEN)
- ((1 CUE_BITS) - 1);
- sc-cue_mctab[h 3] |= 1 (h 0x7);
- ETHER_NEXT_MULTI(step, enm);
- }
+ /* now program new ones */
+ ETHER_FIRST_MULTI(step, ac, enm);
+ while (enm != NULL) {
+ h = ether_crc32_le(enm-enm_addrlo, ETHER_ADDR_LEN)
+ ((1 CUE_BITS) - 1);
- ifp-if_flags = ~IFF_ALLMULTI;
+ sc-cue_mctab[h 3] |= 1 (h 0x7);
+
+ ETHER_NEXT_MULTI(step, enm);
+ }
+ }
/*
* Also include the broadcast address in the filter
* so we can receive broadcast frames.
*/
- if (ifp-if_flags IFF_BROADCAST) {
- h = ether_crc32_le(etherbroadcastaddr, ETHER_ADDR_LEN)
- ((1 CUE_BITS) - 1);
- sc-cue_mctab[h 3] |= 1 (h 0x7);
- }
+ h = ether_crc32_le(etherbroadcastaddr, ETHER_ADDR_LEN)
+ ((1 CUE_BITS) - 1);
+ sc-cue_mctab[h 3] |= 1 (h 0x7);
cue_mem(sc, CUE_CMD_WRITESRAM, CUE_MCAST_TABLE_ADDR,
sc-cue_mctab, CUE_MCAST_TABLE_LEN);
@@ -970,17 +968,12 @@ cue_init(void *xsc)
DPRINTFN(10,(%s: %s: enter\n, sc-cue_dev.dv_xname,__func__));
- if (ifp-if_flags IFF_RUNNING)
- return;
-
s = splnet();
/*
* Cancel pending I/O and free all RX/TX buffers.
*/
-#if 1
cue_reset(sc);
-#endif
/* Set advanced operation modes. */
cue_csr_write_1(sc, CUE_ADVANCED_OPMODES,
@@ -1011,8 +1004,8 @@ cue_init(void *xsc)
return;
}
- /* Load the multicast filter. */
- cue_setmulti(sc);
+ /* Program promiscuous mode and multicast filters. */
+ cue_iff(sc);
/*
* Set the number of RX and TX buffers that we want
@@ -1094,37 +1087,24 @@ cue_ioctl(struct ifnet *ifp, u_long comm
switch(command) {
case SIOCSIFADDR:
ifp-if_flags |= IFF_UP;
- cue_init(sc);
-
- switch (ifa-ifa_addr-sa_family) {
+ if (!(ifp-if_flags IFF_RUNNING))
+ cue_init(sc);
#ifdef INET
- case AF_INET:
+ if (ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit(sc-arpcom, ifa);
- break;
-#endif /* INET */
- }
+#endif
break;
case SIOCSIFFLAGS:
if (ifp-if_flags
LLVM warning in sys/dev/isa/sb.c
The sc_model field is currently set to an unsigned int type but the Sound
Blaster code expects a signed type since it sets the model to SB_UNK which
as can be seen from the diff below has a value of -1.
../../../../dev/isa/sb.c:307:8: error: comparison of 0 = unsigned expression
is always true [-Werror,-Wtautological-compare]
OK?
Index: sbdspvar.h
===
RCS file: /home/cvs/src/sys/dev/isa/sbdspvar.h,v
retrieving revision 1.16
diff -u -p -r1.16 sbdspvar.h
--- sbdspvar.h 14 Mar 2002 03:16:05 - 1.16
+++ sbdspvar.h 29 Nov 2013 02:45:11 -
@@ -162,7 +162,7 @@ struct sbdsp_softc {
#define SBM_CT1745 4
#define ISSBM1745(x) ((x)-sc_mixer_model = SBM_CT1XX5)
- u_int sc_model; /* DSP model */
+ int sc_model; /* DSP model */
#define SB_UNK -1
#define SB_1 0 /* original SB */
#define SB_20 1 /* SB 2 */
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
LLVM warning in sys/compat/linux/linux_misc.c
Remove unsigned comparison 0.
../../../../compat/linux/linux_misc.c:1531:24: error: comparison of unsigned
expression 0 is always false [-Werror,-Wtautological-compare]
Comments? OK?
Index: linux_misc.c
===
RCS file: /home/cvs/src/sys/compat/linux/linux_misc.c,v
retrieving revision 1.83
diff -u -p -r1.83 linux_misc.c
--- linux_misc.c25 Oct 2013 05:10:03 - 1.83
+++ linux_misc.c29 Nov 2013 02:32:48 -
@@ -1657,7 +1657,7 @@ linux_sys_prctl(struct proc *p, void *v,
switch (SCARG(uap, option)) {
case LINUX_PR_SET_PDEATHSIG:
- if (SCARG(uap, arg2) 0 || SCARG(uap, arg2) = LINUX__NSIG)
+ if (SCARG(uap, arg2) = LINUX__NSIG)
return (EINVAL);
ed-pdeath_signal = SCARG(uap, arg2);
break;
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Genesys Logic GL620USB-A, USB PC-to-PC link cable (take 2)
On 14/11/13 3:29 PM, SASANO Takayoshi wrote: Hello, Here is Genesys Logic's GL620USB-A driver, new version. I fixed crashing bug when peer is not connected, rewrite sc_dying to usbd_is_dying() (advices from mpi@), and deleted useless codes. This is still work in progress, man is not yet. And please tell me which I have to write copyright notice --- NetBSD or OpenBSD. if_ugl.c is based on if_upl.c, and if_upl.c has NetBSD's one. IMO this is in good enough shape to get it into the tree as is. There are a few issues that need fixing but it would be better to fix them once this has been commited to the tree. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
