This patch fixes a long term borkenness in
ibmvscsi where we were using the wrong timeout
field from the scsi command (and using the
wrong units.) Now broken by the fact that the
scsi_cmnd timeout field is gone entirely.
This only worked before because all the SCSI
targets assumed that 0 was
On 08/22/05 00:55, Matt Domsch wrote:
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- There are some real challenges in supporting a udev-named boot
device. For the most part, it's a distro issue, which is becoming
better. PS: for $10, name a 2.6 distro that uses udev
On 08/21/05 23:52, Andrew Morton wrote:
James Bottomley [EMAIL PROTECTED] wrote:
Since you won't post the usage code, just answer this: how does what
you're doing with idr differ from its originally designed consumer: the
posix timers which also do the idr_remove() in IRQ context?
erp.
On 08/22/05 10:28, James Bottomley wrote:
On Sun, 2005-08-21 at 20:52 -0700, Andrew Morton wrote:
erp. posix_timers has its own irq-safe lock, so we're doing extra,
unneeded locking in that code path.
Possibly, the posix timer code is rather convoluted in this area so I'm
not entirely
On Sun, 2005-08-21 at 20:52 -0700, Andrew Morton wrote:
erp. posix_timers has its own irq-safe lock, so we're doing extra,
unneeded locking in that code path.
Possibly, the posix timer code is rather convoluted in this area so I'm
not entirely sure my analysis is correct.
I think providing
On Mon, 2005-08-22 at 14:46 -0700, Patrick Mansfield wrote:
Did you test with CONFIG_DEBUG_SLAB enabled?
Yes, but only on an ia64.
I have a workaround for problems with device_for_each_child() not being
safe, I'm trying to verify it right now, but the underlying problem is
in klist_next(), I
On Mon, 2005-08-22 at 09:28 -0500, James Bottomley wrote:
I think providing locking inside idr.c was always a mistake - generally we
rely on caller-provided locking for such things.
Well, the reason is because they wanted lockless pre-alloc. If you do
it locked, you can't use GFP_KERNEL
This is a revised patch following this post:
http://marc.theaimsgroup.com/?l=linux-scsim=112461881419898w=2
The plan is to add MODE SELECT SCSI command support to
libata so that parameters such as WCE and DRA can be
changed by a user (i.e. Write(back) Cache Enable and
Disable Read Ahead
James Bottomley [EMAIL PROTECTED] wrote:
Of course, if we're going to go to all this trouble, the next question
that arises naturally is why not just reuse the radix-tree code to
implement idr anyway ... ?
Yes, we could probably have gone that way. radix-tree would need some
enhancements
Douglas Gilbert wrote:
With repect to my libata TEST UNIT READY patch there
is a good chance that can be dropped. The feedback
from the t10 reflector seems to indicate the current
definition may be changed, unfortunately the proposed
changes may require some SAT state information being
held for
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- There are some real challenges in supporting a udev-named boot
device. For the most part, it's a distro issue, which is becoming
better. PS: for $10, name a 2.6 distro that uses udev out
of the box for disk names and
NOTIFYJeff Garzik wrote:
Douglas Gilbert wrote:
The attachment is for discussion. It adds MODE SELECT
support to libata allowing the write(back) cache and
read ahead to be manipulated by users [i.e. the WCE and
DRA ** bits in the SCSI Caching mode page].
In general I approve of this
On Mon, 2005-08-22 at 15:14 -0700, Patrick Mansfield wrote:
based on whatever was in current 2.6.x git tree a couple weeks ago.]
The klist is (effectively) embedded within the struct device.
The klist_next() gets and puts on the klist object, so when the struct
device ref (or kref) counts
James Bottomley [EMAIL PROTECTED] wrote:
Since you won't post the usage code, just answer this: how does what
you're doing with idr differ from its originally designed consumer: the
posix timers which also do the idr_remove() in IRQ context?
erp. posix_timers has its own irq-safe lock, so
On Sun, 2005-08-21 at 17:33 -0700, Luben Tuikov wrote:
No preallocation is done from IRQ context. Do not spread FUD.
It seems to me that you're unaware how IDR works and unaware how
the driver works.
Argumentum ad Hominem now ... we'll get them all eventually.
Since you won't post the usage
On Mon, Aug 22, 2005 at 03:14:27PM -0700, Patrick Mansfield wrote:
Attached is a test module, it oopsed for me with CONFIG_DEBUG_SLAB, on
ppc64. I was trying to complete testing of my hack (on current git tree,
rather than scsi-misc), but have been preempted by other work today.
The patch
On Mon, Aug 22, 2005 at 06:26:25PM -0500, James Bottomley wrote:
On Mon, 2005-08-22 at 17:47 -0500, James Bottomley wrote:
One apparent, but rather nasty, solution would be to embed object get
and put into the klist head as functions that take the node, so
klist_next would take the object
On Mon, 2005-08-22 at 17:39 -0700, Patrick Mansfield wrote:
But, we have to pass in a struct kref, to affect put/get_device, correct?
Correct. Let me post the code mods to drivers/base/core.c so you can
see how it works.
Incidentally, it now passes your dev_child test without causing a slab
On Mon, Aug 22, 2005 at 09:03:03PM -0500, James Bottomley wrote:
On Mon, 2005-08-22 at 17:39 -0700, Patrick Mansfield wrote:
But, we have to pass in a struct kref, to affect put/get_device, correct?
Correct. Let me post the code mods to drivers/base/core.c so you can
see how it works.
OK
19 matches
Mail list logo
