Connect over tcp on the loopback is broken:
4729 amq 0.000007 CALL connect(4,0x804f2a0,0x1c)
4729 amq 75.007420 RET connect -1 errno 60 Connection timed out
allowing rules to be set to match only ipv4/ipv6. And so ipnat must be updated
to actually set this field correctly but to keep things working for old
versions of ipnat (that will set this to 0), make the ioctl handler "update"
the 0 to a 4 to keep things working when people just upgrade kernels. This
forces NAT rule matching to be limited to ipv4 only, here forward, fixing
kern/28662
the root of the file system, and slaves and masters alternate starting
at 3. This means the inode numbers won't be really large until you
really allocate a really lot of ptys.
- Store machine dependent CTRL_LED address in ctrl_led
- Fix LED debug functions to use stored MD values
Actually I only used these debug routines at the very early porting stage
before I got working kernel printf. Heh.
XXX: news1200 has not been tested for many years.
- we should fix genassym.sh to generate proper unsigned values rather than
remove use of such values in each source
- 0xe0dc0000 is port to control LED so INTIOBASE1700_OFF is not proper name
- these LED debug code didn't work on news1200 and it should be fixed anyway
top bit in block addresses.
Also, change some daddr_t->int32_t casts (mostly as arguments to ufs_rw32(),
where they would get promoted anyway) to u_int32_t.
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.
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)
christos