On Mon, 2 Apr 2007 04:59:43 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Okay, here's preliminary patch. I've tested it very lightly so it's
likely to contain bugs and definitely needs to be splitted.
Cool. However, there's something fishy there (not sure whether it's in
your patch or a latent
On Mon, Apr 02, 2007 at 04:59:43AM +0900, Tejun Heo wrote:
Dependencies between sysfs/kobject objects are clearer now and I think
I got the locking and referencing correct. This patch immediately
fixes 'sysfs attr grabbing the wrong kobject and module' problem -
sysfs and module lifetimes
On Mon, Apr 02, 2007 at 04:59:43AM +0900, Tejun Heo wrote:
Hello, James, Greg.
On Fri, Mar 30, 2007 at 01:19:34PM -0500, James Bottomley wrote:
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 for the
From: James Bottomley [EMAIL PROTECTED]
Subject: Re: SMP pass through interface via bsg
Date: Sun, 01 Apr 2007 22:57:42 -0500
On Mon, 2007-04-02 at 11:49 +0900, FUJITA Tomonori wrote:
I started to work on SMP pass through via bsg as a non-SCSI command
experimentation. I asked Doug to try the
Matt,
Have your resolved the unload race conditions yet?
We'd like to update lpfc for the async scans, but our testing gets blocked
very quickly by the bugs. The bugs are not necessarily specific to lpfc
or to FC.
Stack traces are below. Simple ismod/rmmod loop can trigger them
-- james s
James Bottomley wrote:
On Thu, 2007-03-29 at 15:25 -0500, Brian King wrote:
This is pretty much an open coded for loop ... how about just doing a
for loop as attached below?
Fine by me. I was simply coding it up to look like scsi_eh_tur.
Thanks,
Brian
The two advantages to this are:
James Bottomley wrote:
-- each SAS object (host, device, expander, etc) has the own bsg
device
I think so; probably attached via the transport class.
FYI - I understand the idea of a bsg device per object, but really, for
something that is used rarely, it's a bunch of overhead. Objects,
On Mon, 2 Apr 2007, Joerg Schilling wrote:
Hi,
this is a repost as I like to know the current state of the problem...
The USB DMA size problem is known to exist on Linux since February 2004.
I am still in hope that there will be a fix soon.
Me too. I submitted the most recent version of
On Mon, Apr 02 2007, Alan Stern wrote:
On Mon, 2 Apr 2007, Joerg Schilling wrote:
Hi,
this is a repost as I like to know the current state of the problem...
The USB DMA size problem is known to exist on Linux since February 2004.
I am still in hope that there will be a fix soon.
On Mon, 2007-04-02 at 16:23 +0200, Jens Axboe wrote:
FWIW, it had my ack, I think we were just waiting for Doug to ack the sg
bits.
And there's really nothing I can do (well, except write the thing) since
the changes are not in any SCSI pieces I maintain directly ... they're
block and sg.
On Mon, 2 Apr 2007 11:20:48 +0200,
Cornelia Huck [EMAIL PROTECTED] wrote:
Cool. However, there's something fishy there (not sure whether it's in
your patch or a latent bug in the ccw bus code that just has been
uncovered):
Similar bug when loading/unloading a module that creates a driver
James Smart wrote:
James Bottomley wrote:
-- each SAS object (host, device, expander, etc) has the own bsg
device
I think so; probably attached via the transport class.
FYI - I understand the idea of a bsg device per object, but really, for
something that is used rarely, it's a bunch
On Mon, 2007-04-02 at 21:43 +0900, FUJITA Tomonori wrote:
From: James Bottomley [EMAIL PROTECTED]
If you post the code, others who also have the hardware can try it
too ...
I've attached a patch against Jens' bsg tree and uploaed a patch
against the sgv4-tools tree:
Ed Lin wrote:
@@ -1007,6 +1008,11 @@ static int stex_abort(struct scsi_cmnd *
u32 data;
int result = SUCCESS;
unsigned long flags;
+
+ printk(KERN_INFO DRV_NAME
+ (%s): aborting command\n, pci_name(hba-pdev));
+ scsi_print_command(cmd);
+
scmd_printk
From: James Bottomley [EMAIL PROTECTED]
Subject: Re: SMP pass through interface via bsg
Date: Mon, 02 Apr 2007 11:02:01 -0500
On Mon, 2007-04-02 at 21:43 +0900, FUJITA Tomonori wrote:
From: James Bottomley [EMAIL PROTECTED]
If you post the code, others who also have the hardware can try it
On Tue, 2007-04-03 at 01:43 +0900, FUJITA Tomonori wrote:
OK. I found another bug in smp_test tool (sends bogus response buffer
len to kernel). I've uploaded a new patch:
http://zaal.org/bsg/smp-test2.diff
That sort of works; you have a final bug in that the manufacturer info
response frame
On Mon, 2007-04-02 at 09:45 -0400, James Smart wrote:
James Bottomley wrote:
-- each SAS object (host, device, expander, etc) has the own bsg
device
I think so; probably attached via the transport class.
FYI - I understand the idea of a bsg device per object, but really, for
-Original Message-
From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 31, 2007 2:27 AM
To: Ed Lin
Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; Promise_Linux
Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue
On Fri, Mar 30, 2007 at
On Sun, 2007-04-01 at 16:29 -0400, Douglas Gilbert wrote:
...
sas: phy3 added to port0, phy_mask:0x8
sas: DOING DISCOVERY on port 0, pid:2110
aic94xx: scb:0x80 timed out
This might be the problem.
I see this periodically when a phy goes out to lunch on my system ...
with me, it always seems
On Tue, Apr 03 2007, FUJITA Tomonori wrote:
From: James Bottomley [EMAIL PROTECTED]
Subject: Re: SMP pass through interface via bsg
Date: Mon, 02 Apr 2007 12:01:41 -0500
On Tue, 2007-04-03 at 01:43 +0900, FUJITA Tomonori wrote:
OK. I found another bug in smp_test tool (sends bogus
-Original Message-
From: Brian King [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 9:05 AM
To: Ed Lin
Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; Promise_Linux
Subject: Re: [PATCH 4/4] [SCSI]stex: minor cleanup and version update
Ed Lin wrote:
@@ -1007,6
On Mon, 2007-04-02 at 11:14 -0700, Ed Lin wrote:
I just saw the routine name scsi_eh_try_stu, and didn't notice the
allow_restart (partly because I thought it was not harmful...).
But the TEST_UNIT_READY must stay.
Sure ... I was just checking since your change log implied you'd seen
the
Jens Axboe wrote:
On Tue, Apr 03 2007, FUJITA Tomonori wrote:
From: James Bottomley [EMAIL PROTECTED]
Subject: Re: SMP pass through interface via bsg
Date: Mon, 02 Apr 2007 12:01:41 -0500
On Tue, 2007-04-03 at 01:43 +0900, FUJITA Tomonori wrote:
OK. I found another bug in smp_test tool
Duane discovered in the scsi-misc-2.6 code that the reset handler could
be called without the sync command handler set up resulting in a panic.
Judith discovered this issue within minutes and has recently reported
it. Here is a fix.
IMHO, this needs to be applied immediately regardless of the
On Mon, Apr 02 2007, Mike Christie wrote:
Jens Axboe wrote:
On Tue, Apr 03 2007, FUJITA Tomonori wrote:
From: James Bottomley [EMAIL PROTECTED]
Subject: Re: SMP pass through interface via bsg
Date: Mon, 02 Apr 2007 12:01:41 -0500
On Tue, 2007-04-03 at 01:43 +0900, FUJITA Tomonori
From: Jens Axboe [EMAIL PROTECTED]
Subject: Re: SMP pass through interface via bsg
Date: Mon, 2 Apr 2007 20:12:38 +0200
On Tue, Apr 03 2007, FUJITA Tomonori wrote:
From: James Bottomley [EMAIL PROTECTED]
Subject: Re: SMP pass through interface via bsg
Date: Mon, 02 Apr 2007 12:01:41 -0500
--- Tejun Heo [EMAIL PROTECTED] 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
This fixes a regression caused by commit:
2dc611de5a3fd955cd0298c50691d4c05046db97
The sense buffer code in scsi_send_eh_cmnd was changed to use
alloc_page() and a scatter list, but the sense data copy was not
updated to match so what we actually get in the sense buffer is total
grabage
On Mon, Apr 02, 2007 at 12:24:39PM -0700, David Miller wrote:
This fixes a regression caused by commit:
2dc611de5a3fd955cd0298c50691d4c05046db97
The sense buffer code in scsi_send_eh_cmnd was changed to use
alloc_page() and a scatter list, but the sense data copy was not
updated to
--- James Bottomley [EMAIL PROTECTED] wrote:
I'd favour trying to separate kobject and struct device for this ...
move all the sysfs stuff into kobject and device only stuff into struct
^^^
Currently the kobject implementation is pure and well-defined. It
Judith, another layer on this onion also discovered by Duane, the
interrupt enable handler also needed to be set ... The interrupt enable
was called from within the synchronous command handler.
My private email with the fix was sent a whole 5 minutes ahead of yours
;- Here is the jist of it for
Cool! Look forward to your results.
Sorry for being so snitty sounding with the 5 minute comment, I was just
admiring the pace of activity!
Sincerely -- Mark Salyzyn
-Original Message-
From: Judith Lebzelter [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 4:17 PM
To:
If a scsi device reports less than 36 bytes of standard inquiry
data, scsi core logs a KERN_INFO printk indicating this. It was
observed that this results in lots of clutter in the log on
systems with devices that respond to a SCSI Inquiry with PQ=3 or
PQ=1 with less than 36 bytes of inquiry
On Mon, Apr 02, 2007 at 04:20:22PM -0500, [EMAIL PROTECTED] wrote:
if (sdev-inquiry_len 36) {
- printk(KERN_INFO scsi scan: INQUIRY result too short (%d),
- using 36\n, sdev-inquiry_len);
+ SCSI_LOG_SCAN_BUS(1, printk(KERN_INFO scsi
On Mon, 2007-04-02 at 16:20 -0500, [EMAIL PROTECTED] wrote:
If a scsi device reports less than 36 bytes of standard inquiry
data, scsi core logs a KERN_INFO printk indicating this. It was
observed that this results in lots of clutter in the log on
systems with devices that respond to a SCSI
-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 31, 2007 7:22 AM
To: Ed Lin
Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue
On Fri, 2007-03-30 at 15:21 -0700, Ed Lin wrote:
-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 11:28 AM
To: Ed Lin
Cc: linux-scsi; linux-kernel; jeff; Promise_Linux
Subject: RE: [PATCH 3/4] [SCSI]stex: fix reset recovery for
console device
On Mon, 2007-04-02 at 11:14
James Bottomley wrote:
On Sun, 2007-04-01 at 16:29 -0400, Douglas Gilbert wrote:
...
sas: phy3 added to port0, phy_mask:0x8
sas: DOING DISCOVERY on port 0, pid:2110
aic94xx: scb:0x80 timed out
This might be the problem.
I see this periodically when a phy goes out to lunch on my system
Cornelia Huck wrote:
On Mon, 2 Apr 2007 11:20:48 +0200,
Cornelia Huck [EMAIL PROTECTED] wrote:
Cool. However, there's something fishy there (not sure whether it's in
your patch or a latent bug in the ccw bus code that just has been
uncovered):
Similar bug when loading/unloading a module
On Mon, 2007-04-02 at 13:57 -0500, Brian King wrote:
I agree. The reason the ipr adapter firmware added this UA
in this configuration was to support SCSI 1 reservations and
communicate to the host that any reservation previously
held to the disk array is now lost since the adapter was reset.
40 matches
Mail list logo
