- Fix a bug in the same condition where we forgot to drop the ACPI pcib
lock. This fixes hangs after the pcib0 attach on some machines.
Tested by: sos (2)
ever working correctly: the code was linking the QHs together but
then immediately overwriting the "next" pointers. Oops. Also
initialise qh_endphub, since the EHCI spec says that we should
always set the pipe multiplier field to something sensible.
This appears to make basic split transactions work, so enable split
transactions for control, bulk and interrupt pipes (split isochronous
transfers are not yet implemented). It should now be possible to
use USB1 devices even when they are connected through a USB2 hub.
from an mbuf into the fxp_encap() function, as done in other drivers.
- Don't waste time calling bus_dmamap_load_mbuf() if we know the mbuf
chain is too long to fit in a TX descriptor, call m_defrag() first.
- Convert fxp(4) to use bus_dmamap_load_mbuf_sg().
at some point result in a status event being triggered (it should
be a link down event: the Microsoft driver design guide says you
should generate one when the NIC is initialized). Some drivers
generate the event during MiniportInitialize(), such that by the
time MiniportInitialize() completes, the NIC is ready to go. But
some drivers, in particular the ones for Atheros wireless NICs,
don't generate the event until after a device interrupt occurs
at some point after MiniportInitialize() has completed.
The gotcha is that you have to wait until the link status event
occurs one way or the other before you try to fiddle with any
settings (ssid, channel, etc...). For the drivers that set the
event sycnhronously this isn't a problem, but for the others
we have to pause after calling ndis_init_nic() and wait for the event
to arrive before continuing. Failing to wait can cause big trouble:
on my SMP system, calling ndis_setstate_80211() after ndis_init_nic()
completes, but _before_ the link event arrives, will lock up or
reset the system.
What we do now is check to see if a link event arrived while
ndis_init_nic() was running, and if it didn't we msleep() until
it does.
Along the way, I discovered a few other problems:
- Defered procedure calls run at PASSIVE_LEVEL, not DISPATCH_LEVEL.
ntoskrnl_run_dpc() has been fixed accordingly. (I read the documentation
wrong.)
- Similarly, the NDIS interrupt handler, which is essentially a
DPC, also doesn't need to run at DISPATCH_LEVEL. ndis_intrtask()
has been fixed accordingly.
- MiniportQueryInformation() and MiniportSetInformation() run at
DISPATCH_LEVEL, and each request must complete before another
can be submitted. ndis_get_info() and ndis_set_info() have been
fixed accordingly.
- Turned the sleep lock that guards the NDIS thread job list into
a spin lock. We never do anything with this lock held except manage
the job list (no other locks are held), so it's safe to do this,
and it's possible that ndis_sched() and ndis_unsched() can be
called from DISPATCH_LEVEL, so using a sleep lock here is
semantically incorrect. Also updated subr_witness.c to add the
lock to the order list.
Change fhc(4) to use IRQ numbers instead of RIDs for allocating the
IRQs of children. This works similar to e.g. sbus(4), i.e. add the
IRQ resources as fully specified to the resource lists of the children,
allocate them like normal. When establishing the interrupt search the
interrupt maps of the children for a matching INO to determine which
map we need to write the fully specified interrupt number to and to
enable the mapping (before the RID was used to indicate which interrupt
map to use).
- dev/puc/puc.c:
Revert rev. 1.38, with the above change fhc(4) no longer needs special
treatment for allocating IRQs.
Thanks to: joerg for providing access to an E3500
modulating the STPCLK# pin based on the duty cycle. Since p4tcc uses the
same mechanism (but internal to the CPU), we triggered a hang on some
systems at low frequencies when both were in use. Now, disable
acpi_throttle when p4tcc is also present.
Tested by: Kevin Oberman
with no associated data. Also revert previous changes that allocate off
of the stack instead of using malloc, as it's not needed. Many thanks to
LSI for investigating and fixing these problems.
Submitted by: rajeshpr @ lsil . com
a vlan interface attached to a fxp(4) card when it has not been
initialized yet. We now set the links from our internel TX descriptor
structure to the TX command blocks at attach time rather than at init
time. While I'm here, slightly improve the style in fxp_attach().
PR: kern/78112
Reported by: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> and others
Tested by: flz, Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
MFC after: 1 week
place.
This moves the dependency on GCC's and other compiler's features into
the central sys/cdefs.h file, while the individual source files can
then refer to #ifdef __COMPILER_FEATURE_FOO where they by now used to
refer to #if __GNUC__ > 3.1415 && __BARC__ <= 42.
By now, GCC and ICC (the Intel compiler) have been actively tested on
IA32 platforms by netchild. Extension to other compilers is supposed
to be possible, of course.
Submitted by: netchild
Reviewed by: various developers on arch@, some time ago
set the interrupt handler to be INTR_MPSAFE now that xpt_done() can be
called without Giant. Giant is still on the top half of the driver and
the timeout handlers.
with shared IRQs in case the bus code, MD interrupt code, etc. permits.
Together with sys/sparc64/sparc64/intr_machdep.c rev. 1.21 this fixes
an endless loop in uart_intr() when using the second NS16550 on the ISA
bus of sparc64 machines.
- Destroy the hardware mutex on detach and in case attaching fails.
Approved by: marcel
Failure to do this will result in following ata_pio_read() calls walking
off the end of the read buffer.
This resolves the "memory modified after free" panics common with Thinkpads
and CD/DVD drives.
Submitted by: Nate Lawson <nate AT root.org>
idle the 'mask' variable could be set to 0, resulting in the timeout loop
running for the full 31 seconds.
Handling this case eliminates long hangs on resume on some systems.
Submitted by: Nate Lawson <nate AT root.org>
and the X1034A (quad HME; QFE) cards the X1033A (single HME) don't have a
PCI-PCI-bridge so we can't rely on the PCI slot number being useable as
index for the network address to read from the VPD on the latter. Use
the end tag to determine whether it is a QFE VPD with 4 NAs and only use
the slot number as index in this case.
- Remove a useless check.
Prodded by: joerg
Additional testing by: joerg
MFC after: 1 day
o usb_subr.c, add delta 1.119:
Move usb_get_string() and make it public.
o usbdi.c, bring on par with 1.106, this includes:
- Make an iterator abstraction for looping through all descriptors.
- Whine about not being able to figure out default language if we are debugging.
- Move usb_get_string() and make it public.
o usbdi.h, bring on par with 1.64, this includes:
- Make an iterator abstraction for looping through all descriptors.
- Move usb_get_string() and make it public.
o usbdi_util.c, bring on par with 1.42, this includes:
- Add usbd_get_protocol().
- Use NULL instead of 0.
- Fix (mostly harmless) typo.
- Move utility routine from uirda.c to usbdi_util.c.
o usbdi_util.h, bring on par with 1.31, this includes:
- Add usbd_get_protocol().
- Move utility routine from uirda.c to usbdi_util.c.
MFC after: 3 days
is particularly useful when VESA is available (either `options VESA'
or load the vesa module), as BIOSes in some notebooks may correctly
save and restore LCD panel settings using VESA in cases where calling
the video BIOS POST is not effective. On some systems it may also
be necessary to set the hw.acpi.reset_video sysctl to 0.
yet I only changed one of them. So when we loaded drivers, we'd fail
to allocate resources correct.
This pointed out that we were doing the wrong thing when we failed to
attach a child. We released all the resources and almost deleted the
child. Instead, we should keep the resources allocated so when/if a
driver is loaded, we can go w/o having to allocate them. We use
pci_cfg_save/restore to restore the BARs with these resources.
This seems to fix the problems that we were seeing that I thought
might have magically gone away in the last revision of cardbus.c (but
really didn't).
Noticed by: avatar (nicely done!)
