lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 1 Jul 2008 01:26:31 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Anders Grafström 
	<grfstrm@...rs.sourceforge.net>
Cc:	David Acker <dacker@...net.com>, Jeff Garzik <jeff@...zik.org>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>, netdev@...r.kernel.org,
	jesse.brandeburg@...el.com, miltonm@....com,
	e1000-devel@...ts.sourceforge.net
Subject: Re: [PATCH] Fix e100 on systems that have cache incoherent DMA

On Thu, 19 Jun 2008 14:38:33 +0200 Anders Grafstr__m <grfstrm@...rs.sourceforge.net> wrote:

> David Acker wrote:
> > May I ask what actual board you are using and how the e100 is connected 
> > to it?  I plan to test with miniPCI based e100 cards.  Also, can you say 
> > more about it being broke?  Does it crash immediately, fail to move any 
> > data, move some data and stop, etc. ?
> 
> It's a custom board based on the IXDP425 reference design.
> IXP420 with 82551ER integrated on the same board.
> Both RX and TX appears to stop shortly after the driver has been initialized.
> It never recovers after the "exec cuc_dump_reset failed" messages start to show.

So..  where are we with this?  e100 is a pretty popular device and
having it obscurely busted on kooky architectures is likely to be
unpopular.

Did this:

> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -1803,6 +1803,8 @@ static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
>   	if (rx->prev->skb) {
>   		struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;
>   		put_unaligned_le32(rx->dma_addr, &prev_rfd->link);
> +		pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,
> +			sizeof(struct rfd), PCI_DMA_TODEVICE);
>   	}
> 
>   	return 0;

actually fix it?

If so, it's probably better than nothing.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ