Re: Bug #251149: gcc wrapper for sparc is chronically broken
> > > > 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. > > That's probably too ugly for some ppl. Then we'll have to answer the > question of "why does my sparc64 uname report sparc?". > I would be willing to bet that most people will never look and those that do will be competent enough to change whatever option is added to default them back to a 64-bit shell, as long as it's documented well. Jim. -- 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 Mon, May 23, 2005 at 07:27:22PM -0700, David S.Miller wrote: > 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. That's probably too ugly for some ppl. Then we'll have to answer the question of "why does my sparc64 uname report sparc?". > 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. That's what I've wanted for a long time. There was a proposal a long time ago that looked really nice, but I don't think anyone had the motivation to get it all implemented. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ -- 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
You're right. Didn't get down that far. As far as I'm concerned, the default 64-bit is the right thing. But it's hard to convince long time users that a machine that is 99% 32-bit userspace, should compile 64-bit binaries by default, when 99% of the time, those same people are going to want 32-bit. This is a good argument, but as all Debian developers should know, we should take technical correctness over anything. Having a 64-bit machine compile 64-bit by default is technically correct. When "uname -m" reports "sparc64", we should get sparc64 binaries from the compiler. There are tons of work arounds in packages which _correctly_ assumed that sparc64 meant 64-bit, to get them to instead do 32-bit (I believe SSL is one of them, since it always tried to do v9 assembly for sparc64 uname). This is exactly why when I was running the sparc buildd's, I had the build daemon invoking sparc32 for build commands, which is what it should do. 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. So we have to have a correct toolchain, but we also need to make our build system consistent across invocations and users and machines. How do we do this? I'm not sure. We might need to add something into our dpkg-dev system. That's not such a hard thing to do, but it should be easy for someone to disable it in case (like I've done before), someone really does want to build 64-bit packages. On Mon, May 23, 2005 at 02:30:19PM -0700, David S.Miller wrote: > 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] > -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems with esp SCSI driver
Hi, I'm having problems with the esp SCSI driver on a Sun E4000. I'm running a patched version of 2.6.11.9 with two disks and a CDROM attaced to esp0 and 7 disks attached to esp1. I'm running software RAID 5 on the 7 disk set and under high load (the first time when trying to use debootstrap on the RAID and the second time when rebuilding) it seems to work fine for about 20 minutes and then: [ partial log as machine is remote and problem leaves the system largely unusable and unable to reboot ] esp1: Aborting command esp1: dumping state esp1: dma -- cond_reg addr esp1: SW [sreg<11> sstep<04> ireg<10>] esp1: HW reread [sreg<11> sstep ireg<00>] esp1: current command [tgt<0a> lun<00> pphase cphase] esp1: disconnected [tgt<09> lun<00> pphase cphase] esp1: Aborting command esp1: dumping state esp1: dma -- cond_reg addr esp1: SW [sreg<11> sstep<04> ireg<10>] esp1: HW reread [sreg<11> sstep ireg<00>] esp1: current command [tgt<0a> lun<00> pphase cphase] esp1: disconnected [tgt<09> lun<00> pphase cphase] <... message repeated a number of times ...> esp1: Resetting scsi bus esp1: Gross error sreg=40 esp1: SCSI bus reset interrupt esp1: DMA error b2bf8a03 esp1: Resetting scsi bus esp1: SCSI bus reset interrupt scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 10 lun 0 scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 9 lun 0 scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 8 lun 0 scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 14 lun 0 scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 13 lun 0 scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 12 lun 0 scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 11 lun 0 SCSI error : <1 0 10 0> return code = 0x2 end_request: I/O error, dev sde, sector 5335680 raid5: Disk failure on sde1, disabling device. Operation continuing on 5 devices scsi1 (10:0): rejecting I/O to offline device the RAID then promptly fails each disk in turn and renders /dev/md0 unusable. After this has happened, none of the disks in the set can be accessed (dd if=/dev/sdi1 of=/dev/null) gives and error saying the device cannot be opened. Each time it has failed on accessing a different disk and I believe the disks are OK. The machine fails to reboot cleanly and requires a hardware power cycle. Can anyone suggest anything? Searching the web only gives a few vauge suggestions to check the hardware and termination. Cheers, - Martin -- Martin [EMAIL PROTECTED] "Seasons change, things come to pass" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug #251149: gcc wrapper for sparc is chronically broken
From: [EMAIL PROTECTED] Date: Mon, 23 May 2005 13:24:18 -0700 > The other alternative is to "touch /etc/disable_64_gcc Sure, but in the mail you are specifically replying to I stated: > > Also, /etc/disable_64_gcc is a workaround and should not be there > > by default as it is now, especially on your build machines. So I > > highly recommend that the build machine environment setup I > > described above is implemented. > > > > I'm going to be making GCC do this in the vanilla gcc sources by > > default, I've already convinced the other Sparc backend > > maintainers that it is the absolute right thing to do. And it > > won't be checking for the /etc/disable_64_gcc workaround file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug #251149: gcc wrapper for sparc is chronically broken
The other alternative is to "touch /etc/disable_64_gcc On Sat, May 21, 2005 at 04:05:21PM -0700, David S. Miller wrote: > 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] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X - window setup on Sparc station 5.
Hello. On Monday 23 May 2005 20:33, [EMAIL PROTECTED] wrote: > Hello group, Thanks a bunch for replying my earlier question. > I'm having problems in installting the X windows. I indexed the > packages using CDROM and tried to install the same. Nothing seems to > happen. Your help will be appreciated. > I'm searching on line and will try more. > > regards Hmm. I'm moving, all my Sparcstations are at my new appartment - cannot check at the moment. So I'm talking right out of my head... Are we talking about Debian Woody (3.0rx)? At the end of the installation process, you are offered to run a tool called tasksel (Task Select). There is an option called X Window System. Select it. This will install the required software. You still have to setup your X Window configuration - you need to know which graphics card is installed. Does text mode work? You can call dmesg and search for your grafics card. I'm writing this mail on a Ultra2 with Debain Woody installed, dmesg reports a framebuffer device fb0 and a Creator card. Should work on SS5, too. Probably you have a CG6. If dmesg doesn't help, reboot and STOP-A. You will get a logo depending on your graphics hardware, and some text reporting CPU type and speed, memory size and - as far as I remember - the graphics board. Good luck, Hartwig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sparcstation 5 - Debian installation
On Mon, 2005-05-23 at 10:48 -0700, [EMAIL PROTECTED] wrote: > thanks a bunch to all ! I got it. My next task is to setup the X. I > don't know which card i've. > I'll try first. The C conrfiguration part of the installation usually problems display adaptors and sets all that up for you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
X - window setup on Sparc station 5.
Hello group, Thanks a bunch for replying my earlier question. I'm having problems in installting the X windows. I indexed the packages using CDROM and tried to install the same. Nothing seems to happen. Your help will be appreciated. I'm searching on line and will try more. regards
Re: Sparcstation 5 - Debian installation
thanks a bunch to all ! I got it. My next task is to setup the X. I don't know which card i've. I'll try first. regards -a On 23 May 2005 10:02:05 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, > > Assuming you have a keyboard attached to the machine, type STOP-a > while booting to get the prom prompt, then type "boot cdrom". This will > work as long as the alias for the cdrom is set up up correctly. If not, > or if I have missed the point of your question, you'd better wait for > someone more expert to answer, > > Regards, > > Ben Mulvihill > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: Sparcstation 5 - Debian installation
Hi, Assuming you have a keyboard attached to the machine, type STOP-a while booting to get the prom prompt, then type "boot cdrom". This will work as long as the alias for the cdrom is set up up correctly. If not, or if I have missed the point of your question, you'd better wait for someone more expert to answer, Regards, Ben Mulvihill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sparcstation 5 - Debian installation
Le lundi 23 mai 2005 à 12:43 -0400, Chris Trainor a écrit : > You should just be able to hit Stop-A and then type boot cdrom on most > Sparc 5's. > > If your using a PC style keyboard and not a Sun, then I have no idea. :( Stop-A is just a «break». Probably «ctrl-b» would work. > --Chris [..]
Re: Sparcstation 5 - Debian installation
You should just be able to hit Stop-A and then type boot cdrom on most Sparc 5's. If your using a PC style keyboard and not a Sun, then I have no idea. :( --Chris On Mon, 23 May 2005, [EMAIL PROTECTED] wrote: > Hi, > I'm trying to start the installation CD on a Sun sparcstation. I > forgot the key combination to default the boot search in the cdrom. If > any body knows the same please let me knwo asap. > > regards > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sparcstation 5 - Debian installation
Hi, I'm trying to start the installation CD on a Sun sparcstation. I forgot the key combination to default the boot search in the cdrom. If any body knows the same please let me knwo asap. regards
Re: 64 bit versions of strace and gdb
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. On Tue, May 17, 2005 at 12:18:57PM -0700, David S. Miller wrote: > 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 :-) -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
