question about sparc 64-bit user land

question about sparc 64-bit user land

[Felix von Leitner]

My understanding is that there is no 64-bit user land support for
UltraSPARC, although the kernel runs in 64-bit mode.  Is that correct?
If yes: why is that (still) so?

What needs to be done?

Felix

Re: question about sparc 64-bit user land

[Ben Collins]

On Sat, Jan 26, 2002 at 12:16:03PM -0500, linux-kernel-owner@vger.kernel.org wrote:
> My understanding is that there is no 64-bit user land support for
> UltraSPARC, although the kernel runs in 64-bit mode.  Is that correct?
> If yes: why is that (still) so?

No, that is incorrect. Debian currenty has 64bit userland support, and I
believe Rockports does aswell. Someone on the sparclinux claims full
64bit bootstrap (including X), but that isn't really needed since 64bit
is actually slower than 32bit userland.

-- 
 .----------=======-=-======-=========-----------=====------------=-=-----.
/       Ben Collins    --    Debian GNU/Linux    --    WatchGuard.com      \
`          bcollins@debian.org   --   Ben.Collins@watchguard.com           '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Re: question about sparc 64-bit user land

[Jeff Garzik]

Felix von Leitner wrote:
> 
> My understanding is that there is no 64-bit user land support for
> UltraSPARC, although the kernel runs in 64-bit mode.  Is that correct?
> If yes: why is that (still) so?

sparc64 has an in-kernel thunk layer that lets it run sparc32 binaries,
and a sparc32 userland.

Presumeably the standard benefits apply for 32 over 64 bits, such as
lower I-cache usage and smaller programs overall.  Though most
Linux/Unix applications seem to work ok on 64-bit, (a) some don't and
(b) few apps actually take good advantage of 64-bit machine int and
address space.

Of course, all that said, coming from an Alpha AXP background I prefer
64-bit userland ;-)

	Jeff


-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: question about sparc 64-bit user land

[Andreas Jaeger]

Felix von Leitner <usenet-20020126@fefe.de> writes:

> My understanding is that there is no 64-bit user land support for
> UltraSPARC, although the kernel runs in 64-bit mode.  Is that correct?
> If yes: why is that (still) so?

There is Sparc64 userland - but only very few people use it.  glibc
and binutils are ready but for compilation you should use a GCC 3.1
CVS version.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

CRAP in 2.4.18-pre7

[Martin Dalecki]

I would like to notice that the changes in 2.4.18-pre7 to the
tulip eth driver are apparently causing absymal performance drops
on my version of this card. Apparently the performance is dropping
from the expected 10MB/s to about 10kB/s. The only special
thing about the configuration in question is the fact that it's
a direct connection between two hosts. Well, more precisely it's
a cross-over link between my notebook and desktop.

Here is an excerpt from the lspci command:

00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21041 
[Tulip Pass 3] (rev 11)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at d400 [size=128]
        Region 1: Memory at cfffdf80 (32-bit, non-prefetchable) [size=128]
        Expansion ROM at cff80000 [disabled] [size=256K]

The motherboard is a SiS735 chip. The card is apparently sharing it's 
interrupt
(which I guess could be a cause of the problem) with nearly anything else
on the system:

          CPU0
  0:     654927          XT-PIC  timer
  1:      25591          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:        107          XT-PIC  bttv
  8:     283913          XT-PIC  rtc
 11:      70064          XT-PIC  usb-ohci, usb-ohci, eth0, SiS 7012
 12:      39738          XT-PIC  PS/2 Mouse
 14:     198652          XT-PIC  ide0
 15:          0          XT-PIC  ide1
NMI:          0
ERR:          0
[root@domek athlon]#

Oh well yes I have added the newest version of the i810_audio.c for
support of the on board sound card - it's working *GREATLY*.

Please revert the changes in question from the pre-patch.

Re: CRAP in 2.4.18-pre7

[Jeff Garzik]

Martin Dalecki wrote:
> I would like to notice that the changes in 2.4.18-pre7 to the
> tulip eth driver are apparently causing absymal performance drops
> on my version of this card. Apparently the performance is dropping
> from the expected 10MB/s to about 10kB/s. The only special
> thing about the configuration in question is the fact that it's
> a direct connection between two hosts. Well, more precisely it's
> a cross-over link between my notebook and desktop.

Are you seeing collisions?
What is the other side configured as?
What type of cabling?


> Here is an excerpt from the lspci command:
> 
> 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21041

This is interesting considering that for most people, 21041 did not work
at all until 2.4.18-preXX tulip patches.

	Jeff


-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: CRAP in 2.4.18-pre7

[Martin Dalecki]

Jeff Garzik wrote:

>Martin Dalecki wrote:
>
>>I would like to notice that the changes in 2.4.18-pre7 to the
>>tulip eth driver are apparently causing absymal performance drops
>>on my version of this card. Apparently the performance is dropping
>>from the expected 10MB/s to about 10kB/s. The only special
>>thing about the configuration in question is the fact that it's
>>a direct connection between two hosts. Well, more precisely it's
>>a cross-over link between my notebook and desktop.
>>
>
>Are you seeing collisions?
>
NO not at all! The transfer is one with scp over a corssover direct link 
between two hosts.
No hub between involved.

>What is the other side configured as?
>
00:00.0 Host bridge: Intel Corp. 82440MX I/O Controller (rev 01)
00:00.2 Modem: Intel Corp.: Unknown device 7196
00:02.0 VGA compatible controller: Silicon Motion, Inc. SM720 Lynx3DM 
(rev b1)
00:06.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 
(rev 12)
00:07.0 ISA bridge: Intel Corp. 82440MX PCI to ISA Bridge (rev 01)
00:07.1 IDE interface: Intel Corp. 82440MX EIDE Controller
00:07.2 USB Controller: Intel Corp. 82440MX USB Universal Host Controller
00:07.3 Bridge: Intel Corp. 82440MX Power Management Controller
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 
(rev 10)
00:0c.0 CardBus bridge: Texas Instruments PCI1451 PC card Cardbus Controller
00:0c.1 CardBus bridge: Texas Instruments PCI1451 PC card Cardbus Controller

And works otherwise fine everywhere.

>What type of cabling?
>

CAT5 crossover nothing unusual. It's a direct link between two hosts.
Most wiredly the transfer doesn't abort or therelike. It's just getting 
absymally sloooooow.

>>Here is an excerpt from the lspci command:
>>
>>00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21041
>>
>
>This is interesting considering that for most people, 21041 did not work
>at all until 2.4.18-preXX tulip patches.
>
Well maybe it helps this is version 17 of the chip.

Re: CRAP in 2.4.18-pre7

[root]

Martin Dalecki wrote:

> Jeff Garzik wrote:
>
> >Martin Dalecki wrote:
> >
> >>I would like to notice that the changes in 2.4.18-pre7 to the
> >>tulip eth driver are apparently causing absymal performance drops
> >>on my version of this card. Apparently the performance is dropping
> >>>from the expected 10MB/s to about 10kB/s. The only special
> >>thing about the configuration in question is the fact that it's
> >>a direct connection between two hosts. Well, more precisely it's
> >>a cross-over link between my notebook and desktop.
> >>
> >
> >Are you seeing collisions?
> >
> NO not at all! The transfer is one with scp over a corssover direct link
> between two hosts.
> No hub between involved.

You don't need a hub to have collisions.

Duplex mismatch (i.e. one card in full-duplex, the other in half-duplex)
would just show 10-50 KByte/sec transfer rates typically.

The card's statistics about "collisions" and "late collisions" would
positively prove if this is the case.

Re: CRAP in 2.4.18-pre7

[Michal Jaegermann]

On Sun, Jan 27, 2002 at 03:11:28PM +0100, Martin Dalecki wrote:
> I would like to notice that the changes in 2.4.18-pre7 to the
> tulip eth driver are apparently causing absymal performance drops
> on my version of this card.

Well, from what I know 'tulip' driver in later 2.4 kernels simply does
NOT work with any of my tulip cards, on x86 or on alpha, with a version
higher that something like 0.9.14a (which was yet in 2.4.6-ac4, I think;
I may have versions details wrong at this moment and would have to do
some digging to be sure).  In other words its performance is unable to
drop any lower does not matter what I will do.

I reported that a few times in the past, including dumps of PCI
registers and other diagnostic information, but I was never dignified
even with "Yes, noted, and maybe later ..." response.

There were other posting with similar reports so it does not look like
that I am unique in that position.  I am just using 'de4x5' driver
instead but I never had problems with 'tulip' in 2.2 series.

  Michal

Re: CRAP in 2.4.18-pre7

[H. Peter Anvin]

Followup to:  <3C543E86.7F0FA37A@gmx.net>
By author:    root <gunther.mayer@gmx.net>
In newsgroup: linux.dev.kernel
> 
> You don't need a hub to have collisions.
> 
> Duplex mismatch (i.e. one card in full-duplex, the other in half-duplex)
> would just show 10-50 KByte/sec transfer rates typically.
> 
> The card's statistics about "collisions" and "late collisions" would
> positively prove if this is the case.
> 

Not all cards correctly autoconfigure across a crossover cable (they
should, but not all do).  When autoconfigure is screwed up, as you
indicate above, things will be *VERY* messed up.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: CRAP in 2.4.18-pre7

[Stephan von Krawczynski]

On Sun, 27 Jan 2002 11:46:42 -0700
Michal Jaegermann <michal@harddata.com> wrote:

> On Sun, Jan 27, 2002 at 03:11:28PM +0100, Martin Dalecki wrote:
> > I would like to notice that the changes in 2.4.18-pre7 to the
> > tulip eth driver are apparently causing absymal performance drops
> > on my version of this card.
> 
> Well, from what I know 'tulip' driver in later 2.4 kernels simply does
> NOT work with any of my tulip cards, on x86 or on alpha, with a version
> higher that something like 0.9.14a (which was yet in 2.4.6-ac4, I think;
> I may have versions details wrong at this moment and would have to do
> some digging to be sure).  In other words its performance is unable to
> drop any lower does not matter what I will do.

Hm, maybe you should shortly state which vendor (OEM or the like) you are
using. I generally cannot confirm any problems with tulip-driver in 2.4.
I use a wide variety of cards including 4 port cards, very old 21041 DLink,
the former DFE-series etc.
Maybe this is a specific problem with a certain vendor or board type?

Regards,
Stephan

Re: CRAP in 2.4.18-pre7

[Michal Jaegermann]

On Sun, Jan 27, 2002 at 10:58:45PM +0100, Stephan von Krawczynski wrote:
> On Sun, 27 Jan 2002 11:46:42 -0700
> Michal Jaegermann <michal@harddata.com> wrote:
> 
> > Well, from what I know 'tulip' driver in later 2.4 kernels simply does
> > NOT work with any of my tulip cards, on x86 or on alpha,

> Hm, maybe you should shortly state which vendor (OEM or the like) you are
> using.

Ok, how about these:

# lspci -v -s 2:5.0
02:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
	Subsystem: Digital Equipment Corporation DE500 Fast Ethernet
	Flags: bus master, medium devsel, latency 96, IRQ 3
	I/O ports at c400 [size=128]
	Memory at db002000 (32-bit, non-prefetchable) [size=1K]
	Expansion ROM at <unassigned> [disabled] [size=256K]

# lspci -n -s 2:5.0
02:05.0 Class 0200: 1011:0019 (rev 41)

and (another machine runing something "old" at the moment):

# lspci -v -s 0:5.0
00:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22)
        Subsystem: Unknown device 1025:0310
        Flags: bus master, medium devsel, latency 32, IRQ 18
        I/O ports at 8000
        Memory at 0000000004200000 (32-bit, non-prefetchable)

# lspci -n -s 0:5.0
00:05.0 Class 0200: 1011:0009 (rev 22)

This is what I happen to have on hands right now.

> I generally cannot confirm any problems with tulip-driver in 2.4.

Lucky you!  The same goes for me if you do s/2.4/2.2/. :-)

> Maybe this is a specific problem with a certain vendor or board type?

Well, the vendor seems to be tulip designers and for a board type I had
exactly the same results with various x86 and Alpha boards.

If you will search through linux-kernel archives you will notice that
some people were able to restart a network with 2.4 tulip drivers by
unplugging a cable and plugging it back.  Even this trick does not work
in my case.  Yes, I am aware about negotiation troubles with tulips.
Forcing speed also does not help. 'de4x5' is still fine or you will be
not reading this. :-)

  Michal

Re: CRAP in 2.4.18-pre7

[Martin Dalecki]

H. Peter Anvin wrote:

>Followup to:  <3C543E86.7F0FA37A@gmx.net>
>By author:    root <gunther.mayer@gmx.net>
>In newsgroup: linux.dev.kernel
>
>>You don't need a hub to have collisions.
>>
>>Duplex mismatch (i.e. one card in full-duplex, the other in half-duplex)
>>would just show 10-50 KByte/sec transfer rates typically.
>>
>>The card's statistics about "collisions" and "late collisions" would
>>positively prove if this is the case.
>>
>
>Not all cards correctly autoconfigure across a crossover cable (they
>should, but not all do).  When autoconfigure is screwed up, as you
>indicate above, things will be *VERY* messed up.
>

Well boys, I know about the ifconfig command, and I just don't see 
anything special there.
In esp. no collision indications. I would rather suspect, that there are 
maybe some IRQ sharing
problems with the driver, since this got changed as well. However I 
simple just didn't
have the time to narrow it down to this. (In esp. doing a recompile with 
just the blah_irq -> blash_irqsave
changes enabled.


>
>
>	-hpa
>

Re: CRAP in 2.4.18-pre7

[H. Peter Anvin]

Martin Dalecki wrote:

> 
> Well boys, I know about the ifconfig command, and I just don't see 
> anything special there.
> In esp. no collision indications. I would rather suspect, that there are 
> maybe some IRQ sharing
> problems with the driver, since this got changed as well. However I 
> simple just didn't
> have the time to narrow it down to this. (In esp. doing a recompile with 
> just the blah_irq -> blash_irqsave
> changes enabled.
> 


Autoconfigure screwing up usually (in my experience) doesn't indicate 
collisions.  If you have 100Mbit and FD lights on your card, they would 
typically be going on and off, though.

	-hpa