From: Jens Axboe <[EMAIL PROTECTED]>
Subject: Re: [PATCH] bsg: minor bug fixes
Date: Fri, 30 Mar 2007 08:38:04 +0200
> On Fri, Mar 30 2007, FUJITA Tomonori wrote:
> > This fixes the following minor issues:
> >
> > - When bsg_register_queue is called with a request queue that doesn't
> > have requ
On Fri, Mar 30 2007, FUJITA Tomonori wrote:
> From: Jens Axboe <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] bsg: minor bug fixes
> Date: Fri, 30 Mar 2007 08:38:04 +0200
>
> > On Fri, Mar 30 2007, FUJITA Tomonori wrote:
> > > This fixes the following minor issues:
> > >
> > > - When bsg_register_que
Thanks for the info.
Attached is the patch I feel will address this issue. As an added 'perk' I have
also added the code to detect if the controller was previously initialized for
interrupted operations by ANY operating system should the reset_devices kernel
parameter not be set and we are deal
Hello, all.
This document tries to describe lifetime problems of the current
device driver model primarily from the point view of device drivers
and establish consensus, or at least, start discussion about how to
solve these problems. This is primarily based on my experience with
IDE and SCSI la
On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
> Orphaning sysfs nodes on unregistration is a big step in this
> direction. With sysfs reference counting out of the picture,
> implementing 'disconnect immediate' interface only on a few components
> (including request_queue) should suffice for
Hi James,
On 3/30/07, James Bottomley <[EMAIL PROTECTED]> wrote:
On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
> Orphaning sysfs nodes on unregistration is a big step in this
> direction. With sysfs reference counting out of the picture,
> implementing 'disconnect immediate' interface onl
On Fri, 30 Mar 2007 18:43:02 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> One way to solve this problem is to subordinate lifetime rule #b to
> rule #c. Each kobject points to its owning module such that grabbing
> a kobject automatically grabs the module. The problem with this
> approach is th
Cornelia Huck wrote:
> On Fri, 30 Mar 2007 18:43:02 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> One way to solve this problem is to subordinate lifetime rule #b to
>> rule #c. Each kobject points to its owning module such that grabbing
>> a kobject automatically grabs the module. The prob
James Bottomley wrote:
> On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
>> Orphaning sysfs nodes on unregistration is a big step in this
>> direction. With sysfs reference counting out of the picture,
>> implementing 'disconnect immediate' interface only on a few components
>> (including requ
On Fri, 30 Mar 2007 22:19:52 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> > Shouldn't getting/putting the module refcount be solely done in
> > kobject.c? Grab the module reference when the kobject is created and
> > release the module reference in kobject_cleanup() after the release
> > function
Cornelia Huck wrote:
> On Fri, 30 Mar 2007 22:19:52 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>>> Shouldn't getting/putting the module refcount be solely done in
>>> kobject.c? Grab the module reference when the kobject is created and
>>> release the module reference in kobject_cleanup() aft
On Fri, 30 Mar 2007 22:58:39 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> It's a little bit more convoluted than that. Module reference count of
> zero doesn't indicate that there is no one referencing the module. It
> just means that the module can be unloaded. ie. There still can be any
> nu
Cornelia Huck wrote:
> On Fri, 30 Mar 2007 22:58:39 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> It's a little bit more convoluted than that. Module reference count of
>> zero doesn't indicate that there is no one referencing the module. It
>> just means that the module can be unloaded. i
On Fri, Mar 30, 2007 at 10:30:48AM -0400, Salyzyn, Mark wrote:
> Thanks for the info.
>
> Attached is the patch I feel will address this issue. As an added 'perk' I
> have also added the code to detect if the controller was previously
> initialized for interrupted operations by ANY operating sys
Resending patch file.
I looked at the submission that showed on the list, and the original email, and
a blank line dropped away at line 20 of the patch (!)
Dunno, hope this comes through this second time. But if not, please add the
blank line as referenced.
Sincerely -- Mark Salyzyn
> -Or
On Fri, Mar 30, 2007 at 01:21:33PM -0400, Salyzyn, Mark wrote:
> Resending patch file.
>
> I looked at the submission that showed on the list, and the original email,
> and a blank line dropped away at line 20 of the patch (!)
>
> Dunno, hope this comes through this second time. But if not, plea
On Fri, Mar 30, 2007 at 06:43:02PM +0900, Tejun Heo wrote:
> Hello, all.
>
> This document tries to describe lifetime problems of the current
> device driver model primarily from the point view of device drivers
> and establish consensus, or at least, start discussion about how to
> solve these pr
On Fri, Mar 30, 2007 at 10:38:00PM +0900, Tejun Heo wrote:
> James Bottomley wrote:
> > On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
> >> Orphaning sysfs nodes on unregistration is a big step in this
> >> direction. With sysfs reference counting out of the picture,
> >> implementing 'discon
On Fri, 2007-03-30 at 09:15 -0400, Dmitry Torokhov wrote:
> If you want to manage lifetime rules independently you might want to
> not embed struct device into you subsystems objects but attach them
> via pointers and use device_create(). Now that we orphan sysfs access
> upon unregistering device
On 3/30/07, James Bottomley <[EMAIL PROTECTED]> wrote:
On Fri, 2007-03-30 at 09:15 -0400, Dmitry Torokhov wrote:
> If you want to manage lifetime rules independently you might want to
> not embed struct device into you subsystems objects but attach them
> via pointers and use device_create(). Now
On Fri, 2007-03-30 at 22:38 +0900, Tejun Heo wrote:
> My plan was to make sysfs more independent from struct device/kobject.
> e.g. Something like the following.
That's sort of what I was reaching for too ... it just looks to me that
all the sysfs glue is in kobject, so they make a good candidate
My tree I am working on is 'more advanced' as it includes the series of other
patches submitted over the past week :-( We have some interference going on. I
suggest pulling this patch until the others have cleared.
I will submit a patch to you privately to work this issue shortly ...
Sincerely
On Sat, 31 Mar 2007 00:08:19 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> (3) make sure all existing kobjects are released by module exit function.
>
> For example, let's say there is a hypothetical disk device /dev/dk0
> driven by a hypothetical driver mydrv. /dev/dk0 is represented like the
>
On Mon, Mar 26, 2007 at 04:06:53PM -0500, James Bottomley wrote:
> On Mon, 2007-03-26 at 21:38 +0100, Christoph Hellwig wrote:
> > On Mon, Mar 26, 2007 at 03:35:47PM -0500, James Bottomley wrote:
> > > I agree the non-legacy (CardBus and beyond) ones can be built in. I
> > > thought the legacy 8 a
The internal id/lun mapping of st_vsc and st_vsc1 controllers is different
from st_shasta. The original driver code can only map first 16 'entities'
for st_vsc and st_vsc1 while there are actually 128 available.
Also the ST_MAX_LUN_PER_TARGET should be 8, although this can do
no harm because inq
After reset completed, the scsi error handler sends out START_STOP
and TEST_UNIT_READY to the device. For 'normal' devices these
commands will be handled by firmware. However, because the RAID
console only interfaces to scsi mid layer, the firmware will not process
these commands for it. This will
During hard bus reset of st_shasta controllers, 1 ms is not enough for
16-port controllers, although it's good for 8-port controllers. Extend the
wait time to 100 ms to allow bus resets finish successfully.
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/
Add debug information into abort and host_reset routine.
Change ioremap to ioremap_nocache.
Version updated to 3.6..1.
Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 9465f35..5a10cfa 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi
Ed Lin wrote:
The internal id/lun mapping of st_vsc and st_vsc1 controllers is different
from st_shasta. The original driver code can only map first 16 'entities'
for st_vsc and st_vsc1 while there are actually 128 available.
Also the ST_MAX_LUN_PER_TARGET should be 8, although this can do
no
Cornelia Huck wrote:
> On Sat, 31 Mar 2007 00:08:19 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> (3) make sure all existing kobjects are released by module exit function.
>>
>> For example, let's say there is a hypothetical disk device /dev/dk0
>> driven by a hypothetical driver mydrv. /dev
Tejun Heo wrote:
> Cornelia Huck wrote:
>> On Sat, 31 Mar 2007 00:08:19 +0900,
>> Tejun Heo <[EMAIL PROTECTED]> wrote:
>>
>>> (3) make sure all existing kobjects are released by module exit function.
>>>
>>> For example, let's say there is a hypothetical disk device /dev/dk0
>>> driven by a hypothe
31 matches
Mail list logo
