Correctly handle additional disks without BIOS partition tables.
Previously, vinum_scandisk stopped scanning additional disks for
native partitions after any good partition was found. This applies
to all platforms, but was a particular problem on systems without
BIOS partition tables.
Submitted by: harti
the hardware mutex if it is held. Re-add calls to Enable/Clear fixed events.
This is not known to have caused problems. Bug symptoms might have included
instability after an aborted suspend attempt or power/sleep buttons not
being enabled.
CP-168U board. It initializes and attaches in the same way as the
older (but higher performance) C168H. The only difference is the
board ID, which is 0x1681.
PR: kern/53548
Submitted by: regnauld@catpipe.net
MFC after: 1 week
the Palm device and the USB host controller deadlock. The USB host
controller is expecting an early-end-of-transmission packet with 0
data, and the Palm doesn't send one because it's already communicated
the amount of data it's going to send in a header (which ucom/uvisor
are oblivious to). This is the problem that has been known on the
pilot-link lists as the "[Free]BSD USB problem", but not understood.
Submitted by: Nathan J. Williams <nathanw@MIT.EDU>
for partly-aligned operations through /dev/crypto (unlikely)
o add missing case in iov code that never showed up because of the above bug
Submitted by: "Jason L. Wright" <jason@thought.net>
MFC after: 3 days
found only many tv-cards.
We currently use more ore less evil hacks (slow_msp_audio sysctl) to
configure the various variants of these chips in order to have
stereo autodetection work. Nevertheless, this doesn't always work
even though it _should_, according to the specs.
This is, for example, the case for some popular Hauppauge models sold
sold in Germany.
However, the Linux driver always worked for me and others. Looking at
the sourcecode you will find that the linux-driver uses a very much
enhanced approach to program the various msp34xx chipset variants,
which is also found in the specs for these chips.
This is a port of the Linux MSP34xx code, written by Gerd Knorr
<kraxel@bytesex.org>, who agreed to re-release his code under a
BSD license for this port.
A new config option "BKTR_NEW_MSP34XX_DRIVER" is added, which is required
to enable the new driver. Otherwise the old code is used.
The msp34xx.c file is diff-reduced to the linux-driver to make later
modifications easier, thus it doesn't follow style(9) in most cases.
Approved by: roger (committing this, no time to test/review),
keichii (code review)
These are 10/100 only NICs found on the IBM Thinkpad R40E and
G40. These seem to be based on the BCM5705 MAC but with a PHY
that doesn't support 1000Mbps modes.
Submitted by: Igor Sviridov <sia@nest.org>
ioctls.
In the particular case of ptrace(), this commit more-or-less reverts
revision 1.53 of sys_process.c, which appears to have been erroneous.
Reviewed by: iedowse, jhb
to configure this correctly yields many watchdog timeouts even on lightly
loaded machines. This is a common complaint from users with Dell 1750
servers with built-in dual 5704 NICs.
the time the card is inserted and the time that the card is
configured. This can lead to interrupt storms. The O2Micro suggested
workaround is to route the card function interrupt to IRQ1. It
appears from my testing that this is an acceptable workaround for most
chipsets (there's still some issue with the ricoh chipset).
Also, only look at the NOT_A_CARD bit when the bridge tells us there's
a card present. At least one test caused this to be true after the
card was removed, but the author couldn't recreate it with the
workaround in place. The change is more conservative than the
previous code, but still has the work around that wasn't present in
the older code.
BGE_MACSTAT_MI_COMPLETE bit in the MAC status register as a link
change indicator. We turn this bit on now because some of the newer
chips need it, but it usually just means that reading/writing
an MII/GMII register has completed, not that a link change has
occured.
the standard.
1) When the bridge tells us that we have a card that isn't recognized, we
use the force register to force the CV_TEST to run. This test causes the
bridge to re-evaluate the card. Once this re-evaluation process happens,
we get a new interrupt that may say it is ready to process. We try this up
to 20 times. Tests have shown that this appears to correctly reset the
'Unknown card type' problem that I saw on my Sony PCG-505TS.
2) Take a page from OLDCARD and always read the CSC register in the ISR.
Some TI (and it seems maybe Ricoh) chipsets require this to behave
properly. This work around appears to work due to some power management
protocols that were improperly implemented. Maybe it can be removed when
this driver supports the full PME# protocol described in the standards.
3) Minor additional debug printf when debugging is enabled.
4) Minor additional commentary for things that are obvious only after study.
# I'm committing this from my Sony PCG-505TS using shared PCI interrupts
# and NEWCARD, but there are some issues with the Ricoh bridge still, but
# at least now I can boot with the card inserted and have it work.
PCG-505BX (for example) has one of those:
wi0: <Intersil Prism3> mem 0xf8000000-0xf8000fff at device 2.0 on pci2
wi0: 802.11 address: 00:02:8a:94:d8:73
wi0: using RF:PRISM3(Mini-PCI)
wi0: Intersil Firmware: Primary (1.1.1), Station (1.5.6)
wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
has the same product id, but different vendor id. It also appears
that the MELCO's id should be 0x18a instead of 0x8a01. Fix this.
Submitted by: Shizuka Kudo-san
