| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
Expect caller to lock before calling sis_stop()
Various style stuff.
|
| |
|
| |
|
| |
|
|
|
|
| |
implemented "sis_nextdesc" pointer to keep a pointer instead.
|
|
|
|
|
|
|
| |
their fields directly in the softc structure.
This is a no-op which shortens most of the affected source lines
by N * 10 characters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
3C920B-EMB-WNM Integrated Fast Ethernet Controller
Submitter reports that the card appears to autonegotiate properly, and
operate well with high levels of NFS traffic.
PR: 75253
Submitted by: "Oleg V. Nauman" <oleg at reis dot zp dot ua>
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
| |
generic bridge support was biting us more than it helped, whenever a new chipset
came out from a vendor and misprogramming it caused strange hangs or corruption.
[2] Add a large number of PCI IDs based on what the linux drivers support.
Note that the new PCI IDs haven't been tested, they're just *likely* to work.
In particular the VIA AGP 8x chipsets are concerning, due to lack of testing,
possible issues (kern/69953), and not having a nice "does this bridge say it
would do 8x" function. However, this shouldn't make the situation worse, since
these chips would have probed in the past anyway.
|
|
|
|
|
| |
Thoroughly tested by: Ender <ender NO tog SPAM net>
MFC after: 4 weeks
|
|
|
|
|
|
|
|
|
|
| |
In contrast to OpenBSD we enable jumbo frame support
depending on MTU setting (like done for xmac).
Approved by: pjd (mentor)
Obtained from: OpenBSD if_sk.c r1.52 (YU_SMR_MFL_JUMBO flag)
Tested by: Heinz Knocke <knockefreebsd at o2 dot pl>
MFC after: 5 days
|
|
|
|
|
|
|
|
|
|
|
|
| |
zero-copy receive of jumbo frames. This eliminates the need for the
jumbo frame allocator implemented in kern/uipc_jumbo.c and sys/jumbo.h.
Remove it.
Note: Zero-copy receive of jumbo frames did not work without these changes;
I believe there was insufficient locking on the jumbo vm object.
Tested by: ken@
Discussed with: gallatin@
|
|
|
|
| |
- Avoid LOR in pcn_probe() by removing useless mutex stuff.
|
|
|
|
|
|
| |
- Initialize sc->pcn_type during ATTACH as softc contents may not surivive
from PROBE.
- Print out chip-id to assist with ongoing pcn(4) debugging efforts.
|
|
|
|
| |
Obtained from: NetBSD
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
queue a packet to the hardware... instead of when the hardware queue is
empty..
don't initalize cur_tx now that it doesn't need to be...
Pointed out by: bde
|
|
|
|
|
|
| |
panic...
Pointed out by: Bjoern A. Zeeb
|
|
|
|
|
|
|
|
| |
also fix up handling and proding of the tx, _OACTIVE is now handled
better...
Submitted by: Peter Edwards (sk_jfree)
Obtained from: OpenBSD and/or NetBSD (tx prod)
|
|
|
|
|
|
|
|
|
| |
but sk(4) is so prevalent on AMD64 motherboards we need to reduce the number
of round trips in the mailing lists trying to get sufficient information to
make sure we've got a handle on all the problems and are working towards
making sk(4) solid.
Submitted by: bz
|
|
|
|
|
|
|
|
|
|
| |
hardcoded 128k for Yukon devices. 88E8001 only has 64k of on-chip RAM[1].
[1] http://www.marvell.com/products/pcconn/yukon/Yukon_88E8001_10_073103_final.pdf
Tested by: amd64, current
Approved by: rwatson (mentor)
MFC after: 1 week
|
|
|
|
|
|
|
| |
Patch by mlaier.
Approved by: mlaier
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
Original patch by me, improvements by ru
Happy birthday to: BSDforen.de!
Approved by: ru
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
| |
sensitive, but less excercised location (the watchdog). While here use the
*_start_locked function directly to avoid drop, grab, drop lock.
I have to be very careful with future ALTQ patches!
Found & reviewed by: rwatson
MFC after: 3 days
|
|
|
|
|
|
|
| |
* Announce some more fields from ro area for better debugging of broken
sk(4)s on various boards.
Submitted by: Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the device is suspended or shutting down. This will need to be rethought
slightly if we implement suspend/resume support within vr(4).
This appears to fix the vr_shutdown() panic on SMP machines.
My theory here is there's a race somewhere during vr_detach() with
vr_intr() in the SMP case which was sometimes being triggered,
although quite why this was happening is unclear (vr_stop() also
explicitly disables interrupts by writing to the IMR register).
MFC-to-RELENG_5* candidate.
PR: kern/62889
Tested by: seb at struchtrup dot com
MFC after: 10 days
|
|
|
|
|
|
|
|
| |
detach; triggered by ether_ifdetach() -> if_delmulti() -> vr_ioctl().
MFC candidate.
PR: kern/62889
MFC after: 3 days
|
|
|
|
| |
synchronization that one entails.
|
|
|
|
|
|
| |
two loops in agp_generic_bind_memory(). As an intended side-effect, all
of the calls to vm_page_wakeup() are now performed with the containing
vm object lock held.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
as the original logic did. This fixes a race with vr_intr() which was
masked on UP systems and manifested on SMP systems.
PR: kern/62889
MFC after: 1 day
|
|
|
|
|
|
|
| |
(usually taking 20 seconds to transmit a packet).. no longer fall back
to only transmitting one packet (instead of the entire queue) after we
have processed the entire send queue... I have no idea why we didn't
start seeing this problem ~6 years ago when this code was introduced...
|
|
|
|
|
|
|
| |
Do not tell the hardware to send when there were no packets enqueued.
Found and reviewed by: green
MFC after: 1 days
|
|
|
|
| |
enabled, but not 3D.
|
|
|
|
|
|
|
|
|
|
| |
is a no-op on little endian architectures, but fixes getting the MAC
address for some dc(4) cards on big endian architectures.
This is a RELENG_5 candidate.
Tested by: gallatin (powerpc), marius (sparc64)
First version of the patch written by: gallatin
|
| |
|
|
|
|
|
| |
The driver doesn't look any less safe without Giant than with, and works
with IS_MPSAFE set to 1 here, so others should probably test it as such.
|
|
|
|
|
|
|
|
|
|
|
| |
to 7422 since it appears that the 8169S can't transmit anything larger..
The 8169S can receive full jumbo frames, but we don't have an mru to let
the upper layers know this...
add fixup so that this driver should work on alignment constrained platforms
(!i386 && !amd64)
MFC after: 5 days
|
|
|
|
|
| |
Discussed with: glebius
X-MFC after: 5.3-Release
|
| |
|
|
|
|
|
| |
Submitted by: Johan Karlsson
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
shared code...
define rx descriptor count in terms of tx
align defines
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
(which was derived from the "ncr" driver) and add a MODULE_DEPEND
on "cam".
MT5 candidate, IMHO.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
| |
it only if we weren't UP before. In some cases xl_init causes long media
re-negotiation, and ppp(8) fails to open PPPoE connection because it sets
IFF_UP every time before opening PPPoE connection.
PR: kern/69133
Patch by: mdodd
Approved by: wpaul, julian (mentor)
MFC after: 1 week
|
|
|
|
| |
MFC after: 3 days
|