arp(8) and ndp(8) tweaks
Diff below indicates by using a `l' flag which entries are local to the
machine.
It also skips broadcast entries from the arp -a output because even if
they are implemented as llinfo entries, they'll never be resolved and can
be safely ignored.
Finally it change arp(8) to display 'permanent' instead of 'static' for
local entries, to be coherent with ndp(8).
Ok?
Index: arp/arp.8
===
RCS file: /home/ncvs/src/usr.sbin/arp/arp.8,v
retrieving revision 1.34
diff -u -p -r1.34 arp.8
--- arp/arp.8 21 Aug 2014 10:23:47 - 1.34
+++ arp/arp.8 2 Sep 2014 08:18:23 -
@@ -99,7 +99,9 @@ or
it will never expire.
.It Flags
Flags on the ARP entry, in a single letter.
-They are: proxy
+They are: local
+.Pq Sq l ,
+proxy
.Pq Sq P
and published
.Pq Sq p .
Index: arp/arp.c
===
RCS file: /home/ncvs/src/usr.sbin/arp/arp.c,v
retrieving revision 1.60
diff -u -p -r1.60 arp.c
--- arp/arp.c 22 Aug 2014 22:14:53 - 1.60
+++ arp/arp.c 2 Sep 2014 08:18:23 -
@@ -493,6 +493,8 @@ search(in_addr_t addr, void (*action)(st
rtm = (struct rt_msghdr *)next;
if (rtm-rtm_version != RTM_VERSION)
continue;
+ if (rtm-rtm_flags RTF_BROADCAST)
+ continue;
sin = (struct sockaddr_inarp *)(next + rtm-rtm_hdrlen);
sdl = (struct sockaddr_dl *)(sin + 1);
if (addr) {
@@ -557,7 +559,7 @@ print_entry(struct sockaddr_dl *sdl, str
printf(%-*.*s %-*.*s %*.*s, addrwidth, addrwidth, host,
llwidth, llwidth, ether_str(sdl), ifwidth, ifwidth, ifname);
- if (rtm-rtm_flags RTF_PERMANENT_ARP)
+ if (rtm-rtm_flags (RTF_PERMANENT_ARP|RTF_LOCAL|RTF_BROADCAST))
printf( %-10.10s, permanent);
else if (rtm-rtm_rmx.rmx_expire == 0)
printf( %-10.10s, static);
@@ -567,7 +569,8 @@ print_entry(struct sockaddr_dl *sdl, str
else
printf( %-10.10s, expired);
- snprintf(flgbuf, sizeof(flgbuf), %s%s,
+ snprintf(flgbuf, sizeof(flgbuf), %s%s%s,
+ (rtm-rtm_flags RTF_LOCAL) ? l : ,
(sin-sin_other SIN_PROXY) ? P : ,
(rtm-rtm_flags RTF_ANNOUNCE) ? p : );
Index: ndp/ndp.8
===
RCS file: /home/ncvs/src/usr.sbin/ndp/ndp.8,v
retrieving revision 1.32
diff -u -p -r1.32 ndp.8
--- ndp/ndp.8 12 Jul 2014 17:03:47 - 1.32
+++ ndp/ndp.8 2 Sep 2014 08:18:23 -
@@ -105,7 +105,9 @@ Unknown state (should never happen).
.El
.It Flags
Flags on the neighbor cache entry, in a single letter.
-They are: Router
+They are: local
+.Pq Sq l ,
+Router
.Pq Sq R
and proxy neighbor advertisement
.Pq Sq p .
Index: ndp/ndp.c
===
RCS file: /home/ncvs/src/usr.sbin/ndp/ndp.c,v
retrieving revision 1.56
diff -u -p -r1.56 ndp.c
--- ndp/ndp.c 22 Aug 2014 22:37:32 - 1.56
+++ ndp/ndp.c 2 Sep 2014 08:18:23 -
@@ -714,23 +714,17 @@ again:;
* other flags. R: router, P: proxy, W: ??
*/
if ((rtm-rtm_addrs RTA_NETMASK) == 0) {
- snprintf(flgbuf, sizeof(flgbuf), %s%s,
+ snprintf(flgbuf, sizeof(flgbuf), %s%s%s,
+ (rtm-rtm_flags RTF_LOCAL) ? l : ,
isrouter ? R : ,
(rtm-rtm_flags RTF_ANNOUNCE) ? p : );
} else {
sin = (struct sockaddr_in6 *)
(sdl-sdl_len + (char *)sdl);
-#if 0 /* W and P are mystery even for us */
- snprintf(flgbuf, sizeof(flgbuf), %s%s%s%s,
+ snprintf(flgbuf, sizeof(flgbuf), %s%s%s,
+ (rtm-rtm_flags RTF_LOCAL) ? l : ,
isrouter ? R : ,
- !IN6_IS_ADDR_UNSPECIFIED(sin-sin6_addr) ? P :
,
- (sin-sin6_len != sizeof(struct sockaddr_in6)) ?
W : ,
(rtm-rtm_flags RTF_ANNOUNCE) ? p : );
-#else
- snprintf(flgbuf, sizeof(flgbuf), %s%s,
- isrouter ? R : ,
- (rtm-rtm_flags RTF_ANNOUNCE) ? p : );
-#endif
}
printf( %s, flgbuf);
Re: bge(4) Jumbo support for newer chipsets
On 2 September 2014 03:54, Brad Smith b...@comstyle.com wrote: On Wed, Aug 27, 2014 at 02:25:27AM -0400, Brad Smith wrote: Looking for some testing of the following diff to add Jumbo support for the BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766 chipsets. Here is an updated diff with bge_rxrinfo() being fixed. get it in. OK mikeb
re(4) feature flags additions and changes
Add some feature flags and store in the softc the various max Jumbo frame sizes
for the different generations of chips. No behavioral change.
Tested with..
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800)
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G (0x4c00)
OK?
Index: pci/if_re_pci.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 if_re_pci.c
--- pci/if_re_pci.c 22 Jul 2014 13:12:11 - 1.41
+++ pci/if_re_pci.c 20 Aug 2014 02:06:34 -
@@ -197,6 +197,23 @@ re_pci_attach(struct device *parent, str
CSR_WRITE_1(sc, RL_EECMD, RL_EEMODE_OFF);
}
+ sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
+
+ switch (sc-sc_hwrev) {
+ case RL_HWREV_8168GU:
+ if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_REALTEK_RT8101E) {
+ /* RTL8106EUS */
+ sc-rl_flags |= RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
+ } else {
+ sc-rl_flags |= RL_FLAG_JUMBOV2 | RL_FLAG_WOL_MANLINK;
+ sc-rl_max_mtu = RL_JUMBO_MTU_9K;
+ }
+ break;
+ default:
+ break;
+ }
+
/* Call bus-independent attach routine */
if (re_attach(sc, intrstr)) {
pci_intr_disestablish(pc, psc-sc_ih);
Index: cardbus/if_re_cardbus.c
===
RCS file: /home/cvs/src/sys/dev/cardbus/if_re_cardbus.c,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 if_re_cardbus.c
--- cardbus/if_re_cardbus.c 11 Aug 2014 12:45:45 - 1.24
+++ cardbus/if_re_cardbus.c 24 Aug 2014 23:09:04 -
@@ -152,6 +152,8 @@ re_cardbus_attach(struct device *parent,
}
snprintf(intrstr, sizeof(intrstr), irq %d, ca-ca_intrline);
+ sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
+
/* Call bus-independent (common) attach routine */
if (re_attach(sc, intrstr)) {
cardbus_intr_disestablish(ct-ct_cc, ct-ct_cf, csc-sc_ih);
Index: ic/re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.155
diff -u -p -u -p -r1.155 re.c
--- ic/re.c 22 Jul 2014 13:12:12 - 1.155
+++ ic/re.c 24 Aug 2014 23:09:05 -
@@ -578,7 +578,7 @@ re_iff(struct rl_softc *sc)
* parts. This means we have to write the hash pattern in reverse
* order for those devices.
*/
- if (sc-rl_flags RL_FLAG_INVMAR) {
+ if (sc-rl_flags RL_FLAG_PCIE) {
CSR_WRITE_4(sc, RL_MAR0, swap32(hashes[1]));
CSR_WRITE_4(sc, RL_MAR4, swap32(hashes[0]));
} else {
@@ -604,7 +604,7 @@ re_reset(struct rl_softc *sc)
if (i == RL_TIMEOUT)
printf(%s: reset never completed!\n, sc-sc_dev.dv_xname);
- if (sc-rl_flags RL_FLAG_MACLDPS)
+ if (sc-rl_flags RL_FLAG_MACRESET)
CSR_WRITE_1(sc, RL_LDPS, 1);
}
@@ -635,17 +635,16 @@ re_attach(struct rl_softc *sc, const cha
const struct re_revision *rr;
const char *re_name = NULL;
- sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
-
switch (sc-sc_hwrev) {
case RL_HWREV_8139CPLUS:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_FASTETHER | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8100E:
case RL_HWREV_8100E_SPIN2:
case RL_HWREV_8101E:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8103E:
sc-rl_flags |= RL_FLAG_MACSLEEP;
@@ -653,70 +652,94 @@ re_attach(struct rl_softc *sc, const cha
case RL_HWREV_8102E:
case RL_HWREV_8102EL:
case RL_HWREV_8102EL_SPIN1:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 |
- RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
+ RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_FASTETHER |
+ RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8401E:
- case RL_HWREV_8402:
case RL_HWREV_8105E:
case RL_HWREV_8105E_SPIN1:
case RL_HWREV_8106E:
- sc-rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
- RL_FLAG_PHYWAKE_PM | RL_FLAG_PAR | RL_FLAG_DESCV2 |
-
Re: re(4) feature flags additions and changes
On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote: Add some feature flags and store in the softc the various max Jumbo frame sizes for the different generations of chips. No behavioral change. Tested with.. re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800) re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G (0x4c00) OK? This would be a much easier diff to read if you didn't change the names of a whole bunch of flags. +#define RL_FLAG_HWIM0x00800 +#define RL_FLAG_MACSLEEP0x0800 This is obviously wrong.
Re: re(4) feature flags additions and changes
On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote:
Add some feature flags and store in the softc the various max Jumbo frame
sizes
for the different generations of chips. No behavioral change.
Tested with..
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800)
re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G (0x4c00)
OK?
Fix a typo with RL_FLAG_HWIM.
Index: pci/if_re_pci.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 if_re_pci.c
--- pci/if_re_pci.c 22 Jul 2014 13:12:11 - 1.41
+++ pci/if_re_pci.c 20 Aug 2014 02:06:34 -
@@ -197,6 +197,23 @@ re_pci_attach(struct device *parent, str
CSR_WRITE_1(sc, RL_EECMD, RL_EEMODE_OFF);
}
+ sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
+
+ switch (sc-sc_hwrev) {
+ case RL_HWREV_8168GU:
+ if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_REALTEK_RT8101E) {
+ /* RTL8106EUS */
+ sc-rl_flags |= RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
+ } else {
+ sc-rl_flags |= RL_FLAG_JUMBOV2 | RL_FLAG_WOL_MANLINK;
+ sc-rl_max_mtu = RL_JUMBO_MTU_9K;
+ }
+ break;
+ default:
+ break;
+ }
+
/* Call bus-independent attach routine */
if (re_attach(sc, intrstr)) {
pci_intr_disestablish(pc, psc-sc_ih);
Index: cardbus/if_re_cardbus.c
===
RCS file: /home/cvs/src/sys/dev/cardbus/if_re_cardbus.c,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 if_re_cardbus.c
--- cardbus/if_re_cardbus.c 11 Aug 2014 12:45:45 - 1.24
+++ cardbus/if_re_cardbus.c 24 Aug 2014 23:09:04 -
@@ -152,6 +152,8 @@ re_cardbus_attach(struct device *parent,
}
snprintf(intrstr, sizeof(intrstr), irq %d, ca-ca_intrline);
+ sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
+
/* Call bus-independent (common) attach routine */
if (re_attach(sc, intrstr)) {
cardbus_intr_disestablish(ct-ct_cc, ct-ct_cf, csc-sc_ih);
Index: ic/re.c
===
RCS file: /home/cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.155
diff -u -p -u -p -r1.155 re.c
--- ic/re.c 22 Jul 2014 13:12:12 - 1.155
+++ ic/re.c 24 Aug 2014 23:09:05 -
@@ -578,7 +578,7 @@ re_iff(struct rl_softc *sc)
* parts. This means we have to write the hash pattern in reverse
* order for those devices.
*/
- if (sc-rl_flags RL_FLAG_INVMAR) {
+ if (sc-rl_flags RL_FLAG_PCIE) {
CSR_WRITE_4(sc, RL_MAR0, swap32(hashes[1]));
CSR_WRITE_4(sc, RL_MAR4, swap32(hashes[0]));
} else {
@@ -604,7 +604,7 @@ re_reset(struct rl_softc *sc)
if (i == RL_TIMEOUT)
printf(%s: reset never completed!\n, sc-sc_dev.dv_xname);
- if (sc-rl_flags RL_FLAG_MACLDPS)
+ if (sc-rl_flags RL_FLAG_MACRESET)
CSR_WRITE_1(sc, RL_LDPS, 1);
}
@@ -635,17 +635,16 @@ re_attach(struct rl_softc *sc, const cha
const struct re_revision *rr;
const char *re_name = NULL;
- sc-sc_hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
-
switch (sc-sc_hwrev) {
case RL_HWREV_8139CPLUS:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_FASTETHER | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8100E:
case RL_HWREV_8100E_SPIN2:
case RL_HWREV_8101E:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_FASTETHER;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8103E:
sc-rl_flags |= RL_FLAG_MACSLEEP;
@@ -653,70 +652,94 @@ re_attach(struct rl_softc *sc, const cha
case RL_HWREV_8102E:
case RL_HWREV_8102EL:
case RL_HWREV_8102EL_SPIN1:
- sc-rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR |
- RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 |
- RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
+ RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_FASTETHER |
+ RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD;
+ sc-rl_max_mtu = RL_MTU;
break;
case RL_HWREV_8401E:
- case RL_HWREV_8402:
case RL_HWREV_8105E:
case RL_HWREV_8105E_SPIN1:
case RL_HWREV_8106E:
- sc-rl_flags |= RL_FLAG_INVMAR |
Re: re(4) feature flags additions and changes
On Tue, Sep 02, 2014 at 09:03:34PM +1000, Jonathan Gray wrote: On Tue, Sep 02, 2014 at 06:28:48AM -0400, Brad Smith wrote: Add some feature flags and store in the softc the various max Jumbo frame sizes for the different generations of chips. No behavioral change. Tested with.. re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800) re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x0c: RTL8168G/8111G (0x4c00) OK? This would be a much easier diff to read if you didn't change the names of a whole bunch of flags. Changed.. RL_FLAG_MACLDPS - RL_FLAG_MACRESET. Removed.. RL_FLAG_INVMAR, RL_FLAG_NOJUMBO. Added.. RL_FLAG_FASTETHER, RL_FLAG_CMDSTOP_WAIT_TXQ, RL_FLAG_JUMBOV2, RL_FLAG_WOL_MANLINK, RL_FLAG_WAIT_TXPOLL, RL_FLAG_WOLRXENB. +#defineRL_FLAG_HWIM0x00800 +#defineRL_FLAG_MACSLEEP0x0800 This is obviously wrong. A typo. Fixed. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: minphys woes
On Monday 01 September 2014 22:24:16, David Gwynne wrote: i haven't found a controller that does less than MAXPHYS. perhaps they meant to improve the situation but stopped short. if we wanted to raise MAXPHYS, we'd have to support older controllers that cant do greater than 64k with some mechanism. So the summary of this thread is that - drivers have to support 64K transfers - the minphys mechanism is useless at the moment Not quite what I hoped, but ok. Do you know a good place where this should be documented?
Re: minphys woes
On Tue, Sep 2, 2014 at 12:51 PM, Stefan Fritsch s...@sfritsch.de wrote: On Monday 01 September 2014 22:24:16, David Gwynne wrote: i haven't found a controller that does less than MAXPHYS. perhaps they meant to improve the situation but stopped short. if we wanted to raise MAXPHYS, we'd have to support older controllers that cant do greater than 64k with some mechanism. So the summary of this thread is that - drivers have to support 64K transfers - the minphys mechanism is useless at the moment Useless? It works just fine for physio, which is what it was designed for, no? Not quite what I hoped, but ok. Do you know a good place where this should be documented? minphys is currently documented on physio(9) Philip Guenther
Re: minphys woes
On Tuesday 02 September 2014 13:15:19, Philip Guenther wrote: On Tue, Sep 2, 2014 at 12:51 PM, Stefan Fritsch s...@sfritsch.de wrote: On Monday 01 September 2014 22:24:16, David Gwynne wrote: i haven't found a controller that does less than MAXPHYS. perhaps they meant to improve the situation but stopped short. if we wanted to raise MAXPHYS, we'd have to support older controllers that cant do greater than 64k with some mechanism. So the summary of this thread is that - drivers have to support 64K transfers - the minphys mechanism is useless at the moment Useless? It works just fine for physio, which is what it was designed for, no? Not quite what I hoped, but ok. Do you know a good place where this should be documented? minphys is currently documented on physio(9) From physio(9): minphys A device specific routine called to determine the maximum transfer size that the device's strategy routine can handle. Since we have seen that the driver must be able to handle 64k blocks in any case, the fact that minphys is device specific is useless, isn't it?
Re: LibreSSL 2.0.5 released
Brent Cook busterb at gmail.com writes: We have released LibreSSL 2.0.5, which should be arriving in the LibreSSL directory of an OpenBSD mirror near you. [SNIP] We welcome feedback and support from the community as we continue to work on LibreSSL. First of all, many thanks to the entire team for the ongoing LibreSSL (libcrypto/libssl) efforts - great stuff. Those wishing to verify LibreSSL tarballs can use my portable version of OpenBSD's signify (project I began back in May [1]). It is quite self-contained and doesn't depend on things like libbsd for BSDisms or OpenSSL/LibreSSL for prng seed material. So, I anticipate it should build on many POSIXy systems (tested on Linux and Windows/Cygwin). The latest version was sync'd on 20140902 and includes signify.c rev1.91 and updated support code including tweaks that hopefully make explicit_bzero more resistant to overzealous compilers: http://sf.net/projects/slackdepot/files/signify/signify-portable-20140902.tar.bz2 My example-driven HOWTO should be enough to get one started. --mancha PS A few LibreSSL versions ago, verification worked flawlessly. However, the latest SHA256 digest lists contain full paths (e.g. /home/sign/libressl-2.0.2.tar.gz) which interfere with verification. Mistake? === [1] http://www.linuxquestions.org/questions/slackware-14/openbsd%27s-new-john-hancock-4175504101/
Re: minphys woes
On Tue, Sep 2, 2014 at 2:07 PM, Stefan Fritsch s...@sfritsch.de wrote: On Tuesday 02 September 2014 13:15:19, Philip Guenther wrote: On Tue, Sep 2, 2014 at 12:51 PM, Stefan Fritsch s...@sfritsch.de wrote: On Monday 01 September 2014 22:24:16, David Gwynne wrote: i haven't found a controller that does less than MAXPHYS. perhaps they meant to improve the situation but stopped short. if we wanted to raise MAXPHYS, we'd have to support older controllers that cant do greater than 64k with some mechanism. So the summary of this thread is that - drivers have to support 64K transfers - the minphys mechanism is useless at the moment Useless? It works just fine for physio, which is what it was designed for, no? Not quite what I hoped, but ok. Do you know a good place where this should be documented? minphys is currently documented on physio(9) From physio(9): minphys A device specific routine called to determine the maximum transfer size that the device's strategy routine can handle. Since we have seen that the driver must be able to handle 64k blocks in any case, the fact that minphys is device specific is useless, isn't it? physio() is used by character device access. Looks to me like sdminphys() will change the chunking behavior of this: dd if=/dev/zero of=/dev/rsd0a bs=100M count=1 depending on whether sd0 is a SCSI-I device, no? Philip Guenther
Re: apmd -A induced hangs
On Sun, Aug 31, 2014 at 09:44:11PM +0200, Alexander Bluhm wrote:
On Tue, Jul 29, 2014 at 12:19:43AM +0200, Alexander Bluhm wrote:
Next I will try with this diff and without running apmd.
I was runnig with the diff and without apmd and used sysctl hw.setperf
manually. In this month my thinkpad never crashed.
So I have added apmd -A again to rc.conf now and will report what
happens.
With the diff and with apmd -A I had 2 hangs in less than 3 days.
Next test will be with the diff and with apmd -C on my T430s.
bluhm
Index: acpicpu.c
===
RCS file: /home/cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.60
diff -u -p -r1.60 acpicpu.c
--- acpicpu.c 12 Jul 2014 18:48:17 - 1.60
+++ acpicpu.c 13 Jul 2014 14:00:03 -
@@ -202,9 +202,7 @@ acpicpu_set_pdc(struct acpicpu_softc *sc
static uint8_t cpu_oscuuid[16] = { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29,
0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70,
0x58, 0x71, 0x39, 0x53 };
- cap = ACPI_PDC_C_C1_HALT | ACPI_PDC_P_FFH | ACPI_PDC_C_C1_FFH
- | ACPI_PDC_C_C2C3_FFH | ACPI_PDC_SMP_P_SWCOORD | ACPI_PDC_SMP_C2C3
- | ACPI_PDC_SMP_C1PT;
+ cap = ACPI_PDC_P_FFH | ACPI_PDC_C_C1_FFH;
if (aml_searchname(sc-sc_devnode, _OSC)) {
/* Query _OSC */
OpenBSD 5.6-current (GENERIC.MP) #99: Tue Sep 2 00:52:02 CEST 2014
bluhm@t430s.bluhm.invalid:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16845570048 (16065MB)
avail mem = 16388403200 (15629MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbae9d000 (68 entries)
bios0: vendor LENOVO version G7ET94WW (2.54 ) date 04/30/2013
bios0: LENOVO 2355CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI
UEFI MSDM SSDT SSDT UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.86 MHz
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.42 MHz
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.42 MHz
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.42 MHz
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 4 (EXP3)
acpiprt5 at acpi0: bus 12 (EXP5)
acpiprt6 at acpi0: bus -1 (EXP6)
acpiprt7 at acpi0: bus -1 (EXP7)
acpiprt8 at acpi0: bus -1 (EXP8)
acpicpu0 at acpi0: C3, PSS
acpicpu1 at acpi0: C3
acpicpu2 at acpi0: C3
acpicpu3 at acpi0: C3
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2
acpitz0 at acpi0: critical temperature is 103 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model
