Re: Cannot use a keydisk to encrypt the Raspberry Pi (but passphrase works)
Not a bug. My fault. Manually encrypting the devices in the shell requires the use of "fdisk" to create 2 partitions, one FAT32 (0C) and the other OpenBSD (A6). By calling "fdisk -iy", it would only create one A6 partition. The Raspberry Pi will not boot like this. Only the guided installation was working before (with a passphrase) -- it creates the 2 partitions for you. I never actually attempted to manually encrypt the devices in a shell, with a passphrase, or it would also fail -- and this bug report would never have existed. Sorry. I tried to mirror what the guided installation creates: a 16MB (32768) Win95 FAT32L partition number 0 (starting at 32768), and an OpenBSD partition number 3 starting at 65536, taking up the rest of the disk. It worked. A fully-encrypted Raspberry Pi. Wonderful.
'pfctl -K' does not kill source tracking entries for src/dst couples
>Synopsis: Bug using 'pfctl -K' to kill source tracking entries for specific source/destination couples >Category: system >Environment: System : OpenBSD 7.4 Details : OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023 r...@syspatch-74-amd64.openbsd.org: /usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: 'pfctl -K key' allows to kill all source tracking entries for specific sources or for every sources. Repeating the '-K key' could allow to delete those entries for the specific destination following the second -K option. Looking at the source code (sbin/pfctl/pfctl.c), I found in pfctl_kill_src_nodes() that the destination address is not copied in the 'psnk_dst' of the 'struct psnk' but in the 'psnk_src' (maybe a typo ?). >Fix: I would just suggest to change the address given to the 'copy_satopfaddr' from the source to the destination, as I did in the following lines. --- src/sbin/pfctl/pfctl.c 2024-01-25 07:32:49.837429476 +0100 +++ pfctl.c 2024-01-29 18:20:52.271923562 +0100 @@ -514,7 +514,7 @@ pfctl_kill_src_nodes(int dev, int opts) dests++; - copy_satopfaddr(_src.addr.v.a.addr, + copy_satopfaddr(_dst.addr.v.a.addr, resp[1]->ai_addr); if (ioctl(dev, DIOCKILLSRCNODES, ) == -1) Best regards, Olivier.
Re: TSO em(4) problem
On Sun, Jan 28, 2024 at 07:46:29PM +0100, Marcus Glocker wrote:
> Anyway, the TSO support just has been backed out. Thanks again for all
> your testing!
I am still interested to get em with TSO working if possible. Most
use cases work fine. If there is a bug in our driver, we may fix
it. If it is hardware bug, we should identitfy the broken chip
revisions.
Here is the backed out em TSO diff together with the TCP header
diff for sparc64.
Kurt, could you still test this in your next sparc64 build?
bluhm
Index: dev/pci/if_em.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/dev/pci/if_em.c,v
diff -u -p -r1.371 if_em.c
--- dev/pci/if_em.c 28 Jan 2024 18:42:58 - 1.371
+++ dev/pci/if_em.c 29 Jan 2024 14:37:36 -
@@ -291,6 +291,8 @@ void em_receive_checksum(struct em_softc
struct mbuf *);
u_int em_transmit_checksum_setup(struct em_queue *, struct mbuf *, u_int,
u_int32_t *, u_int32_t *);
+u_int em_tso_setup(struct em_queue *, struct mbuf *, u_int, u_int32_t *,
+ u_int32_t *);
u_int em_tx_ctx_setup(struct em_queue *, struct mbuf *, u_int, u_int32_t *,
u_int32_t *);
void em_iff(struct em_softc *);
@@ -1188,7 +1190,7 @@ em_flowstatus(struct em_softc *sc)
*
* This routine maps the mbufs to tx descriptors.
*
- * return 0 on success, positive on failure
+ * return 0 on failure, positive on success
**/
u_int
em_encap(struct em_queue *que, struct mbuf *m)
@@ -1236,7 +1238,15 @@ em_encap(struct em_queue *que, struct mb
}
if (sc->hw.mac_type >= em_82575 && sc->hw.mac_type <= em_i210) {
- used += em_tx_ctx_setup(que, m, head, _upper, _lower);
+ if (ISSET(m->m_pkthdr.csum_flags, M_TCP_TSO)) {
+ used += em_tso_setup(que, m, head, _upper,
+ _lower);
+ if (!used)
+ return (used);
+ } else {
+ used += em_tx_ctx_setup(que, m, head, _upper,
+ _lower);
+ }
} else if (sc->hw.mac_type >= em_82543) {
used += em_transmit_checksum_setup(que, m, head,
_upper, _lower);
@@ -1569,6 +1579,21 @@ em_update_link_status(struct em_softc *s
ifp->if_link_state = link_state;
if_link_state_change(ifp);
}
+
+ /* Disable TSO for 10/100 speeds to avoid some hardware issues */
+ switch (sc->link_speed) {
+ case SPEED_10:
+ case SPEED_100:
+ if (sc->hw.mac_type >= em_82575 && sc->hw.mac_type <= em_i210) {
+ ifp->if_capabilities &= ~IFCAP_TSOv4;
+ ifp->if_capabilities &= ~IFCAP_TSOv6;
+ }
+ break;
+ case SPEED_1000:
+ if (sc->hw.mac_type >= em_82575 && sc->hw.mac_type <= em_i210)
+ ifp->if_capabilities |= IFCAP_TSOv4 | IFCAP_TSOv6;
+ break;
+ }
}
/*
@@ -1988,6 +2013,7 @@ em_setup_interface(struct em_softc *sc)
if (sc->hw.mac_type >= em_82575 && sc->hw.mac_type <= em_i210) {
ifp->if_capabilities |= IFCAP_CSUM_IPv4;
ifp->if_capabilities |= IFCAP_CSUM_TCPv6 | IFCAP_CSUM_UDPv6;
+ ifp->if_capabilities |= IFCAP_TSOv4 | IFCAP_TSOv6;
}
/*
@@ -2231,9 +2257,9 @@ em_setup_transmit_structures(struct em_s
for (i = 0; i < sc->sc_tx_slots; i++) {
pkt = >tx.sc_tx_pkts_ring[i];
- error = bus_dmamap_create(sc->sc_dmat,
MAX_JUMBO_FRAME_SIZE,
+ error = bus_dmamap_create(sc->sc_dmat, EM_TSO_SIZE,
EM_MAX_SCATTER / (sc->pcix_82544 ? 2 : 1),
- MAX_JUMBO_FRAME_SIZE, 0, BUS_DMA_NOWAIT,
>pkt_map);
+ EM_TSO_SEG_SIZE, 0, BUS_DMA_NOWAIT, >pkt_map);
if (error != 0) {
printf("%s: Unable to create TX DMA map\n",
DEVNAME(sc));
@@ -2403,6 +2429,81 @@ em_free_transmit_structures(struct em_so
0, que->tx.sc_tx_dma.dma_map->dm_mapsize,
BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE);
}
+}
+
+u_int
+em_tso_setup(struct em_queue *que, struct mbuf *mp, u_int head,
+u_int32_t *olinfo_status, u_int32_t *cmd_type_len)
+{
+ struct ether_extracted ext;
+ struct e1000_adv_tx_context_desc *TD;
+ uint32_t vlan_macip_lens = 0, type_tucmd_mlhl = 0, mss_l4len_idx = 0;
+ uint32_t paylen = 0;
+ uint8_t iphlen = 0;
+
+ *olinfo_status = 0;
+ *cmd_type_len = 0;
+ TD = (struct e1000_adv_tx_context_desc
Re: TSO em(4) problem
On Sat, Jan 27, 2024 at 08:08:35AM +0100, Hrvoje Popovski wrote:
> On 26.1.2024. 22:47, Alexander Bluhm wrote:
> > On Fri, Jan 26, 2024 at 11:41:49AM +0100, Hrvoje Popovski wrote:
> >> I've manage to reproduce TSO em problem on anoter setup, unfortunatly
> >> production.
> > What helped debugging a similar issue with ixl(4) and TSO was to
> > remove all TSO specific code from the driver. Then only this part
> > remains from the original em(4) TSO diff.
> >
> > error = bus_dmamap_create(sc->sc_dmat, EM_TSO_SIZE,
> > EM_MAX_SCATTER / (sc->pcix_82544 ? 2 : 1),
> > EM_TSO_SEG_SIZE, 0, BUS_DMA_NOWAIT, >pkt_map);
> >
> > The parameters that changed when adding TSO are:
> >
> > bus_size_t size:MAX_JUMBO_FRAME_SIZE 16128 -> EM_TSO_SIZE 65535
> > bus_size_t maxsegsz:MAX_JUMBO_FRAME_SIZE 16128 -> EM_TSO_SEG_SIZE
> > 4096
> >
> > I suspect that this is the cause for the regression as disabling
> > TSO did not help. Would it be possible to run the diff below? I
> > expect that the problem will still be there. But then we know it
> > must be the change of one of the bus_dmamap_create() arguments.
> >
> > bluhm
>
> Hi,
>
> with this diff em0 seems happy and em watchdog is gone.
This is very interesting. That means that the bus_dmamap_create()
argument does not cause the regression.
Did you see anywhere "output TSO packets hardware processed in"
netstat -s. In some iteration of testing you turned TSO off with
sysctl net.inet.tcp.tso=0, but it did not help. So no TSO packets
from the stack.
In another mail you mentioned
> Setup is very simple
> em0 - carp <- uplink
> em1 - pfsync
> ix1 - vlans - carp
ix supports LRO. If you forward from ix1 to em0 the LRO packets
from ix hardware are split by TSO on em hardware. And the ix does
vlan offloading + LRO, so em must do vlan offloading properly with
TSO. Or do you use a vlan interface?
Does it help to disable LRO, ifconfig ix1 -tcplro ?
I see this vlan code with mac_type checks. Can we end in a
configuration where we enable TSO but cannot do VLAN offloading?
#if NVLAN > 0
/* Find out if we are in VLAN mode */
if (m->m_flags & M_VLANTAG && (sc->hw.mac_type < em_82575 ||
sc->hw.mac_type > em_i210)) {
/* Set the VLAN id */
desc->upper.fields.special = htole16(m->m_pkthdr.ether_vtag);
/* Tell hardware to add tag */
desc->lower.data |= htole32(E1000_TXD_CMD_VLE);
}
#endif
Hrvoje, I know you do great tests in your lab. Did you try this
setup:
Send bulk TCP traffic in vlan that will trigger LRO.
Do VLAN + LRO offloading in ix.
Forward it to em with TSO.
In theory when going through vlan interface it should remove
M_VLANTAG. But something must be wrong and I wonder what.
bluhm
