Age | Commit message (Collapse) | Author |
|
more, so zap the special treatment for EEXIST
|
|
periodic scans:
-keep a tree of nexthops with valid/invalid flags
-provide kroute_match, which takes an IP address and gives the kernel route
for that
-find the kernel route for a given nexthop with that
-keep a marker on the kernel route that a nexthop depends on it
-on removal of the kernel route, re-evaluate the affected nexthops for
validity.
ok claudio@
|
|
|
|
affecting a multiuser boot.
|
|
rolling their own.
Use them more cleverly in vx, in order to get the driver to at least attach
and frob chips. Not tested besides multiuser boot (hence ttyflags -a), and
checking cu(1) connects. More testing to come once I remember where I have
hidden the 332XT transition module...
|
|
|
|
|
|
|
|
ok deraadt@
|
|
again on reload
|
|
|
|
A bit icky, but binutils includes contain both libiberty stuff and its
own stuff...
|
|
|
|
|
|
Restore comment that was lost.
|
|
|
|
|
|
|
|
|
|
o free(sym)
|
|
|
|
|
|
|
|
|
|
ok claudio@
|
|
|
|
|
|
neighbor system
|
|
there's a small probability that poll() announces us a new connection on the
listening socket that vanishes before we can call accept(), and thus accept()
would block.
|
|
if we're in state ACTIVE and get an TIMER_CONNRETRY event, we need to
change the state to CONNECT _before_ we call session_connect() to attempt
a connect, as session_connect can generate events that caus further state
changes.
as far as i saw that it only causes a bit confusion for sessions dangling
between CONNECT and ACTIVE all the time without causing real trouble, but bugs
are bugs, right.
|
|
|
|
ok otto@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
added prefix in the kernel routing table. if yes and inserted by us change
action from ADD to CHANGE, if not added by us do not add or change that
prefix.
|
|
|
|
|
|
|
|
|
|
|
|
by software, so be sure to set them both the precise _and imprecise_ floating
point exception handlers, whatever the state of the HANDLER define is (which
is anyway, soon to be hitting the dust in a cvs tree near you...)
This allows userland software to really trust fpgetsticky() results.
|
|
few places, requested by theo
|
|
Renauld of Network Storage Solutions, Inc. Many fixes, wider device
support. In particular, the notorious 'Target 0' problem seems to be
fixed.
Does *not* include any updates to isa or eisa code beyond what was
necessary to compile.
Known issues:
1) Tagged Queuing is probably not optimal.
2) PPR negotiation may not be fully functional.
3) No support yet for freezing devices or channels.
4) The mechanism for preventing 'A' and 'B' channel confusion during probe
can fail if scsibus > 254 found.
5) Requeuing I/O's not working. A workaround will be committed almost
immediately. At the moment timeouts, SCSI message rejects, aborting
SCB's and trying to freeze a device may cause incomplete i/o's to be
reported as complete.
6) Verbosity and probe messages need work.
7) Last disk on bus seems to go through an extra re-negotiation.
8) >16 devices on an adapter will trigger the usual problems of total
openings exceeding available SCB's under heavy load.
Tested by deraadt@, beck@, miod@, naddy@, drahn@, marc@ amoung
others.
ok deraadt@.
|
|
Renauld of Network Storage Solutions, Inc. Many fixes, wider device
support. In particular, the notorious 'Target 0' problem seems to be
fixed.
Does *not* include any updates to isa or eisa code beyond what was
necessary to compile.
Known issues:
1) Tagged Queuing is probably not optimal.
2) PPR negotiation may not be fully functional.
3) No support yet for freezing devices or channels.
4) The mechanism for preventing 'A' and 'B' channel confusion during probe
can fail if scsibus > 254 found.
5) Requeuing I/O's not working. A workaround will be committed almost
immediately. At the moment timeouts, SCSI message rejects, aborting
SCB's and trying to freeze a device may cause incomplete i/o's to be
reported as complete.
6) Verbosity and probe messages need work.
7) Last disk on bus seems to go through an extra re-negotiation.
8) >16 devices on an adapter will trigger the usual problems of total
openings exceeding available SCB's under heavy load.
Tested by deraadt@, beck@, miod@, naddy@, drahn@, marc@ amoung
others.
ok deraadt@.
|
|
Renauld of Network Storage Solutions, Inc. Many fixes, wider device
support. In particular, the notorious 'Target 0' problem seems to be
fixed.
Does *not* include any updates to isa or eisa code beyond what was
necessary to compile.
Known issues:
1) Tagged Queuing is probably not optimal.
2) PPR negotiation may not be fully functional.
3) No support yet for freezing devices or channels.
4) The mechanism for preventing 'A' and 'B' channel confusion during probe
can fail if scsibus > 254 found.
5) Requeuing I/O's not working. A workaround will be committed almost
immediately. At the moment timeouts, SCSI message rejects, aborting
SCB's and trying to freeze a device may cause incomplete i/o's to be
reported as complete.
6) Verbosity and probe messages need work.
7) Last disk on bus seems to go through an extra re-negotiation.
8) >16 devices on an adapter will trigger the usual problems of total
openings exceeding available SCB's under heavy load.
Tested by deraadt@, beck@, miod@, naddy@, drahn@, marc@ amoung
others.
ok deraadt@.
|
|
Renauld of Network Storage Solutions, Inc. Many fixes, wider device
support. In particular, the notorious 'Target 0' problem seems to be
fixed.
Does *not* include any updates to isa or eisa code beyond what was
necessary to compile.
Known issues:
1) Tagged Queuing is probably not optimal.
2) PPR negotiation may not be fully functional.
3) No support yet for freezing devices or channels.
4) The mechanism for preventing 'A' and 'B' channel confusion during probe
can fail if scsibus > 254 found.
5) Requeuing I/O's not working. A workaround will be committed almost
immediately. At the moment timeouts, SCSI message rejects, aborting
SCB's and trying to freeze a device may cause incomplete i/o's to be
reported as complete.
6) Verbosity and probe messages need work.
7) Last disk on bus seems to go through an extra re-negotiation.
8) >16 devices on an adapter will trigger the usual problems of total
openings exceeding available SCB's under heavy load.
Tested by deraadt@, beck@, miod@, naddy@, drahn@, marc@ amoung
others.
ok deraadt@.
|