Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
So here we have an anonymous poster challenge a fairly big corporation in an open forum to make a "definative" (sic!) legal statement about a complex issue. How naive can anybody be? If he really wants to achieve any change, he definitely goes about it the wrong way. This open-loop bitching is unproductive and wasteful, not even entertaining. Mr Anonymous Toy just enjoys ranting, and will never stop. (See other threads) Let's ignore him, his position is at the far-out fringe. Enough said. Peter Alfke, speaking for himself.Article: 95901
So here we have an anonymous poster challenge a fairly big corporation in an open forum to make a "definative" (sic!) legal statement about a complex issue. How naive can anybody be? If he really wants to achieve any change, he definitely goes about it the wrong way. This open-loop bitching is unproductive and wasteful, not even entertaining. Mr Anonymous Toy just enjoys ranting, and will never stop. (See other threads) Let's ignore him, his position is at the far-out fringe. Enough said. Peter Alfke, speaking for himself.Article: 95902
Ok ... take this slowly ... Phil Tomson wrote: > But again, if the code I am distributing under GPL or BSD (or whatever open You put at the top of your ruby code, a GPL license. > source licnese) is only designed to deal with XDL, I really don't see the Then you include deriviative and licensed Xilinx information in that same file which are in DIRECT conflict with each other. The GPL license says that you can not restrict distributions, ans the Xilinx license says you must restrict distribution of Xilinx IP implictly disclosed by your ruby code which is legally a derived work from Xilinx Documentation, file formats, and other Xilinx IP. GPL is very strong, is does not allow co-mingling which reduces or restricts the GPL terms.Article: 95903
Jerry Coffin wrote: >... > In the end, however, you're right: a design certainly _can_ be screwed > up to the point that the only hope for it is to throw it away and start > over. > ... To quote from your former message, > Hmmm...did I somehow end up in the wrong newsgroup? I thought this was > comp.arch.fpga .... The number of things which can be done is probably infinite. However, programmability is a major feature of programmable devices - or at least I naively thought so until today :-). This posting is not meant to contradict your last message which says, if analyzed correctly, more or less the same. It is just meant to make the analysis easier :-). Cheers, Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 95904
Rick, Afraid not. Spartan folks are just not into reconfiguring, unless it is the whole bitstream. Seems they polled their customers, and even though they have shipped 10 million S3's to date, they see no need... So for S3, no. Don't know about Spartan 3E. Now in V4, partial is supported, and even partial while running is supported (sort of, but most would say that you have to be a pretty expert user to do it right now). The SDR developers are way ahead in this, and they pretty much have to have it working, so since V4 is the choice for SDR platforms, we are busy busy busy with the tools and support. AustinArticle: 95905
Kevin Morris wrote: > I'm finishing up an FPGA Journal article called "Stop. Go. Yield. - > Dude! Where's my Chip?" > > I'm looking for people that have had delivery problems with FPGAs - Good! I was worried that you might be a student looking for a Verilog design for a traffic light controller. :-)Article: 95906
Peter Alfke wrote: > So here we have an anonymous poster challenge a fairly big corporation > in an open forum to make a "definative" (sic!) legal statement about a > complex issue. > How naive can anybody be? > If he really wants to achieve any change, he definitely goes about it > the wrong way. > This open-loop bitching is unproductive and wasteful, not even > entertaining. > Mr Anonymous Toy just enjoys ranting, and will never stop. (See other > threads) > Let's ignore him, his position is at the far-out fringe. > Enough said. > Peter Alfke, speaking for himself. You know Peter ... I've tried very hard to avoid the very same unprofessional BS that you and other posters here frequently resort to in the form of direct personal attacks. Xilinx must be very very proud of that behavior, even if you try to hide behind the "speaking for himself." But unless you expecially like that form of abuse, it's best to cease it, as everyone will take note that is how to be pissy with you by example. As far as your anonymous rants, live with it. I've actually told everyone who I am, and it's not that difficult to figure it out, except for some of the most clueless here. Over half of the posters to this forum do not use their full legal names with company affiliation and addresses to clearly identify who they are, who they work for, and where they are located. The handles for GEO, dp, rickman, John H, Tim, and scores of others are equally annoymous, and perfectly acceptable by all usenet standards to post and particpate here -- and have been for the 25 years I've participated in usenet forums. So get used to it. Get a clue ... this has been a very productive discussion about the very restrictive Xilinx IP Licensing, and just how many of your customers do not have a clue about what Xilinx expects in protecting that IP. It's clear that even after this discussion, that the miss-information of a number of respected posters is likely to be remembered for a very long time. What went wrong with it was the failure to get clear and concise answers from Xilinx, which you seem mockingly proud of in your rant above. Especially since the Xilinx staff failed to be direct and clear about all the issues. When Xilinx staff are unable to clearly and definatively state that the Xilinx license clearly is incompatable with all accepted open sources licenses, then I think Xilinx Legal needs to set you guys down and have a long training session. When you mockingly are proud that Xilinx staff can not answer such a direct questions, then maybe Xilinx needs to consider more than just training issues. Certainly, mixing Xilinx IP with open source under BSD or GPL is strictly forbidden. Things like the JHDLBits problem occur as the direct lack of training and initiative on the part of Xilinx staffers to recognize and intervine early when a customer or intern gets off the path set by Xilinx Legal department. That is a Xilinx internal problem, that somebody really needs to fix. Your managment should be utterly ashamed that I have to press the issue and fend off dozens of clearly WRONG posts that XDL is an open interface and should be used for open source development. When Ray, and others, in this forum suggest that XDL can be mixed with open source it should be a Xilinx person stepping up and quickly correcting the matter to avoid another JHDLBits public relations blunder. This whole thread is a public relations blunder that clear concise posts from Xilinx staff could have stopped long ago by being open and direct. And you dare mock this when it's litterially your fault? If Xilinx can not articulate it's own legal policy clearly in forums like this, then Xilinx has a severe problem that it's legal department and board of directors need to address in regard to staffing responsibilities. It's totally and utterly clueless to hide behind ignorance regarding IP and licensing. I wonder just how many Xilinx developers lack the training to undersand what is LGPL and what is pure open source .... and how many Xilinx product files are contaminated with open sources. And how many of your 3rd party developers have Xilinx proprietary information comingled with open source? I wonder how many of your customers are writing XDL code using open source code segments and libraries that are not LGPL licensed? Do you even have a clue what this really means? If not, how do you expect to discuss this matter with your developers to make sure both Xilinx and open source license are not violated. The whole issue is a direct result of the systematic failure of Xilinx to openly and directly answer questions and provide full and complete information. That you dare to mock that, is utterly clueless. JohnArticle: 95907
bjzhangwn wrote: > I want to implement an ata controller in the fpga,the controller use > the ultra dma mode to read and write datas,and I want to know if it is > difficult to implement it.Can some one give me some advice. > check out the ATA core on <www.opencores.org> Regards, MarkArticle: 95908
Peter Alfke <peter@xilinx.com> wrote: > So here we have an anonymous poster challenge a fairly big corporation > in an open forum to make a "definative" (sic!) legal statement about a > complex issue. As far as I can tell, he's not so much `challenging' as explaining his position. He is afraid that he will get burned by legalities if he uses XDL, and explains the assurances that he needs. What's wrong with that? His position may sound paranoid, but considering the silly lawsuits that there have been in the past, I can't say I blame him. There is a reason that everyone here keeps claiming IANAL. Also, the JHDLBits affair seems to have scared him. His side of the story does sound scary. > How naive can anybody be? Perhaps he is naive, but building your software on assurances from people in an open forum, no matter how well-intentioned, is also bloody naive. Personally I think his fears about the license, apart from the `Xilinx only' clause, are unfounded, and I hope that when he calms down a bit he'll read the licenses again, and see that. His software does sound interesting. > If he really wants to achieve any change, he definitely goes about it > the wrong way. Well, with that I have to agree. He could make his point a little less forcefully, and be a lot more effective. His `giving back to the community' claim is also a bit extreme.Article: 95909
fpga_toys@yahoo.com wrote: > I've actually told > everyone who I am, and it's not that difficult to figure it out, I can't find any reference to you, so who are you then. EdArticle: 95910
In article <1138316309.314750.42980@o13g2000cwo.googlegroups.com>, <fpga_toys@yahoo.com> wrote: > >Take Phil's project for example. The base license for Ruby is GPL, >which >means that he will have to be very careful to keep Ruby and Ruby >libraries >completely separate from anything that contains IP from XDL. If he is >careful, he might even be able to do that. If he is not and ends up >with >a blended license derivative work, then one or both licenses are >violated. Actually, I think it would be difficult to get Ruby and it's libraries mixed up with the project code. The only way I can imagine that would happen is if we decided to embed Ruby into C code - I really don't forsee that. The scenario you describe is not only easy to avoid, it would be difficult to create. There's the Ruby interpreter (yes, it's GPL, but it's also dual licensed with a much more liberal license from Matz which says "do what ye will with it", but I digress) and libraries (mostly GPL, maybe some BSD depending on which you use). There's our project code which would happen to be written in Ruby (though, that's not written in stone at this point, maybe it would be C or Haskell...). The Ruby interpreter merely runs our Ruby code. There is no inclusion of the Ruby interpreter code (written in C) with our project code _unless_ we were to embed Ruby (and again, I really don't forsee doing that). The Ruby interpretter is a totally seperate entity that would just happen to run our code. >What is certain, is that he could never distribute the XDL portions >publicly >as open source, and would have to have a very long talk with Xilinx >Legal >and his own lawyer to carefully spell out distribution rights of the >derived >work. A C&D order is the least of your worries if there is a miss-step. >The >real fear is that they file for damages and legal costs, that literally >could >ruin the rest of your life since a Chapter 7 these days is harder to >get >without paying some or all your liabilities in such a judgement. > >I don't think it's personally worth the risk, expecially for an open >source >project. > The worst case scenario as I see it is that Xilinx changes their mind on XDL and decides they don't want 3rd party tools built around it. They send a C&D and the code is pulled. Yes, people would be upset, however, It doesn't seem to be something that would lead to a monetary judgement if the C&D is complied with. I don't believe that any of the JHDLBits people had legal judgements against them; have you heard differently? PhilArticle: 95911
Phil Tomson wrote: > In another thread we've been talking about creating some open source tools for > parsing and manipulating XDL. The motivation being that since bitstreams are > closed, working XDL might just be the next best thing. > > But then someone brought up the fate of JHDLBits: apparently the prjoject was > squashed by Xilinx. Does anyone have any details about what happened? If > someone succeeded in developing an open source ecosystem of tools built around > XDL, would that project also suffer the same fate? (It would be nice to know > before investing much time and effort in developing tools around XDL) As one of the four people who worked on JHDLBits, perhaps I can clear up some of the misconceptions in this thread. 1. JHDLBits was indeed intended to be an open-source project, based upon JBits as the bitstream interface. There was never any actual or attempted reverse-engineering, because JBits already gave us the necessary bitstream access. 2. The development team was pretty green, and though we came up with some interesting stuff, the project was not robust (lack of understanding of how and when to use exceptions, lack of understanding of how to use public, private, and protected access, ...). 3. There was never any effort on the part of Xilinx, legal or otherwise, to squash the project. We simply got to the end of the funding agreement, had two people graduate, and another one eventually switch departments. That left me, and I was only involved on the side because of my familiarity with JBits and related tools, but I was busy working on my own research with its own unrelated funding. 4. JHDLBits could still be a worthwhile open-source project, although it's completely inactive at present, and if somebody with decent software engineering skills feels like bringing it up to snuff, your contribution would likely be welcomed with open arms. NeilArticle: 95912
Symon wrote: > <allanherriman@hotmail.com> wrote in message > news:1138195695.581945.80890@g44g2000cwa.googlegroups.com... > >>P.S. how did you know it was a sunny day here? >> > > He's obviously been following the cricket now that Holland have qualified > for the world cup. It looks sunny at the SCG in the picture of Jayasuriya > after he hit a century! > http://news.bbc.co.uk/sport1/hi/cricket/4634280.stm You know, there's just not enough talk about cricket on comp.arch.fpga. Perhaps a new group - comp.arch.fpga.cricket? John (who travels past the 'Gabba every day on the way to work...)Article: 95913
Neil, Thank you for setting the record straight. I am sorry that John Lawrence Bass (aka 'toys') has slandered the relationship, and the work you did. I could not reveal the facts, as it would have violated your privacy and our agreeements with our research colleagues (which we respect). Austin Neil Steiner wrote: -snip- > As one of the four people who worked on JHDLBits, perhaps I can clear up > some of the misconceptions in this thread. > > 1. JHDLBits was indeed intended to be an open-source project, based upon > JBits as the bitstream interface. There was never any actual or > attempted reverse-engineering, because JBits already gave us the > necessary bitstream access. > > 2. The development team was pretty green, and though we came up with > some interesting stuff, the project was not robust (lack of > understanding of how and when to use exceptions, lack of understanding > of how to use public, private, and protected access, ...). > > 3. There was never any effort on the part of Xilinx, legal or otherwise, > to squash the project. We simply got to the end of the funding > agreement, had two people graduate, and another one eventually switch > departments. That left me, and I was only involved on the side because > of my familiarity with JBits and related tools, but I was busy working > on my own research with its own unrelated funding. > > 4. JHDLBits could still be a worthwhile open-source project, although > it's completely inactive at present, and if somebody with decent > software engineering skills feels like bringing it up to snuff, your > contribution would likely be welcomed with open arms.Article: 95914
In article <43D97452.9070103@vt.edu>, Neil Steiner <neil.steiner@vt.edu> wrote: >Phil Tomson wrote: >> In another thread we've been talking about creating some open source tools for >> parsing and manipulating XDL. The motivation being that since bitstreams are >> closed, working XDL might just be the next best thing. >> >> But then someone brought up the fate of JHDLBits: apparently the prjoject was >> squashed by Xilinx. Does anyone have any details about what happened? If >> someone succeeded in developing an open source ecosystem of tools built around >> XDL, would that project also suffer the same fate? (It would be nice to know >> before investing much time and effort in developing tools around XDL) > >As one of the four people who worked on JHDLBits, perhaps I can clear up >some of the misconceptions in this thread. > >1. JHDLBits was indeed intended to be an open-source project, based upon >JBits as the bitstream interface. There was never any actual or >attempted reverse-engineering, because JBits already gave us the >necessary bitstream access. > >2. The development team was pretty green, and though we came up with >some interesting stuff, the project was not robust (lack of >understanding of how and when to use exceptions, lack of understanding >of how to use public, private, and protected access, ...). > >3. There was never any effort on the part of Xilinx, legal or otherwise, >to squash the project. We simply got to the end of the funding >agreement, had two people graduate, and another one eventually switch >departments. That left me, and I was only involved on the side because >of my familiarity with JBits and related tools, but I was busy working >on my own research with its own unrelated funding. > >4. JHDLBits could still be a worthwhile open-source project, although >it's completely inactive at present, and if somebody with decent >software engineering skills feels like bringing it up to snuff, your >contribution would likely be welcomed with open arms. > >Neil Neil, Thanks for clearing this up. Is the source code available anywhere? PhilArticle: 95915
Phil Tomson wrote: > The worst case scenario as I see it is that Xilinx changes their mind on XDL > and decides they don't want 3rd party tools built around it. They send a C&D > and the code is pulled. Yes, people would be upset, however, It doesn't seem > to be something that would lead to a monetary judgement if the C&D is complied > with. I don't believe that any of the JHDLBits people had legal judgements > against them; have you heard differently? As I stated earlier I don't think that the XDL format has any protectable elements under US copyright law, but I am not a Lawyer. I also don't believe that Xilinx has any interest in keeping the format "closed" especially since the format is specific to Xilinx devices and it uses our naming conventions which would be very awkward to use for any non-Xilinx device. My earlier statement about "use for Xilinx only devices" was intended to reference the use of the NCD2XDL and XDL2NCD software that is included in ISE 8.1i which would be covered under the EULA. I believe that one of the other threads mentioned using our synthesizer (XST) to generate LUTs and then to take the output of this through XDL and then to a non-Xilinx device through some translator. This would be excluded by our EULA. However using FpgaC or Ruby (??) to generate an XDL netlist and then somehow getting this into a non-Xilinx device without using any ISE 8.1i software should be fine. If you are planning to use this in your project and want an official confirmation that we wouldn't pull the rug out from under you at a future date you should contact our legal department and ask them for a permission to do so. We'll probably want the usual "NO WARRANTY" stuff, but I highly doubt that it will be a problem and it should be taken care of in a short amount of time. Ed McGettigan -- Xilinx Inc.Article: 95916
I don't completely comprehend what you mean by back propogation. But yes, it is possible to get optimum probabilities for bits mapped to a constellation symbol. You would find results on that if you search for Bit Interleaved Coded Modulation, or BICM in short.Article: 95917
"Peter Alfke" <peter@xilinx.com> wrote in message news:1138303332.041604.64010@z14g2000cwz.googlegroups.com... > > Yaju Nagaonkar wrote: >>...> Anyways, the problem I am having is that I am not able to pull PROG_B >> low to reset the FPGA. The miroprocessor pin goes low but it is not >> able to pull the PROG_B low at all? >> > What do you really mean? > The output pin goes Low, but the PROG pin does not? What is between > these pins, more than a strip of copper? > Pewter Alfke, Xilinx > Pewter? Time to lay off the beer, Peter. BobArticle: 95918
Yeah, that's what I figured. Next time I'll get it in writing before I believe a promise about support. Hmmm... actually I did have it in writing if you count email. Austin Lesea wrote: > Rick, > > Afraid not. Spartan folks are just not into reconfiguring, unless it is > the whole bitstream. Seems they polled their customers, and even though > they have shipped 10 million S3's to date, they see no need... > > So for S3, no. > > Don't know about Spartan 3E. > > Now in V4, partial is supported, and even partial while running is > supported (sort of, but most would say that you have to be a pretty > expert user to do it right now). > > The SDR developers are way ahead in this, and they pretty much have to > have it working, so since V4 is the choice for SDR platforms, we are > busy busy busy with the tools and support. > > AustinArticle: 95919
Ed McGettigan wrote: > As I stated earlier I don't think that the XDL format has any > protectable elements under US copyright law, but I am not a Lawyer. > I also don't believe that Xilinx has any interest in keeping the > format "closed" especially since the format is specific to Xilinx > devices and it uses our naming conventions which would be very > awkward to use for any non-Xilinx device. > > My earlier statement about "use for Xilinx only devices" was intended to > reference the use of the NCD2XDL and XDL2NCD software that is included > in ISE 8.1i which would be covered under the EULA. I believe that one > of the other threads mentioned using our synthesizer (XST) to generate LUTs > and then to take the output of this through XDL and then to a non-Xilinx > device through some translator. This would be excluded by our EULA. > However > using FpgaC or Ruby (??) to generate an XDL netlist and then somehow > getting > this into a non-Xilinx device without using any ISE 8.1i software should be > fine. > > If you are planning to use this in your project and want an official > confirmation that we wouldn't pull the rug out from under you at > a future date you should contact our legal department and ask them > for a permission to do so. We'll probably want the usual "NO WARRANTY" > stuff, but I highly doubt that it will be a problem and it should be > taken care of in a short amount of time. > > Ed McGettigan > -- > Xilinx Inc. Thank you Ed for clearing this up. It is basically what I've been trying to say.Article: 95920
In the following I talk about german law, but AFAIK US law leads to similar conclusions. fpga_toys@yahoo.com schrieb: > Ed McGettigan wrote: > >>I believe that it is established copyright law that SW interface >>specs are not protectable elements although there appear to be >>some gray areas. Of course you can not distribute Xilinx software or IP libraries. Every user usign your tool would need to obtain his own copy if ISE. Apart from the copyright law does not matter at all. Trade secrets are the interesting part. Easy, if you only use information that is available from published sources. > Software copyrights yes, but Xilinx claims a business contract license > to protect IP in the release ... that is different law, and to violate > the license is breach of contract. So, do not buy it as a business. Have someone by a copy privately. (For example get the student edition from the bookstore). No you have all the consumer protection restrictions in place that limit what xilinx can state in an EULA. >>The XDL tool explicitly states that you are allowed to create tools >>that use the output of NCD2XDL or tools that create input for XDL2NCD. >>This use of course is restricted to use for Xilinx devices per the >>ISE 8.1i EULA. It is not possible to restrict the scope of usage of a product by a private customer. (principle of first sale, "Erschöpfungsgrundsatz") Imagine a car from a manufacturer that has an EULA that says you are not allowed to use it to drive to car dealers selling competitor models. You can use the xilinx tools in any way you like. But you are not allowed to distribute or modify them. > It is this "restricted to use for Xilinx devices" that violates every > open > source license, and which as a developer using BSD licenses that we > can not accept (nor does any other accepted open source license). Be > cause of this restriction, there is no forum where the software can be > released, as it's impossible to acertain that the recipient is also > bound > by the Xilinx license terms. Open source requires that no restrictions > be > placed on the distribution, other than governmental. You can have an open source tool that only works when certain closed sourced tools are present. I for example run Linux on a closed sourced processor and am even using closed source graphic board drivers. An of course you can create input files in the language that the closed source tool uses. (fair use, you must be allowed to do that to use the tool) > So read the EULA carefully, as the business contract language requires > that you protect the IP assets you aquire as part of the license ... as > they are trade secret and proprietary ... not public domain, and free to > distribute. I am not so sure about the IP. The core generator, yes. The libraries used to synthesize HDL, probably not. There were cases with high courts in the 80s about whether you need to pay royalties when using sound synthesizer or sampler sounds in music produced for profit. The courts clearly stated that it is the intended use of an instrument to produce music, an that you do not need to pay royalties. What Xilinx is trying to do is to say: "You do not need to pay royalties if you only playback your music with CD players of brand X" I do not believe that works out. All this reasoning does not apply to WebPack! When you give something away for free, you can impose almost any restrictions that you like. Kolja SulimmaArticle: 95921
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:43d951c0@clear.net.nz... > Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > >> Antti Lukats wrote: >> >> [... snip ...] >> >>>but if you can wait then the Spartan3e kit $149 USD includes also on >>>board >>>Platform USB Cable (sold standalone for $149!) as free bonus :) >> >> >> I just wanted to provide a little more information on this to make it >> completely clear about the USB cable supplied with the board. >> >> First, some backround. The Xilinx Platform USB Cable is a >> self-contained USB-based programming cable that provides in-system >> programming for a variety of Xilinx devices. >> http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-USB >> >> The Spartan-3E Starter Kit Board includes a standard A-B USB cable. >> The cable connects your computer's USB port to the USB slave port on >> the board to program the Spartan-3E FPGA, the Platform Flash PROM, or >> the on-board CPLDs. Think of it as an "embedded", single-target >> version of the Xilinx USB download cable. It is not designed to >> program devices that are not already on the board. > > So there is no header that allows the few PGM wires, to be taken > off-board, to another FPGA/CPLD ? > Silly question then : why not ? > > -jg > answer: marketing but it should be easy to fix, the Cypress chip is not an BGA so all the PGM wires can be trapped on the topside of the PCB -- Antti Lukats http://www.xilant.comArticle: 95922
"Göran Bilski" <goran.bilski@xilinx.com> wrote in message news:drbaoh$nsr4@cliff.xsj.xilinx.com... > Marco T. wrote: >> Hallo, >> I would insert multichannel opb sdram controller into a project. >> >> I would use xcl bus to access read/write datas into a integer matrix. >> >> I would know if every time I would perform read/write operations into a >> element of the matrix I need to: >> >> 1) disable data cache >> 2) init cache with address of matrix element >> 3) enable cache >> >> Is it correct? >> >> Following that the system copy the region of sdram into bram cache to >> perform operations on it? >> >> Many Thanks >> Marco > > Hi Marco, > > If your matrix is stored in the sdram, you don't need to disable the cache > to read/write the contents of the matrix. > > The accesses on the xcl bus is only read cachemiss cacheline fills and > write through address/data. It's not a general bus for doing a fetch of a > whole matrix. > > Göran Bilski I have connected to opb some peripheral which have high throughput. I would use xcl channel to avoid a bottleneck into opb bus. So, if I have understood, cache is a transparent bus. To read or write into cached sdam I don't need "special" functions, only perform normal operations like a=b, then the system verify if the location of a is into cached sdram. If yes, the system uses xcl chnnel. Is it correct?Article: 95923
Hello,
thanks for the excellent hint!
Later on that day, I tried a linux kernel without smp and the same
problem occurred. So multi-processors did not seem to be part of the
problem. That also brought me back to networking issues, since I heard
about 7.1 needing correct hostname and so on. But I couldn't figure it
out until I read your hint.
So I tried "strace -f ise". When the splash screen is over, I get never
ending loops of the following messages (it might not be cut at the
right part of the message...)
[pid 22097] close(7) = 0
[pid 22097] getpid() = 22097
[pid 22097] open("/etc/hostid", O_RDONLY) = -1 ENOENT (No such file or
directory)
[pid 22097] open("/etc/hostid", O_RDONLY) = -1 ENOENT (No such file or
directory)
[pid 22097] uname({sys="Linux", node="lmesim121", ...}) = 0
[pid 22097] socket(PF_FILE, SOCK_STREAM, 0) = 7
[pid 22097] connect(7, {sa_family=AF_FILE,
path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or
directory)
[pid 22097] close(7) = 0
[pid 22097] open("/etc/hosts", O_RDONLY) = 7
[pid 22097] fcntl(7, F_GETFD) = 0
[pid 22097] fcntl(7, F_SETFD, FD_CLOEXEC) = 0
[pid 22097] fstat(7, {st_mode=S_IFREG|0644, st_size=349, ...}) = 0
[pid 22097] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a97390000
[pid 22097] read(7, "# Do not remove the following li"..., 4096) = 349
[pid 22097] read(7, "", 4096) = 0
[pid 22097] close(7) = 0
[pid 22097] munmap(0x2a97390000, 4096) = 0
[pid 22097] socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
[pid 22097] connect(7, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.122.0.1")}, 28) = 0
[pid 22097] fcntl(7, F_GETFL) = 0x2 (flags O_RDWR)
[pid 22097] fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 22097] poll([{fd=7, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
[pid 22097] sendto(7,
"V\374\1\0\0\1\0\0\0\0\0\0\tlmesim121\5ikoop\6pri"..., 40, 0, NULL, 0)
= 40
[pid 22097] poll([{fd=7, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
[pid 22097] ioctl(7, FIONREAD, [197]) = 0
[pid 22097] recvfrom(7,
"V\374\205\200\0\1\0\1\0\4\0\3\tlmesim121\5ikoop\6pri"..., 1024, 0,
{sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.122.0.1")}, [16]) = 197
"ikoop.privat" is the domainname and the computer is in the
10.122.182.x subnet. So although I do not have a clue, what's going on,
I see that it seems to hang with networking issues. Probably "name
resolution" as you mentioned.
However, something must have changed in version 8, since 7 was running
fine.
I set hostname and domainname and the /etc/hosts with no success. My
Linux knowledge is at its end, can anybody help me, please?
Thanks a lot, Joachim
Article: 95924"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag news:drbp92$nh99@cliff.xsj.xilinx.com... > fpga_toys@yahoo.com wrote: >> I've actually told >> everyone who I am, and it's not that difficult to figure it out, > > I can't find any reference to you, so who are you then. > > Ed Ed, you are right he hasnt told that, he actually told to me that I should get used to people (like he) hiding its identify. but if I am not mistaken then his name is: John Bass -- Antti Lukats http://www.xilant.com
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z