patch helped an ASMedia controller talking to the asx189_178a ethernet
hardware.
David
From:
> On 01/17/2014 06:34 AM, David Laight wrote:
>
> > Can you try the patch I posted that stops the ownership on LINK TRBs
> > being changed before that on the linked-to TRB?
>
> Sadly, the patch didn't fix the ASMedia lockup behavior, however :(
>
> I
From: walt
> On 01/17/2014 06:34 AM, David Laight wrote:
>
> > Can you try the patch I posted that stops the ownership on LINK TRBs
> > being changed before that on the linked-to TRB?
>
> Please disregard my earlier post about the patch not applying cleanly.
> That wa
From: Sarah Sharp
> On Mon, Jan 20, 2014 at 11:21:14AM +0000, David Laight wrote:
...
> > A guess...
> >
> > In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead
> > of xhci_td_remainder().
>
> Why? Walt has a 0.96 xHCI host controller, and the for
From: walt
> On 01/21/2014 01:51 AM, David Laight wrote:
> > From: Sarah Sharp
> >> On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
> > ...
> >>> A guess...
> >>>
> >>> In queue_bulk_sg_tx() try calling xhci_v1_0_td_remai
measure the results.
I don't know if md and dm are currently smart enough to realize that the entire
stripe is being overwritten and avoid the RMW cycle. If they can't, I would
expect that once we start measuring it, they will gain such support.
David Lang
--
To unsubscribe from this li
DPO or FUA
[ 198.485850] sda: sda1
[ 198.485926] sd 0:0:24:1089486880: [sda] Enabling DIX T10-DIF-TYPE1-IP
protection
[ 198.487652] sd 0:0:24:1089486880: [sda] Attached SCSI disk
[ 276.566682] XFS (sda1): Mounting Filesystem
[ 276.576558] XFS (sda1): Ending clean mount
Signed-off-by: David Milburn
On 02/03/2014 09:55 PM, Martin K. Petersen wrote:
"David" == David Milburn writes:
David> When enabling DIX T10-DIF-TYPE1-IP protection you can hit the
David> bip_vec full condition which fails to attach the integrity
David> metadata and returns 0 back to bio_integrity_prep
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Mon, 16 Jul 2007 11:47:27 +0200
> This updates the sparc iommu/pci dma mappers to sg chaining.
>
> Cc: [EMAIL PROTECTED]
> Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To un
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Mon, 16 Jul 2007 11:47:28 +0200
> This updates the sparc64 iommu/pci dma mappers to sg chaining.
>
> Cc: [EMAIL PROTECTED]
> Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
I think these reports all point to a problem with the sparc32
kernel far outside of the drivers in question.
We have no reports like this on sparc64.
My running theory is that things like msleep() are returning
immediately on sparc32, or at least too fast, instead of delaying
the minimum necessa
From: Mark Fortescue <[EMAIL PROTECTED]>
Date: Fri, 20 Jul 2007 21:27:42 +0100 (BST)
> I have found that on my sun4c, I need to increase the ESP_BUS_TIMEOUT from
> 250ms to 275ms when I build the ESP driver into the kernel or the ESP
> does not find the disk.
>
> If I build the driver as a modu
James, can you queue this up to Linus? Thanks a lot!
[SCSI] ESP: Increase ESP_BUS_TIMEOUT to 275.
This matches the original driver's value and seems to be
necessary for some disks on sun4c systems.
Reported by Mark Fortescue <[EMAIL PROTECTED]>
Signed-off-by: David S. Mil
From: Mark Fortescue <[EMAIL PROTECTED]>
Date: Mon, 23 Jul 2007 23:41:34 +0100 (BST)
> I can also get the ESP driver to fail to find disks with the same error
> codes if I build it as a module driver however if I build the ESP driver
> into the kernel, it does not fail (ESP BUS_TIMEOUT=275).
Th
From: James Bottomley <[EMAIL PROTECTED]>
Date: Mon, 23 Jul 2007 19:50:23 -0500
> On Mon, 2007-07-23 at 23:41 +0100, Mark Fortescue wrote:
> > For targets with a disk connected, I get scan responses of:
> > scsi scan: INQUIRY failed with code 0x802
> > after app 170ms.
>
> Thats SCSI sta
rom: "root" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Thu, 19 Jul 2007 20:07:22 +0400
Sender: "David S. Miller" <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.15 (2007-04-06)
Fake-Sender:[EMAIL PROTECTED]
Sparc optimized memset
From: Mark Fortescue <[EMAIL PROTECTED]>
Date: Tue, 24 Jul 2007 22:28:42 +0100 (BST)
> I thought I rememberd seeing somthing about memset.
>
> Having changed the memset code, I have found that the ESP scsi BUS
> Timeout can be reverted back to 250ms. Both SCSI drivers are now working
> properly
timeout value than to
leave it increased when there is no reason for doing so.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index 856e38b..d5576d5 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -220,7
Reduce the length of some printk messages and make the messages
> more consistant. All cosmetic but it makes it easier to read as it
> scrolles off the screen during boot.
>
> Signed-off-by: Mark Fortescue <[EMAIL PROTECTED]>
I'm fine with this:
Signed-off-by: David S. Miller
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Mon, 6 Aug 2007 17:24:58 -0600
> @@ -514,11 +514,14 @@ struct esp {
>
> struct completion *eh_reset;
>
> - struct sbus_dma *dma;
> + union {
> + struct sbus_dma *sbus_dma;
> + unsigned intx86
exportable headers.
>
> /usr/include/scsi is provided by glibc.
> Remove the scsi export from make headers_install target.
>
>
> Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
Acked-by: David Woodhouse <[EMAIL PROTECTED]>
> ---
> include/Kbuild |
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Wed, 15 Aug 2007 11:26:00 -0600
> On Tue, Aug 07, 2007 at 12:26:04AM -0700, David Miller wrote:
> > > - struct sbus_dma *dma;
> > > + union {
> > > + struct sbus_dma *sbus_dma;
>
Because the ->unique_id is set too late, the ESP scsi host
instance numbers in the kernel log during probing are
wrong.
Bug reported by Meelis Roos.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 77b06a9..95cf7
ings that we've
tried to make sure specifically aren't declared.
David
---
[PATCH] VFS: Make BSG declarations dependent on CONFIG_BLOCK
From: David Howells <[EMAIL PROTECTED]>
Make BSG function declarations dependent on CONFIG_BLOCK as they are not
compilable if the block layer i
From: James Bottomley <[EMAIL PROTECTED]>
Date: Tue, 25 Sep 2007 20:00:02 -0500
> David Miller (1):
> esp: fix instance numbering.
I'd like to request that this one goes into 2.6.23 as
it is a bug fix and the bug confuses users.
Thanks.
-
To unsubscribe from this li
> > autosuspend. It's not supposed to work by the higher level announcing:
> > "I want to autosuspend now, so all you lower guys had better get
> > ready."
>
> I see. And there's an appealing simplicity to it. But why insist that
> this is the one true way?
I was unaware there was another defin
don't have the time to setup things for testing this patch on
the qlogicpti hardware I have, but with the scsi_rbuf_{get,put}()
deletion added to the patch I would really like to see this go
into 2.6.24 anyways.
If things explode I'll pick up the pieces.
Acked-by: David S. Miller <[E
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun, 30 Sep 2007 20:52:45 -0400
> David Miller wrote:
> > It compiles :-) You deleted the only uses of scsi_rbuf_{get,put}()
> > so you can kill those off too.
>
>
> Seeing as how they are exact duplicates of libata
From: Luben Tuikov <[EMAIL PROTECTED]>
Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT)
> Your "want to get their card working" way of view is very
> simplistic to justify generating and assigning SAS WWN in the kernel.
> This is the job of the manufacturer/packager, not the host OS.
When you are thous
From: James Bottomley <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 18:09:06 -0400
> For the record, what the current in-kernel aic94xx driver does for this
> case is allow a parameter override to specify the WWN in the case where
> the card burned in one has gone missing or is corrupt. I think this
From: James Bottomley <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 18:14:48 -0400
> On Fri, 2007-10-05 at 15:11 -0700, David Miller wrote:
> > auto_wwn=1 or somthing like that
>
> I'd far prefer
>
> override_wwn =
>
> since I assume auto_wwn means ge
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 18:41:40 -0400
> And that's been my plan from day one... which is remarkably a lot like
> the behavior of several net drivers. :)
>
> * attempt to read WWN during module load
> * admin may optionally choose to manually specify OR aut
From: James Bottomley <[EMAIL PROTECTED]>
Date: Sat, 06 Oct 2007 09:11:10 -0500
> My problem with auto generated is that it's provably impossible to
> generate globally unique numbers for WWNs without some internal source
> of uniqueness (I know sparcs have this in their serial number, but most
>
From: James Bottomley <[EMAIL PROTECTED]>
Date: Sat, 06 Oct 2007 10:04:55 -0500
> If you remember Rusty's guide to interfaces, this is a level 14 easy to
> misuse interface: "The obvious use is wrong"; since the obvious use is
> to put it in module parameters and have the problem go away (for
> no
From: Boaz Harrosh <[EMAIL PROTECTED]>
Date: Wed, 10 Oct 2007 20:25:30 +0200
>
> - convert to accessors and !use_sg cleanup
>
> Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send th
t,exit}.
> >
> > Based on a bug report by Rob Landley.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> Acked-by: Rob Landley <[EMAIL PROTECTED]>
I'm fine with this fix too.
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscrib
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 11 Oct 2007 11:20:58 -0700
> Well if fc4.c compiles OK on non-sparc64 then perhaps we should enable
> compilation on non-sparc64. It will increase maintainability and code
> quality and stuff.
No objections to including drivers/fc4/Kconfig direc
From: James Bottomley <[EMAIL PROTECTED]>
Date: Fri, 12 Oct 2007 13:04:33 -0500
> On Thu, 2007-10-11 at 17:38 -0700, David Miller wrote:
> > From: Andrew Morton <[EMAIL PROTECTED]>
> > Date: Thu, 11 Oct 2007 11:20:58 -0700
> >
> > > Well if fc4.c compile
Matthew Wilcox wrote:
You really need to get the fuck over yourself.
That is so rude. You need to learn some manners.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-i
rdware to test
> it any more. I talked to Dave Miller about it, and he agrees we can
> delete it. If anyone wants a software FC stack in future, they can
> retrieve this driver from git.
>
> Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Acked-
Nick Piggin wrote:
On Monday 15 October 2007 19:52, Rob Landley wrote:
On Monday 15 October 2007 8:37:44 am Nick Piggin wrote:
You really shouldn't configure
so much [swap] unless you do want the kernel to actually use it all, right?
Two words: "Software suspend". I've actually
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 09:21:49 +0200
> On Wed, Oct 17 2007, FUJITA Tomonori wrote:
> > Commit 2c941a204070ab32d92d40318a3196a7fb994c00 looks incomplete. The
> > helper functions like prepare_sg() need to support sg chaining too.
>
> Thanks Tomo, applied. I'll
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 01:33:25 -0700 (PDT)
> sg_next() gives you a NULL after the last entry, but tests have been
> changed to compare against sg_last() which is likely not what we
> want for those checks.
This of course isn't true, ig
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 10:45:28 +0200
> Righto, it's invalid to call sg_next() on the last entry!
Unfortunately, that's what the sparc64 code wanted to do, this
transformation in the sparc64 sg chaining patch is not equilavent:
- struct scatterlist *sg_
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 18:24:01 +0900
> On Wed, 17 Oct 2007 11:16:29 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Oct 17 2007, David Miller wrote:
> > > I would suggest that other sg_last() uses be audi
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 11:16:29 +0200
> On Wed, Oct 17 2007, David Miller wrote:
> > From: Jens Axboe <[EMAIL PROTECTED]>
> > Date: Wed, 17 Oct 2007 10:45:28 +0200
> >
> > > Righto, it's invalid to call sg_n
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 12:58:40 +0200
> The problem is that you cannot zero the entire sg entry, because then
> you'd potentially overwrite the chain pointer.
>
> I'd propose just adding a
>
> sg_dma_address(sg) = 0;
> sg_dma_len(sg) = 0;
>
>
on top of Fujita-san's most recent
sparc64 patch and we should be good to go.
>From 0f6e2c3085ec57df78b249a8722323692f33a1b2 Mon Sep 17 00:00:00 2001
From: David S. Miller <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 04:08:48 -0700
Subject: [PATCH] [SPARC64]: Fix loop terminating conditio
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Wed, 17 Oct 2007 13:11:46 +0200
> On Wed, Oct 17 2007, David Miller wrote:
> > Jens, please also add the following on top of Fujita-san's most recent
> > sparc64 patch and we should be good to go.
>
> Awesome, thanks.
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 15:04:31 +1000
> At least for now.
>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscr
From: Tuomas Vainikka
Date: Thu, 12 Sep 2013 18:36:09 +0300
> Does anyone have the register descriptions for the FAS216 chip? It
> would seem that receiving only one byte during reconnect is perfectly
> normal [1] unless SCSI-2 features are explicitly enabled (which
> esp_scsi doesn't seem to be
From: Michael Schmitz
Date: Mon, 7 Apr 2014 08:33:12 +1200
> Hello Dave, Tuomas,
>
>>> Also, looking at the timeout formulae in the old NCR53C9x.c driver,
>>> the values would be different for FAS216. Why was this dropped from
>>> the modern esp_scsi?
>>
>> I've never seen a formula for any ESP
On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote:
> [+ David, VT-d maintainer ]
>
> Jiang, David, can you please have a look into this issue?
>
> > > >> > > > > DMAR:[fault reason 02] Present bit in context entry is clear
> > > >
ext command to time out (however far in time from the first
failure) will trigger the medium access timeout and put the device offline.
The resetting of sdkp->medium_access_timed_out should occur before the check
for sense data.
Signed-off-by: David Jeffery
---
To reproduce using scsi_debu
;t care how *you* deal with them, or even if you
can. All I want to know is how I tell you about the problem, because *I*
sure as hell don't want to be trying to deal with it in the IOMMU code.
That's a generic PCI layer thing. :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
e address 0x7f61e000 is in an E820-reserved region,
and that there's and RMRR covering that region for an unspecified PCI
device, but that's going to be the hpsa.
So if isn't just a simple case of us assigning this device to the wrong
IOMMU, *perhaps* it's that we lose the RMRR
hes. That's another case where we need to preserve the
RMRR mapping after the driver takes over — and it *was* working.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
PCI_SLOT(devfn), PCI_FUNC(devfn), drhd->reg_base_addr);
+ else
+ printk("Device %x:%02x:%02x.%d on no IOMMU\n", segment, bus,
+ PCI_SLOT(devfn), PCI_FUNC(devfn));
return iommu;
}
--
Sent with Evolut
testing the following patch?
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong
Reported-by: Michael Schmitz
Signed-off-by: David S. Miller
diff --git a/drivers/s
you know as soon as I can
> test it later today.
Thanks.
Jiang, if you can then let me have a copy with a signed-off-by I'll
shepherd it upstream along with your other patch which is already in my
iommu-2.6.git tree.
--
Sent with Evolution's ActiveSync sup
On Wed, 2014-04-16 at 15:37 +0200, j...@8bytes.org wrote:
> Hey David,
>
> On Mon, Apr 14, 2014 at 05:03:51PM +, Woodhouse, David wrote:
> > Jiang, if you can then let me have a copy with a signed-off-by I'll
> > shepherd it upstream along with your other pa
On Fri, 25 Apr 2014, James Bottomley wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 65a123d..9db097a 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -137,6 +137,7 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd,
> int reason, i
tion on this point.
All SCSI transports are supposed to behave the same way. I hope this
can be corrected quickly.
Thanks,
--David
> -Original Message-
> From: Sagi Grimberg [mailto:sa...@dev.mellanox.co.il]
> Sent: Sunday, May 25, 2014 11:31 AM
> To: martin.peter...@
ld they be left as is, or changed to use ==?
Do we want to add an extra test to find_first_zero_bit() and effectively
slow down all the calls - especially those where the length is a
multiple of 8 (probably the most common).
Maybe the documented return code should be changed to allow for the
existing behaviour.
ssary. == for the failure test is fine.
There is nothing wrong with defensive coding.
The 'tmp |= ~0UL << size' ensures that the return value is 'correct'
when there are no bits set.
The function could have been defined so that this wasn't needed.
If you assume tha
ript and some typing.
For networking bits:
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e cannot be
restored or migrated?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
However that still might not force an actual disc access.
In any case you really only want to do a read, doing a write will kill the NAND
memory.
David
N�r��yb�X��ǧv�^�){.n�+{���"�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i
From: loody
...
> but what it really do is read sector, not media_change or test_unit_ready.
Maybe one of the programs that reads the mbr partition table can
be persuaded to do a direct read?
David
On Wed, 2014-07-09 at 15:57 +0200, Bart Van Assche wrote:
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -1644,10 +1644,14 @@ static void srp_process_rsp(struct srp_target_port
> *target, struct srp_rsp *rsp)
>SCSI_S
From: Anish Bhatt
Date: Tue, 15 Jul 2014 19:55:52 -0700
> +#define pr_info_ipaddr(fmt_trail,\
> + addr1, addr2, args_trail...)\
Barf... use "%pIS" instead, which takes a pointer to a sockaddr of family
AF_INET or AF_INET
From: Anish Bhatt
Date: Thu, 17 Jul 2014 00:18:14 -0700
>The following patchset add ipv6 support for the cxgb4i(iscsi) driver.
>
> Patch 1 moves a define from the iw_cxgb4 to cxgb4 to prevent code duplication,
> as it is used by cxgb4i and iw_cxgb4 both.
> Patch 2 exports symbols needed by
The FRV bits look okay. I can't test them until I get back from Australia in
Feb.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
rn 1;
} while (test_and_set_bit(tag, bqt->tag_map));
Please see the following link for the discussion
http://marc.theaimsgroup.com/?l=linux-scsi&m=115886351206726&w=2
Cheers
David Somayajulu
QLogic Corporation
-
To unsubscribe from this list: send the line "unsubscribe l
Fine by me.
Acked-By: David Howells <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 27, 2007 8:08 AM
> On Mon, 2007-01-22 at 12:26 -0800, David C Somayajulu wrote:
> > The included patch fixes the following issues:
> > 1. qla3xxx/qla4xxx co-existence issue which can result in a locku
esses larger than 32-bits,
causing the hardware to use bounce buffers (and is thus slow, and also
happened to expose a bug in swiotlb).
-David
On Sun, 2007-02-04 at 13:05 +0100, Stefan Richter wrote:
> In order to use OHCI physical DMA, all s/g elements, s/g tables, ORBs,
> and response buff
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 6 Feb 2007 13:29:17 -0800
> Apparently a recent regression.
It's on sparc32 (and SMP on top of that, scary) which is only lightly
maintained, so it could be anything. It would be interesting if
running a uniprocessor kernel made the problem go a
od never loaded. (Except
when using the obsolete old-style hotplug scripts ... which are unusable
on ~100 BogoMIPS embedded systems that only run busybox, but may have no
options for lots of external storage other than USB.) Yep, this is a LOT
faster too.
Signed-off-by: David Brownell <[EMAIL PROTEC
On Wednesday 21 March 2007 4:01 am, Michael Tokarev wrote:
> David Brownell wrote:
> > This teaches scsi devices how to support "new style" hotplug/coldplug:
> > using a modalias sysfs attribute for coldplug, and MODALIAS environment
> > variable for hotplug.
>
ix this by using page_address(sgl.page) which is OK
because we know this is low-mem due to GFP_ATOMIC.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index b8edcf5..918bb60 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/
From: Andrew Burgess <[EMAIL PROTECTED]>
Date: Thu, 5 Apr 2007 15:13:27 -0700
> David, do you see any other problems with scsi_send_eh_cmnd?
>
> I've switched back to 2.6.18 which seems to not oops
> and am happy to try patches.
Does 2.6.20 with my patch OOPS too? Does
From: James Bottomley <[EMAIL PROTECTED]>
Date: Thu, 05 Apr 2007 19:02:19 -0500
> On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
> > From: Andrew Burgess <[EMAIL PROTECTED]>
> > Date: Thu, 5 Apr 2007 15:13:27 -0700
> >
> > > David, do you see
From: James Bottomley <[EMAIL PROTECTED]>
Date: Fri, 06 Apr 2007 10:27:57 -0500
> On Fri, 2007-04-06 at 08:12 -0700, Andrew Burgess wrote:
> > Yes. The 3w-.c driver changed between 2.6.18 and 2.6.20 but
> > nothing jumps out to my untrained eyes. Here's the diff:
> > Also, I should mention tha
I don't believe this function behaves as some call sites intend.
For example, if the driver implements the ->change_queue_type()
method, and I say to use simple tags in sysfs, and sdev->ordered_tags
is already set, I am not going to get simple tags since
sdev->ordered_tags will stay set and scsi_
Sparc64 systems which have an on-board qla2xxx chip (such as
SunBlade-1000 and SunBlade-2000, there are probably some other systems
like this too) do not have any NVRAM information present, in fact the
NVRAM is basically all 0's from what I can tell.
This always worked just fine since the code wo
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 09:37:12 -0700
> On Mon, 16 Apr 2007, David Miller wrote:
>
> > But even if that fails, I think the fallback code should be put back,
> > since it obviously was used by at least one system and it's pro
From: David Miller <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 12:37:43 -0700 (PDT)
> Now I'm happy to code up the sparc OFW property bits but your attitude
> and perspective on this absolutely has to change and the old fallback
> code still has to go back in there, possible
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 14:10:49 -0700
> Ok, how about the following patch based on the one you posted which
> adds the codes to retrieve the WWPN/WWNN from firmware on SPARC, and
> also adds the module-parameter override I mentioned above.
>
> Perhaps the
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 15:25:17 -0700
> Fine, I'll agree that wacking-users (and
> I'll wager the outliers) with a 2x4 was a bit extreme,
And that, right there, is basically the end of the conversation.
You don't do this to users, ever.
Put a big loud ke
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 16:28:51 -0700
> Sorry, but let's be realistic, this type of warning would have
> *NEVER* been addressed if we kept the status quo
Wrong. I watch the logs all the time and would have sent you a fix to
use the Sparc firmware info as
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 16:47:05 -0700
> Dave, according to your earlier emails, the qla2xxx driver worked
> 'fine' in driver versions before commit
> 7aef45ac92f49e76d990b51b7ecd714b9a608be1. If that were the case, then
> you would have seen the warning me
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 19:41:07 -0700
> That verbiage sounds fine -- so would you consider the previous patch
> I submitted (with module parameter) along with the wording above?
Yes, that sounds fine.
> I'm in transit for a redeye to NY so I won't be able
From: "Seokmann Ju" <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2007 11:28:07 -0700
> Hello David,
> On Mon 4/16/2007 10:02 PM, David Miller wrote:
> > > I'm in transit for a redeye to NY so I won't be able to modify the
> > > patch, If you w
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Wed, 18 Apr 2007 18:13:46 +0100
> Note that I expect Sun put in the invalid ROM intentionally, as we have
> similar cases with other cards that have totally messed up ROMs in
> Sun-branded versions. Personally I think that's an utterly bad decisio
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Wed, 18 Apr 2007 18:16:32 +0100
> On Tue, Apr 17, 2007 at 11:28:07AM -0700, Seokmann Ju wrote:
> > Hello David,
> > On Mon 4/16/2007 10:02 PM, David Miller wrote:
> > > > I'm in transit for a redeye
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Wed, 18 Apr 2007 10:28:02 -0700
> On Wed, 18 Apr 2007, Christoph Hellwig wrote:
>
> > I don't think a module option is a good idea at this point. The problem
> > is you broke some so far perfectly working setups, which is not okay.
> > The only firs
Update the driver version reported by MEGAIOC_QDRVRVER to
match LSI_COMMON_MOD_VERSION.
Signed-off-by: David Milburn <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_mm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_m
From: Robert Peterson <[EMAIL PROTECTED]>
Date: Fri, 20 Apr 2007 10:40:30 -0500
> I've seen some chatter about the qla2xxx driver but not paid attention, so
> I'm sorry if this is a known issue. I've got an older qlogic hba, and recent
> drivers don't seem to play nice with it. I've got the late
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Tue, 24 Apr 2007 13:22:35 +0100
> Overall the driver looks really nice, thanks a lot!
Thanks.
> would be nice to have dev_printk here, but sbus still seems to
> lack driver model integration.
There is only partial integration at the moment, but
201 - 300 of 697 matches
Mail list logo