subroutine wi_txcmd_wait from wi_cmd and wi_stop.
This stops wi from griping, "wi0: command timed out, cmd=0x10b,
arg=0x0", when we down/up the interface. Thanks to Pavel Cahyna
for reporting this bug.
around a cngetc() that will never return while "halted", which is rude,
and which also requires domain 0 to not just restart us, but kill us
first. Suggestion from Michael Kukat (though this change is not the
same as the one he suggested).
Will cngetc() actually return something when running in domain 0 with a
VGA console? I don't think it will; if it actually does, we should make
this behaviour depend on whether we're in domain 0 or some other domain.
This way we save a mess of #ifdefs. XXX: This code is disgusting. Drivers
should not communicate with the rest of the kernel by means of global variables.
vp->v_specinfo to get the proper st_dev and st_rdev numbers. We're
already picking over the kernel, so let's do it right. That means
also asserting the file type for the /dev/pts directory (S_IFDIR) and
nodes therein (S_IFCHR).
Remove getptsmajor(), since we no longer need it. Besides, it was
being used wrongly.
After receiving the magic 10-line incantation from Christos for
re-building the autoconf stuff, attempt to do so. This might fix
the problem, or might not. That is why this stuff is so fun.
does different things depending what's in %ebx.
We weren't setting %ebx here *at all*; so we did not get SCHEDOP_yield,
which was what was wanted; so unpredictable things happened, notably
immediate return to the NetBSD idle loop, in other words spinning on CPU.
Definitely not cool!
Michael Kukat caught this one and suggested this fix on port-xen.
Following Charles Hannum's wi(4) optimizations, there could be a
Transmit command outstanding after wi_tx_intr or wi_start returns.
The driver would blithely issue a second command [*] before the
first command was finished, taking the first command's WI_EV_CMD
indication to mean the second command had finished. The driver
would be dreadfully confused when the second command's results did
not meet its expectations (e.g., a RID mismatch error would occur).
The packet transmit section of the code would never read the
WI_EV_CMD it expected, so transmissions would cease.
This patch counts the outstanding transmit commands (there can be
only one) and, if a transmit command is outstanding at the top of
wi_cmd(), wi_cmd waits for the command to complete. If there was
a transmit command outstanding when wi_cmd begins, it calls
wi_cmd_intr() on its way out.
I have tested this on an Orinoco card. Previously, the card would
stop transmitting or the kernel would panic as desynchronization
occurred. Now it works beautifully.
[*] A second command could be issued by wi_ioctl or else by
wi_intr->wi_info_intr->wi_newstate->wi_read_xrid->wi_read_rid.
wi_read_rid(sc, rid, &val, &buflen) == 0 && buflen == sizeof(val),
become wi_read_xrid calls
wi_read_xrid(sc, rid, &val, sizeof(val)) == 0.
If the actual RID length is different from the expected RID length,
wi_read_rid prints to the log.
Originally written by rafal@ back in April 2003. Field-tested by many
people since.
(I am not committing the pmap hack at this time; although pmap changes are
necessary to fully address the r5k panic/coma problems, the implementation
needs further thought)
