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 Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
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 might fix ix(4). anyone able to test?
Index: if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.99
diff -u -p -r1.99 if_ix.c
--- if_ix.c 26 Aug 2014 11:01:22 - 1.99
+++ if_ix.c 27 Aug 2014 11:16:53 -
@@ -441,18 +441,6 @@ ixgbe_ioctl(struct ifnet * ifp, u_long c
#endif
break;
- case SIOCSIFMTU:
- IOCTL_DEBUGOUT(ioctl: SIOCSIFMTU (Set Interface MTU));
- if (ifr-ifr_mtu ETHERMIN || ifr-ifr_mtu ifp-if_hardmtu)
- error = EINVAL;
- else if (ifp-if_mtu != ifr-ifr_mtu) {
- ifp-if_mtu = ifr-ifr_mtu;
- sc-max_frame_size =
- ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN;
- ixgbe_init(sc);
- }
- break;
-
case SIOCSIFFLAGS:
IOCTL_DEBUGOUT(ioctl: SIOCSIFFLAGS (Set Interface Flags));
if (ifp-if_flags IFF_UP) {
@@ -690,7 +678,7 @@ ixgbe_init(void *arg)
IXGBE_WRITE_REG(sc-hw, IXGBE_GPIE, gpie);
/* Set MTU size */
- if (ifp-if_mtu ETHERMTU) {
+ if (ifp-if_hardmtu ETHERMTU) {
mhadd = IXGBE_READ_REG(sc-hw, IXGBE_MHADD);
mhadd = ~IXGBE_MHADD_MFS_MASK;
mhadd |= sc-max_frame_size IXGBE_MHADD_MFS_SHIFT;
@@ -1596,7 +1584,7 @@ ixgbe_setup_interface(struct ix_softc *s
ether_ifattach(ifp);
sc-max_frame_size =
- ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN;
+ ifp-if_hardmtu + ETHER_HDR_LEN + ETHER_CRC_LEN;
}
void
@@ -2680,7 +2668,7 @@ ixgbe_initialize_receive_units(struct ix
/* Set for Jumbo Frames? */
hlreg = IXGBE_READ_REG(sc-hw, IXGBE_HLREG0);
- if (ifp-if_mtu ETHERMTU)
+ if (ifp-if_hardmtu ETHERMTU)
hlreg |= IXGBE_HLREG0_JUMBOEN;
else
hlreg = ~IXGBE_HLREG0_JUMBOEN;
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
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 might fix oce. can anyone test?
Index: if_oce.c
===
RCS file: /cvs/src/sys/dev/pci/if_oce.c,v
retrieving revision 1.78
diff -u -p -r1.78 if_oce.c
--- if_oce.c14 Aug 2014 09:52:03 - 1.78
+++ if_oce.c27 Aug 2014 11:21:53 -
@@ -879,14 +879,6 @@ oce_ioctl(struct ifnet *ifp, u_long comm
oce_stop(sc);
}
break;
- case SIOCSIFMTU:
- if (ifr-ifr_mtu OCE_MIN_MTU || ifr-ifr_mtu OCE_MAX_MTU)
- error = EINVAL;
- else if (ifp-if_mtu != ifr-ifr_mtu) {
- ifp-if_mtu = ifr-ifr_mtu;
- oce_init(sc);
- }
- break;
case SIOCGIFMEDIA:
case SIOCSIFMEDIA:
error = ifmedia_ioctl(ifp, ifr, sc-sc_media, command);
@@ -1084,7 +1076,7 @@ oce_init(void *arg)
goto error;
OCE_RQ_FOREACH(sc, rq, i) {
- rq-mtu = ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN +
+ rq-mtu = ifp-if_hardmtu + ETHER_HDR_LEN + ETHER_CRC_LEN +
ETHER_VLAN_ENCAP_LEN;
if (oce_new_rq(sc, rq)) {
printf(%s: failed to create rq\n,
newsyslog.conf: add httpd default log files to the rotation
Add httpd default log files to the rotation. Index: newsyslog.conf === RCS file: /cvs/src/etc/newsyslog.conf,v retrieving revision 1.32 diff -u -p -r1.32 newsyslog.conf --- newsyslog.conf 26 Aug 2014 19:33:48 - 1.32 +++ newsyslog.conf 27 Aug 2014 11:49:40 - @@ -14,3 +14,5 @@ /var/log/wtmp 644 7 *$W6D4 B /var/log/xferlog 640 7 250 * Z /var/log/pflog 600 3 250 * ZB pkill -HUP -u root -U root -t - -x pflogd +/var/www/logs/access.log 644 4 *$W0 Z pkill -USR1 -u root -U root -x httpd +/var/www/logs/error.log644 7 250 * Z pkill -USR1 -u root -U root -x httpd -- Christian naddy Weisgerber na...@mips.inka.de
Re: newsyslog.conf: add httpd default log files to the rotation
On Wed, Aug 27, 2014 at 01:52:19PM +0200, Christian Weisgerber wrote: Add httpd default log files to the rotation. Index: newsyslog.conf === RCS file: /cvs/src/etc/newsyslog.conf,v retrieving revision 1.32 diff -u -p -r1.32 newsyslog.conf --- newsyslog.conf26 Aug 2014 19:33:48 - 1.32 +++ newsyslog.conf27 Aug 2014 11:49:40 - @@ -14,3 +14,5 @@ /var/log/wtmp644 7 *$W6D4 B /var/log/xferlog 640 7 250 * Z /var/log/pflog 600 3 250 * ZB pkill -HUP -u root -U root -t - -x pflogd +/var/www/logs/access.log 644 4 *$W0 Z pkill -USR1 -u root -U root -x httpd +/var/www/logs/error.log 644 7 250 * Z pkill -USR1 -u root -U root -x httpd ok Reyk
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On 27 August 2014 13:17, David Gwynne da...@gwynne.id.au wrote: On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote: 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 might fix ix(4). anyone able to test? ix and oce (internally though) calculate various paramethers related to flow control, internal buffer sizes and so on based on the maximum frame size. therefore if i set max frame size to 16k but always use 1,5k all these calculations will be off. and by killing SIOCSIFMTU you make it impossible for the driver to readjust them. we have no idea at the moment how will this affect nic's behavior. pieces of such black magic such as the code under /* Hardware Packet Buffer Flow Control setup */ comment must be studied before making such changes. and as i've mentioned to dlg, ix diff also switches it to using 16k cluster pool no matter what you actually need. this can be changed, but needs testing (i'm doing it now).
Re: patch: acpitz: active cooling and notify 0x81
Hi Jonathan,
First, thanks for your feedback and for your patch.
On Wed, Aug 27, 2014 at 02:42:43AM +1000, Jonathan Gray wrote:
Rather than calling acpi_setfan() again would it make
sense to remove the cached state value and move
the state reading to just before the method is called?
That said I'm not familiar with the acpitz code and
haven't gone off to look at the spec.
At first reading I am quite disappointed to remove caching.
So I have:
- checked in others acpi termal-zone implementation to see if caching
is using or not for active cooling.
- try to measure some values on my host.
Others implementations checked:
- netbsd : caching used (sys/dev/acpi/acpi_tz.c, l.368)
- freebsd : caching used (head/sys/dev/acpica/acpi_thermal.c, l.564)
- linux : caching seems not be used (but not 100% sure)
(please note I am not expert in theses kernels implementations, so I
could be wrong).
Some measures:
I first try to measure the cost of acpi_setfan in term of time:
something between 9998432ns et 14574920ns (0.0099 and 0.015 s). It
seems not being a heavy operation (too my eyes).
Secondly, the number of call of acpi_setfan, with and without caching.
The test kernel is build with caching enable. The without-caching
counter is incremented every time acpi_setfan would be call without
caching, and with-caching counter incremented only when acpi_setfan is
called (the patch below was applied: an unknown state would result
acpi_setfan calling).
During 1h09 :
- without caching: 3388 calls
- with caching: 742 calls
The cache is used at 78% of time.
So, even if your patch resolve the initial problem (the fan don't keep
running whereas state is unknown), I would prefer to keep the cache in
place. But if you think the impact of not use this cache is negligible,
it is ok for me.
I join a very conservative patch which just allow calling
acpi_setfan(sc,i,_OFF) if cache is unknown.
Thanks.
--
Sébastien Marie
Index: dev/acpi/acpitz.c
===
RCS file: /cvs/src/sys/dev/acpi/acpitz.c,v
retrieving revision 1.47
diff -u -p -r1.47 acpitz.c
--- dev/acpi/acpitz.c 12 Jul 2014 02:44:49 - 1.47
+++ dev/acpi/acpitz.c 27 Aug 2014 12:38:36 -
@@ -424,7 +424,7 @@ acpitz_refresh(void *arg)
acpitz_setfan(sc, i, _ON_);
} else if (sc-sc_ac[i] != -1) {
/* turn off fan i */
- if (sc-sc_ac_stat[i] 0)
+ if (sc-sc_ac_stat[i] == -1 || sc-sc_ac_stat[i] 0)
acpitz_setfan(sc, i, _OFF);
}
}
Re: let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
On 27 August 2014 13:23, David Gwynne da...@gwynne.id.au wrote: On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote: 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 might fix oce. can anyone test? works fine here. i think we can go with this one. OK mikeb
Re: bge(4) Jumbo support for newer chipsets
On 27 August 2014 08:25, Brad Smith b...@comstyle.com wrote: Looking for some testing of the following diff to add Jumbo support for the BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766 chipsets. i have tested this on Broadcom BCM5719 rev 0x01, unknown BCM5719 (0x5719001), APE firmware NCSI 1.1.15.0 and Broadcom BCM5714 rev 0xa3, BCM5715 A3 (0x9003). it works, however i'm not strictly a fan of switching the cluster pool to larger one for 5714. wasting another 8k page (on sparc for example) for every rx cluster in 90% cases sounds kinda wrong to me. but ymmv. apart from that there's a deficiency in the diff itself. you probably want to change MCLBYTES in bge_rxrinfo to bge_rx_std_len otherwise statistics look wrong. i'm certainly OK with !5714 part of the diff.
changing ffs mount between rw and ro while preserving softdep
Why not keep the softdep flag when updating rw-ro?
E.g. via mount -ur /usr/obj
fstab(5) already allows ro+softdep.
--- /usr/src/sys/ufs/ffs/ffs_vfsops.c.orig Wed Aug 27 19:00:31 2014
+++ /usr/src/sys/ufs/ffs/ffs_vfsops.c Wed Aug 27 19:01:19 2014
@@ -218,10 +218,9 @@
flags = WRITECLOSE;
if (mp-mnt_flag MNT_FORCE)
flags |= FORCECLOSE;
- if (fs-fs_flags FS_DOSOFTDEP) {
+ if (fs-fs_flags FS_DOSOFTDEP)
error = softdep_flushfiles(mp, flags, p);
- mp-mnt_flag = ~MNT_SOFTDEP;
- } else
+ else
error = ffs_flushfiles(mp, flags, p);
ronly = 1;
}
--
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Re: changing ffs mount between rw and ro while preserving softdep
Why not keep the softdep flag when updating rw-ro? E.g. via mount -ur /usr/obj fstab(5) already allows ro+softdep. Because if we were to apply this diff, there would be no way to switch from rw+softdep to rw.
Re: changing ffs mount between rw and ro while preserving softdep
On Wed, Aug 27, 2014 at 11:50 AM, Miod Vallat m...@online.fr wrote: Why not keep the softdep flag when updating rw-ro? E.g. via mount -ur /usr/obj fstab(5) already allows ro+softdep. Because if we were to apply this diff, there would be no way to switch from rw+softdep to rw. And what exactly is the operational/behavioral difference between ro and ro+softdep?
Re: changing ffs mount between rw and ro while preserving softdep
On 08/27/14 16:59, Philip Guenther wrote: On Wed, Aug 27, 2014 at 11:50 AM, Miod Vallat m...@online.fr wrote: Why not keep the softdep flag when updating rw-ro? E.g. via mount -ur /usr/obj fstab(5) already allows ro+softdep. Because if we were to apply this diff, there would be no way to switch from rw+softdep to rw. And what exactly is the operational/behavioral difference between ro and ro+softdep? Extra code being executed when it doesn't have to be? --STeve Andre'
/usr/share/misc/mime.types diff
Compared the new mime.types file to the one from nginx and found this. Index: mime.types === RCS file: /cvs/src/share/misc/mime.types,v retrieving revision 1.1 diff -u -p -r1.1 mime.types --- mime.types 25 Aug 2014 14:27:54 - 1.1 +++ mime.types 28 Aug 2014 03:26:24 - @@ -75,7 +75,7 @@ image/vnd.wap.wbmpwbmp image/webp webp image/x-icon ico image/x-jngjng -image/x-ms-bmp mp +image/x-ms-bmp bmp text/css css text/html html htm shtml
Re: Make procfs root listing work again
On Wed, Aug 20, 2014 at 5:23 AM, Visa Hankala v...@hankala.org wrote: On Tue, Aug 19, 2014 at 10:14:59PM -0700, Philip Guenther wrote: Can you describe what you're using that needs it? Well, I am not using it. The code has not been sent to the Attic yet and I happened to take a look at it. That is all. So, broken for 5.5, disabled for 5.6, and no one has said I'm using this in 5.4 for details, help! Maybe I'll fire up my tedu keyboard (manufactured by Stihl) this weekend... Philip Guenther
