From owner-linux-origin@oss.sgi.com Tue Feb 1 14:53:17 2000 Received: by oss.sgi.com id ; Tue, 1 Feb 2000 14:53:07 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:45815 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 1 Feb 2000 14:52:48 -0800 Received: from cacc-13.uni-koblenz.de (cacc-13.uni-koblenz.de [141.26.131.13]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA14032 for ; Tue, 1 Feb 2000 23:55:42 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Tue, 1 Feb 2000 22:36:40 +0100 Date: Tue, 1 Feb 2000 22:36:40 +0100 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: ISA / EISA? Message-ID: <20000201223639.C19485@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Are there any ISA / EISA bridges available for SN0? Ralf From owner-linux-origin@oss.sgi.com Tue Feb 1 14:57:17 2000 Received: by oss.sgi.com id ; Tue, 1 Feb 2000 14:57:07 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47190 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Feb 2000 14:56:58 -0800 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09400; Tue, 1 Feb 2000 15:02:37 -0800 (PST) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA52939; Tue, 1 Feb 2000 14:58:42 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200002012258.OAA52939@google.engr.sgi.com> Subject: Re: ISA / EISA? To: ralf@oss.sgi.com (Ralf Baechle) Date: Tue, 1 Feb 2000 14:58:42 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000201223639.C19485@uni-koblenz.de> from "Ralf Baechle" at Feb 01, 2000 10:36:40 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > Are there any ISA / EISA bridges available for SN0? > > Ralf > No, we do not support ISA / EISA devices. AFAIK. KAnoj From owner-linux-origin@oss.sgi.com Tue Feb 1 15:25:07 2000 Received: by oss.sgi.com id ; Tue, 1 Feb 2000 15:24:57 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:6534 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 1 Feb 2000 15:24:41 -0800 Received: from cacc-13.uni-koblenz.de (cacc-13.uni-koblenz.de [141.26.131.13]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA17509; Wed, 2 Feb 2000 00:27:39 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 2 Feb 2000 00:25:40 +0100 Date: Wed, 2 Feb 2000 00:25:40 +0100 From: Ralf Baechle To: Srinivasa Prasad Thirumalachar Cc: linux-origin@oss.sgi.com Subject: Re: ISA / EISA? Message-ID: <20000202002540.F20247@uni-koblenz.de> References: <20000201223639.C19485@uni-koblenz.de> <200002012300.PAA67722@sprasad.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200002012300.PAA67722@sprasad.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Feb 01, 2000 at 03:00:18PM -0800, Srinivasa Prasad Thirumalachar wrote: > > Are there any ISA / EISA bridges available for SN0? > > I dont think so. Do you think someone would have built a > pci to isa bridge :-) > > Then you can see if you can get the > pci card cage addition to the o200 and stick in the pci card. Ok, that answer sounds sufficiently fuzzy that I will not try to get the ISA support (isa_* functions in ) right for SN before somebody presents me actual hardware. It will be easy to implent it as long as it's just a single (E)ISA bus. Ralf From owner-linux-origin@oss.sgi.com Tue Feb 1 15:29:37 2000 Received: by oss.sgi.com id ; Tue, 1 Feb 2000 15:29:28 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:5188 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 1 Feb 2000 15:29:24 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA16386; Tue, 1 Feb 2000 15:27:58 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA86594; Tue, 1 Feb 2000 15:32:09 -0800 (PST) mail_from (wje@liveoak.engr.sgi.com) Received: (from wje@localhost) by liveoak.engr.sgi.com (8.9.3/8.8.7) id PAA30900; Tue, 1 Feb 2000 15:32:00 -0800 X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f From: "William J. Earl" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14487.27888.88320.174780@liveoak.engr.sgi.com> Date: Tue, 1 Feb 2000 15:32:00 -0800 (PST) To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Cc: ralf@oss.sgi.com (Ralf Baechle), linux-origin@oss.sgi.com Subject: Re: ISA / EISA? In-Reply-To: <200002012258.OAA52939@google.engr.sgi.com> References: <20000201223639.C19485@uni-koblenz.de> <200002012258.OAA52939@google.engr.sgi.com> X-Mailer: VM 6.74 under Emacs 20.3.1 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Kanoj Sarcar writes: > > > > Are there any ISA / EISA bridges available for SN0? > > > > Ralf > > > > No, we do not support ISA / EISA devices. AFAIK. There is a part from National, the PC87200, which allows one to make a PCI-to-ISA adapter (with up to 4 ISA slots), but I don't know of any extension modules along the lines of the Bit3 PCI-to-PCI extenders which use it. From owner-linux-origin@oss.sgi.com Thu Feb 3 07:41:21 2000 Received: by oss.sgi.com id ; Thu, 3 Feb 2000 07:41:11 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10758 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Feb 2000 07:40:45 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA01348 for ; Tue, 1 Feb 2000 23:38:11 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id XAA72786 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Tue, 1 Feb 2000 23:35:17 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA16262 for linux-origin@oss.sgi.com; Tue, 1 Feb 2000 23:35:03 -0800 Date: Tue, 1 Feb 2000 23:35:03 -0800 From: dagum@barrel.engr.sgi.com (Leo Dagum) Message-Id: <200002020735.XAA16262@barrel.engr.sgi.com> To: linux-origin@oss.sgi.com Subject: dynamic dma interface Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I had a closer look at the dynamic dma interface introduced in 2.3.41 and, although a step in the right direction, it's very much tailored to just sparc64 and solving only the problem of 32 bit dma's in a .gt. 32 bit paddr space. I think without much impact on their existing sparc64 code, this could be made a lot more general. Description ----------- A brief summary of the interfaces as I understand them is: Following two routines are used for what they call "static" dma mappings. These are roughly equivalent to PCIIO_DMA_CMD type mappings in Irix. The 'alloc' routine will allocate the memory, acquire necessary hw resources and map the vaddr to a paddr and return this value. The 'free' routine free's hw resources and the allocated memory. void *pci_alloc_consistent(struct pci_dev *pdev, size_t size, dma_addr_t *dma_addrp) void pci_free_consistent(struct pci_dev *pdev, size_t size, void *cpu, dma_addr_t dvma) These four routines are used for what they call "streaming" dma mappings. These are roughly equivalent to PCIIO_DMA_DATA type mappings in Irix. The routines assume the device driver has allocated the required memory and they simply do the mapping. The 'sg' routines are used for scatter-gather dma's. dma_addr_t pci_map_single(struct pci_dev *pdev, void *addr, size_t sz) void pci_unmap_single(struct pci_dev *pdev, dma_addr_t bus_addr, size_t sz) int pci_map_sg(struct pci_dev *pdev, struct scatterlist *sglist, int nelems) void pci_unmap_sg(struct pci_dev *pdev, struct scatterlist *sglist, int nelems) Finally, these two routines are used in conjunction with the 'pci_map_*' routines to force memory consistency if you use the same streaming dma region multiple times and touch the data between dma transfers. void pci_dma_sync_single(struct pci_dev *pdev, dma_addr_t bus_addr, size_t sz) void pci_dma_sync_sg(struct pci_dev *pdev, struct scatterlist *sglist, int nelems) Issues ------ 1. Assumes that resources are only required for 32-bit devices doing dma's into a .gt. 32-bit paddr space. On mips64 we need to allocate resources for all dma's (i.e. RRB's on the bridge are required for any dma, and in addition ATE's are required for 32-bit dma's). How do we distinguish between 32bit dma's and 64bit dma's with this interface? Jakub states outright in one of his postings that the "whole interface is currently for SAC". 2. Not what I consider an orthogonal interface. E.g. pci_alloc_consistent() will actually call page_alloc() for you whereas pci_map_single() expects you to already have allocated memory. I makes more sense to let the driver explicitly do the memory allocation. Then this interface needs only allocate any hw resources for the dma and then do the mapping. This also allows you to reserve a much larger mapping size than what you may want to actually allocate, which would be useful if the reservation of hw resources were decoupled from the actual mapping of addresses. 3. The interface is not very extendible. Different kinds of mappings are provided through api, so extensions are only possible through new api. Proposal -------- The issues above could be addressed fairly easily. First of all, there's no need for pci_alloc_consistent() to allocate the memory. Instead let the driver allocate the memory. Then rather than have a pci_alloc_consistent() call, just have a pci_map_single() call which takes a flag argument. The flag could specify CONSISTENT vs. STREAMING. This would make it easier for mips64 to add additional performance-oriented flags that make sense for different platforms (and would be no-ops on unsupported hardware). Most importantly it allows you to specify (through a flag) when your card is 64 bit capable, so the same interface can work for either 32 bit or 64 bit pci cards. Ideally we would want to distinguish between allocating hw resources and actually translating (i.e. mapping) addresses. The pci_map_single() interface ties the two together. There's some performance to be gained by separating the two because that allows you to grab the hw resources just once and reuse them for different dma's. Also it means that you don't need a flag argument for the 'sg' interfaces (assuming you were going to use a flag to distinguish between 32-bit and 64-bit pci cards). You simply have one pci_alloc_resources() call which takes the flag argument, allocates the appropriate resources, and then pci_map_single/pci_map_sg do the appropriate address mapping. Comments? Btw, if you want to see the code, I downloaded 2.3.41 to annie.engr:/usr/src/linux-2.3.41. The interfaces are coded in arch/sparc64/kernel/pci_iommu.c - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Thu Feb 3 21:05:44 2000 Received: by oss.sgi.com id ; Thu, 3 Feb 2000 21:05:35 -0800 Received: from sgi.SGI.COM ([192.48.153.1]:5894 "EHLO sgi.com") by oss.sgi.com with ESMTP id ; Thu, 3 Feb 2000 21:05:24 -0800 Received: from google.engr.sgi.com ([163.154.10.145]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05981 for ; Wed, 2 Feb 2000 13:00:14 -0800 (PST) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA45113; Wed, 2 Feb 2000 12:58:58 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200002022058.MAA45113@google.engr.sgi.com> Subject: Re: dynamic dma interface To: dagum@barrel.engr.sgi.com (Leo Dagum) Date: Wed, 2 Feb 2000 12:58:57 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <200002020735.XAA16262@barrel.engr.sgi.com> from "Leo Dagum" at Feb 01, 2000 11:35:03 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > Issues > ------ > 1. Assumes that resources are only required for 32-bit devices doing > dma's into a .gt. 32-bit paddr space. On mips64 we need to allocate > resources for all dma's (i.e. RRB's on the bridge are required for > any dma, and in addition ATE's are required for 32-bit dma's). > How do we distinguish between 32bit dma's and 64bit dma's with this > interface? Jakub states outright in one of his postings that > the "whole interface is currently for SAC". As you mention later on, we probably need to pass a 32/64 bit flag down to the pci/dma layers (most efficient). Alternately, we might need to come up with a way of tying some information to each device number, similar to the irix hwgraph, from which this information can be looked up. Agree with all your comments. Kanoj From owner-linux-origin@oss.sgi.com Thu Feb 3 22:10:45 2000 Received: by oss.sgi.com id ; Thu, 3 Feb 2000 22:10:35 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:15003 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 3 Feb 2000 22:10:13 -0800 Received: from cacc-17.uni-koblenz.de (cacc-17.uni-koblenz.de [141.26.131.17]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA01857; Wed, 2 Feb 2000 23:04:59 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 2 Feb 2000 23:03:08 +0100 Date: Wed, 2 Feb 2000 23:03:08 +0100 From: Ralf Baechle To: Leo Dagum Cc: bcasavan@sprasad.engr.sgi.com, server1-plat@sprasad.engr.sgi.com, Srinivasa Prasad Thirumalachar , steiner@sprasad.engr.sgi.com, linux-origin@oss.sgi.com Subject: Re: PCI violations? with o200 hardware - background Message-ID: <20000202230307.A1422@uni-koblenz.de> References: <200001141934.LAA22202@sprasad.engr.sgi.com> <10002020953.ZM17017@barrel.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <10002020953.ZM17017@barrel.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Wed, Feb 02, 2000 at 09:53:31AM -0800, Leo Dagum wrote: > Interrupt Signal Distribution > > There are two unique interrupt signals on each PCI bus. > The INTA# and INTC# signals > are wired together, and the INTB# and INTD# signals > are wired together. A PCI device > that uses two distinct signals must use > INTA and INTB, or INTC and INTD. A device > that needs more than two signals can use > the additional signal lines, but such a device > must also provide a register from which the device > driver can learn the cause of the interrupt. The Linux PCI backend already knows about this, see ip27-pci.c. I don't think it's a violation of the PCI specs. The PCI specs only say how the interrupts of PCI daughter busses are wired to their parents, not to the host bus. Even sharing of interrupts is mandatory feature afaik. Ralf From owner-linux-origin@oss.sgi.com Fri Feb 4 21:53:42 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 21:53:32 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:2483 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 21:53:24 -0800 Received: from cacc-20.uni-koblenz.de (cacc-20.uni-koblenz.de [141.26.131.20]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA03609; Thu, 3 Feb 2000 22:48:17 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 3 Feb 2000 13:30:58 +0100 Date: Thu, 3 Feb 2000 13:30:58 +0100 From: Ralf Baechle To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: Re: dynamic dma interface Message-ID: <20000203133058.A734@uni-koblenz.de> References: <200002020735.XAA16262@barrel.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200002020735.XAA16262@barrel.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Feb 01, 2000 at 11:35:03PM -0800, Leo Dagum wrote: > Proposal > -------- > The issues above could be addressed fairly easily. First of all, there's > no need for pci_alloc_consistent() to allocate the memory. Instead let > the driver allocate the memory. The Sparc people won't like the driver doing allocations itself, neither would I when considering the various other MIPS DMA implementations. If you only want to separate the allocaton of memory from the pci_alloc_consistent() but still do the actual allocations in the layer of pci_*(), no problem with that. We just want to keep the actual allocation outside of the drivers. Look at the drivers that have been hacked to work on MIPS machines and you'll see why ... The interface tries to hide issues like cache coherency outside the driver. These matter when allocating matter just like obfuscating things like cache line size etc., from which pool DMA memory gets allocated etc. We don't want driver writers to deal with these; most of them don't have the slightest clue of what these terms mean, believe me :-( As for flags, getting PCIIO_DMA_{CMD,DATA} would be useful as without hints like that we will not be able to use prefetching and write gathhering on the Origin. Another flag that DaveM and Co. already seem to have agreed on are r/w flags which are needed for some hardware. Ralf From owner-linux-origin@oss.sgi.com Fri Feb 4 22:25:22 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 22:25:12 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:43612 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 22:24:52 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA23559 for ; Thu, 3 Feb 2000 14:15:21 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id OAA98657 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Thu, 3 Feb 2000 14:19:33 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA19848 for linux-origin@oss.sgi.com; Thu, 3 Feb 2000 14:19:19 -0800 From: "Leo Dagum" Message-Id: <10002031419.ZM19846@barrel.engr.sgi.com> Date: Thu, 3 Feb 2000 14:19:19 -0800 In-Reply-To: Ralf Baechle "Re: dynamic dma interface" (Feb 3, 1:30pm) References: <200002020735.XAA16262@barrel.engr.sgi.com> <20000203133058.A734@uni-koblenz.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: linux-origin@oss.sgi.com Subject: Re: dynamic dma interface Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Feb 3, 1:30pm, Ralf Baechle wrote: > Subject: Re: dynamic dma interface > On Tue, Feb 01, 2000 at 11:35:03PM -0800, Leo Dagum wrote: > > > Proposal > > -------- > > The issues above could be addressed fairly easily. First of all, there's > > no need for pci_alloc_consistent() to allocate the memory. Instead let > > the driver allocate the memory. > > The Sparc people won't like the driver doing allocations itself, neither > would I when considering the various other MIPS DMA implementations. > > If you only want to separate the allocaton of memory from the > pci_alloc_consistent() but still do the actual allocations in the layer of > pci_*(), no problem with that. We just want to keep the actual allocation > outside of the drivers. Look at the drivers that have been hacked to > work on MIPS machines and you'll see why ... > So the idea is that pci_alloc_consistent() is for quick and dirty use and pci_map_* are for more advanced use? Presumably the driver has done the memory allocation for pci_map_* right? If that's the case, I have no problem with it, just a different philosophy on interfaces than what I'm used to. > The interface tries to hide issues like cache coherency outside the driver. > These matter when allocating matter just like obfuscating things like cache > line size etc., from which pool DMA memory gets allocated etc. We don't > want driver writers to deal with these; most of them don't have the > slightest clue of what these terms mean, believe me :-( > > As for flags, getting PCIIO_DMA_{CMD,DATA} would be useful as without hints > like that we will not be able to use prefetching and write gathhering on the > Origin. Another flag that DaveM and Co. already seem to have agreed on are > r/w flags which are needed for some hardware. That's great news! So they're going to add flags to the interface? Can we get a flag like PCIIO_DMA_A64 so we can distinguish between 32-bit and 64-bit capable cards? Also is there any chance they would consider splitting the pci_map_* interface into an "allocate_resources" and a actual "map"? - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Fri Feb 4 16:40:06 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:49 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:20101 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 3 Feb 2000 17:31:15 -0800 Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA21710; Fri, 4 Feb 2000 02:31:11 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 4 Feb 2000 02:30:48 +0100 Date: Fri, 4 Feb 2000 02:30:48 +0100 From: Ralf Baechle To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: Re: dynamic dma interface Message-ID: <20000204023048.C696@uni-koblenz.de> References: <200002020735.XAA16262@barrel.engr.sgi.com> <20000203133058.A734@uni-koblenz.de> <10002031419.ZM19846@barrel.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <10002031419.ZM19846@barrel.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Thu, Feb 03, 2000 at 02:19:19PM -0800, Leo Dagum wrote: > So the idea is that pci_alloc_consistent() is for quick and dirty > use and pci_map_* are for more advanced use? Presumably the driver > has done the memory allocation for pci_map_* right? If that's the > case, I have no problem with it, just a different philosophy on > interfaces than what I'm used to. No, the idea is that pci_alloc_consistent is used for dma areas that are used multiple times, like Ethernet rings buffers or SCSI HA CDB's. The allocation of the memory really needs to be done outside of the driver because which Intel hacker would know that on MIPS I might need to access my Ethernet ring buffers via KSEG1? pci_{,un}map_{single,sg} are for _streaming_ mappings. A typical use would be for data to/from disk. The document says explicitly streaming, I also didn't noticed this before. So you could think of them basically like implicitly having set the flag PCIIO_DMA_DATA. The expectation is that it's being used for mappings which are relativly large and also sufficiently aligned, such that the driver doing it's own allocation would not be a problem. (Even silly stuff like the Deskstation Tyne's 512kb DMA buffer SRAM, basically a bounce buffer for DMA data, could be hidden there.) > That's great news! So they're going to add flags to the interface? Can > we get a flag like PCIIO_DMA_A64 so we can distinguish between 32-bit > and 64-bit capable cards? All routines get a struct pci_dev * as the first argument. I wonder if 64-bitiness of a device can be enquired via this pointer? Somebody with a PCI spec know the answer? > Also is there any chance they would consider > splitting the pci_map_* interface into an "allocate_resources" and a > actual "map"? Don't know. Ralf From owner-linux-origin@oss.sgi.com Fri Feb 4 16:40:10 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:50 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:25389 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 16:06:32 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA04379; Fri, 4 Feb 2000 16:02:04 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id QAA79848; Fri, 4 Feb 2000 16:06:16 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA22244; Fri, 4 Feb 2000 16:06:01 -0800 From: "Leo Dagum" Message-Id: <10002041606.ZM22242@barrel.engr.sgi.com> Date: Fri, 4 Feb 2000 16:06:01 -0800 In-Reply-To: Ralf Baechle "pci_* API" (Feb 5, 12:46am) References: <20000205004629.G2140@uni-koblenz.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Ralf Baechle , Leo Dagum Subject: Re: pci_* API Cc: linux-origin@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Feb 5, 12:46am, Ralf Baechle wrote: > Subject: pci_* API > It seems the consens is that they want to go for a second set of functions > named pci64_* and safe the hand full of cycles it takes to check the > flags. > Compared to the cost of doing a dma, the cycles spent on checking flags are insignificant. This approach strikes me as very near sighted, but I suppose that kind of argument doesn't go very far in the Linux community. How about the kernel-bloat argument? Would that sway them? What about the cost of an i-cache miss on account of having these additional, highly redundant routines? I think it's a mistake to introduce such a rigid interface when there is opportunity to make it more flexible at less cost. If they are truly interested in performance then they should introduce an interface that allows different platforms to easily provide performance features that tailored for the platform. - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Fri Feb 4 16:40:11 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:50 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:61356 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 15:47:02 -0800 Received: from cacc-6.uni-koblenz.de (cacc-6.uni-koblenz.de [141.26.131.6]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA22351; Sat, 5 Feb 2000 00:46:58 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Sat, 5 Feb 2000 00:46:29 +0100 Date: Sat, 5 Feb 2000 00:46:29 +0100 From: Ralf Baechle To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: pci_* API Message-ID: <20000205004629.G2140@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing It seems the consens is that they want to go for a second set of functions named pci64_* and safe the hand full of cycles it takes to check the flags. Ralf From owner-linux-origin@oss.sgi.com Thu Feb 17 02:34:15 2000 Received: by oss.sgi.com id ; Thu, 17 Feb 2000 02:33:56 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:32216 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 17 Feb 2000 02:33:44 -0800 Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id LAA09197; Thu, 17 Feb 2000 11:33:41 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 16 Feb 2000 19:49:28 +0100 Date: Wed, 16 Feb 2000 19:49:28 +0100 From: Ralf Baechle To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: New pci_* API Message-ID: <20000216194928.B6330@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Leo, as I recently already have mailed to you my 2.3.41 has a implementation of the new pci_() API. As is it should only work for Origins with upto two gb of memory. I should also mention that because none of my drivers currently uses this API the code isn't tested beyond that it compiles without warnings. So if you could take a look over that code and do what's necessary I thing that't be cool. The IOC3 Ethernet driver would make a nice testcase for the new API. Right now it does everything itself. Ralf From owner-linux-origin@oss.sgi.com Thu Feb 17 02:34:15 2000 Received: by oss.sgi.com id ; Thu, 17 Feb 2000 02:34:05 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:33240 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 17 Feb 2000 02:33:46 -0800 Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id LAA09202 for ; Thu, 17 Feb 2000 11:33:42 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 16 Feb 2000 22:40:07 +0100 Date: Wed, 16 Feb 2000 22:40:07 +0100 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: /dev/console bugs Message-ID: <20000216224007.A6543@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Please try if 2.3.42 fixes the /dev/console problems. I've found that the serial drivers has a good number of differences from my version that don't seem to make sense to me. I've now replaced it with my private version which should be identical with Linus'. Ralf From owner-linux-origin@oss.sgi.com Thu Feb 17 22:15:56 2000 Received: by oss.sgi.com id ; Thu, 17 Feb 2000 22:15:37 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56957 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 17 Feb 2000 22:15:12 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA08591 for ; Thu, 17 Feb 2000 22:18:07 -0800 (PST) mail_from (ulfc@cthulhu.engr.sgi.com) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA74694 for ; Thu, 17 Feb 2000 22:14:56 -0800 (PST) mail_from (ulfc@engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 1A25410508C for ; Thu, 17 Feb 2000 22:12:51 -0800 (PST) Date: Thu, 17 Feb 2000 22:12:51 -0800 (PST) From: Ulf Carlsson To: linux-origin@oss.sgi.com Subject: O200 documentation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Hi, I've collected all the documentation for the O200 that I've been able to find on the network. All of it is in either pdf or postscript format. I could unfortunately not get the documents I converted from framemaker to postscript into only one file, and thus are they splitted. It would be possible to use psmerge to put them together, although it's not worth the trouble. dbear:/build4/ulfc/o200-docs Ulf From owner-linux-origin@oss.sgi.com Fri Feb 18 14:30:23 2000 Received: by oss.sgi.com id ; Fri, 18 Feb 2000 14:30:13 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:53146 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Fri, 18 Feb 2000 14:29:53 -0800 Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA05013; Fri, 18 Feb 2000 23:29:49 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 18 Feb 2000 22:39:54 +0100 Date: Fri, 18 Feb 2000 22:39:54 +0100 From: Ralf Baechle To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: FYI: Recently on vger ... Message-ID: <20000218223954.B24098@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing These are the most recent changes to the PCI DMA API in vger's CVS. Ralf ----- Forwarded message from "David S. Miller" ----- From: "David S. Miller" To: sparclinux-cvs@vger.rutgers.edu Subject: CVS Update@vger.rutgers.edu: linux Date: Fri, 18 Feb 2000 08:51:07 -0500 CVSROOT: /vger/u4/cvs Module name: linux Changes by: davem@vger.rutgers.edu 00/02/18 08:51:04 Modified files: Documentation : DMA-mapping.txt arch/alpha/kernel: pci_iommu.c arch/sparc/kernel: ioport.c arch/sparc64/kernel: pci_iommu.c pci_psycho.c pci_sabre.c sbus.c drivers/block : ide-dma.c drivers/fc4 : fc.c drivers/net : 3c59x.c 8139too.c acenic.c de4x5.c eepro100.c myri_sbus.c rtl8129.c starfire.c sunbmac.c sunhme.c sunhme.h drivers/net/sk98lin: skge.c drivers/parport: parport_pc.c drivers/sbus/audio: cs4231.c dbri.c drivers/scsi : aic7xxx.c eata_dma_proc.c esp.c ncr53c8xx.c qlogicisp.c qlogicpti.c scsi.c scsi.h scsi_obsolete.c scsi_scan.c sd.c sym53c8xx.c include/asm-alpha: pci.h include/asm-arm: pci.h include/asm-i386: pci.h include/asm-ia64: pci.h include/asm-ppc: pci.h include/asm-sparc: pci.h sbus.h include/asm-sparc64: floppy.h pbm.h pci.h sbus.h include/linux : ide.h pci.h Log message: Nearly complete PCI dma mapping interfaces. 1) Add direction flag to streaming mapping functions. Most ports ignore it, sparc64 uses write permissions with it, and ARM+MIPS will use it for more efficient cache flushes. 2) Add pci_dma_supported() to query handling of DMA addressing limitations of devices. As per suggestions from Thomas Sailer. 3) Massive DMA-mapping.txt fixup and cleanups. Based upon the contributions and suggestions of many. This unearthed some bugs in the sc_data_direction settings done by the scsi layer. But these were caught and fixed. Only the 64-bit API remains, and I must do some study before I can put it together properly. ----- End forwarded message ----- From owner-linux-origin@oss.sgi.com Wed Feb 23 15:14:20 2000 Received: by oss.sgi.com id ; Wed, 23 Feb 2000 15:14:10 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:58350 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Wed, 23 Feb 2000 15:13:50 -0800 Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA12729; Thu, 24 Feb 2000 00:13:44 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 23 Feb 2000 22:58:54 +0100 Date: Wed, 23 Feb 2000 22:58:54 +0100 From: Ralf Baechle To: linux-origin@oss.sgi.com Cc: Nancy Bigham Subject: 2.3.47 Message-ID: <20000223225854.A9597@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Guys, just wanted to drop you all a note that I've finally managed to catch up with Linus, I'm now running 2.3.47. Doing my best that I'll manage to merge the mega patch from my private CVS archive to oss. Ralf From owner-linux-origin@oss.sgi.com Thu Feb 24 16:42:40 2000 Received: by oss.sgi.com id ; Thu, 24 Feb 2000 16:42:31 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:13161 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 24 Feb 2000 16:42:10 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA26813 for ; Thu, 24 Feb 2000 16:37:38 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id QAA43938 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Thu, 24 Feb 2000 16:41:54 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA01640 for linux-origin@oss.sgi.com; Thu, 24 Feb 2000 16:41:48 -0800 From: "Leo Dagum" Message-Id: <10002241641.ZM1638@barrel.engr.sgi.com> Date: Thu, 24 Feb 2000 16:41:48 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: linux-origin@oss.sgi.com Subject: (Fwd) CLOSE 779767 - please fix the following kcons mappings Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing FYI Penguin[2-4] are now on the ktools map. - leo --- Forwarded mail from sgi.tasks.nsdsa@fido Date: Thu, 24 Feb 2000 14:31:58 -0800 (PST) Reply-To: sgi.tasks.nsdsa@fido From: pv@fddi-odin.corp.sgi.com (salina@engr.sgi.com) Subject: CLOSE 779767 - please fix the following kcons mappings To: dagum@cthulhu View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=779767 *Status : closed Priority : 3 Assigned Engineer : nsdsa-open Submitter : dagum Opened Date : 01/22/00 *Closed Date : 02/24/00 *Fixed By : salina *Fixed By Domain : engr *Modified Date : 02/24/00 *Modified User : salina *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: salina@engr (BugWorks) Date: Feb 24 2000 02:27:13PM ========================== The ktools.map has been fixed. penguin* machines have been restored to the ktools.map. Sorry for the long delay. ---End of forwarded mail from sgi.tasks.nsdsa@fido -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Thu Feb 24 18:35:51 2000 Received: by oss.sgi.com id ; Thu, 24 Feb 2000 18:35:42 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:60293 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 24 Feb 2000 18:35:22 -0800 Received: from cacc-30.uni-koblenz.de (cacc-30.uni-koblenz.de [141.26.131.30]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id DAA20842 for ; Fri, 25 Feb 2000 03:35:18 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 25 Feb 2000 03:32:34 +0100 Date: Fri, 25 Feb 2000 03:32:34 +0100 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: Merging with Linus Message-ID: <20000225033234.B12699@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing In order to get the diffs down to a managable size again I've just sent over 2mb patches to Linus. If Linus applies them, after his next pre-patch I'll be able to merge the small but hairy things after doing the necessary cleanups for a full merge. Ralf From owner-linux-origin@oss.sgi.com Fri Feb 25 08:20:34 2000 Received: by oss.sgi.com id ; Fri, 25 Feb 2000 08:20:25 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:53935 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Fri, 25 Feb 2000 08:20:10 -0800 Received: from cacc-25.uni-koblenz.de (cacc-25.uni-koblenz.de [141.26.131.25]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA04547 for ; Fri, 25 Feb 2000 17:19:56 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 25 Feb 2000 15:06:30 +0100 Date: Fri, 25 Feb 2000 15:06:29 +0100 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: Re: Merging with Linus Message-ID: <20000225150629.B14586@uni-koblenz.de> References: <20000225033234.B12699@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000225033234.B12699@uni-koblenz.de> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Fri, Feb 25, 2000 at 03:32:34AM +0100, Ralf Baechle wrote: > In order to get the diffs down to a managable size again I've just sent > over 2mb patches to Linus. If Linus applies them, after his next pre-patch > I'll be able to merge the small but hairy things after doing the necessary > cleanups for a full merge. Update - Linus has accepted my patches; they're part of pre-patch-2.3.48-2. Ralf From owner-linux-origin@oss.sgi.com Fri Feb 25 13:25:48 2000 Received: by oss.sgi.com id ; Fri, 25 Feb 2000 13:25:27 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:52195 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Fri, 25 Feb 2000 13:25:23 -0800 Received: from cacc-30.uni-koblenz.de (cacc-30.uni-koblenz.de [141.26.131.30]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA02770; Fri, 25 Feb 2000 22:25:19 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Fri, 25 Feb 2000 21:42:30 +0100 Date: Fri, 25 Feb 2000 21:42:30 +0100 From: Ralf Baechle To: Ulf Carlsson Cc: linux-origin@oss.sgi.com Subject: Re: binutils problem Message-ID: <20000225214230.A15413@uni-koblenz.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Fri, Feb 25, 2000 at 04:53:17AM -0800, Ulf Carlsson wrote: > I think have found the cause of the lost addend now. It's basically an > attempt to fool bfd that backfires. The bfd thinks that local relocations > always are relative to a section, and not relative to the section itself. The > mips assembler code subtracts the value of the symbol from the relocation > addend because it assumes that bfd will incorrectly add it back later, as it > should have done if the relocation was relative to a section. However if the > addend is 0, bfd assumes that it's a relocation against an external symbol, > and thus drops the addend. I think bfd has to explicitly check if the symbol is extern instead if I understand you correctly? > In our test case the symbol value is 8 and the > relocation addend is 8 so we end up with 0 as the addend, and bfd doesn't add > the symbol value back because it thinks the relocation is external. I don't > see an obvious fix for this and there doesn't seem to be a generic workaround > for it either, maybe I can find something tomorrow.. I've played with this variation of your code: .data .word 0 .globl foo .align 2 .type foo,@object .size foo,8 foo: .word 0xdeadbeef .word foo+4 and indeed looks like you are correct. I also took a look at elf32-mips.c. It has a few places that check for if an addend is zero, just search for ->addend. Ralf From owner-linux-origin@oss.sgi.com Fri Feb 25 14:00:07 2000 Received: by oss.sgi.com id ; Fri, 25 Feb 2000 13:59:48 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:22639 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 25 Feb 2000 13:59:35 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA24167; Fri, 25 Feb 2000 13:55:02 -0800 (PST) mail_from (ulfc@cthulhu.engr.sgi.com) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA41573; Fri, 25 Feb 2000 13:59:19 -0800 (PST) mail_from (ulfc@engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id EC643105016; Fri, 25 Feb 2000 13:54:27 -0800 (PST) Date: Fri, 25 Feb 2000 13:54:27 -0800 (PST) From: Ulf Carlsson To: Ralf Baechle Cc: linux-origin@oss.sgi.com Subject: Re: binutils problem In-Reply-To: <20000225214230.A15413@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > I think bfd has to explicitly check if the symbol is extern instead if I > understand you correctly? The issue has obviously been solved in the i386 code since they have extern or weak local relocations against the symbols themselves and not as an offset from the section. I took a quick look at the i386 code last night, but it seems to have a lot of differences from what we're doing in the MIPS code right now. I think we can convert the technique they're using for their relocations though, we're basically trying to do the same thing. I didn't really find how they do it in the i386 code but they may set the section for weak and global symbols to something else than the common section and thus they don't get into the stupid nutcase when the bfd assumes that the relocation is against the section itself. > > In our test case the symbol value is 8 and the relocation addend is 8 so > > we end up with 0 as the addend, and bfd doesn't add the symbol value back > > because it thinks the relocation is external. I don't see an obvious fix > > for this and there doesn't seem to be a generic workaround for it either, > > maybe I can find something tomorrow.. > > I've played with this variation of your code: Yeah, it was possible to simplify the testcase a little bit... > and indeed looks like you are correct. I also took a look at elf32-mips.c. > It has a few places that check for if an addend is zero, just search for > ->addend. Well, it doesn't matter what addends we pass to the bfd interface it will still break unless we do something serious about it. It is not possibly to tell the bfd to generate a relocation to a symbol with offset equal to the addend. We shouldn't have to do something special for the addend is equal to zero case, we need a generic solution. Anyway we aren't really in a hurry to fix this right now, it's easy to provide a workaround for this specific case in the kernel. I'll try to fix it over the weekend. Ulf From owner-linux-origin@oss.sgi.com Fri Feb 25 16:25:29 2000 Received: by oss.sgi.com id ; Fri, 25 Feb 2000 16:25:10 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20599 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 25 Feb 2000 16:24:35 -0800 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA02914 for ; Fri, 25 Feb 2000 16:27:38 -0800 (PST) mail_from (bcasavan@sgi.com) Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA16318; Fri, 25 Feb 2000 18:23:07 -0600 (CST) Received: from kzerza.americas.sgi.com (kzerza.americas.sgi.com [128.162.191.33]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA05393; Fri, 25 Feb 2000 18:23:06 -0600 (CST) Received: from localhost by kzerza.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) via ESMTP id SAA68951; Fri, 25 Feb 2000 18:23:06 -0600 (CST) Date: Fri, 25 Feb 2000 18:23:06 -0600 From: Brent Casavant X-Sender: bcasavan@kzerza.americas.sgi.com Reply-To: Brent Casavant To: Leo Dagum cc: linux-origin@oss.sgi.com Subject: Re: (Fwd) CLOSE 779767 - please fix the following kcons mappings In-Reply-To: <10002241641.ZM1638@barrel.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Thu, 24 Feb 2000, Leo Dagum wrote: > FYI > > Penguin[2-4] are now on the ktools map. For anyone inside the SGI firewall, you can use the following page to locate Ktools machines of any particular type you need (by Iris Processor Number). These pages are updated every day at 5:30AM Central with the current Ktools maps. http://wwwsdiv.americas.sgi.com/~bcasavan/klist Brent -- Brent Casavant | The opinions expressed herein are not necessarily Silicon Graphics, Inc. | those of Silicon Graphics. Come to think of it, bcasavan@sgi.com | they're probably not even those of the author. From owner-linux-origin@oss.sgi.com Sat Feb 26 02:22:43 2000 Received: by oss.sgi.com id ; Sat, 26 Feb 2000 02:22:34 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54801 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 26 Feb 2000 02:22:20 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id CAA02476; Sat, 26 Feb 2000 02:25:24 -0800 (PST) mail_from (ulfc@cthulhu.engr.sgi.com) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id CAA01226; Sat, 26 Feb 2000 02:22:04 -0800 (PST) mail_from (ulfc@engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 6A60A105016; Sat, 26 Feb 2000 02:20:46 -0800 (PST) Date: Sat, 26 Feb 2000 02:20:46 -0800 (PST) From: Ulf Carlsson To: Ralf Baechle Cc: linux-origin@oss.sgi.com Subject: Re: mips64 boot In-Reply-To: <20000226024649.A18436@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > The situation for userland is different and much more complex. GNU libc and > other packages do heavily rely on GNU ld's features. Add that GNU ld is > evolving. That makes using anything but GNU ld a no go for userspace. I was talking to Ralf earlier and I mentioned that I thought SGI was going to use the MIPS Pro compiler to compile the Linux that will run on the IA-64 SN1 machines. I really don't know what's happening with the MIPS Pro compiler nowadays, I've only heard rumours from here and there. If the MIPS Pro compiler is going to be used to compile Linux I assume that the GNU specific features required to compile the GNU libc, such as symbol versioning, will be added, and we can use the features for MIPS as well as IA-64. Does anyone know whether the MIPS Pro compiler for IA-64 will be open sourced or not? Ulf From owner-linux-origin@oss.sgi.com Sat Feb 26 05:21:04 2000 Received: by oss.sgi.com id ; Sat, 26 Feb 2000 05:20:54 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:31965 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Sat, 26 Feb 2000 05:20:34 -0800 Received: from cacc-7.uni-koblenz.de (cacc-7.uni-koblenz.de [141.26.131.7]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id OAA06320; Sat, 26 Feb 2000 14:20:30 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Sat, 26 Feb 2000 14:02:08 +0100 Date: Sat, 26 Feb 2000 14:02:08 +0100 From: Ralf Baechle To: Ulf Carlsson Cc: linux-origin@oss.sgi.com Subject: Re: mips64 boot Message-ID: <20000226140208.B19730@uni-koblenz.de> References: <20000226024649.A18436@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Sat, Feb 26, 2000 at 02:20:46AM -0800, Ulf Carlsson wrote: > > The situation for userland is different and much more complex. GNU libc and > > other packages do heavily rely on GNU ld's features. Add that GNU ld is > > evolving. That makes using anything but GNU ld a no go for userspace. > > I was talking to Ralf earlier and I mentioned that I thought SGI was going to > use the MIPS Pro compiler to compile the Linux that will run on the IA-64 SN1 > machines. I really don't know what's happening with the MIPS Pro compiler > nowadays, I've only heard rumours from here and there. If the MIPS Pro > compiler is going to be used to compile Linux I assume that the GNU specific > features required to compile the GNU libc, such as symbol versioning, will be > added, and we can use the features for MIPS as well as IA-64. Does anyone > know whether the MIPS Pro compiler for IA-64 will be open sourced or not? In that context it may make sense to consider compiler, assembler and linker as related but not directly dependent parts. As said GNU ld and binutils are really insane pieces of code. Expressing it with Alan Cox's words: ``and yes bfd hacking is like doing sendmail configs blind with a belgian keyboard''. And yes, bfd is indeed the abreviation for Big Fucking Deal. The alternative expansion Binary File Descriptor library was created later on ... I would really, really hate if we'd use a different assembler and linker than all the others Linux architectures. It would still leave us with with a broken libbfd which various tools are linked against. The most important one of these is GDB and GDB functionality on IRIX already suffers a good bit from the brokenness of libbfd on MIPS. I just say N32 and 64 ABIs. As mentioned before people at Cygnus have considered replacing GNU ld years ago. Most important to drop everything but ELF support for a ld replacement. With that happening and a new ld going into binutils libbfd still wouldn't be eleminated. But large parts of it's functionality could be eleminated, the complexity by reduced dramatically. Result: only winners, at least among the ELF users. So after some brain storming I think we should try to convince the other architectures that GNU ld is really overdue to be replaced. Probbly little convincing required. What we get is hopefully some linker that is maintainable for us again. Ralf From owner-linux-origin@oss.sgi.com Sat Feb 26 20:50:10 2000 Received: by oss.sgi.com id ; Sat, 26 Feb 2000 20:50:01 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40239 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 26 Feb 2000 20:49:40 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA02148 for ; Sat, 26 Feb 2000 20:52:44 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA40994 for ; Sat, 26 Feb 2000 20:49:38 -0800 (PST) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id UAA64649 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Sat, 26 Feb 2000 20:48:07 -0800 (PST) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id UAA05992 for linux-origin@oss.sgi.com; Sat, 26 Feb 2000 20:47:42 -0800 Date: Sat, 26 Feb 2000 20:47:42 -0800 From: dagum@barrel.engr.sgi.com (Leo Dagum) Message-Id: <200002270447.UAA05992@barrel.engr.sgi.com> To: linux-origin@oss.sgi.com Subject: Re: mips64 boot References: <20000226024649.A18436@uni-koblenz.de> Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > From: Ralf Baechle > > On Sat, Feb 26, 2000 at 02:20:46AM -0800, Ulf Carlsson wrote: > > > > The situation for userland is different and much more complex. GNU libc and > > > other packages do heavily rely on GNU ld's features. Add that GNU ld is > > > evolving. That makes using anything but GNU ld a no go for userspace. > > > > I was talking to Ralf earlier and I mentioned that I thought SGI was going to > > use the MIPS Pro compiler to compile the Linux that will run on the IA-64 SN1 > > machines. I really don't know what's happening with the MIPS Pro compiler > > nowadays, I've only heard rumours from here and there. If the MIPS Pro > > compiler is going to be used to compile Linux I assume that the GNU specific > > features required to compile the GNU libc, such as symbol versioning, will be > > added, and we can use the features for MIPS as well as IA-64. Does anyone > > know whether the MIPS Pro compiler for IA-64 will be open sourced or not? The back-end is going to be open sourced (code generation and optimization), the front end remains gcc. See: http://info.engr.sgi.com/opensrc/proposals/compiler.html > > In that context it may make sense to consider compiler, assembler and > linker as related but not directly dependent parts. > > As said GNU ld and binutils are really insane pieces of code. Expressing > it with Alan Cox's words: ``and yes bfd hacking is like doing sendmail > configs blind with a belgian keyboard''. And yes, bfd is indeed the > abreviation for Big Fucking Deal. The alternative expansion Binary File > Descriptor library was created later on ... > > I would really, really hate if we'd use a different assembler and linker > than all the others Linux architectures. It would still leave us with > with a broken libbfd which various tools are linked against. The most > important one of these is GDB and GDB functionality on IRIX already > suffers a good bit from the brokenness of libbfd on MIPS. I just say > N32 and 64 ABIs. > > As mentioned before people at Cygnus have considered replacing GNU ld > years ago. Most important to drop everything but ELF support for a > ld replacement. With that happening and a new ld going into binutils > libbfd still wouldn't be eleminated. But large parts of it's > functionality could be eleminated, the complexity by reduced dramatically. > Result: only winners, at least among the ELF users. So after some > brain storming I think we should try to convince the other architectures > that GNU ld is really overdue to be replaced. Probbly little convincing > required. What we get is hopefully some linker that is maintainable for > us again. That makes some sense as a long term strategy, but do you really want to continue doing battle with binutils until a new loader comes along from Cygnus? I didn't think so. - leo > > Ralf > Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Sun Feb 27 14:32:55 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 14:32:45 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32330 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 14:32:19 -0800 Received: from sprasad.engr.sgi.com (sprasad.engr.sgi.com [163.154.5.109]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA09442; Sun, 27 Feb 2000 14:35:24 -0800 (PST) mail_from (sprasad@sprasad.engr.sgi.com) Received: (from sprasad@localhost) by sprasad.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id OAA12100; Sun, 27 Feb 2000 14:30:24 -0800 (PST) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200002272230.OAA12100@sprasad.engr.sgi.com> Subject: Re: mips64 boot To: ulfc@cthulhu.engr.sgi.com (Ulf Carlsson) Date: Sun, 27 Feb 2000 14:30:23 -0800 (PST) Cc: ralf@oss.sgi.com (Ralf Baechle), linux-origin@oss.sgi.com In-Reply-To: from "Ulf Carlsson" at Feb 26, 2000 02:20:46 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing According to Ulf Carlsson ... > > > The situation for userland is different and much more complex. GNU libc and > > other packages do heavily rely on GNU ld's features. Add that GNU ld is > > evolving. That makes using anything but GNU ld a no go for userspace. > > I was talking to Ralf earlier and I mentioned that I thought SGI was going to > use the MIPS Pro compiler to compile the Linux that will run on the IA-64 SN1 > machines. I really don't know what's happening with the MIPS Pro compiler > nowadays, I've only heard rumours from here and there. If the MIPS Pro > compiler is going to be used to compile Linux I assume that the GNU specific > features required to compile the GNU libc, such as symbol versioning, will be > added, and we can use the features for MIPS as well as IA-64. Does anyone > know whether the MIPS Pro compiler for IA-64 will be open sourced or not? I dont think symbol versioning etc will be added to the MIPS pro tool set. The version running on babylon.engr has lots of problems and we found it hard to even build the kernel. Forget MIPSpro for anything in linux. The way ia64 tools are structured is that most of the pieces are taken from the cygnus open source gcc. Just the optimization is sgi contribution. preprocessor, parser+intermediate codegen assembler loader linker for ia64 is gcc based. The MIPSpro type of optimization algorithms have been re-implemented for ia64. SGI intends to open source ia64 tools but current are waiting for a nod from Intel. Srinivasa > > Ulf > From owner-linux-origin@oss.sgi.com Sun Feb 27 14:50:15 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 14:50:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57674 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 14:49:44 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA06209; Sun, 27 Feb 2000 14:52:49 -0800 (PST) mail_from (ulfc@cthulhu.engr.sgi.com) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA88311; Sun, 27 Feb 2000 14:49:43 -0800 (PST) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA00900; Sun, 27 Feb 2000 14:48:12 -0800 (PST) mail_from (ulfc@engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 7167A105016; Sun, 27 Feb 2000 14:46:50 -0800 (PST) Date: Sun, 27 Feb 2000 14:46:50 -0800 (PST) From: Ulf Carlsson To: Srinivasa Prasad Thirumalachar Cc: Ralf Baechle , linux-origin@oss.sgi.com Subject: Re: mips64 boot In-Reply-To: <200002272230.OAA12100@sprasad.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > I dont think symbol versioning etc will be added to the MIPS pro tool set. > The version running on babylon.engr has lots of problems and we found it > hard to even build the kernel. Forget MIPSpro for anything in linux. I think we can drop my suggestion then. This really sucks. Thanks for letting us know, Srinivasa. Ulf From owner-linux-origin@oss.sgi.com Tue Feb 29 14:44:30 2000 Received: by oss.sgi.com id ; Tue, 29 Feb 2000 14:44:20 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:33355 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Feb 2000 14:44:06 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA20429 for ; Tue, 29 Feb 2000 14:39:32 -0800 (PST) mail_from (kanoj@google.engr.sgi.com) Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA16941 for ; Tue, 29 Feb 2000 14:43:34 -0800 (PST) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA44330 for linux-origin@oss.sgi.com; Tue, 29 Feb 2000 14:46:02 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200002292246.OAA44330@google.engr.sgi.com> Subject: compiler problem To: linux-origin@oss.sgi.com Date: Tue, 29 Feb 2000 14:46:02 -0800 (PST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing In arch/ia64/kernel/linux32.c, I added in some piece of code that _should_ look like this: static int nargs(unsigned int arg, char **ap) { char *ptr; int n, err; n = 0; do { if ((err = get_user(ptr, (int *)arg))) return(err); if (ap) *ap++ = ptr; arg += sizeof(unsigned int); n++; } while(ptr); return(n - 1); } Unfortunately,compile fails with this code, so I had to check in: static int nargs(unsigned int arg, char **ap) { char *ptr; int n, err; n = 0; for (; ptr; ) { do { if ((err = get_user(ptr, (int *)arg))) return(err); if (ap) *ap++ = ptr; arg += sizeof(unsigned int); n++; } return(n - 1); } Unfortunately, this does not work all the time, since the variable "ptr" is not initialized. If I do initialize it, I get the same compilation problem. This is either a problem with the definition of get_user(), or the compiler itself. If any one has time to look, and get anywhere with it, let me know ... Kanoj From owner-linux-origin@oss.sgi.com Tue Feb 29 15:38:10 2000 Received: by oss.sgi.com id ; Tue, 29 Feb 2000 15:38:01 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:3800 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 29 Feb 2000 15:37:45 -0800 Received: from cacc-5.uni-koblenz.de (cacc-5.uni-koblenz.de [141.26.131.5]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA12743; Wed, 1 Mar 2000 00:37:41 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Tue, 29 Feb 2000 23:54:15 +0100 Date: Tue, 29 Feb 2000 23:54:15 +0100 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: compiler problem Message-ID: <20000229235414.E1585@uni-koblenz.de> References: <200002292246.OAA44330@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200002292246.OAA44330@google.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Feb 29, 2000 at 02:46:02PM -0800, Kanoj Sarcar wrote: > In arch/ia64/kernel/linux32.c, I added in some piece of code that > _should_ look like this: [...] Is this part of the binary compatibility execve(2) syscall? I wasted a lot of time because our MIPS compiler did die on my execve(2) compat syscall. Ralf From owner-linux-origin@oss.sgi.com Tue Feb 29 15:43:21 2000 Received: by oss.sgi.com id ; Tue, 29 Feb 2000 15:43:10 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1601 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 29 Feb 2000 15:42:58 -0800 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA04505; Tue, 29 Feb 2000 15:46:06 -0800 (PST) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA80931; Tue, 29 Feb 2000 15:46:41 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200002292346.PAA80931@google.engr.sgi.com> Subject: Re: compiler problem To: ralf@oss.sgi.com (Ralf Baechle) Date: Tue, 29 Feb 2000 15:46:41 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000229235414.E1585@uni-koblenz.de> from "Ralf Baechle" at Feb 29, 2000 11:54:15 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > On Tue, Feb 29, 2000 at 02:46:02PM -0800, Kanoj Sarcar wrote: > > > In arch/ia64/kernel/linux32.c, I added in some piece of code that > > _should_ look like this: > > [...] > > Is this part of the binary compatibility execve(2) syscall? I wasted a lot > of time because our MIPS compiler did die on my execve(2) compat syscall. > > Ralf > Yes, this is so that 32 bit execs go to sys32_execve, instead of sys_execve. The reason being that the argv[]/envp[] has to be copied specially, since these entries are only 32bit large for mips32. Kanoj From owner-linux-origin@oss.sgi.com Tue Feb 29 17:20:41 2000 Received: by oss.sgi.com id ; Tue, 29 Feb 2000 17:20:32 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:13559 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 29 Feb 2000 17:20:29 -0800 Received: from cacc-5.uni-koblenz.de (cacc-5.uni-koblenz.de [141.26.131.5]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA18313; Wed, 1 Mar 2000 02:20:25 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 1 Mar 2000 00:46:06 +0100 Date: Wed, 1 Mar 2000 00:46:06 +0100 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: compiler problem Message-ID: <20000301004606.G1585@uni-koblenz.de> References: <20000229235414.E1585@uni-koblenz.de> <200002292346.PAA80931@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200002292346.PAA80931@google.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Feb 29, 2000 at 03:46:41PM -0800, Kanoj Sarcar wrote: > > Is this part of the binary compatibility execve(2) syscall? I wasted a lot > > of time because our MIPS compiler did die on my execve(2) compat syscall. > > Yes, this is so that 32 bit execs go to sys32_execve, instead of > sys_execve. The reason being that the argv[]/envp[] has to be > copied specially, since these entries are only 32bit large for > mips32. Ok, so it's what I already did observe in my kernel. I've got a workaround which seems to be stable but no fix for the compiler. Ralf