They do make it _sound_ like that: For example, UPA supports UltraSPARC's separate data and
address bus architecture. These large buses-the address bus is 64 bits wide to directly support the 64-bit, V9 architecture, while the data bus is 144 bits wide (128 bits for data and 16 bits for error checking)-allowing for peak, achievable bandwidth. But, they are talking about the seperate busses of the mainboard, not the UPA. http://docs.sun.com/db/doc/805-7764-12/6j7a77hhh?a=view#z400010a55fa Thaey actually state that UPA data is 64 bit. Check figure C-2 where the connector is 64 bit, and shares the data bus. With a 72 bit interface. That functional diagram isn't really clear on that part of it. I'm assuming the other 8 bits are parity (1/2 width data, 1/2 width parity?) but I wouldn't bet anything on it nor would I state it as more than a guess. The non-working arch refers to sparc (not sparc64) in 2.6.0-test6 and is completely wrong. It actually was a compound issue with gcc, then a corrupted second stage loader. The wierd part was that another user I mail to had the exact same problem, and wierdly enough, the exact same cause. (Not quite SO wierd, we are in the same area that had a blackout..both working on install's and kernels at the same time.) ----- Original Message ----- From: "Erwann Abalea" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, October 03, 2003 10:19 AM Subject: Re: [debian-sparc] Re: 2.6.0-test6 <snip> > According to this document > (http://www.eecis.udel.edu/nsfri/docs/Ultra-II/UPA.pdf), the UPA *address* > bus is 64 bit wide, and its *data* bus is 144 bit wide, with 128 bits for > data and 16 bits for error checking. > > I saw mentions of 64-byte transfer blocks in other documents, for example > for the prefetch instruction. Thanks Google for those interesting > documents. ;) > > > Maybe I'm just an old fogey who remembers the days when you tried to wring > > out the performance by aligning software as closely to hardware as possible. > > Maybe I think it's strange/inelegant to have a nonworking architecture in > > the kernel source. > > What are you talking about? nonworking architecture? > > -- > Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5 > ----- > SM> Désolé (c'est quand-même terrible cette société oû l'on doit > SM> s'excuser d'être doué, vraiment...) > Si en + tu devais t'excuser d'être crétin t'aurais un job a plein temps > -+- RM in http://neuneu.ctw.cc - Là, ya indubitablement consensus -+- > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
