Re: Attempts to set date with 'date -s' hang the machine
From: Frans Pop <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 14:07:24 +0100 > I've tested this patch on my Ultra10 and it works. The date is now set > correctly without hanging. > > Thanks David. Thanks for testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: tg3 driver fails
From: Hendrik Sattler <[EMAIL PROTECTED]> Date: Wed, 6 Jul 2005 22:22:06 +0200 > Does initrd or the like work with network boot? How does the card > actually do network boot when not being able to operate without > firmware (chicken-egg problem)? If the network card cannot handle > network boot: why would you want such a crap? The openfirmware forth code on the card is executed by the system boot firmware. > It's good for ISDN cards as there are many modes to operate in but for an > ethernet card? It's been happening for a long time. Way back in the Acenic days, the firmware is used to work around a bug in the DMA unit of the card. This is not uncommon. Many current generation cards also do TCP Segmentation Offload in firmware as well. Although gradually most of this stuff is being done in the chip itself, but bugs are harder to fix as a result. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: v210 installation
From: Dave Love <[EMAIL PROTECTED]> Date: Wed, 06 Jul 2005 18:02:40 +0100 > It looks about time to give up on this. There are some PCI controller fixes I've made for UltraSPARC-IIIi systems recently in the 2.6.x tree, but since Debian can't even get one-liner device ID changes into the releases in less than 2 months time, I've stopped submitting fixes like that here. I also don't have V210/V240 systems at my disposal, so things are very hard to test, and these two system types seem to be the most problematic UltraSPARC-IIIi platforms to support :-/ -- 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: tg3 driver fails
From: Jurij Smakov <[EMAIL PROTECTED]> Date: Wed, 6 Jul 2005 11:09:55 -0400 (EDT) > Yes, this is a known problem. The firmware has been removed from the > driver due to unclear licensing information and failure to comply with > DFSG (Debian Free Software Guidelines). I would like to personally thank the Debian project for making life miserable for it's users and making many platforms totally uninstallable and unusable due to this decision. I am sure every user who can't use Debian on his system out of the box because of this firmware problem will not mind because the high moral standards of the Debian project are much more important than a properly working system. -- 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
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: 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: __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: Floppy boot - Sun AXi - Fast Data Access MMU Miss
On Wed, 01 Jun 2005 14:16:17 -0500 Nicolas Will <[EMAIL PROTECTED]> wrote: > Is there a fix somewhere (OpenBoot upgrade?), or should I go straight to > netboot? I would seriously suggest using a netboot. The floppy boot doesn't work on nearly all UltraSPARC systems. -- 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 09:43:50 -0400 Tad Bilby <[EMAIL PROTECTED]> wrote: > We are a Sun OEM that put the 2500 mainboard into rack chassis- ... > We would like to help but I am not sure about loaning hardware.. It is an interesting support model where the kernel engineers don't have the hardware, and then people expect the thing to work and for it to also be regression tested against future changes over time. Because of how rediculious that expectation is, I don't lose any sleep at night when I discover that machines I don't have in my personal possesion aren't supported properly. Sun or the OEM's have to pony up with loaner systems if they really expect this stuff to work. -- 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: 64 bit versions of strace and gdb
From: Ben Collins <[EMAIL PROTECTED]> Date: Mon, 23 May 2005 09:13:16 -0400 > I had assumed it would be included with the main package. Let me check. > > Ok, strace includes strace64 binary. Not sure what the deal is with gdb. > I'll check with the maintainer to see what happened to that patch. Thanks a lot Ben. -- 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: "Jim Crilly" <[EMAIL PROTECTED]> Date: Tue, 24 May 2005 14:42:27 -0400 > True, but building kernels on sparc64 wasn't terribly fun for me the last > time I tried it either so I decided it wasn't worth it and just stuck with > the Debian kernel images. Amusing as I do all of the sparc64 kernel development under Debian/Sparc on all of my machines. It builds out of the box, both 2.4.x and 2.6.x. -- 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: 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: Bug #251149: gcc wrapper for sparc is chronically broken
From: Thiemo Seufer <[EMAIL PROTECTED]> Date: Sun, 22 May 2005 01:37:50 +0200 > David S. Miller wrote: > [snip] > > This is not a bug, it should be closed. On sparc64, gcc should emit > > 64-bit code by default. If you want 32-bit code emitted on a sparc64 > > system you have exactly two options 1) add -m32 to the command line > > or 2) run your build in a "sparc32 bash" environment. > > JFTR, there's a more general tool in debian called linux32. I think that's great. Having "ppc32", "sparc32" et al. is not very wise. -- 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
On Sat, 21 May 2005 14:06:52 +0200 Falk Hueffner <[EMAIL PROTECTED]> wrote: > this bug has been open for quite some time as "important". Can some > sparc people please comment on it? This is not a bug, it should be closed. On sparc64, gcc should emit 64-bit code by default. If you want 32-bit code emitted on a sparc64 system you have exactly two options 1) add -m32 to the command line or 2) run your build in a "sparc32 bash" environment. What the compiler outputs by default is merely one aspect of this problem, the gcc wrapper is doing the right thing. You can easily set this up on the Debian build system sparc machines by having the shell environment startup through "sparc32" when a certain hostname is used. For example, foo-32 as the hostname would cause this to happen. So use that hostname to build "sparc" 32-bit packages, and use a non-environment-changing hostname in order to build 64-bit sparc packages. This idea is about about 8 years old. :-) This is needed _ANYWAYS_ to get the uname output to be correct for 32-bit sparc builds. It prints out "sparc64" otherwise, and that makes configure and other auto tools do the wrong thing. Consider this. When you build or bootstrap gcc, if "uname" outputs "sparc64" you will not get a successful gcc bootstrap unless the compiler outputs 64-bit code by default, requiring that "CC" gets changed to add "-m64" to the command line is more than madness. The gcc bootstrap is the litmus test of correct default code type generation behavior. 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: 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: __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: 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]
Re: sunpci under linux ??
On Fri, 13 May 2005 15:17:26 -0700 (PDT) <[EMAIL PROTECTED]> wrote: > Now this does bring up another issue, to wit: what could he do if he > did not know that some code was created through the study of Sun code? Many years ago Sun told me they might be willing to write a proprietary binary-only Linux driver for the sunpci card, but were totally unwilling to release the specs for the chip so that a free driver could be done. So, it's pretty clear they want to keep the technology secret, so any sunpci driver I'd tend to keep out of the tree. For other instances, when people submit code they provide a "Signed-off-by:" line, which means that they are stating that the code is in the clear as far as they know. Which means that the onus is on them to make sure that the patch they are submitting is OK. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sunpci under linux ??
On Wed, 11 May 2005 22:53:32 +0200 Admar Schoonen <[EMAIL PROTECTED]> wrote: > Currently, the cards only work in Solaris (afaict). However, Solaris > will be open sourced within a few months, so perhaps some specs of the > card will become available. Now if only I had a little more spare time > and was a lot more competent in programming... I will not accept any code into the Linux kernel that was written based upon the studying of the Solaris open source tree. The legal ramifications of doing this are unclear, at best. I just wanted to say that before anyone gets the idea to do so. -- 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: __alloc_pages: 2-order allocation failed
On Fri, 29 Apr 2005 10:47:54 -0400 Mike Edwards <[EMAIL PROTECTED]> wrote: > Apr 29 08:45:34 psychology kernel: __alloc_pages: 2-order allocation failed > (gfp=0x20/0) > Apr 29 08:45:34 psychology kernel: __alloc_pages: task(spamc) pid(25917) > caller(0046edc0) > Apr 29 08:45:34 psychology kernel: DEBUG: __get_free_pages() order 2 failed > called by 0046aaa8 ... > 0046a9c0 t kmem_cache_grow > 0046ad00 T kmem_cache_alloc_batch Does spamc use AF_UNIX sockets to communicate with other processes? If so, someone should audit it to make sure it checks properly for return values on write() calls. If spamc uses non-blocking AF_UNIX sockets, -ENOBUFS can happen under normal circumstances. If the sockets were blocking then the kernel could sleep to swap out some pages to free up some space and then the call could succeed. A quick perusal of the spamc sources seems to indicate that it does use non-blocking AF_UNIX sockets as the transport to talk to the spamassasindaemon. I'm on vacation so cannot investigate this more deeply. -- 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
On Tue, 26 Apr 2005 23:01:57 -0700 (PDT)
<[EMAIL PROTECTED]> wrote:
> The dmesg outputs motivating my original (misinterpreted and/or poorly
> phrased) IDE controller rant:
> hdc: dma_timer_expiry: dma status == 0x60
> hdc: DMA timeout retry
> hdc: timeout waiting for DMA
> hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> hdc: drive not ready for command
What kernel version gives you this?
--
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
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 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: fast data access mmu miss after harddisk upgrade
On Sat, 23 Apr 2005 23:11:25 -0700 (PDT) <[EMAIL PROTECTED]> wrote: > --- Jurij Smakov <[EMAIL PROTECTED]> wrote: > > This is a pretty old heisenbug, which cannot be reproduced reliably > > (except on SunFire 280R). It has been reported numerous times before, > > both > > on this list and in BTS. See bugs #267428, #299043, #301503 and > > probably > > others. > > Can anybody tell me what this error message means on a technical > hardware level? I am not comprehending it and googling it did not lead > me to anything either. It means that the kernel either: 1) dereferenced a bad pointer, such as a NULL or something 2) or it didn't remap the kernel properly into the TLBs right before taking over the trap table from the firwmare Sometimes adding "-p" to the kernel boot command line can get you come debugging messages, but not always. It is a low level crash, and usually the most useful piece of information you can provide the developers is the output of ".registers" from the OBP "ok" prompt when this kind of crash happens. The PC value dumped in particular will say where in SILO or the kernel that the crash occurs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Open kernel-image-2.6.8 bugs on sparc - help needed
On Sat, 23 Apr 2005 14:16:34 -0400 (EDT) Jurij Smakov <[EMAIL PROTECTED]> wrote: > * #275037: writing to a parallel port causes kernel oops. >I was able to reproduce it, however it only happens if parport_pc module >is loaded. It appears that there are two modules - parport and >parport_pc. parport_pc seems to be appropriate for the "PC-style" >parallel port chips and I have no idea whether it should work for >sparc as well. With just parport module loaded oops is not happening. >Please comment if you have a setup with working printing via parallel >port. parport_pc is the driver that should be used for the on-board parallel port devices on PCI UltraSPARC systems. This driver should work in 2.4.x, and either way the OOPS is unacceptable. > * #286267: loading snd-sun-cs4231 module fails to create /dev/dsp via udev >As a first step I tried making sound work :-) (it appears to work fine >for the submitter). With a 2.6.8-2 kernel on Ultra5 with cs4231 card I >get the sound using snd-sun-cs4231 module, but it is choppy and >corrupted (tried using 'play' from sox package to play wavs and mpg321 >to play mp3s). Ironically, alsaplayer fails miserably. I have also tried >using the latest ALSA development release (1.0.9rc2) from [0], with >identical results. Hence the question, how does one get working sound, >if it is possible at all? Comments on the original bug are welcome too, >there is a seemingly relevant thread on debian-user [1], but no solution >has been posted there. The DMA handling in this driver needs some serious fixing. I wasted a week or so converting the old 2.4.x driver into an ALSA driver and that was enough for me :-) > * #305691: cg6 framebuffer seems to be screwed with 2.6.8 kernel. On >Ultra1 with cg6 the colors are wrong on console (yellow instead of >white in debconf screens for example). Starting X just brings up >a blank screen and hangs, no visible errors in the log. I remember >that some fixes for cg6 were mentioned on sparclinux mailing list a >while ago, but they seems to be relevant for sparc32. Is anyone >successfully running X with 2.6.8 and cg6? A working XF86Config-4 >file for that setup would be greatly appreciated. With 2.6.10 it just >blanks the screen immediately after boot even though booting proceeds >normally. Yes, all the necessary kernel level fixes should be in the current 2.6.x kernel sources, just diff your 2.6.8 drivers/video/cg6.c with the current driver. The color maps weren't setup correctly and all sorts of other problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weird Mouse Behaviour with 2.6
Ok, let's kill this bug already :-)
We were neglecting to invoke sunsu_change_speed() when first
setting up the keyboard and mouse ports. That's why things
were not working.
This should fix it and I'll push this upsteam.
[SPARC64]: In sunsu driver, make sure to fully init chip for kbd/ms
We were forgetting to call sunsu_change_speed(). The reason
that replugging in the mouse cable "fixes things" is that
causes a BREAK interrupt which in turn caused a call to
sunsu_change_speed() which would get the chip setup properly.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
--- a/drivers/serial/sunsu.c2005-04-20 10:17:40.0 -0700
+++ b/drivers/serial/sunsu.c2005-04-21 22:01:41.0 -0700
@@ -1285,6 +1285,7 @@
static int __init sunsu_kbd_ms_init(struct uart_sunsu_port *up, int channel)
{
+ int quot, baud;
#ifdef CONFIG_SERIO
struct serio *serio;
#endif
@@ -1293,10 +1294,14 @@
up->port.type = PORT_UNKNOWN;
up->port.uartclk = (SU_BASE_BAUD * 16);
- if (up->su_type == SU_PORT_KBD)
+ if (up->su_type == SU_PORT_KBD) {
up->cflag = B1200 | CS8 | CLOCAL | CREAD;
- else
+ baud = 1200;
+ } else {
up->cflag = B4800 | CS8 | CLOCAL | CREAD;
+ baud = 4800;
+ }
+ quot = up->port.uartclk / (16 * baud);
sunsu_autoconfig(up);
if (up->port.type == PORT_UNKNOWN)
@@ -1337,6 +1342,8 @@
}
#endif
+ sunsu_change_speed(&up->port, up->cflag, 0, quot);
+
sunsu_startup(&up->port);
return 0;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lots of kernel problems with U30
On Thu, 21 Apr 2005 20:33:26 -0400 (EDT) Jurij Smakov <[EMAIL PROTECTED]> wrote: > Probably I wasn't completely correct. You do not have to select the i386 > layout, you just do not need to do anything in userspace to setup the > console keymap. As I understand, somewhere between the 2.4 and 2.6 the > keymap setting was moved from userspace to kernel space, so that kernel > detects the keyboard type and sets the correct keymap itself. 2.4.x kernel keyboard device outputs Sun keyboard codes, 2.6.x kernel keyboard device outputs i386 keyboard codes. This is why using Sun keyboard maps in userspace with a 2.6.x kernel gives bogus results. -- 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 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: rtc and chrony on Ultra 1 and Ultra 5
On Wed, 20 Apr 2005 10:18:50 -0700 Eric Brower <[EMAIL PROTECTED]> wrote: > Depending upon what Chrony expects, perhaps no-ops would make them > work, but I suspect chrony ought to get a bit smarter to support such > devices. I haven't looked at the code, but I assume the interrupts > are disabled while warping time. The switch_interrupts() function in chrony basically tries RTC_UIE_ON and RTC_UIE_OFF and barfs a log message regardless of the error return. Any error makes it output a log message. And as Eric stated, these chips lack any interrupt facilities at all, so we the generic RTC driver would do the same thing. In any event, I'll change my Mostek RTC driver changes such that it returns the same error codes driver/char/rtc.c does for these cases. -- 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 20 Apr 2005 18:36:15 +0200 Sebastian Niehaus <[EMAIL PROTECTED]> wrote: > Well, I will try somewtimes (as soon as I have faster internet > access). Did you submit this patch to be included in the "official" > kernel? Not yet, need to get chrony actually working first. :-) -- 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: 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: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 14:32:44 -0700
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> chrony needs to be hacked to try and use RTC_GET/RTC_SET on sparc.
Or we can do something like this, provide the PC rtc ioctls
in the Mostek RTC driver.
Frans, perhaps you can give this a spin instead?
drivers/sbus/char/rtc.c: 136d088ef324eb5843dfe9fdf9351b89fc3aae73
--- drivers/sbus/char/rtc.c
+++ drivers/sbus/char/rtc.c 2005-04-19 14:46:18.0 -0700
@@ -28,6 +28,24 @@
static int rtc_busy = 0;
+/* This is the structure layout used by drivers/char/rtc.c, we
+ * support that drivers ioctls so that things are less in
+ * userspace.
+ */
+struct rtc_time_generic {
+ int tm_sec;
+ int tm_min;
+ int tm_hour;
+ int tm_mday;
+ int tm_mon;
+ int tm_year;
+ int tm_wday;
+ int tm_yday;
+ int tm_isdst;
+};
+#define RTC_RD_TIME_IOR('p', 0x09, struct rtc_time_generic) /* Read RTC
time */
+#define RTC_SET_TIME _IOW('p', 0x0a, struct rtc_time_generic) /* Set RTC
time*/
+
/* Retrieve the current date and time from the real time clock. */
static void get_rtc_time(struct rtc_time *t)
{
@@ -82,29 +100,72 @@
spin_unlock_irq(&mostek_lock);
}
+static int put_rtc_time_generic(void __user *argp, struct rtc_time *tm)
+{
+ struct rtc_time_generic __user *utm = argp;
+
+ if (__put_user(tm->sec, &utm->tm_sec) ||
+ __put_user(tm->min, &utm->tm_min) ||
+ __put_user(tm->hour, &utm->tm_hour) ||
+ __put_user(tm->dom, &utm->tm_mday) ||
+ __put_user(tm->month, &utm->tm_mon) ||
+ __put_user(tm->year, &utm->tm_year) ||
+ __put_user(tm->dow, &utm->tm_wday) ||
+ __put_user(0, &utm->tm_yday) ||
+ __put_user(0, &utm->tm_isdst))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int get_rtc_time_generic(struct rtc_time *tm, void __user *argp)
+{
+ struct rtc_time_generic __user *utm = argp;
+
+ if (__get_user(tm->sec, &utm->tm_sec) ||
+ __get_user(tm->min, &utm->tm_min) ||
+ __get_user(tm->hour, &utm->tm_hour) ||
+ __get_user(tm->dom, &utm->tm_mday) ||
+ __get_user(tm->month, &utm->tm_mon) ||
+ __get_user(tm->year, &utm->tm_year) ||
+ __get_user(tm->dow, &utm->tm_wday))
+ return -EFAULT;
+
+ return 0;
+}
+
static int rtc_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
unsigned long arg)
{
struct rtc_time rtc_tm;
void __user *argp = (void __user *)arg;
- switch (cmd)
- {
+ switch (cmd) {
case RTCGET:
+ case RTC_RD_TIME:
memset(&rtc_tm, 0, sizeof(struct rtc_time));
get_rtc_time(&rtc_tm);
- if (copy_to_user(argp, &rtc_tm, sizeof(struct rtc_time)))
+ if (cmd == RTCGET) {
+ if (copy_to_user(argp, &rtc_tm,
+sizeof(struct rtc_time)))
+ return -EFAULT;
+ } else if (put_rtc_time_generic(argp, &rtc_tm))
return -EFAULT;
return 0;
case RTCSET:
+ case RTC_SET_TIME:
if (!capable(CAP_SYS_TIME))
return -EPERM;
- if (copy_from_user(&rtc_tm, argp, sizeof(struct rtc_time)))
+ if (cmd == RTCSET) {
+ if (copy_from_user(&rtc_tm, argp,
+ sizeof(struct rtc_time)))
+ return -EFAULT;
+ } else if (get_rtc_time_generic(&rtc_tm, argp))
return -EFAULT;
set_rtc_time(&rtc_tm);
@@ -164,6 +225,7 @@
printk(KERN_ERR "rtc: unable to get misc minor for Mostek\n");
return error;
}
+ printk("rtc_sun_init: Registered Mostek RTC driver.\n");
return 0;
}
--
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 23:34:06 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > Thanks a lot David. The RTC error was something that had been nagging me > for some time. Please see my other email, my patch is incredibly wrong. chrony needs to be hacked to try and use RTC_GET/RTC_SET on sparc. -- 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 > > 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: inode issue with openpromfs [was Re: rtc and chrony on Ultra 1 and Ultra 5]
On Tue, 19 Apr 2005 17:02:29 -0400 Mike Edwards <[EMAIL PROTECTED]> wrote: > That reminds me... Yes, I've seen this before too. Openpromfs is due for a cleanup anyways, I'll try to get to fixing this at some point. -- 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:16:28 +0200 Sebastian Niehaus <[EMAIL PROTECTED]> wrote: > Sorry for behaving like a complete moron :-( bash$ dpkg -S /usr/sbin/prtconf sparc-utils: /usr/sbin/prtconf bash$ So you need to: bash# apt-get install sparc-utils I'm surprised that package isn't in base at this point. -- 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 > > 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? Not functionally, your machine should work fine. But it is a bug that wants fixing. drivers/sbus/char/rtc.c, function rtc_sun_init() should find a better test of whether drivers/char/rtc.c has probed a PCI rtc chip or not. I'll try to come up with something. -- 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:48:03 -0400 Mike Edwards <[EMAIL PROTECTED]> wrote: > Ahhh, resolved that problem. PEBKAC. > > Kernel command line: root=/dev/sdh2 ro maxcpus=1 > > I'll go take a flying leap off the nearest cliff, now. Don't :-) Lots of people set CONFIG_NR_CPUS too low as well, as I described in my other reply. -- 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:40:27 -0400
Mike Edwards <[EMAIL PROTECTED]> wrote:
> Erk. Can you give me a patch for that, or, at the very least, tell me
> what to modify? My C is rusty.
Make mm/page_alloc.c:__get_free_pages() do something like this:
page = alloc_pages(gfp_mask, order);
if (!page) {
if (order > 0)
printk("DEBUG: __get_free_pages() order %d failed "
"called by %p\n",
order, __builtin_return_address(0));
return 0;
}
> As it is, I'm going to have to reboot this box in any case. Can you
> think of a reason why an SMP kernel on a dual processor E450 only
> started one processor at boot time? (Yes, openprom sees both
> processors, and the old kernel had no problem with them, either).
Make sure CONFIG_NR_CPUS is set large enough.
It must be at least as large as the largest "physical cpu number"
of all the cpus in your machine. The physical numbering is not
necessarily linear, it can be "0 2 4 6" or similar for a 4-cpu
machine, 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 Tue, 19 Apr 2005 21:28:21 +0200
Frans Pop <[EMAIL PROTECTED]> wrote:
> On Tuesday 19 April 2005 20:47, David S. Miller wrote:
> > Can someone provide "/usr/sbin/prtconv -pv" on either the Ultra5 or
> > Ultra10 system which fails like this? It may provide the clue.
> Attached.
Why did the rename the device node to "eeprom"? :-/
Node 0xf0066414
address: fffba000
reg: 0014..2000
model: 'mk48t59'
name: 'eeprom'
That's your clock chip.
Give this patch a try (should apply cleanly to just about any 2.6.x)
drivers/char/rtc.c: 0af5fb0c19e378bc3c660c70873cdf22d806f9b8
--- drivers/char/rtc.c
+++ drivers/char/rtc.c 2005-04-19 12:29:00.0 -0700
@@ -889,6 +889,28 @@
static irqreturn_t (*rtc_int_handler_ptr)(int irq, void *dev_id, struct
pt_regs *regs);
#endif
+#ifdef __sparc__
+static int is_rtc_device(char *name, int prom_node)
+{
+ unsigned char model[32];
+
+ if (!strcmp(name, "rtc"))
+ return 1;
+
+ prom_getstring(prom_node, "model", model, sizeof(model));
+ if (!strcmp(model, "mk48t02") ||
+ !strcmp(model, "mk48t08") ||
+ !strcmp(model, "mk48t59") ||
+ !strcmp(model, "m5819") ||
+ !strcmp(model, "m5819p") ||
+ !strcmp(model, "m5823") ||
+ !strcmp(model, "ds1287"))
+ return 1;
+
+ return 0;
+}
+#endif
+
static int __init rtc_init(void)
{
struct proc_dir_entry *ent;
@@ -909,7 +931,8 @@
#ifdef __sparc__
for_each_ebus(ebus) {
for_each_ebusdev(edev, ebus) {
- if(strcmp(edev->prom_name, "rtc") == 0) {
+ if (is_rtc_device(edev->prom_name,
+ edev->prom_node)) {
rtc_port = edev->resource[0].start;
rtc_irq = edev->irqs[0];
goto found;
@@ -919,7 +942,8 @@
#ifdef __sparc_v9__
for_each_isa(isa_br) {
for_each_isadev(isa_dev, isa_br) {
- if (strcmp(isa_dev->prom_name, "rtc") == 0) {
+ if (is_rtc_device(isa_dev->prom_name,
+ isa_dev->prom_node)) {
rtc_port = isa_dev->resource.start;
rtc_irq = isa_dev->irq;
goto found;
--
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 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: 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: __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: 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: 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: 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: Serial console on Ultra10 - no login-prompt
On Tue, 12 Apr 2005 14:35:57 +0200 Olle Görling <[EMAIL PROTECTED]> wrote: > As far as I can tell, CONFIG_SERIAL_CONSOLE shouldn't be in sparc64. > There are no references to it in the sparc64-tree. He meant CONFIG_SERIAL_CORE_CONSOLE. You also need CONFIG_SERIAL_$(DRIVER_NAME)_CONSOLE set as well. For example, CONFIG_SERIAL_SUNZILOG_CONSOLE for sunzilog driver.
Re: Weird Mouse Behaviour with 2.6
On Mon, 4 Apr 2005 13:22:37 -0700 Eric Brower <[EMAIL PROTECTED]> wrote: > It seems to me that serial_core.c::uart_wait_until_sent() should > assert if port->timeout is 0 I definitely agree it should BUG() on this. We would have caught this problem a long time ago if it did. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weird Mouse Behaviour with 2.6
On Mon, 4 Apr 2005 11:11:01 -0700
Eric Brower <[EMAIL PROTECTED]> wrote:
> In tty_ioctl.c tty_wait_until_sent() if the timeout variable is set to
> zero (which many callers do explicitly) it gets reassigned to
> MAX_SCHEDULE_TIMEOUT (this is LONG_MAX). If there are no characters
> waiting to be sent (!tty->driver->chars_in_buffer(tty)) we drop out of
> our loop and supply the timeout variable to uart_wait_until_sent
> (tty->driver->wait_until_sent). The problem is uart_wait_until_sent
> is specified with a timeout argument of type int, not long. This
> becomes -1 in uart_wait_until_sent, which I don't think is intended.
> If your port->timeout value in this function is also zero (as seems
> the case with sunsab), this seems doubly bad and leads to massive
> mdelay times in uart_wait_until_sent. This will appear to you as a
> hung getty.
Good catch. That third argument should be "unsigned long timeout"
indeed. I've pointed this out in private email to Russell, Linus
and Andrew.
uart_update_timeout() calls done by the driver (in this case sunsab.c)
should be updating the port->timeout value properly. Indeed, sunsab.c
fails to call uart_update_timeout() at all.
Hmmm, I wonder if the port->uartclk we use in sunsab.c needs to be
multiplied by 16, like sunsu.c does.
Anyways, this patch below should be a step in the right direction.
= drivers/serial/sunsab.c 1.38 vs edited =
--- 1.38/drivers/serial/sunsab.c2004-12-08 21:31:16 -08:00
+++ edited/drivers/serial/sunsab.c 2005-04-04 12:17:25 -07:00
@@ -682,7 +682,8 @@
/* Internal routine, port->lock is held and local interrupts are disabled. */
static void sunsab_convert_to_sab(struct uart_sunsab_port *up, unsigned int
cflag,
- unsigned int iflag, int baud)
+ unsigned int iflag, unsigned int baud,
+ unsigned int quot)
{
unsigned int ebrg;
unsigned char dafo;
@@ -766,6 +767,9 @@
up->port.ignore_status_mask |= (SAB82532_ISR0_RPF |
SAB82532_ISR0_TCD);
+ uart_update_timeout(&up->port, cflag,
+ (up->port.uartclk / (16 * quot)));
+
/* Now bang the new settings into the chip. */
sunsab_cec_wait(up);
sunsab_tec_wait(up);
@@ -784,10 +788,11 @@
{
struct uart_sunsab_port *up = (struct uart_sunsab_port *) port;
unsigned long flags;
- int baud = uart_get_baud_rate(port, termios, old, 0, 400);
+ unsigned int baud = uart_get_baud_rate(port, termios, old, 0, 400);
+ unsigned int quot = uart_get_divisor(port, baud);
spin_lock_irqsave(&up->port.lock, flags);
- sunsab_convert_to_sab(up, termios->c_cflag, termios->c_iflag, baud);
+ sunsab_convert_to_sab(up, termios->c_cflag, termios->c_iflag, baud,
quot);
spin_unlock_irqrestore(&up->port.lock, flags);
}
@@ -880,7 +885,7 @@
{
struct uart_sunsab_port *up = &sunsab_ports[con->index];
unsigned long flags;
- int baud;
+ unsigned int baud, quot;
printk("Console: ttyS%d (SAB82532)\n",
(sunsab_reg.minor - 64) + con->index);
@@ -926,7 +931,8 @@
SAB82532_IMR1_XPR;
writeb(up->interrupt_mask1, &up->regs->w.imr1);
- sunsab_convert_to_sab(up, con->cflag, 0, baud);
+ quot = uart_get_divisor(&up->port, baud);
+ sunsab_convert_to_sab(up, con->cflag, 0, baud, quot);
sunsab_set_mctrl(&up->port, TIOCM_DTR | TIOCM_RTS);
spin_unlock_irqrestore(&up->port.lock, flags);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: install on Sun Blade 100
On Fri, 1 Apr 2005 18:11:19 -0500 Anthony Townsend <[EMAIL PROTECTED]> wrote: > is Debian SPARC reliable as a production system or are there a pile of > issues? > > just looking to run a basic Internet server - httpd and sshd It should run just fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: __alloc_pages: 2-order allocation failed
On Thu, 31 Mar 2005 14:42:45 -0500 Mike Edwards <[EMAIL PROTECTED]> wrote: > I can try the patch if you still feel it'll help - but it does look > like SA was at fault in this particular case. Just knowing it is SA is insufficient information, we need to know what inside of the kernel, as part of whatever SA is doing, asks for such a large allocation. Please apply the patch and obtain the debugging information, as I have asked you to. -- 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: Help with hardware choices
On Wed, 30 Mar 2005 18:20:25 -0500 Brandon Mercer <[EMAIL PROTECTED]> wrote: > I do not know what you're talking about. Sparcs use considerably less > power, run cooler, last longer, are more stable and are comparable with > speed. You've got to be kidding me. Maybe for ancient pre-UltraSPARC boxes, but my dual-750Mhz SunBlade1000 alone I can hear humming in the very next room and I don't need any heat in that room because of that machine. Similarly for my Ultra60. > Don't confuse clock cycles with speed either. I'm not at all. I've been maintaining and working on the sparc Linux ports for at least 10 years. I rewrote the GCC compiler backend for Sparc from scratch. I wrote all of the instruction scheduling descriptions in the SPARC backend of GCC. I'm the only person who has bothered trying to write assembler optimized code for UltraSPARC in libmpeg and MESA. It might be possible that I kind of know what I'm talking about when I say that SPARCs simply aren't a good bang for the buck these days. I know the hardware inside and out, so given that do you think I'm qualified to make those statements? > I've got an old sparcstation 20 with a 60Mhz proc, that performs just as > well as my Pentium200 for network routing. Yes, hardware from back in the mid-80's, the glory days of Sun hardware when it actually was comparable to the x86 offerings of the same time frame. Some things have changed in the last 15 years :-) I have a strong vested interest in SPARC doing well, yet I can sit here and say SPARC really has lost the cpu wars. I wish other Sun/SPARC lovers could be similarly realistic. -- 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 17:58:58 -0500 Mike Edwards <[EMAIL PROTECTED]> wrote: > This doesn't sound useful for servers. :) Is this an issue with Linux > in general, or only with certain ports? When I said "The kernel" I did mean Linux in general not for a specific port such as Sparc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help with hardware choices
On Wed, 30 Mar 2005 15:51:29 -0600 Kent West <[EMAIL PROTECTED]> wrote: > Dale Scheetz wrote: (snippage throughout) > > >I have been tasked with picking the hardware, and my feeling is that > >SPARC offers the best bang for the buck. > > Let me preface this by saying I have no idea what I'm talking about, but > if it were me, I'd at least take a look at the Mac-mini (this site is > doing web hosting on Minis - > http://www.xrackhosting.com/machine.php?pid=dedicated_hosting) and/or > the Xserve if you need that much horsepower. One thing is for sure, SPARC is definitely not the best bang for the buck. Case in point, I just dropped $2600.00USD on a new SunBlade1500 with 1.5GHZ cpus and 1GB of ram. I know that for around $700.00USD in parts you can put together your own Opteron system which is twice as powerful. The SunBlade sucks twice as much power and is twice as loud as the Opteron as well. The SPARC machines only makes sense for people deeply interested in Sparc already, such as myself. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: __alloc_pages: 2-order allocation failed
On Tue, 29 Mar 2005 13:43:10 -0500 Mike Edwards <[EMAIL PROTECTED]> wrote: > The odd thing is, psychology shouldn't be running out of memory - this > beast has 4 GB. It's not running out of memory so much as memory is too fragmented to produce a 2-order allocation successfully. The kernel uses the buddy-system algorithm to allocate free pages, this means when a 2-order allocation is requested the kernel has to find 4 consequetive and aligned pages in the free page pool. Sometimes after lots of uptime, this is difficult if not impossible to achieve. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some things are broken in 2.6.11 kernel
On Sun, 27 Mar 2005 22:59:44 +0200 Erwann ABALEA <[EMAIL PROTECTED]> wrote: > I wanted to compile an 'official' 2.6.11 linux kernel (taken from > www.kernel.org) for a sparc64 machine, and it failed on 2 points: > * when configuring for SMP + preemptible kernel, spinlock_t and >rwlock_t lack a new member, break_lock. This member is present in >the sparc port, but not the sparc64. When adding it, the >compilation process tells me somewhere: Don't enable PREEMPT anyways, it's still very unreliable. I rarely run it and I'm the only one maintaining the sparc64 kernel :-) > kernel/spinlock.c: In function `_read_lock': > kernel/spinlock.c:250: warning: implicit declaration of function > `read_can_lock' > kernel/spinlock.c: In function `_write_lock': > kernel/spinlock.c:251: warning: implicit declaration of function > `write_can_lock' I'll try to get to this when I have time. > * compilation of the ffb driver fails. A macro named DRM has >apparently been removed, but some code still uses it (ffb_context.c >at least). It's going to likely stay broken, as the current sunffb XFree86 driver doesn't even support DRM any longer, and support is unlikely to ever be added back. -- 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:51:52 +0100 Dieter Jurzitza <[EMAIL PROTECTED]> wrote: > Without afbinit things get *very* slow, That's correct, because without afbinit the chip's acceleration cannot be used, thus we drop down to pure unaccelerated software graphics rendering to the frame buffer. This is what should happen. -- 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: Testers wanted for kernel/discover1
On Wed, 23 Mar 2005 23:51:12 -0500 (EST) Jurij Smakov <[EMAIL PROTECTED]> wrote: > * Modular IDE in kernel 2.4.27. That change potentially may affect all > sparc machines with IDE controllers, so it would be nice if as many people > as possible would give it a spin and confirm that nothing breaks. For > information see my last message to the bug 298927 [0]. Thanks to Clint > Adams who has already confirmed that it fixes his SB100. That's great that you were able to make this work. What was the exact kernel config change you made to achieve this? I ask because I hate letting things like this go and just say "great it works now", I'd like to sit down and try and figure out what the actual cause was. Thanks Jurij. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weird Mouse Behaviour with 2.6
On Sun, 20 Mar 2005 11:59:20 +0100 Detlef <[EMAIL PROTECTED]> wrote: > I would like using the additional Keys on the Keyboard but with the x86 > layout they seem to be unaccessible, or is there a way of using them? They are still accessible. Maybe calling them "x86 keycodes" is a misnomer, it's more or less rather a generic set of keycodes. Every keyboard type can be mapped onto this keycode set. > > Reconfigure the console package properly to just use the kernel > > default keymap. > > Wouldn't this give me a US KB layout? Yes it would. > > 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. > > > The machine is an Ultra Sparc 30, I have posted some output from hwconfig > below. Great, thanks. Based upon all the reports, it seems that only the "su" driver causes these weird mouse bootup problems. I'll investigate it soon, hopefully. -- 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 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: 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 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: fc-al and A5000
On Tue, 15 Mar 2005 01:00:40 -0500 Morten Pedersen <[EMAIL PROTECTED]> wrote: > does anyone know where to find some information or know how to make my > E4500 talk to my A5000? Unfortunately, you are currently out of luck. The SBUS fc drivers are in a very poor state and don't work for most people. Ben Collins is trying to get the SOC/SOCAL driver working with his array on his E4500. He'll certainly post results if he makes any progress. -- 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: 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 (was: Bits (Nybbles?) from the Vancouver release team meeting)
On Tue, 15 Mar 2005 00:07:28 +0100 Frans Pop <[EMAIL PROTECTED]> wrote: > See installation-report #298927 in BTS [1]. Also this [2] thread on > d-boot. > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298927 Current images have the tg3 bug fix he talks about. The IDE problem is weird. There are two possibilities: 1) The ALI driver doesn't work modular on his box for some reason. 2) Some patch in the debian kernel tree causes it to break. He does state that building a vanilla 2.4.27 with the ALI driver built statically makes it work. I kind of remember this report for some reason. Perhaps some other device took over the IDE ports or something weird like that, which makes modular IDE driver not work. Can we get this reporter to retry with current CDROM images? If it still fails, I'll pull out my SB100 and help debug. > [2] http://lists.debian.org/debian-boot/2005/03/msg00249.html This says that current images work and no longer have the problem. > There is also #299074 [3], but that is probably unrelated. > > [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299074 He lists the exact way to solve the problem, which is that SBUS driver modules don't get loaded properly, and that by autoloading the modules he listed the problem can be worked around. It looks to me like there is an autoprobing and automatic module loading mechanism for PCI devices, and there is not one for SBUS devices. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
