Re: Race condition in vmd(8) resulting in "freezing"
On Mon, Mar 04, 2019 at 01:25:16PM +0200, Wictor Lund wrote:
> Hi misc@!
>
> I have figured out that it is possible to get vmd(8) into a state where
> 1) com1_dev.rcv_pending != 0
> 2) there is data pending on com1_dev.fd
> 3) the guest doesn't seem to care
>
> This results in a locked up situation where com_rcv_event() is called on
> indefinitely. It seems to me that an interrupt is lost somewhere, leading
> to a situation where the guest OS is happily ignorant of the available data,
> while the vmm is waiting for the guest to eat it up.
>
> This has made it impossible to install Linux via the serial console on
> vmm(4). It seems that people previously have reported "freezing" problems
> in vmm(4) form time to time, but when reported no one else have been able to
> reproduce it.
>
> I have solved the problem for myself by changing com_rcv_event() to the
> following:
>
> static void
> com_rcv_event(int fd, short kind, void *arg)
> {
> mutex_lock(&com1_dev.mutex);
>
> /*
> * We already have other data pending to be received. The data that
> * has become available now will be moved to the com port later.
> */
> if (com1_dev.rcv_pending) {
> /* If pending interrupt, inject */
> if ((com1_dev.regs.iir & IIR_NOPEND) == 0) {
> utrace("comrcv injintr", &com1_dev.regs.lsr,
> sizeof(com1_dev.regs.lsr));
> /* XXX: vcpu_id */
> vcpu_assert_pic_irq((uintptr_t) arg, 0, com1_dev.irq);
> vcpu_deassert_pic_irq((uintptr_t) arg, 0,
> com1_dev.irq);
> }
> mutex_unlock(&com1_dev.mutex);
> return;
> }
> if (com1_dev.regs.lsr & LSR_RXRDY)
> com1_dev.rcv_pending = 1;
> else {
> com_rcv(&com1_dev, (uintptr_t) arg, 0);
>
> /* If pending interrupt, inject */
> if ((com1_dev.regs.iir & IIR_NOPEND) == 0) {
> /* XXX: vcpu_id */
> vcpu_assert_pic_irq((uintptr_t) arg, 0, com1_dev.irq);
> vcpu_deassert_pic_irq((uintptr_t) arg, 0,
> com1_dev.irq);
> }
> }
>
> mutex_unlock(&com1_dev.mutex);
> }
>
> However, I have little experience in the interrupt behaviour on x86. I'm
> also aware of that there has been an attempt to fix this behaviour [1].
>
> I think the problem is that when com_rcv() is called from
> vcpu_process_com_data(), the interrupt is triggered using vcpu_exit_inout(),
> which was not touched in the previous attempt [1] to fix the "freezing"
> problem. vcpu_exit_inout() still uses a simple vcpu_assert_pic_irq() call
> to trigger the interrupt while for example com_rcv_event() uses the
> vcpu_assert_pic_irq(); vcpu_deassert_pic_irq() sequence to trigger it.
>
> With my modifications to com_rcv_event() I was able to install not only
> alpine linux, but even debian using the serial console. Without the
> modification I can't even install alpine linux via the serial console.
>
> Any thoughts on this? If people think my change is a sound one, I can make
> a proper patch for it. If people think the change is unsound, I would have
> to look into changing vcpu_exit_inout() and probably extend the interface to
> it to decide how the interrupt should be triggered.
>
> 1. https://marc.info/?l=openbsd-cvs&m=153115270302514&w=2
>
> --
> Wictor Lund
>
Thanks Wictor!
Can you make a proper diff and resend please?
-ml
Re: man httpd.conf option does not mention option blocks
On Mon, Mar 04, 2019 at 03:46:25PM -0600, Alfred Morgan wrote:
> jmc wrote:
> > i think if you attached a diff to your mail, no matter how poorly
> > written, you would have a better chance of something happening.
>
> How does this sound?
> A specified option may be written inside curly brackets in order to specify
> a block of one or more specified options.
> (diff included below)
>
morning.
thanks for following this up with a diff!
regarding your sentence - it's confusing. this is a tough one to write,
i think. from everything following that sentence to the end of that
section, can everything take this {} notation?
alias { x y z }
that is valid? or it's just command words that take lists of options,
like
tls {
cert x
ciphers y
}
the sentence doesn;t make this clear. i can't offer an improvement
without understand where it's valid. can you supply more detail (not in
a diff, just describe it).
> > where can {} be used? just here or other places? is there a general rule?
>
> Yes, I tested several specified options and this appears to be a general
> rule. One thing I noticed, which made me include "one or more" in my
> documentation, is an optional specified option will not accept an empty
> curly brackets `{ }` such as the option `hsts [option]` won't allow to be
> written as `hsts { }`.
>
so it applies just to commands which have an argument "option"?
> > what https examples would improve the page?
>
> I believe a tls option with a multiple specified options block containing
> paths to acme-client default key and cert paths example would be great. And
> how about using named ports even.
>
fair enough. i'll try and get some feedback on this/
jmc
> Index: httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.103
> diff -u -p -r1.103 httpd.conf.5
> --- httpd.conf.519 Feb 2019 11:37:26 - 1.103
> +++ httpd.conf.54 Mar 2019 21:33:27 -
> @@ -155,7 +155,9 @@ see
> .Xr patterns 7 .
> .El
> .Pp
> -Followed by a block of options that is enclosed in curly brackets:
> +Followed by a block of options that is enclosed in curly brackets.
> +A specified option may be written inside curly brackets in order to specify
> +a block of one or more specified options:
> .Bl -tag -width Ds
> .It Ic alias Ar name
> Specify an additional alias
> @@ -714,9 +716,13 @@ the server will be matched based on the
> .Bd -literal -offset indent
> server "www.example.com" {
> alias "example.com"
> - listen on * port 80
> - listen on * tls port 443
> + listen on * port http
> + listen on * tls port https
> root "/htdocs/www.example.com"
> +tls {
> +key "/etc/ssl/private/example.com.key"
> +certificate "/etc/ssl/example.com.fullchain.pem"
> +}
> }
>
> server "www.a.example.com" {
>
> --
> -alfred
Re: Live ACPI "Hibernate" Style Snapshot possible without Powering Down?
On Mon, Mar 04, 2019 at 06:44:15PM -0700, Theo de Raadt wrote: > Z Ero wrote: > > > Hello, > > > > Curious if there is a facility to save system memory state to disk for > > recovery such as is done the ZZZ (hibernate) command without actually > > powering down? Could be useful to return to a previous active memory > > state for devices that are not on UPS or not closely monitored but do > > preform non-scripted batch work. > > > > So, for example if there is a transient power interruption on > > 03-05-2019 at 12 AM the device could be configured just to reboot to > > the state it was in at 03-04-2019 at 12 AM where it was doing similar > > work. I don't mean load a file back up but reload a previous active > > memory / process state as if returning from hibernate. > > > > Thus to enable this hibernate style dumps would be saved periodically > > by cron for example. > > > > I understand that for some dumping active memory to disk without > > powering down might present a security concern but this is not a > > problem for my application. > > What you are asking for is impossible to do correctly, because files > will be open. As a result, the filesystem image you return to will be > incoherent with respect to the open vnodes. > > I mean, it can be done. It just will have so many artificial deficits > at the low-level that it won't suit the high-level purpose you intend > fully. > If one really wanted to do this, the right approach would be to start with filesystem and memory snapshots in vmm/vmd. I think the former can be done with enhancing qcow2, and the latter is basically already done (via vmctl send). I await OP's diff to implement this. -ml
Re: Live ACPI "Hibernate" Style Snapshot possible without Powering Down?
Z Ero wrote: > Hello, > > Curious if there is a facility to save system memory state to disk for > recovery such as is done the ZZZ (hibernate) command without actually > powering down? Could be useful to return to a previous active memory > state for devices that are not on UPS or not closely monitored but do > preform non-scripted batch work. > > So, for example if there is a transient power interruption on > 03-05-2019 at 12 AM the device could be configured just to reboot to > the state it was in at 03-04-2019 at 12 AM where it was doing similar > work. I don't mean load a file back up but reload a previous active > memory / process state as if returning from hibernate. > > Thus to enable this hibernate style dumps would be saved periodically > by cron for example. > > I understand that for some dumping active memory to disk without > powering down might present a security concern but this is not a > problem for my application. What you are asking for is impossible to do correctly, because files will be open. As a result, the filesystem image you return to will be incoherent with respect to the open vnodes. I mean, it can be done. It just will have so many artificial deficits at the low-level that it won't suit the high-level purpose you intend fully.
Re: Live ACPI "Hibernate" Style Snapshot possible without Powering Down?
On Mon, Mar 04, 2019 at 07:06:15PM -0500, Z Ero wrote: > Hello, > > Curious if there is a facility to save system memory state to disk for > recovery such as is done the ZZZ (hibernate) command without actually > powering down? Could be useful to return to a previous active memory > state for devices that are not on UPS or not closely monitored but do > preform non-scripted batch work. > > So, for example if there is a transient power interruption on > 03-05-2019 at 12 AM the device could be configured just to reboot to > the state it was in at 03-04-2019 at 12 AM where it was doing similar > work. I don't mean load a file back up but reload a previous active > memory / process state as if returning from hibernate. > > Thus to enable this hibernate style dumps would be saved periodically > by cron for example. > > I understand that for some dumping active memory to disk without > powering down might present a security concern but this is not a > problem for my application. > > Thanks > We don't do this.
Live ACPI "Hibernate" Style Snapshot possible without Powering Down?
Hello, Curious if there is a facility to save system memory state to disk for recovery such as is done the ZZZ (hibernate) command without actually powering down? Could be useful to return to a previous active memory state for devices that are not on UPS or not closely monitored but do preform non-scripted batch work. So, for example if there is a transient power interruption on 03-05-2019 at 12 AM the device could be configured just to reboot to the state it was in at 03-04-2019 at 12 AM where it was doing similar work. I don't mean load a file back up but reload a previous active memory / process state as if returning from hibernate. Thus to enable this hibernate style dumps would be saved periodically by cron for example. I understand that for some dumping active memory to disk without powering down might present a security concern but this is not a problem for my application. Thanks
Re: dhcrelay multiple instances possible bug
Hi Riccardo,
dhrelay only operates on a single interface, so you're not missing anything
there.
Can you show me the ps output for the dhcrelay processes you start? The rcctl
commands you show below don't include the rcctl start dhcrelay and
dhcrelay_second bits.
I have the following in rc.local (mostly because this config predates rcctl):
foo=192.0.2.194
bar=192.0.2.196
echo -n 'start dhcp relays:'
for i in vlan371 vlan373 \
vlan835 \
vlan801 vlan847 vlan866 vlan867 \
vlan811 vlan815 vlan816 \
vlan1101 vlan1147 vlan1165 vlan1166 \
vlan1201 vlan1231 vlan1247 vlan1265 vlan1266 \
vlan1301 vlan1331 vlan1347 vlan1365 vlan1366 \
vlan971 vlan966 \
vlan1401 vlan1465 vlan1466 vlan1467 \
vlan1501 vlan1565 vlan1566 \
vlan1601 vlan1647 vlan1665 vlan1666 vlan1667 \
vlan1701 vlan1747 vlan1765 vlan1766 \
vlan1801 vlan1865 vlan1866 \
vlan1901 vlan1965 vlan1966 \
vlan2001 vlan2065 vlan2066 vlan2067 \
vlan2008 vlan2068 \
vlan2506 vlan2533 vlan2536 vlan2531 vlan2537 vlan2547; do
/usr/sbin/dhcrelay -i ${i} $foo $bar
echo -n " ${i}"
done
echo '.'
Which produces:
xdlg@shotgun1 pf$ ps -aux | grep dhc
_dhcp40965 0.0 0.0 532 1008 ?? Ssp 10Nov17 12:06.67
/usr/sbin/dhcrelay -i vlan371 192.0.2.194 192.0.2.196
_dhcp16825 0.0 0.0 536 1012 ?? Ssp 10Nov172:08.80
/usr/sbin/dhcrelay -i vlan867 192.0.2.194 192.0.2.196
_dhcp69672 0.0 0.0 532 1076 ?? Isp 10Nov170:46.06
/usr/sbin/dhcrelay -i vlan866 192.0.2.194 192.0.2.196
_dhcp48117 0.0 0.0 536 972 ?? Isp 10Nov170:00.02
/usr/sbin/dhcrelay -i vlan373 192.0.2.194 192.0.2.196
_dhcp43065 0.0 0.0 540 1068 ?? Isp 10Nov170:06.02
/usr/sbin/dhcrelay -i vlan835 192.0.2.194 192.0.2.196
_dhcp77793 0.0 0.0 540 988 ?? Ssp 10Nov17 19:26.92
/usr/sbin/dhcrelay -i vlan801 192.0.2.194 192.0.2.196
_dhcp68793 0.0 0.0 540 1028 ?? Isp 10Nov170:08.40
/usr/sbin/dhcrelay -i vlan847 192.0.2.194 192.0.2.196
_dhcp12879 0.0 0.0 540 1016 ?? Isp 10Nov171:14.46
/usr/sbin/dhcrelay -i vlan1101 192.0.2.194 192.0.2.196
_dhcp10430 0.0 0.0 544 1052 ?? Ssp 10Nov171:42.55
/usr/sbin/dhcrelay -i vlan811 192.0.2.194 192.0.2.196
_dhcp87753 0.0 0.0 544 1016 ?? Isp 10Nov170:31.65
/usr/sbin/dhcrelay -i vlan815 192.0.2.194 192.0.2.196
_dhcp21434 0.0 0.0 536 1024 ?? Isp 10Nov170:00.20
/usr/sbin/dhcrelay -i vlan816 192.0.2.194 192.0.2.196
_dhcp17816 0.0 0.0 540 1020 ?? Isp 10Nov170:00.00
/usr/sbin/dhcrelay -i vlan1147 192.0.2.194 192.0.2.196
_dhcp67338 0.0 0.0 540 1020 ?? Isp 10Nov170:00.11
/usr/sbin/dhcrelay -i vlan1247 192.0.2.194 192.0.2.196
_dhcp73549 0.0 0.0 540 1020 ?? Isp 10Nov170:00.55
/usr/sbin/dhcrelay -i vlan1165 192.0.2.194 192.0.2.196
_dhcp78748 0.0 0.0 540 1012 ?? Isp 10Nov170:02.33
/usr/sbin/dhcrelay -i vlan1166 192.0.2.194 192.0.2.196
_dhcp82689 0.0 0.0 540 1008 ?? Isp 10Nov172:02.18
/usr/sbin/dhcrelay -i vlan1201 192.0.2.194 192.0.2.196
_dhcp31199 0.0 0.0 540 996 ?? Isp 10Nov170:07.63
/usr/sbin/dhcrelay -i vlan1231 192.0.2.194 192.0.2.196
_dhcp21332 0.0 0.0 532 1004 ?? Isp 10Nov171:24.02
/usr/sbin/dhcrelay -i vlan1265 192.0.2.194 192.0.2.196
_dhcp35688 0.0 0.0 544 1040 ?? Isp 10Nov170:00.28
/usr/sbin/dhcrelay -i vlan1347 192.0.2.194 192.0.2.196
_dhcp36741 0.0 0.0 540 1032 ?? Isp 10Nov170:07.17
/usr/sbin/dhcrelay -i vlan1266 192.0.2.194 192.0.2.196
_dhcp90274 0.0 0.0 544 1024 ?? Isp 10Nov17 19:17.78
/usr/sbin/dhcrelay -i vlan1301 192.0.2.194 192.0.2.196
_dhcp42199 0.0 0.0 548 1052 ?? Isp 10Nov170:00.17
/usr/sbin/dhcrelay -i vlan1331 192.0.2.194 192.0.2.196
_dhcp83979 0.0 0.0 528 1000 ?? Ssp 10Nov172:09.78
/usr/sbin/dhcrelay -i vlan1365 192.0.2.194 192.0.2.196
_dhcp52142 0.0 0.0 536 792 ?? Isp 10Nov170:00.00
/usr/sbin/dhcrelay -i vlan965 192.0.2.194 192.0.2.196
_dhcp17747 0.0 0.0 540 996 ?? Isp 10Nov170:05.03
/usr/sbin/dhcrelay -i vlan1366 192.0.2.194 192.0.2.196
_dhcp85673 0.0 0.0 536 988 ?? Isp 10Nov170:11.59
/usr/sbin/dhcrelay -i vlan947 192.0.2.194 192.0.2.196
_dhcp 266 0.0 0.0 536 964 ?? Isp 10Nov170:01.84
/usr/sbin/dhcrelay -i vlan966 192.0.2.194 192.0.2.196
_dhcp59857 0.0 0.0 540 984 ?? Isp 10Nov174:26.67
/usr/sbin/dhcrelay -i vlan1401 192.0.2.194 192.0.2.196
_dhcp17159 0.0 0.0 536 1012 ?? Ssp 10Nov171:27.85
/usr/sbin/dhcrelay -i vlan971 192.0.2.194 192.0.2.196
_dhcp67613 0.0 0.0 540 1028 ?? Isp 10Nov172:29.27
/usr/sbin/dhcrelay -i vlan1465 192.0.2.194 192.0.2.196
_dhcp33040 0.0 0.0 536 840 ?? Isp 10Nov170:00.00
/usr/sbin/dhcrelay -i vlan1565 192.0.2.194 192.0.2.196
_dhcp 4850 0.0 0.0 544 844 ?? Isp
Re: man httpd.conf option does not mention option blocks
jmc wrote:
> i think if you attached a diff to your mail, no matter how poorly
> written, you would have a better chance of something happening.
How does this sound?
A specified option may be written inside curly brackets in order to specify
a block of one or more specified options.
(diff included below)
> where can {} be used? just here or other places? is there a general rule?
Yes, I tested several specified options and this appears to be a general
rule. One thing I noticed, which made me include "one or more" in my
documentation, is an optional specified option will not accept an empty
curly brackets `{ }` such as the option `hsts [option]` won't allow to be
written as `hsts { }`.
> what https examples would improve the page?
I believe a tls option with a multiple specified options block containing
paths to acme-client default key and cert paths example would be great. And
how about using named ports even.
Index: httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.103
diff -u -p -r1.103 httpd.conf.5
--- httpd.conf.519 Feb 2019 11:37:26 - 1.103
+++ httpd.conf.54 Mar 2019 21:33:27 -
@@ -155,7 +155,9 @@ see
.Xr patterns 7 .
.El
.Pp
-Followed by a block of options that is enclosed in curly brackets:
+Followed by a block of options that is enclosed in curly brackets.
+A specified option may be written inside curly brackets in order to specify
+a block of one or more specified options:
.Bl -tag -width Ds
.It Ic alias Ar name
Specify an additional alias
@@ -714,9 +716,13 @@ the server will be matched based on the
.Bd -literal -offset indent
server "www.example.com" {
alias "example.com"
- listen on * port 80
- listen on * tls port 443
+ listen on * port http
+ listen on * tls port https
root "/htdocs/www.example.com"
+tls {
+key "/etc/ssl/private/example.com.key"
+certificate "/etc/ssl/example.com.fullchain.pem"
+}
}
server "www.a.example.com" {
--
-alfred
Intel Pro 1000MT Dual Port nic. Need eeprom dump from working card via ethtool. It ff ff ff...d out it's EEPROM, but I got one port working after a day... but not the second.
does anyone have a intel Pro 1000MT Dual port gigabit card they could give an eeprom dump of (via ethtool -e eth1 ), I now have one port working but the other is not, the eeprom someone posted seems to be only for the 1st port I need help with an intel dual port gigabit nic. It' zeroed out it's eprom (well... 1'd it out) and thus I had to reload the eeprom the dump someone posted seems to be only for the single port card tho, and the 2nd port is inactive (it worked yesterday before the self-bricking) (That has been hugely helpful however) The magic number for the intel PRO 1000MT is: 0x10798086 The offset file worked for one port, but not the other. [code] Offset Values -- -- 0x 00 04 23 cb 27 cc 10 02 ff ff ff ff ff ff ff ff 0x0010 84 a7 07 08 0a 66 2e 00 86 80 00 61 4e 00 20 b2 0x0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0040 cf 00 61 78 0b 28 00 00 c8 04 ff ff ff ff ff ff 0x0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06 0x0060 2c 01 00 40 1f 12 ff ff ff ff ff ff ff ff ff ff 0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff fe 24 31 [/code] These commands got 1 port of the intel Pro 1000MT Dual Port working: [code] ethtool -E eth1 magic 0x10798086 offset 0x0 value 0x00 ethtool -E eth1 magic 0x10798086 offset 0x1 value 0x04 ethtool -E eth1 magic 0x10798086 offset 0x2 value 0x23 ethtool -E eth1 magic 0x10798086 offset 0x3 value 0xcb ethtool -E eth1 magic 0x10798086 offset 0x4 value 0x27 ethtool -E eth1 magic 0x10798086 offset 0x5 value 0xcc ethtool -E eth1 magic 0x10798086 offset 0x6 value 0x10 ethtool -E eth1 magic 0x10798086 offset 0x7 value 0x02 ethtool -E eth1 magic 0x10798086 offset 0x8 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x9 value 0xff ethtool -E eth1 magic 0x10798086 offset 0xa value 0xff ethtool -E eth1 magic 0x10798086 offset 0xb value 0xff ethtool -E eth1 magic 0x10798086 offset 0xc value 0xff ethtool -E eth1 magic 0x10798086 offset 0xd value 0xff ethtool -E eth1 magic 0x10798086 offset 0xe value 0xff ethtool -E eth1 magic 0x10798086 offset 0xf value 0xff ethtool -E eth1 magic 0x10798086 offset 0x10 value 0x84 ethtool -E eth1 magic 0x10798086 offset 0x11 value 0xa7 ethtool -E eth1 magic 0x10798086 offset 0x12 value 0x07 ethtool -E eth1 magic 0x10798086 offset 0x13 value 0x08 ethtool -E eth1 magic 0x10798086 offset 0x14 value 0x0a ethtool -E eth1 magic 0x10798086 offset 0x15 value 0x66 ethtool -E eth1 magic 0x10798086 offset 0x16 value 0x2e ethtool -E eth1 magic 0x10798086 offset 0x17 value 0x00 ethtool -E eth1 magic 0x10798086 offset 0x18 value 0x86 ethtool -E eth1 magic 0x10798086 offset 0x19 value 0x80 ethtool -E eth1 magic 0x10798086 offset 0x1a value 0x00 ethtool -E eth1 magic 0x10798086 offset 0x1b value 0x61 ethtool -E eth1 magic 0x10798086 offset 0x1c value 0x4e ethtool -E eth1 magic 0x10798086 offset 0x1d value 0x00 ethtool -E eth1 magic 0x10798086 offset 0x1e value 0x20 ethtool -E eth1 magic 0x10798086 offset 0x1f value 0xb2 ethtool -E eth1 magic 0x10798086 offset 0x20 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x21 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x22 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x23 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x24 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x25 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x26 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x27 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x28 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x29 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x2a value 0xff ethtool -E eth1 magic 0x10798086 offset 0x2b value 0xff ethtool -E eth1 magic 0x10798086 offset 0x2c value 0xff ethtool -E eth1 magic 0x10798086 offset 0x2d value 0xff ethtool -E eth1 magic 0x10798086 offset 0x2e value 0xff ethtool -E eth1 magic 0x10798086 offset 0x2f value 0xff ethtool -E eth1 magic 0x10798086 offset 0x30 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x31 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x32 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x33 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x34 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x35 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x36 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x37 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x38 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x39 value 0xff ethtool -E eth1 magic 0x10798086 offset 0x3a value 0xff ethtool -E eth1 magic 0x10798086 offset 0x3b value 0xff ethtool -E eth1 magic 0x10798086 offset 0x3c value 0xff ethtool -E eth1 magic 0x10798086 offset 0x3d value 0xff ethtool -E eth1 magic 0x10798086 offset 0x3e value 0xff ethtool -E eth1 magic 0x10798086 offset 0x3f value 0xff ethtool -E eth1 magic 0x10798086 offset 0x40 value 0xcf ethtool -E eth1 magic 0x10798086 offset 0x41 valu
dhcrelay multiple instances possible bug
Hi there, many years that i don't use this ml. I'm Riccardo writing from Spain, nice to meet you guys. First of all, many compliments for the exceptional hard work that you've done in the OpenBSD development. Just, thank you. Next a possible bug: In the OpenBSD dhcrelay(8) implementation i cannot find an option to specify different interfaces in a single daemon instance, try to image a router with multiple vlans and a dhcpd server in other machine in an internal service dedicated routed ip network segment. The first instance is executed by the command: rcctl enable dhcrelay rcctl set dhcrelay flags "-i vlanxxx DST_ADDR" The second one i've done this workaround: cd /etc/rc.d cp -p dhcrelay dhcrelay_second rcctl enable dhcrelay_second rcctl set dhcrelay_second flags "-i vlanyyy DST_ADDR" Now if i open a tcpdump session in the router and in the server and i configure correctly the dhcpd in the server i notice that traffic from the dhcrelay_second to the dhclient host in the vlanyyy isn't correctly forwarded. And it is not a pf problem. The strangeness is that if i don't execute the relay from rcctl but i execute with: dhcrelay_second -d -i vlanyyy DST_ADDR it works like a charm. If you want more debug or pcap files or access to the machines there's no problem at all. Thank you to spend your time, nice regards, RG -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: Canyelles, BCN, España PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
Re: Keeping track of MAC addresses
On Thu, 21 Feb 2019 at 07:15, wrote: > > > did you take a look at net/arpwatch? > > Too many emails; email to root is not a useful mechanism for me. arpwatch could be configured to send emails to an address other than root. At the time I was using it, the --help showed a command line option for specifying alternative email addresses, but it did not work then. It's been many years since I used it, so this may have changed, but I had to adjust #define's for WATCHER and WATCHEE, to hard code alternative email addresses into the binary. Combined with an email to SMS text message gateway service, this gave my manager and I almost instant notification when staff with physical access added hosts to certain networks they were not permitted to. Shane
Re: Packet loss with latest snapshot
On Mon, 4 Mar 2019, 13:29 David Gwynne, wrote: > On Mon, Mar 04, 2019 at 10:36:23AM +0100, Tony Sarendal wrote: > > On Mon, 4 Mar 2019, 09:43 Tony Sarendal, wrote: > > > > > > > > > > > Den m??n 4 mars 2019 kl 09:26 skrev Tony Sarendal : > > > > > >> Den s??n 3 mars 2019 kl 21:35 skrev Theo de Raadt < > dera...@openbsd.org>: > > >> > > >>> Tony, > > >>> > > >>> Are you out of your mind? You didn't provide even a rough hint about > > >>> what your firewall configuration looks like. You recognize that's > > >>> pathetic, right? > > >>> > > >>> > Earlier in the week I could run parallel ping-pong tests through my > > >>> test > > >>> > firewalls > > >>> > at 300kpps without any packet loss. I updated to the latest > snapshot > > >>> today > > >>> > and > > >>> > start to see packet loss at around 80kpps. > > >>> > > > >>> > /T > > >>> > > > >>> > OpenBSD 6.5-beta (GENERIC.MP) #764: Sun Mar 3 10:24:08 MST 2019 > > >>> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ > > >>> GENERIC.MP > > >>> > real mem = 34300891136 (32711MB) > > >>> > avail mem = 33251393536 (31711MB) > > >>> > mpath0 at root > > >>> > scsibus0 at mpath0: 256 targets > > >>> > mainbus0 at root > > >>> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec170 (34 entries) > > >>> > bios0: vendor American Megatrends Inc. version "3.0" date > 04/24/2015 > > >>> > bios0: Supermicro X10SLD > > >>> > acpi0 at bios0: rev 2 > > >>> > acpi0: sleep states S0 S4 S5 > > >>> > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT MCFG PRAD HPET > SSDT > > >>> SSDT > > >>> > SPMI DMAR EINJ ERST HEST BERT > > >>> > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) > > >>> PEG2(S4) > > >>> > PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) > RP04(S4) > > >>> > PXSX(S4) RP05(S4) [...] > > >>> > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > >>> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > >>> > cpu0 at mainbus0: apid 0 (boot processor) > > >>> > cpu0: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.68 MHz, > 06-3c-03 > > >>> > cpu0: > > >>> > > > >>> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > >>> > cpu0: 256KB 64b/line 8-way L2 cache > > >>> > cpu0: smt 0, core 0, package 0 > > >>> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > > >>> > cpu0: apic clock running at 99MHz > > >>> > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > > >>> > cpu1 at mainbus0: apid 2 (application processor) > > >>> > cpu1: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, > 06-3c-03 > > >>> > cpu1: > > >>> > > > >>> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > >>> > cpu1: 256KB 64b/line 8-way L2 cache > > >>> > cpu1: smt 0, core 1, package 0 > > >>> > cpu2 at mainbus0: apid 4 (application processor) > > >>> > cpu2: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, > 06-3c-03 > > >>> > cpu2: > > >>> > > > >>> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > >>> > cpu2: 256KB 64b/line 8-way L2 cache > > >>> > cpu2: smt 0, core 2, package 0 > > >>> > cpu3 at mainbus0: apid 6 (application processor) > > >>> > cpu3: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, > 06-3c-03 > > >>> > cpu3: > > >>> > > > >>> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > >>> > cpu3: 256KB 64b/line 8-way L2 cache > > >>> > cpu3: smt 0, core 3, package 0 > > >>> > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins > > >>> > acpimcfg0 at acpi0 > > >>> > acpimcfg0: addr 0xf800, bus 0-63 > > >>> > acpihpet0 at acpi0: 14318179 Hz > > >>> > a
Race condition in vmd(8) resulting in "freezing"
Hi misc@!
I have figured out that it is possible to get vmd(8) into a state where
1) com1_dev.rcv_pending != 0
2) there is data pending on com1_dev.fd
3) the guest doesn't seem to care
This results in a locked up situation where com_rcv_event() is called on
indefinitely. It seems to me that an interrupt is lost somewhere, leading
to a situation where the guest OS is happily ignorant of the available data,
while the vmm is waiting for the guest to eat it up.
This has made it impossible to install Linux via the serial console on
vmm(4). It seems that people previously have reported "freezing" problems
in vmm(4) form time to time, but when reported no one else have been able to
reproduce it.
I have solved the problem for myself by changing com_rcv_event() to the
following:
static void
com_rcv_event(int fd, short kind, void *arg)
{
mutex_lock(&com1_dev.mutex);
/*
* We already have other data pending to be received. The data that
* has become available now will be moved to the com port later.
*/
if (com1_dev.rcv_pending) {
/* If pending interrupt, inject */
if ((com1_dev.regs.iir & IIR_NOPEND) == 0) {
utrace("comrcv injintr", &com1_dev.regs.lsr,
sizeof(com1_dev.regs.lsr));
/* XXX: vcpu_id */
vcpu_assert_pic_irq((uintptr_t) arg, 0, com1_dev.irq);
vcpu_deassert_pic_irq((uintptr_t) arg, 0, com1_dev.irq);
}
mutex_unlock(&com1_dev.mutex);
return;
}
if (com1_dev.regs.lsr & LSR_RXRDY)
com1_dev.rcv_pending = 1;
else {
com_rcv(&com1_dev, (uintptr_t) arg, 0);
/* If pending interrupt, inject */
if ((com1_dev.regs.iir & IIR_NOPEND) == 0) {
/* XXX: vcpu_id */
vcpu_assert_pic_irq((uintptr_t) arg, 0, com1_dev.irq);
vcpu_deassert_pic_irq((uintptr_t) arg, 0, com1_dev.irq);
}
}
mutex_unlock(&com1_dev.mutex);
}
However, I have little experience in the interrupt behaviour on x86. I'm
also aware of that there has been an attempt to fix this behaviour [1].
I think the problem is that when com_rcv() is called from
vcpu_process_com_data(), the interrupt is triggered using vcpu_exit_inout(),
which was not touched in the previous attempt [1] to fix the "freezing"
problem. vcpu_exit_inout() still uses a simple vcpu_assert_pic_irq() call
to trigger the interrupt while for example com_rcv_event() uses the
vcpu_assert_pic_irq(); vcpu_deassert_pic_irq() sequence to trigger it.
With my modifications to com_rcv_event() I was able to install not only
alpine linux, but even debian using the serial console. Without the
modification I can't even install alpine linux via the serial console.
Any thoughts on this? If people think my change is a sound one, I can make
a proper patch for it. If people think the change is unsound, I would have
to look into changing vcpu_exit_inout() and probably extend the interface to
it to decide how the interrupt should be triggered.
1. https://marc.info/?l=openbsd-cvs&m=153115270302514&w=2
--
Wictor Lund
Re: Packet loss with latest snapshot
On Mon, Mar 04, 2019 at 10:36:23AM +0100, Tony Sarendal wrote: > On Mon, 4 Mar 2019, 09:43 Tony Sarendal, wrote: > > > > > > > Den m??n 4 mars 2019 kl 09:26 skrev Tony Sarendal : > > > >> Den s??n 3 mars 2019 kl 21:35 skrev Theo de Raadt : > >> > >>> Tony, > >>> > >>> Are you out of your mind? You didn't provide even a rough hint about > >>> what your firewall configuration looks like. You recognize that's > >>> pathetic, right? > >>> > >>> > Earlier in the week I could run parallel ping-pong tests through my > >>> test > >>> > firewalls > >>> > at 300kpps without any packet loss. I updated to the latest snapshot > >>> today > >>> > and > >>> > start to see packet loss at around 80kpps. > >>> > > >>> > /T > >>> > > >>> > OpenBSD 6.5-beta (GENERIC.MP) #764: Sun Mar 3 10:24:08 MST 2019 > >>> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ > >>> GENERIC.MP > >>> > real mem = 34300891136 (32711MB) > >>> > avail mem = 33251393536 (31711MB) > >>> > mpath0 at root > >>> > scsibus0 at mpath0: 256 targets > >>> > mainbus0 at root > >>> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec170 (34 entries) > >>> > bios0: vendor American Megatrends Inc. version "3.0" date 04/24/2015 > >>> > bios0: Supermicro X10SLD > >>> > acpi0 at bios0: rev 2 > >>> > acpi0: sleep states S0 S4 S5 > >>> > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT MCFG PRAD HPET SSDT > >>> SSDT > >>> > SPMI DMAR EINJ ERST HEST BERT > >>> > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) > >>> PEG2(S4) > >>> > PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) > >>> > PXSX(S4) RP05(S4) [...] > >>> > acpitimer0 at acpi0: 3579545 Hz, 24 bits > >>> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > >>> > cpu0 at mainbus0: apid 0 (boot processor) > >>> > cpu0: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.68 MHz, 06-3c-03 > >>> > cpu0: > >>> > > >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > >>> > cpu0: 256KB 64b/line 8-way L2 cache > >>> > cpu0: smt 0, core 0, package 0 > >>> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > >>> > cpu0: apic clock running at 99MHz > >>> > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > >>> > cpu1 at mainbus0: apid 2 (application processor) > >>> > cpu1: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 > >>> > cpu1: > >>> > > >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > >>> > cpu1: 256KB 64b/line 8-way L2 cache > >>> > cpu1: smt 0, core 1, package 0 > >>> > cpu2 at mainbus0: apid 4 (application processor) > >>> > cpu2: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 > >>> > cpu2: > >>> > > >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > >>> > cpu2: 256KB 64b/line 8-way L2 cache > >>> > cpu2: smt 0, core 2, package 0 > >>> > cpu3 at mainbus0: apid 6 (application processor) > >>> > cpu3: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 > >>> > cpu3: > >>> > > >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > >>> > cpu3: 256KB 64b/line 8-way L2 cache > >>> > cpu3: smt 0, core 3, package 0 > >>> > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins > >>> > acpimcfg0 at acpi0 > >>> > acpimcfg0: addr 0xf800, bus 0-63 > >>> > acpihpet0 at acpi0: 14318179 Hz > >>> > acpiprt0 at acpi0: bus 0 (PCI0) > >>> > acpiprt1 at acpi0: bus 1 (PEG0) > >>> > acpiprt2 at acpi0: bus 2 (PEG1) > >>> > acpiprt3 at acpi0: bus -1 (PEG2) > >>> > acpiprt4 at acpi0: bus 3 (RP01) > >>> > acpiprt5 at acpi0: bus -1 (RP02) > >>> > acpiprt6 at acpi0: bu
Re: Packet loss with latest snapshot
On Mon, 4 Mar 2019, 09:43 Tony Sarendal, wrote: > > > Den mån 4 mars 2019 kl 09:26 skrev Tony Sarendal : > >> Den sön 3 mars 2019 kl 21:35 skrev Theo de Raadt : >> >>> Tony, >>> >>> Are you out of your mind? You didn't provide even a rough hint about >>> what your firewall configuration looks like. You recognize that's >>> pathetic, right? >>> >>> > Earlier in the week I could run parallel ping-pong tests through my >>> test >>> > firewalls >>> > at 300kpps without any packet loss. I updated to the latest snapshot >>> today >>> > and >>> > start to see packet loss at around 80kpps. >>> > >>> > /T >>> > >>> > OpenBSD 6.5-beta (GENERIC.MP) #764: Sun Mar 3 10:24:08 MST 2019 >>> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ >>> GENERIC.MP >>> > real mem = 34300891136 (32711MB) >>> > avail mem = 33251393536 (31711MB) >>> > mpath0 at root >>> > scsibus0 at mpath0: 256 targets >>> > mainbus0 at root >>> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec170 (34 entries) >>> > bios0: vendor American Megatrends Inc. version "3.0" date 04/24/2015 >>> > bios0: Supermicro X10SLD >>> > acpi0 at bios0: rev 2 >>> > acpi0: sleep states S0 S4 S5 >>> > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT MCFG PRAD HPET SSDT >>> SSDT >>> > SPMI DMAR EINJ ERST HEST BERT >>> > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) >>> PEG2(S4) >>> > PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) >>> > PXSX(S4) RP05(S4) [...] >>> > acpitimer0 at acpi0: 3579545 Hz, 24 bits >>> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >>> > cpu0 at mainbus0: apid 0 (boot processor) >>> > cpu0: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.68 MHz, 06-3c-03 >>> > cpu0: >>> > >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >>> > cpu0: 256KB 64b/line 8-way L2 cache >>> > cpu0: smt 0, core 0, package 0 >>> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges >>> > cpu0: apic clock running at 99MHz >>> > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE >>> > cpu1 at mainbus0: apid 2 (application processor) >>> > cpu1: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 >>> > cpu1: >>> > >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >>> > cpu1: 256KB 64b/line 8-way L2 cache >>> > cpu1: smt 0, core 1, package 0 >>> > cpu2 at mainbus0: apid 4 (application processor) >>> > cpu2: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 >>> > cpu2: >>> > >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >>> > cpu2: 256KB 64b/line 8-way L2 cache >>> > cpu2: smt 0, core 2, package 0 >>> > cpu3 at mainbus0: apid 6 (application processor) >>> > cpu3: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 >>> > cpu3: >>> > >>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >>> > cpu3: 256KB 64b/line 8-way L2 cache >>> > cpu3: smt 0, core 3, package 0 >>> > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins >>> > acpimcfg0 at acpi0 >>> > acpimcfg0: addr 0xf800, bus 0-63 >>> > acpihpet0 at acpi0: 14318179 Hz >>> > acpiprt0 at acpi0: bus 0 (PCI0) >>> > acpiprt1 at acpi0: bus 1 (PEG0) >>> > acpiprt2 at acpi0: bus 2 (PEG1) >>> > acpiprt3 at acpi0: bus -1 (PEG2) >>> > acpiprt4 at acpi0: bus 3 (RP01) >>> > acpiprt5 at acpi0: bus -1 (RP02) >>> > acpiprt6 at acpi0: bus -1 (RP03) >>> > acpiprt7 at acpi0: bus -1 (RP04) >>> > acpiprt8 at acpi0: bus -1 (RP05) >>> > acpiprt9 at acpi0: bus -1 (RP06) >>> > acpiprt10 at acpi0: bus -1 (RP07) >>> > acpiprt11 at acpi0: bus -1 (RP08) >>> > acpiec0 at acpi0: not pres
Re: Packet loss with latest snapshot
Den mån 4 mars 2019 kl 09:26 skrev Tony Sarendal : > Den sön 3 mars 2019 kl 21:35 skrev Theo de Raadt : > >> Tony, >> >> Are you out of your mind? You didn't provide even a rough hint about >> what your firewall configuration looks like. You recognize that's >> pathetic, right? >> >> > Earlier in the week I could run parallel ping-pong tests through my test >> > firewalls >> > at 300kpps without any packet loss. I updated to the latest snapshot >> today >> > and >> > start to see packet loss at around 80kpps. >> > >> > /T >> > >> > OpenBSD 6.5-beta (GENERIC.MP) #764: Sun Mar 3 10:24:08 MST 2019 >> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ >> GENERIC.MP >> > real mem = 34300891136 (32711MB) >> > avail mem = 33251393536 (31711MB) >> > mpath0 at root >> > scsibus0 at mpath0: 256 targets >> > mainbus0 at root >> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec170 (34 entries) >> > bios0: vendor American Megatrends Inc. version "3.0" date 04/24/2015 >> > bios0: Supermicro X10SLD >> > acpi0 at bios0: rev 2 >> > acpi0: sleep states S0 S4 S5 >> > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT MCFG PRAD HPET SSDT >> SSDT >> > SPMI DMAR EINJ ERST HEST BERT >> > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) >> PEG2(S4) >> > PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) >> > PXSX(S4) RP05(S4) [...] >> > acpitimer0 at acpi0: 3579545 Hz, 24 bits >> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >> > cpu0 at mainbus0: apid 0 (boot processor) >> > cpu0: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.68 MHz, 06-3c-03 >> > cpu0: >> > >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> > cpu0: 256KB 64b/line 8-way L2 cache >> > cpu0: smt 0, core 0, package 0 >> > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges >> > cpu0: apic clock running at 99MHz >> > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE >> > cpu1 at mainbus0: apid 2 (application processor) >> > cpu1: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 >> > cpu1: >> > >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> > cpu1: 256KB 64b/line 8-way L2 cache >> > cpu1: smt 0, core 1, package 0 >> > cpu2 at mainbus0: apid 4 (application processor) >> > cpu2: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 >> > cpu2: >> > >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> > cpu2: 256KB 64b/line 8-way L2 cache >> > cpu2: smt 0, core 2, package 0 >> > cpu3 at mainbus0: apid 6 (application processor) >> > cpu3: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 >> > cpu3: >> > >> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> > cpu3: 256KB 64b/line 8-way L2 cache >> > cpu3: smt 0, core 3, package 0 >> > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins >> > acpimcfg0 at acpi0 >> > acpimcfg0: addr 0xf800, bus 0-63 >> > acpihpet0 at acpi0: 14318179 Hz >> > acpiprt0 at acpi0: bus 0 (PCI0) >> > acpiprt1 at acpi0: bus 1 (PEG0) >> > acpiprt2 at acpi0: bus 2 (PEG1) >> > acpiprt3 at acpi0: bus -1 (PEG2) >> > acpiprt4 at acpi0: bus 3 (RP01) >> > acpiprt5 at acpi0: bus -1 (RP02) >> > acpiprt6 at acpi0: bus -1 (RP03) >> > acpiprt7 at acpi0: bus -1 (RP04) >> > acpiprt8 at acpi0: bus -1 (RP05) >> > acpiprt9 at acpi0: bus -1 (RP06) >> > acpiprt10 at acpi0: bus -1 (RP07) >> > acpiprt11 at acpi0: bus -1 (RP08) >> > acpiec0 at acpi0: not present >> > acpicpu0 at acpi0: C1(@1 halt!) >> > acpicpu1 at acpi0: C1(@1 halt!) >> > acpicpu2 at acpi0: C1(@1 halt!) >> > acpicpu3 at acpi0: C1(@1 hal
Re: Packet loss with latest snapshot
Den sön 3 mars 2019 kl 21:35 skrev Theo de Raadt : > Tony, > > Are you out of your mind? You didn't provide even a rough hint about > what your firewall configuration looks like. You recognize that's > pathetic, right? > > > Earlier in the week I could run parallel ping-pong tests through my test > > firewalls > > at 300kpps without any packet loss. I updated to the latest snapshot > today > > and > > start to see packet loss at around 80kpps. > > > > /T > > > > OpenBSD 6.5-beta (GENERIC.MP) #764: Sun Mar 3 10:24:08 MST 2019 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 34300891136 (32711MB) > > avail mem = 33251393536 (31711MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec170 (34 entries) > > bios0: vendor American Megatrends Inc. version "3.0" date 04/24/2015 > > bios0: Supermicro X10SLD > > acpi0 at bios0: rev 2 > > acpi0: sleep states S0 S4 S5 > > acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT MCFG PRAD HPET SSDT SSDT > > SPMI DMAR EINJ ERST HEST BERT > > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) > PEG2(S4) > > PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) > > PXSX(S4) RP05(S4) [...] > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.68 MHz, 06-3c-03 > > cpu0: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu0: 256KB 64b/line 8-way L2 cache > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > > cpu0: apic clock running at 99MHz > > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > > cpu1 at mainbus0: apid 2 (application processor) > > cpu1: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 > > cpu1: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu1: 256KB 64b/line 8-way L2 cache > > cpu1: smt 0, core 1, package 0 > > cpu2 at mainbus0: apid 4 (application processor) > > cpu2: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 > > cpu2: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu2: 256KB 64b/line 8-way L2 cache > > cpu2: smt 0, core 2, package 0 > > cpu3 at mainbus0: apid 6 (application processor) > > cpu3: Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz, 3500.01 MHz, 06-3c-03 > > cpu3: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu3: 256KB 64b/line 8-way L2 cache > > cpu3: smt 0, core 3, package 0 > > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins > > acpimcfg0 at acpi0 > > acpimcfg0: addr 0xf800, bus 0-63 > > acpihpet0 at acpi0: 14318179 Hz > > acpiprt0 at acpi0: bus 0 (PCI0) > > acpiprt1 at acpi0: bus 1 (PEG0) > > acpiprt2 at acpi0: bus 2 (PEG1) > > acpiprt3 at acpi0: bus -1 (PEG2) > > acpiprt4 at acpi0: bus 3 (RP01) > > acpiprt5 at acpi0: bus -1 (RP02) > > acpiprt6 at acpi0: bus -1 (RP03) > > acpiprt7 at acpi0: bus -1 (RP04) > > acpiprt8 at acpi0: bus -1 (RP05) > > acpiprt9 at acpi0: bus -1 (RP06) > > acpiprt10 at acpi0: bus -1 (RP07) > > acpiprt11 at acpi0: bus -1 (RP08) > > acpiec0 at acpi0: not present > > acpicpu0 at acpi0: C1(@1 halt!) > > acpicpu1 at acpi0: C1(@1 halt!) > > acpicpu2 at acpi0: C1(@1 halt!) > > acpicpu3 at acpi0: C1(@1 halt!) > > acpipwrres0 at acpi0: PG00, resource for PEG0 > > acpipwrres1 at acpi0: PG01, resource for PEG1 > > acpipwrres2 at acpi0: PG02, resource for
