This changes the naming of USB serial devices to: /dev/ttyU%d and
/dev/cuaU%d for call-in and call-out devices respectively. (Please
notice: capital 'U')
Please also note that we now have .init and .lock devices for USB
serial ports. These are not persistent across device removal. devd(8)
can be used to configure them on attachment time.
These changes also improve the chances of the system surviving if
the USB device is unplugged at an inconvenient time. At least we
do not rip things apart while there are any threads in the device
driver anymore.
Remove cdevsw, rely on the tty generic one.
Don't make_dev(), use ttycreate() which does all the magic.
In detach, do close procesing if we ripped things apart
while the device was open. Call ttyfree() once we're done
cleaning up.
select(2), and discovered to my horror that ugen(4)'s bulk in/out support
is horribly lobotomized. Bulk transfers are done using the synchronous
API instead of the asynchronous one. This causes the following broken
behavior to occur:
- You open the bulk in/out ugen device and get a descriptor
- You create some other descriptor (socket, other device, etc...)
- You select on both the descriptors waiting until either one has
data ready to read
- Because of ugen's brokenness, you block in usb_bulk_transfer() inside
ugen_do_read() instead of blocking in select()
- The non-USB descriptor becomes ready for reading, but you remain blocked
on select()
- The USB descriptor becomes ready for reading
- Only now are you woken up so that you can ready data from either
descriptor.
The result is select() can only wake up when there's USB data pending. If
any other descriptor becomes ready, you lose: until the USB descriptor
becomes ready, you stay asleep.
The correct approach is to use async bulk transfers, so I changed
the read code to use the async bulk transfer API. I left the write
side alone for now since it's less of an issue.
Note that the uscanner driver has the same brokenness in it.
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
mutexes instead.
This closes the last (known) race issues in ATA which should fix
the various hangs etc seen on heavy loaded systems.
Change from using timeout functions to using callout functions in
the timeout code. This together with above closes the race that could
happen if timeout and device interrupt occured simultaniously.
Also fix the possible recursion in ata_reinit() on very dodgy
devices that could take us down in the probe.
I have from Broadcom does not give much information on these devices,
so the Broadcom Linux driver was used for clues to what these chips
support. It turns out they are similar to the 5705 with the 5751
being the PCI-Express version and needing special work-arounds and
settings.
Use kthread_exit() instead of falling through the end of the worker
thread's main function. Since kthread_exit() wakeup(9)s everyone
sleeping on the thread handle, drop the superfluous wakeup() call.
because it was mostly irrelevant - except for the silly BIOS_PADDRTOVADDR
etc macros. Along the way of working around this, I missed a few things.
* Make syscons properly inherit the bios capslock/shiftlock/etc state like
i386 does. Note that we cannot inherit the bios key repeat rate because
that requires a bios call (which is impossible for us).
* Give syscons the ability to beep on amd64. Oops.
While here, make bios.c compile and add it to files.amd64.
panic on hub detach bugs that have been reported. This work around
detaches the device before deleting it. This changes the detach order
from in-order to pre-order. This avoids uhub's deleting the children
after its subdevs has been deleted.
This is only a workaround. This leads to a strange condition in the
device tree where attached devices are children of detached ones. I
really don't know what that's supposed to mean, but does violate my
sense of POLA. Fortunately, the violation is short lived, which is
why I'm going ahead and committing the work around.
# We really need to consider life w/o the multiple nested layers of
# compatibility macros. They make finding bugs like this *MUCH*
# harder.
Patch by: iadowse
MT5 before: next_release(5.3-BETA5) (unless someting better comes along)
and 0x3f7. fdc_isa_alloc_resource() didn't work right in this case
(it accessed FDOUT correctly due to an overflow of the first resource.
It accesed FDSTS and FDDATA incorrectly via the second resource (which
wound up accessing FDOUT and the tape register at 0x3f3) and badly for
the CTL register (at location 0x3f4). This is a minimal fix that just
'eats' the first one if it covers two locations and has an offset of
0. This confusion lead the floppy driver to think there'd been a disk
change, which uncovered a deadlock in the floppy/geom code which lead
to a panic. These changes fix that by fixing the underlying resource
problem, but doesn't address the potential deadlock issue that might
still be there.
This is a minimal fix so it can more safely be merged into 5 w/o risk
for known working configurations (hence the use of the ugly goto,
which reduces case 8 to case 6 w/o affecting cases 1-7). A more
invasive fix that will handle more ACPI resource list diversity is in
the pipeline that should kill these issues once and for all, while
staying within the resources that we allocate.
Tested/Reported by: das
Reviewed by: njl
MFC before: re->next_release_name(5.3-BETA5);
registers are control bits or depending on the model contain additional
time bits with a different meaning than the lower ones. In order to
only read the desired time bits and not change the upper bits on write
use appropriate masks in the gettime and settime function respectively.
Due to the polarity of the stop oscillator bit and the fact that the
century bits aren't used on sparc64 not masking them didn't cause
problems so far.
- Fix two off-by-one errors in the handling of the day of week. The
genclock code represents the dow as 0 - 6 with 0 being Sunday but the
mk48txx use 1 - 7 with 1 being Sunday. In the settime function when
writing the dow to the clock the range wasn't adjusted accordingly but
the clock apparently played along nicely otherwise the second bug in
the gettime function which mapped 1 - 7 to 0 - 6 but with 0 meaning
Saturday would have been triggered. Fixing these makes the date being
stored in the same format Sun/Solaris uses and cures the "Invalid time
in real time clock. Check and reset the date immediately!" when the
date was set under Solaris prior to booting FreeBSD/sparc64. [1]
Looking at other clock drivers/code e.g. FreeBSD/alpha the former "bug",
i.e. storing the dow as 0 - 6 even when the clock uses 1 - 7, seems to
be common but might be on purpose for compatibility when multi-booting
with other OS which do the same. So it might make sense to add a flag
to handle the dow off-by-one for use of this driver on platforms other
than sparc64.
- Check the state of the battery on mk48txx that support this in the
attach function.
- Add a note that use of the century bit should be implemented but isn't
required at the moment because it isn't used on sparc64.
Problem noted by: joerg [1]
MT5 candidate.
driver. Trim its fingernails by removing some useless bits before
fixing the 'thread not terminated on detach' problem.
o dmacnt is no longer used now that we allocate at attach time. Remove
it from struct fdc_data.
o ISPNP was only ever set, but never tested. It used to be used for the
allocation routines to change how it allocated resources. Since that's
no longer necessary, retire the flag.
o ISPCMICA was only ever tested, but never set. GC it. This removes
a special case in determining the drive type. The drive type is
now set in fdc_pcmcia.c, so the hack isn't needed anymore. Sadly,
this isn't tested with a Y-E Data pcmcia floppy drive because there
are a number of other issues that preclude it from working.
o Fix ifdef for reading from the rtc. I'm of the opinion that this ifdef
should be moved into fdc_isa.c, but not today as ideally there'd be
other fixes to the probing of children. So now we just read it on
i386 ! pc98 (there's no #define for MACHINE_ARCH, just MACHINE, hence
this slightly inelegant kludge) and amd64. The PC98 exclusion likely
isn't meaningful since pc98 uses a different driver, but will be when
merging of the pc98 floppy code into this driver is complete (this is the
other reason I think this block of code belongs outside fdc.c).
All of these changes are safe to MT5.
copper NICs, a link change event is posted whenever MII autopolling is
toggled off and on, which happens whenever someone calls
bge_miibus_readreg() or bge_miibus_writereg() to access the PHY
registers. This means anytime someone called the SIOCGIFMEDIA ioctl
on a bge interface, the link would reset. Even a simple "ifconfig bge0"
would do it, though other apps like dhclient or the PPPoE daemon could
trigger it as well. An obvious symptom of this problem is lots of
"bgeX: gigabit link up" messages appearing on the console for no
apparent reason.
Through experimentation, I determined that when a real link change
event occurs, the BGE_MIMODE_AUTOPOLL in the BGE_MI_MODE register
is always set, so now if we have a copper NIC and an link change
event occurs and the BGE_MIMODE_AUTOPOLL bit is clear, we ignore
the event.
Note that this does not apply to the original BCM5700 chip since we
use a different method for sensing link changes with that chip (the
status block method was broken), nor to fiber optic NICs since they
don't use the GMII PHY access registers.
another way to misinterpret the spec. Also, always fall back to the hints
probe on any attach failure, not just when _FDE fails.
Thanks to imp and scottl for finding this.
Tested by: rwatson (minimally)
MFC after: 5 days
After this change it should be possible to use very big md(4) devices.
- Clean up and simplify the code a bit.
- Use humanize_number(3) to print size of md(4) devices.
- Add 't' suffix which stands for terabyte.
- Make '-S' to really work with all types of devices.
- Other minor changes.
it is only used in one function. While doing so, change its type to
vm_ooffset_t.
We are still limited for swap-backed devices to 16TB on 32-bit architectures
where PAGE_SIZE is 4096 bytes.
This make "_NEC" devices appear as "NEC" which is more corrent.
The reason is tha NEC originally screwed up on the byteorder in the
model string, so now that they have realized that they prefixed the '_'
so that not every ATA driver on the planet would call them "EN C" :)
reserving it at use time is more miserly, low memory (< 16MB)
evaporates quickly on many systems, so there may not be any suitable
buffers available. This specifically doesn't use the newer, fancier
isa_dma_init to ease merging to 5.
Reviewed by: tegge, phk
the firmware status register on the card to see if the firmware is still
running. There is no way to recover from this, but at least it can give
a hint as whether the car has crashed (which happens all too often).
MFC after: 3 days
errors for the attachment process for the floppy controller. This is
a band-aide because it doesn't try any of the fallback methods when
_FDE isn't long enough, but should be sufficient for people
experiencing the dreaded mutex not initialized panic.
problems:
1) Add locking for SMP, code provided by Alan Cox
2) While testing Alan's patches, I observed serious problems with
the jumbo buffer allocation code (machine crashed twice), so I gutted
it and rewrote the receive handler to use multiple chained descriptors.
Each RX descriptor gets a single 2K cluster, and the chip will fill in
as many as it needs to hold the complete packet.
User reports that this corrects the data corruption issues previously
observed and discussed on -current.
Note that this driver still needs to be hit with the busdma stick.
I intend to inflict said beating in the near future.
MFC after: 1 week
o Allow for up to 3 resource I/O ranges to be given for the floppy
controller, rather than just two that are allowed for now.
o Make sure that we can work with either a base address of 0x3f0 or 0x3f2.
o Create new inline functions to access the YE DATA's unique BDCR register.
o Update pccard attachment to add the fd device.
o Do some minor style(9) polishing.
# I'm guessing that the fdc pccard attachment broke some time ago, since
# there are a number of issues with it still.
doesn't do this is beyond me, but that will be investigated later. This
results in programming the chip with the correct frequency, which in turn
allows devices to negotiate up to the full 20MB/s.
calls in sb_cmd2() and sb_getmixer(). The lock has already be grabbed
before these functions are called.
This is a RELENG_5 candidate.
PR: 71189
Submitted by: stephane
MFC after: 3 days
VT6122 gigabit ethernet chip and integrated 10/100/1000 copper PHY.
The vge driver has been added to GENERIC for i386, pc98 and amd64,
but not to sparc or ia64 since I don't have the ability to test
it there. The vge(4) driver supports VLANs, checksum offload and
jumbo frames.
Also added the lge(4) and nge(4) drivers to GENERIC for i386 and
pc98 since I was in the neighborhood. There's no reason to leave them
out anymore.
holds sndstat_lock across a call to uiomove(), which is not legal
to do with a mutex because of the possibility that the data transfer
could sleep because of a page fault. It is not possible to just
unlock the mutex for the uiomove() call without introducing another
locking mechanism to prevent the body of sndstat_read() from being
re-entered. Converting sndstat_lock to an sx lock is the least
complicated change.
This is a candidate for RELENG_5.
LOR: 030
MFC after: 4 days
redundant at this point and should be retired). Don't free subdevs if
we don't attach any devices. This was leaving stale device_t's
around. Don't touch the device if it isn't attached since the name
isn't meaningful then. Switch from strncpy (properly used) to
strlcpy.
From a patch submitted by Peter Pentchev
device_t instances when no driver attaches. They are left around, and
we need to remember them.
# The usbd_device_handle->subdevs[] array likely is completely bogus
# at this point, but one change at a time, since its removal will need
# to have similar code replace it extracted from newbus.
Part of the patch submitted by Peter Pentchev after an excellent
analysis of the underlying problems.
MFC After: 1 week
produced better results for a test program I had here, it didn't
substantially change the number of crashes that I saw. Both the old
code and the new code seemed to produce the same crashes from the usb
layer. Since the new code also solves a close() crash, go with it
until the underlying issues wrt devices going away can be addressed.
The reference counts are there to block detach until the sleepers in
read/write/ioctl have gotten out, not to prevent the open device from
going away. Restore the old behavior so that we have a chance to wake
up sleepers when the usb device goes away, so they can properly return
EIO back to the caller when this happens.
Otherwise, we have a guarnateed panic waiting to happen when a device
detaches with an active read channel.
This should be merged to 5 asap.
would turn off all fans when initializing a zone. However, the HP Omnibook
500 generates a notify saying the zone needs to be re-evaluated whenever
its fan is switched on or off. This produced an infinite loop. Also, note
that running _SCP can generate the same notify.
Since we need to make sure old fan references are turned off when getting
new ones, run acpi_tz_monitor() first. This will turn off any unneeded
fans. Then, check for new settings. After that, run acpi_tz_monitor()
again to turn on/off any fans referenced by the new settings.
Tested by: brooks
returned and then infer the state from calls to _ON/_OFF. This works
around a problem in systems that don't correctly report the state (i.e.
the HP Omnibook 500 reports "on" for its fan always after it has been
turned on once).
I was unable to test this as the PAE kernel crashed with a "cannot copy
LDT" before coming up. When this gets a bit more testing, I'll fix the PAE
conf file to allow isp devices.
PR: 59728
to RS232 bridges, such as the one found in the DeLorme Earthmate USB GPS
receiver (which is the only device currently supported by this driver).
While other USB to serial drivers in the tree rely heavily on ucom, this
one is self-contained. The reason for that is that ucom assumes that
the bridge uses bulk pipes for I/O, while the Cypress parts actually
register as human interface devices and use HID reports for configuration
and I/O.
The driver is not entirely complete: there is no support yet for flow
control, and output doesn't seem to work, though I don't know if that is
because of a bug in the code, or simply because the Earthmate is a read-
only device.
This essentially merges revs 1.143-1.1445 of sys/pci/if_rl.c.
This now marks the interrupt MPSAFE along with making the mutex non-recursive.
Looked over by: bms
In places where we have long delays that doesn't depend on too accurate
timing, use ata_udelay() instead of DELAY() so we dont uselessly spin
the CPU if not nessesary;
It makes no sense in a PAE environment and is impossible to handle correctly.
This case is also never used right now. This should make the iir(4) driver
ready for PAE.
unless ACPI_DEBUG is defined. Users don't typically care about errant
breakpoint instructions. The HP Pavilion 7915 has this in its PCI0
_INI method for rev 0x6040000 of the RSDT.
Removed support for Intel 82541ER
Added fix for 82547 which corrects an issue with Jumbo frames larger than 10k.
Added fix for vlan tagged frames not being properly bridged.
Corrected TBI workaround.
Corrected incorrect LED operation issues
Submitted by: tackerman (Tony Ackerman)
MFC after: 2 weeks
should only affect current resources, it seems best to wait until all
configuration is done before disabling it. If this fixes any problems, it
is a MT5 candidate.
ENOENT when there's no PNP ID for this device node, or ENXIO when there
is one, but it doesn't match.
In the nonPNP case (as most Alpha systems appear to be), we were
treating the error return as an error, when it should be have ignored
it. Version 1.9 properly ignored it, but the attach re-write of 1.10
introduced this logic error.
Pointy Hat to: phk (for breaking it then asking me to fix it :-)
Sponsored by: The Voices in Bill Paul's Head, LLC
the old one is. Hence we need to evaluate the old one for _FDI since it
has a valid ACPI_HANDLE ivar. This is a minimal fix. Make a note that a
more complete one is to make fdc support the ACPI_HANDLE ivar for its
children.
This and the previous change are MT5 candidates.
nor are they 3D accelarators as the description would like us to
believe. Since the TGA2 adapter has a VGA mode (unlike the TGA adapter),
one can use the VGA driver instead.
This fixes GENERIC kernels on alpha with TGA2 adapters.
o Remove PSM_SYNCERR_THRESHOLD1. This value specified how many sync
errors were required before the mouse is re-initialised.
Re-initialisation is now done after (packetsize * 2) sync errors as
things aren't likely to improve after that.
o Reset lastinputerror when re-initialisation occurs. We don't want
to continue to drop data after re-initialisation.
o Count the number of failed packets independently of the syncerrors
statistic. syncerrors is useful for recovering sync within a single
packet. pkterrors allows us to detect when the mouse changes its
packet mode due to some external event (e.g. KVM switch).
o Reinitialize the mouse if we see more than psmpkterrthresh errors
during the validation period. The validation period begins as soon
as a sync error is detected and continues until psmerrsecs/msecs
time has elapsed. The defaults for these two values force a reset
if we see two packet errors in a 2 second period. This allows rapid
detection of packet framing errors caused by the mouse changing packet
modes.
o Export psmpkterrthresh as a sysctl
o Export psmloglevel as a sysctl.
o Enable more debugging code to be enabled at runtime via psmloglevel.
o Simplify verbose conditioned loging by using a VLOG macro.
o Add several comments describing the sync recovery algorithm of
this driver.
Large Portions by: Brian Somers <brian@Awfulhak.org>
Inspired and Frustrated by: Belkin KVMs
Reviewed by: njl, philip
its users.
netisr_queue() now returns (0) on success and ERRNO on failure. At the
moment ENXIO (netisr queue not functional) and ENOBUFS (netisr queue full)
are supported.
Previously it would return (1) on success but the return value of IF_HANDOFF()
was interpreted wrongly and (0) was actually returned on success. Due to this
schednetisr() was never called to kick the scheduling of the isr. However this
was masked by other normal packets coming through netisr_dispatch() causing the
dequeueing of waiting packets.
PR: kern/70988
Found by: MOROHOSHI Akihiko <moro@remus.dti.ne.jp>
MFC after: 3 days
Add missing untimeout that would get lost in handling of some
error situations, and caused what looked like random timeouts
afterwards when the timeout fired.
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.
Set the DMA SGL length correctly if the DMA request must be chained because
it is too large to fit in one SGL.
This should fix this driver for some Dell Precision systems.
RELENG_5 candidate.
PR: kern/66479
Submitted by: HITOSHI Osada <qfh02545@nifty.com>
the geometry code to grab a mutex that prohibits any driver on the
stack below it from sleeping, it's not safe to allow anything in
the top half of isp to sleep (excepting the thread that Fibre Channel
instances use to re-scan loops/fabrics).
hold its own values, pass them up to the parent (acpi0) and merge/uniq them
on the way. After the namespace evaluation, acpi will reserve these
resources and manage them via rman before bus_generic_probe() and
bus_generic_attach(). This is necessary because some systems specify
conflicting resources in separate sysresource objects. It's also cleaner
in that the interface between sysresource and acpi is now merely the parent's
resource list. This code handles the following cases:
1. Unique resource: add it to the parent via bus_set_resource().
2. New wholly contained in old: discard new.
3. New tail overlaps old head: grow old head downward.
AND/OR
4. New head overlaps old tail: grow old tail upward.
Tested by: Pawel Worach <sajd_at_telia.com>
Tested by: Radek Kozlowski <radek_at_raadradd.com>
MFC after: 5 days
deal with 24-bit addresses. While the two other attachments, namely
isa and cbus, do it properly, the PCI attachment was passing
BUS_SPACE_MAXADDR instead of BUS_SPACE_MAXADDR_24BIT. This bug
became apparent with the new contigmalloc() code.
This fixes the problem reported with lnc(4) interfaces inside VMWare,
and should theoritically also fix any user of a PCI lnc(4) card. It
is a RELENG_5 MFC candidate.
Tested by: Florian Le Goff <madflo@beertech.org>
before returning. Device nodes are created via the "taste" mechanism,
so this is necessary in order to make sure that devfs entries are
created before mdconfig(8) returns.
This may be a MFC candidate for 5.3.
Suggested by: phk
allocation. Notably, in this case, the driver tries to allocate several
pieces of memory and then fails if the pieces allocated after the first
do not come after it physically, and within a specific range (8MB I
believe). Of course, this could just as easily fail for any number of
reasons, but it almost always fails now that contiguous allocations start
at the end of possible specified memory locations rather than the beginning.
Allocate all the possibly-needed memory up front, even though it's a waste,
to get around this. The least bogus solution would be to take the physical
address from the first allocation and create a new tag that specified that
further allocations must follow it within that 8MB window, then use that
when allocating new channels, but that's left for anyone else that really
feels like doing it.
Tested by: Erwin Lansing <erwin@lansing.dk>
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
systems that have overlapping regions specified in their sysresource
objects. This patch fixes ATA DMA and acpi_timer allocation for such
sysctems. It should eventually be moved to resource_list_add() if it is
a valid generalized approach. The minimal approach for 5.3 is:
"Loop through all current resources to see if the new one overlaps
any existing ones. If so, the old one always takes precedence and
the new one is adjusted (or rejected). We check for three cases:
1. Tail of new resource overlaps head of old resource: truncate the
new resource so it is contiguous with the start of the old.
2. New resource wholly contained within the old resource: error.
3. Head of new resource overlaps tail of old resource: truncate the
new resource so it is contiguous, following the old."
Tested by: Radek Kozlowski <radek_at_raadradd.com>
Discussed with: imp
MFC after: 4 days
of 0x3f2-0x3f5,0x3f7 the ports are not 7 bytes apart. This should fix
floppy probing on such systems. (We handle the case of adjusting for
a start of 0x3f2 -> 0x3f0 separately, although that code should still be
checked if there are still floppy problems for others.)
Tested by: Sarunas Vancevicius <vsarunas_at_eircom.net>
MFC after: 3 days
Centralize the fdctl_wr() function by adding the offset in
the resource to the softc structure.
Bugfix: Read the drive-change signal from the correct place:
same place as the ctl register.
Remove the cdevsw{} related code and implement a GEOM class.
Ditch the state-engine and park a thread on each controller
to service the queue.
Make the interrupt FAST & MPSAFE since it is just a simple
wakeup(9) call.
Rely on a per controller mutex to protect the bioqueues.
Grab GEOMs topology lock when we have to and Giant when
ISADMA needs it. Since all access to the hardware is
isolated in the per controller thread, the rest of the
driver is lock & Giant free.
Create a per-drive queue where requests are parked while
the motor spins up. When the motor is running the requests
are purged to the per controller queue. This allows
requests to other drives to be serviced during spin-up.
Only setup the motor-off timeout when we finish the last
request on the queue and cancel it when a new request
arrives. This fixes the bug in the old code where the motor
turned off while we were still retrying a request.
Make the "drive-change" work reliably. Probe the drive on
first opens. Probe with a recal and a seek to cyl=1 to
reset the drive change line and check again to see if we
have a media.
When we see the media disappear we destroy the geom provider,
create a new one, and flag that autodetection should happen
next time we see a media (unless a specific format is configured).
Add sysctl tunables for a lot of drive related parameters.
If you spend a lot of time waiting for floppies you can
grab the i82078 pdf from Intels web-page and try tuning
these.
Add sysctl debug.fdc.debugflags which will enable various
kinds of debugging printfs.
Add central definitions of our well known floppy formats.
Simplify datastructures for autoselection of format and
call the code at the right times.
Bugfix: Remove at least one piece of code which would have
made 2.88M floppies not work.
Use implied seeks on enhanced controllers.
Use multisector transfers on all controllers. Increase
ISADMA bounce buffers accordingly.
Fall back to single sector when retrying. Reset retry count
on every successful transaction.
Sort functions in a more sensible order and generally tidy
up a fair bit here and there.
Assorted related fixes and adjustments in userland utilities.
WORKAROUNDS:
Do allow r/w opens of r/o media but refuse actual write
operations. This is necessary until the p4::phk_bufwork
branch gets integrated (This problem relates to remounting
not reopening devices, see sys/*/*/${fs}_vfsops.c for details).
Keep PC98's private copy of the old floppy driver compiling
and presumably working (see below).
TODO (planned)
Move probing of drives until after interrupts/timeouts work
(like for ATA/SCSI drives).
TODO (unplanned)
This driver should be made to work on PC98 as well.
Test on YE-DATA PCMCIA floppy drive.
Fix 2.88M media.
This is a MT5 candidate (depends on the bioq_takefirst() addition).
the driver to issue a bus reset more quickly than intended. We want to
*wait* if we find another SCB that could be the cause of this timeout,
not proceed to a bus reset.
Noticed by: kan
callers. These ioctls attempted to enable and disable the ACPI
interpreter at runtime. In practice, it is not possible to boot with
ACPI and then disable it on many systems and trying to do so can cause
crashes, interrupt storms, etc. Binary compatibility with userland is
retained.
MFC after: 2 days
also generates a notify. Since we held the lock over this call, the
notify never got to run and the battery status read never returned.
Document this also.
Tested by: Maxim Maximov <mcsi_at_mcsi.pp.ru>
Approved by: re (scottl)
data packet is received from the mouse. In the case of many KVM's,
this avoids a bug in their mouse emulation that sends back incorrect
sync when you explicitly request a data packet from the mouse. Without
this change, you must force the driver into stock PS/2 mode or be flooded
with a never ending stream of "out of sync" messages on these KVMs.
Approved by: re
The ISA probe uses an identify routine to probe all slot locations from
1 to 14 that do not conflict with other allocated resources. This required
making aic7770.c part of the driver core when compiled as a module.
aic7xxx.c:
aic79xx.c:
aic_osm_lib.c:
Use aic_scb_timer_start() consistently to start the watchdog timer.
This removes a few places that verbatum copied the code in
aic_scb_timer_start().
During recovery processing, allow commands to still be queued to
the controller. The only requirement we have is that our recovery
command be queued first - something the code already guaranteed.
The only other change required to make this work is to prevent
timers from being started for these newly queued commands.
Approved by: re
only required to support probing of the Adaptec 284X VLB SCSI controller
which becomes visible in EISA space if you perform these writes. 284X
probing is moving to an ISA attachment.
This was tested with a Netgear WG311v2 802.11b/g PCI card. Things
that were fixed:
- This chip has two memory mapped regions, one at PCIR_BAR(0) and the
other at PCIR_BAR(1). This is a little different from the other
chips I've seen with two PCI shared memory regions, since they tend
to have the second BAR ad PCIR_BAR(2). if_ndis_pci.c tests explicitly
for PCIR_BAR(2). This has been changed to simply fill in ndis_res_mem
first and ndis_res_altmem second, if a second shared memory range
exists. Given that NDIS drivers seem to scan for BARs in ascending
order, I think this should be ok.
- Fixed the code that tries to process firmware images that have been
loaded as .ko files. To save a step, I was setting up the address
mapping in ndis_open_file(), but ndis_map_file() flags pre-existing
mappings as an error (to avoid duplicate mappings). Changed this so
that the mapping is now donw in ndis_map_file() as expected.
- Made the typedef for 'driver_entry' explicitly include __stdcall
to silence gcc warning in ndis_load_driver().
NOTE: the Texas Instruments ACX111 driver needs firmware. With my
card, there were 3 .bin files shipped with the driver. You must
either put these files in /compat/ndis or convert them with
ndiscvt -f and kldload them so the driver can use them. Without
the firmware image, the NIC won't work.
