question about sparc 64-bit user land

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

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      \
`          [email protected]   --   [email protected]           '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

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

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 [email protected]
   private [email protected]
    http://www.suse.de/~aj

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.

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

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

NO not at all! The transfer is one with scp over a corssover direct link between two hosts. No hub between involved.

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.

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.

Well maybe it helps this is version 17 of the chip.

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.

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

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

Followup to:  <[email protected]>
By author:    root <[email protected]>
In newsgroup: linux.dev.kernel

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

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

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.

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

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

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