[BUG][x86_64]pci layer may report wrong iomem resources data to drivers
lo,
aic7xxx driver mmio / dma on x86_64 linux broken here.
i need some comments and further investigation advice on this:
(resend, mozilla misconfig )
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_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr,
uint8_t __iomem **maddr)
{
// u_long start;
u_long len;
int error;
uint64_t start;
...
printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64 0x%lx\n", start,
pci_resource_flags(ahc->dev_softc, 1) & PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp
return (error);
aic7xxx: pci_resource_start 0xff000 mem64 0x4
---^
just to doublecheck the situation, posted lspci already.
will check next, if
len = pci_resource_len(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
if (request_mem_region(start, len, "aic7xxx") == 0)
succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc->dev_softc, 1);
len = pci_resource_len(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
if (request_mem_region(start, len, "aic7xxx") == 0)
error = ENOMEM;
printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x memlen 0x%lx \n",
error, len ); //schorpp
tom1:~# dmesg |grep aic
aic7xxx: DMA_32BIT_MASK
aic7xxx: req_mem_region 0x0 memlen 0x1000
aic7xxx: pci_resource_start 0xff000 *maddr 0x2 mem64 0x4
aic7xxx: PCI Device 0:6:0 failed memory mapped test. Using PIO.
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware worked
fine in a winxp_x64 test setup a few months ago.
will ask LKML.
y
tom
sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
"66 MHz, 64-bit, PCI interface that
supports zero wait-state memory;
also operates on 33 MHz, 32-bit
PCI busses"
this chip is capable of 64bit addressing, as pci_resource_ (checking this)
on x86_64 platform and lspci on x86_64 *and* AMDK7 configured kernels reports,
even on PCI/32, right?
or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the full 64
bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
be able to decode the full 32 bits. I can fix the mmio check not to
hang, but the card won't actually work mmio until whatever's assigning
the BAR above 32 bits is fixed (that could either be a kernel PCI bug or
a BIOS bug).
ok, i trust in that. adaptor bios and mainboard bios *are* out, winxp_x64
driver handled all.
so agree on kernel pci hal issue.
but what for const uint64_t mask_39bit = 0x7FULL;
then?
can adaptec.inc pls comment? since the aha19160 card is still in production
state, i assume they want to have a linux x86_64 dma capable driver. so far it
is not, or can other users having this card pls confirm my pci system broken?
James
y
tom
-
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
-
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
-
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/
[BUG][x86_64]pci layer may report wrong iomem resources data to drivers
lo,
aic7xxx driver mmio / dma on x86_64 linux broken here.
i need some comments and further investigation advice on this:
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_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr, uint8_t __iomem **maddr) { // u_long start;
u_long len; int error; uint64_t start; ...
printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64
0x%lx\n", start, pci_resource_flags(ahc->dev_softc, 1) &
PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp return (error);
aic7xxx: pci_resource_start 0xff000 mem64 0x4
---^
just to doublecheck the situation, posted lspci already.
will check next, if len = pci_resource_len(ahc->dev_softc, 1); if
(start != 0) { *bus_addr = start; // if
(request_mem_region(start, 0x1000, "aic7xxx") == 0) if
(request_mem_region(start, len, "aic7xxx") == 0)
succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc->dev_softc, 1); len =
pci_resource_len(ahc->dev_softc, 1); if (start != 0) { *bus_addr =
start; // if (request_mem_region(start, 0x1000,
"aic7xxx") == 0) if (request_mem_region(start, len, "aic7xxx") == 0)
error = ENOMEM; printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x
memlen 0x%lx \n", error, len ); //schorpp
tom1:~# dmesg |grep aic aic7xxx: DMA_32BIT_MASK aic7xxx:
req_mem_region 0x0 memlen 0x1000 aic7xxx: pci_resource_start
0xff000 *maddr 0x2 mem64 0x4 aic7xxx: PCI Device 0:6:0 failed
memory mapped test. Using PIO. aic7892: Ultra160 Wide Channel A,
SCSI Id=7, 32/253 SCBs
we've a bug in the x86_64 linux pci config, BIOS is ok, the
hardware worked fine in a winxp_x64 test setup a few months
ago.
will ask LKML.
y tom
sorry, wrong according to
http://download.adaptec.com/pdfs/aic7892.pdf.
"66 MHz, 64-bit, PCI interface that supports zero wait-state
memory; also operates on 33 MHz, 32-bit PCI busses"
this chip is capable of 64bit addressing, as pci_resource_
(checking this) on x86_64 platform and lspci on x86_64 *and*
AMDK7 configured kernels reports, even on PCI/32, right? or is
it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the
full 64 bits, so I suspect it should never get a 64 bit BAR,
since it wouldn't be able to decode the full 32 bits. I can fix
the mmio check not to hang, but the card won't actually work mmio
until whatever's assigning the BAR above 32 bits is fixed (that
could either be a kernel PCI bug or a BIOS bug).
ok, i trust in that. adaptor bios and mainboard bios *are* out,
winxp_x64 driver handled all. so agree on kernel pci hal issue. but
what for const uint64_t mask_39bit = 0x7FULL;
then?
can adaptec.inc pls comment? since the aha19160 card is still
in production state, i assume they want to have a linux x86_64
dma capable driver. so far it is not, or can other users having
this card pls confirm my pci system broken?
James
y tom
- 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
-
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/
[BUG][x86_64]pci layer may report wrong iomem resources data to drivers
lo,
aic7xxx driver mmio / dma on x86_64 linux broken here.
i need some comments and further investigation advice on this:
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_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr, uint8_t __iomem **maddr) { // u_long start;
u_long len; int error; uint64_t start; ...
printk(KERN_WARNING aic7xxx: pci_resource_start 0x%llx mem64
0x%lx\n, start, pci_resource_flags(ahc-dev_softc, 1)
PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp return (error);
aic7xxx: pci_resource_start 0xff000 mem64 0x4
---^
just to doublecheck the situation, posted lspci already.
will check next, if len = pci_resource_len(ahc-dev_softc, 1); if
(start != 0) { *bus_addr = start; // if
(request_mem_region(start, 0x1000, aic7xxx) == 0) if
(request_mem_region(start, len, aic7xxx) == 0)
succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc-dev_softc, 1); len =
pci_resource_len(ahc-dev_softc, 1); if (start != 0) { *bus_addr =
start; // if (request_mem_region(start, 0x1000,
aic7xxx) == 0) if (request_mem_region(start, len, aic7xxx) == 0)
error = ENOMEM; printk(KERN_WARNING aic7xxx: req_mem_region 0x%x
memlen 0x%lx \n, error, len ); //schorpp
tom1:~# dmesg |grep aic aic7xxx: DMA_32BIT_MASK aic7xxx:
req_mem_region 0x0 memlen 0x1000 aic7xxx: pci_resource_start
0xff000 *maddr 0x2 mem64 0x4 aic7xxx: PCI Device 0:6:0 failed
memory mapped test. Using PIO. aic7892: Ultra160 Wide Channel A,
SCSI Id=7, 32/253 SCBs
we've a bug in the x86_64 linux pci config, BIOS is ok, the
hardware worked fine in a winxp_x64 test setup a few months
ago.
will ask LKML.
y tom
sorry, wrong according to
http://download.adaptec.com/pdfs/aic7892.pdf.
66 MHz, 64-bit, PCI interface that supports zero wait-state
memory; also operates on 33 MHz, 32-bit PCI busses
this chip is capable of 64bit addressing, as pci_resource_
(checking this) on x86_64 platform and lspci on x86_64 *and*
AMDK7 configured kernels reports, even on PCI/32, right? or is
it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the
full 64 bits, so I suspect it should never get a 64 bit BAR,
since it wouldn't be able to decode the full 32 bits. I can fix
the mmio check not to hang, but the card won't actually work mmio
until whatever's assigning the BAR above 32 bits is fixed (that
could either be a kernel PCI bug or a BIOS bug).
ok, i trust in that. adaptor bios and mainboard bios *are* out,
winxp_x64 driver handled all. so agree on kernel pci hal issue. but
what for const uint64_t mask_39bit = 0x7FULL;
then?
can adaptec.inc pls comment? since the aha19160 card is still
in production state, i assume they want to have a linux x86_64
dma capable driver. so far it is not, or can other users having
this card pls confirm my pci system broken?
James
y tom
- 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
-
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/
[BUG][x86_64]pci layer may report wrong iomem resources data to drivers
lo,
aic7xxx driver mmio / dma on x86_64 linux broken here.
i need some comments and further investigation advice on this:
(resend, mozilla misconfig )
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_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr,
uint8_t __iomem **maddr)
{
// u_long start;
u_long len;
int error;
uint64_t start;
...
printk(KERN_WARNING aic7xxx: pci_resource_start 0x%llx mem64 0x%lx\n, start,
pci_resource_flags(ahc-dev_softc, 1) PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp
return (error);
aic7xxx: pci_resource_start 0xff000 mem64 0x4
---^
just to doublecheck the situation, posted lspci already.
will check next, if
len = pci_resource_len(ahc-dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, aic7xxx) == 0)
if (request_mem_region(start, len, aic7xxx) == 0)
succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc-dev_softc, 1);
len = pci_resource_len(ahc-dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, aic7xxx) == 0)
if (request_mem_region(start, len, aic7xxx) == 0)
error = ENOMEM;
printk(KERN_WARNING aic7xxx: req_mem_region 0x%x memlen 0x%lx \n,
error, len ); //schorpp
tom1:~# dmesg |grep aic
aic7xxx: DMA_32BIT_MASK
aic7xxx: req_mem_region 0x0 memlen 0x1000
aic7xxx: pci_resource_start 0xff000 *maddr 0x2 mem64 0x4
aic7xxx: PCI Device 0:6:0 failed memory mapped test. Using PIO.
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware worked
fine in a winxp_x64 test setup a few months ago.
will ask LKML.
y
tom
sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
66 MHz, 64-bit, PCI interface that
supports zero wait-state memory;
also operates on 33 MHz, 32-bit
PCI busses
this chip is capable of 64bit addressing, as pci_resource_ (checking this)
on x86_64 platform and lspci on x86_64 *and* AMDK7 configured kernels reports,
even on PCI/32, right?
or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the full 64
bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
be able to decode the full 32 bits. I can fix the mmio check not to
hang, but the card won't actually work mmio until whatever's assigning
the BAR above 32 bits is fixed (that could either be a kernel PCI bug or
a BIOS bug).
ok, i trust in that. adaptor bios and mainboard bios *are* out, winxp_x64
driver handled all.
so agree on kernel pci hal issue.
but what for const uint64_t mask_39bit = 0x7FULL;
then?
can adaptec.inc pls comment? since the aha19160 card is still in production
state, i assume they want to have a linux x86_64 dma capable driver. so far it
is not, or can other users having this card pls confirm my pci system broken?
James
y
tom
-
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
-
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
-
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/
