Add a missing structure comment for the recently
added @list member.
Cc: Stephen Rothwell
Cc: Daniel Vetter
Cc: Christian König
Fixes: 8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
Reported-by: Stephen Rothwell
Signed-off-by: Luben Tuikov
---
include/d
On 2020-12-09 5:24 p.m., Stephen Rothwell wrote:
> Hi Luben,
>
> On Wed, 9 Dec 2020 16:58:07 -0500 Luben Tuikov wrote:
>>
>> Add a missing structure comment for the recently
>> added @list member.
>>
>> Signed-off-by: Luben Tuikov
>>
>>
Add a missing structure comment for the recently
added @list member.
Signed-off-by: Luben Tuikov
Cc: Stephen Rothwell
Cc: Daniel Vetter
Cc: Christian König
---
include/drm/gpu_scheduler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/gpu_scheduler.h b
On 2020-12-09 05:02, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/drm/gpu_scheduler.h:201: warning: Function parameter or member 'list'
> not described in 'drm_sched_job'
>
> Introduced by commit
On 2020-10-23 03:46, Takashi Iwai wrote:
> Hi,
>
> the amdgpu driver's ASSERT_CRITICAL() macro calls the
> kgdb_breakpoing() even if no debug option is set, and this leads to a
> kernel panic on distro kernels. The first two patches are the
> oneliner fixes for those, while the last one is the cl
On 2020-07-29 9:49 a.m., Alex Deucher wrote:
> On Wed, Jul 29, 2020 at 4:11 AM Christian König
> wrote:
>>
>> Am 28.07.20 um 21:29 schrieb Peilin Ye:
>>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing
>>> amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lock
--- On Tue, 2/12/08, James Bottomley [EMAIL PROTECTED]> wrote:
> > I understand what you are trying to do - I guess I
> just doubt the value
> > you've added by doing this. I think that
> there's going to be so much
> > customization that system vendors will want to add,
> that they are going
> >
--- On Tue, 2/12/08, James Bottomley [EMAIL PROTECTED]> wrote:
> > I apologize for taking so long to review this patch.
> I obviously agree
> > wholeheartedly with Luben. The problem I ran into
> while trying to
> > design an enclosure management interface for the SATA
> devices is that
> > there
--- On Tue, 2/12/08, Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote:
> Hi,
> I apologize for taking so long to review this patch. I
> obviously agree
> wholeheartedly with Luben. The problem I ran into while
> trying to
> design an enclosure management interface for the SATA
> devices is that
--- On Fri, 2/8/08, Alan Cox <[EMAIL PROTECTED]> wrote:
> The word "illegal" has a precise dictionary
> meaning of "prohibited by
> law". The error messages are therefore incorrect as so
> far nobody has
> made SCSI violations a criminal offence.
>
> This corrects scsi to match various other subsy
--- On Fri, 2/8/08, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote:
> > Is there an open iSCSI Target implementation which
> does NOT
> > issue commands to sub-target devices via the SCSI
> mid-layer, but
> > bypasses it completely?
> >
> >Luben
> >
>
> Hi Luben,
>
> I am guessing you mean
--- On Fri, 2/8/08, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
> > Is there an open iSCSI Target implementation which
> does NOT
> > issue commands to sub-target devices via the SCSI
> mid-layer, but
> > bypasses it completely?
>
> What do you mean? To call directly low level backstorage
> S
Is there an open iSCSI Target implementation which does NOT
issue commands to sub-target devices via the SCSI mid-layer, but
bypasses it completely?
Luben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
--- On Tue, 2/5/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > Wrong ... we don't export non-SCSI devices as
> SCSI
> > > (with the single and
> > > rather annoying exception of ATA via SAT).
> >
> > I didn't say you should do that. I had already
> > mentioned that vendors export such contr
--- On Tue, 2/5/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > > I guess the same could be said for STGT and
> SCST,
> > > right?
> > >
> > > You mean both of their kernel pieces are modular?
>
> > > That's correct.
> >
> > No, you know very well what I mean.
> >
> > By the same logic you
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > --- On Mon, 2/4/08, James Bottomley
> <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2008-02-04 at 18:01 -0800, Luben Tuikov
> wrote:
> > > > --- On Mon, 2/4/08, James Bottomley
> &g
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-02-04 at 18:01 -0800, Luben Tuikov wrote:
> > --- On Mon, 2/4/08, James Bottomley
> <[EMAIL PROTECTED]> wrote:
> > > > > The enclosure misc device is really
> just
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > The enclosure misc device is really just a
> library providing
> > > sysfs
> > > support for physical enclosure devices and their
> > > components.
> >
> > Who is the target audience/user of those facilities?
> > a) The kernel it
--- On Sun, 2/3/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> The enclosure misc device is really just a library providing
> sysfs
> support for physical enclosure devices and their
> components.
Who is the target audience/user of those facilities?
a) The kernel itself needing to read/write SE
--- On Mon, 1/28/08, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The ideal solution would be to do mapping against a
> different struct
> > device for each port, so that we could maintain the
> proper DMA mask for
> > each of them at all times. However I'm not sure if
> that's possible.
>
> I cannot
--- On Mon, 1/28/08, Robert Hancock <[EMAIL PROTECTED]> wrote:
> The trick is that if an ATAPI device is connected, we (as
> far as I'm
> aware) can't use ADMA mode, so we have to switch that
> port into legacy
> mode.
Can you double check this with the HW architect of the
HW DMA engine of the A
--- Rob Landley <[EMAIL PROTECTED]> wrote:
> On Sunday 14 October 2007 7:45:46 pm Luben Tuikov wrote:
> > Matthew's expletive and extremely rude response really shows
> > the general attitude of the linux-scsi people.
>
> No, it doesn't. James Bottomley ha
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-13 at 16:05 -0600, Matthew Wilcox wrote:
> > On Thu, Oct 11, 2007 at 08:11:21PM -0500, Rob Landley wrote:
> > > My impression from asking questions on the linux-scsi mailing list is
> > > that the
> > > scsi upper/middle/lower layer
You should run "git-update-server-info" in
pub/scm/linux/kernel/git/jgarzik/libata-dev.git.
info/refs disagrees with refs/heads/* .
Luben
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> [ I just sent this upstream to Andrew and Linus ]
>
> Now that I have nailed down the corruption problem
--- James Smart <[EMAIL PROTECTED]> wrote:
> Here's one pro for setting WWNs at arbitrary times...
>If the box is migrating applications (say containers) that want
>different SAN connectivity, where that connectivity (view) is based
>on their WWN, it would be really nice to selectively
--- 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. I
--- 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 /
--- Damien Wyart <[EMAIL PROTECTED]> wrote:
> > > > The reiser4 failure is unexpected. Could you please see if you can
> > > > capture a trace, let the people at [EMAIL PROTECTED] know?
>
> > > Ok, I've handwritten the messages, here they are :
>
> > > reiser4 panicked cowardly : reiser4[umount(2
--- [EMAIL PROTECTED] wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Sun, Dec 17, 2006 at 03:05:39AM -0800
> > On Sun, 17 Dec 2006 12:00:12 +0100
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > > Okay, I have identified the patch that causes the problem to appear,
> > > which
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-12-06 at 12:24 -0800, Luben Tuikov wrote:
> > NEEDS_RETRY _does_ terminate, after it exhausts the retries. But since
> > by the ASC value we know that no amount of retries is going to work,
> > this chu
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
> > case MEDIUM_ERROR:
> > + if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
> > + sshdr.asc == 0x13 || /* AMNF DATA FIELD */
> > + sshdr.asc == 0x1
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 5 Dec 2006 21:00:20 -0800 (PST) Luben Tuikov <[EMAIL PROTECTED]>
> > wrote:
> > --- Michael Reed <[EMAIL PROTECTED]> wrote:
> > > Luben Tuikov wrote:
> > > ...snip...
> > > >
--- Michael Reed <[EMAIL PROTECTED]> wrote:
> Luben Tuikov wrote:
> ...snip...
> > This statement in scsi_io_completion() causes the infinite retry loop:
> >if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> > return;
>
> The code in
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 30 Nov 2006 22:34:57 -0800 (PST)
> Luben Tuikov <[EMAIL PROTECTED]> wrote:
>
> > --- Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > On Wed, 29 Nov 2006 17:22:48 -0800 (PST)
> > > Luben Tuiko
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Nov 2006 17:22:48 -0800 (PST)
> Luben Tuikov <[EMAIL PROTECTED]> wrote:
>
> > Suppose reading sector 0 always reports an error,
> > sense key HARDWARE ERROR.
> >
> > What I'm observing
--- Luben Tuikov <[EMAIL PROTECTED]> wrote:
> Suppose reading sector 0 always reports an error,
> sense key HARDWARE ERROR.
>
> What I'm observing is that the request to read sector 0,
> reading partition information, is retried forever, ad infinitum.
>
> Doe
Suppose reading sector 0 always reports an error,
sense key HARDWARE ERROR.
What I'm observing is that the request to read sector 0,
reading partition information, is retried forever, ad infinitum.
Does anyone have a patch to resolve this? (2.6.19-rc6)
Thanks,
Luben
-
To unsubscribe from th
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13-mm2/Documentation/dontdiff -Naur
linux-2.6.13-mm2-orig/include/scsi/sas/sas.h
linux-2.6.13-mm2/include/scsi/sas/sas.h
--- linux-2.6.13-mm2-orig/include/scsi/sas/sas.h1969-12-31
19:00:00.0 -0500
+++
Andrew,
The following is a patchset of the SAS code as posted
today but it has the suggestions by Nish and Alexey,
and it is against -mm2 tree.
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13-mm2/Documentation/dontdiff -Nau
linux-2.6.13-mm2-orig/drivers/scsi/Kconfig
Those files live in include/scsi/sas/ and were missed in the
previous patchset:
sas.h
sas_class.h
sas_discover.h
sas_expander.h
sas_frames.h
sas_frames_be.h
sas_frames_le.h
sas_task.h
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-
On 09/09/05 16:05, Nish Aravamudan wrote:
> On 9/9/05, Luben Tuikov <[EMAIL PROTECTED]> wrote:
>
>>Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
>
>
>
>
>
>>--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_expander.c 1969-12-31
>>
On 09/09/05 16:18, Alexey Dobriyan wrote:
> On Fri, Sep 09, 2005 at 03:32:05PM -0400, Luben Tuikov wrote:
>
>>--- linux-2.6.13-orig/drivers/scsi/aic94xx/Makefile
>>+++ linux-2.6.13/drivers/scsi/aic94xx/Makefile
>
>
>>+CHECK = sparse -Wbitwise
>
>
>
On 09/09/05 15:59, Nish Aravamudan wrote:
> On 9/9/05, Luben Tuikov <[EMAIL PROTECTED]> wrote:
>
>>Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
>
>
>
>
>
> +static int sas_execute_task(struct sas_task *task, void *buffer, int size,
>
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_common.c
linux-2.6.13/drivers/scsi/sas-class/sas_common.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_common.c 1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_internal.h
linux-2.6.13/drivers/scsi/sas-class/sas_internal.h
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_internal.h 1969-12-31
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_init.c
linux-2.6.13/drivers/scsi/sas-class/sas_init.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_init.c 1969-12-31
19:00:00.0
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_tmf.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_tmf.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_tmf.c1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_task.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_task.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_task.c 1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
Attached in gzipped format, since it is so big.
aic94xx_seq_microcode.patch.gz
Description: GNU Zip compressed data
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_scb.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_scb.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_scb.c1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_init.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_init.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_init.c 1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dump.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_dump.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dump.h 1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_seq.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_seq.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_seq.c1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_phy.c
linux-2.6.13/drivers/scsi/sas-class/sas_phy.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_phy.c 1969-12-31
19:00:00.0
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_hwi.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_hwi.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_hwi.h1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_reg.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_reg.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_reg.c1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_sas.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_sas.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_sas.h1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_dump.h
linux-2.6.13/drivers/scsi/sas-class/sas_dump.h
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_dump.h 1969-12-31
19:00:00.0
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dump.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_dump.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dump.c 1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_seq.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_seq.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_seq.h1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_dump.c
linux-2.6.13/drivers/scsi/sas-class/sas_dump.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_dump.c 1969-12-31
19:00:00.0
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_port.c
linux-2.6.13/drivers/scsi/sas-class/sas_port.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_port.c 1969-12-31
19:00:00.0
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_hwi.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_hwi.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_hwi.c1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/README
linux-2.6.13/drivers/scsi/sas-class/README
--- linux-2.6.13-orig/drivers/scsi/sas-class/README 1969-12-31
19:00:00.0 -0500
+++
this, so that the host
adapter firmware gets less interrupts.
DBMS machines may want to run in this mode.
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_scsi_host.c
linux-2.6.13/drivers/scsi/sas
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_event.c
linux-2.6.13/drivers/scsi/sas-class/sas_event.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_event.c1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_discover.c
linux-2.6.13/drivers/scsi/sas-class/sas_discover.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_discover.c 1969-12-31
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_reg.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_reg.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_reg.h1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_sds.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_sds.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_sds.c1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_expander.c
linux-2.6.13/drivers/scsi/sas-class/sas_expander.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_expander.c 1969-12-31
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/Kconfig
linux-2.6.13/drivers/scsi/sas-class/Kconfig
--- linux-2.6.13-orig/drivers/scsi/sas-class/Kconfig1969-12-31
19:00:00.0 -0500
+++
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/Makefile
linux-2.6.13/drivers/scsi/sas-class/Makefile
--- linux-2.6.13-orig/drivers/scsi/sas-class/Makefile 1969-12-31
19:00:00.0 -0500
+++
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/expander_conf.c
linux-2.6.13/drivers/scsi/sas-class/expander_conf.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/expander_conf.c1969-12-31
Using the User Space Expander configuration utility
===
The file "expander_conf.c" is a user space program
which uses the "smp_portal" SMP portal to communicate
with expanders in the domain.
It gives you complete control of the expander you're
talki
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx.h1969-12-31
19:00:00.0 -0500
+++
This email shows an example of two domains.
The first domain has only two devices: the SAS initiator
and a SAS end device (a disk).
The second domain has expanders, SAS disks, a SATA II disk
and a SATAPI disk.
A succinct and full listings of the sysfs tree are shown
using the tree(1) program.
Sam
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/README
linux-2.6.13/drivers/scsi/aic94xx/README
--- linux-2.6.13-orig/drivers/scsi/aic94xx/README 1969-12-31
19:00:00.0 -0500
+++ linux-
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dev.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_dev.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dev.c1969-12-31
19:00:00.000
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/Kconfig
linux-2.6.13/drivers/scsi/aic94xx/Kconfig
--- linux-2.6.13-orig/drivers/scsi/aic94xx/Kconfig 1969-12-31
19:00:00.0 -0500
+++
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/Makefile
linux-2.6.13/drivers/scsi/aic94xx/Makefile
--- linux-2.6.13-orig/drivers/scsi/aic94xx/Makefile 1969-12-31
19:00:00.0 -0500
+++
On 08/28/05 23:54, Trond Myklebust wrote:
> må den 29.08.2005 Klokka 13:37 (+1000) skreiv Nick Piggin:
>
>>James Bottomley wrote:
>>
>>>On Sun, 2005-08-28 at 18:35 -0700, Andrew Morton wrote:
>>
It does make the tree higher and hence will incur some more cache missing
when descending the t
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-08-21 at 10:27 -0700, Luben Tuikov wrote:
> > Is this the only use _you_ could find for a *radix tree*? ;-)
> > Since of course sd.c uses it just as an enumeration, according to
> > you this must be the o
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-08-21 at 08:49 -0700, Luben Tuikov wrote:
> > The caller is the aic94xx SAS LLDD. It uses IDR to generate unique
> > task tag for each SCSI task being submitted. It is then used to lookup
> > the task gi
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 en
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?
>
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-08-21 at 08:49 -0700, Luben Tuikov wrote:
> > The caller is the aic94xx SAS LLDD. It uses IDR to generate unique
> > task tag for each SCSI task being submitted. It is then used to lookup
> > the task gi
--- Luben Tuikov <[EMAIL PROTECTED]> wrote:
> --- James Bottomley <[EMAIL PROTECTED]> wrote:
> > However, there is an infrastructure in the block layer called the
> > generic tag infrastructure which was designed precisely for this purpose
> > and which is d
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> Jim Houston <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2005-08-16 at 18:03, Luben Tuikov wrote:
> >
> > > If idr_get_new() or idr_remove() is used in IRQ context,
> > > then we may get a lockup w
On 08/19/05 17:10, Patrick Mansfield wrote:
> Luben -
>
> On Fri, Aug 19, 2005 at 04:43:41PM -0400, Luben Tuikov wrote:
>
>>On 08/19/05 16:11, Patrick Mansfield wrote:
>
>
>>>I was changing it to wakeup the eh even while other IO is outstanding, so
>>&
On 08/19/05 16:29, Mike Anderson wrote:
> Luben Tuikov <[EMAIL PROTECTED]> wrote:
>>Consider this: When SCSI Core told you that the command timed out,
>> A) it has already finished,
>> B) it hasn't already finished.
>>
>>In case A, you c
On 08/19/05 16:11, Patrick Mansfield wrote:
> On Fri, Aug 19, 2005 at 04:03:15PM -0400, Luben Tuikov wrote:
>>The eh_timed_out + eh_strategy_handler is actually pretty perfect,
>>and _complete_, for any application and purpose in recovering a
>
>
> One other point: Ano
On 08/19/05 15:38, Patrick Mansfield wrote:
> On Fri, Aug 19, 2005 at 02:46:35PM -0400, Luben Tuikov wrote:
>
>
>>Using the command time out hook and the strategy routine, gives _complete_
>>control over host recovery, and I really do mean _complete_.
>>
>
On 08/19/05 01:40, Tejun Heo wrote:
> I genearally agree that the events are somewhat standard for block
> devices but IMHO SCSI EH also has fair amount SCSI-specific assumptions
> and ATA is a bit too different from SCSI to fit cleanly into it. For
> example, when handling NCQ errors, the wh
On 08/18/05 23:49, Jeff Garzik wrote:
> 1) The fine-grained hooks of the SCSI layer are somewhat standard for
> block devices. The events they signify -- timeout, abort cmd, dev
> reset, bus reset, and host reset -- map precisely to the events that we
> must deal with at the ATA level.
"dev re
Hi,
This patch encloses the idr.h header file in
#ifndef __IDR_H__ macro.
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
--- linux-2.6.12.5/include/linux/idr.h.old 2005-08-16 17:20:15.0
-0400
+++ linux-2.6.12.5/include/linux/idr.h 2005-08-16 17:21:11.0 -0400
@
spin_lock to spin_lock_irqsave,
and spin_unlock to spin_unlock_irqrestore, to allow
idr_get_new(), idr_find() and idr_remove() to be
called from IRQ context, while idr_pre_get() to be
called in process context.
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
--- linux-2.6.12.5/lib/idr
Hi,
This patch encloses the idr.h header file in
#ifndef __IDR_H__ macro.
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
--- linux-2.6.12.5/include/linux/idr.h.old 2005-08-16 17:20:15.0
-0400
+++ linux-2.6.12.5/include/linux/idr.h 2005-08-16 17:21:11.0 -0400
@
spin_lock to spin_lock_irqsave,
and spin_unlock to spin_unlock_irqrestore, to allow
idr_get_new(), idr_find() and idr_remove() to be
called from IRQ context, while idr_pre_get() to be
called in process context.
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
--- linux-2.6.12.5/lib/idr
On 08/15/05 21:08, James Bottomley wrote:
>>Think if SCSI used this same style of representation. For example,
>>if there was no scsi target device entity, but class entities did
>>exist and they just pointed back to the scsi host device entry.
>
>
> Yes, it's theoretically possible to have had S
1 - 100 of 108 matches
Mail list logo
