| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
same pnpbios id
|
| |
|
| |
|
| |
|
|
|
|
| |
with IPv6 loopback addr for its dest or src addr as ours.
|
| |
|
| |
|
|
|
|
| |
on newer alpha workstations and servers
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
packets into a single buffer, and set the DC_TX_COALESCE flag for the
Davicom DM9102 chip. I thought I had escaped this problem, but... This
chip appears to silently corrupt or discard transmitted frames when
using scatter/gather DMA (i.e. DMAing each packet fragment in place
with a separate descriptor). The only way to insure reliable transmission
is to coalesce transmitted packets into a single cluster buffer. (There
may also be an alignment constraint here, but mbuf cluster buffers are
naturally aligned on 2K boundaries, which seems to be good enough.)
The DM9102 driver for Linux written by Davicom also uses this workaround.
Unfortunately, the Davicom datasheet has no errata section describing
this or any other apparently known defect.
Problem noted by: allan_chou@davicom.com.tw
|
|
|
|
| |
Submitted by: gibbs
|
|
|
|
|
|
|
|
|
|
| |
drive the transmitter, we have to check the interface's send queue in the
TX end of frame handler (i.e. the usb bulk out callback) and push out new
transmissions if the queue has packets in it and the transmitter is
ready. But the txeof handler is also called from a USB callback running
at splusb() too.
Grrr.
|
| |
|
| |
|
|
|
|
|
|
| |
ioctl.
By popular demand.
|
| |
|
|
|
|
| |
kicking but these changes get me around 1000 KB/sec.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use IFQ_MAXLEN instead. This seemed like a good idea at the time since
most 3c509s have all of 2k for their TX fifo. My intention was to revisit
ifq_maxlen and auto-scale it or something.
ttcp-t: 16777216 bytes in 21.53 real seconds = 761.07 KB/sec +++
ttcp-t: 2771 I/O calls, msec/call = 7.96, calls/sec = 128.72
ttcp-t: 0.0user 2.9sys 0:21real 13% 20i+280d 222maxrss 0+2pf 717+0csw
ttcp-r: 16777216 bytes in 14.11 real seconds = 1161.48 KB/sec +++
ttcp-r: 2050 I/O calls, msec/call = 7.05, calls/sec = 145.33
ttcp-r: 0.0user 1.4sys 0:14real 10% 87i+1198d 196maxrss 0+1pf 1949+186csw
I've got some tweaks that move the TX speed up to the RX speed but I've
got to groom them from the mess I've made of my source tree.
Yelled at by: wpaul
|
| |
|
|
|
|
| |
subtract the length of the SNAP header).
|
| |
|
|
|
|
| |
have no multicast entries to add is not handled right).
|
|
|
|
|
| |
Make the alpha linker script more like the i386 version - delete the
/usr/local and egcs directories
|
|
|
|
|
|
|
| |
with the intended changes.
Drop db_aout.c from files, let db_kld.c do the work.
Noticed by: bde
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ddb is entered. Don't refer to `in_Debugger' to see if we
are in the debugger. (The variable used to be static in Debugger()
and wasn't updated if ddb is entered via traps and panic anyway.)
- Don't refer to `in_Debugger'.
- Add `db_active' to i386/i386/db_interface.d (as in
alpha/alpha/db_interface.c).
- Remove cnpollc() stub from ddb/db_input.c.
- Add the dbctl function to syscons, pcvt, and sio. (The function for
pcvt and sio is noop at the moment.)
Jointly developed by: bde and me
(The final version was tweaked by me and not reviewed by bde. Thus,
if there is any error in this commit, that is entirely of mine, not
his.)
Some changes were obtained from: NetBSD
|
|
|
|
|
| |
misunderstanding between the PR originator and me. I hope I got it
right this time.
|
| |
|
|
|
|
|
| |
Always use db_kld.c for symbol table support as the base kernel maintains
this information.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem occurs when an indirect block and a data block are
being allocated at the same time. For example when the 13th block
of the file is written, the filesystem needs to allocate the first
indirect block and a data block. If the indirect block allocation
succeeds, but the data block allocation fails, the error code
dellocates the indirect block as it has nothing at which to point.
Unfortunately, it does not deallocate the indirect block's associated
dependencies which then fail when they find the block unexpectedly
gone (ptr == 0 instead of its expected value). The fix is to fsync
the file before doing the block rollback, as the fsync will flush
out all of the dependencies. Once the rollback is done the file
must be fsync'ed again so that the soft updates code does not find
unexpected changes. This approach is much slower than writing the
code to back out the extraneous dependencies, but running out of
disk space is not expected to be a common occurence, so just getting
it right is the main criterion.
PR: kern/15063
Submitted by: Assar Westerlund <assar@stacken.kth.se>
|
|
|
|
|
|
| |
have been cleaned up by deallocte_dependencies(). Once that is done, it
is safe to post the request to free the blocks. A similar change is also
needed for the freefile case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Packets are received inside USB bulk transfer callbacks, which run at
splusb() (actually splbio()). The packet input queues are meant to be
manipulated at splimp(). However the locking apparently breaks down under
certain circumstances and the input queues can get trampled.
There's a similar problem with if_ppp, which is driven by hardware/tty
interrupts from the serial driver, but which must also manipulate the
packet input queues at splimp(). The fix there is to use a netisr, and
that's the fix I used here. (I can hear you groaning back there. Hush up.)
The usb_ethersubr module maintains a single queue of its own. When a
packet is received in the USB callback routine, it's placed on this
queue with usb_ether_input(). This routine also schedules a soft net
interrupt with schednetisr(). The ISR routine then runs later, at
splnet, outside of the USB callback/interrupt context, and passes the
packet to ether_input(), hopefully in a safe manner.
The reason this is implemented as a separate module is that there are
a limited number of NETISRs that we can use, and snarfing one up for
each driver that needs it is wasteful (there will be three once I get
the CATC driver done). It also reduces code duplication to a certain
small extent. Unfortunately, it also needs to be linked in with the
usb.ko module in order for the USB ethernet drivers to share it.
Also removed some uneeded includes from if_aue.c and if_kue.c
Fix suggested by: peter
Not rejected as a hairbrained idea by: n_hibma
|
| |
|
| |
|
|
|
|
| |
implemented as dummies to ease problem solving.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This fixes page fault panic observed when diverting packets
with IP options (e.g. ping -R remoteIP over natd).
PR: kern/8596, kern/11199
|
|
|
|
| |
with linux_base-6.1.
|
| |
|
| |
|
|
|
|
| |
PR: 15956
|
| |
|
|
|
|
| |
Suggested by: bde
|
|
|
|
|
|
| |
an infinite loop if a signal is delivered here.
remove it again, this still ought to be revisited as the error should
probably be returned.
|
|
|
|
| |
possible.
|
| |
|
|
|
|
|
| |
the vga driver won't be fooled to believe it has a CGA card when
in fact it is a VGA card.
|
|
|
|
| |
. s/freebsd/FreeBSD
|
|
|
|
| |
- Remove erroneous comments.
|