Reconmap used to have one pointer for every reconstruction unit. This
does not scale well in the land of 1TB disks, where some 100MB+ of
"status pointers" are required for typical configurations. Convert
the reconstruction code to use a "sliding status window" which will
scale nicely regardless of the number of stripes/reconstruction units
in the RAID set. Convert the main reconstruction loop to rebuild the
array in chunks rather than in one big lump.
As part of these changes, introduce a function to kick any waiters on
the head separation callback list, and use that in the main
reconstruction event queue to wake up the waiters if things have
stalled. (I believe this may fix a race condition that could occur at
at least at the very end of a disk during reconstruction under heavy
IO load.)
Thanks to Brian Buhrow for all his help, support, and patience in
testing these changes.
Revert condvar changes; there seem to be other locking issues
(independent of these changes insofar as I can tell), and it will
only complicate things for now to introduce more changes.
Argh!
config_found_ia on the node to save a bunch of useless 'device NNN
not configured' messages at startup. While here, condense ACPI printfs
at attach time.
up of write parameters call and a call to perform a series of operations on
these devices.
Note that the MMC framework interface is still not exposed to userland
unless the expose_mmc flag is set. This is to prevent applications to build
on a possibly still moving target. This flag will eventually be removed.
Wasabi Systems.
Fix bus_dma usage to fix write operations in the light of bounce buffers.
Use the 64bit bus_dma tag for 9550+ to avoid bouncing buffers.
- more/better diagnostic messages
- dynamically allocate units in preparation for 9650+ support
- better distribute queue slots over disks according to size
- drain large request queue on 9550
- keep track of resets, will be needed for 9650.
This changes have been contributed by Wasabi Systems.
Some device seems to need a bit of delay before being ready to accept a
command (such as my SATA cdrom drive) May fix port-i386/38548.
As a bonus this makes the dmesg output prettier, by not mixing PHY
status with ATA/ATAPI probe.
in config register).
This fixes the continuous interrupt stream previously seen. It is now
possible to run `ifconfig gem0 up`. However, "gem0: device timeout"
messages appear and we don't appear to receive any interrupts.
- change sc_rev numbers to match quirk numbers used in Realtek's driver
- tweak some register definitions
Taken from Realtek's FreeBSD driver.
Untested yet on 8168C, but no bad sideeffect on older chips.
- Add drm_dmamem_alloc/drm_dmamem_free to drm_memory.c to nicely wrap up
the bus_dma API.
- Start using the above in drm_pci.c.
- Add DRM_NETBSD_DMA_ADDR/DRM_NETBSD_DMA_VADDR macros.
Locking:
- Use IPL_NONE for all locks except the IRQ lock, which runs at IPL_VM.
- Use IPL_VM instead of IPL_TTY with pci_intr_establish() for consistency's
sake. These two changes seem to eliminate the presistent lockups I was
having (NetBSD-current/amd64 r300).
- Start getting rid of DRM_SPININIT/DRM_SPINUNINIT and DRM_SPINLOCK/
DRM_SPINUNLOCK ... these annoy me to no end--not to mention that they
locks may or may not be spinlocks! It's a linux frob, really.
We're way beyond merging any useful bsd-core code on a large scale, which
was the only good reason to keep them around.
Memory allocation:
- Change drm_memory.c so that it contains generally useful, memory
allocation functions using kmem(9) (mostly used by the drivers
themselves). However, I expect to use this more in the future
in the "bsd core". These functions always use KM_NOSLEEP.
The new drm_dmamem_alloc function has a wait argument which
takes DRM_DMA_WAIT/DRM_DMA_NOWAIT (defined as their bus_dma
counterparts), and honors this hint in its calls to kmem(9)
and bus_dma(9) functions.
- Got rid of these functions' "area" argument--it's been deprecated for
ages. Provide macros in drmP.h to deal with the os-independent code.
- Declare these functions inline -- I believe they're used enough
by the i915 and radeon drivers to justify it. Please let me know
if I am mistaken.
NOTE: With these changes, a glxgears score which was previously
~3900fps is now ~4400fps (same setup as mentioned above). I realize
that using kmem(9) could cause problems, but I can't seem to run into
any with my test setup. If anyone smells regression, please let me
know.
of NULL to pci_activate()
Call the variable where we store the PCI Command & Status Register
'csr' instead of 'pmreg'.
In sipcom_intr(), get out if the device is inactive. Otherwise
sip(4) may inadvertently try to handle a shared interrupt before
the driver state is completely set up.
NetBSD finds them in: save and restore power management state
(D0..D3) and PCI Configuration Registers 0x0 through 0x40 during
device attachment and detachment, respectively. Among other things,
this will fix sip(4) detachment and re-attachment.
since udv_attach will not accept a larger offset than signed 64-bit will
provide. Not the best fix, but good enough for now -- at least an X server
will now startup and get proper mappings.
one, throttle it down before the reset. This way the user need not know
the magic `hw.ath0.txintrperiod=1' fix if the default value is too high
for their machine.
cegger