A cleanup block for virtio.c vionet_notifyq()
It looks like there were two cases of a memory leak (lack of free(pkt)). Also fix typo: unexpceted -> unexpected, and remove an empty line after a while(). Index: virtio.c === RCS file: /cvs/src/usr.sbin/vmd/virtio.c,v retrieving revision 1.4 diff -u -p -r1.4 virtio.c --- virtio.c3 Dec 2015 08:42:11 - 1.4 +++ virtio.c1 Jan 2016 07:28:48 - @@ -1005,7 +1005,6 @@ vionet_notify_rx(struct vionet_dev *dev) /* - * XXX this function needs a cleanup block, lots of free(blah); return (0) * XXX cant trust ring data from VM, be extra cautious. * XXX advertise link status to guest */ @@ -1022,12 +1021,13 @@ vionet_notifyq(struct vionet_dev *dev) struct vring_avail *avail; struct vring_used *used; + vr = pkt = NULL; ret = 0; /* Invalid queue? */ if (dev->cfg.queue_notify != 1) { vionet_notify_rx(dev); - return (0); + goto out; } vr_sz = vring_size(VIONET_QUEUE_SIZE); @@ -1037,7 +1037,7 @@ vionet_notifyq(struct vionet_dev *dev) vr = malloc(vr_sz); if (vr == NULL) { log_warn("malloc error getting vionet ring"); - return (0); + goto out; } bzero(vr, vr_sz); @@ -1046,8 +1046,7 @@ vionet_notifyq(struct vionet_dev *dev) if (read_page((uint32_t)q_gpa + i, vr + i, PAGE_SIZE, 0)) { log_warnx("error reading gpa 0x%x", (uint32_t)q_gpa + i); - free(vr); - return (0); + goto out; } } @@ -1064,12 +1063,10 @@ vionet_notifyq(struct vionet_dev *dev) if ((avail->idx & VIONET_QUEUE_MASK) == idx) { log_warnx("vionet tx queue notify - nothing to do?"); - free(vr); - return (0); + goto out; } while ((avail->idx & VIONET_QUEUE_MASK) != idx) { - hdr_desc_idx = avail->ring[idx] & VIONET_QUEUE_MASK; hdr_desc = &desc[hdr_desc_idx]; pktsz = 0; @@ -1093,8 +1090,7 @@ vionet_notifyq(struct vionet_dev *dev) pkt = malloc(pktsz); if (pkt == NULL) { log_warn("malloc error alloc packet buf"); - free(vr); - return (0); + goto out; } ofs = 0; @@ -1104,10 +1100,9 @@ vionet_notifyq(struct vionet_dev *dev) while (pkt_desc->flags & VRING_DESC_F_NEXT) { /* must be not writable */ if (pkt_desc->flags & VRING_DESC_F_WRITE) { - log_warnx("unexpceted writable tx desc " + log_warnx("unexpected writable tx desc " "%d", pkt_desc_idx); - free(vr); - return (0); + goto out; } /* Read packet from descriptor ring */ @@ -1115,9 +1110,7 @@ vionet_notifyq(struct vionet_dev *dev) pkt_desc->len, 0)) { log_warnx("vionet: packet read_page error " "@ 0x%llx", pkt_desc->addr); - free(pkt); - free(vr); - return (0); + goto out; } ofs += pkt_desc->len; @@ -1127,10 +1120,9 @@ vionet_notifyq(struct vionet_dev *dev) /* Now handle tail descriptor - must be not writable */ if (pkt_desc->flags & VRING_DESC_F_WRITE) { - log_warnx("unexpceted writable tx descriptor %d", + log_warnx("unexpected writable tx descriptor %d", pkt_desc_idx); - free(vr); - return (0); + goto out; } /* Read packet from descriptor ring */ @@ -1138,18 +1130,14 @@ vionet_notifyq(struct vionet_dev *dev) pkt_desc->len, 0)) { log_warnx("vionet: packet read_page error @ " "0x%llx", pkt_desc->addr); - free(pkt); - free(vr); - return (0); + goto out; } /* XXX signed vs unsigned here, funky cast */ if (write(dev->fd, pkt, pktsz) != (int)pktsz) { log_warnx("vionet: tx failed writing to tap: " "%d", errno); - free(pkt); - free(vr); -
patch sys/kern/kern_xxx.c for SYSCALL_DEBUG
The following patch permits kern_xxx.c to build with SYSCALL_DEBUG. Index: kern_xxx.c === RCS file: /systems/cvs/src/sys/kern/kern_xxx.c,v retrieving revision 1.29 diff -u -p -u -r1.29 kern_xxx.c --- kern_xxx.c 5 Dec 2015 10:11:53 - 1.29 +++ kern_xxx.c 31 Dec 2015 20:17:26 - @@ -39,6 +39,7 @@ #include #include #include +#include int sys_reboot(struct proc *p, void *v, register_t *retval) @@ -105,9 +106,9 @@ scdebug_call(struct proc *p, register_t printf("proc %d (%s): %s num ", p->p_pid, p->p_comm, em->e_name); if (code < 0 || code >= em->e_nsysent) - printf("OUT OF RANGE (%d)", code); + printf("OUT OF RANGE (%d)", (int) code); else { - printf("%d call: %s", code, em->e_syscallnames[code]); + printf("%d call: %s", (int) code, em->e_syscallnames[code]); if (scdebug & SCDEBUG_SHOWARGS) { printf("("); for (i = 0; i < sy->sy_argsize / sizeof(register_t); @@ -138,9 +139,9 @@ scdebug_ret(struct proc *p, register_t c printf("proc %d (%s): %s num ", p->p_pid, p->p_comm, em->e_name); if (code < 0 || code >= em->e_nsysent) - printf("OUT OF RANGE (%d)", code); + printf("OUT OF RANGE (%d)", (int) code); else - printf("%d ret: err = %d, rv = 0x%lx,0x%lx", code, + printf("%d ret: err = %d, rv = 0x%lx,0x%lx", (int) code, error, (long)retval[0], (long)retval[1]); printf("\n"); }
integer truncation in soreceive()
Another integer overflow: A recv() call with a size of 2^32 bytes causes soreceive() to spin in an endless loop, resulting in a system freeze. The diff below prevents this behaviour by establishing an upper bound for uio_resid before assigning the value to an integer variable with smaller width. Also the 'offset' and 'resid' variables are converted to use the correct integer types. cheers, natano Index: kern/uipc_socket.c === RCS file: /cvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.144 diff -u -p -u -r1.144 uipc_socket.c --- kern/uipc_socket.c 5 Dec 2015 10:11:53 - 1.144 +++ kern/uipc_socket.c 31 Dec 2015 21:26:01 - @@ -613,13 +613,14 @@ soreceive(struct socket *so, struct mbuf { struct mbuf *m, **mp; struct mbuf *cm; - int flags, len, error, s, offset; + int flags, len, error, s; + u_long offset; struct protosw *pr = so->so_proto; struct mbuf *nextrecord; int moff, type = 0; size_t orig_resid = uio->uio_resid; int uio_error = 0; - int resid; + size_t resid; mp = mp0; if (paddr) @@ -639,8 +640,8 @@ soreceive(struct socket *so, struct mbuf if (error) goto bad; do { - error = uiomovei(mtod(m, caddr_t), - (int) min(uio->uio_resid, m->m_len), uio); + error = uiomove(mtod(m, caddr_t), + ulmin(uio->uio_resid, m->m_len), uio); m = m_free(m); } while (uio->uio_resid && error == 0 && m); bad: @@ -833,11 +834,9 @@ dontblock: panic("receive 3"); #endif so->so_state &= ~SS_RCVATMARK; - len = uio->uio_resid; + len = ulmin(uio->uio_resid, m->m_len - moff); if (so->so_oobmark && len > so->so_oobmark - offset) len = so->so_oobmark - offset; - if (len > m->m_len - moff) - len = m->m_len - moff; /* * If mp is set, just pass back the mbufs. * Otherwise copy them out via the uio, then free.
mention /etc/doas.conf instead of plain doas.conf
I just switched from sudo to doas and was stumped by this. The doas code expects doas.conf in /etc yet the manpage does not explicitly make that clear. I added a SYNOPSIS like in "man login.conf". Thanks Index: doas.conf.5 === RCS file: /cvs/src/usr.bin/doas/doas.conf.5,v retrieving revision 1.16 diff -u -p -u -p -r1.16 doas.conf.5 --- doas.conf.5 1 Sep 2015 13:20:53 - 1.16 +++ doas.conf.5 31 Dec 2015 23:39:23 - @@ -19,12 +19,14 @@ .Sh NAME .Nm doas.conf .Nd doas configuration file +.Sh SYNOPSIS +.Nm /etc/doas.conf .Sh DESCRIPTION The .Xr doas 1 utility executes commands as other users according to the rules -in the -.Nm +in +.Nm /etc/doas.conf configuration file. .Pp The rules have the following format: Index: doas.conf.5 === RCS file: /cvs/src/usr.bin/doas/doas.conf.5,v retrieving revision 1.16 diff -u -p -u -p -r1.16 doas.conf.5 --- doas.conf.5 1 Sep 2015 13:20:53 - 1.16 +++ doas.conf.5 31 Dec 2015 23:32:22 - @@ -19,12 +19,14 @@ .Sh NAME .Nm doas.conf .Nd doas configuration file +.Sh SYNOPSIS +.Nm /etc/doas.conf .Sh DESCRIPTION The .Xr doas 1 utility executes commands as other users according to the rules -in the -.Nm +in +.Nm /etc/doas.conf configuration file. .Pp The rules have the following format:
Re: eeprom does not compile on current/macppc
On Thu, 31 Dec 2015 11:23:19 -0800, Philip Guenther wrote: > Putting it in the header[] array appears to generate good output, even > with the -p option. OK millert@, works fine with and without -p. - todd
uvm_io: uiomovei -> uiomove
Hello sz is type vsize_t, and vsize_t and vaddr_t are unsigned long on every arch, so I believe this can safely be converted. vaddr_t baseva, endva, pageoffset, kva; vsize_t chunksz, togo, sz; - David Index: uvm/uvm_io.c === RCS file: /cvs/src/sys/uvm/uvm_io.c,v retrieving revision 1.25 diff -u -p -r1.25 uvm_io.c --- uvm/uvm_io.c14 Mar 2015 03:38:53 - 1.25 +++ uvm/uvm_io.c31 Dec 2015 21:46:14 - @@ -109,7 +109,7 @@ uvm_io(vm_map_t map, struct uio *uio, in sz = chunksz - pageoffset; if (sz > togo) sz = togo; - error = uiomovei((caddr_t) (kva + pageoffset), sz, uio); + error = uiomove((caddr_t) (kva + pageoffset), sz, uio); togo -= sz; baseva += chunksz;
Re: Get PCI resources from ACPI
On Wed, 30 Dec 2015, Mark Kettenis wrote: ... > Updated diff. Once again the ACPI standard is ambiguous and/or violated > by the hardware vendors. This should fix at least the ports Dell r620 > that naddy@ told me about. Here's the diff of dmesgs with-vs-without this diff on my yoga12: @@ -41,6 +41,11 @@ cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 +bus 0 +extent `pcimem' (0x0 - 0x), flags=0 + 0x0 - 0x9 + 0xe - 0xcfff + 0xfeb0 - 0x acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) Everything seems to still be working Philip Guenther
Clarify vmctl(8) console
I wasn't sure which key combination is the escape sequence. Index: vmctl.8 === RCS file: /cvs/src/usr.sbin/vmctl/vmctl.8,v retrieving revision 1.9 diff -u -p -r1.9 vmctl.8 --- vmctl.8 11 Dec 2015 10:16:53 - 1.9 +++ vmctl.8 31 Dec 2015 20:56:22 - @@ -47,7 +47,9 @@ the name of a virtual machine. The options are as follows: .Bl -tag -width Ds .It Cm console Ar id -Connect to the console of the VM with the specified +Using +.Xr cu 1 +connect to the console of the VM with the specified .Ar id . .It Cm create Ar path Fl s Ar size Creates a VM disk image file with the specified -- Michal Mazurek
Re: OpenBSD 5.8 on Xeon-D (1540) systems
> On Dec 31, 2015, at 2:43 PM, Mark Kettenis wrote: > > Can you please send me a dmesg as well as the acpidump output for this > machine? That will give me a chance at figuring out what is going > wrong. Here you go, Mark: http://elemental.org/xeon-d.tar.gz /dale signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenBSD 5.8 on Xeon-D (1540) systems
> From: Dale Ghent > Date: Thu, 31 Dec 2015 13:45:49 -0500 > > > Read my message again. I'm suggesting to turn xhci off in the kernel, > > not the BIOS. > > Alright, so here's an update. This Xeon-D system is able to be booted and > installed using your suggestions: > > In BIOS: > CPU Configuration -> Cores Enabled -> set to 1 > > In UKC: > disable acpi At that point, all bets are off. Disabling acpi is useful as a debugging tool, but don't expect to see a fully functional system after doing this on modern hardware. > disable xhci > > Here's the interesting part: Once installed (with either 5.8 or > 5.9-beta) I can re-enable all 8 cores in the BIOS and the machine > will continue to boot properly (ie, cpu0 will be boot CPU, not an > application CPU as before) > > So, aside from the understandably unsupported 10Gb NICs on this (the > integrated 1Gb NICs don't appear to have problems), there are 3 > issues: > > 1) cpu0 showing up as an application CPU when booting a install >image, but not with an installed image and thus requiring CPUs to be >reduced to 1 and then bumped back up to 8. > 2) acpi needs to be disabled (reasons unknown to me why this needs to happen) > 3) xhci driver needs to be looked at to see why it locks up and >stops kernel progression on boot > > Being a relative noob to this area of OpenBSD, I'm willing to try > some patches if anyone has the inclination to try some ideas. I > think the Xeon-D would be great for OpenBSD-based VPN appliances and > such. Can you please send me a dmesg as well as the acpidump output for this machine? That will give me a chance at figuring out what is going wrong. Cheers, Mark
Re: eeprom does not compile on current/macppc
> From: "Todd C. Miller" > Date: Thu, 31 Dec 2015 12:13:05 -0700 > > On Thu, 31 Dec 2015 11:02:01 -0800, Philip Guenther wrote: > > > Wouldn't it better to have yacc's skeleton.c provide a prototype so > > that it's fixed for all .y files? I see that bison's output includes > > an "int yyparse (void);" prototype, so I would expect minimal ports > > issues. > > That's probably the best approach of all. Somewhat tricky though. It's standard practice to #define yyparse xxx_yyparse in order to prevent namespace problems. The prototype provided by yacc's skeleton.c should come after such a define. Perhaps adding it to the "header" bit will work. But I'm far from sure. It does seem standard practive to provide a yyparse() prototype. So I went ahead and committed that bit. No point in leaving the tree broken. Those who care can submit a diff to change yacc.
Re: eeprom does not compile on current/macppc
On Thu, Dec 31, 2015 at 11:13 AM, Todd C. Miller wrote: > On Thu, 31 Dec 2015 11:02:01 -0800, Philip Guenther wrote: > >> Wouldn't it better to have yacc's skeleton.c provide a prototype so >> that it's fixed for all .y files? I see that bison's output includes >> an "int yyparse (void);" prototype, so I would expect minimal ports >> issues. > > That's probably the best approach of all. Putting it in the header[] array appears to generate good output, even with the -p option. ok? --- skeleton.c 30 Dec 2015 17:16:47 - 1.38 +++ skeleton.c 31 Dec 2015 19:21:28 - @@ -109,6 +109,7 @@ char *header[] = "short *yysslim;", "YYSTYPE *yyvs;", "unsigned int yystacksize;", + "int yyparse(void);", NULL };
Re: eeprom does not compile on current/macppc
> From: "Todd C. Miller" > Date: Thu, 31 Dec 2015 12:01:10 -0700 > > On Thu, 31 Dec 2015 19:53:01 +0100, Mark Kettenis wrote: > > > Fallout from -Werror-implicit-function-declaration. > > > > Diff below fixes it. ok? > > Hmmm, should the yyparse() proto really be static? The actual > yyparse() generated by yacc is not static. Hmm. I think static would be ok here. But I can't find the bits in the C standard that say so. And yyparse() wasn't static before. So I've committed it without the static.
Re: eeprom does not compile on current/macppc
On Thu, 31 Dec 2015 11:02:01 -0800, Philip Guenther wrote: > Wouldn't it better to have yacc's skeleton.c provide a prototype so > that it's fixed for all .y files? I see that bison's output includes > an "int yyparse (void);" prototype, so I would expect minimal ports > issues. That's probably the best approach of all. - todd
Re: eeprom does not compile on current/macppc
On Thu, 31 Dec 2015 19:53:01 +0100, Mark Kettenis wrote: > Fallout from -Werror-implicit-function-declaration. > > Diff below fixes it. ok? Hmmm, should the yyparse() proto really be static? The actual yyparse() generated by yacc is not static. - todd
Re: eeprom does not compile on current/macppc
> Date: Thu, 31 Dec 2015 13:18:13 +0100 > From: Jan Stary > > ===> usr.sbin/eeprom > cc -O2 -pipe -Werror-implicit-function-declaration -c getdate.c > /usr/src/usr.sbin/eeprom/getdate.y: In function 'get_date': > /usr/src/usr.sbin/eeprom/getdate.y:860: error: implicit declaration of > function 'yyparse' Fallout from -Werror-implicit-function-declaration. Diff below fixes it. ok? Index: getdate.y === RCS file: /cvs/src/usr.sbin/eeprom/getdate.y,v retrieving revision 1.9 diff -u -p -r1.9 getdate.y --- getdate.y 3 Dec 2013 01:48:37 - 1.9 +++ getdate.y 31 Dec 2015 18:50:42 - @@ -21,6 +21,8 @@ #include #include +static int yyparse(void); + #define EPOCH 1970 #define HOUR(x)((time_t)(x) * 60) #define SECSPERDAY (24L * 60L * 60L)
Re: eeprom does not compile on current/macppc
On Thu, 31 Dec 2015 19:53:01 +0100, Mark Kettenis wrote: > Fallout from -Werror-implicit-function-declaration. > > Diff below fixes it. ok? OK millert@ - todd
Re: eeprom does not compile on current/macppc
On Thu, Dec 31, 2015 at 10:53 AM, Mark Kettenis wrote: >> Date: Thu, 31 Dec 2015 13:18:13 +0100 >> From: Jan Stary >> >> ===> usr.sbin/eeprom >> cc -O2 -pipe -Werror-implicit-function-declaration -c getdate.c >> /usr/src/usr.sbin/eeprom/getdate.y: In function 'get_date': >> /usr/src/usr.sbin/eeprom/getdate.y:860: error: implicit declaration of >> function 'yyparse' > > Fallout from -Werror-implicit-function-declaration. > > Diff below fixes it. ok? Wouldn't it better to have yacc's skeleton.c provide a prototype so that it's fixed for all .y files? I see that bison's output includes an "int yyparse (void);" prototype, so I would expect minimal ports issues. Philip Guenther
Re: OpenBSD 5.8 on Xeon-D (1540) systems
> Read my message again. I'm suggesting to turn xhci off in the kernel, > not the BIOS. Alright, so here's an update. This Xeon-D system is able to be booted and installed using your suggestions: In BIOS: CPU Configuration -> Cores Enabled -> set to 1 In UKC: disable acpi disable xhci Here's the interesting part: Once installed (with either 5.8 or 5.9-beta) I can re-enable all 8 cores in the BIOS and the machine will continue to boot properly (ie, cpu0 will be boot CPU, not an application CPU as before) So, aside from the understandably unsupported 10Gb NICs on this (the integrated 1Gb NICs don't appear to have problems), there are 3 issues: 1) cpu0 showing up as an application CPU when booting a install image, but not with an installed image and thus requiring CPUs to be reduced to 1 and then bumped back up to 8. 2) acpi needs to be disabled (reasons unknown to me why this needs to happen) 3) xhci driver needs to be looked at to see why it locks up and stops kernel progression on boot Being a relative noob to this area of OpenBSD, I'm willing to try some patches if anyone has the inclination to try some ideas. I think the Xeon-D would be great for OpenBSD-based VPN appliances and such. /dale signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Make em(4) more mpsafe again
On Fri, Jan 01, 2016 at 12:08:53AM +1000, David Gwynne wrote: > [...] > tests? ok? > [...] I'll test it tonight in my hackerspace. There's never a better time for testing network patches than new years eve, since people will be drunk enough to ignore occasional glitches when I restart the router :) -- Gregor
Re: Make em(4) more mpsafe again
On Sat, Dec 05, 2015 at 03:41:24PM +0100, Claudio Jeker wrote: > So Mark and I spent some time to figure out what the issue was with ix(4) > based on that info I resurected the em(4) mpsafe diff that got backed out > and I applied the same fix. It is somewhat unclear if this fixes the > watchdog timeouts since in theory the wdog timer should be stopped when > hitting the race condition we hit in ix(4). > > I'm currently hammering my test system with this and until now I have not > seen a watchdog fired. i built on this diff to try and mark em_start as mpsafe and came up with the following. the start/txeof interaction should be simpler with this so maybe any watchdog issues should be resolved. tests? ok? Index: if_em.c === RCS file: /cvs/src/sys/dev/pci/if_em.c,v retrieving revision 1.313 diff -u -p -r1.313 if_em.c --- if_em.c 25 Nov 2015 03:09:59 - 1.313 +++ if_em.c 29 Dec 2015 10:46:35 - @@ -230,7 +230,7 @@ void em_txeof(struct em_softc *); int em_allocate_receive_structures(struct em_softc *); int em_allocate_transmit_structures(struct em_softc *); int em_rxfill(struct em_softc *); -void em_rxeof(struct em_softc *); +int em_rxeof(struct em_softc *); void em_receive_checksum(struct em_softc *, struct em_rx_desc *, struct mbuf *); void em_transmit_checksum_setup(struct em_softc *, struct mbuf *, @@ -588,15 +588,14 @@ err_pci: void em_start(struct ifnet *ifp) { - struct mbuf*m_head; struct em_softc *sc = ifp->if_softc; - int post = 0; - - if (!(ifp->if_flags & IFF_RUNNING) || ifq_is_oactive(&ifp->if_snd)) - return; + struct mbuf *m; + int post = 0; - if (!sc->link_active) + if (!sc->link_active) { + IFQ_PURGE(&ifp->if_snd); return; + } if (sc->hw.mac_type != em_82547) { bus_dmamap_sync(sc->txdma.dma_tag, sc->txdma.dma_map, 0, @@ -605,22 +604,24 @@ em_start(struct ifnet *ifp) } for (;;) { - m_head = ifq_deq_begin(&ifp->if_snd); - if (m_head == NULL) - break; - - if (em_encap(sc, m_head)) { - ifq_deq_rollback(&ifp->if_snd, m_head); + if (EM_MAX_SCATTER + 1 > sc->num_tx_desc_avail) { ifq_set_oactive(&ifp->if_snd); break; } - ifq_deq_commit(&ifp->if_snd, m_head); + m = ifq_dequeue(&ifp->if_snd); + if (m == NULL) + break; + + if (em_encap(sc, m) != 0) { + /* ifp->if_oerrors++; */ + continue; + } #if NBPFILTER > 0 /* Send a copy of the frame to the BPF listener */ if (ifp->if_bpf) - bpf_mtap_ether(ifp->if_bpf, m_head, BPF_DIRECTION_OUT); + bpf_mtap_ether(ifp->if_bpf, m, BPF_DIRECTION_OUT); #endif /* Set timeout in case hardware has problems transmitting */ @@ -901,7 +902,6 @@ em_intr(void *arg) struct em_softc *sc = arg; struct ifnet*ifp = &sc->interface_data.ac_if; u_int32_t reg_icr, test_icr; - int refill = 0; test_icr = reg_icr = E1000_READ_REG(&sc->hw, ICR); if (sc->hw.mac_type >= em_82571) @@ -910,31 +910,23 @@ em_intr(void *arg) return (0); if (ifp->if_flags & IFF_RUNNING) { - em_rxeof(sc); em_txeof(sc); - refill = 1; - } - - if (reg_icr & E1000_ICR_RXO) - sc->rx_overruns++; - KERNEL_LOCK(); + if (em_rxeof(sc) || ISSET(reg_icr, E1000_ICR_RXO)) { + if (em_rxfill(sc)) { + E1000_WRITE_REG(&sc->hw, RDT, + sc->last_rx_desc_filled); + } + } + } /* Link status change */ if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { + KERNEL_LOCK(); sc->hw.get_link_status = 1; em_check_for_link(&sc->hw); em_update_link_status(sc); - } - - if (ifp->if_flags & IFF_RUNNING && !IFQ_IS_EMPTY(&ifp->if_snd)) - em_start(ifp); - - KERNEL_UNLOCK(); - - if (refill && em_rxfill(sc)) { - /* Advance the Rx Queue #0 "Tail Pointer". */ - E1000_WRITE_REG(&sc->hw, RDT, sc->last_rx_desc_filled); + KERNEL_UNLOCK(); } return (1); @@ -1096,7 +1088,7 @@ int em_encap(struct em_softc *sc, struct mbuf *m_head) { u_int32_t txd_upper; - u_int32_t txd_lower, txd_used = 0, txd_saved = 0; + u_int32_t txd_lower, txd_used = 0; int i, j, fir
Re: Support for the "ste" device driver on amd64
Thank you for a clear explanation. I agree that the device is old and if the current driver needs to be rewritten, it is better to focus on more important tasks. Best wishes for the New Year! Andrzej On Wed, Dec 30, 2015 at 05:11:37PM -0700, Theo de Raadt wrote: > The driver must be rewritten to use bus_dma(9). > > It will not be re-enabled as-is, since many architectures will never > have vtophys. In particular, amd64. > > "testing" won't help. Nor is there any other information needed. The > problem is obvious. To a kernel developer, the commit message speaks > far enough to the issue. > > If you don't have the skill to do it, well that's too bad... there > also appears to be a lack of people who want to rewrite the driver. > It is a very old and rare chip. There are far more important issues > than supporting such ancient devices. > > So you are better off getting some other device. > > >I got access to a D-Link DFE-580TX PCI network device (Sundance Technologies > >ST201 10/100 Ethernet device) recently and decided to do some preliminary > >experiments on amd64 involving the corresponding driver on OpenBSD. I will > >be using this device for about a week for research purposes. > > > >The driver seems to have been temporarily disabled in the default kernel > >configuration (GENERIC, rev 1.70) on amd64, while it remains enabled on > >i386. The respective commit description was: "remove support for sf and ste. > > vtophys is NOT a working solution. Do not re-enable these drivers until > >they are bus-dma'ified.". > > > >Currently, the following warning/error appears on amd64 after activating the > >driver: > > > >cc1: warnings being treated as errors > >../../../../dev/pci/if_ste.c: In function 'ste_newbuf': > >../../../../dev/pci/if_ste.c:963: warning: implicit declaration of function > >'vtophys' > >*** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:938 > >'if_ste.o') > > > >I have verified (and thus can confirm) that the ste* driver in FreeBSD 10.2 > >RELEASE works on amd64. Apparently it does not use vtophys anymore though. > > > >I wonder if I could help with testing, or deliver specific information that > >might be necessary to improve the corresponding driver in OpenBSD (amd64)? > > > >Best wishes, > >Andrzej > > > >
eeprom does not compile on current/macppc
Rebuilding the userland on a current/maccppc MacMini filas with ===> usr.sbin/eeprom cc -O2 -pipe -Werror-implicit-function-declaration -c getdate.c /usr/src/usr.sbin/eeprom/getdate.y: In function 'get_date': /usr/src/usr.sbin/eeprom/getdate.y:860: error: implicit declaration of function 'yyparse' Jan [ using 560212 bytes of bsd ELF symbol table ] console out [NVDA,Display-A] console in [keyboard], using USB using parent NVDA,Parent:: memaddr 9800, size 800 : consaddr 98004000 : ioaddr 9100, size 100: width 1280 linebytes 1536 height 960 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.9-beta (GENERIC) #0: Wed Dec 30 22:14:37 CET 2015 r...@emac.stare.cz:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 1073741824 (1024MB) avail mem = 1029025792 (981MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: model PowerMac4,4 cpu0 at mainbus0: 7450 (Revision 0x201): 700 MHz: 256KB L2 cache mem0 at mainbus0 spdmem0 at mem0: 512MB SDRAM non-parity PC133CL2 spdmem1 at mem0: 512MB SDRAM non-parity PC133CL3 memc0 at mainbus0: uni-n rev 0x11 kiic0 at memc0 offset 0xf8001000 iic0 at kiic0 mpcpcibr0 at mainbus0 pci: uni-north pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple Uni-N2 AGP" rev 0x00 agp at pchb0 not configured vgafb0 at pci0 dev 16 function 0 "NVIDIA GeForce2 MX" rev 0xb2 wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) mpcpcibr1 at mainbus0 pci: uni-north pci1 at mpcpcibr1 bus 0 macobio0 at pci1 dev 23 function 0 "Apple Keylargo" rev 0x03 openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE macgpio0 at macobio0 offset 0x50 macgpio1 at macgpio0 offset 0x59: irq 47 pgs0 at macgpio0 offset 0x61: irq 55 "fan" at macgpio0 offset 0x0 not configured "gpio7" at macgpio0 offset 0x71 not configured "gpio5" at macgpio0 offset 0x6f not configured "extint-gpio15" at macgpio0 offset 0x67 not configured "extint-gpio4" at macgpio0 offset 0x5c not configured "gpio6" at macgpio0 offset 0x70 not configured "gpio11" at macgpio0 offset 0x75 not configured "escc-legacy" at macobio0 offset 0x12000 not configured zs0 at macobio0 offset 0x13000: irq 22,23 zstty0 at zs0 channel 0 zstty1 at zs0 channel 1 snapper0 at macobio0 offset 0x1: irq 30,1,2 "timer" at macobio0 offset 0x15000 not configured adb0 at macobio0 offset 0x16000 apm0 at adb0: battery flags 0x9, 0% charged piic0 at adb0 iic1 at piic0 "imic5002" at iic1 addr 0xe8 not configured "imic5003" at iic1 addr 0xea not configured "ivad-2" at iic1 addr 0x146 not configured "ivad-eeprom" at iic1 addr 0x153 not configured "ivad-pwm" at iic1 addr 0x14c not configured kiic1 at macobio0 offset 0x18000 iic2 at kiic1 wdc0 at macobio0 offset 0x1f000 irq 19: DMA wd0 at wdc0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 39073MB, 80022600 sectors wd0(wdc0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4 wdc1 at macobio0 offset 0x2 irq 20: DMA atapiscsi0 at wdc1 channel 0 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable cd0(wdc1:0:0): using BIOS timings, DMA mode 2 wdc2 at macobio0 offset 0x21000 irq 21: DMA audio0 at snapper0 ohci0 at pci1 dev 24 function 0 "Apple USB" rev 0x00: irq 27, version 1.0 ohci1 at pci1 dev 25 function 0 "Apple USB" rev 0x00: irq 28, version 1.0 usb0 at ohci0: USB revision 1.0 uhub0 at usb0 "Apple OHCI root hub" rev 1.00/1.00 addr 1 usb1 at ohci1: USB revision 1.0 uhub1 at usb1 "Apple OHCI root hub" rev 1.00/1.00 addr 1 mpcpcibr2 at mainbus0 pci: uni-north pci2 at mpcpcibr2 bus 0 "AT&T/Lucent FW322 1394" rev 0x00 at pci2 dev 14 function 0 not configured gem0 at pci2 dev 15 function 0 "Apple Uni-N GMAC" rev 0x01: irq 41, address 00:03:93:c1:1b:d6 bmtphy0 at gem0 phy 0: BCM5221 100baseTX PHY, rev. 4 uhidev0 at uhub0 port 2 configuration 1 interface 0 "Logitech USB-PS/2 Optical Mouse" rev 2.00/11.10 addr 2 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 uhub2 at uhub1 port 1 "Mitsumi Electric Hub in Apple Extended USB Keyboard" rev 1.10/4.10 addr 2 uhidev1 at uhub2 port 3 configuration 1 interface 0 "Mitsumi Electric Apple Extended USB Keyboard" rev 1.10/4.10 addr 3 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 variable keys, 6 key codes, country code 13 wskbd0 at ukbd0: console keyboard, using wsdisplay0 uhidev2 at uhub2 port 3 configuration 1 interface 1 "Mitsumi Electric Apple Extended USB Keyboard" rev 1.10/4.10 addr 3 uhidev2: iclass 3/0, 3 report ids uhid0 at uhidev2 reportid 2: input=1, output=0, feature=0 uhid1 at uhidev2 reportid 3: input=3, output=0, feature=0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets bootpath: /pci@f200/mac-io@17/ata-4@1f000/disk@0:/bsd root on wd0a (c8e76da06027160f.a) swap on wd0b dump o