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
On Sat, Jan 26, 2002 at 12:16:03PM -0500, [email protected] 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 \
` [email protected] -- [email protected] '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
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
Felix von Leitner <[email protected]> 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 [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.
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
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.
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.
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
Followup to: <[email protected]>
By author: root <[email protected]>
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
--
<[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]>
On Sun, 27 Jan 2002 11:46:42 -0700
Michal Jaegermann <[email protected]> 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
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 <[email protected]> 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
H. Peter Anvin wrote:
>Followup to: <[email protected]>
>By author: root <[email protected]>
>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
>
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