Re: Attempts to set date with 'date -s' hang the machine
From: Jurij Smakov [EMAIL PROTECTED] Date: Mon, 30 Jan 2006 00:34:51 -0800 (PST) get_compat_timespec: ts=f800bf7a7e80 get_compat_timespec: ts-tv_sec=f800bf7a7e80 get_compat_timespec: ts-tv_nsec=f800bf7a7e88 get_compat_timespec: cts=ef8d7cd8 get_compat_timespec: cts-tv_sec=ef8d7cd8 get_compat_timespec: cts-tv_nsec=ef8d7cdc I've also got the debugging output from a few other (successful) calls to get_compat_timespec(), the output then typically looks like that: get_compat_timespec: ts=f800bfbc7e80 get_compat_timespec: ts-tv_sec=f800bfbc7e80 get_compat_timespec: ts-tv_nsec=f800bfbc7e88 get_compat_timespec: cts=efa23c88 get_compat_timespec: cts-tv_sec=efa23c88 get_compat_timespec: cts-tv_nsec=efa23c8c Here the higher byte of the cts is set to zero, as I believe it should be for a userspace address. In the failing case the upper byte is set to , which probably causes the problem. I'd appreciate any ideas on how to resolve this issue. In the first case get_compat_timespec() is being called with user pointers which have been sign extended, and that's the bug. A simple tree-wide grep for compat_sys_clock_settime() shows where this is occuring, in arch/sparc64/kernel/sys32.S with this compat syscall stub: SIGN1(sys32_clock_settime, compat_sys_clock_settime, %o1) Which is extending the pointer second arg. In fact no sign extensions are actually necessary here, so this stub can just be completely eliminated. This patch does that, and should fix this bug. diff --git a/arch/sparc64/kernel/sys32.S b/arch/sparc64/kernel/sys32.S index 9cd272a..60b5937 100644 --- a/arch/sparc64/kernel/sys32.S +++ b/arch/sparc64/kernel/sys32.S @@ -84,7 +84,6 @@ SIGN2(sys32_fadvise64_64, compat_sys_fad SIGN2(sys32_bdflush, sys_bdflush, %o0, %o1) SIGN1(sys32_mlockall, sys_mlockall, %o0) SIGN1(sys32_nfsservctl, compat_sys_nfsservctl, %o0) -SIGN1(sys32_clock_settime, compat_sys_clock_settime, %o1) SIGN1(sys32_clock_nanosleep, compat_sys_clock_nanosleep, %o1) SIGN1(sys32_timer_settime, compat_sys_timer_settime, %o1) SIGN1(sys32_io_submit, compat_sys_io_submit, %o1) diff --git a/arch/sparc64/kernel/systbls.S b/arch/sparc64/kernel/systbls.S index bf0fc5b..2881faf 100644 --- a/arch/sparc64/kernel/systbls.S +++ b/arch/sparc64/kernel/systbls.S @@ -71,7 +71,7 @@ sys_call_table32: /*240*/.word sys_munlockall, sys32_sched_setparam, sys32_sched_getparam, sys32_sched_setscheduler, sys32_sched_getscheduler .word sys_sched_yield, sys32_sched_get_priority_max, sys32_sched_get_priority_min, sys32_sched_rr_get_interval, compat_sys_nanosleep /*250*/.word sys32_mremap, sys32_sysctl, sys32_getsid, sys_fdatasync, sys32_nfsservctl - .word sys_ni_syscall, sys32_clock_settime, compat_sys_clock_gettime, compat_sys_clock_getres, sys32_clock_nanosleep + .word sys_ni_syscall, compat_sys_clock_settime, compat_sys_clock_gettime, compat_sys_clock_getres, sys32_clock_nanosleep /*260*/.word compat_sys_sched_getaffinity, compat_sys_sched_setaffinity, sys32_timer_settime, compat_sys_timer_gettime, sys_timer_getoverrun .word sys_timer_delete, compat_sys_timer_create, sys_ni_syscall, compat_sys_io_setup, sys_io_destroy /*270*/.word sys32_io_submit, sys_io_cancel, compat_sys_io_getevents, sys32_mq_open, sys_mq_unlink -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SPARC64]: Eliminate race condition reading Hummingbird STICK register
From: Richard Mortimer [EMAIL PROTECTED] Date: Mon, 16 Jan 2006 23:05:06 + [SPARC64]: Eliminate race condition reading Hummingbird STICK register Ensure a consistent value is read from the STICK register by ensuring that both high and low are read without high changing due to a roll over of the low register. Signed-off-by: Richard Mortimer [EMAIL PROTECTED] It's so sad that I spent such an enormous amount time specifically trying to get this sequence right and yet still messed it up! Nice job Richard, I'll apply your patch and submit it to -stable as well. Thanks a lot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc64 U60: no iptables
From: [EMAIL PROTECTED] Date: Mon, 10 Oct 2005 10:25:07 +0200 Indeed they are. Does the patch assume that cpus are numbered in a row ? Yes, and that assumption is incorrect. Now, I reverted the patch for ip_tables.c, ip6_tables.c and ebtables.c. Everything is working ok (11h uptime). Right. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc64 U60: no iptables
From: Sébastien Bernard [EMAIL PROTECTED] Date: Sun, 09 Oct 2005 20:28:31 +0200 Can one explain me why this patch works on other archs, and oops on the sparc64 smp ? Can one explain why I'm the only one to have this problem ? On your Ultra60 the two physical cpus are numbered 0 and 2.
Re: future libc6-sparcv9 and libc6-sparcv9b support
From: GOTO Masanori [EMAIL PROTECTED] Date: Thu, 18 Aug 2005 14:07:28 +0900 I have a question about optimization package: libc6-sparcv9 and libc6-sparcv9b. Both packages are prepared for optimized versions of libc6. They are currently supported - but I would like to know what the advantage of those packages is. Just optimization? Are those packages widely used? Besides being compiled with the proper optimization and feature options, they use memcpy and memset implementations which are several orders of magnitude faster than plain Sparc versions. Every single UltraSPARC debian system I have has these special versions of the library installed. You can feel the difference these libraries make, performance wise, in many cases. These days 2.6 kernel is getting popularity, so it's nice time to support NPTL on sparc systems. But having a lot of optimized packages and variants like NPTL take much longer build time + maintenance cost. If we replace unpopular optimized libc6 packages with NPTL libc6 in future, it's much valuable for users, I think. How about to drop libc6-sparcv9/sparcv9b and introduce NPTL-enabled libc6 in future? You'll only get NPTL to work on sparcv9 and later anyways. Pure traditional sparc 32-bit NPTL is non-functioning even in the current glibc tree. And I doubt there is much incentive to write the support. Only sparcv9 and later work with NPTL, and since it requires TLS this means current CVS binutils is necessary as well especially if you wish to build 64-bit NPTL enabled glibc on sparc as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: future libc6-sparcv9 and libc6-sparcv9b support
From: GOTO Masanori [EMAIL PROTECTED] Date: Thu, 18 Aug 2005 19:51:45 +0900 Well, we sometimes meet words optimization makes faster, but we merely see the actual result of performance gain. How much is the improvement of such optimized packages? Is sparcv9b valuable compared with sparcv9? Yes, because the optimized memcpy/memset in the sparcv9 package is severely suboptimal for UltraSPARC-III and later chips, which is what the sparcv9b package is needed for. From your suggestion, normal libc6 package (that's also usable for pre sparcv9 archs) does not have any NPTL support, but libc6-sparcv9 (and v9b) can have NPTL support. IIRC, you have worked for 64bit NPTL support on sparc, so I expect libc6-sparc64 will be able to support NPTL without hassle. Right. BTW, if we move to glibc 2.4 series in future, at that time we may need to drop LT support. It means the traditional pre sparcv9 system will be also dropped. Is that acceptable direction for sparc users? (Note that dropping LT is not decided and I think we shouldn't do so currently). Right, it will be necessary. To be honest, pure traditional sparc 32-bit support is a real roadblock to progress in any of these areas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: future libc6-sparcv9 and libc6-sparcv9b support
From: Jakub Jelinek [EMAIL PROTECTED]
Date: Thu, 18 Aug 2005 06:53:36 -0400
Do you remember when we talked about how pre-v9 support could be done,
including fast mutex support (for mutexes NPTL uses just 0/1/2 values
of the futexes and does atomic ops on them, so sticking a ldstub lock
in the MS byte would work).
Yes I do, but I've lost all time to work on this. And I see
no opportunity in the future.
Do we need sparcv[78] NPTL programs being able to use process shared
synchronization primitives with sparcv{9,64} NPTL programs, or is it
enough when just sparcv[78] programs can talk together and sparcv{9,64}
together?
I think the restriction is reasonable, and that's the way to go.
I was working on a way that would allow sharing, but the currently
layout of the glibc NPTL sources does not allow to override enough
of the implementation to pull it off. I was going to put a spinlock
into the semaphore structure, and stuff like that, for example. This
kind of approach would not have slowed down v9+/sparc64 much at all.
I really wanted to pursue things that way, just use ldstub for all
this stuff, but Ulrich would probably dislike it when he sees how much
stuff would need to be moved into sysdep/* overridable areas. Every
change to semaphores generically would require some sparc updates, for
example.
Lack of an atomic word compare and swap makes current glibc development
incredibly painful.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UltraSparc III
From: Jon Biddell [EMAIL PROTECTED] Date: Tue, 9 Aug 2005 20:59:28 +1000 Any progress on UltraSparc III support yet, or is it still a pain in the ass getting info out of SUN ? Linux has supported the UltraSPARC-III since I got my first SunBlade1000 system 3 or 4 years ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UltraSparc III
From: Jon Biddell [EMAIL PROTECTED] Date: Wed, 10 Aug 2005 10:26:14 +1000 I know I keep getting the dreaded Fast Data Access MMU Miss error when I boot from the debian installer CD (SILO 1.49 I believe), but booting from a Gentoo CD with the same version of SILO works fine... That's just a bug somewhere that somebody needs to track down and fix, it's not because the Ultra-III is not sufficiently documented or understood. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hardware sensors
From: Dave Love [EMAIL PROTECTED] Date: Wed, 27 Jul 2005 13:41:39 +0100 Are hardware sensors accessible on (any sort of) Ultras, and if so, how? I tried lm-sensors on U5, B100 and V210 with no joy. The bbc-envctrl driver supports the temperature and fan sensors on the SunBlade1000 systems. I am not aware of any usable sensors in the SunBlade100, and definitely not in any previous models such as the U5. The I2C bus on the SunBlade100 is mainly used for the smart card reader device that sits right above the floppy drive. Interestingly, the SunBlade100 does support cpu frequency scaling for reduced power consumption, and the us2e_cpufreq driver provides support for that under Linux. I guess there must be a fan-speed and/or temperature sensor hookup somewhere in the SunBlade100... but I have no idea where. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: drm kernel code for ffb Elite 3D card
From: [EMAIL PROTECTED] Date: Wed, 20 Jul 2005 14:27:55 +0200 I've seen on ML that the DRI hardware acceleration for the Elite 3D has been marked broken. The Elite 3D never had DRI acceleration supported on it. Only Creator3D did, and that got disabled because it was nearly impossible to add correct font rendering support and at the same time still support DRI. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Woody running SMP on a SPARCserver 1000E (sun4d)
From: Mark Morgan Lloyd [EMAIL PROTECTED] Date: Wed, 20 Jul 2005 22:50:42 + In arch/sparc/kernel/sun4d_smp.c there is a call to calibrate_delay(): this should be commented out. As far as I can tell (and I stress that I am neither a Sun guru nor a kernel hacker) it is only used for the secondary CPUs which default to the same speed as the primary one- and who in their right mind would try to run dissimilar CPUs SMP? Due to cache effects, as you boot the other cpus into the kernel, the calibrate_delay() calculation can change. We really do need to run this on every cpu, so this problem has to be fixed by some method other than simply commenting out the call to calibrate_delay() -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Elite 3D color alteration.
From: Aurelien Larcher [EMAIL PROTECTED] Date: Tue, 12 Jul 2005 00:09:21 +0200 I'm confused ... I should have RTFMed a lot more. I've discover that mplayer provide an option to swap Red and Blue. I'm going to ask the mplayer team if the option could be enabled by default for the elite 3d (is it reasonable ?) but by the way you can specify the option : mplayer -vf rgb2bgr=swap (I hope this hint can save time for other people facing this issue) I fear/'m pleased I have a lot more to learn concerning Linux and the Sun hardware ;) The RGB ordering of the frame buffer can be portably determined by asking the X server using one of the standard X library calls from the application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Elite 3D color alteration.
From: Aurelien Larcher [EMAIL PROTECTED] Date: Sun, 10 Jul 2005 14:42:43 +0200 indeed the colordepth doesn't matter (I tested from 8bits to 24bits) and it seems that red and blue are swapped with mplayer. with vlc colors are right but regarding the cpu load it seems that this player uses software rendering rather than my card. Yes, there is no hardware acceleration for movie rendering on the elite3d card. What should I do ? Is there something I can change to correct the rgb order ? (Is that the colormap I found in the web ?) mplayer needs to have the bug fixed, that's all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Elite 3D color alteration.
From: Aurelien Larcher [EMAIL PROTECTED] Date: Sun, 10 Jul 2005 02:11:25 +0200 My current problem is that colors are altered when I play a movie. The program you are using to watch the movie is not using the correct RGB order for the framebuffer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installation Problem on Sun Fire V240
From: Ben Collins [EMAIL PROTECTED] Date: Fri, 8 Jul 2005 15:11:24 -0400 So SILO from hd works, but SILO from cd doesn't? I can't think of anything that is different when booting from CD other than the first stage bootloader (which is pretty trivial). The only thing could could possibly be the issue is something to do with initrd. Maybe some bug haas crept in, maybe it's a memory mapping issue particular to the III/IIIi's. Could be that SILO is writing the initrd over top of the kernel or writing the value into the wrong place in the kernel. Quick test of this would be to see if you could boot from CD with no initrd and mounting a hd for root. Ben, one thing I've been considering a lot lately while reading these reports is a somehow corrupted sign extension when calling into the OBP. SILO is, for better or for worse, a 32-bit Sparc binary. However, we go into 64-bit mode when we jump into the firmware. If the upper 32-bits of some parameter we pass in has garbage in it, we'll totally die in the firmware. It's something to consider. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tg3 driver fails
From: Jurij Smakov [EMAIL PROTECTED] Date: Thu, 7 Jul 2005 00:38:00 -0400 (EDT) In fact, Debian is actively working on resolving this situation. Keep defending yourselves. This was a disaster regardless of the technical reasons or details of the situation. No user wants to hear a story, they want their systems to work, and developers do too. I don't want to hear a story either, because all I see are user's systems not working and nothing that can be done about it at this time. That's why many people are disappointed with the way the latest Debian stable release turned out. That's why many developers don't want to work on Debian any more, and want to move on to other distributions where it's not politics madness all the time. I'm not making this up, people email me all the time telling me they've finally had enough of Debian and intend to move on to put their energy somewhere deserving of it. Dismembering drivers so that they are non-functional, making it literally impossible to get a _one line_ timer chip probing bug fix for sparc64 into the Debian kernel tree _two months_ leading up to the stable release, among other things... Yeah keep this kind of stuff up and Debian has a very bright future. Because of the _diabolically stupid_ kernel change policies, I couldn't even help fix bugs in the kernel that were showing up in sparc64. It would have been a total waste of my time to submit any bug fix patches, because nothing was being allowed into the kernel. It's so unbelievable, I feel like I'm writing fiction when I recount it. This policy didn't make the stable release better, or go out more quickly. Instead, it turned this Debian release into a complete joke and ended up pissing off a lot of very capable and talented people who wanted to improve the release, yet couldn't because their hands were tied. It's all the stupid politics. Debian can either use this as a lesson and learn, or the Debian folks can decide instead to continue sitting around trying to justify what happened with this argument or that argument. You decide. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SunBlade 1000 Installation
From: Jon Biddell [EMAIL PROTECTED] Date: Fri, 8 Jul 2005 07:44:25 +1000 The box has an Elite3D-m3 graphics card in it - not standard for this box (came from an Ultra 80 I think), but the guy I bought it off probably took the better Creative 3D card out - anyway, does anyone know which xserver driver I should be using ? I've tried vesa, vga and fb to no effect. Use the sunffb (Creator3D) driver. You won't get any acceleration unless you explicitly load firmware onto the Elite3D card, which you'll have to get from a Solaris distribution as Sun refuses to let it be distributed with Linux distributions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tg3 driver fails
From: Hendrik Sattler [EMAIL PROTECTED] Date: Wed, 6 Jul 2005 18:25:04 +0200 They removed that code without actually testing that the driver still works or without providing any method to make it working again? Why didn't they remove the whole driver, then? Because they have commited an entirely irresponsible act by breaking people's systems like this. However, I agree that all firmware should be removed from the kernel and provided externally (like done with the AVM B1 ISDN cards). However, Debian _must_ tell then, where to find the firmware (means: don't let the user alone with this)! This doesn't work either. What if the tg3 card is your only network access? How might you get that magic firmware file? This scheme doesn't work, firmware belongs in the kernel tree so that at boot time, regardless of your internet access, you can get a working device. What if I want to use NFS root over the tg3 device? This whole situation is utterly rediculious and does nothing other than hurt users. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: execution file compiled on x86 on sparc64
From: Patrick Morris [EMAIL PROTECTED] Date: Wed, 06 Jul 2005 15:50:06 -0700 No. They're totally different architectures. Actually, indirectly you can with something like qemu which does work on Sparc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
From: Jordanek Edward [EMAIL PROTECTED] Date: Sat, 25 Jun 2005 01:30:32 +0200 (CEST) Booting Linux. PCI: Bogus PROM assignment. BUS[01] DEVFN[0] This is due to buggy firmware in some of Sun's higher end add-on PCI graphics cards. Please take the graphics card out of the PCI slot, Linux can't work on it anyways. The on-board ATI graphics inside your Sun Blade machines will work just fine. This might make FreeBSD work as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on SunBlade 1000
From: Jon Biddell [EMAIL PROTECTED] Date: Tue, 21 Jun 2005 18:21:33 +1000 Every single time I boot, from any of the Sarge install images, I get the dreaded Fast Data Access MMU Miss message. Interestingly though I can boot from Solaris 10, and from a Gentoo install CD with no problems. Can anyone offer any clues as to how to get around this ? The current stable tftpboot images should work. Sarge is from before proper UltraSPARC-III support was added to the boot loader. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on SunBlade 1000
Now comes the fun part - hardware detection. It tries to load the qlogicisp SCSI driver and says it's having problems loading it, so it can't see my two 73Gb FC drives. It needs the qlogicfc driver, not the qlogicisp one. Perhaps this is some bug in the installer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: __alloc_pages: errors resolved? [wa Re: __alloc_pages: 2-order allocation failed]
On Tue, 7 Jun 2005 11:13:21 -0400 Mike Edwards [EMAIL PROTECTED] wrote: I've abandoned the Debian 2.4 kernels in favor of vanilla 2.4.30, and this problem has yet to crop up. 11:03:06 up 9 days, 18:42, 13 users, load average: 0.47, 0.17, 0.14 Working on 10 days uptime, and no complaints. The SMTP server has yet to stop responding, too. This doesn't surprise me at all. Instead of ignoring the issue, can you please look into it? I'm glad that you think you can allocate my time and my priorities however you wish, but sadly this is not the case. I currently have more pressing matters, as networking maintainer, and simply have zero time to look into any sparc issues lately. Sorry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on SunBlade 2500
On Thu, 26 May 2005 00:59:12 -0300 Ivan Stepaniuk [EMAIL PROTECTED] wrote: I've tried to install from CD, also via tftp, in both cases it crashes when loading the kernel/initrd with diferent error mesages about memory mapping (i'll post those messages later, im at home now). I'm looking for a starting point, url, or magic recipe ;) You're the first person likely to try and install on this machine. SunBlade1500 wouldn't boot properly until I got one myself and added the necessary fixes, I certainly wish I had a 2500 too so I could make that work as well but unlike in the old days Sun doesn't loan me out hardware anymore so that I can do that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #251149: gcc wrapper for sparc is chronically broken
From: Ben Collins [EMAIL PROTECTED] Date: Tue, 24 May 2005 14:29:16 -0400 And what about building kernels? They will by default be building sparc32 kernels. That's the most likely place for this to be a problem. People can't wrap their brain around how to build a sparc64 kernel often right now anyways, making things sparc32 by default isn't going to change that. The most common error is simply not having a 64-bit libc installed, which is needed to build and execute the kernel build tools that get compiled and run as part of the kernel build. There also does not exist the necessary 64-bit versions of the graphical libraries needed to use the graphical kernel configurator. But one can override HOSTCC=gcc -m32 during the build to get that working. Anyways, back to the main point, I don't think making sparc32 the default will change the sparc64 kernel build situation one iota. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #251149: gcc wrapper for sparc is chronically broken
From: [EMAIL PROTECTED] Date: Mon, 23 May 2005 13:24:18 -0700 The other alternative is to touch /etc/disable_64_gcc Sure, but in the mail you are specifically replying to I stated: Also, /etc/disable_64_gcc is a workaround and should not be there by default as it is now, especially on your build machines. So I highly recommend that the build machine environment setup I described above is implemented. I'm going to be making GCC do this in the vanilla gcc sources by default, I've already convinced the other Sparc backend maintainers that it is the absolute right thing to do. And it won't be checking for the /etc/disable_64_gcc workaround file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug #251149: gcc wrapper for sparc is chronically broken
From: Ben Collins [EMAIL PROTECTED] Date: Mon, 23 May 2005 20:21:57 -0400 But (and this but is for David), that means users can't simply do apt-get source foo; cd foo-1.1; dpkg-buildpackage and get the same build they got from us, which is a consistency Debian needs. Maintainers trying to fix bugs on sparc in their packages that log in to one of our machines shouldn't have to worry about this subtlety either. Make the login environment be sparc32 by default. Doesn't that solve the problem? And for die-hard 64-bit people like me they can undo this via some configuration mechanism. It is one option. Another option is to bite the bullet and think about real sub-arch'ing for debian packages. Then, for a *.sparc package the dpkg building knows to sparc32 whatever, yet for a *.sparc64 package the dpkg building machinery does not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: __alloc_pages: 2-order allocation failed
From: Mike Edwards [EMAIL PROTECTED] Date: Thu, 19 May 2005 13:25:17 -0400 David, do you know if anything further was done on this issue? The spamc daemons simply don't do correct error checking on writes to AF_UNIX sockets. I thought I explained this pretty well, so that someone could go check out the userspace bits and look for the bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XVR500 on linux ?
On Fri, 20 May 2005 00:43:38 +0200 (CEST) MAURIN Sylvain [EMAIL PROTECTED] wrote: Subsidiary question ... May I do something with a XVR500 card outside Solaris world ? Not under Linux, no specs and no drivers. It might work on some of the BSD's using the VGA driver one of them has for their sparc64. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 64 bit versions of strace and gdb
On Tue, 17 May 2005 11:06:10 -0400 Ben Collins [EMAIL PROTECTED] wrote: Yes, they both are now. Where do you see those sparc64 and gdb64 packages Ben? I checked both testing and unstable, and neither have them. Do they just have some weird name? Of course, on the systems where I've installed the package file manually, apt-get install gdb64 says that I already have the latest version :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[PATCH] 2.6.x SMP UltraSPARC instability
Can folks seeing problems on SMP sparc64 boxes with 2.6.x
give this patch a try?
--- 1/arch/sparc64/kernel/irq.c.~1~ 2005-04-29 05:51:44.0 -0700
+++ 2/arch/sparc64/kernel/irq.c 2005-04-29 05:52:10.0 -0700
@@ -756,7 +756,7 @@
clear_softint(clr_mask);
}
#else
- int should_forward = 1;
+ int should_forward = 0;
clear_softint(1 irq);
#endif
@@ -1007,10 +1007,10 @@
}
upa_writel(tid | IMAP_VALID, imap);
- while (!cpu_online(goal_cpu)) {
+ do {
if (++goal_cpu = NR_CPUS)
goal_cpu = 0;
- }
+ } while (!cpu_online(goal_cpu));
return goal_cpu;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: chrony: [sparc] Fails to read RTC and floods logfiles
On Fri, 29 Apr 2005 11:48:07 +0200
Frans Pop [EMAIL PROTECTED] wrote:
One problem is that the Mostek RTC driver currently does not support the
RTC_(RD/SET)_TIME. However, the thread contains a patch that will fix
this. I am not completely sure if this patch is final yet or if has will
be (has been) submitted for inclusion in the kernel.
Please let us know your/upstream's thoughts on this.
THe fix is in upstream 2.6.x and will be in upstream 2.4.x as
soon as Marcelo sets up a GIT tree I can use to merge changes
to him.
From an strace [3] I ran on chrony when it fails and floods the logs, it
seems that the main problem is in the use of RTC_UIE_ON, RTC_UIE_OFF
calls as the clock chip does not have an interrupt node.
Perhaps some error handling can be added there.
That's correct, not all RTC devices have interrupt generation
capabilities, and thus support UIE. So logging an error when
RTC_UIE_{ON,OFF} returns -EINVAL or similar is not such a good
idea.
Now, to be fair, there is a generic RTC driver in the kernel we could
move over to, called drivers/char/genrtc.c that makes some kind of
attempt to emulate UIE in software by using timers. I may at
some point in the future move the Mostek RTC driver over to that
thing, but not anytime soon.
So in the meantime, chrony should probably not log when UIE
ioctls do not succeed, it can just mean that the RTC device
does not support generating interrupts.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
I tried everything I could and I can't get more then 6.6MB/sec out of the IDE disks on my Ultra10's. If anyone can quote better numbers on Solaris, or *BSD, or whatever, let me hear about it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, 26 Apr 2005 18:35:37 -0700 (PDT) [EMAIL PROTECTED] wrote: What kind of benchmark did you run? It would be sort of silly if I didn't do a similar test. /sbin/hdparm -t /dev/hda which does an uncached O_DIRECT 20MB read from the IDE disk, it's the real disk bandwidth not a cached number. Also, try /sbin/hdparm -c3 -m16 -d1 -X34 /dev/hda if the performance stinks even worse than the 6.6MB I'm getting. DMA tends to not get enabled by default unless the disk is in the IDE layer white list, the Seagate's that came standard in Ultra5 and Ultra10 systems just so happen to be in that white list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
On Fri, 22 Apr 2005 21:41:13 -0700 (PDT) [EMAIL PROTECTED] wrote: Oh shit, don't get me started on that IDE controller! I wish people would code as much as they complain. I'll see what I can do about making the cmd646 driver use better PIO and DMA timings like the OpenBSD and NetBSD one aparently does on Ultra5/Ultra10 et al.. Little girls, quit whining... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creator 3 D Framebuffer on Sun Ulta 1: XFree resolution and refresh rate settings
You can't change the screen resolution and refresh rates after the system has booted. Neither the kernel nor Xfree86 know how to reprogram the chip into a different resolution or refresh rate. Instead, you have to much with the OpenPROM environment variables and reset the machine. For example, from the OBP prompt: ok setenv output-device screen:r1280x1024x66 or whatever, on my large Sony flatpanel I use this: ok setenv output-device screen:r1920x1200x70 You can find a list of usable resolutions and refresh rates from the Sun Framebuffer document referenced earlier in this thread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: __alloc_pages: 2-order allocation failed
On Wed, 20 Apr 2005 15:40:41 -0400 Mike Edwards [EMAIL PROTECTED] wrote: David, this doesn't look like it's going to be easy. Show me the exact contents of the full function __get_free_pages() after your edits. You must have mad some slight error. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creator 3 D Framebuffer on Sun Ulta 1: XFree resolution and refresh rate settings
On 20 Apr 2005 22:42:32 +0200 Sebastian Niehaus [EMAIL PROTECTED] wrote: I started from the OBP prompt: the changes I make in the OBP and with the eeprom utility seem to be equivalent. Nevertheless: they don't have any effect. ... Do I have to expect the OBP screen will appear in the new refresh rate. Yes, that is what should happen. If it doesn't, this means that either: 1) The creator can't support that refresh rate, unlikely due to what you claim. 2) The OBP mode switching code does not think your monitor can handle the mode you've requested. Experiment with different modes and refresh rates. You can test more efficiently by changing the output-device setting, doing a reset-all, then from the OBP prompt cd to the FFB device node, on my system its: ok cd /SUNW,ffb Then ask for properties with the .properties command. ok .properties There are a few interesting entries here. For one, there is edid_data which is the response the OBP driver got from your monitor when it tried to auto-determine the monitor's capabilities. A value of zero here means the OBP driver will need to make very conservative decisions about what kinds of modes to accept. Next there is v_freq which is the frequency in use. On mine it's 0x46 which is decimal 70 which is what I put into my output-device env var. height and width are the resolution in pixels that OBP has decided to use. Also make sure that screen is an alias to your Creator3D device and not some other video card in your machine (if you do in fact have a video card). As you can see, things have to be absolutely perfect in your specification for the resolution to get set correctly, it is very picky. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: __alloc_pages: 2-order allocation failed
On Tue, 19 Apr 2005 10:34:52 -0400 Mike Edwards [EMAIL PROTECTED] wrote: __alloc_pages: 1-order allocation failed (gfp=0x20/0) __alloc_pages: task(spamc) pid(15858) caller(0046ed98) What symbols in the System.map of this kernel are near the 0x46ed98 address being output? It will solve the puzzle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On 19 Apr 2005 14:32:39 +0200 Sebastian Niehaus [EMAIL PROTECTED] wrote: Frans Pop [EMAIL PROTECTED] writes: On Tuesday 19 April 2005 12:33, Sebastian Niehaus wrote: | radioactive:/home/niehaus# dmesg | grep -i rtc | rtc_init: no PC rtc found I have the same problem on my Ultra 10. I don't really get it as there is an RTC present in the system There must be one since the date is set up quite correctly even without network. On the Ultra1, the drivers/sbus/char/rtc.c driver is used. It is very strange to see the rtc_init: no PC rtc found message on an Ultra5 or Ultra10, as drivers/char/rtc.c is the driver that should be used on that platform. Can someone provide /usr/sbin/prtconv -pv on either the Ultra5 or Ultra10 system which fails like this? It may provide the clue. Also, is this with a 2.4.x or 2.6.x kernel? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 21:07:34 +0200 Frans Pop [EMAIL PROTECTED] wrote: I've added a debug statement in this code, which gives the following output: Apr 19 20:39:22 localhost kernel: rtc_init: ebus auxio Apr 19 20:39:22 localhost kernel: rtc_init: ebus power Apr 19 20:39:22 localhost kernel: rtc_init: ebus SUNW,pll Apr 19 20:39:22 localhost kernel: rtc_init: ebus se Apr 19 20:39:22 localhost kernel: rtc_init: ebus su Apr 19 20:39:22 localhost kernel: rtc_init: ebus su Apr 19 20:39:22 localhost kernel: rtc_init: ebus ecpp Apr 19 20:39:22 localhost kernel: rtc_init: ebus fdthree Apr 19 20:39:22 localhost kernel: rtc_init: ebus eeprom Apr 19 20:39:22 localhost kernel: rtc_init: ebus flashprom Apr 19 20:39:22 localhost kernel: rtc_init: ebus SUNW,CS4231 Apr 19 20:39:22 localhost kernel: rtc_init: no PC rtc found So, apparently __sparc__ is defined for my U10. I also added a similar statement in the isa bus scan, so __sparc_v9__ is not set. Any ideas where the RTC could be hiding? __sparc_v9__ should be set when compiling 64-bit code... Can you add a #error OK it is set or something right under the #ifdef __sparc_v9__ to make sure? If you added debugging to the ISA loop and it didn't print out, this just means that your box lacks that bus type. Anyways, /usr/sbin/prtconf -pv output would shed more light on this problem. Thanks for your debugging so far. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: __alloc_pages: 2-order allocation failed
On Tue, 19 Apr 2005 15:17:41 -0400 Mike Edwards [EMAIL PROTECTED] wrote: I'm currently running qmail with a virtual memory limit of 64 MB (via ulimit). I wonder if it's trying to allocate more memory than that... It shouldn't change the behavior of this stuff. That limit reaching would get caught at a higher level, before we get to __alloc_pages(). 0046ed80 T __get_free_pages 0046edc0 T get_zeroed_page 0046ee00 T __free_pages 0046ee60 T free_pages Ugh... can you copy the debug statements into __get_free_pages(). Make the debugging get printed out when __alloc_pages() returns NULL. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 22:57:43 +0200 Frans Pop [EMAIL PROTECTED] wrote: Apr 19 22:32:32 localhost kernel: Real Time Clock Driver v1.12 about 30 lines skipped Apr 19 22:32:32 localhost kernel: rtc: unable to get misc minor for Mostek So, the patch looks to work. Nice one! Is this last line a problem? Actually, I take all of what I just said back. Things should have been fine before, if drivers/char/rtc.c doesn't see the device, drivers/sbus/char/rtc.c will register itself so you will have a fully functioning /dev/rtc device. That cannot find PC rtc device message can be safely ignored. You should not use the patch I posted, because drivers/char/rtc.c does not program Mostek chips correctly, it may even scramble your eeprom. chrony probably only knows about the drivers/char/rtc.c ioctl calls, not the ones provided by Sparc's drivers/sbus/char/rtc.c driver (RTC_SET and RTC_GET). You can look in the util-linux sources to see how these two sets of ioctls() are probed for, /sbin/hwclock knows how to do it for example. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On 19 Apr 2005 23:57:51 +0200 Sebastian Niehaus [EMAIL PROTECTED] wrote: Okay, Sun Ultra 5 with 2.4.27: Yes, same situation as Frans's machine. This chip is programmed by the drivers/sbus/char/rtc.c driver which only provides some Sparc specfici ioctls() to get/set RTC settings. The patch I just posted most recently for 2.6.x should allow chrony to work even in this case by providing support for the normal PC rtc driver's ioctls. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Framebuffer console not restored correctly after X server abort
On Mon, 18 Apr 2005 22:54:43 +0200 Francois Lucas [EMAIL PROTECTED] wrote: The config is an quad Ultra 80 running sid with debian 2.6 SMP kernel and a creator3D. Unfortunately, if the sunffb closedown function isn't called the color key in the framebuffer pixels is not restored to what the kernel was using resulting in the behavior you see. This should only really happen if the Xserver takes an unrecoverrable fault from which it cannot call the sunffb shutdown routines. You'll need to debug the Xserver sources to try and fix this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun hardware questions...
On Tue, 19 Apr 2005 00:04:30 + Zak Close [EMAIL PROTECTED] wrote: is it just for solaris, or can it be talked to/booted from the PROM? It is just for Solaris. The card is driven by the Solaris kernel. Userland tools communicate with the kernel driver for the PCi card to load up it's RAM with a sub-OS to run, provide a disk image from which to boot, things like that. The PCi card provides virtual dummy devices for the x86 processor environment running on that card. So there is a pseudo VGA device et al., just the most simplest things necessary to boot up a real system and run applications, nothing more. Since this has become a non-Sparc/Linux discussion, please take it to the appropriate forum. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Weird things regarding Xfree and Creator 3d (or why don't I manage to get Xvideo and DRI working)
On Sun, 17 Apr 2005 17:39:48 -0400 Ben Collins [EMAIL PROTECTED] wrote: DRI has been disabled in current xfree86 for creator3d, IIRC. That's correct. In order to support XAA and the modern font rendering stuff correctly, DRI support had to get turned off on sunffb. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: __alloc_pages: 2-order allocation failed
On Wed, 30 Mar 2005 19:01:17 -0500 Mike Edwards [EMAIL PROTECTED] wrote: The reason I asked was because the IBM article I linked to earlier seemed to indicate the problem cropped up on 64 bit systems. That problem in that article is S390 platform specific. They use these higher-order allocations for the S390 page tables. Sparc64 only uses up to order 1 allocations for it's page tables so wouldn't trigger the bug you saw. In any case, I can't recall coming across this issue before, and most of the systems I run have far less memory than this beast. :) Is there a way to fix this? Try to find out what is asking for such a large allocation. You can do that by applying a patch similar to this one so that the debug message prints out more information: = mm/page_alloc.c 1.72 vs edited = --- 1.72/mm/page_alloc.c2004-08-08 01:58:48 -07:00 +++ edited/mm/page_alloc.c 2005-03-30 16:21:23 -08:00 @@ -476,6 +476,8 @@ out: printk(KERN_NOTICE __alloc_pages: %u-order allocation failed (gfp=0x%x/%i)\n, order, gfp_mask, !!(current-flags PF_MEMALLOC)); + printk(KERN_NOTICE __alloc_pages: task(%s) pid(%d) caller(%p)\n, + current-comm, current-pid, __builtin_return_address(0)); if (unlikely(vm_gfp_debug)) dump_stack(); return NULL; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#287249: xserver-xfree86: Crashes on SPARC with Elite3D/m6
On Sat, 26 Mar 2005 20:32:44 +0100 T.Amm [EMAIL PROTECTED] wrote: Any other install kernel just gives me a MMU-Fast Instruction Miss. So I am actually damned with Solaris - which is not *so* bad - but what's life without Linux? Use the latest Sarge testing boot images, I'm happily running Debian on my 1.5GHZ SB1500 Back to the bug report. The X server already makes a check, but there was some talk the other week about this check crashing Creator3D chips (since we poke a register that only exists on the Elite3D card to check this) so it's possible someone patched the test out or changed it. I haven't looked at the X server sources in a year or so unfortunately, so I'm pretty out of touch with the current state of the tree. And with a million and a half networking and sparc64 kernel things to do, I doubt I'll get back to it any time soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc32 Floppy Eject
On Thu, 24 Mar 2005 14:27:27 +0100
Frans Pop [EMAIL PROTECTED] wrote:
David: do you maybe have some ideas?
If you are referring to me here, can I ask that you CC: people
you wish to get the attention of? I only noticed this by accident
while scanning my debian-sparc folder.
I can't think of anything changed in the floppy driver that would
break this. It's a very simple ioctl (FDEJECT), so the only places
where this could be effected are:
1) arch/sparc64/kernel/ioctl32.c, and fs/compat_ioctl.c (which the former
includes), make sure FDEJECT is marked properly so that 32-bit
binaries can use this ioctl properly, if this is occuring
on a sparc64 kernel
2) check the FDEJECT handling in drivers/block/fd.c and
include/asm-sparc{,64}/floppy.h
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Weird Mouse Behaviour with 2.6
On Fri, 18 Mar 2005 10:27:20 +0100 Detlef [EMAIL PROTECTED] wrote: Kindly ignoring the fact that the Keyboard and Mouse will not work because set-up for Kernel 2.6 (IMHO the most useless change to the kernel ever) Absolutely wrong. The previous situation was a mess, keyboard maps had to be coded up for every keyboard type out there. Now, multi-lingual keyboard maps need to be written for only one keyboard type, x86. Reconfigure the console package properly to just use the kernel default keymap. b) reboot and use kernel 2.6.11 (or 2.6.8) got to ssh to the machine from a different box to reboot because the kernel handles the keyboard differntly As said before after using this procedure the mouse works as expected even after further reboots of 2.6.11.2 / 2.6.8-2. Yes, there is some problem initializing the serial line that the keyboard and mouse use. The break characters that get detected when the baud rate is incorrect are not showing up for some reason. What kind of machine is this? It only happens with certain serial controllers, not all, which is why your machine type is important. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On Tue, 15 Mar 2005 21:34:04 +0100 Detlef [EMAIL PROTECTED] wrote: Is a multihead / Xinerama configuration with Sparc possible at all? I've gotten it to work often with multiple creator3d cards, but never with mixed card types. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On 16 Mar 2005 01:27:49 + Martin [EMAIL PROTECTED] wrote: I suspect there is something wrong with the PCI scan of X. Scanpci does only list the 66MHz PCI Bus omitting the second bus installed whereas lspci sees all of the devices. There certainly used to be something wrong with it. Check the archives for around autumn last year (IIRC), there was a patch for handling scanning the PCI bus. I have seen one message about this but was not able to find out more. where and how would I look for these? I think it was relating to running X on SPARC on a 2.6 kernel and was around the time 2.6 came out. Which would mean it was some time in 2004. Download the archives and grep or google seem like your best options. The PCI device tree names under /proc/bus/pci have changed to the format of: /proc/bus/pci/$(PCI_DOMAIN_NUM):$(PCI_BUS_NUM)/ instead of the old: /proc/bus/pci/$(PCI_BUS_NUM)/ X's device probe has never been fixed to handle this correctly. It really needs this fix, as X is busted on multiple platforms with 2.6.x kernels because of this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On 16 Mar 2005 02:48:27 + Martin [EMAIL PROTECTED] wrote: This: http://lists.debian.org/debian-sparc/2004/05/msg00203.html purports to be a patch, seems a bit hack-ish but looks like a start. I guess it's not a complete solution for the reason given here: http://lists.debian.org/debian-sparc/2004/01/msg00026.html Right, it only works when your video card is behind the first PCI controller. The latest CVS version of XFree86 seems to have a different solution which I /think/ solves the problem. http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c change 249 249. Deal with Linux 2.6's PCI bus naming (Marc La France). It looks promising. But given that 4.4 won't be in Debian for licencing reasons and there is a migration to X.org planned for post-sarge it does seem like quite a reasonable approach to solving the problem. Right, and I'm more than happy to work on a careful backport of that patch. I'll try to find some time for that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 14 Mar 2005 16:59:49 -0500 Joey Hess [EMAIL PROTECTED] wrote: Mark Brown wrote: Me too, probably. I'd managed to completely miss the call for help in the last status updates (looking at the announcement I must've started skimming well before the call for help in the kernel section). Outside of the kernel what areas need attention for SPARC? We seem to have some serious problems with d-i on newer sun systems (such as sun blades). Keyboard doesn't work, CD may not work. This may or may not be a kernel problem. Just one thing I happen to know of. Which exact blade models? My SB1500 is my main workstaion and besides that (fixed) clock probing issue, the machine works flawlessly. There are minor ATI Radeon xfree86 driver issues, which I'll submit fixes for, but simply using fbdev as the driver works perfectly fine and works around those problems. Also, my CDROM and USB keyboard worked fine. I have a SB100 and a SB1000 here as well for testing and fixing such problems. The only thing really missing from my arsenal are SB150 and SB2500. I'd accept donations of either for sparc64 support purposes (hint hint) :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AtyFB in 2.6.10, still not perfect
On Mon, 14 Mar 2005 23:50:02 +0100 Luigi Gangitano [EMAIL PROTECTED] wrote: Hi all, I've just upgraded to the latest kernel-source-2.6.10 and recompiled it. AtyFB on my SB100 works now (sort of), but the console misses the first column on the left and some random pixels are corrupted. Under XFree86 I've got the same corruption of randome areas of the screen (I'll try to get some screenshot if this is of help). This is the relevant output of kernel (really I still don't know how to interpret it... :-)): The mach64 chip on the SB100 has some very odd PLL clock inputs compared the what is shipped on PCI and AGP cards sold for PCs. Reporting these details here isn't really going to help much, as the folks active with the kernel ATI driver don't read this mailing list. Could you please, therefore, report your stuff to [EMAIL PROTECTED] who seems to be the most active person working on this driver lately? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SunBlade D-I problems
On Mon, 14 Mar 2005 22:21:53 -0500 Joey Hess [EMAIL PROTECTED] wrote: Yes, but I didn't realize that it was probably a non-bug. Do you think I ought to revert that then? I think so, just autoloading modules to work around incorrect SBUS module loading isn't such a good idea. Ben didn't mention in #299074 what version of d-i he used, but it seems unlikely that it predated rc2, which should have included that change. I've pinged Ben under seperate cover, asking him to provide this information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SunBlade D-I problems
On Mon, 14 Mar 2005 21:51:48 -0500 (EST) Jurij Smakov [EMAIL PROTECTED] wrote: After discussing it with Joshua Kwan, I came to believe that this is just another incarnation of the CMD646 problem. He had quite a lot of troubles trying make it work as a module, in the end it was just compiled in 2.4.27, which took care of the problem. The same solution can be used for ALI, but it would be nice to get to the root of it. Autoprobing for SBUS devices has been included in discover1 for quite some time now. And it works nicely with the recent (pre-RC3) installer images, I have tested it myself just a few days ago on an Ultra 1. How exactly is the SBUS device traversal performed? Using /proc/openprom or /dev/openprom tree walking? If that is the kind of method used, there are so many different paths you have to try in order to get at all the SBUS bus roots correctly. In particular, on a machine like Ben's E4500, there are probably 4 or so SBUS roots in his machine. There are examples in the prtconf sources in the sparc-utils package of what the device tree layouts look like. In hindsight I should have provided some /proc or /sys based SBUS device tree. Eventually I'll code up something like that so people don't have to poke around the firmware device tree for SBUS probing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Elite3D PCI, anyone?
On Wed, 2 Mar 2005 16:40:48 +0100 (CET) Chris Andrew [EMAIL PROTECTED] wrote: I had an Elite card in my Ultra 60. You need to install a package to get it to work. The package is afbinit, and comes with Woody. What he hasn't isn't an AFB (which Sun calls Elite3d). It's a PCI card made by 3dlabs (which Sun calls Expert 3d) which has no Linux drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Elite3D PCI, anyone?
On Wed, 2 Mar 2005 02:35:55 +0100 (MET) Eddie C. Dost [EMAIL PROTECTED] wrote: I have a Rage 7000 Mac card working in my Uax just fine. The Rage 7000 Mac is also an ATI card but newer version. The Mac stuff says its an OBP card. Very good so far. This card can do reasonable 32bit screens with 1280 x 1024... The problem is ATI messed up two small spots in the OBP and got caught by powerpc machine specific issues. The card won't boot at all, i.e. the Ultra wont come up at all with the original card. I have set up some binary patches for my specific Rage 7000 card, which work well for me. Sun sells and uses a Rage 7000 with OBP on it too. They call it the XVR-100 and I have one in the SunBlade-1500 (Silver) I just got. Node 0xf00917a0 address: faddc000 assigned-addresses: c2001810..0800..0800.81001814..0300..0100.82001818..0010..0001.82001830..0012..0002 aty,fcode: '1.86' aty,card#: '102-85514-00' aty,rom#: '113-85514-101' version: '@(#)xvr100.fth 2.3 03/10/17 SMI ' reg: 1800.....02001810....0400.02001814....0100.02001818....8000.02001830....0002 character-set: 'ISO8859-1' display-type: 'CRT' depth: 0008 linebytes: 0700 height: 04b0 width: 0640 aty,sclk: 000249f0 aty,mclk: 000249f0 aty,refclk: 6978 aty,flags: 039b edid: 00ff.ff00.4dd9d000.67175700.2d0d0103.0e321f78.eacea9a3.574c9926.19484cbd.ee80a940.81808140.01010101.01010101.0101734b.80a072b0.2a4080d0.1300ef35.111c.483f4030.62b03240.40c01300.ef351100.001e.00fd0037.411e5f14.000a2020.20202020.00fc.0053444d.2d503233.32570a20.202000af device_type: 'display' model: 'SUNW,375-3181' name: 'SUNW,XVR-100' fcode-rom-offset: 66mhz-capable: fast-back-to-back: devsel-speed: 0001 class-code: 0003 interrupts: 0001 latency-timer: 0040 cache-line-size: 0010 max-latency: min-grant: 0008 subsystem-id: 0908 subsystem-vendor-id: 1002 revision-id: device-id: 5159 vendor-id: 1002 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Elite3D PCI, anyone?
On Tue, 01 Mar 2005 20:58:25 +0100 Luigi Gangitano [EMAIL PROTECTED] wrote: I'm pleased to become part of the debian sparc minority (as some folks on -devel want to point out: let's remove all of them!!!). :-) So here I have my brand new Sun Blade 100 (not that new...) to help debian spread on Sparc. Installation went fine, new kernel as well. Just the Elite3D PCI is not recongnized by X: :01:02.0 VGA compatible controller: Intergraph Corporation: Unknown device 07a0 I've seen the SBus drivers, and will be hacking the next days on them. Did anyone already solved the puzzle? (just asking). It's a totally different chipset (3dlabs), there is no documentation available and therefore there will likely never be a driver for Linux. Take that PCI card out and use the on-board PGX64 (ATI mach64 based) video, Linux works on that just fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later
On Wed, 16 Feb 2005 03:27:51 +0100 Frans Pop [EMAIL PROTECTED] wrote: Excellent! Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores the old behavior. I guess that solves the regression since 2.6.10-rc2. Please let me know if this patch will be submitted for inclusion as is so I can also submit it for inclusion in the Debian 2.6.10 kernel. I applied it and will push upstream. I would like to set a lower default resolution as my monitor barely supports [EMAIL PROTECTED] I tried two things: - # eeprom output-device=screen:r1024x768x70 This seems to be completely ignored during boot; resolution is still 1152x900. The PROM console driver will only accept certain settings. I believe the allowable settings is documented in the Sun Framebuffer Handbook or something like that. - boot with parameter 'video=atyfb:[EMAIL PROTECTED]' This does work, but csync is not set to high and so the monitor again goes into suspend; after 'fbset -csync high' the monitor turns on. Is csync something that needs to be set by the user or should the driver take care of that also at frequencies other then 1152x900? Unfortunately, the user needs to specify this. I, at one point, even convinced the XFREE86 mach64 maintainer to enable CSYNC by default and that broke things for some users and thus the default had to be changed back to off. Therefore the kernel fb driver shouldn't turn CSYNC on by default either. The second question concerns the use of Stop-A. If you tell the kernel to use a different resolution than the PROM had, stop-a is not going to work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HELP] [PORT] sparc vs sparc5 vs ultrasparc?
On Sat, 25 Dec 2004 15:34:17 -0600 Marcelo E. Magallon [EMAIL PROTECTED] wrote: 4. There's some assembly versions of a couple of routines, but they are only used on sunos, not linux. I don't know if these are maintained or not. Is someone willing to try this out and tell me if these work? Grep for USE_SPARC_ASM in the mesa sources (6.2.1 from upstream). That's a bug in the Makefiles, Linux/Sparc should make use of them too. They are maintained and work, I wrote them I should know :-)
Re: uses only 10 out of 12 cpus on a E4500, 2.6.9
On Thu, 23 Dec 2004 23:21:41 -0600 morten pedersen [EMAIL PROTECTED] wrote: i have an E4500 with 12 cpus. when i installed Sarge i had 10 cpus. i upgraded to 12. but it only probes and uses 10. when it boots, POST shows 12 ok cpus. any ideas? It's due to the CONFIG_NR_CPUS setting used when building the kernel. It needs to be larger than the largest physical cpu number in your machine in order to use all available processors.
Re: E250, Raptor gfx, kernel 2.6: questions...
On Tue, 23 Nov 2004 15:24:51 -0500
Ron Murray [EMAIL PROTECTED] wrote:
When I try to run X under a 2.6 kernel (currently 2.6.9) it fails
(segfaults) at the point where it should be scanning the PCI
bus. We're beginning to think that this isn't a framebuffer problem,
but rather a problem in X itself. Anyone know of any problems with X
under sparc64 with 2.6 kernels? I'm using the current sarge X
packages.
There was a bug with mmap'ing frame buffers in 2.6.x kernels
which was only fixed within the past few days. This may be
what you're seeing. Try this patch:
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/11/16 22:11:16-08:00 [EMAIL PROTECTED]
# [SPARC64]: Do not set VM_LOCKED on I/O mapped areas.
#
# Use VM_RESERVED instead.
#
# Signed-off-by: David S. Miller [EMAIL PROTECTED]
#
# drivers/video/sbuslib.c
# 2004/11/16 22:10:39-08:00 [EMAIL PROTECTED] +1 -1
# [SPARC64]: Do not set VM_LOCKED on I/O mapped areas.
#
# drivers/video/fbmem.c
# 2004/11/16 22:10:39-08:00 [EMAIL PROTECTED] +1 -2
# [SPARC64]: Do not set VM_LOCKED on I/O mapped areas.
#
# drivers/video/aty/atyfb_base.c
# 2004/11/16 22:10:39-08:00 [EMAIL PROTECTED] +1 -3
# [SPARC64]: Do not set VM_LOCKED on I/O mapped areas.
#
# arch/sparc64/kernel/pci.c
# 2004/11/16 22:10:38-08:00 [EMAIL PROTECTED] +1 -1
# [SPARC64]: Do not set VM_LOCKED on I/O mapped areas.
#
diff -Nru a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
--- a/arch/sparc64/kernel/pci.c 2004-11-23 12:17:00 -08:00
+++ b/arch/sparc64/kernel/pci.c 2004-11-23 12:17:00 -08:00
@@ -725,7 +725,7 @@
static void __pci_mmap_set_flags(struct pci_dev *dev, struct vm_area_struct
*vma,
enum pci_mmap_state mmap_state)
{
- vma-vm_flags |= (VM_SHM | VM_LOCKED);
+ vma-vm_flags |= (VM_IO | VM_RESERVED);
}
/* Set vm_page_prot of VMA, as appropriate for this architecture, for a pci
diff -Nru a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
--- a/drivers/video/aty/atyfb_base.c2004-11-23 12:17:01 -08:00
+++ b/drivers/video/aty/atyfb_base.c2004-11-23 12:17:01 -08:00
@@ -1844,7 +1844,7 @@
size = vma-vm_end - vma-vm_start;
/* To stop the swapper from even considering these pages. */
- vma-vm_flags |= (VM_SHM | VM_LOCKED);
+ vma-vm_flags |= (VM_IO | VM_RESERVED);
if (((vma-vm_pgoff == 0) (size == info-fix.smem_len)) ||
((off == info-fix.smem_len) (size == PAGE_SIZE)))
@@ -1890,8 +1890,6 @@
if (!map_size)
return -EINVAL;
-
- vma-vm_flags |= VM_IO;
if (!par-mmaped)
par-mmaped = 1;
diff -Nru a/drivers/video/fbmem.c b/drivers/video/fbmem.c
--- a/drivers/video/fbmem.c 2004-11-23 12:17:00 -08:00
+++ b/drivers/video/fbmem.c 2004-11-23 12:17:00 -08:00
@@ -906,9 +906,8 @@
off += start;
vma-vm_pgoff = off PAGE_SHIFT;
/* This is an IO map - tell maydump to skip this VMA */
- vma-vm_flags |= VM_IO;
+ vma-vm_flags |= VM_IO | VM_RESERVED;
#if defined(__sparc_v9__)
- vma-vm_flags |= (VM_SHM | VM_LOCKED);
if (io_remap_page_range(vma, vma-vm_start, off,
vma-vm_end - vma-vm_start, vma-vm_page_prot,
0))
return -EAGAIN;
diff -Nru a/drivers/video/sbuslib.c b/drivers/video/sbuslib.c
--- a/drivers/video/sbuslib.c 2004-11-23 12:17:01 -08:00
+++ b/drivers/video/sbuslib.c 2004-11-23 12:17:01 -08:00
@@ -52,7 +52,7 @@
off = vma-vm_pgoff PAGE_SHIFT;
/* To stop the swapper from even considering these pages */
- vma-vm_flags |= (VM_SHM | VM_IO | VM_LOCKED);
+ vma-vm_flags |= (VM_IO | VM_RESERVED);
/* Each page, see which map applies */
for (page = 0; page size; ){
Re: Intall Debian on Sun Blade 1000
On Sun, 07 Nov 2004 00:01:17 +0100 Turbo Fredriksson [EMAIL PROTECTED] wrote: Don't use USB, it's not supported on the UltraSPARC III (yet)... Yes it does work fine on UltraSPARC-III and has done so for years. It drives the keyboard and mouse for one thing.
Re: sun blade 1500 install
On Wed, 27 Oct 2004 23:48:55 +0200 [EMAIL PROTECTED] (Geert Stappers) wrote: short answer why this approach fails: the boot image does not seem to contain support for the network interface (tg3). Contact your hardware supplier (or better: demand GPL drivers before you buy) Think before replying, please? There is a fully open-source tg3 driver that supports the sunblade1500 onboard ethernet. The debian images just don't have it added to the boot image. I understand all of the issues with included firmware, but that's been edited out of the debian kernel trees and it's a no-brainer to add this driver to the sparc install images.
Re: buildd failure for sparc - floating point encoding?
On Wed, 27 Oct 2004 00:44:56 +0100 Helen Faulkner [EMAIL PROTECTED] wrote: #if defined(sun)||defined(MIPSEB)||defined(IBMRS)||defined(HP)||defined(NeXT)||defined(mac)||defined(POWERPC) # define FP1cpu #endif This first define test should be __sparc__ instead of sun.
Re: raptor gfx
On Fri, 8 Oct 2004 07:21:46 -0400 Huston [EMAIL PROTECTED] wrote: What driver and settings do I need to use with the above video card on an Sun E250 server It's a permedia2 graphics chip.
Re: Lack of 64 bit support in devel tools for stable, current and future.
On Mon, 04 Oct 2004 11:29:01 -0700 [EMAIL PROTECTED] wrote: The lack of a 64 bit compiler able to compile to a 64bit sparc version 9b instruction set is really, really, really, really pissing me and hundreds if not thousands of other people off. The versions of gcc available in the current stable is lacking this MUCH NEEDED SUPPORT and since all you have to do is read the documentation and use the correct host in your configure of gcc I really see no reason why such idiocy needs to continue. The testing distribution, and what will become the next stable distribution, has everything you are complaining is missing. The technology simply wasn't ready back when sarge was released. It isn't simply a matter of reading the documentation and rebuilding gcc, you also have to provide all of the libraries side-by-side with their 32-bit counterparts and therefore there are packaging, filesystem layout, and build environment issues as well. You want to make the problem seem much simpler than it really is.
Re: kernel-image-2.6*-sparc32-smp missing
On Fri, 24 Sep 2004 17:47:35 +0200 Hendrik Sattler [EMAIL PROTECTED] wrote: Am Donnerstag, 23. September 2004 22:19 schrieb Hendrik Sattler: uname[12]: Unimplemented SPARC system call 188 readlink[14]: Unimplemented SPARC system call 188 S02mountvirtfs[13]: Unimplemented SPARC system call 188 touch[15]: Unimplemented SPARC system call 188 mountpoint[16]: Unimplemented SPARC system call 188 mount[17]: Unimplemented SPARC system call 188 BTW: what is this SPARC system call 188 anyway? Is this a real kernel bug or just a noisy klogd? It's just noise. It is the system call glibc uses to see if the newer threading system calls are available, which they are not in 2.4.x kernels.
Re: Kernel 2.6.8 - SILO/initrd problems
On Fri, 10 Sep 2004 21:26:13 -0700 Joshua Kwan [EMAIL PROTECTED] wrote: With our upcoming release in mind it may be a better idea to fix the kernel instead of hacking around it in userspace... Why is the kernel in need of fixing? In particular, given the fact that from a distribution maker's perspective, the 2.6.x behavior (generating _ONLY_ x86 key codes to userspace regardless of architecture or keyboard type) is a boon for simplification for keyboard configuration. No more Sun/ARM/PPC/etc. specific crap needed anymore. In fact I find it quite puzzling that, given the above, you want to revert back to the 2.4.x days of complicated keyboard configuration.
Re: Kernel 2.6.8 - SILO/initrd problems
On Sat, 11 Sep 2004 01:00:18 +0100 Neil Pilgrim [EMAIL PROTECTED] wrote: AFAIK you need to have the initrd line in your silo.conf. However 2.6.x kernels appear to be broken under debian ATM - the reason that I'm not using 2.6.x :( I do all of my 2.6.x kernel development, and I mean all of it even kernel networking maintainence, on sparc64. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=269405 kernel-image-2.6.8-1-sparc64: keyboard problem [bug in console-data] If you simply, as the bug report recommends, run dpkg-reconfigure on console-data package and tell it to simply use the kernel keymap things will work perfectly fine for both 2.4.x and 2.6.x kernels on sparc64. I guess tha answers your question in the bug report.
Re: cfdisk on sparc?
On Mon, 6 Sep 2004 15:03:37 +0200 Jan-Benedict Glaw [EMAIL PROTECTED] wrote: cfdisk is AFAIK only used to edit DOS or PC-BIOS like partition tables. Sparc computers use their slices only, so there's exactly no use for such a partition sector on a Sparc computer's harddisk... Not true, people can and do use PC style boot blocks on their Sparc systems all the time. You just can't use one easily on the partition you wish to boot from, that's all. In fact this is a major feature, in that you can attach x86/Linux disks up to your Sparc to examine them and retrieve data.
Re: Wintv card in Ultra sparc 10
On Mon, 6 Sep 2004 15:18:04 -0400 Ben Collins [EMAIL PROTECTED] wrote: From what I understand, you have to use the latest 2.6 kernel to do it (where the driver has been fixed not to use virt_to_bus and friends). The 2.4.x version should work fine too, I was using it with my Nintendo64 2 years ago.
Re: [PATCH] Re: lvm problems on sparc64 - Trying to vfree() nonexistent vm area
On Thu, 02 Sep 2004 11:58:12 +0100 Richard Mortimer [EMAIL PROTECTED] wrote: On Thu, 2004-09-02 at 02:37, David S. Miller wrote: On Tue, 31 Aug 2004 23:00:10 +0100 Richard Mortimer [EMAIL PROTECTED] wrote: How do they look Please resend your patch without all the line breaks created by your email client. It looks fine otherwise :) Bah. Clients are just getting too clever these days. Hopefully this should be ok. Thanks a lot Richard, applied.
Re: [PATCH] Re: lvm problems on sparc64 - Trying to vfree() nonexistent vm area
On Tue, 31 Aug 2004 23:00:10 +0100 Richard Mortimer [EMAIL PROTECTED] wrote: How do they look Please resend your patch without all the line breaks created by your email client. It looks fine otherwise :)
Re: debian on a Sun Netra 1125
On Mon, 30 Aug 2004 10:54:32 +1000 (EST) Craig Ian Dewick [EMAIL PROTECTED] wrote: If you want good performance don't get a Sparc :-) It depends what 'performance' means to you. If it means raw i/o and data processing ability then you want Sparc, otherwise if you equate 'performance' to be how fast Doom 1/2/3/etc. runs on your computer, then you're better off with a Wintendo machine. You can laugh and call it Wintendo all you want, but even the I/O performance of modern x86 (and Opteron) systems blows Sparc away. I would kill to get the main bus and memory performance of a modern x86 on my UltraSPARC-III machines. I would kill also to even get just a PCI-X host controller, but Sun still hasn't made a PCI-X chipset for their Sparc systems yet. Current generation x86 systems are shipping with PCI Express now, which therefore puts Sparc boxes two generations behind as far as PCI bus technology is concerned. As far as main memory performance is concerned, several x86 _laptops_ have faster main memory than current generation UltraSPARC boxes do. As sparc64 kernel maintainer you'd think I'd have a vested interest in touting how great Sparc is. Performance isn't that category these days, and it hasn't been so in a _long_ time. There are some things about sparc I find beautiful, and doing all of my work on sparc64/linux means that I get to help find portability bugs quite effectively in code people send me. Sun doesn't even submit UltraSPARC single cpu CINT2000/CFP2000 numbers any more, for that they submit the numbers of their Opteron machines. They still submit numbers for 32 processor and larger systems for CINT2000 Rate and CFP2000 Rate. Look at the most recent time Sun posted single cpu UltraSPARC numbers. It was first quarter 2004, a paltry CINT2000 of 608 and 613 for 1.2 GHZ cpus. Meanwhile a Dell Precision Workstation 360 with 2.8GHZ P4 x86 chips is churning out a score of 1205. Price on dell.com for such a machine, fully loaded, is ~$1600.00 USD. The Sun machine, a V240, in comparison, will set you back $3595.00USD for a minimal config. And take this in, understanding that Sun has some of the brightest compiler optimization people on the planet. I even tried to take a look at SECweb99 numbers. I had to go all the way back to 2002 second quarter, where they have a Sun Fire V480 4 processor scoring 4500 when meanwhile a 4 cpu Del PowerEdge 6600 4 processor running Linux/TUX handily spanks it scoring 5750. Another example from that series, Sun Netra20 2 cpu at 2503 and 2 cpu Dell PowerEdge 2650 at 4130. If that's not an example of raw i/o and data processing ability I don't know what is. If I'm setting up a high end web server, I don't think I'd be using Sparc thanks :) If I wanted a fast machine with good cpu performance and a fast disk and networking, I'd get a 3+ Ghz Xeon or an Opteron with PCI-X or perferably PCI Express. I'd have a machine composed of commodity parts, and my choice of a handful of OS's and several compilers. And hey if it's too expensive for me right now, I'd just wait a month or two for the price to get chopped in half. I've meanwhile been waiting for a year or longer for SunBlade1500 prices to lower enough so I can get my hands on one to improve Linux support. And yes, I'd be able to play quake3 and doom3 on it too :-)
[PATCH] Re: lvm problems on sparc64 - Trying to vfree() nonexistent vm area
On Tue, 31 Aug 2004 01:15:40 +0100 Richard Mortimer [EMAIL PROTECTED] wrote: I'm seeing problems with lvm on sparc64. I have a reproducible test case using snapshots where I can reliably reproduce an error similar to Trying to vfree() nonexistent vm area (000140072000) For once it's not sparc64's fault, it's a bug in the generic LVM ioctl handling :-) It saves both pointers, clobbers the userspace copy, then only restores one of the two pointers correctly. Easy to fix, see below. Marcelo, please apply, thanks. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/08/30 17:24:05-07:00 [EMAIL PROTECTED] # [LVM]: Do not forget to restore both user pointers. # # This in particular can make compatability layers # crash, and it is a bug for regular applications # too. # # Signed-off-by: David S. Miller [EMAIL PROTECTED] # # drivers/md/lvm.c # 2004/08/30 17:23:48-07:00 [EMAIL PROTECTED] +12 -0 # [LVM]: Do not forget to restore both user pointers. # # This in particular can make compatability layers # crash, and it is a bug for regular applications # too. # # Signed-off-by: David S. Miller [EMAIL PROTECTED] # diff -Nru a/drivers/md/lvm.c b/drivers/md/lvm.c --- a/drivers/md/lvm.c 2004-08-30 17:24:13 -07:00 +++ b/drivers/md/lvm.c 2004-08-30 17:24:13 -07:00 @@ -2689,6 +2689,10 @@ (lv_status_byname_req.lv-lv_current_pe, saved_ptr1, sizeof(void *)) != 0) return -EFAULT; + if (copy_to_user + (lv_status_byname_req.lv-lv_block_exception, +saved_ptr2, sizeof(void *)) != 0) + return -EFAULT; return 0; } } @@ -2743,6 +2747,10 @@ (lv_status_byindex_req.lv-lv_current_pe, saved_ptr1, sizeof(void *)) != 0) return -EFAULT; + if (copy_to_user + (lv_status_byindex_req.lv-lv_block_exception, saved_ptr2, +sizeof(void *)) != 0) + return -EFAULT; return 0; } /* lvm_do_lv_status_byindex() */ @@ -2799,6 +2807,10 @@ /* Restore usermode pointers */ if (copy_to_user (lv_status_bydev_req.lv-lv_current_pe, saved_ptr1, +sizeof(void *)) != 0) + return -EFAULT; + if (copy_to_user + (lv_status_bydev_req.lv-lv_block_exception, saved_ptr2, sizeof(void *)) != 0) return -EFAULT;
Re: xine-lib build failure on sparc buildds
It's a binutils sparc bug, see the archives of debian-sparc, where I posted a fix. But for some reason nobody has fired up a new binutils build yet to get this fixed up. :-/
Re: debian on a Sun Netra 1125
On Sun, 29 Aug 2004 19:11:23 +0200 Daniel J. Priem [EMAIL PROTECTED] wrote: What can you say about the performance of this machine. how fast is it? like a duro 1800 or what. i only know that a sparc is about Mhz*3=i386 If you want good performance don't get a Sparc :-) I also heavily disagree with that Mhz formula, if I had to give one I'd give something closer to mhz*1.5 at best. But with the speed the main busses are getting on x86 these days, that multiplier is getting smaller and smaller. And the x86 uses memory much better than sparc due to the increased code density the x86 CISC instruction set has. It's amusing, the things that people said was a large disadvantage, turns out the be a huge benefit. :-)
Re: [PATCH] SunSAB console problems in 2.6.x
On Fri, 27 Aug 2004 17:01:01 -0700
Joshua Kwan [EMAIL PROTECTED] wrote:
-mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o
+mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o delay.o
lib-$(CONFIG_DEBUG_SPINLOCK) += debuglocks.o
lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
You forgot delay.c.
Sorry, I'm a retard.
This patch should be better.
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/08/27 16:12:23-07:00 [EMAIL PROTECTED]
# [SPARC64]: Fix delay with HZ==1000.
#
# When I moved sparc64 over to HZ==1000 this added some
# problems to the udelay() handling. Specifically, with
# slower cpus we could now get underflows to zero for
# things like udelay(1) due to the order of multiplies
# and shifts.
#
# Fix this, and move it out to arch/sparc64/lib/delay.c
# so it is easier to tinker with this in the future and
# also to optimize away one of the multiplies for the
# constant delay case just like other platforms do.
#
# Signed-off-by: David S. Miller [EMAIL PROTECTED]
#
# include/asm-sparc64/delay.h
# 2004/08/27 16:10:13-07:00 [EMAIL PROTECTED] +21 -46
# [SPARC64]: Fix delay with HZ==1000.
#
# arch/sparc64/lib/Makefile
# 2004/08/27 16:10:13-07:00 [EMAIL PROTECTED] +1 -1
# [SPARC64]: Fix delay with HZ==1000.
#
# arch/sparc64/kernel/sparc64_ksyms.c
# 2004/08/27 16:10:13-07:00 [EMAIL PROTECTED] +6 -0
# [SPARC64]: Fix delay with HZ==1000.
#
# arch/sparc64/lib/delay.c
# 2004/08/27 16:10:01-07:00 [EMAIL PROTECTED] +49 -0
# [SPARC64]: Fix delay with HZ==1000.
#
# arch/sparc64/lib/delay.c
# 2004/08/27 16:10:01-07:00 [EMAIL PROTECTED] +0 -0
# BitKeeper file /disk1/BK/sparc-2.6/arch/sparc64/lib/delay.c
#
diff -Nru a/arch/sparc64/kernel/sparc64_ksyms.c
b/arch/sparc64/kernel/sparc64_ksyms.c
--- a/arch/sparc64/kernel/sparc64_ksyms.c 2004-08-27 16:48:00 -07:00
+++ b/arch/sparc64/kernel/sparc64_ksyms.c 2004-08-27 16:48:00 -07:00
@@ -372,6 +372,12 @@
EXPORT_SYMBOL_NOVERS(memmove);
EXPORT_SYMBOL_NOVERS(strncmp);
+/* Delay routines. */
+EXPORT_SYMBOL(__udelay);
+EXPORT_SYMBOL(__ndelay);
+EXPORT_SYMBOL(__const_udelay);
+EXPORT_SYMBOL(__delay);
+
void VISenter(void);
/* RAID code needs this */
EXPORT_SYMBOL_NOVERS(VISenter);
diff -Nru a/arch/sparc64/lib/Makefile b/arch/sparc64/lib/Makefile
--- a/arch/sparc64/lib/Makefile 2004-08-27 16:48:00 -07:00
+++ b/arch/sparc64/lib/Makefile 2004-08-27 16:48:00 -07:00
@@ -12,7 +12,7 @@
U1memcpy.o U1copy_from_user.o U1copy_to_user.o \
U3memcpy.o U3copy_from_user.o U3copy_to_user.o U3patch.o \
copy_in_user.o user_fixup.o memmove.o \
-mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o
+mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o delay.o
lib-$(CONFIG_DEBUG_SPINLOCK) += debuglocks.o
lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
diff -Nru a/arch/sparc64/lib/delay.c b/arch/sparc64/lib/delay.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/sparc64/lib/delay.c 2004-08-27 16:48:00 -07:00
@@ -0,0 +1,49 @@
+/* delay.c: Delay loops for sparc64
+ *
+ * Copyright (C) 2004 David S. Miller davem@redhat.com
+ *
+ * Based heavily upon x86 variant which is:
+ * Copyright (C) 1993 Linus Torvalds
+ * Copyright (C) 1997 Martin Mares [EMAIL PROTECTED]
+ */
+
+#include linux/delay.h
+
+void __delay(unsigned long loops)
+{
+ __asm__ __volatile__(
+ b,pt%%xcc, 1f\n
+ cmp%0, 0\n
+ .align 32\n
+1:\n
+ bne,pt %%xcc, 1b\n
+ subcc %0, 1, %0\n
+ : =r (loops)
+ : 0 (loops)
+ : cc);
+}
+
+/* We used to multiply by HZ after shifting down by 32 bits
+ * but that runs into problems for higher values of HZ and
+ * slow cpus.
+ */
+void __const_udelay(unsigned long n)
+{
+ n *= 4;
+
+ n *= (cpu_data(smp_processor_id()).udelay_val * (HZ/4));
+ n = 32;
+
+ __delay(n + 1);
+}
+
+void __udelay(unsigned long n)
+{
+ __const_udelay(n * 0x10c7UL);
+}
+
+
+void __ndelay(unsigned long n)
+{
+ __const_udelay(n * 0x5UL);
+}
diff -Nru a/include/asm-sparc64/delay.h b/include/asm-sparc64/delay.h
--- a/include/asm-sparc64/delay.h 2004-08-27 16:48:00 -07:00
+++ b/include/asm-sparc64/delay.h 2004-08-27 16:48:00 -07:00
@@ -1,7 +1,11 @@
-/* $Id: delay.h,v 1.13 2002/02/02 03:33:48 kanoj Exp $
- * delay.h: Linux delay routines on the V9.
+/* delay.h: Linux delay routines on sparc64.
*
- * Copyright (C) 1996 David S. Miller ([EMAIL PROTECTED]).
+ * Copyright (C) 1996, 2004 David S. Miller ([EMAIL PROTECTED]).
+ *
+ * Based heavily upon x86 variant which is:
+ * Copyright (C) 1993 Linus Torvalds
+ *
+ * Delay routines calling functions in arch/sparc64/lib/delay.c
*/
#ifndef __SPARC64_DELAY_H
@@ -13,50 +17,21 @@
#ifndef __ASSEMBLY__
-static __inline__ void __delay(unsigned long loops)
-{
- __asm__ __volatile__(
- b,pt%%xcc, 1f\n
- cmp%0, 0\n
- .align 32\n
-1:\n
- bne,pt %%xcc, 1b\n
Re: [PATCH] SunSAB console problems in 2.6.x
On Fri, 27 Aug 2004 16:24:13 -0700 Joshua Kwan [EMAIL PROTECTED] wrote: David S. Miller wrote: Are all of you guys seeing this problem on uniprocessor? Ralph, Joshua? Yeah. Although I thought you'd already fixed it with that patch? Or was it just a hack? Just a hack. See the email I just sent out, it has the correct fix.
Re: tcp_ecn in kernel-image-2.4.26-sparc64
On Fri, 20 Aug 2004 22:17:37 +0100 Richard Mortimer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~$ grep INET_ECN /boot/config-2.4.26-sparc64 CONFIG_INET_ECN=y Is this intentional? It's arbitrary these days because... Should I log a bug to get INET_ECN disabled in the kernels; should there be an boottime setting to turn off ecn; or is the idea that it is enabled by default? The setting really belongs in /etc/sysctl.conf The INET_ECN config option disappeared entirely from 2.6.x
Re: FTBFS: fftw3
On Thu, 19 Aug 2004 08:55:25 -0400 Ben Collins [EMAIL PROTECTED] wrote: On Thu, Aug 19, 2004 at 12:10:51PM +0200, Paul Brossier wrote: hi all it would great if any of you could investigate why fftw3 fails [1] to build on sparc. following Steve's advice [2,3], we added some configure flags to debian/rules. it seemed to work well, except from sparc: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../kernel -I../rdft -O3 -fomit-frame-pointer -fno-schedule-insns -fstrict-aliasing -mcpu=ultrasparc -pthread -MT reodft11e-r2hc-odd.lo -MD -MP -MF .deps/reodft11e-r2hc-odd.Tpo -c reodft11e-r2hc-odd.c -fPIC -DPIC -o .libs/reodft11e-r2hc-odd.lo That -mcpu=ultrasparc thing is your problem. Building like that means it wont run on sparc32 systems, and that's a bug. Figure out why it is trying to use those flags (especially when the buildd forces a sparc32 like environment, which should keep this from happening). Using -mcpu=ultrasparc is wrong for binaries which need to work on sparc32, that's correct. But the build failure is real, and needs to be fixed independantly. As mentioned in other emails, it's most likely a binutils bug since glibc builds are failing similarly.
Re: FTBFS: fftw3
On Thu, 19 Aug 2004 09:40:56 -0400 Ben Collins [EMAIL PROTECTED] wrote: But the build failure is real, and needs to be fixed independantly. As mentioned in other emails, it's most likely a binutils bug since glibc builds are failing similarly. Is it the sparc32 glibc build, or the v9 optimized one? If the latter, then the bug may be related to the -mcpu=ultrasparc flag. Get the assembler from one of the failed test cases and look for registers = %f32 with odd numbers such as %f33 or %f35. If you can't find that, it is in fact a binutils bug. -mcpu=ultrasparc only means anything because it allows usage of the = %f32 float regs, -mcpu=v9 would do that too and thus also trigger the error.
Re: FTBFS: fftw3
On Thu, 19 Aug 2004 10:57:25 -0400 Ben Collins [EMAIL PROTECTED] wrote: That makes sense then. I'm only suggesting for fftw3 to disable the -mcpu flag because 1) it's correct, and 2) it would get them past the build failure. Fixing the binutils bug is a seperate issue. I completely agree.
Re: Kernel serie 2.6 compilation error on sparc64
On Tue, 10 Aug 2004 11:30:24 -0300 Antonio Luiz Pacifico [EMAIL PROTECTED] wrote: drivers/usb/gadget/net2280.c: In function `net2280_alloc_buffer': drivers/usb/gadget/net2280.c:479: warning: implicit declaration of function `dma_alloc_coherent' The USB gadget layer is not supported currently, simply remove it from your configuration.
Re: Kernel serie 2.6 compilation error on sparc64
On Mon, 09 Aug 2004 19:23:59 -0300 Antonio Luiz Pacifico [EMAIL PROTECTED] wrote: Some days ago I related that kernel source 2.6.7 was with erros during the compilation. David S. Miller answered to try 2.6.8-rc3. I did. But the compilation failled again. How did it fail with 2.6.8-rc3? With arch/sparc64/defconfig it compiles perfectly for me. Please don't say it failed again, show us exactly how. I use current 2.6.x kernels on all of my machines here for kernel development, and they work just fine. Build failures are usually from deviations from arch/sparc64/defconfig or similar, so you have to show the exact failure and (as you happily did) list your configuration as well. Thanks.
Re: Compiling error on sparc64 kernel 2.6.7
On Thu, 05 Aug 2004 18:23:25 -0300 Antonio Luiz Pacifico [EMAIL PROTECTED] wrote: Compling the kernel source version 2.6.7 on sparc64 architecture I reveived the following error message: Try 2.6.8-rc3, this problem should be fixed there.
Re: New procps, may break
On Thu, 29 Jul 2004 23:08:21 +1000 [EMAIL PROTECTED] (Craig Small) wrote: A new procps has been uploaded. I think the 64bit arches will be ok but I'd just like to let you lot know that there might be problems on the sparc or amd64. Complaining won't fix it, but patches that don't break the package in other exciting ways will fix it. I know it works ok for an alpha so the compliing part is fine, but the lib vs lib64 might be a problem. Can you elaborate on the expected potential failure? You do have something specific your worried about, otherwise you wouldn't mention anything :-) Thanks. And I'll try to help out with whatever explodes.
Re: sarge upgrade - root mounts readonly
On Tue, 6 Jul 2004 21:33:09 -0500 Patrick Finnegan [EMAIL PROTECTED] wrote: Hmm. I saw the same problem on an Ultra 5 running 2.6.7 with woody. Does it have to be newer than that? The fix was made on March 24th, 2004. So it should be in there. Your followup to this email indicates that you were actually using 2.4.18 which I know did not have the fix.
Re: Bug#257833: Configuration for sparc64 not found
On Tue, 6 Jul 2004 12:42:43 +0200 Marco d'Itri [EMAIL PROTECTED] wrote: Did the output of uname -m change? The script is expecting it to be sun4u on sparc64 systems. It outputs sparc64 on sparc64 Linux systems. It has never output sun4u, only Solaris systems do that.
Re: Direct rendering: No
On Tue, 6 Jul 2004 22:50:53 +0200 (CEST) Erwann Abalea [EMAIL PROTECTED] wrote: What have I done wrong? What can I do to have hardware 3D acceleration again with my Creator3D FFB1? (except reverting back to stable) In order to add support for the render extension of xfree86 (ie. get nice fonts like everyone else) the DRM support had to be dropped. The creator3d is such a crappy chip, no texturing capabilities at all for example, that it's not the end of the world. :-)
Re: Direct rendering: No
On Tue, 6 Jul 2004 17:29:01 -0400 (EDT) JLB [EMAIL PROTECTED] wrote: Suggest an alternative then. One with 3D acceleration support -and- nice font support. An x86 system with an ATI Radeon :-) For sparc64, no such options exist currently until someone gets the ATI Radeon support working on that platform. If I personally had a SB1500 I'd be working on that myself, but at $3000 USD it's out of my price range for fun toys to play with currently.
Re: Direct rendering: No
On Tue, 6 Jul 2004 17:51:15 -0400 (EDT) JLB [EMAIL PROTECTED] wrote: Also, the only good ATI drivers are closed-source and x86-only. Some of us care about such things. Not true, the xfree86 and x11.org ATI drivers support the 7500 and similar families with full OpenGL acceleration. I know because this is what I used to play quake3 on my Athlon for a long time. Well, we turned off all accelerated 3D support so you can have pretty fonts, without giving you a choice as to which you find a higher priority; if you don't like it, spend 3.5 kilodollars on some fancy-schmantzy Sun hardware AND write your own drivers, or just switch to x86. You are going to complain about free development? Where are your coding contributions to the xfree86 support of the creator3d driver? Frankly, I'd rather have accelerated 3D than pretty fonts. It sounds like it would be worth your while to work on the creator3d xfree86 driver to get the DRM support operational again. It would be an excellent and welcomed contribution on your part. I look forward to seeing your work.
Re: Direct rendering: No
On Tue, 6 Jul 2004 18:13:34 -0400 Mike Edwards [EMAIL PROTECTED] wrote: Seriously, though - don't simply disable somthing that people are using - give the user a choice as to what behavior s?he wants. It was simply not possible given the current way the XAA layer is architected. It's incompatible with how the creator3d DRM stuff needs to work. I discussed this with Ben Collins at the time I did the work, and having the creator3d driver support render properly and making the driver easier to maintain (by making it use the XAA layer) was more important than the lousy 3d support. Frankly, if any texturing is done, the software rendering is in fact faster than when the DRM stuff on creator3d was working. The only thing faster with the creator3d opengl support was purely non-textured rendering, which is nice for pretty screensavers but that's about it. Like I said in my other email, I welcome contributions from people to get the 3d stuff working again.
Re: [Rapidly drifting OT] Re: Direct rendering: No
On Tue, 6 Jul 2004 18:43:05 -0400 (EDT) JLB [EMAIL PROTECTED] wrote: It sounds like it would be worth your while to work on the creator3d xfree86 driver to get the DRM support operational again. It would be an excellent and welcomed contribution on your part. I look forward to seeing your work. I'm a sysadmin, not a driver hacker. Evidently, my opinion is worth less (or worthless?) because I haven't the foggiest clue how to write or alter a video driver? Then stick with Sarge. You have that option too, you know. What magnificant enterprise wide mission critical application do you need opengl acceleration for? Your screensaver? I definitely feel (as does Ben Collins the sparc port maintainer) that correct font rendering is more important than things like that.
Re: sarge upgrade - root mounts readonly
On Tue, 6 Jul 2004 21:33:21 -0400 (EDT) Andy Tolonen [EMAIL PROTECTED] wrote: I have been running woody (kernel 2.4.24) happily for 6 months on my ultra 10. this week, i decided to upgrade to testing by changing my sources.list and running apt-get dist-upgrade. everything appeared to work fine. a few days later, i rebooted and only the root fs mounted read-only. i didnt modify /etc/fstab or anything. so why might this happen? It's a bug in the kernel that one of the startup scripts is exposing. Upgrade to a more recent kernel and it will fix itself. It was a bug in sys_mount() syscall translations for 32-bit binaries running on 64-bit kernel.
