Re: correct includes in man(3) pages
On Tue, Jun 04, 2013 at 07:01:06AM +0200, Ingo Schwarze wrote: > Hi, > > Jan Klemkow wrote on Mon, Jun 03, 2013 at 11:21:39PM +0200: > > > This diff converts all obsolete '.Fd' tags into '.In' tags of manpages > > of category three. I hope this diff is ok so. If something is wrong > > with is, just wrote me and I will fix it. > > Even though .Fd is not wrong, .In is nicer, so i like the idea. > I wouldn't have spent the time to write this patch, > but now that we have it, i'd like to see it go in. > > I have checked it with these commands: > > grep '^-[^-]' tmp.patch | sed 's/^-.Fd #include $//' > > minus.txt > grep '^+[^+]' tmp.patch | sed 's/^+.In //' > plus.txt > diff -u minus.txt plus.txt > > Right now, i cannot easily commit it myself as my man tree is > full of M's. > > So unless jmc@ objects, any developer who wants to should feel > free to commit this with ok schwarze@. > > Thanks, > Ingo i've no objection to the diff. i'm desperately short of time though, so i'm not volunteering to do this myself. having said this, the diff needs checked for more than correctness. it touches at least kerberos, and that is 3rd party. there may be more in there. in the case of kerberos i'd rather that was passed back to the kerberos folks. or it can be introduced as a local change if we feel it's that important - in that case, whoever is managing kerberos for us (robert?) needs to agree. jmc
Re: correct includes in man(3) pages
Hi, Jan Klemkow wrote on Mon, Jun 03, 2013 at 11:21:39PM +0200: > This diff converts all obsolete '.Fd' tags into '.In' tags of manpages > of category three. I hope this diff is ok so. If something is wrong > with is, just wrote me and I will fix it. Even though .Fd is not wrong, .In is nicer, so i like the idea. I wouldn't have spent the time to write this patch, but now that we have it, i'd like to see it go in. I have checked it with these commands: grep '^-[^-]' tmp.patch | sed 's/^-.Fd #include $//' > minus.txt grep '^+[^+]' tmp.patch | sed 's/^+.In //' > plus.txt diff -u minus.txt plus.txt Right now, i cannot easily commit it myself as my man tree is full of M's. So unless jmc@ objects, any developer who wants to should feel free to commit this with ok schwarze@. Thanks, Ingo
Re: ipsec / PF received-on
On Mon, Jun 03, 2013 at 11:49:58PM +0100, Stuart Henderson wrote: > On a router running PF and isakmpd, I have a rule like this: > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > I was surprised to find this being applied to packets received on vlan5 > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets > (as in, generated on the router itself, not actually themselves received on > vlan5) end up getting natted. > > What does anyone else think...expected or not? > Question, would you expect the ipsec packets to match against this rule? match out on pppoe0 inet all received-on enc0 nat-to $someip As in should we change the received interface when we hit ipsec? Think carefully since this path is edged by dragons and deep dark rabbit holes. -- :wq Claudio
Re: ipsec / PF received-on
On 2013/06/04 02:01, Mike Belopuhov wrote: > On 4 June 2013 00:49, Stuart Henderson wrote: > > On a router running PF and isakmpd, I have a rule like this: > > > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > > > I was surprised to find this being applied to packets received on vlan5 > > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) > > packets > > (as in, generated on the router itself, not actually themselves received on > > vlan5) end up getting natted. > > > > What does anyone else think...expected or not? > > > > but if you do the same w/o 'received-on' then packets would get natted > anyways, won't they? it's special to received-on - replace it with 'from 10.15.5.0/24' and the proto esp packets don't get natted. 01:40:23.273366 esp aa.145 > xx.66 spi 0x13800d75 seq 747 len 104 < change pf rule here > 01:40:24.278672 esp aa.146 > xx.66 spi 0x13800d75 seq 748 len 104 On 2013/06/03 17:03, Chris Cappuccio wrote: > Stuart Henderson [s...@spacehopper.org] wrote: > > On a router running PF and isakmpd, I have a rule like this: > > > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > > > I was surprised to find this being applied to packets received on vlan5 > > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) > > packets > > (as in, generated on the router itself, not actually themselves received on > > vlan5) end up getting natted. > > > > What does anyone else think...expected or not? > > From your description, i'd think ipsec should not be processing these packets, > PF should get them first. > oh, there's some other natting too, this probably is a bit of a corner case match out on enc0 from 10.15.5.0/24 to 192.168.40.0/21 nat-to $cip_ip ike esp from $cip_ip (10.15.5.0/24) to 192.168.40.0/21 local $localip peer $peer
Re: ipsec / PF received-on
Stuart Henderson [s...@spacehopper.org] wrote: > On a router running PF and isakmpd, I have a rule like this: > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > I was surprised to find this being applied to packets received on vlan5 > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets > (as in, generated on the router itself, not actually themselves received on > vlan5) end up getting natted. > > What does anyone else think...expected or not? >From your description, i'd think ipsec should not be processing these packets, PF should get them first.
Re: ipsec / PF received-on
On 4 June 2013 00:49, Stuart Henderson wrote: > On a router running PF and isakmpd, I have a rule like this: > > match out on pppoe0 inet all received-on vlan5 nat-to $someip > > I was surprised to find this being applied to packets received on vlan5 > and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets > (as in, generated on the router itself, not actually themselves received on > vlan5) end up getting natted. > > What does anyone else think...expected or not? > but if you do the same w/o 'received-on' then packets would get natted anyways, won't they?
ipsec / PF received-on
On a router running PF and isakmpd, I have a rule like this: match out on pppoe0 inet all received-on vlan5 nat-to $someip I was surprised to find this being applied to packets received on vlan5 and caught by an ipsec flow; the resulting *encapsulated* (proto ESP) packets (as in, generated on the router itself, not actually themselves received on vlan5) end up getting natted. What does anyone else think...expected or not?
RFC 3442 (classless static routes) in dhclient
Anybody encountering dhcp environments that try to server out
classless static routes, i.e. dhcp option 121? Support for
static routes (option 33) thown in for free.
Apparently Microsoft Network Access Protection may be using them.
If so, tests of the diff below would be highly appreciated.
Ken
Index: clparse.c
===
RCS file: /cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.57
diff -u -p -r1.57 clparse.c
--- clparse.c 2 May 2013 16:35:27 - 1.57
+++ clparse.c 2 Jun 2013 15:26:57 -
@@ -72,6 +72,9 @@ read_client_conf(void)
[config->requested_option_count++] = DHO_BROADCAST_ADDRESS;
config->requested_options
[config->requested_option_count++] = DHO_TIME_OFFSET;
+ /* RFC 3442 says CLASSLESS_STATIC_ROUTES must be before ROUTERS! */
+ config->requested_options
+ [config->requested_option_count++] = DHO_CLASSLESS_STATIC_ROUTES;
config->requested_options
[config->requested_option_count++] = DHO_ROUTERS;
config->requested_options
Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.248
diff -u -p -r1.248 dhclient.c
--- dhclient.c 1 Jun 2013 16:26:07 - 1.248
+++ dhclient.c 2 Jun 2013 22:33:35 -
@@ -109,6 +109,8 @@ void socket_nonblockmode(int);
voidapply_ignore_list(char *);
void add_default_route(int, struct in_addr, struct in_addr);
+void add_static_routes(int, struct option_data *);
+void add_classless_static_routes(int, struct option_data *);
#defineROUNDUP(a) \
((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long))
@@ -790,12 +792,21 @@ bind_lease(void)
* is done by the RTM_NEWADDR message being received.
*/
add_address(ifi->name, ifi->rdomain, client->new->address, mask);
- if (options[DHO_ROUTERS].len) {
- memset(&gateway, 0, sizeof(gateway));
- /* XXX Only use FIRST router address for now. */
- memcpy(&gateway.s_addr, options[DHO_ROUTERS].data,
- options[DHO_ROUTERS].len);
- add_default_route(ifi->rdomain, client->new->address, gateway);
+ if (options[DHO_CLASSLESS_STATIC_ROUTES].len) {
+ add_classless_static_routes(ifi->rdomain,
+ &options[DHO_CLASSLESS_STATIC_ROUTES]);
+ } else {
+ if (options[DHO_ROUTERS].len) {
+ memset(&gateway, 0, sizeof(gateway));
+ /* XXX Only use FIRST router address for now. */
+ memcpy(&gateway.s_addr, options[DHO_ROUTERS].data,
+ options[DHO_ROUTERS].len);
+ add_default_route(ifi->rdomain, client->new->address,
+ gateway);
+ }
+ if (options[DHO_STATIC_ROUTES].len)
+ add_static_routes(ifi->rdomain,
+ &options[DHO_STATIC_ROUTES]);
}
client->new->resolv_conf = resolv_conf_contents(
@@ -2280,27 +2291,76 @@ priv_write_file(struct imsg_write_file *
void
add_default_route(int rdomain, struct in_addr addr, struct in_addr gateway)
{
- struct imsg_add_routeimsg;
- int rslt;
-
- memset(&imsg, 0, sizeof(imsg));
+ struct in_addr netmask;
+ int addrs;
- imsg.rdomain = rdomain;
- imsg.dest = addr;
- imsg.addrs = RTA_DST | RTA_NETMASK;
+ memset(&netmask, 0, sizeof(netmask));
+ addrs = RTA_DST | RTA_NETMASK;
/*
* Set gateway address if and only if non-zero addr supplied. A
* gateway address of 0 implies '-iface'.
*/
- if (bcmp(&gateway, &addr, sizeof(addr)) != 0) {
- imsg.gateway = gateway;
- imsg.addrs |= RTA_GATEWAY;
+ if (bcmp(&gateway, &addr, sizeof(addr)) != 0)
+ addrs |= RTA_GATEWAY;
+
+ add_route(rdomain, addr, netmask, gateway, addrs);
+}
+
+void
+add_static_routes(int rdomain, struct option_data *static_routes)
+{
+ struct in_addr dest, netmask, gateway;
+ u_int8_t *addr;
+ int i;
+
+ memset(&netmask, 0, sizeof(netmask)); /* Always 0 for class addrs. */
+
+ for (i = 0; (i + 7) < static_routes->len; i += 8) {
+ addr = &static_routes->data[i];
+ memset(&dest, 0, sizeof(dest));
+ memset(&gateway, 0, sizeof(gateway));
+
+ memcpy(&dest.s_addr, addr, 4);
+ if (dest.s_addr == INADDR_ANY)
+ continue; /* RFC 2132 says 0.0.0.0 is not allowed. */
+ memcpy(&gateway.s_addr, addr+4, 4);
+
+ /* XXX Order implies priority but we're ignoring that. */
+ add_route(rdo
Re: Test needed: ehci(4) suspend/resume rework
> > Ok so, here's an updated diff with the reset enable in the resume case. > > Updated diff after recent ehci(4) changes. > > I'm still looking for non-regression tests. Awesome to see ehci suspend/resume getting some love; I will get to testing this in a few hours.
Re: Fuse (and sshfs) support for OpenBSD
On Mon, Jun 03, 2013 at 12:14:04PM -0400, Ted Unangst wrote: > On Mon, Jun 03, 2013 at 17:14, Sylvestre Gallon wrote: > > You will find in this mail a patch for fuse support in kernel. I will send 2 > > other mails for the userland and the ports patch. There is still work to do > > on my fuse implementation but as I understand there is an hackathon occuring > > at the moment and mpi@ tells me that it could be a good idea to send you > > something before the end of this event, even if my implementation is not > > perfect yet. > > Thank you! I have added all the files, with the sole exception that > the kernel GENERIC config and userland lib Makefile will not be > enabled immediately. > \o/ -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: Fuse (and sshfs) support for OpenBSD
On Mon, Jun 03, 2013 at 17:14, Sylvestre Gallon wrote: > You will find in this mail a patch for fuse support in kernel. I will send 2 > other mails for the userland and the ports patch. There is still work to do > on my fuse implementation but as I understand there is an hackathon occuring > at the moment and mpi@ tells me that it could be a good idea to send you > something before the end of this event, even if my implementation is not > perfect yet. Thank you! I have added all the files, with the sole exception that the kernel GENERIC config and userland lib Makefile will not be enabled immediately.
Re: Fuse (and sshfs) support for OpenBSD
Here is the last patch. It does not differ from last time.
You only need to install sysutils/sshfs and if you have done all the last
tasks well. it will works like that :
root # sshfs user@domainname:/path/to/file /mnt/
Cheers,
Index: sysutils/Makefile
===
RCS file: /cvs/ports/sysutils/Makefile,v
retrieving revision 1.290
diff -u -p -u -p -r1.290 Makefile
--- sysutils/Makefile 22 Apr 2013 06:48:58 - 1.290
+++ sysutils/Makefile 29 Apr 2013 13:50:36 -
@@ -188,6 +188,7 @@
SUBDIR += snapdl
SUBDIR += socket
SUBDIR += socklog
+ SUBDIR += sshfs-fuse
SUBDIR += stan
SUBDIR += stow
SUBDIR += stress
Index: sysutils/sshfs-fuse/Makefile
===
RCS file: sysutils/sshfs-fuse/Makefile
diff -N sysutils/sshfs-fuse/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/sshfs-fuse/Makefile29 Apr 2013 13:50:37 -
@@ -0,0 +1,24 @@
+# $OpenBSD: Makefile,v 1.33 2013/01/09 00:02:15 brad Exp $
+
+COMMENT= Mount remote directories over ssh
+
+VERSION= 2.4
+DISTNAME= sshfs-fuse-${VERSION}
+CATEGORIES=sysutils
+
+HOMEPAGE= http://sshfs.sourceforge.net/
+MASTER_SITES=
http://sourceforge.net/projects/fuse/files/sshfs-fuse/${VERSION}/
+
+MAINTAINER=Gallon Sylvestre
+
+# LGPL
+PERMIT_PACKAGE_CDROM= Yes
+PERMIT_PACKAGE_FTP=Yes
+PERMIT_DISTFILES_FTP= Yes
+
+CONFIGURE_STYLE=gnu
+CONFIGURE_ARGS+= ${CONFIGURE_SHARED}
+WANTLIB= c pthread glib-2.0
+LIB_DEPENDS+= devel/glib2
+
+.include
Index: sysutils/sshfs-fuse/distinfo
===
RCS file: sysutils/sshfs-fuse/distinfo
diff -N sysutils/sshfs-fuse/distinfo
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/sshfs-fuse/distinfo29 Apr 2013 13:50:37 -
@@ -0,0 +1,2 @@
+SHA256 (sshfs-fuse-2.4.tar.gz) = PJO6hSJWgJPJT/nFo3Y5KTgN0ik2XZBXaf+CR113TdE=
+SIZE (sshfs-fuse-2.4.tar.gz) = 132930
Index: sysutils/sshfs-fuse/patches/patch-sshfs_c
===
RCS file: sysutils/sshfs-fuse/patches/patch-sshfs_c
diff -N sysutils/sshfs-fuse/patches/patch-sshfs_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/sshfs-fuse/patches/patch-sshfs_c 29 Apr 2013 13:50:37 -
@@ -0,0 +1,27 @@
+--- sshfs.c.orig Thu Mar 8 10:34:39 2012
sshfs.cFri Mar 29 10:37:09 2013
+@@ -11,7 +11,6 @@
+
+ #include
+ #include
+-#include
+ #include
+ #include
+ #include
+@@ -32,6 +31,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -1543,7 +1543,7 @@ static int sftp_error_to_errno(uint32_t error)
+ case SSH_FX_NO_SUCH_FILE: return ENOENT;
+ case SSH_FX_PERMISSION_DENIED: return EACCES;
+ case SSH_FX_FAILURE: return EPERM;
+- case SSH_FX_BAD_MESSAGE: return EBADMSG;
++ case SSH_FX_BAD_MESSAGE: return ENOMSG;
+ case SSH_FX_NO_CONNECTION: return ENOTCONN;
+ case SSH_FX_CONNECTION_LOST: return ECONNABORTED;
+ case SSH_FX_OP_UNSUPPORTED:return EOPNOTSUPP;
Index: sysutils/sshfs-fuse/pkg/DESCR
===
RCS file: sysutils/sshfs-fuse/pkg/DESCR
diff -N sysutils/sshfs-fuse/pkg/DESCR
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/sshfs-fuse/pkg/DESCR 29 Apr 2013 13:50:37 -
@@ -0,0 +1 @@
+SSHFS allows you to mount a remote directory over a normal ssh connection.
Index: sysutils/sshfs-fuse/pkg/PLIST
===
RCS file: sysutils/sshfs-fuse/pkg/PLIST
diff -N sysutils/sshfs-fuse/pkg/PLIST
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/sshfs-fuse/pkg/PLIST 29 Apr 2013 13:50:37 -
@@ -0,0 +1,3 @@
+@comment $OpenBSD$
+@bin bin/sshfs
+@man man/man1/sshfs.1
More Secrets of Buffer Cache Enlargement.
Here's a new version of the buffer flipper that fixes
a problem found by krw@. - All comments from before still apply:
> You too can have a GIANT buffer cache etc. etc...
>
> After much bug fighting in the midlayer and now uvm over the last 6
> months in a number of places, I think it's about time to shop this
> around again.
>
> This will only make a difference on amd64 - if you have 4 GB or more
> of RAM. What it does is allows the high (non-DMA reachable) memory to
> be used for buffer cache pages. It will use your set buffer
> cache percentage of both dma'able, and above dma'able pages for the
> cache, migrating the oldest cache pages into high memory. pages
> are flipped back into dma'able memory if they are needed for IO.
>
> Notwithstanding that it only "matters" on amd64, it does change how
> the world works a bit, and therefore requires testing everywhere. It
> has survived multiple make build/make release test cycles now on my
> machines (amd64,i386,zaurus,sparc,sparc64,hppa) (with various settings
> of bufcachepercent) and is running on my NFS server
> (bufcachepercent=90) without any complaints throughout that - it's
> been running on my laptop for a long time now.
>
> If you try it, and have troubles (i.e. any new regressions), please
> ensure you have your machine's console accessible (check to see if you
> have ddb.console=1 in /etc/sysctl.conf) and if you have problems
> please try to get
>
>
> trace
> ps
> show bcstats
> show uvm
>
> from ddb if at all possible.
>
> Please let me know how you do with it, and most importantly what
> you try it on/with.
>
-Bob
(diff also in ~beck/viagra.diff14 on cvs)
Index: sys/kern/kern_sysctl.c
===
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.234
diff -u -p -r1.234 kern_sysctl.c
--- sys/kern/kern_sysctl.c 6 Apr 2013 03:44:34 - 1.234
+++ sys/kern/kern_sysctl.c 3 Jun 2013 14:51:14 -
@@ -110,6 +110,7 @@ extern struct disklist_head disklist;
extern fixpt_t ccpu;
extern long numvnodes;
extern u_int mcllivelocks;
+extern psize_t b_dmapages_total, b_highpages_total, b_dmamaxpages;
extern void nmbclust_update(void);
@@ -564,8 +565,8 @@ kern_sysctl(int *name, u_int namelen, vo
return (sysctl_cptime2(name + 1, namelen -1, oldp, oldlenp,
newp, newlen));
case KERN_CACHEPCT: {
- u_int64_t dmapages;
- int opct, pgs;
+ psize_t pgs;
+ int opct;
opct = bufcachepercent;
error = sysctl_int(oldp, oldlenp, newp, newlen,
&bufcachepercent);
@@ -575,9 +576,11 @@ kern_sysctl(int *name, u_int namelen, vo
bufcachepercent = opct;
return (EINVAL);
}
- dmapages = uvm_pagecount(&dma_constraint);
if (bufcachepercent != opct) {
- pgs = bufcachepercent * dmapages / 100;
+ pgs = (b_highpages_total + b_dmapages_total)
+ * bufcachepercent / 100;
+ b_dmamaxpages = b_dmapages_total * bufcachepercent
+ / 100;
bufadjust(pgs); /* adjust bufpages */
bufhighpages = bufpages; /* set high water mark */
}
Index: sys/kern/spec_vnops.c
===
RCS file: /cvs/src/sys/kern/spec_vnops.c,v
retrieving revision 1.71
diff -u -p -r1.71 spec_vnops.c
--- sys/kern/spec_vnops.c 28 Mar 2013 03:29:44 - 1.71
+++ sys/kern/spec_vnops.c 3 Jun 2013 14:51:14 -
@@ -457,7 +457,9 @@ spec_strategy(void *v)
struct vop_strategy_args *ap = v;
struct buf *bp = ap->a_bp;
int maj = major(bp->b_dev);
-
+
+ if (!ISSET(bp->b_flags, B_DMA) && ISSET(bp->b_flags, B_BC))
+ panic("bogus buf %p passed to spec_strategy", bp);
if (LIST_FIRST(&bp->b_dep) != NULL)
buf_start(bp);
Index: sys/kern/vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.146
diff -u -p -r1.146 vfs_bio.c
--- sys/kern/vfs_bio.c 17 Feb 2013 17:39:29 - 1.146
+++ sys/kern/vfs_bio.c 3 Jun 2013 14:59:18 -
@@ -63,12 +63,17 @@
/*
* Definitions for the buffer free lists.
*/
-#defineBQUEUES 2 /* number of free buffer queues
*/
+#defineBQUEUES 3 /* number of free buffer queues
*/
#defineBQ_DIRTY0 /* LRU queue with dirty buffers
*/
-#defineBQ_CLEAN1 /* LRU queue with clean buffers
*/
+#defineBQ_CLEANL 1 /* LRU queue with clean low
buffers */
+#defineBQ_CLEANH 2 /* LRU queue with
Re: Test needed: ehci(4) suspend/resume rework
On 02/05/13(Thu) 09:41, Martin Pieuchot wrote:
> On 01/05/13(Wed) 17:44, Ted Unangst wrote:
> > On Sun, Apr 28, 2013 at 15:44, Martin Pieuchot wrote:
> > > Diff below is a rework of the suspend/resume logic in ehci(4).
> > >
> >
> > > In case this diff doesn't help or if you have a problem when resuming,
> > > I left an "#ifdef 0" block in the DVACT_RESUME. Try enabling it and tell
> > > me if it changes something.
> >
> > Got around to testing this. Now everything works. It still prints
> > echi_idone about 100 times after resume, but it doesn't print it
> > forever.
> >
> > I'd say the diff works, but only with the reset in the resume case as
> > well.
>
> Ok so, here's an updated diff with the reset enable in the resume case.
Updated diff after recent ehci(4) changes.
I'm still looking for non-regression tests.
Index: dev/usb/ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.133
diff -u -p -r1.133 ehci.c
--- dev/usb/ehci.c 30 May 2013 16:15:02 - 1.133
+++ dev/usb/ehci.c 3 Jun 2013 13:49:17 -
@@ -353,22 +353,10 @@ ehci_init(struct ehci_softc *sc)
sc->sc_bus.usbrev = USBREV_2_0;
- /* Reset the controller */
DPRINTF(("%s: resetting\n", sc->sc_bus.bdev.dv_xname));
- EOWRITE4(sc, EHCI_USBCMD, 0); /* Halt controller */
- usb_delay_ms(&sc->sc_bus, 1);
- EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET);
- for (i = 0; i < 100; i++) {
- usb_delay_ms(&sc->sc_bus, 1);
- hcr = EOREAD4(sc, EHCI_USBCMD) & EHCI_CMD_HCRESET;
- if (!hcr)
- break;
- }
- if (hcr) {
- printf("%s: reset timeout\n",
- sc->sc_bus.bdev.dv_xname);
- return (USBD_IOERROR);
- }
+ err = ehci_reset(sc);
+ if (err)
+ return (err);
/* frame list size at default, read back what we got and use that */
switch (EHCI_CMD_FLS(EOREAD4(sc, EHCI_USBCMD))) {
@@ -1033,6 +1021,8 @@ ehci_detach(struct ehci_softc *sc, int f
timeout_del(&sc->sc_tmo_intrlist);
+ ehci_reset(sc);
+
usb_delay_ms(&sc->sc_bus, 300); /* XXX let stray task complete */
/* XXX free other data structures XXX */
@@ -1045,7 +1035,7 @@ int
ehci_activate(struct device *self, int act)
{
struct ehci_softc *sc = (struct ehci_softc *)self;
- u_int32_t cmd, hcr;
+ u_int32_t cmd, hcr, cparams;
int i, rv = 0;
switch (act) {
@@ -1056,95 +1046,74 @@ ehci_activate(struct device *self, int a
rv = config_activate_children(self, act);
sc->sc_bus.use_polling++;
- for (i = 1; i <= sc->sc_noport; i++) {
- cmd = EOREAD4(sc, EHCI_PORTSC(i));
- if ((cmd & (EHCI_PS_PO|EHCI_PS_PE)) == EHCI_PS_PE)
- EOWRITE4(sc, EHCI_PORTSC(i),
- cmd | EHCI_PS_SUSP);
- }
-
- sc->sc_cmd = EOREAD4(sc, EHCI_USBCMD);
- cmd = sc->sc_cmd & ~(EHCI_CMD_ASE | EHCI_CMD_PSE);
+ /*
+* First tell the host to stop processing Asynchronous
+* and Periodic schedules.
+*/
+ cmd = EOREAD4(sc, EHCI_USBCMD) & ~(EHCI_CMD_ASE | EHCI_CMD_PSE);
EOWRITE4(sc, EHCI_USBCMD, cmd);
-
for (i = 0; i < 100; i++) {
+ usb_delay_ms(&sc->sc_bus, 1);
hcr = EOREAD4(sc, EHCI_USBSTS) &
(EHCI_STS_ASS | EHCI_STS_PSS);
if (hcr == 0)
break;
-
- usb_delay_ms(&sc->sc_bus, 1);
}
if (hcr != 0)
- printf("%s: reset timeout\n",
+ printf("%s: disable schedules timeout\n",
sc->sc_bus.bdev.dv_xname);
- cmd &= ~EHCI_CMD_RS;
- EOWRITE4(sc, EHCI_USBCMD, cmd);
-
- for (i = 0; i < 100; i++) {
- hcr = EOREAD4(sc, EHCI_USBSTS) & EHCI_STS_HCH;
- if (hcr == EHCI_STS_HCH)
- break;
-
- usb_delay_ms(&sc->sc_bus, 1);
- }
- if (hcr != EHCI_STS_HCH)
- printf("%s: config timeout\n",
- sc->sc_bus.bdev.dv_xname);
+ /*
+* Then reset the host as if it was a shutdown.
+*
+* All USB devices are disconnected/reconnected during
+* a suspend/resume cycle so keep it simple.
+*/
+ ehci_reset(sc);
sc->sc_bus.use_polling--;
break;
case DVACT_POWERDOWN:
rv = config_activate_children(self,
