acenic >4gig sendfile problem

acenic >4gig sendfile problem

[Dave Hansen]

When doing sendfile with my acenic card on my 8xPIII-700 and PAE 
running 2.4.18, I'm getting all zeros in the files being transmitted. 
  Running the Redhat 2.4.18-4 kernel fixes the problem.  I saw this 
entry in the rpm's changelog:
* Sat Aug 25 2001 Ingo Molnar <mingo@redhat.com>
- fix the acenic driver bug that caused random kernel memory being
    sent out on the wire, on x86 systems with more than 4 GB RAM.

I tried to pull the relevant bits out of
linux-2.4.17-selected-ac-bits.patch and linux-2.4.18-tg3.patch, with
no success.  I mailed Ingo with no response.

Does anybody remember what the fix was, or still have the patch handy?
-- 
Dave Hansen
haveblue@us.ibm.com

Re: acenic >4gig sendfile problem

[Jes Sorensen]

>>>>> "Dave" == Dave Hansen <haveblue@us.ibm.com> writes:

Dave> When doing sendfile with my acenic card on my 8xPIII-700 and PAE
Dave> running 2.4.18, I'm getting all zeros in the files being
Dave> transmitted.  Running the Redhat 2.4.18-4 kernel fixes the
Dave> problem.  I saw this entry in the rpm's changelog: * Sat Aug 25
Dave> 2001 Ingo Molnar <mingo@redhat.com> - fix the acenic driver bug
Dave> that caused random kernel memory being sent out on the wire, on
Dave> x86 systems with more than 4 GB RAM.

Actually I think you're hitting a bug in pci_map_page() rather than in
the acenic.driver.

Try the patch from Ben LaHaise included below.

Jes


------- Start of forwarded message -------
Resent-Message-Id: <200206102358.g5ANwbx23959@toomuch.toronto.redhat.com>
Date: Mon, 10 Jun 2002 19:56:44 -0400
From: Benjamin LaHaise <bcrl@redhat.com>
To: Marcelo Tosatti <marcelo@conectiva.com.br>,
   Linux Kernel <linux-kernel@vger.kernel.org>
Subject: highmem pci dma mapping does not work, missing cast in asm-i386/pci.h
Message-ID: <20020610195644.C13225@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-From: bcrl@redhat.com
Resent-Date: Mon, 10 Jun 2002 19:58:37 -0400
Resent-To: jes@wildopensource.com

Hello all,

There's a missing cast in pci_map_page that causes 64 bit capable 
drivers to access the wrong memory for highmem pages.  Please 
include the patch below to fix it.

		-ben
-- 
"You will be reincarnated as a toad; and you will be much happier."

:r ~/patches/v2.4/v2.4.19-pre10-pci_highmem.diff
diff -urN v2.4.19-pre10/include/asm-i386/pci.h pci-v2.4.19-pre10/include/asm-i386/pci.h
--- v2.4.19-pre10/include/asm-i386/pci.h	Thu Jun  6 20:10:08 2002
+++ pci-v2.4.19-pre10/include/asm-i386/pci.h	Mon Jun 10 19:54:16 2002
@@ -103,7 +103,7 @@
 	if (direction == PCI_DMA_NONE)
 		out_of_line_bug();
 
-	return (page - mem_map) * PAGE_SIZE + offset;
+	return (dma_addr_t)(page - mem_map) * PAGE_SIZE + offset;
 }
 
 static inline void pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

------- End of forwarded message -------

Re: acenic >4gig sendfile problem

[Roy Sigurd Karlsbakk]

But...

sendfile() doesn't support >4gig anyway - does it?
that's the (yet unimplemented) sendfile64()

roy

-- 
Roy Sigurd Karlsbakk, Datavaktmester

Computers are like air conditioners.
They stop working when you open Windows.

On Monday 24 June 2002 17:31, Jes Sorensen wrote:
> >>>>> "Dave" == Dave Hansen <haveblue@us.ibm.com> writes:
>
> Dave> When doing sendfile with my acenic card on my 8xPIII-700 and PAE
> Dave> running 2.4.18, I'm getting all zeros in the files being
> Dave> transmitted.  Running the Redhat 2.4.18-4 kernel fixes the
> Dave> problem.  I saw this entry in the rpm's changelog: * Sat Aug 25
> Dave> 2001 Ingo Molnar <mingo@redhat.com> - fix the acenic driver bug
> Dave> that caused random kernel memory being sent out on the wire, on
> Dave> x86 systems with more than 4 GB RAM.
>
> Actually I think you're hitting a bug in pci_map_page() rather than in
> the acenic.driver.
>
> Try the patch from Ben LaHaise included below.
>
> Jes
>
>
> ------- Start of forwarded message -------
> Resent-Message-Id: <200206102358.g5ANwbx23959@toomuch.toronto.redhat.com>
> Date: Mon, 10 Jun 2002 19:56:44 -0400
> From: Benjamin LaHaise <bcrl@redhat.com>
> To: Marcelo Tosatti <marcelo@conectiva.com.br>,
>    Linux Kernel <linux-kernel@vger.kernel.org>
> Subject: highmem pci dma mapping does not work, missing cast in
> asm-i386/pci.h Message-ID: <20020610195644.C13225@redhat.com>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Resent-From: bcrl@redhat.com
> Resent-Date: Mon, 10 Jun 2002 19:58:37 -0400
> Resent-To: jes@wildopensource.com
>
> Hello all,
>
> There's a missing cast in pci_map_page that causes 64 bit capable
> drivers to access the wrong memory for highmem pages.  Please
> include the patch below to fix it.
>
> 		-ben

Re: acenic >4gig sendfile problem

[David S. Miller]

   From: Roy Sigurd Karlsbakk <roy@karlsbakk.net>
   Date: Mon, 24 Jun 2002 17:54:59 +0200

   sendfile() doesn't support >4gig anyway - does it?
   that's the (yet unimplemented) sendfile64()

Nothing to do with file offsets.  It has to do with what physical page
the file data ends up in which can be anywhere.

Re: acenic >4gig sendfile problem

[Dave Hansen]

Jes Sorensen wrote:
>>>>>>"Dave" == Dave Hansen <haveblue@us.ibm.com> writes:
>>>>>
> 
> Dave> When doing sendfile with my acenic card on my 8xPIII-700 and PAE
> Dave> running 2.4.18, I'm getting all zeros in the files being
> Dave> transmitted.  Running the Redhat 2.4.18-4 kernel fixes the
> Dave> problem.  I saw this entry in the rpm's changelog: * Sat Aug 25
> Dave> 2001 Ingo Molnar <mingo@redhat.com> - fix the acenic driver bug
> Dave> that caused random kernel memory being sent out on the wire, on
> Dave> x86 systems with more than 4 GB RAM.
> 
> Actually I think you're hitting a bug in pci_map_page() rather than in
> the acenic.driver.
> 
> Try the patch from Ben LaHaise included below.
> 

Thanks for the patch.  I'll give it a shot when I get back from OLS.

-- 
Dave Hansen
haveblue@us.ibm.com