- 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.
doing the cmpxchg, where another thread can successfully get a read hold
on the lock. That shouldn't fail anyone trying trying to get a read
hold. So for read locks, never bail just because the CAS fails, only bail
if we the status bits in the lock word say we can't have it.
acquiring the rwlock recursively in some paths.
Introduce _prop_rwlock_tryrdlock() and use it in these functions, so
that the rwlock is *always* acquired once, while here add some
_PROP_RWLOCK_OWNED asserts to verify.
This definitely fixes the "locking against myself" panics.
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.
Simplify the mount locking. Remove all the crud to deal with recursion on
the mount lock, and crud to deal with unmount as another weirdo lock.
Hopefully this will once and for all fix the deadlocks with this. With this
commit there are two locks on each mount:
- krwlock_t mnt_unmounting. This is used to prevent unmount across critical
sections like getnewvnode(). It's only ever read locked with rw_tryenter(),
and is only ever write locked in dounmount(). A write hold can't be taken
on this lock if the current LWP could hold a vnode lock.
- kmutex_t mnt_updating. This is taken by threads updating the mount, for
example when going r/o -> r/w, and is only present to serialize updates.
In order to take this lock, a read hold must first be taken on
mnt_unmounting, and the two need to be held across the operation.
One effect of this change: previously if an unmount failed, we would make a
half hearted attempt to back out of it gracefully, but that was unlikely to
work in a lot of cases. Now while an unmount that will be aborted is in
progress, new file operations within the mount will fail instead of being
delayed. That is unlikely to be a problem though, because if the admin
requests unmount of a file system then s(he) has made a decision to deny
access to the resource.
When we read interface flags and capabilities from the kernel, take
care not to record them in our current environment (env), but record
them in the output environment (oenv), instead. This helps us get
interface capabilities and flags right.
