Hello Eric ,
On Tue, 20 Mar 2007, Mr. James W. Laferriere wrote:
On Mon, 19 Mar 2007, Moore, Eric wrote:
On Saturday, March 17, 2007 2:33 PM, James W. Laferriere wrote:
Hello All , I am have been having this problem since I
purchased the
controller and after changing out the
thomas schorpp wrote:
James Bottomley wrote:
On Sat, 2007-03-24 at 01:51 +0100, thomas schorpp wrote:
no. so the pci layer reports wrong start:
nonsense. it succeeds, confused function return with the error flag:
// u_long start;
// u_long start = 0xFFEFF000;
u_long start
James Bottomley wrote:
On Sat, 2007-03-24 at 01:51 +0100, thomas schorpp wrote:
no. so the pci layer reports wrong start:
nonsense. it succeeds, confused function return with the error flag:
// u_long start;
// u_long start = 0xFFEFF000;
u_long start = 0x3000;
On Sat, 2007-03-24 at 01:51 +0100, thomas schorpp wrote:
> > no. so the pci layer reports wrong start:
>
> nonsense. it succeeds, confused function return with the error flag:
>
> // u_long start;
> // u_long start = 0xFFEFF000;
> u_long start = 0x3000;
> int
thomas schorpp wrote:
thomas schorpp wrote:
James Bottomley wrote:
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
i agree for this to be a 32bit dma busmaster chip,
since pci_resource_flags and lspci say 64bit mem resource type
aic7xxx: pci_resource_start f000 *maddr 2 mem64
thomas schorpp wrote:
James Bottomley wrote:
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
i agree for this to be a 32bit dma busmaster chip,
since pci_resource_flags and lspci say 64bit mem resource type
aic7xxx: pci_resource_start f000 *maddr 2 mem64 4
static int
ahc_li
>
> When we put this in, the kernel code that we inspected allowed for
> the call if msi was not enabled (check on dev->msi_enabled), and did
> nothing. Thus, we believed it was in the scope of the interface.
> kfree does the same kind of thing. Testing on 2.6.21-rc4 on a machine
> w/o MSI also re
James Bottomley wrote:
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
i agree for this to be a 32bit dma busmaster chip,
since pci_resource_flags and lspci say 64bit mem resource type
aic7xxx: pci_resource_start f000 *maddr 2 mem64 4
static int
ahc_linux_pci_reserve_mem_reg
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
> > i agree for this to be a 32bit dma busmaster chip,
> > since pci_resource_flags and lspci say 64bit mem resource type
> >
> > aic7xxx: pci_resource_start f000 *maddr 2 mem64 4
> >
> > we've a bug in the x86_64 linux pci config,
Richard,
When we put this in, the kernel code that we inspected allowed for
the call if msi was not enabled (check on dev->msi_enabled), and did
nothing. Thus, we believed it was in the scope of the interface.
kfree does the same kind of thing. Testing on 2.6.21-rc4 on a machine
w/o MSI also resu
--- Documentation/scsi/aic7xxx.txt 2007-03-23 16:44:05.0 +0100
+++ Documentation/scsi/aic7xxx.txt 2007-03-23 17:01:19.0 +0100
@@ -28,7 +28,7 @@
aic7880 10PCI/3220MHz16Bit 16
aic7890 20PCI/3240MHz16Bit 16 3 4 5 6 7 8
aic7891 20P
thomas schorpp wrote:
James Bottomley wrote:
On Fri, 2007-03-23 at 02:26 +0100, thomas schorpp wrote:
ok, overriding the first while(ahc_is_paused) that blocked before (i
see no sense for doing this in a pci mmap test function, cause proper
resource setup is required *before* using such I/O fu
From: Richard Lary <[EMAIL PROTECTED]>
This patch adds test for phba->cfg_use_msi
before calls to pci_msi_disable() to prevent
calls to this function when pci_msi_enable()
has not been called.
Signed-off-by: Richard Lary <[EMAIL PROTECTED]>
---
Calling pci_msi_disable() when pci_msi_enable()
has
13 matches
Mail list logo
