From: Russell King [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 09:55:07 +
On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote:
I've created [EMAIL PROTECTED]
By doing so you've just said (implicitly) that you can not tolerate
someone having a different opinion from your own.
I
From: Rene Herman [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 12:46:24 +0100
[EMAIL PROTECTED] is not subscriber-only. Same as that arm list,
it's _moderated_ for non-subscribers and given that I and other moderators
have been doing our best to moderate quickly (I tend to stay logged in to
From: David Miller [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)
The fact that it farts at me every time I post to this thread.
See? I got another one and I have received at least 10 of the
following over the past 2 days.
That's rediculious.
And because a human adds
From: Ingo Molnar [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 15:08:47 +0100
In fact this thread is the very example: David points out that on netdev
some of those bugs were already discussed and resolved. Had it been all
on lkml we'd all be aware of it.
That's a rediculious argument.
One
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 03:49:16 -0800
Do you believe that our response to bug reports is adequate?
Do you feel that making us feel and look like shit helps?
I guess I'm just masterbating here all night long with the 46
bug fixes I've reviewed fully and
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 04:12:59 -0800
On Tue, 13 Nov 2007 03:58:24 -0800 (PST) David Miller [EMAIL PROTECTED]
wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 03:49:16 -0800
Do you believe that our response to bug reports
From: Mark Lord [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 13:18:43 -0500
Mind you, no arguing that this is effective when that poor bloke has
a day free to download the git-tree and build/reboot a dozen times.
Like the internet, this time spent is beneficial because it's
pushing the work out to
From: Russell King [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 23:40:33 +
ARM ep93xx defconfig has been broken since 2.6.23-git1 due to:
drivers/net/arm/ep93xx_eth.c:420: error: implicit declaration of function
'__netif_rx_schedule_prep'
caused by: [NET]: Make NAPI polling independent
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 06:56:06 +0100
If so, MANITAINERS claims that it is subscribers-only. That would cause
some bug reporters to give up and go away.
Find some other mailing list; I'm not hosting *nor* am I willing to run a
non-subscribers
From: David Gaarenstroom [EMAIL PROTECTED]
Date: Sun, 28 Oct 2007 21:11:13 +0100
I would like those to be removed, but to be conservative we should
first get some testing feedback that confirms this just like those
provided to me from the AMD folks for the RS690, RX790 and RD580
cases.
From: Shane Huang [EMAIL PROTECTED]
Date: Wed, 24 Oct 2007 14:43:21 +0800
This patch and the third one seems can make my SB700 SATA controller
work under MSI(simply tested on 2.6.23-rc5).
So you may withdraw the RS690/RD580/RX790 MSI disablement patches
Ok, I've respun the patches including all of the feedback I've
obtained. Again, it's at:
kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git
Greg, I think this stuff is ready to go so if you would pull
them in I would really appreciate it.
These changes clean up the handling
This reverts commit e3008dedff4bdc96a5f67224cd3d8d12237082a0.
The real bug was an INTX issue in the tg3 ethernet chip, and
cured by commit c129d962a66c76964954a98b38586ada82cf9381
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
drivers/pci/quirks.c|1 -
include/linux/pci_ids.h |
This is the fix for the following problem:
https://bugzilla.redhat.com/show_bug.cgi?id=227657
The bnx2 device 5706 complains about MSI not working behind a
ServerWorks HT1000 PCIX bridge. An earlier commit to fix the problem:
e3008dedff4bdc96a5f67224cd3d8d12237082a0:
PCI: disable MSI by
A reasonably common problem with some devices is that they will
disable MSI generation when the INTX_DISABLE bit is set in the
PCI_COMMAND register.
Quirk this explicitly, guarding the pci_intx() calls in msi.c with
this quirk indication.
The first entries for this quirk are for 5714 and 5780
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
drivers/pci/quirks.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 9e8c7af..d8f2d89 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
Now that we have dealt with the real issue, in that some ATI SATA and
USB controllers needed the INTX_DISABLE quirk, we can remove these AMD
chipset global MSI disabling quirks.
This reverts three changesets:
4be8f906435a6af241821ab5b94b2b12cb7d57d8 (PCI: disable MSI on RS690)
From: Jeff Garzik [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 06:01:17 -0400
David Miller wrote:
My suggestion is:
...
Sounds good to me also.
Ok, it seems I've sort-of self-nominated myself to implement
this so I'll try to work on it tomorrow :-)
-
To unsubscribe from this list: send the line
From: David Miller [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 03:06:22 -0700 (PDT)
Ok, it seems I've sort-of self-nominated myself to implement
this so I'll try to work on it tomorrow :-)
I have a working implementation, fully tested on a machine
with Tigon3 ethernet chips that have the quirk
The forthcoming patches are also available from:
kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git
and clean up the handling of the common quirk wherein setting
INTX_DISABLE will mistakedly disable MSI generation for some
devices.
For devices without that problem, we want to
This reverts commit e3008dedff4bdc96a5f67224cd3d8d12237082a0.
The real bug was an INTX issue in the tg3 ethernet chip, and
cured by commit c129d962a66c76964954a98b38586ada82cf9381
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
drivers/pci/quirks.c|1 -
include/linux/pci_ids.h |
This is the fix for the following problem:
https://bugzilla.redhat.com/show_bug.cgi?id=227657
The bnx2 device 5706 complains about MSI not working behind a
ServerWorks HT1000 PCIX bridge. An earlier commit to fix the problem:
e3008dedff4bdc96a5f67224cd3d8d12237082a0:
PCI: disable MSI by
A reasonably common problem with some devices is that they will
disable MSI generation when the INTX_DISABLE bit is set in the
PCI_COMMAND register.
Quirk this explicitly, guarding the pci_intx() calls in msi.c with
this quirk indication.
The first entries for this quirk are for 5714 and 5780
Signed-off-by: David S. Miller [EMAIL PROTECTED]
---
drivers/pci/quirks.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 591eaa4..5795a3d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
From: Daniel Barkalow [EMAIL PROTECTED]
Date: Wed, 24 Oct 2007 00:58:45 -0400 (EDT)
I'm not sure all of the pci_intx() calls in msi.c should be skipped when
the quirk applies; I think some of them might be there so that the legacy
interrupt won't be delivered while MSI is turned off (since
From: Michael Chan [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 21:59:39 -0700
David Miller wrote:
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
+ PCI_DEVICE_ID_TIGON3_5780,
+ quirk_msi_intx_disable_bug);
+DECLARE_PCI_FIXUP_FINAL
From: Michael Ellerman [EMAIL PROTECTED]
Date: Wed, 24 Oct 2007 15:30:21 +1000
That looks like 6 hunks doing exactly the same thing? What about
creating a pci_intx_quirked() (or something) that checks the flag and
then does/or does not call pci_intx().
Good idea, I'll add that to the patch.
-
From: Krzysztof Halasa [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 01:40:18 +0200
Jeff Garzik [EMAIL PROTECTED] writes:
In general it is documented that INTX_DISABLE should apply only to
INTx# so devices that disable MSI based on that bit are out of spec.
The wording is:
10: This bit
From: Daniel Barkalow [EMAIL PROTECTED]
Date: Mon, 22 Oct 2007 17:31:04 -0400 (EDT)
It's likewise documented (although maybe arguable in wording) that the
device shouldn't send legacy interrupts if MSI is in use, regardless of
INTX_DISABLE, but this also happens in the field.
I think that
From: Michal Piotrowski [EMAIL PROTECTED]
Date: Tue, 05 Jun 2007 16:54:35 +0200
Sparc64
Subject: arch/sparc64/time.c doesn't compile on Ultra 1 (no PCI)
References : http://bugzilla.kernel.org/show_bug.cgi?id=8540
Submitter : Horst H. von Brand [EMAIL PROTECTED]
Status : patch
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 09 May 2007 18:46:16 -0400
Bartlomiej Zolnierkiewicz wrote:
Bartlomiej Zolnierkiewicz (11):
ide: fix UDMA/MWDMA/SWDMA masks (v3)
ide: rework the code for selecting the best DMA transfer mode (v3)
ide: add ide_tune_dma()
From: Alan Cox [EMAIL PROTECTED]
Date: Fri, 23 Mar 2007 20:08:19 +
u64 is always unsigned long long (and its debug anyway)
It's plain unsigned long on sparc64 and some other 64-bit platforms.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to
32 matches
Mail list logo
