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  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:	Fri, 16 Nov 2007 18:59:30 -0600
From:	"Jon Nelson" <jnelson@...poni.net>
To:	"Stephen Hemminger" <shemminger@...ux-foundation.org>
Cc:	"Jarek Poplawski" <jarkao2@...pl>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	jnelson-kernel-bugzilla@...poni.net
Subject: Re: [PATCH] via-velocity: don't oops on MTU change.

On 11/16/07, Stephen Hemminger <shemminger@...ux-foundation.org> wrote:
> On Fri, 16 Nov 2007 10:21:25 -0600
> "Jon Nelson" <jnelson@...poni.net> wrote:
>
> > I get a segmentation fault.
> >
> > Should this patch be in addition to the one from bug 9382?
> > http://bugzilla.kernel.org/attachment.cgi?id=13555&action=view
> >
> Yes. The new patch adds just recomputes the rx buf size in
> one place, so it can be set when device is down.
> Also, the computation will always yield same result now, the old
> code computed different values depending on whether it was initial
> or changed MTU.

OK. This is what I did.
Using git I grabbed a copy of Linus' tree and using the latest files
for via-velocity.[c,h], commit
99fee6d7e5748d96884667a4628118f7fc130ea0, I determined that if I
backed out change 44c10138fd4bbc4b6d6bff0873c24902f2a9da65 (PCI:
Change all drivers to use pci_device->revision) I could get it to
compile. This gets me a more recent driver.

Then I applied both of the patches you have provided me, and built and
tried that.
No sigseg, no oops on initial MTU, no sigseg or oops on subsequent MTU changes.

Performance appears to be worse after MTU changes, though. I can get
about 30MB/s with 7200 (the largest the board will support?) and about
5MB/s with 1500. If I *start out* with 1500 performance is 35-40MB/s.
However, the immediate issue appears to be solved (oopses).

If there is a better tree to pull from, I'm more than willing to keep
trying different drivers, at least for a while. I also have tg3 driver
issues to sort out.

-- 
Jon
-
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