twork driver might be needed
to make it possible to test the old kernel on particular hardware.
In the worst case, I can patch LINUX_VERSION_CODE and KERNEL_VERSION
locally to make out-of-tree modules work. Or else just not test kernels
with sublevel > 255.
Tony Battersby
Cybernetics
Thumshirn
> Reported-by: Andrey Konovalov
> Cc: Hannes Reinecke
> Cc: Christoph Hellwig
> Cc: Doug Gilbert
> Reviewed-by: Hannes Reinecke
> Acked-by: Doug Gilbert
> Signed-off-by: Martin K. Petersen
> Cc: Tony Battersby
> Signed-off-by: Greg Kroah-Hartman
> Signed
to
that version, clean it up, and resubmit when I have time.
Andrew, please revert all 9 patches. I will resubmit the set when I
have a workable solution.
Tony Battersby
to
that version, clean it up, and resubmit when I have time.
Andrew, please revert all 9 patches. I will resubmit the set when I
have a workable solution.
Tony Battersby
onfirm by reverting my dmapool
patches and enabling DMAPOOL_DEBUG, which is at the top of mm/dmapool.c:
#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB_DEBUG_ON)
#define DMAPOOL_DEBUG 1
#endif
Tony Battersby
onfirm by reverting my dmapool
patches and enabling DMAPOOL_DEBUG, which is at the top of mm/dmapool.c:
#if defined(CONFIG_DEBUG_SLAB) || defined(CONFIG_SLUB_DEBUG_ON)
#define DMAPOOL_DEBUG 1
#endif
Tony Battersby
On 06/15/2016 05:50 PM, Borislav Petkov wrote:
> On Wed, Jun 15, 2016 at 05:43:42PM -0400, Tony Battersby wrote:
>> With that patch applied, modprobe amd64_edac_mod correctly reports "No
>> such device" and everything is fine.
> Good, thanks!
>
> I'll add your
On 06/15/2016 05:50 PM, Borislav Petkov wrote:
> On Wed, Jun 15, 2016 at 05:43:42PM -0400, Tony Battersby wrote:
>> With that patch applied, modprobe amd64_edac_mod correctly reports "No
>> such device" and everything is fine.
> Good, thanks!
>
> I'll add your
On 06/15/2016 05:12 PM, Borislav Petkov wrote:
> On Wed, Jun 15, 2016 at 04:46:40PM -0400, Tony Battersby wrote:
>> The following commit is causing an oops:
>>
>> 3f37a36b6282 ("EDAC, amd64_edac: Drop pci_register_driver() use")
>>
>> The oops happens w
On 06/15/2016 05:12 PM, Borislav Petkov wrote:
> On Wed, Jun 15, 2016 at 04:46:40PM -0400, Tony Battersby wrote:
>> The following commit is causing an oops:
>>
>> 3f37a36b6282 ("EDAC, amd64_edac: Drop pci_register_driver() use")
>>
>> The oops happens w
The following commit is causing an oops:
3f37a36b6282 ("EDAC, amd64_edac: Drop pci_register_driver() use")
The oops happens when I "modprobe amd64_edac_mod" on an Intel
Xeon-based system, or when booting the same system with amd64_edac
built-in. Obviously the module is not meant for this
The following commit is causing an oops:
3f37a36b6282 ("EDAC, amd64_edac: Drop pci_register_driver() use")
The oops happens when I "modprobe amd64_edac_mod" on an Intel
Xeon-based system, or when booting the same system with amd64_edac
built-in. Obviously the module is not meant for this
b: core : hub: Fix
BOS 'NULL pointer' kernel panic"), which has already been applied
upstream. It looks to me like that patch might have fixed the same
problem in a different way, in which case Changbin's patch is not
needed. But I haven't been involved in developing or testing that
patch, so I can't say for sure. At the very least, 464ad8c43a9e
conflicts with Changbin's patch.
Changbin, can you take a look at 464ad8c43a9e and see if that fixes the
same problem that your patch did?
Thanks,
Tony Battersby
clear BOS field
> during reset device"). But d8f00cd685f5 is buggy and reverted. This
> new patch should be the final fix.
>
> Best Regards,
> Du, Changbin
>
I think Greg is referring to commit 464ad8c43a9e ("usb: core : hub: Fix
BOS 'NULL pointer' kernel panic"), which has already been applied
upstream. It looks to me like that patch might have fixed the same
problem in a different way, in which case Changbin's patch is not
needed. But I haven't been involved in developing or testing that
patch, so I can't say for sure. At the very least, 464ad8c43a9e
conflicts with Changbin's patch.
Changbin, can you take a look at 464ad8c43a9e and see if that fixes the
same problem that your patch did?
Thanks,
Tony Battersby
Thanks, that fixes it.
Note: your patch appears to be against linux-next. I had to change
"arch/x86/events/intel/uncore_snbep.c" to
"arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c" for the patch to
apply against current linux-git.
Tested-by: Tony Battersby <to...@cyb
Thanks, that fixes it.
Note: your patch appears to be against linux-next. I had to change
"arch/x86/events/intel/uncore_snbep.c" to
"arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c" for the patch to
apply against current linux-git.
Tested-by: Tony Battersby
On 02/24/
The following commit in 4.5 is causing a general protection fault during
early boot:
d6980ef32570 ("perf/x86/intel/uncore: Add Broadwell-EP uncore support")
With the commit reverted, the system boots fine.
CPU: Intel(R) Xeon(R) CPU D-1520 @ 2.20GHz
Motherboard: Supermicro
The following commit in 4.5 is causing a general protection fault during
early boot:
d6980ef32570 ("perf/x86/intel/uncore: Add Broadwell-EP uncore support")
With the commit reverted, the system boots fine.
CPU: Intel(R) Xeon(R) CPU D-1520 @ 2.20GHz
Motherboard: Supermicro
On 09/18/2015 12:19 PM, Tony Battersby wrote:
> But why do drivers even need this at all? Here is a typical usage:
>
> int qce_mapsg(struct device *dev, struct scatterlist *sg, int nents,
> enum dma_data_direction dir, bool chained)
> {
> int err;
&
quot;crypto: talitos - Add ablkcipher algorithms" (2009)
643b39b031f5 "crypto: caam - chaining support" (2012)
(CC'ing the original authors)
Tony Battersby
Cybernetics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
On 09/18/2015 12:19 PM, Tony Battersby wrote:
> But why do drivers even need this at all? Here is a typical usage:
>
> int qce_mapsg(struct device *dev, struct scatterlist *sg, int nents,
> enum dma_data_direction dir, bool chained)
> {
> int err;
&
quot;crypto: talitos - Add ablkcipher algorithms" (2009)
643b39b031f5 "crypto: caam - chaining support" (2012)
(CC'ing the original authors)
Tony Battersby
Cybernetics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
647 ("scsi: add support for a blk-mq based I/O path.")
Cc: # 3.17+
Signed-off-by: Tony Battersby
---
For immediate inclusion.
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 106884a..cfadcce 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
support for a blk-mq based I/O path.)
Cc: sta...@vger.kernel.org # 3.17+
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For immediate inclusion.
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 106884a..cfadcce 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi
. We use the new flag for
> sas ata tag allocation.
>
> Reported-by: Tony Battersby
> Signed-off-by: Shaohua Li
>
Yes, that fixes it. Thanks!
Tested-by: Tony Battersby
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 4c35f08..ef150eb 100644
> --
ata tag allocation.
Reported-by: Tony Battersby to...@cybernetics.com
Signed-off-by: Shaohua Li s...@fb.com
Yes, that fixes it. Thanks!
Tested-by: Tony Battersby to...@cybernetics.com
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4c35f08..ef150eb 100644
On 03/11/2015 05:45 PM, Jens Axboe wrote:
> On 03/11/2015 02:15 PM, Tony Battersby wrote:
>> This reverts commits 12cb5ce101abfaf74421f8cc9f196e708209eb79 and
>> 98bd4be1ba95f2fe7f543910792b7163a5de06eb.
>>
>> Commit 12cb5ce101ab ("libata: use blk taging") caus
t is also necessary to revert commit 98bd4be1ba95
("libata: move sas ata tag allocation to libata-scsi.c"), which appears
to have been a follow-on cleanup to the commit that caused the problem.
Fixes: 12cb5ce101ab ("libata: use blk taging")
Signed-off-by: Tony Battersby
---
Note: when
that caused the problem.
Fixes: 12cb5ce101ab (libata: use blk taging)
Signed-off-by: Tony Battersby to...@cybernetics.com
---
Note: when reverting the two commits above, I had to fixup conflicts
with the following commit:
72dd299d5039a336493993dcc63413cf31d0e662 (libata: allow sata_sil24 to
opt-out
On 03/11/2015 05:45 PM, Jens Axboe wrote:
On 03/11/2015 02:15 PM, Tony Battersby wrote:
This reverts commits 12cb5ce101abfaf74421f8cc9f196e708209eb79 and
98bd4be1ba95f2fe7f543910792b7163a5de06eb.
Commit 12cb5ce101ab (libata: use blk taging) causes the following oops
with scsi-mq enabled
On 02/11/2015 11:31 AM, Tony Battersby wrote:
> Note: I did a number of tests with this patch, but I do not have any
> programs to test commands with bidirectional data transfer. I would
> appreciate if someone could test that.
Replying to myself, I was able to test bidirectional data
be
applied after the patch titled "sg: fix unkillable I/O wait deadlock
with scsi-mq".
Cc: Douglas Gilbert
Cc: # 3.17+
Signed-off-by: Tony Battersby
---
For inclusion in kernel 3.20.
The difference in behavior is due to bt_get() in block/blk-mq-tag.c
checking for __GFP_WAIT.
The bsg driv
).
Cc: Douglas Gilbert
Cc: # 3.17+
Signed-off-by: Tony Battersby
---
For inclusion in kernel 3.20.
This is the exact same patch as before; I have only updated the patch
description to reflect new details uncovered by myself and Douglas
Gilbert. There is also now a second related patch to sg tha
: Douglas Gilbert dgilb...@interlog.com
Cc: sta...@vger.kernel.org # 3.17+
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in kernel 3.20.
This is the exact same patch as before; I have only updated the patch
description to reflect new details uncovered by myself and Douglas
Gilbert
be
applied after the patch titled sg: fix unkillable I/O wait deadlock
with scsi-mq.
Cc: Douglas Gilbert dgilb...@interlog.com
Cc: sta...@vger.kernel.org # 3.17+
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in kernel 3.20.
The difference in behavior is due to bt_get() in block/blk
On 02/11/2015 11:31 AM, Tony Battersby wrote:
Note: I did a number of tests with this patch, but I do not have any
programs to test commands with bidirectional data transfer. I would
appreciate if someone could test that.
Replying to myself, I was able to test bidirectional data transfer
On 02/11/2015 12:45 PM, Douglas Gilbert wrote:
> On 15-02-11 11:32 AM, Tony Battersby wrote:
>> Fix SCSI generic read() incorrectly returning success after detecting an
>> error.
>>
>> Cc:
>> Signed-off-by: Tony Battersby
>> ---
>>
>> For inclu
the deadlock by calling blk_put_request() as soon as
the SCSI command completes instead of waiting for userspace to call read().
Cc: # 3.17+
Signed-off-by: Tony Battersby
---
For inclusion in kernel 3.20.
I encountered this problem using mptsas (can_queue == 127) and 8 disks
connected via an expan
Fix SCSI generic read() incorrectly returning success after detecting an
error.
Cc:
Signed-off-by: Tony Battersby
---
For inclusion in kernel 3.20.
--- linux-3.19.0/drivers/scsi/sg.c.orig 2015-02-08 21:54:22.0 -0500
+++ linux-3.19.0/drivers/scsi/sg.c 2015-02-10 09:26:09.0
If the allocation of bt->bs fails, then bt->map can be freed twice, once
in blk_mq_init_bitmap_tags() -> bt_alloc(), and once in
blk_mq_init_bitmap_tags() -> bt_free(). Fix by setting the pointer to
NULL after the first free.
Cc:
Signed-off-by: Tony Battersby
---
For inclusion in
k by calling blk_put_request() as soon as the SCSI command
completes instead of waiting for userspace to call read().
Cc: # 3.17+
Signed-off-by: Tony Battersby
---
For inclusion in kernel 3.20.
Note: I did a number of tests with this patch, but I do not have any
programs to test commands with b
blk_put_request() as soon as the SCSI command
completes instead of waiting for userspace to call read().
Cc: sta...@vger.kernel.org # 3.17+
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in kernel 3.20.
Note: I did a number of tests with this patch, but I do not have any
programs
by calling blk_put_request() as soon as
the SCSI command completes instead of waiting for userspace to call read().
Cc: sta...@vger.kernel.org # 3.17+
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in kernel 3.20.
I encountered this problem using mptsas (can_queue == 127) and 8
If the allocation of bt-bs fails, then bt-map can be freed twice, once
in blk_mq_init_bitmap_tags() - bt_alloc(), and once in
blk_mq_init_bitmap_tags() - bt_free(). Fix by setting the pointer to
NULL after the first free.
Cc: sta...@vger.kernel.org
Signed-off-by: Tony Battersby
Fix SCSI generic read() incorrectly returning success after detecting an
error.
Cc: sta...@vger.kernel.org
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in kernel 3.20.
--- linux-3.19.0/drivers/scsi/sg.c.orig 2015-02-08 21:54:22.0 -0500
+++ linux-3.19.0/drivers
On 02/11/2015 12:45 PM, Douglas Gilbert wrote:
On 15-02-11 11:32 AM, Tony Battersby wrote:
Fix SCSI generic read() incorrectly returning success after detecting an
error.
Cc: sta...@vger.kernel.org
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in kernel 3.20
ups, etc., any of which may appear to be completely
unrelated to the root cause.
Cc: # 3.17.x, 3.18.x
Signed-off-by: Tony Battersby
---
I encountered this problem with a QLogic QLE2672 FC HBA using qla2xxx.
On my system, this would trigger BUG_ON(atomic_read(>bi_remaining) <= 0)
in
, etc., any of which may appear to be completely
unrelated to the root cause.
Cc: sta...@vger.kernel.org # 3.17.x, 3.18.x
Signed-off-by: Tony Battersby to...@cybernetics.com
---
I encountered this problem with a QLogic QLE2672 FC HBA using qla2xxx.
On my system, this would trigger BUG_ON(atomic_read
Fix an error path in SCSI_IOCTL_SEND_COMMAND that calls
blk_put_request(rq) on an invalid IS_ERR(rq) pointer.
Fixes: a492f075450f ("block,scsi: fixup blk_get_request dead queue scenarios")
Signed-off-by: Tony Battersby
---
(resending, since no one picked it up last time)
For inclusi
Fix an error path in SCSI_IOCTL_SEND_COMMAND that calls
blk_put_request(rq) on an invalid IS_ERR(rq) pointer.
Fixes: a492f075450f (block,scsi: fixup blk_get_request dead queue scenarios)
Signed-off-by: Tony Battersby to...@cybernetics.com
---
(resending, since no one picked it up last time
Fix a memory leak with scsi-mq triggered by commands with large data
transfer length.
Fixes: c53c6d6a68b1 ("scatterlist: allow chaining to preallocated chunks")
Cc: # 3.17.x
Signed-off-by: Tony Battersby
---
For inclusion in 3.18 and 3.17.x.
--- a/lib/scatterlist.c 2014-1
Fix an error path in SCSI_IOCTL_SEND_COMMAND that calls
blk_put_request(rq) on an invalid IS_ERR(rq) pointer.
Fixes: a492f075450f ("block,scsi: fixup blk_get_request dead queue
scenarios")
Signed-off-by: Tony Battersby
---
For inclusion in 3.18 only.
This does not conflict with
Fix an error path in SCSI_IOCTL_SEND_COMMAND that calls
blk_put_request(rq) on an invalid IS_ERR(rq) pointer.
Fixes: a492f075450f (block,scsi: fixup blk_get_request dead queue
scenarios)
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in 3.18 only.
This does not conflict
Fix a memory leak with scsi-mq triggered by commands with large data
transfer length.
Fixes: c53c6d6a68b1 (scatterlist: allow chaining to preallocated chunks)
Cc: sta...@vger.kernel.org # 3.17.x
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in 3.18 and 3.17.x.
--- a/lib
On 08/23/2014 03:09 PM, Douglas Gilbert wrote:
>> For inclusion in 3.17 only.
> May want to check if blk-mq work in lk 3.16 and earlier
> breaks the bsg driver's capability to send SCSI cdbs
> that are longer than 16 bytes.
>
>
I think 3.16 and earlier are OK. The problem was caused by
On 08/23/2014 03:09 PM, Douglas Gilbert wrote:
For inclusion in 3.17 only.
May want to check if blk-mq work in lk 3.16 and earlier
breaks the bsg driver's capability to send SCSI cdbs
that are longer than 16 bytes.
I think 3.16 and earlier are OK. The problem was caused by
rge CDBs only). Without this patch, scsi_mq_prep_fn() will set
rq->cmd back to rq->__cmd, causing the wrong CDB to be sent to the device.
Signed-off-by: Tony Battersby
---
For inclusion in 3.17 only.
diff -urpN linux-3.17.0-rc1-a/block/blk-core.c
linux-3.17.0-rc1-b/block/blk-core.c
--- lin
blk_rq_set_block_pc() memsets rq->cmd to 0, so it should come
immediately after blk_get_request() to avoid overwriting the
user-supplied CDB. Also check for failure to allocate rq.
Fixes: f27b087b81b7 ("block: add blk_rq_set_block_pc()")
Cc: # 3.16.x
Signed-off-by: T
only). Without this patch, scsi_mq_prep_fn() will set
rq-cmd back to rq-__cmd, causing the wrong CDB to be sent to the device.
Signed-off-by: Tony Battersby to...@cybernetics.com
---
For inclusion in 3.17 only.
diff -urpN linux-3.17.0-rc1-a/block/blk-core.c
linux-3.17.0-rc1-b/block/blk-core.c
blk_rq_set_block_pc() memsets rq-cmd to 0, so it should come
immediately after blk_get_request() to avoid overwriting the
user-supplied CDB. Also check for failure to allocate rq.
Fixes: f27b087b81b7 (block: add blk_rq_set_block_pc())
Cc: sta...@vger.kernel.org # 3.16.x
Signed-off-by: Tony
rences to the pages intentionally.
Tony Battersby
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to the pages intentionally.
Tony Battersby
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andy Lutomirski wrote:
> On 04/10/2014 05:22 PM, David Herrmann wrote:
>
>> Hi
>>
>> On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby
>> wrote:
>>
>>> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
>>&g
Andy Lutomirski wrote:
On 04/10/2014 05:22 PM, David Herrmann wrote:
Hi
On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby to...@cybernetics.com
wrote:
For O_DIRECT the kernel pins the submitted pages in memory for DMA by
incrementing the page reference counts when the I/O
urn an error instead of granting the seal if a page is
found with an unexpected extra reference that might have been added by
e.g. get_user_pages() for direct I/O. But looking over shmem_set_seals()
in patch 2/6, it doesn't seem to do that.
Tony Battersby
Cybernetics
--
To unsubscribe from this
the seal if a page is
found with an unexpected extra reference that might have been added by
e.g. get_user_pages() for direct I/O. But looking over shmem_set_seals()
in patch 2/6, it doesn't seem to do that.
Tony Battersby
Cybernetics
--
To unsubscribe from this list: send the line unsubscribe
> I attached a backport of the patch from Tony (added as cc) that is in
> 2.6.25-rc2. Could you try it out against 2.6.24.2 just to make sure it
> was this patch, then we can send it to stable.
>
Yes, I had wanted to send this patch to -stable, but got distracted with
other bugs. So please
I attached a backport of the patch from Tony (added as cc) that is in
2.6.25-rc2. Could you try it out against 2.6.24.2 just to make sure it
was this patch, then we can send it to stable.
Yes, I had wanted to send this patch to -stable, but got distracted with
other bugs. So please do
The following patch fixes the problem for me. Do we want to accept this
patch and call it a day or continue investigating the source of the problem?
Patch applies to 2.6.24.2, but doesn't apply to 2.6.25-rc. If everyone
agrees that this is the right solution, I will resubmit with a proper
Update:
Herbert's patch alters the arguments to alloc_skb_fclone() and
skb_reserve() from within sk_stream_alloc_pskb(). This changes the
skb_headroom() and skb_tailroom() of the returned skb. I decided to see
if I could detect the precise point at which data corruption started to
happen. The
Matt Carlson wrote:
> Hi Tony. Can you give us the output of :
>
> sudo lspci -vvv - -s 03:01.0'
>
03:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit
Ethernet (rev 15)
Subsystem: Compaq Computer Corporation NC7770 Gigabit Server Adapter
(PCI-X,
Herbert Xu wrote:
> On Tue, Feb 19, 2008 at 05:14:26PM -0500, Tony Battersby wrote:
>
>> Update: when I revert Herbert's patch in addition to applying your
>> patch, the iSCSI performance goes back up to 115 MB/s again in both
>> directions. So it looks like turning off
Michael Chan wrote:
> On Tue, 2008-02-19 at 17:14 -0500, Tony Battersby wrote:
>
>
>> Update: when I revert Herbert's patch in addition to applying your
>> patch, the iSCSI performance goes back up to 115 MB/s again in both
>> directions. So it looks like turning
Michael Chan wrote:
On Tue, 2008-02-19 at 17:14 -0500, Tony Battersby wrote:
Update: when I revert Herbert's patch in addition to applying your
patch, the iSCSI performance goes back up to 115 MB/s again in both
directions. So it looks like turning off SG for TX didn't itself cause
Herbert Xu wrote:
On Tue, Feb 19, 2008 at 05:14:26PM -0500, Tony Battersby wrote:
Update: when I revert Herbert's patch in addition to applying your
patch, the iSCSI performance goes back up to 115 MB/s again in both
directions. So it looks like turning off SG for TX didn't itself cause
Matt Carlson wrote:
Hi Tony. Can you give us the output of :
sudo lspci -vvv - -s 03:01.0'
03:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit
Ethernet (rev 15)
Subsystem: Compaq Computer Corporation NC7770 Gigabit Server Adapter
(PCI-X, 10/100/1000-T)
Update:
Herbert's patch alters the arguments to alloc_skb_fclone() and
skb_reserve() from within sk_stream_alloc_pskb(). This changes the
skb_headroom() and skb_tailroom() of the returned skb. I decided to see
if I could detect the precise point at which data corruption started to
happen. The
The following patch fixes the problem for me. Do we want to accept this
patch and call it a day or continue investigating the source of the problem?
Patch applies to 2.6.24.2, but doesn't apply to 2.6.25-rc. If everyone
agrees that this is the right solution, I will resubmit with a proper
Michael Chan wrote:
> On Tue, 2008-02-19 at 11:16 -0500, Tony Battersby wrote:
>
>> iSCSI
>> performance drops to 6 - 15 MB/s when the 3Com NIC is doing heavy rx
>> with light tx,
>>
>
> That's strange. The patch should only affect TX performance slig
Michael Chan wrote:
>> The SysKonnect NIC that does not exhibit this problem has a chip that
>> says "BCM5411KQM" "TT0128 P2Q" and "56975E".
> I think this is the 5700, but please send me the tg3 output that
> identifies the chip and the revision. Something like this:
>
> eth2: Tigon3
Michael Chan wrote:
> On Mon, 2008-02-18 at 16:35 -0800, David Miller wrote:
>
>
>> One consequence of Herbert's change is that the chip will see a
>> different datastream. The initial skb->data linear area will be
>> smaller, and the transition to the fragmented area of pages will be
>>
Michael Chan wrote:
On Mon, 2008-02-18 at 16:35 -0800, David Miller wrote:
One consequence of Herbert's change is that the chip will see a
different datastream. The initial skb-data linear area will be
smaller, and the transition to the fragmented area of pages will be
quicker.
Michael Chan wrote:
The SysKonnect NIC that does not exhibit this problem has a chip that
says BCM5411KQM TT0128 P2Q and 56975E.
I think this is the 5700, but please send me the tg3 output that
identifies the chip and the revision. Something like this:
eth2: Tigon3 [partno(BCM95705) rev
Michael Chan wrote:
On Tue, 2008-02-19 at 11:16 -0500, Tony Battersby wrote:
iSCSI
performance drops to 6 - 15 MB/s when the 3Com NIC is doing heavy rx
with light tx,
That's strange. The patch should only affect TX performance slightly
since we are just turning off SG for TX
dma_readq_full: 2188114
dma_read_prioq_full: 162588
tx_comp_queue_full: 0
ring_set_send_prod_index: 2901128
ring_status_update: 218885
nic_irqs: 146494
nic_avoided_irqs: 72391
nic_tx_threshold_hit: 103584
Tony Battersby
Cybernetics
--
To unsubscribe from
tx_comp_queue_full: 0
ring_set_send_prod_index: 2901128
ring_status_update: 218885
nic_irqs: 146494
nic_avoided_irqs: 72391
nic_tx_threshold_hit: 103584
Tony Battersby
Cybernetics
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
ile leaving other
threads running, then this is a bug. If it is not valid, then this
problem can be ignored, but let me know if that is the case. AFAIK,
everything else seems to work in this situation; problems opening files
in /proc being the only exception that I have encountered so far.
Thanks,
Tony Batt
.
Thanks,
Tony Battersby
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
88 matches
Mail list logo
