eeprom does not compile on current/macppc

[Jan Stary]

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/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 

Re: Support for the "ste" device driver on amd64

[na...@poczta.fm]

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
> >
> >

Re: Make em(4) more mpsafe again

[David Gwynne]

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(>if_snd))
-   return;
+   struct mbuf *m;
+   int post = 0;
 
-   if (!sc->link_active)
+   if (!sc->link_active) {
+   IFQ_PURGE(>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(>if_snd);
-   if (m_head == NULL)
-   break;
-
-   if (em_encap(sc, m_head)) {
-   ifq_deq_rollback(>if_snd, m_head);
+   if (EM_MAX_SCATTER + 1 > sc->num_tx_desc_avail) {
ifq_set_oactive(>if_snd);
break;
}
 
-   ifq_deq_commit(>if_snd, m_head);
+   m = ifq_dequeue(>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 = >interface_data.ac_if;
u_int32_t   reg_icr, test_icr;
-   int refill = 0;
 
test_icr = reg_icr = E1000_READ_REG(>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(>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(>hw);
em_update_link_status(sc);
-   }
-
-   if (ifp->if_flags & IFF_RUNNING && !IFQ_IS_EMPTY(>if_snd))
-   em_start(ifp);
-
-   KERNEL_UNLOCK();
-
-   if (refill && em_rxfill(sc)) {
-   /* Advance the Rx Queue #0 "Tail Pointer". */
-   E1000_WRITE_REG(>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, first, error = 0, last = 0;
bus_dmamap_tmap;
 
@@ 

Re: OpenBSD 5.8 on Xeon-D (1540) systems

[Dale Ghent]

> 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: eeprom does not compile on current/macppc

[Mark Kettenis]

> 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

[Philip Guenther]

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: Make em(4) more mpsafe again

[Gregor Best]

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: eeprom does not compile on current/macppc

[Todd C. Miller]

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: OpenBSD 5.8 on Xeon-D (1540) systems

[Mark Kettenis]

> 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

[Mark Kettenis]

> 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

[Todd C. Miller]

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

[Mark Kettenis]

> 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

[Todd C. Miller]

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

[Philip Guenther]

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

[Dale Ghent]

> 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

Clarify vmctl(8) console

[Michal Mazurek]

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: Get PCI resources from ACPI

[Philip Guenther]

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

integer truncation in soreceive()

[Martin Natano]

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.

uvm_io: uiomovei -> uiomove

[David Hill]

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: eeprom does not compile on current/macppc

[Todd C. Miller]

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

mention /etc/doas.conf instead of plain doas.conf

[Amit Kulkarni]

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:

patch sys/kern/kern_xxx.c for SYSCALL_DEBUG

[Josh Grosse]

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");
 }

A cleanup block for virtio.c vionet_notifyq()

[Michal Mazurek]

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 = [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);
-