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
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
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
--- 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
> >
--- 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 is all
--- 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 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
there
--- 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
--- 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 subsystems
I've
--- 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
--- 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
>
--- 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
SCSI drivers
--- 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 futher down the
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
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 info
--- 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
--- 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
--- 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're preaching to include
--- 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 controls
as either
--- 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
--- 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
--- 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 SES
--- 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 itself needing to
--- 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 a
library providing
sysfs
support for physical enclosure
--- 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
--- 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
--- 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 imagine why
--- 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 ASIC?
--- 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 has been exc
--- 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 has been exceedingly polite and helpful, as
were
--- 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
--- 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 layers doesn't use
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
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, I can
--- 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 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 set
--- 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.
--- 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
--- 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
--- 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
--- 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 :
--- [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,
> > >
--- 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(2451)] :
--- [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 is
--- 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
--- 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 chunk of the patch resolves it quicker, i.e
--- 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 ==
--- 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 == 0x14) { /*
--- 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
--- 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 2.6.19 is result==0, not !!result, which
--- 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...
This statement in scsi_io_completion() causes the infinite retry loop
--- 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 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 Tuikov [EMAIL PROTECTED] wrote:
Suppose reading sector 0 always
--- 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 is t
--- 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 is that the request to read sector 0,
reading partition
--- 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.
>
> Does any
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
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
--- 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.
Does anyone have a patch to resolve
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
+++
1 - 100 of 206 matches
Mail list logo
