Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Linux Software

HP Still Porting Linux to 64 bit PA RISC 51

Fungai wrote with an update to the on-going HP/Puffin Group story. There'd been some confusion with the recent purchase of Puffin Group by Linuxcare, but HP has confirmed that they will port Linux to their 64 bit PA-RISC chips. HP will still be partnering with Puffin Group to do it, with results expected in the first half of 2000.
This discussion has been archived. No new comments can be posted.

HP Still Porting Linux to 64 bit PA RISC

Comments Filter:
  • Has anyone here used a RISC processor? I haven't, and I'm curious as to the performance level of these things running Linux....
  • What does this mean for the 700/800 series machines and the porting effort there? I myself own 2 700 series machines that I would like to have Linux running on. Now true I wouldnt mind buying a J7000 but I think economically isn't there going to be more likeliness of people buying older Nova class and the K,R,D, and B series?

    MaShaun Jones
  • It's not necessarily a matter of *buying* old ones... at work we've got a TON of old D classes sitting around doing nothing that I would love to put linux on to play with :)
  • by NYC ( 10100 ) on Tuesday December 21, 1999 @04:59AM (#1456624)
    Apple and SGI computers are some examples of machines that run on RISC processors.

    Apple computers are known for their amazing speed (the latest G3s were not suitable for export) but their inferior OS loses any benefits in speed gained from the hardware. Of course, you can always install a RISC-based version of Linux like mklinux on a Mac.

    SGI machines like the Origin server series are among the fatest computers in commercial use today. My SGI O2 workstation is only 200MHz, but since the processor is a RISC processor, it is comparable to a 300+MHz CICS processor.


    --Ivan, weenie NT4 user: bite me!

  • The more the merrier. So now we have the Mer^H^H^HItanium, now the HP processor...

    Well, best of luck geeks. Heres hoping that Linux will run on another platform soon.

    On an offtopic note: I tried posting this story earlier, but /. was down (or /.ed). Rob, could you please inform us of possible downtimes before hand. Not all of us have free local calls. :(
  • From what I know of the 2GB filesize limitation, it goes away with 64 bit processors, right?

    And the 2038 problem too?

    Are there other interesting things that get cleaned up, or turn out to be gotchas?

  • by NYC ( 10100 )
    Here are some links to linux ports on RISC processors:

    Apple Macintosh

    SGI
    • SGI Linux [sgi.com]

      --Ivan, weenie NT4 user: bite me!
  • I have access to a HP Vizualize workstation, dual 440 Mhz processor, each is somewhat faster than what a Pentium 3 at 800 would give and architecture is somewhat better and it can use PCI cards and USB components (if drivers exist)...

    As for class N machines a recent one will have at least 2 processor (what we have is 2 class N with 4 processors each and a shared Raid Array)... These machine are physically huge, they are extremely fast and extremely expensive. They have much better performance than you can have with any x86-based computer right now. They don't have a great price/performance ratio, but sometime you need the performance they deliver...

  • Well, I've used a 32 bit RISC (the PowerPC 603e), with linux and I'm pretty satisfied. The only problem is that intel is just about the only system that seriously gets supported. So things most closed-source products like Metrowerks or Corel Wordperfect don't work.

    However in terms of the feel of things I'd say my 603e @ 200Mhz "feels" roughly like a Pentium 233-266. (Both on linux, as long as I'm not doing heavy disk access or 3D stuff.... The linuxPPC scsi/ide drivers seem out of whack to me, but I could be wrong)

    As a development machine/webserver, it's great, but like I said if you wanna run a lot of closed-source stuff, that's a different story. (I just got word for Loki that QIIIA won't be available for LinuxPPC for quite a while. sigh, guess I'm gonna have to go buy _another_ computer. :) )
  • Alphas are RISC, and Linux has run (extremely well) on them for quite some time now. The floating point performance on the alphas is incredble - they work great.
  • I posted this story a couple of hours ago but I'd still like to add my thoughts..

    This is a good thing for Linux, but a better one for HP. Just when you thought they'd put all their eggs in the IA64 basket... Out pops Linux on 64-bit PA RISC and a nice new hardware revenue stream for HP.

    The-cynical-but-fond-of-risk-Linux-user
  • by twit ( 60210 ) on Tuesday December 21, 1999 @05:52AM (#1456633) Homepage
    I think (the eternal IMHO) that the major advantage that a PA-RISC port presents is not blinding speed on the desktop or price-performance, but access to a family of mission-critical hardware. Linux, developed on PC's and ported to a wide range of workstation hardware, has historically been short on big iron. Access to PA-RISC hardware, whether legacy or new machines, will go a long way towards remedying that deficit.

    If people (myself among them) spoke out against linux's reliability on commodity hardware, no one can question the reliability and stability of HP's unix hardware. It would be easy to sell me on a HP unix box running Linux - or at least, it would be, if I was still doing that kind of stuff.

    --
  • The 2GB limitation has already been fixed in newer kernels, you can use files > 2GB with 32 bit processors now.
    Don't know about the 2038 problem - might be a glibc issue, but I'm not sure...
  • Why can't linux people just accept that their OS' niche is a unix-like OS running on commodity hardware? We've seen another good example of an OS that tries to be all things, and look how it failed. Do we really want to take the industry down that path again? Linux works exceptionally well on the hardware it was designed for: namely, x86 hardware. It runs on macintoshes, HP machines, Alphas, and god only knows what else... but those are all inferior ports.

    Code sharing is good. Code bloat is not. My vote is to fork the existing ports into seperate kernel dev teams and refocus linux. If we spread ourselves too thin, we'll release about as often as Microsoft. *stepping down off the soap box* Mark me down now.

  • Only a tiny portion of the Linux kernel code is CPU-specific. The filesystem, scheduling, IPC, networking, and terminal subsystems are all CPU-neutral. Forking the entire kernel on a CPU-by-CPU basis isn't necessary.

    It runs on macintoshes, HP machines, Alphas, and god only knows what else... but those are all inferior ports.

    Care to supply some evidence of that alleged inferiority? Even just saying how they're inferior would be a start. They can't all be inferior in the same way.

  • I'm not sure how 'code bloat' gets into this. The support for a given platform is compiled in only for that platform so it doesn't really matter how many platforms are supported.

    'Spreading ourselves too thin' might appear to be a valid critisism, except that the same people aren't maintaining all the ports. HP wants a port to their hardware, so they're paying people to do it. The burden on the core developers is minimal, PLUS the HP (actually Puffin Group) staff might find solutions to problems that could benefit everybody.

    The beauty of having lots of platforms is that we can move easily from one 'commodity' platform to another as the economics change. ia32 hardware may provide a nice price point today, but if AMD or Transmeta or Sam's Chip Factory comes up with a fast, cheap platform, we know the transition will be easy and smooth.

    I suspect that the ia64 port would have been far more difficult had 64-bit support not already been in place for Alpha. Similarly, changes introduced for ia64 will probably be good for Alpha, Sparc64, and HP. I just don't see the down side that you you're worried about.

  • Why can't linux people just accept that their OS' niche is a unix-like OS running on commodity hardware?

    Because it isn't?
    Seriously, Linux is the first operating system that I have ever seen that isn't in a niche. True, it has its roots on i386 commodity boxes, but it has been designed properly and runs well (and without nasty compromises) on more stuff that just about any other OS.

    Do we really want to take the industry down that path again?

    Nobody is taking the industry anywhere. The industry is scrabbling to follow.

    Code sharing is good. Code bloat is not.

    While it is true that the Linux codebase will always expand (unless legacy support is elected to be removed) the runtime of any particular port does not have to be that huge.

    My vote is to fork the existing ports into seperate kernel dev teams and refocus linux,

    Separate teams are precisely what the subject of the original post was about: the Puffin Group is one such, working on 64 bit PA-RISC; Trillium is another, working on IA-64. I don't see that there is any lack of focus.
  • by sterwill ( 972 ) on Tuesday December 21, 1999 @07:29AM (#1456641) Homepage
    Inferior ports?! You are just completely wrong! Tell me which "inferior ports" you've actually _used_ (installed, used, and maintained). Projects you've "heard about on Slashdot" do not count. I'll wager you haven't actually used Linux on real hardware (something that's evolved since 1980, like the Alpha, Sparc, or PowerPC, or MIPS, or PA-RISC), or you'd know just how exactly ignorant your assertion is.

    I wrote this comment on a 333 MHz PowerBook running Linux 2.3.22, in X at 1024x768 at 32 bpp, with all the software I need to get all my work done. Every piece of hardware is supported, and it's a better laptop value than any Intel-based offering. The 56K internal modem works, the 10/100 Ethernet works, the 14.1" screen is beautiful, the media bays (batteries, CD-ROM, DVD-ROM) work great, power management is superb (5 hours off a single battery), audio in and out, two completely useful USB ports (one of which runs a Logitech mouse when I'm parked at a desk), and even S-Video _and_ VGA output, and external SCSI. All of this with no "docking stations" -- the ports are right on the back. And they're $2499.

    I also use Linux on the Alpha, and the Alpha architecture is supported as well as, and possibly better, than the PowerPC architecture.

    Have you run any of these?

    --
  • Will the port run on HP3000/MPEiX boxes as well?
    Your Working Boy,
  • I was not bashing PA-RISC, (well not very much) just stating the facts. maybe this will prod them to release their PA-8600 sometime. :) MIPS(high end) is already on life support. (the doctors are just talking about when to pull the plug) SPARC just fell down and is pulling its emergency response key. if USIII does not show up soon SPARC may be on its way to the emergency ward. PA-RISC is in a deep coma. Limbo land. The problem I see is that they have allready commited to IA64. most of HP's brain trust is working on Mickinley. and the left over is working on PA-8600. Do they have the resources to start a new design now? and if they did when will it be done? I think a lot of these companies and consumers too. need to wake up and realize that having one company make all the chips is a bad thing. So I still hope for a miracle to revive the alternative cpu market as well as the alternative OS market.
  • Isn't it interesting, then, that the way they generate buzz for their box is to port Linux to it?
  • I don't know how much HP has paid to Puffin-and-friends to port the kernel (though I bet equipment makes up a big chunk of the total). A few million dollars, at most.

    Now consider all the customers who've spent billions over the years to run their businesses with HP equipment. With the great and growing value of open source, why on earth would you deny them access? How rude!

    This is reason IBM whipped up a custom kernel for their mainframe customers. Negligible cost for ever increasing benefits.

    disclaimer: I've only worked on IA-32, but I saw an HP server cube once (HP9000 IIRC).
  • >No, those are based on Motorola 680x0 CPUs, not PA-RISC.

    No, the HP3000's are PA-RISC based (except for the REALLY old ones)
    systems that run HP's MPE OS. You're thinking of the 300 series
    workstations, that pre-dated the motorola based 400 series workstations,
    which in turn predated the pa-risc based 700 series workstations.

    HP3000's are still available today.
  • shucks, the original 32 bits lasted 68 years, and now that's been multiplied by 4 billion... that's an awfully long time, overkill even. I guess it would introduce too many weird incompatibilities, but wouldn't it be handy if time_t had a few of its 64 bits dedicated to fractional seconds? nah, usleep already confuses me.

    An off-the-64bit topic question: when astronomers and nuclear physicists decide that we need a leap second, what happens to UTC? does Unix-midnight and midnight in Greenwich England no longer coincide because the number of seconds since 1970 no longer evenly arrives at date boundaries?

    BTW, thanks for all of the other answers, everybody.

  • by Anonymous Coward

    My understanding is that there is little difference between the 3000's and the 9000's, except for the model number sticker. If so, there should be no problem with the Linux port.
  • PA-RISC is in a deep coma. Limbo land. The problem I see is that they have allready commited to IA64. most of HP's brain trust is working on Mickinley. and the left over is working on PA-8600.

    Do they have the resources to start a new design now? and if they did when will it be done?

    HP corporate press [hp.com] and some analysts (Gartner?) disagree with the death of PA-RISC. If this PR is correct, HP must already be working on at least PA-8700. The .hp.com in my e-mail address means I can't comment further. And even when PA-RISC dies, the ideas aren't completely dead. Does the IA64 instruction set look more like Pentium or PA-RISC?

    Seems to me some people will feel comfortable going to IA-64 right away, and some will probably take a while. Just think how many folks are still running really old OSes. There'll also probably be a short period where the performance of PA-RISC and other current processors overlaps with IA-64 performance, just as there is probably some overlap between Pentium and PA-RISC today.

    Linux on PA-RISC gives people the option to convert to Linux sooner and/or cheaper, either converting their existing HP boxes or purchasing new ones, and then switch to Linux on IA-64 later -- two small steps instead of one large one. (Some will continue using HP-UX of course)

    This sounds like customer choice, which seems like a good idea.

    But the best reason for Linux on PA-RISC is that I have fun helping make it happen!

  • by Xenu ( 21845 )
    The leap second [navy.mil] is normally inserted at the end of the last day in June or December. The last leap second was added to December, 1998. The sequence was:

    1998-12-31 23:59:59
    1998-12-31 23:59:60
    1999-01-01 00:00:00

    Note that there can be 61 seconds in a minute when a leap second is inserted.

    Some Unix systems pretend that leap seconds do not exist, others attept to take them into account, using tables of leap seconds. It might be better to run the system clock on TAI and convert to UTC or local time with a leap second table.

  • I have the pleasure to work on PA RISC Systems from time to time, and I absolutely love them. PA-RISC is a beatiful, somehow strange and verrrry fast CPU, the only one to keep up with the Alpha lately.

    All other RISC CPUs (MIPS, USPARC, and esp. Power(PC),...) have fallen behind the Alpha and PA-RISC, and if I had to chose one of the two for my desktop, I think I would chose the PA-RISC. Sure, the Alpha 21264 is a little faster, but the overall Quality of the HP hardware is hard to beat.

    We have some really old PA-RISC Workstations (~1990) and they are still in best condition and fun to work with. These machines are astonishingly fast for their time. An ancient PA-RISC 7100 is as fast (INT) as a PPro at half the clock speed, and competes with a P2/400 at FP - running at a 5th of the clock speed!

    P.S.: Don't be fooled by the PowerPC and Apples stupid "supercomputer" campaign. Even the G4 is horribly slooowwww for a RISC CPU, even in FP. A fast CISC Athlon still beats it any day of the week. And x86 have broken the GFLOP barrier almost a year before Apple with their G4. If you want a real computer, don't go for Apple toys.

  • the latter but, HP controls PA-RISC, HP does not control IA64. my feeling is after Mckinley ships. Intel will control both the arch and implementation of all future IA64 processors.

    That wouldn't seem logical if this earlier announcement [hp.com] is true.

    but wait a couple of years and HP will be buying and reselling Intel IA64 server hardware building blocks like they do now with IA32.

    It wouldn't surprise me if the part of HP currently selling high-end IA32 boxes goes this way.

    There'll also probably be a short period where the performance of PA-RISC and other current processors overlaps with IA-64 performance

    How short do you think this will be? one year or several decades?

    My personal opinion is the longer overlap with existing and new processors the better -- competition is good.

    Yeah, good luck with linux. and PA-RISC. I bet more people will want your big-iron PA systems than dell's new IA64-systems.

    Hope so.

    Are you working with Merced (erhh iTanium), proto systems?
    -- A bunch or questions you will not answer

    Some of my friends are working on IA64 stuff. I've used the IA64 simluator but haven't seen the actual working hardware yet.

  • HP is smart to continue to develop the PA-RISC.

    Intel's work (adding legacy 386 baggage) has made the Merced/Itanic slow and late.

    If AMD's 64-bit 386 instruction set cpu is a winner, Intel will drop the Itanic like a hot potato and where would that leave HP?

  • Beeoooch? What the hell is that?

    Oh, I get it. Object-oriented methodology wrestling.

    Let's get ready to RUMMMMMMM-BAUGH!

    :-)
  • Yes.. sure.. that will happen.. about as soon as M$ realized that their niche is a unstable, bloated OS running on expensive hardware or in a trashcan. I prefer the second. Linux's power (while it is not the only free unix clone) is in its cost and functionality. So that school cant afford IRIX 6.1 for the donated indy2... put linux on it.. need to make a router.. put linux on it.. not start a debate on linux in the enerprise.. but the power of linux is on old and obscure hardware.. and that may include the latest RISC chip. just my thoughts --- rm -rf /* is a good password... just dont type it twice
  • That might have been thinking about a year with two leap seconds, with both leap seconds inserted at the same time. The literature says that the rule is to keep UTC within 900 ms of UT1 (astronomical time). If multiple leap seconds are needed, they would be inserted on different dates, say the end of June and December.

E = MC ** 2 +- 3db

Working...