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.
> >
&g
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 -
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 workaroun
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 ELF
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
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
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 re
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
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
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 Op
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
---
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 u
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
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 sur
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
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
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
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 -
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 fo
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
-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,
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.
On 01/21/15 06:51, Jim Smith wrote:
hi all,
the below diff enables support for jumbo frames on
some newer re(4) devices. i've tested it on 8186D/8111D
and 8186E/8111E chips, which are both able to do 9k
jumbos. it seems to provide a significant speed-up on
simple file transfer tests. most of the
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.mic
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
dangero
On 09/20/14 15:34, Philip Guenther wrote:
On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis wrote:
Date: Sat, 20 Sep 2014 18:15:31 +
From: Miod Vallat
shmctl(2)/shmget(2)/shmat(2) all document
#include
#include
#include
as a requirement for calling these functions.
That was my first
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
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 workarou
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 a
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 (0x
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
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 de
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.13
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.
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
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 ch
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 "Realte
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/
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:
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
retrievi
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.
--
T
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 te
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
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
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 i
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 "B
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 0
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 mor
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 inet autoconf
ifconfig inet6 autoconf
aka inet/inet6 autoconf in hostname.if.
I'm curious to see what w
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
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 "Schn
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 defi
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
> >
> > > Index: arch/socppc/dev/if_tsec.c
> > > ===
> > >
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 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 wrote:
> >
> > > On 31/12/13 5:50 AM, Mike Belopuhov wrote:
> > >> On 31 December
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
con
On Tue, Jan 28, 2014 at 01:21:46PM +1000, David Gwynne wrote:
>
> On 26 Jan 2014, at 11:31 am, Brad Smith wrote:
>
> > On 31/12/13 5:50 AM, Mike Belopuhov wrote:
> >> On 31 December 2013 09:46, Brad Smith wrote:
> >>> On 31/12/13 3:14 AM, Mark Kettenis wrote
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_RXMO
On 31/12/13 5:50 AM, Mike Belopuhov wrote:
On 31 December 2013 09:46, Brad Smith wrote:
On 31/12/13 3:14 AM, Mark Kettenis wrote:
Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith
Don't count RX overruns and missed packets as inputs errors. They're
expected to increment
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
> > &g
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
> > &g
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/c
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
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
The default PF ruleset as setup by rc is too restrictive. Have the default
ruleset allow for DHCPv6.
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 -00
On 31/12/13 5:50 AM, Mike Belopuhov wrote:
On 31 December 2013 09:46, Brad Smith wrote:
On 31/12/13 3:14 AM, Mark Kettenis wrote:
Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith
Don't count RX overruns and missed packets as inputs errors. They're
expected to increment
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.
> >
On 31/12/13 3:14 AM, Mark Kettenis wrote:
Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith
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 tha
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.
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/r
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
eeph
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
On 21/12/13 3:14 PM, Craig R. Skinner wrote:
On 2013-12-21 Sat 09:16 AM |, Theo de Raadt wrote:
You seem to be coming from the perspective that people do stupid
things, and our base system should handle those stupid things.
My perspective is maildir (backed IMAP) is commonly deployed,
and suc
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'
[-Werro
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
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_
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
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]
>
>
7;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.
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 rev
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 '
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
===
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
===
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
===
RC
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]
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/s
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
This popped out at me when I was looking at this driver awhile ago but I see
now LLVM even warns about the fact that it is unused within the smc91cxx
driver code.
smc91cxx.c:191:1: error: unused function 'ether_cmp' [-Werror,-Wunused-function]
OK?
Index: smc91cxx.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
di
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?
Index: if_cdce.c
===
RCS file: /home/cvs/src/sys/dev/usb/if_cdce.c,v
retrieving revision
On 02/12/13 7:36 AM, Mike Belopuhov wrote:
On 2 December 2013 03:07, Brad Smith 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
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
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
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/s
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
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
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:
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/
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
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
=
1 - 100 of 475 matches
Mail list logo
