RE: NS83820 2.6.0-test5 driver seems unstable on IA64

RE: NS83820 2.6.0-test5 driver seems unstable on IA64

[Luck, Tony]

> As I understand it, you even do this stupid printk for user apps
> as well, that makes it more than rediculious.  I'd be surprised
> if anyone can find any useful kernel messages on an ia64 system
> in the dmesg output with all the unaligned access crap there.

I don't think that it is "normal" for applications to do unaligned
memory access.  It means that:

a) the programmer is playing fast and loose with types and/or casts.
b) the end-user is going to be disappointed with the performance.

Looking at a couple of ia64 build servers here I see zero unaligned
access messages in the logs.

-Tony

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Benjamin LaHaise]

On Tue, Sep 23, 2003 at 11:21:35AM -0700, Luck, Tony wrote:
> Looking at a couple of ia64 build servers here I see zero unaligned
> access messages in the logs.

ip options can still be an odd number of bytes.  Having itanic spew bogus 
log messages is just plain wrong (yet another hardware issue pushed off on 
software for no significant gain).

		-ben
-- 
"The software industry today survives only through an unstated agreement 
not to stir things up too much.  We must hope this lawsuit [by SCO] isn't 
the big stirring spoon." -- Ian Lance Taylor, Linux Journal, June 2003

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 14:29:25 -0400
Benjamin LaHaise <bcrl@kvack.org> wrote:

> On Tue, Sep 23, 2003 at 11:21:35AM -0700, Luck, Tony wrote:
> > Looking at a couple of ia64 build servers here I see zero unaligned
> > access messages in the logs.
> 
> ip options can still be an odd number of bytes.  Having itanic spew bogus 
> log messages is just plain wrong (yet another hardware issue pushed off on 
> software for no significant gain).

Also, some TCP implementations sometimes don't align the timestamp
options in the headers as well.

Also, as I mentioned, try IP over appletalk.

Unaligned accesses are perfectly normal, _especially_ in the kernel.
This is an axiom of the kernel networking decided a long time ago, and
printing out a silly message when it happens doesn't make that any
less true.

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Grant Grundler]

On Tue, Sep 23, 2003 at 02:29:25PM -0400, Benjamin LaHaise wrote:
...
> (yet another hardware issue pushed off on software for no significant gain).

Even x86 pays at least a one cycle penalty for every misaligned access.
In general, open source code has no excuse for using misaligned fields.
It's (mostly) avoidable.  TCP/IP headers are the historical exception.

One could make the same arguement that a modern NIC should not require
16 byte alignment for DMA. It's a tradeoff one way or the other.
Just a matter of perspective.

grant

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 11:51:04 -0700
Grant Grundler <iod00d@hp.com> wrote:

> Even x86 pays at least a one cycle penalty for every misaligned access.

Yes, one cycle, and it's completely lost in the noise when it
happens.

> In general, open source code has no excuse for using misaligned fields.
> It's (mostly) avoidable.  TCP/IP headers are the historical exception.

It's not the TCP/IP headers intrinsically, it's what they are embedded
inside of.

For example, if the ethernet driver (as nearly all of our's do which
can) optimized for an ethernet header followed by an IP header, guess
what?  That causes ethernet header followed by appletalk followed
by IP to do unaligned accesses.

It is an unavoidable axoim in the kernel networking.  Unaligned accesses
will happen, and they aren't a bug and therefore not worthy of mention
in the kernel logs any more than "page was freed" :-)

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 20:54:50 +0200
Andreas Schwab <schwab@suse.de> wrote:

> Unaligned access are a BUG.

Wrong, they've been allowed in the kernel networking from day
one and there is nothing that can be done to avoid the cases
for which they occur.

Stop spreading fud.

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Andreas Schwab]

Benjamin LaHaise <bcrl@kvack.org> writes:

> On Tue, Sep 23, 2003 at 11:21:35AM -0700, Luck, Tony wrote:
>> Looking at a couple of ia64 build servers here I see zero unaligned
>> access messages in the logs.
>
> ip options can still be an odd number of bytes.  Having itanic spew bogus 
> log messages is just plain wrong (yet another hardware issue pushed off on 
> software for no significant gain).

Unaligned access are a BUG.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 21:09:47 +0200
Andreas Schwab <schwab@suse.de> wrote:

> The compiler is allowed to take advantage that there are no unaligned
> accesses.  You need to use compiler extensions (like attribute packed) to
> stop it from doing this.

That's correct, and if the address is misaligned the cpu "traps"
and the kernel fixes up the load/store access to fix it up.

This unaligned trap handling is required for a port of Linux to
a given cpu architecture.

That's what we're talking about here.

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Benjamin LaHaise]

On Tue, Sep 23, 2003 at 11:51:04AM -0700, Grant Grundler wrote:
> On Tue, Sep 23, 2003 at 02:29:25PM -0400, Benjamin LaHaise wrote:
> ...
> > (yet another hardware issue pushed off on software for no significant gain).
> 
> Even x86 pays at least a one cycle penalty for every misaligned access.
> In general, open source code has no excuse for using misaligned fields.
> It's (mostly) avoidable.  TCP/IP headers are the historical exception.

The other point to keep in mind is that apparently the .09u rev of the P4 
includes additional hardware for handling unaligned accesses because they 
are so common (gzip is a good example of an app where it is faster to do 
an unaligned access for the benefit of fetching the data in one instruction 
instead of 3+, and there is no way to improve on it).

> One could make the same arguement that a modern NIC should not require
> 16 byte alignment for DMA. It's a tradeoff one way or the other.
> Just a matter of perspective.

I consider the 83820 buggy in this regard, too.  That said, the fix does 
not belong in the driver layer, as having it duplicated in a dozen drivers 
is more stupid than fixing up the arch code which is required anyways.

		-ben
-- 
"The software industry today survives only through an unstated agreement 
not to stir things up too much.  We must hope this lawsuit [by SCO] isn't 
the big stirring spoon." -- Ian Lance Taylor, Linux Journal, June 2003

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 21:16:33 +0200
Andreas Schwab <schwab@suse.de> wrote:

> Or the compiler generates code to take advantage of the fact that the
> lower address bits are zero.

The only place where I can se it doing this legally is for structure
offsets.  For example where a "load 4 byte word" instruction takes an
offsetable address composed of a reg and an integer offset where the
integer offset must be a multiple of 4.

This rule we do abide by in the kernel, because PARISC requires this.

Anything more is asking for trouble, I wouldn't want to use such a compiler
in the real world :)

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Andreas Schwab]

"David S. Miller" <davem@redhat.com> writes:

> On Tue, 23 Sep 2003 20:54:50 +0200
> Andreas Schwab <schwab@suse.de> wrote:
>
>> Unaligned access are a BUG.
>
> Wrong, they've been allowed in the kernel networking from day
> one and there is nothing that can be done to avoid the cases
> for which they occur.

The compiler is allowed to take advantage that there are no unaligned
accesses.  You need to use compiler extensions (like attribute packed) to
stop it from doing this.

> Stop spreading fud.

Nothing like this.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Jeff Garzik]

Traditionally, if the NIC driver is accessing unaligned data, it should
be using get/put_unaligned().

	Jeff

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Benjamin LaHaise]

On Tue, Sep 23, 2003 at 03:10:11PM -0400, Jeff Garzik wrote:
> Traditionally, if the NIC driver is accessing unaligned data, it should
> be using get/put_unaligned().

The driver isn't, the networking stack is (it has to).  For more examples 
where this behaviour is required: PPPoE, VLAN...

		-ben
-- 
"The software industry today survives only through an unstated agreement 
not to stir things up too much.  We must hope this lawsuit [by SCO] isn't 
the big stirring spoon." -- Ian Lance Taylor, Linux Journal, June 2003

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Andreas Schwab]

"David S. Miller" <davem@redhat.com> writes:

> On Tue, 23 Sep 2003 21:09:47 +0200
> Andreas Schwab <schwab@suse.de> wrote:
>
>> The compiler is allowed to take advantage that there are no unaligned
>> accesses.  You need to use compiler extensions (like attribute packed) to
>> stop it from doing this.
>
> That's correct, and if the address is misaligned the cpu "traps"
> and the kernel fixes up the load/store access to fix it up.

Or the compiler generates code to take advantage of the fact that the
lower address bits are zero.

> That's what we're talking about here.

Of course, the kernel language is not ISO C, and never will be.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 20:28:04 +0100
Matthew Wilcox <willy@debian.org> wrote:

> That's not true; they could be avoided by using get_unaligned() and
> put_unaligned().  You just don't want to because they'd make sparc suck.

Not only sparc would be effected by this.  Using {get,put}_unaligned()
all over the networking would incur a penalty for many platforms, not
just sparc.

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Jeff Garzik]

On Tue, Sep 23, 2003 at 03:11:28PM -0400, Benjamin LaHaise wrote:
> On Tue, Sep 23, 2003 at 03:10:11PM -0400, Jeff Garzik wrote:
> > Traditionally, if the NIC driver is accessing unaligned data, it should
> > be using get/put_unaligned().
> 
> The driver isn't, the networking stack is (it has to).  For more examples 
> where this behaviour is required: PPPoE, VLAN...

Oh, no argument....  agreed 100%

	Jeff

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Matthew Wilcox]

On Tue, Sep 23, 2003 at 11:52:00AM -0700, David S. Miller wrote:
> On Tue, 23 Sep 2003 20:54:50 +0200
> Andreas Schwab <schwab@suse.de> wrote:
> 
> > Unaligned access are a BUG.
> 
> Wrong, they've been allowed in the kernel networking from day
> one and there is nothing that can be done to avoid the cases
> for which they occur.

That's not true; they could be avoided by using get_unaligned() and
put_unaligned().  You just don't want to because they'd make sparc suck.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Grant Grundler]

On Tue, Sep 23, 2003 at 11:51:22AM -0700, David S. Miller wrote:
> > Even x86 pays at least a one cycle penalty for every misaligned access.
> 
> Yes, one cycle, and it's completely lost in the noise when it happens.

Depends on the app - for the networking stack, I agree.

To revisit Ben's comment: if we know something is likely to be misaligned,
a RISC processor can efficiently load both parts and merge them (one cycle
penalty vs a regular aligned load). Given misaligned accesses are infrequent
enough to affect performance, it makes sense to do this in SW because
it reduces cost of the HW design/test/mfg cycles.

...
> It is an unavoidable axoim in the kernel networking.  Unaligned accesses
> will happen, and they aren't a bug and therefore not worthy of mention
> in the kernel logs any more than "page was freed" :-)

Ok. If the kernel networking stack used get_unaligned() in the one place
Peter originally found, x86/sparc64?/et al wouldn't see a difference.
It would avoid traps on ia64 and parisc.  Bad idea?
Any other arches it might help/hurt on?

grant

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 13:38:19 -0700
Grant Grundler <iod00d@hp.com> wrote:

> Given misaligned accesses are infrequent enough to affect
> performance, it makes sense to do this in SW because
> it reduces cost of the HW design/test/mfg cycles.

Intel actually optimizes this on the P4, what is your
response to that?  Is Intel wasting they time? :-)

> Ok. If the kernel networking stack used get_unaligned() in the one place
> Peter originally found, x86/sparc64?/et al wouldn't see a difference.
> It would avoid traps on ia64 and parisc.  Bad idea?
> Any other arches it might help/hurt on?

It's needed on every access to every TCP and IP header portion
for the case we're talking about in this thread, where the network
device driver gives the networking a packet that ends up with
unaligned IP and TCP headers.

I once considered adding some get_unaligned() uses to the TCP option
parsing code, guess who rejected that patch?  It wasn't me, it was
Linus himself and I came to learn that he's right on this one.

RE: NS83820 2.6.0-test5 driver seems unstable on IA64

[Alan Cox]

On Maw, 2003-09-23 at 19:21, Luck, Tony wrote:
> a) the programmer is playing fast and loose with types and/or casts.
> b) the end-user is going to be disappointed with the performance.

c) the programmer is being clever and knows the unaligned access is
cheaper on average than the cost of making sure it cant happen

> Looking at a couple of ia64 build servers here I see zero unaligned
> access messages in the logs.

Anyone who can deliver network traffic to your box can soon fix that...

RE: NS83820 2.6.0-test5 driver seems unstable on IA64

[David Mosberger]

>>>>> On Tue, 23 Sep 2003 22:00:34 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> said:

  >> Looking at a couple of ia64 build servers here I see zero unaligned
  >> access messages in the logs.

  Alan> Anyone who can deliver network traffic to your box can soon fix that...

Not if he's running Red Hat.  This is on a Red Hat 9 machine (x86,
just so you can't argue it's ia64-specific...):

 $ fgrep LOGLEVEL /etc/rc.sysinit
 /bin/dmesg -n $LOGLEVEL
 $ fgrep LOGLEVEL /etc/sysconfig/*
 /etc/sysconfig/init:LOGLEVEL=3

Red Hat users won't be bothered by unaligned messages.

	--david

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Grant Grundler]

On Tue, Sep 23, 2003 at 01:45:29PM -0700, David S. Miller wrote:
> Intel actually optimizes this on the P4, what is your
> response to that?  Is Intel wasting they time? :-)

nono...but Intel doesn't have a choice on x86.
They have to optimize for the binaries that are out there.
Compatibility is everything in that market space.

And someone at Intel obviously agrees the newer architectures
should support misaligned access in SW since ever RISC chip
they've built (starting with i860, ~1989) does it that way.

> It's needed on every access to every TCP and IP header portion
> for the case we're talking about in this thread, where the network
> device driver gives the networking a packet that ends up with
> unaligned IP and TCP headers.

Yeah, I don't use most LAN features (PPPoE, VLAN, Appletalk, etc).
I naively thought there must be a subset everyone uses...but defining
that subset sounds like a rat hole I shouldn't go near.

> I once considered adding some get_unaligned() uses to the TCP option
> parsing code, guess who rejected that patch?  It wasn't me, it was
> Linus himself and I came to learn that he's right on this one.

I'm not totally comfortable with that. The NICs I care about seem to
"bias the buffer address" to compensate for some "common case".
Seems like those cases would be cheaper (and more portable) to add
the get_unaligned() calls in the networking stack....I don't know
though really.

thanks,
grant

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Andrew Morton]

"David S. Miller" <davem@redhat.com> wrote:
>
> > That's not true; they could be avoided by using get_unaligned() and
>  > put_unaligned().  You just don't want to because they'd make sparc suck.
> 
>  Not only sparc would be effected by this.  Using {get,put}_unaligned()
>  all over the networking would incur a penalty for many platforms, not
>  just sparc.

Really?  I'd have thought that get/put_unaligned would be a simple
load/store for architectures which wish to implement it in that manner.

Other architectures could take it as an optimisation hint, to avoid taking
a trap.  They'd probably still need to implement the fixup, but if a few of
these hints could reduce the trap frequency significantly then it may be
worth doing?

I guess it depends on how many of these hints would be needed at the source
level to avoid "most" of the traps.

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 15:35:40 -0700
Grant Grundler <iod00d@hp.com> wrote:

> And someone at Intel obviously agrees the newer architectures
> should support misaligned access in SW since ever RISC chip
> they've built (starting with i860, ~1989) does it that way.

That's a amusing coincidence since at least some people think ia64
will end up the same way the i860 did :-)

In the past I did always advocate things the way you are right now,
but these days I think I've been wrong the whole time and Intel on x86
is doing the right thing.

They do everything in hardware and this makes the software so much
simpler.  Sure, there's a lot of architectually inherited complexity
in the x86 family, but their engineering priorities mean there is so
much other stuff you simply never have to think about as a programmer.

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 16:15:29 -0700
Andrew Morton <akpm@osdl.org> wrote:

> "David S. Miller" <davem@redhat.com> wrote:
> >
> > > That's not true; they could be avoided by using get_unaligned() and
> >  > put_unaligned().  You just don't want to because they'd make sparc suck.
> > 
> >  Not only sparc would be effected by this.  Using {get,put}_unaligned()
> >  all over the networking would incur a penalty for many platforms, not
> >  just sparc.
> 
> Really?  I'd have thought that get/put_unaligned would be a simple
> load/store for architectures which wish to implement it in that manner.

Only on systems that have the "load upper/lower-unaligned"
instructions.  On others it's a memmove().

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 17:13:33 -0700
Grant Grundler <iod00d@hp.com> wrote:

> It might. I be happy to share what I know about i860/i960 over pizza.
> I worked on ATT SVR4 port to i860 in 1989/90 and things were quite
> different then...

Q: How does an OS context switch work on the i860?
A: The user sneezes and the kernel cleans up after it.

I've hung out with i860 hackers already in my past :)

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Wed, 24 Sep 2003 01:14:56 +0100
Matthew Wilcox <willy@debian.org> wrote:

> (I can see this descending into get_unaligned_likely() and
> get_aligned_unlikely() which i'd rather avoid ...)

get_unaligned_unlikely() is exactly what just loading the 32-bit value
as if it were aligned is, ie. what we're doing right now.

People who want top performance should not put a networking card into
their machine that can only DMA packets to 32-byte or whatever
boundaries.  That's exactly the limitation NS83820 has and therefore
why it should be avoided like the plague by performance conscious
folks.

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Grant Grundler]

On Tue, Sep 23, 2003 at 04:35:42PM -0700, David S. Miller wrote:
> On Tue, 23 Sep 2003 15:35:40 -0700
> Grant Grundler <iod00d@hp.com> wrote:
> 
> > And someone at Intel obviously agrees the newer architectures
> > should support misaligned access in SW since ever RISC chip
> > they've built (starting with i860, ~1989) does it that way.
> 
> That's a amusing coincidence since at least some people think ia64
> will end up the same way the i860 did :-)

It might. I be happy to share what I know about i860/i960 over pizza.
I worked on ATT SVR4 port to i860 in 1989/90 and things were quite
different then...

> In the past I did always advocate things the way you are right now,
> but these days I think I've been wrong the whole time and Intel on x86
> is doing the right thing.

I'm not so interested in "right" or "wrong". I'd just like to see other
arches besides x86 work well (ia64, parisc in particular) and that includes
how linux deals with unaligned accesses. If x86 is the gold standard
for "the right way", we'd be using bounce buffers for DMA to highmem
(well, PAE support would get added somehow) and 64-bit kernels wouldn't
have happened...but linux so far seems to accomodate other arches *when
reasonable*.  I'll follow Andrew Morton's comments...

> They do everything in hardware and this makes the software so much
> simpler.  Sure, there's a lot of architectually inherited complexity
> in the x86 family, but their engineering priorities mean there is so
> much other stuff you simply never have to think about as a programmer.

Yes, true.  But I think we are digressing from the original thread here...
(/me works his way around another really big rat hole :^)

thanks,
grant

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[Matthew Wilcox]

On Tue, Sep 23, 2003 at 04:37:44PM -0700, David S. Miller wrote:
> > >  Not only sparc would be effected by this.  Using {get,put}_unaligned()
> > >  all over the networking would incur a penalty for many platforms, not
> > >  just sparc.
> > 
> > Really?  I'd have thought that get/put_unaligned would be a simple
> > load/store for architectures which wish to implement it in that manner.
> 
> Only on systems that have the "load upper/lower-unaligned"
> instructions.  On others it's a memmove().

It is at the moment, but why should it be?  Why can't it be implemented
as load-and-trap if that's the fastest way to do it?

(I can see this descending into get_unaligned_likely() and
get_aligned_unlikely() which i'd rather avoid ...)

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[David S. Miller]

On Tue, 23 Sep 2003 14:16:36 -0700
David Mosberger <davidm@napali.hpl.hp.com> wrote:

> Red Hat users won't be bothered by unaligned messages.

Let's hope they don't need to see anything useful in the dmesg output.

Re: NS83820 2.6.0-test5 driver seems unstable on IA64

[William Lee Irwin III]

On Tue, Sep 23, 2003 at 04:35:42PM -0700, David S. Miller wrote:
> That's a amusing coincidence since at least some people think ia64
> will end up the same way the i860 did :-)
> In the past I did always advocate things the way you are right now,
> but these days I think I've been wrong the whole time and Intel on x86
> is doing the right thing.
> They do everything in hardware and this makes the software so much
> simpler.  Sure, there's a lot of architectually inherited complexity
> in the x86 family, but their engineering priorities mean there is so
> much other stuff you simply never have to think about as a programmer.

Several of the x86 "hardware assists" need some rather hefty hacks
codewise to cope with their concomitant data structure proliferations
under industrial workloads, and generally have me begging for RISC's
system-level features instead (which, of course, require various
undoings of Linux' x86 crossdressings to exploit).

Given the reactions in prior threads, this message clearly needs to
wait a long while before it will ever be heard.


-- wli

Re: [OT] NS83820 2.6.0-test5 driver seems unstable on IA64

[n0ano]

The same way it did all exceptions, painfully slow :-)  I still think the
software exception handling on the i860 was one of it's big Achile's heels
but it got killed for other reasons before that became an issue.

On Tue, Sep 23, 2003 at 05:04:08PM -0700, David S. Miller wrote:
> On Tue, 23 Sep 2003 17:13:33 -0700
> Grant Grundler <iod00d@hp.com> wrote:
> 
> > It might. I be happy to share what I know about i860/i960 over pizza.
> > I worked on ATT SVR4 port to i860 in 1989/90 and things were quite
> > different then...
> 
> Q: How does an OS context switch work on the i860?
> A: The user sneezes and the kernel cleans up after it.
> 
> I've hung out with i860 hackers already in my past :)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@n0ano.com
Ph: 303/447-2201