archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <>
To: "David S. Miller" <>
Subject: Re: 2.4.5aa1
Date: Sun, 27 May 2001 04:32:09 +0200	[thread overview]
Message-ID: <20010527043208.G1834@athlon.random> (raw)
In-Reply-To: <20010526193310.A1834@athlon.random> <>
In-Reply-To: <>; from on Sat, May 26, 2001 at 06:35:43PM -0700

On Sat, May 26, 2001 at 06:35:43PM -0700, David S. Miller wrote:
> Andrea Arcangeli writes:
>  > 00_eepro100-64bit-1
>  > 
>  > 	Fixes a 64bit bug that was generating false positives and memory
>  > 	corruption.
>  > 
>  > 	(recommended)
> Good spotting, I've put this into my tree ;-)

fine, thanks!

>  > 00_eepro100-alpha-1
>  > 
>  > 	Possibly fix the eepro100 transmitter hang on alpha by doing atomic PIO
>  > 	updates to avoid the clear_suspend to be lost.
>  > 	
>  > 	(recommended)
> The correct fix is to create {set,clear,change}_bit{8,16,32}()
> routines architectures may implement.  The comment there in eepro100.c


> indicates the those defines are simply wrong for anything other than
> x86, not just Alpha.

The defines are ok but according to Matt they're not using atomic
operations, infact they works fine until you beat them hard. Infact I
guess it may trigger even in x86 in theory, I suspect it doesn't trigger
by luck, I think we should at least declare the __u16 pointer as
volatile or gcc may be free to do whatever it does on alpha without
using the bitops. The patch is actually using an #ifdef __alpha__
because it relys on the fact alpha internally does the 32bit accesses
with the bitops (so it doesn't mess with the other registers).

>  > 00_ipv6-null-oops-1
>  > 
>  > 	Fixes null pointer oops.
>  > 
>  > 	(recommended)
> Please delete this, a proper fix is in 2.4.5, and in fact your
> added NULL test will never pass now :-)

I forgotten it, Alan noticed it too. thanks for the reminder.

>  > 10_no-virtual-1
>  > 
>  > 	Avoids wasting tons of memory if highmem is not selected (like
>  > 	in all the 64bit ports).
>  > 
>  > 	(nice to have)
> I experimented with computing the address every time on sparc64 and
> the performance actually went down slightly, it turned out it's
> quicker to load from an in-cache page struct member than compute the
> offset each time.

Ok, then I will add define_bool CONFIG_NO_PAGE_VIRTUAL y to sparc and

> It's probably not an issue on ix86, but who knows.

On modern x86 it should be faster to compute it to save dcache, memory
bandwith and ram.

Thanks for the review!


  reply	other threads:[~2001-05-27  2:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-26 17:33 2.4.5aa1 Andrea Arcangeli
2001-05-27  1:35 ` 2.4.5aa1 David S. Miller
2001-05-27  2:32   ` Andrea Arcangeli [this message]
2001-05-27 16:25     ` 2.4.5aa1 Andrea Arcangeli
2001-05-27  5:15 ` 2.4.5aa1 Phil Oester
2001-05-27 15:56   ` 2.4.5aa1 Andrea Arcangeli
2001-06-12 23:34 ` 2.4.6pre2aa2 [was Re: 2.4.5aa1] Andrea Arcangeli
2001-06-14 18:43   ` 2.4.6pre3aa1 [was Re: 2.4.6pre2aa2 [was Re: 2.4.5aa1]] Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010527043208.G1834@athlon.random \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).