| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
- 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
|
|
|
|
| |
are either locked down or demonstrated MPSAFE.
|
|
|
|
|
|
| |
PR: [FreeBSD-users-jp 80667]
Submitted by: FUJIMOTO Kou <fujimoto@j.dendai.ac.jp>
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
by default. As such, mark if_dc as IFF_NEEDSGIANT until such
time as appropriate locking review and testing can take place,
and the locking can be enabled by default.
RELENG_5 candidate.
|
|
|
|
|
| |
PR: kern/69858
Submitted by: Jacobo Arvelo <unix4all at gulic dot org>
|
|
|
|
|
|
|
|
|
| |
to check aperture size, avoiding hangs. Maintain the rest of the bits when
setting/unsetting ATTBASE. This essentially matches Linux's AGP driver as well.
PR: kern/70037
Submitted by: Mark Tinguely <tinguely at casselton dot net>
Obtained from: NetBSD
|
|
|
|
| |
follow).
|
|
|
|
|
|
|
| |
allocation earlier on in sk_attach so we don't have to lock until a bit
later.
PR: 69752
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This also applies to AMD64 HW running 'i386' OS.
Submitted by: Jung-uk Kim <jkim@niksun.com>
Integration by: obrien
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variable. If set to "true" OF_getetheraddr() will now return the unique
MAC address stored in the "local-mac-address" property of the device's
OFW node if present and the host address/system default MAC address if
the node doesn't doesn't have such a property. If set to "false" the
host address will be returned for all devices like before this change.
This brings the behaviour of device drivers for NICs with OFW support/
FCode, i.e. dc(4) for on-board DM9102A on Sun machines, gem(4) and hme(4),
regarding "local-mac-address?" in line with NetBSD and Solaris.
The man pages of the respective drivers will be updated separately to
reflect this change.
- Remove OF_getetheraddr2() which was used as a stopgap in dc(4). Its
functionality is now part of OF_getetheraddr().
|
|
|
|
|
| |
IFF_NEEDSGIANT so that ifp->if_start won't be called without Giant
when running debug.mpsafenet=1.
|