Some ATAPI device never get out of busy if touched too fast after a reset.
Delay value from atapi_wdc.c; fix problem reported by Nicolas Joly on
current-users.
warning is triggered pervasively, so print it only once per boot.
(The callers who pass NULL r_procps should soon be fixed to pass a
valid struct proc* ).
Descriptions are not very good because the only documentation I have
says "the VID and PID may be one of these combinations", without any
additional information about the differences or even model names.
go via the normal filter setup path instead. The old behaviour only
worked ok as long as the init function was exclusively called at attach
time, when there was no configuration to be lost.
From Christian Weisgerber in private mail.
Note: While this is technically an ABI change I believe it is a
change that we can afford at this time (and to be pulled up to
2.0, which will be the first release for amd64). The types are
not widely used yet, and a survey of pkgsrc has not shown uses
that would be adversely affected by it.
otherwise we can be stuck in soreceive forever.
the problem is pointed by Minoura Makoto. PR/25662
- clear r_rexmit on reconnect and clear r_rtt and R_TIMING on retransmit
so that the above (and soft mounts) happy.
Add a new explicit `struct proc *p' argument to socreate(), sosend().
Use that argument instead of curproc. Follow-on changes to pass that
argument to socreate(), sosend(), and (*so->so_send)() calls.
These changes reviewed and independently recoded by Matt Thomas.
Changes to soreceive() and (*dom->dom_exernalize() from Matt Thomas:
pass soreceive()'s struct uio* uio->uio_procp to unp_externalize().
Eliminate curproc from unp_externalize. Also, now soreceive() uses
its uio->uio_procp value, pass that same value downward to
((pr->pru_usrreq)() calls for consistency, instead of (struct proc * )0.
Similar changes in sys/nfs to eliminate (most) uses of curproc,
either via the req-> r_procp field of a struct nfsreq *req argument,
or by passing down new explicit struct proc * arguments.
Reviewed by: Matt Thomas, posted to tech-kern.
NB: The (*pr->pru_usrreq)() change should be tested on more (all!) protocols.
width implementation was a rather poor choice. Per discussion with
Charles Hannum.
Note: While this is technically an ABI change I believe it is a
change that we can afford at this time (and to be pulled up to
2.0). The types are not widely used yet, and a survey of pkgsrc
has not shown uses that would be adversely affected by it.
