From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Hammad Qureshi" Subject: Query Date: Wed, 6 Mar 2002 14:46:14 +0500 Message-ID: <00e601c1c508$c59ff7d0$0f01a8c0@RABTAGUI8> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C1C51D.AAA2BD40" Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C1C51D.AAA2BD40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello !!! All the nice people out there.... I am new on the list and I need some queries answered here about the = ALSA. I am trying to develop an application that can record multiple channels = i.e. about 8. I have looked into a few API's but have not found anything = promising. I have a card that can record 8 channels. I need help here.=20 I also want to know of a good site where I can get some documentation on = ALSA. Please reply to this mail... Hammad. ------=_NextPart_000_0025_01C1C51D.AAA2BD40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello !!! All the nice people out=20 there....

I am new on the list and I need some = queries=20 answered here about the ALSA.

I am trying to develop an application = that can=20 record multiple channels i.e. about 8. I have looked into a few API's = but have=20 not found anything promising. I have a card that can record 8 channels. = I need=20 help here.

I also want to know of a good site = where I can get=20 some documentation on ALSA.

Please reply to this = mail...

Hammad.

------=_NextPart_000_0025_01C1C51D.AAA2BD40-- _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Davis Subject: Re: Query Date: Wed, 06 Mar 2002 03:07:53 -0500 Message-ID: <200203061307.IAA15505@renoir.op.net> In-reply-to: Your message of "Wed, 06 Mar 2002 14:46:14 +0500." <00e601c1c508$c59ff7d0$0f01a8c0@RABTAGUI8> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Hammad Qureshi Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 1) just a quick note to point out that whether you know it or not, the email program you are using is sending out copies of your mail in both plain text and HTML formats. increasingly on the net, there are filters being put in place that silently dump HTML-formatted email. some mailing lists will not ever accept such posts. as long as you do this, you are (1) wasting network bandwidth by sending messages that are typically more than twice as long as they could be (2) making it harder for people using traditional email readers to read them (3) risking the chance that people will never see your mail because its filtered before reaching their email inbox. >I am new on the list and I need some queries answered here about the = >ALSA. > >I am trying to develop an application that can record multiple channels = >i.e. about 8. I have looked into a few API's but have not found anything = >promising. I have a card that can record 8 channels. I need help here.=20 see http://ardour.sf.net/ alternatively, check out ecasound at http://www.eca.cx >I also want to know of a good site where I can get some documentation on = >ALSA. There are none at this time. --p _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: snmp snmp Subject: Query Date: Wed, 16 Mar 2011 15:06:35 +0530 Message-ID: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=JhCjwJK+0F5ldEH86y9mFZlMDRMD1QzmNcWVj2MT/k4=; b=fpBboG3j1OZ0qxy6fV+pODX/sfZEJae0cp31z1GPXXW/IobgFq0kiEZhhz10fRl1N4 9bJP7xV5QY+GDJ1cWaF/eatKvx3cLMyZKW/cX5di1zlhRMa3rv/VNHpVv9D/q2nsfVF/ qWA4PS5KZYkUvHoj0S04wyZ1ffvF2VNOR5VdA= Sender: linux-numa-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-numa@vger.kernel.org Hi , Me and my friends are working on a new concept. Idea is to run different kernels on different cores in a multicore architecture. Each kernel is performing logically different tasks. We believe to improve the cache performance and reduce cpu idle time. This concept can be applied to filers , graphics processing systems , embedded systems. Our implementation is on Intel core 2 duo machine. So far our implementation includes running two kernels simultaneously (one on each core) , handling hard-disk on one core and ethernet on another core so as to divide the network and disk subsystem. But here we are unable to measure the performance. Can u please suggest any method to measure the performance in terms of throughput and response time? Thank you. From mboxrd@z Thu Jan 1 00:00:00 1970 From: snmp snmp Subject: Re: Query Date: Thu, 17 Mar 2011 14:43:08 +0530 Message-ID: References: Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qgvH629vZPu6F5vAi7AYRY6QPTTwUpUrA0BfKQso1O4=; b=G5wM2F8nQjGnUVMFTfoXsLewldLFckmM/oyVyXhkoleF4vP4/d2fjx4CemGc3WPwx1 Ocsnn+uhQ0kmPHvtBBqNGfJaFr5saMVtWlD05PEk1uBG26onrrHV5crXpT7gPUKdBEOP bWp16JC15YArP136c0BsGwqeexSo9FGMgpAdg= In-Reply-To: Sender: linux-numa-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="iso-8859-1" To: Tharindu Rukshan Bamunuarachchi Cc: linux-numa@vger.kernel.org Thanks for replying... We are implementing it on a 2 core machine so we have two kernels running...we have made changes in the grub code to load second kernel image in memory and send start-up Inter Processor Interrupts to second core and wake it from halted state...second core starts executing second kernel code..and first kernel starts running on first core after grub is done with it's operations. We have made changes in kernel code to initialize different subsystems on the two kernels. This includes changing the way in which interrupts are routed and also changing the listing of PCI devices. We have reserved memory for both kernels and some memory is shared for inter-kernel communication. On Thu, Mar 17, 2011 at 6:41 AM, Tharindu Rukshan Bamunuarachchi wrote: > interesting idea ... how do you run multiple kernels in different cor= es ? > > u should hv changed most of kernel code. > __ > Tharindu "R" Bamunuarachchi. > > > > > On Wed, Mar 16, 2011 at 3:06 PM, snmp snmp wrote: >> Hi , >> =A0 =A0 Me and my friends are working on a new concept. >> =A0 =A0 Idea is to run different kernels on different cores in a >> multicore architecture. Each kernel is performing logically differen= t >> tasks. We believe to improve the cache performance and reduce cpu id= le >> time. This concept can be applied to filers , graphics processing >> systems , embedded systems. >> =A0 =A0 Our implementation is on Intel core 2 duo machine. So far ou= r >> implementation includes running two kernels simultaneously (one on >> each core) , handling hard-disk on one core and ethernet on another >> core so as to divide the network and disk subsystem. >> >> =A0 =A0 But here we are unable to measure the performance. Can u ple= ase >> suggest any method to measure the performance in terms of throughput >> and response time? >> >> =A0 =A0 Thank you. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-numa= " in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >> > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from beta.dmz-eu.st.com ([164.129.1.35]) by canuck.infradead.org with esmtp (Exim 4.33 #1 (Red Hat Linux)) id 1BdqWS-0000zi-5N for linux-mtd@lists.infradead.org; Fri, 25 Jun 2004 09:13:40 -0400 Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 153ABDD34 for ; Fri, 25 Jun 2004 13:13:38 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2A7E612303 for ; Fri, 25 Jun 2004 13:13:37 +0000 (UTC) Received: from mail2.dlh.st.com (mail2.dlh.st.com [138.198.194.103]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 412B6F2A5 for ; Fri, 25 Jun 2004 13:13:35 +0000 (GMT) From: Manish RATHI To: Date: Fri, 25 Jun 2004 18:43:34 +0530 Message-ID: <000101c45ab6$37efd9f0$7c04b40a@dlh.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: query List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, I am newbee in linux. i've to write a nand flash driver for a Soc which is using ARM as core = so that soc can boot from nand flash rather than ram based file = system(initrd). i need to write a nand flash driver. As far as i understand nand driver = will be layer interacting with nand fLASH. Above it there will be mtd layer and above it there will be file system. Mtd layer is already available in linux. Can somebody suggest me good = literature to understand it and nand based flash driver.? I'd like to know how will be flow from user application to layer. Will these primitives be same like open, close, read, write, lseek, ioctl or some additional will be needed. will boot block be in flash? Does kernel read by flash using open and = write? Pls also tell me relevant information sites. Thanks Regards Manish From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from web13205.mail.yahoo.com ([216.136.174.190]) by canuck.infradead.org with smtp (Exim 4.42 #1 (Red Hat Linux)) id 1CgioT-0006wG-FW for linux-mtd@lists.infradead.org; Tue, 21 Dec 2004 07:08:27 -0500 Message-ID: <20041221120823.80642.qmail@web13205.mail.yahoo.com> Date: Tue, 21 Dec 2004 04:08:23 -0800 (PST) From: Rudresh NB To: linux-mtd@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Query List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi All, Iam using samsung Nand flash (k9f2g08u0m). In that there is restriction of random page program. I heard that jffs2 takes care. but iam unable to find where exactly (In which file ) it is taken care. Brief explanation is appreciated. Thanx in advance Rgds NBR __________________________________ Do you Yahoo!? All your favorites on one personal page – Try My Yahoo! http://my.yahoo.com From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 21 Dec 2004 12:19:01 +0000 (GMT) From: "Artem B. Bityuckiy" To: Rudresh NB In-Reply-To: <20041221120823.80642.qmail@web13205.mail.yahoo.com> Message-ID: References: <20041221120823.80642.qmail@web13205.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: Artem Bityuckiy Cc: linux-mtd@lists.infradead.org Subject: Re: Query List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 21 Dec 2004, Rudresh NB wrote: > Hi All, > Iam using samsung Nand flash (k9f2g08u0m). In > that there is restriction of random page program. I > heard that jffs2 takes care. but iam unable to find > where exactly (In which file ) it is taken care.=20 > Brief explanation is appreciated. >=20 > Thanx in advance Hi. JFFS2 uses a buffer (wbuf) of size =3D NAND page size and accomulates all= =20 the writes there. When the buffer become full, it flushes it to the=20 correspondent NAND page. See wbuf.c. =20 > Rgds > NBR >=20 >=20 >=20 > =09=09 > __________________________________=20 > Do you Yahoo!?=20 > All your favorites on one personal page =96 Try My Yahoo! > http://my.yahoo.com=20 >=20 > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ >=20 -- Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fra-del-01.spheriq.net ([195.46.51.97]) by canuck.infradead.org with esmtps (Exim 4.42 #1 (Red Hat Linux)) id 1CgjLo-0007wQ-Vw for linux-mtd@lists.infradead.org; Tue, 21 Dec 2004 07:42:55 -0500 Received: from fra-inc-06.spheriq.net (fra-inc-06.spheriq.net [195.46.51.70]) by fra-del-01.spheriq.net with ESMTP id iBLCgoUV019402 for ; Tue, 21 Dec 2004 12:42:50 GMT Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-inc-06.spheriq.net with ESMTP id iBLCgous020996 for ; Tue, 21 Dec 2004 12:42:50 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-02.spheriq.net with ESMTP id iBLCgnXb029497 for ; Tue, 21 Dec 2004 12:42:49 GMT Sender: Estelle HAMMACHE Message-ID: <41C81A43.C8E52F8@st.com> Date: Tue, 21 Dec 2004 13:42:43 +0100 From: Estelle HAMMACHE MIME-Version: 1.0 To: Rudresh NB References: <20041221120823.80642.qmail@web13205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-mtd@lists.infradead.org Subject: Re: Query List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, JFFS2 write pages sequentially from the start of an erase block to the end of the block. The current write block is in c->nextblock. The current write offset in this block is c->nextblock->offset. There is a write buffer (see file wbuf.c) to ensure that only full pages are written, even though data nodes may overlap a page boundary. Data nodes may not overlap an erase block boundary: if there is no more room in the current block, a new (empty) block is selected (and the page buffer is flushed in the old block previously to writing to the new block). The new block selection and the write address selection happen in nodemgmt.c (jffs2_do_reserve_space). Does this answer your question ? Estelle Rudresh NB wrote: > > Hi All, > Iam using samsung Nand flash (k9f2g08u0m). In > that there is restriction of random page program. I > heard that jffs2 takes care. but iam unable to find > where exactly (In which file ) it is taken care. > Brief explanation is appreciated. > > Thanx in advance > > Rgds > NBR From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from web13202.mail.yahoo.com ([216.136.174.187]) by canuck.infradead.org with smtp (Exim 4.42 #1 (Red Hat Linux)) id 1Ch2RT-000550-6I for linux-mtd@lists.infradead.org; Wed, 22 Dec 2004 04:06:22 -0500 Message-ID: <20041222090557.21188.qmail@web13202.mail.yahoo.com> Date: Wed, 22 Dec 2004 01:05:57 -0800 (PST) From: Rudresh NB To: Estelle HAMMACHE In-Reply-To: <41C81A43.C8E52F8@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-mtd@lists.infradead.org Subject: Re: Query List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, Thanx for the reply. I have couple of questions. 1) How JFFS2 will take care of Updating the same page in the block. 2) How does the logical addr to physical addr of block no happens Rgds NBR --- Estelle HAMMACHE wrote: > Hi, > JFFS2 write pages sequentially from the start of an > erase > block to the end of the block. The current > write block is in c->nextblock. The current write > offset > in this block is c->nextblock->offset. > There is a write buffer (see file wbuf.c) to ensure > that > only full pages are written, even though data nodes > may > overlap a page boundary. > Data nodes may not overlap an erase block boundary: > if there > is no more room in the current block, a new (empty) > block > is selected (and the page buffer is flushed in the > old block > previously to writing to the new block). The new > block > selection and the write address selection happen in > nodemgmt.c (jffs2_do_reserve_space). > Does this answer your question ? > Estelle > > Rudresh NB wrote: > > > > Hi All, > > Iam using samsung Nand flash (k9f2g08u0m). > In > > that there is restriction of random page program. > I > > heard that jffs2 takes care. but iam unable to > find > > where exactly (In which file ) it is taken care. > > Brief explanation is appreciated. > > > > Thanx in advance > > > > Rgds > > NBR > __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lon-del-03.spheriq.net ([195.46.50.99]) by canuck.infradead.org with esmtps (Exim 4.42 #1 (Red Hat Linux)) id 1Ch2lC-0005KG-Tg for linux-mtd@lists.infradead.org; Wed, 22 Dec 2004 04:26:26 -0500 Received: from lon-inc-01.spheriq.net ([195.46.50.65]) by lon-del-03.spheriq.net with ESMTP id iBM9QJo9016797 for ; Wed, 22 Dec 2004 09:26:19 GMT Received: from lon-out-01.spheriq.net (lon-out-01.spheriq.net [195.46.50.129]) by lon-inc-01.spheriq.net with ESMTP id iBM9QJVo008882 for ; Wed, 22 Dec 2004 09:26:19 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-01.spheriq.net with ESMTP id iBM9QKLX019640 for ; Wed, 22 Dec 2004 09:26:20 GMT Sender: Estelle HAMMACHE Message-ID: <41C93DB6.16162C19@st.com> Date: Wed, 22 Dec 2004 10:26:14 +0100 From: Estelle HAMMACHE MIME-Version: 1.0 To: Rudresh NB References: <20041222090557.21188.qmail@web13202.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-mtd@lists.infradead.org Subject: Re: Query List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Rudresh NB wrote: > > Hi, > Thanx for the reply. > > I have couple of questions. > > 1) How JFFS2 will take care of Updating the same page > in the block. JFFS2 will not _update_ a NAND Flash page. When the user overwrites a file with new data, JFFS2 will NOT update the previous data. Rather JFFS2 will write the new data at another free place, increasing the version number. The old data which is not needed anymore will disappear during garbage collection. JFFS2 does not write twice to the same physical page, unless the block was erased in the meantime. I suggest that you read http://sources.redhat.com/jffs2/jffs2.pdf if you haven't already. > 2) How does the logical addr to physical addr of block > no happens JFFS2 is NOT an FTL. There are no logical block numbers in JFFS2. I think the block adresses are relative to the start of the partition, this is managed in mtd drivers (?). bye Estelle > --- Estelle Hammache wrote: > > > Hi, > > JFFS2 write pages sequentially from the start of an > > erase > > block to the end of the block. The current > > write block is in c->nextblock. The current write > > offset > > in this block is c->nextblock->offset. > > There is a write buffer (see file wbuf.c) to ensure > > that > > only full pages are written, even though data nodes > > may > > overlap a page boundary. > > Data nodes may not overlap an erase block boundary: > > if there > > is no more room in the current block, a new (empty) > > block > > is selected (and the page buffer is flushed in the > > old block > > previously to writing to the new block). The new > > block > > selection and the write address selection happen in > > nodemgmt.c (jffs2_do_reserve_space). > > Does this answer your question ? > > Estelle > > > > Rudresh NB wrote: > > > > > > Hi All, > > > Iam using samsung Nand flash (k9f2g08u0m). > > In > > > that there is restriction of random page program. > > I > > > heard that jffs2 takes care. but iam unable to > > find > > > where exactly (In which file ) it is taken care. > > > Brief explanation is appreciated. > > > > > > Thanx in advance > > > > > > Rgds > > > NBR From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sundareswar Jayakumar" Subject: query Date: Tue, 21 Oct 2003 16:39:36 +0530 Sender: nfs-admin@lists.sourceforge.net Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 1ABz3Q-0003yH-00 for ; Tue, 21 Oct 2003 09:08:16 -0700 Received: from cdacb.ernet.in ([202.141.63.1]) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.22) id 1ABuPY-0001DP-48 for nfs@lists.sourceforge.net; Tue, 21 Oct 2003 04:10:48 -0700 Received: from sundar (sundar.ctsf.cdac.org.in [192.168.60.102]) by cdacb.ernet.in (8.12.9/8.12.9) with SMTP id h9LGo8sO018205 for ; Tue, 21 Oct 2003 16:50:08 GMT To: Errors-To: nfs-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Unsubscribe: , List-Archive: Hi, I am working on adistributed filesytem on linux.I am using nfs source code as a learning resource.I require a clarification. In many entry points the Big Kernel Lock lock/unlock_kernel is used instead of locking just the private data structures of the filesystem.why is it so?.kindly clarify w.r.t to a smp m/c. Thanks sundar ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: query Date: 22 Oct 2003 09:45:47 -0500 Sender: nfs-admin@lists.sourceforge.net Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 1ACM9v-0000FU-00 for ; Wed, 22 Oct 2003 09:48:31 -0700 Received: from pat.uio.no ([129.240.130.16] ident=7411) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.22) id 1ACKIF-0005Np-3d for nfs@lists.sourceforge.net; Wed, 22 Oct 2003 07:48:59 -0700 To: "Sundareswar Jayakumar" In-Reply-To: Errors-To: nfs-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Unsubscribe: , List-Archive: >>>>> " " == Sundareswar Jayakumar writes: > Hi, > I am working on adistributed filesytem on linux.I am using > nfs source code as a learning resource.I require a > clarification. > In many entry points the Big Kernel Lock lock/unlock_kernel is > used instead of locking just the private data structures of the > filesystem.why is it so?.kindly clarify w.r.t to a smp m/c. When working on performance, you pursue the largest sources of latency first... BKL contention has not yet turned up on the radar screen. There has therefore not yet been enough incentive to replace it as a mechanism for serialization. Cheers, Trond ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: query Date: Wed, 22 Oct 2003 12:53:27 +1000 Sender: nfs-admin@lists.sourceforge.net Message-ID: <16277.61735.731705.976287@notabene.cse.unsw.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 1ACSls-0000ek-00 for ; Wed, 22 Oct 2003 16:52:09 -0700 Received: from panoramix.vasoftware.com ([198.186.202.147] helo=externalmx.vasoftware.com ident=mail) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.22) id 1ACRx0-0004un-VK for nfs@lists.sourceforge.net; Wed, 22 Oct 2003 15:59:35 -0700 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24]:59232) by externalmx.vasoftware.com with smtp (Exim 4.22 #1 (Debian)) id 1AC9mE-0005nK-Mn for ; Tue, 21 Oct 2003 20:35:14 -0700 Received: From notabene ([129.94.211.194] == dulcimer.orchestra.cse.unsw.EDU.AU) (for ) (for ) By note With Smtp ; Wed, 22 Oct 2003 12:53:31 +1000 To: "Sundareswar Jayakumar" In-Reply-To: message from Sundareswar Jayakumar on Tuesday October 21 Errors-To: nfs-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Unsubscribe: , List-Archive: On Tuesday October 21, sundar@cdacb.ernet.in wrote: > Hi, > I am working on adistributed filesytem on linux.I am using > nfs source code as a learning resource.I require a clarification. > > > In many entry points the Big Kernel Lock lock/unlock_kernel is > used instead of locking just the private data structures of the > filesystem.why is it so?.kindly clarify w.r.t to a smp m/c. Because tghe BKL was the easiest way to make it work under SMP, and the process of refining the locks hasn't made it into 2.4. The 2.6.0 kernel does not use the BKL for nfsd at all, and I have patches that remove the BKL for 2.4 but marcelo didn't want them when I offered them some months ago, and I haven't offered again since. NeilBrown > > Thanks > sundar > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > NFS maillist - NFS@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Lever, Charles" Subject: RE: query Date: Thu, 23 Oct 2003 06:56:38 -0700 Sender: nfs-admin@lists.sourceforge.net Message-ID: <482A3FA0050D21419C269D13989C6113127F5F@lavender-fe.eng.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: , "Trond Myklebust" Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian)) id 1ADJft-0008Vt-00 for ; Sat, 25 Oct 2003 01:21:30 -0700 Received: from mx01.netapp.com ([198.95.226.53]) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.22) id 1ACfzp-0007Lc-7w for nfs@lists.sourceforge.net; Thu, 23 Oct 2003 06:59:25 -0700 To: "Sundareswar Jayakumar" Errors-To: nfs-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Unsubscribe: , List-Archive: hi- what trond says is true, and i'd like to supplement that idea by saying that the types of workloads where the BKL would be a bottleneck are rare these days, compared to the problems more common workloads experience, so it has been a lower priority. i think as database on NFS becomes more popular, for example, this issue will become more important. > -----Original Message----- > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > Sent: Wednesday, October 22, 2003 9:46 AM > To: Sundareswar Jayakumar > Cc: nfs@lists.sourceforge.net > Subject: Re: [NFS] query >=20 >=20 > >>>>> " " =3D=3D Sundareswar Jayakumar writes: >=20 > > Hi, > > I am working on adistributed filesytem on=20 > linux.I am using > > nfs source code as a learning resource.I require a > > clarification. >=20 >=20 > > In many entry points the Big Kernel Lock lock/unlock_kernel is > > used instead of locking just the private data structures of the > > filesystem.why is it so?.kindly clarify w.r.t to a smp m/c. >=20 > When working on performance, you pursue the largest sources of latency > first... > BKL contention has not yet turned up on the radar screen. There has > therefore not yet been enough incentive to replace it as a mechanism > for serialization. >=20 > Cheers, > Trond >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance=20 > to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > NFS maillist - NFS@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs >=20 ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chandrashekhar" Subject: query Date: Tue, 9 May 2006 16:36:09 +0530 Message-ID: <200605091106.k49B67in017337@IPDMBG0043ATL2.usa.prod.interland.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C67386.AF2AFDC0" Return-path: Received: from [10.3.1.94] (helo=sc8-sf-list2-new.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1FdQ2n-0003ej-6b for nfs@lists.sourceforge.net; Tue, 09 May 2006 04:06:21 -0700 Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1FdQ2n-0006c7-3B for nfs@lists.sourceforge.net; Tue, 09 May 2006 04:06:21 -0700 Received: from ftp.einfochips.com ([66.223.16.207] helo=IPDMBG0043ATL2.usa.prod.interland.net ident=[U2FsdGVkX1+JPL69rw/+9xwqTYNWk0zbmdK9NKFMonA=]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1FdQ2j-0006ig-PS for nfs@lists.sourceforge.net; Tue, 09 May 2006 04:06:21 -0700 Received: from SHEKHARK ([59.163.66.163]) (authenticated bits=0) by IPDMBG0043ATL2.usa.prod.interland.net (8.12.11.20060308/8.12.11) with ESMTP id k49B67in017337 for ; Tue, 9 May 2006 07:06:09 -0400 To: Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C67386.AF2AFDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am Chandrashekhar, I writing one application, in which wanted to access non-windows drive, which will be imported through NFS, can you please explain me is there any library or any other way I can access data from non-dos partition drive. Thanks in advance. Regards, Chandrashekhar. ------=_NextPart_000_0000_01C67386.AF2AFDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am Chandrashekhar, I writing one application, in = which wanted to access non-windows drive, which will be imported through NFS, = can you please explain me is there any library or any other way I can access = data from non-dos partition drive.

Thanks in advance.

Regards,

Chandrashekhar.

------=_NextPart_000_0000_01C67386.AF2AFDC0-- ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: RahulSrivastava 71616 Date: Mon, 11 Jan 2010 14:12:25 +0000 Subject: Query Message-Id: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sctp@vger.kernel.org Hi All, I have a query. When using Linux SCTP one-to-many style sockets sendmsg succedes even though message is not delivered at the peer. When I ask the socket to wait for notification it gave send failed in notification. Is this possible for sendmsg to fail for even for one-to-many style socket (for peer errors)? Regards, Rahul ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Date: Mon, 11 Jan 2010 17:05:21 +0000 Subject: Re: Query Message-Id: <4B4B5A51.4030701@hp.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sctp@vger.kernel.org RahulSrivastava 71616 wrote: > Hi All, > I have a query. When using Linux SCTP one-to-many style sockets sendmsg succedes even though message is not delivered at the peer. When I ask the socket to wait for notification it gave send failed in notification. > Is this possible for sendmsg to fail for even for one-to-many style socket (for peer errors)? > Yes. sendmsg() will return success when the data has successfully been accepted by the kernel. However, if peer has problems, you may get a SEND_FAILED notification. This is not linux SCTP specific. TCP can behave the same way (minus the notification). -vlad > Regards, > Rahul > > > > ****************************************************************************************** > This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! > ***************************************************************************************** > -- > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > From mboxrd@z Thu Jan 1 00:00:00 1970 From: RahulSrivastava 71616 Date: Tue, 12 Jan 2010 04:56:40 +0000 Subject: Re: Query Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sctp@vger.kernel.org Thanks! If sendmsg succedes like this then how its possible to maintain ordering of messages: Consider below order: send1 ----> send2 send1 was not recieved but send2 was successfully recived by peer on same association. Application gets a notification of send1 (indicating send failed). Regards, Rahul ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** ----- Original Message ----- From: Vlad Yasevich Date: Monday, January 11, 2010 10:35 pm Subject: Re: Query To: RahulSrivastava 71616 Cc: linux-sctp@vger.kernel.org > > > RahulSrivastava 71616 wrote: > > Hi All, > > I have a query. When using Linux SCTP one-to-many style > sockets sendmsg succedes even though message is not delivered at > the peer. When I ask the socket to wait for notification it gave > send failed in notification. > > Is this possible for sendmsg to fail for even for one-to-many > style socket (for peer errors)? > > > > Yes. sendmsg() will return success when the data has successfully > been accepted > by the kernel. However, if peer has problems, you may get a > SEND_FAILEDnotification. > > This is not linux SCTP specific. TCP can behave the same way > (minus the > notification). > > -vlad > > > Regards, > > Rahul > > > > > > > > > ******************************************************************************************> This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! > > > *****************************************************************************************> -- > > To unsubscribe from this list: send the line "unsubscribe linux- > sctp" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Date: Tue, 12 Jan 2010 20:52:42 +0000 Subject: Re: Query Message-Id: <4B4CE11A.9090207@hp.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sctp@vger.kernel.org RahulSrivastava 71616 wrote: > Thanks! > If sendmsg succedes like this then how its possible to maintain ordering of messages: > Consider below order: > send1 ----> send2 > > send1 was not recieved but send2 was successfully recived by peer on same association. Application gets a notification of send1 (indicating send failed). > No, that will not happen on the same association unless partial reliability is used. In the normal scenario (full reliability), if send1 fails, then the association is destroyed. The SEND_FAILED event is typically generated in the case of excessive retransmissions that cause the association to terminate. There are a few other times it can be generated, but all those times have to do with setting a time_to_live on the message. So, if you are using implicit connect (i.e used the sendto/sendmsg() call to establish an association), then the steps are these: 1) queue the message to the kernel queue. 2) start association procedure. a) if association is successful, send the message. b) if association fails, notify the user to association and send failure. If if you already have an association, the protocol will attempt to deliver all messages in order. If the message has already been queued to the kernel, and the association terminates due to retransmissions, you will get an association termination notification and a send failed notification. Any subsequent send calls by the applications will attempt to establish a new association. -vlad > > > Regards, > Rahul > > > ****************************************************************************************** > This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! > ***************************************************************************************** > > ----- Original Message ----- > From: Vlad Yasevich > Date: Monday, January 11, 2010 10:35 pm > Subject: Re: Query > To: RahulSrivastava 71616 > Cc: linux-sctp@vger.kernel.org > >> >> RahulSrivastava 71616 wrote: >>> Hi All, >>> I have a query. When using Linux SCTP one-to-many style >> sockets sendmsg succedes even though message is not delivered at >> the peer. When I ask the socket to wait for notification it gave >> send failed in notification. >>> Is this possible for sendmsg to fail for even for one-to-many >> style socket (for peer errors)? >> Yes. sendmsg() will return success when the data has successfully >> been accepted >> by the kernel. However, if peer has problems, you may get a >> SEND_FAILEDnotification. >> >> This is not linux SCTP specific. TCP can behave the same way >> (minus the >> notification). >> >> -vlad >> >>> Regards, >>> Rahul >>> >>> >>> >>> >> ******************************************************************************************> This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! >>> >> *****************************************************************************************> -- >>> To unsubscribe from this list: send the line "unsubscribe linux- >> sctp" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> > From mboxrd@z Thu Jan 1 00:00:00 1970 From: RahulSrivastava 71616 Date: Tue, 05 Apr 2011 06:30:19 +0000 Subject: Query Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sctp@vger.kernel.org Hi All, I am running a test application and I am finding lksctp performance is at least 25% of UDP on Linux. Specifically my profiler tells sctp_sendmsg is at least 5 times slower than UDP sendto. Can anybody provide pointers on this? Regards, Rahul ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 03:11:47 -0700 (PDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42ABNfg028723 for ; Fri, 2 May 2008 03:11:28 -0700 Received: from outbound4-dub-R.bigfish.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1255BADE1CF for ; Fri, 2 May 2008 03:12:07 -0700 (PDT) Received: from outbound4-dub-R.bigfish.com (outbound-dub.frontbridge.com [213.199.154.16]) by cuda.sgi.com with ESMTP id kI7PUUc9eLqd6eK0 for ; Fri, 02 May 2008 03:12:07 -0700 (PDT) Received: from outbound4-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound4-dub-R.bigfish.com (Postfix) with ESMTP id 5DE3417C047D for ; Fri, 2 May 2008 10:08:25 +0000 (UTC) Received: from mail72-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound4-dub.bigfish.com (Postfix) with ESMTP id 36940136805C for ; Fri, 2 May 2008 10:08:25 +0000 (UTC) Received: from mail72-dub (localhost.localdomain [127.0.0.1]) by mail72-dub-R.bigfish.com (Postfix) with ESMTP id 2702410082E2 for ; Fri, 2 May 2008 10:08:24 +0000 (UTC) Received: from mailus1.cgg.com (72-20-130-72.cgg.com [72.20.130.72]) by mail72-dub.bigfish.com (Postfix) with ESMTP id 7CACCA78073 for ; Fri, 2 May 2008 10:08:22 +0000 (UTC) Received: from in02ex01.int.cgg.com (in02ex01.int.cgg.com [192.168.53.201]) by mailus1.cgg.com (MailerCGG) with ESMTP id 5862A1D4001 for ; Fri, 2 May 2008 05:08:17 -0500 (CDT) MIME-Version: 1.0 Subject: query Date: Fri, 2 May 2008 15:38:13 +0530 Message-ID: <87604E51C77C4F4988CF1C7F088D562D9BE614@in02ex01.int.cgg.com> From: "Nandedkar, Rishiraj" Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: xfs@oss.sgi.com Hi, I would like to know which Linux version support XFS file system. I am working on linux3.5 and 4.3 and 7.3 but all these versions not support XFS. Please let me know which Linux version supports xfs and where can I get this versions Thanks in advance Thx & Regards Rishi Nandedkar It support CGGVERITAS [[HTML alternate version deleted]] From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 03:35:16 -0700 (PDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42AYtmb030501 for ; Fri, 2 May 2008 03:34:57 -0700 Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A8C04ADE326 for ; Fri, 2 May 2008 03:35:39 -0700 (PDT) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by cuda.sgi.com with ESMTP id l6jE6Y6Cp8wBRDIY for ; Fri, 02 May 2008 03:35:39 -0700 (PDT) Date: Fri, 2 May 2008 12:35:41 +0200 From: Emmanuel Florac Subject: Re: query Message-ID: <20080502123541.2216848e@harpe.intellique.com> In-Reply-To: <87604E51C77C4F4988CF1C7F088D562D9BE614@in02ex01.int.cgg.com> References: <87604E51C77C4F4988CF1C7F088D562D9BE614@in02ex01.int.cgg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: "Nandedkar, Rishiraj" Cc: xfs@oss.sgi.com Le Fri, 2 May 2008 15:38:13 +0530 "Nandedkar, Rishiraj" écrivait: > I would like to know which Linux version support XFS file system. I am > working on linux3.5 and 4.3 and 7.3 but all these versions not support > XFS. You are misleaded. There is no such thing as "linux 3.5" or "linux 7.3". Current Linux kernel version is 2.6.25. However there exists hundreds of GNU/Linux distributions, with many different numbering schemes, that may come with or without XFS support. Some current common distributions : Debian GNU/Linux 4.0, SuSE Linux Enterprise Server 10.0, RedHat Enterprise Linux 5.0... See http://distrowatch.com/ to find about most of them. Most distributions (except RedHat Enterprise and SuSE Enterprise) may be downloaded (and used) for free. Don't stick with an outdated one! As far as I know, all distributions less than 5 years old should support XFS natively. So either you use some very old distribution (like RedHat Linux 7.3, which is antique), or you didn't looked for the right thing at the right place. -- ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 03:42:38 -0700 (PDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42AgNLD031283 for ; Fri, 2 May 2008 03:42:24 -0700 Received: from outbound9-dub-R.bigfish.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4DBCEADE4D1 for ; Fri, 2 May 2008 03:43:07 -0700 (PDT) Received: from outbound9-dub-R.bigfish.com (outbound-dub.frontbridge.com [213.199.154.16]) by cuda.sgi.com with ESMTP id U3Ehdi135iisQ6Wf for ; Fri, 02 May 2008 03:43:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: query content-class: urn:content-classes:message Date: Fri, 2 May 2008 16:12:58 +0530 Message-ID: <87604E51C77C4F4988CF1C7F088D562D38BE0A@in02ex01.int.cgg.com> From: "Nandedkar, Rishiraj" Content-Transfer-Encoding: 8bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: Emmanuel Florac Cc: xfs@oss.sgi.com Hi, Thank you for update but Linux 7.3 means red hat 7 update 3 red hat 3 update 5.In our system we are unable to detect disk which is having file system in XFS format. Our system is not able to support it. 2.4.21-32.EL is kenal version on our systems. Please let me know which version should I use in redhat.I am trying this with fedora core 3 Thx rishi -----Original Message----- From: Emmanuel Florac [mailto:eflorac@intellique.com] Sent: Friday, May 02, 2008 4:06 PM To: Nandedkar, Rishiraj Cc: xfs@oss.sgi.com Subject: Re: query Le Fri, 2 May 2008 15:38:13 +0530 "Nandedkar, Rishiraj" écrivait: > I would like to know which Linux version support XFS file system. I am > working on linux3.5 and 4.3 and 7.3 but all these versions not support > XFS. You are misleaded. There is no such thing as "linux 3.5" or "linux 7.3". Current Linux kernel version is 2.6.25. However there exists hundreds of GNU/Linux distributions, with many different numbering schemes, that may come with or without XFS support. Some current common distributions : Debian GNU/Linux 4.0, SuSE Linux Enterprise Server 10.0, RedHat Enterprise Linux 5.0... See http://distrowatch.com/ to find about most of them. Most distributions (except RedHat Enterprise and SuSE Enterprise) may be downloaded (and used) for free. Don't stick with an outdated one! As far as I know, all distributions less than 5 years old should support XFS natively. So either you use some very old distribution (like RedHat Linux 7.3, which is antique), or you didn't looked for the right thing at the right place. -- ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 04:15:09 -0700 (PDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42BEgG5002210 for ; Fri, 2 May 2008 04:14:46 -0700 Received: from smtp-out04.alice-dsl.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 04FE61621A98 for ; Fri, 2 May 2008 04:15:26 -0700 (PDT) Received: from smtp-out04.alice-dsl.net (smtp-out04.alice-dsl.net [88.44.63.6]) by cuda.sgi.com with ESMTP id P273j1LDZLbEZJkt for ; Fri, 02 May 2008 04:15:26 -0700 (PDT) Subject: Re: query From: Andi Kleen References: <87604E51C77C4F4988CF1C7F088D562D9BE614@in02ex01.int.cgg.com> <20080502123541.2216848e@harpe.intellique.com> Date: Fri, 02 May 2008 13:14:02 +0200 In-Reply-To: <20080502123541.2216848e@harpe.intellique.com> (Emmanuel Florac's message of "Fri, 2 May 2008 12:35:41 +0200") Message-ID: <87fxt1ez5x.fsf@basil.nowhere.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: Emmanuel Florac Cc: "Nandedkar, Rishiraj" , xfs@oss.sgi.com Emmanuel Florac writes: > > Most distributions (except RedHat Enterprise and SuSE Enterprise) may OT, but actually that's not correct. You can download SLES for free. -Andi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 05:04:48 -0700 (PDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42C4Rxn009837 for ; Fri, 2 May 2008 05:04:30 -0700 Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C93D71622700 for ; Fri, 2 May 2008 05:05:11 -0700 (PDT) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by cuda.sgi.com with ESMTP id vQXS9zAK1HJWPqBG for ; Fri, 02 May 2008 05:05:11 -0700 (PDT) Date: Fri, 2 May 2008 14:05:09 +0200 From: Emmanuel Florac Subject: Re: query Message-ID: <20080502140509.62dadf26@harpe.intellique.com> In-Reply-To: <87604E51C77C4F4988CF1C7F088D562D38BE0A@in02ex01.int.cgg.com> References: <87604E51C77C4F4988CF1C7F088D562D38BE0A@in02ex01.int.cgg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: "Nandedkar, Rishiraj" Cc: xfs@oss.sgi.com Le Fri, 2 May 2008 16:12:58 +0530 "Nandedkar, Rishiraj" écrivait: > Thank you for update but Linux 7.3 means red hat 7 update 3 red hat 3 > update 5.In our system we are unable to detect disk which is having > file system in XFS format. Our system is not able to support it. > 2.4.21-32.EL is kenal version on our systems. Please let me know > which version should I use in redhat.I am trying this with fedora > core 3 RedHat 7.3 ( or even 8.0 and 9.0 for that matter) are really very old and outdated. You'd be much better for pretty much everything with something more up-to-date. Back then RedHat 7.x needed a special additional CD provided by SGI for XFS support IIRC. I'm pretty surprised that RHEL 3 doesn't support XFS though. Anyway, RHEL 4 and 5 do without any doubt (I use XFS on them). -- ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 05:24:34 -0700 (PDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42CODNB011222 for ; Fri, 2 May 2008 05:24:14 -0700 Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 908CE162202F for ; Fri, 2 May 2008 05:24:56 -0700 (PDT) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by cuda.sgi.com with ESMTP id dAK8EQh9ApFalQ62 for ; Fri, 02 May 2008 05:24:56 -0700 (PDT) Date: Fri, 2 May 2008 14:25:00 +0200 From: Emmanuel Florac Subject: Re: query Message-ID: <20080502142500.049e14b0@harpe.intellique.com> In-Reply-To: <87604E51C77C4F4988CF1C7F088D562D38BE0A@in02ex01.int.cgg.com> References: <87604E51C77C4F4988CF1C7F088D562D38BE0A@in02ex01.int.cgg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: "Nandedkar, Rishiraj" Cc: xfs@oss.sgi.com Le Fri, 2 May 2008 16:12:58 +0530 "Nandedkar, Rishiraj" écrivait: > In our system we are unable to detect disk which is having file > system in XFS format. Our system is not able to support it. Just to get sure, how did you try to mount the XFS disks? Is there a software RAID, LVM or other additional layer that may prevent an older system to mount a volume made on a newer one? -- ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 05:37:54 -0700 (PDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42CbXLD012210 for ; Fri, 2 May 2008 05:37:35 -0700 Received: from outbound4-sin-R.bigfish.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2E78EADE85B for ; Fri, 2 May 2008 05:38:17 -0700 (PDT) Received: from outbound4-sin-R.bigfish.com (outbound-sin.frontbridge.com [207.46.51.80]) by cuda.sgi.com with ESMTP id fkAT4FM3OtlYo01z for ; Fri, 02 May 2008 05:38:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: query content-class: urn:content-classes:message Date: Fri, 2 May 2008 17:57:58 +0530 Message-ID: <87604E51C77C4F4988CF1C7F088D562D9BE618@in02ex01.int.cgg.com> From: "Nandedkar, Rishiraj" Content-Transfer-Encoding: 8bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: Emmanuel Florac Cc: xfs@oss.sgi.com Thank you very much -----Original Message----- From: Emmanuel Florac [mailto:eflorac@intellique.com] Sent: Friday, May 02, 2008 5:35 PM To: Nandedkar, Rishiraj Cc: xfs@oss.sgi.com Subject: Re: query Le Fri, 2 May 2008 16:12:58 +0530 "Nandedkar, Rishiraj" écrivait: > Thank you for update but Linux 7.3 means red hat 7 update 3 red hat 3 > update 5.In our system we are unable to detect disk which is having > file system in XFS format. Our system is not able to support it. > 2.4.21-32.EL is kenal version on our systems. Please let me know > which version should I use in redhat.I am trying this with fedora > core 3 RedHat 7.3 ( or even 8.0 and 9.0 for that matter) are really very old and outdated. You'd be much better for pretty much everything with something more up-to-date. Back then RedHat 7.x needed a special additional CD provided by SGI for XFS support IIRC. I'm pretty surprised that RHEL 3 doesn't support XFS though. Anyway, RHEL 4 and 5 do without any doubt (I use XFS on them). -- ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 05:51:25 -0700 (PDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42Cp51v013295 for ; Fri, 2 May 2008 05:51:06 -0700 Received: from proxy2.bredband.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 714E4119CF0 for ; Fri, 2 May 2008 05:51:48 -0700 (PDT) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by cuda.sgi.com with ESMTP id jbHx7kdeep6mXwed for ; Fri, 02 May 2008 05:51:48 -0700 (PDT) Received: from ironport2.bredband.com (195.54.101.122) by proxy2.bredband.net (7.3.127) id 4811833300270805 for xfs@oss.sgi.com; Fri, 2 May 2008 14:51:47 +0200 Message-ID: <481B0E57.5030100@stesmi.com> Date: Fri, 02 May 2008 14:51:35 +0200 From: Stefan Smietanowski MIME-Version: 1.0 Subject: Re: query References: <87604E51C77C4F4988CF1C7F088D562D9BE618@in02ex01.int.cgg.com> In-Reply-To: <87604E51C77C4F4988CF1C7F088D562D9BE618@in02ex01.int.cgg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: "Nandedkar, Rishiraj" Cc: Emmanuel Florac , xfs@oss.sgi.com Nandedkar, Rishiraj wrote: > Thank you very much > > > > -----Original Message----- > From: Emmanuel Florac [mailto:eflorac@intellique.com] > Sent: Friday, May 02, 2008 5:35 PM > To: Nandedkar, Rishiraj > Cc: xfs@oss.sgi.com > Subject: Re: query > > Le Fri, 2 May 2008 16:12:58 +0530 > "Nandedkar, Rishiraj" écrivait: > >> Thank you for update but Linux 7.3 means red hat 7 update 3 red hat 3 >> update 5.In our system we are unable to detect disk which is having >> file system in XFS format. Our system is not able to support it. >> 2.4.21-32.EL is kenal version on our systems. Please let me know >> which version should I use in redhat.I am trying this with fedora >> core 3 > > RedHat 7.3 ( or even 8.0 and 9.0 for that matter) are really very old > and outdated. You'd be much better for pretty much everything with > something more up-to-date. Back then RedHat 7.x needed a special > additional CD provided by SGI for XFS support IIRC. > I'm pretty surprised that RHEL 3 doesn't support XFS though. Anyway, > RHEL 4 and 5 do without any doubt (I use XFS on them). > Another point could be that if you're used to and like RedHat Linux 7.3 and/or RedHat Enterprise Linux then I think looking at either the newer RedHat Enterprise Linue (RHEL) 4 or 5 or Fedora is the way to go. To use XFS in Fedora (http://www.fedoraproject.org) you need to add the word "xfs" to the installer commandline and also make sure you use a seperate, small (100MB is enough) partition that's called /boot that's using ext3 (others work but I recommend using ext3 simply for that partition). // Stefan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 May 2008 06:02:56 -0700 (PDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m42D2Y9Z014456 for ; Fri, 2 May 2008 06:02:37 -0700 Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6B63C11A8C3 for ; Fri, 2 May 2008 06:03:17 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id KRw9nQZVPIGipaHn for ; Fri, 02 May 2008 06:03:17 -0700 (PDT) Message-ID: <481B1113.7040509@sandeen.net> Date: Fri, 02 May 2008 08:03:15 -0500 From: Eric Sandeen MIME-Version: 1.0 Subject: Re: query References: <87604E51C77C4F4988CF1C7F088D562D9BE618@in02ex01.int.cgg.com> <481B0E57.5030100@stesmi.com> In-Reply-To: <481B0E57.5030100@stesmi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: Stefan Smietanowski Cc: "Nandedkar, Rishiraj" , Emmanuel Florac , xfs@oss.sgi.com Stefan Smietanowski wrote: > To use XFS in Fedora (http://www.fedoraproject.org) you need to add the > word "xfs" to the installer commandline Only for F7 and earlier. F8 and beyond give you an xfs option on the partitioning screen by default. -Eric > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id q0BEho6r176127 for ; Wed, 11 Jan 2012 08:43:51 -0600 Received: from gws06.hcl.com (gws06.hcl.com [203.105.185.25]) by cuda.sgi.com with ESMTP id CoZachacYdnPfqZy for ; Wed, 11 Jan 2012 06:43:45 -0800 (PST) From: Anshul Kundra Date: Wed, 11 Jan 2012 20:13:09 +0530 Subject: Query Message-ID: Content-Language: en-US MIME-Version: 1.0 List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5519307757667490809==" Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: "xfs@oss.sgi.com" --===============5519307757667490809== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6AD0DBC0AAAC1409E664C8543D529CB044E3BAB0ENDAHCLTEVS05H_" --_000_E6AD0DBC0AAAC1409E664C8543D529CB044E3BAB0ENDAHCLTEVS05H_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To Developers , I have read about the new member named as xfs_extdelta that is passed in di= fferent xfs internal routines i.e xfs_bmapi , In the 2.4 versions instead o= f using it is just passed as NULL can anyone provide info regarding that wh= ere to initialize and if I pass it NULl then is there any adverse effect of= it XFS_IOCORE_RT not been used in 2.6 version , so if instead of this flag I = will pass XFS_IOCORE_EXCL it will be ok or will cause any crash or adverse = effects or either there is any alternative present to sought out from these= two problems Regards Anshul Kundra HCL TECHNOLOGIES ERS ________________________________ ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- --_000_E6AD0DBC0AAAC1409E664C8543D529CB044E3BAB0ENDAHCLTEVS05H_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To Developers ,

I have read about the new member named as xfs_extdel= ta that is passed in different xfs internal routines i.e xfs_bmapi , In the= 2.4 versions instead of using it is just passed as NULL can anyone provide= info regarding that where to initialize and if I pass it NULl then is there any adverse effect of it

XFS_IOCORE_RT not been used in 2.6 version , s= o if instead of this flag I will pass XFS_IOCORE_EXCL it will be ok or will= cause any crash or adverse effects or either there is any alternative pres= ent to sought out from these two problems

Regards

Anshul Kundra

HCL TECHNOLOGIES

ERS

To Developers ,

Regards

Anshul Kundra

HCL TECHNOLOGIES

ERS

::DISCLAIMER::
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
--_000_E6AD0DBC0AAAC1409E664C8543D529CB044E3BAB15NDAHCLTEVS05H_-- --===============0972046996423881704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs --===============0972046996423881704==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id q0BJsk7s187443 for ; Wed, 11 Jan 2012 13:54:46 -0600 Received: from mail.sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id RqlCYFiuhmvfCVuD for ; Wed, 11 Jan 2012 11:54:44 -0800 (PST) Message-ID: <4F0DE903.7000305@sandeen.net> Date: Wed, 11 Jan 2012 13:54:43 -0600 From: Eric Sandeen MIME-Version: 1.0 Subject: Re: query References: In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Anshul Kundra Cc: "xfs@oss.sgi.com" On 1/11/12 9:51 AM, Anshul Kundra wrote: > To Developers , > > I have read about the new member named as xfs_extdelta that is passed Well, that "new" member was added in 2006 ;) > in different xfs internal routines i.e xfs_bmapi , In the 2.4 > versions instead of using it is just passed as NULL can anyone > provide info regarding that where to initialize and if I pass it NULl > then is there any adverse effect of it > > > > XFS_IOCORE_RT not been used in 2.6 version , so if instead of this > flag I will pass XFS_IOCORE_EXCL it will be ok or will cause any > crash or adverse effects or either there is any alternative present > to sought out from these two problems > The 2.4 codebase was so long ago, I don't think you're going to be able to make any direct translation from 2.6 code to 2.4. Anyone trying to maintain or modify 2.4-era xfs is going to be largely on their own, I'm afraid, unless others have more time than I do to go back and research this stuff... -Eric > > Regards > > Anshul Kundra > > HCL TECHNOLOGIES > > ERS > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- > > ::DISCLAIMER:: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. It shall not attach any > liability on the originator or HCL or its affiliates. Any views or > opinions presented in this email are solely those of the author and > may not necessarily reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message > without the prior written consent of the author of this e-mail is > strictly prohibited. If you have received this email in error please > delete it and notify the sender immediately. Before opening any mail > and attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > > > > _______________________________________________ xfs mailing list > xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: ashwinnayak@vsnl.net (Ashwin Nayak) Date: Thu, 19 May 2005 06:24:20 +0000 Subject: Query Message-Id: <1065472677.10222.1.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lm-sensors@vger.kernel.org Hi, What I would like to know is how you guys can tell at which address which hardware is located. Like you guys say that the pll is at address 0x69 etc.How can I tell if the device that I am looking for is at a particular address. Ashwin From mboxrd@z Thu Jan 1 00:00:00 1970 From: phil@edgedesign.us (Philip Edelbrock) Date: Thu, 19 May 2005 06:24:20 +0000 Subject: Query Message-Id: <3F81D69B.5060901@edgedesign.us> List-Id: References: <1065472677.10222.1.camel@localhost.localdomain> In-Reply-To: <1065472677.10222.1.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lm-sensors@vger.kernel.org First, you can scan the bus to see which addresses have devices which respond to an I2C command. The datasheets show what possible addresses a device can be configured to be located at. Also, blocks of addresses usually are used by certain types of chips (like 0x50-0x5F and 0x30-0x3F are usually eeproms, 0x2D is usually a system hardware monitoring chip, 0x69 is usually a clocking chip, etc.) To confirm the identity, we do some specific query (again as specified by the datasheet) which can be used as a test. For example, some chips have specific registers which will always contain some specific values to identify things like vendor, chip ID, and die rev. So, if you are looking for a specific device and want to see if it is at a particular address, you'll have to try to communicate with it as per the datasheet to see if it responds in a way that you would expect. Unfortunately, there is no clear cut way of knowing what a chip is before talking with it (unlike other bus protocols, like PCI). Does this help? Phil Ashwin Nayak wrote: >Hi, > What I would like to know is how you guys can tell at which address >which hardware is located. Like you guys say that the pll is at address >0x69 etc.How can I tell if the device that I am looking for is at a >particular address. > >Ashwin > > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: khali@linux-fr.org (Jean Delvare) Date: Thu, 19 May 2005 06:24:20 +0000 Subject: Query Message-Id: <20031006225521.0f1414c7.khali@linux-fr.org> List-Id: References: <1065472677.10222.1.camel@localhost.localdomain> In-Reply-To: <1065472677.10222.1.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lm-sensors@vger.kernel.org > What I would like to know is how you guys can tell at which address > which hardware is located. Like you guys say that the pll is at > address 0x69 etc.How can I tell if the device that I am looking for is > at a particular address. Use our sensors-detect script. If it fails detecting what you are looking for, use i2cdetect to list your i2c busses, then use i2cdump on each of the addresses to see the "contents" of each chip. If you have an idea of what you're after (e.g. register X contains manufacturer ID Y) you should be able to locate it. If the identification is of general interest, let us know, so that we may update sensors-detect. You can also send us a patch directly :) -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: aparna misri Subject: Query Date: Fri, 10 Feb 2006 04:35:32 +0000 (GMT) Message-ID: <20060210043532.26157.qmail@web8510.mail.in.yahoo.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org hello, I am doing a small project in networking.I read somewhere that I can use iptables to capture network data.I want to capture IP packets so that I can compress it and then send it to the receiver.Receiver decompresses it at its side.Is it possible to do it with iptables? Aparna. __________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rob Sterenborg" Subject: Re: Query Date: Fri, 10 Feb 2006 14:30:50 +0100 (CET) Message-ID: <56244.193.173.147.3.1139578250.squirrel@webmail.sterenborg.info> References: <20060210043532.26157.qmail@web8510.mail.in.yahoo.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20060210043532.26157.qmail@web8510.mail.in.yahoo.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org On Fri, February 10, 2006 05:35, aparna misri wrote: > hello, > I am doing a small project in networking.I read > somewhere that I can use iptables to capture network > data.I want to capture IP packets so that I can > compress it and then send it to the receiver.Receiver > decompresses it at its side.Is it possible to do it > with iptables? I'd capture it with tcpdump, ethereal or something like that. These are p= acket sniffers, iptables is not. I'm not sure if iptables can capture (and log)= all packets just like a sniffer can. Gr, Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Pablo Sanchez" Subject: RE: Query Date: Fri, 10 Feb 2006 08:41:08 -0500 Message-ID: References: <56244.193.173.147.3.1139578250.squirrel@webmail.sterenborg.info> Reply-To: pablo@blueoakdb.com Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <56244.193.173.147.3.1139578250.squirrel@webmail.sterenborg.info> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org > -----Original Message----- > From: netfilter-bounces@lists.netfilter.org > [mailto:netfilter-bounces@lists.netfilter.org]On Behalf Of Rob > Sterenborg > Sent: Friday, February 10, 2006 8:31 AM > To: netfilter@lists.netfilter.org > Subject: Re: Query >=20 >=20 > I'm not sure if iptables can capture=20 > (and log) all > packets just like a sniffer can. You're right Rob, iptables cannot capture all the packets like a = sniffer. iptables is Layer 3 so you'd miss anything below. For = example, if you wanted to capture PPPoE packets (PADI, PADO, etc), you'd = miss them with iptables. Cheers, -pablo From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vogt Subject: Re: Query Date: Fri, 10 Feb 2006 14:46:24 +0100 Message-ID: <859616420602100546w2f9870abi@mail.gmail.com> References: <20060210043532.26157.qmail@web8510.mail.in.yahoo.com> <56244.193.173.147.3.1139578250.squirrel@webmail.sterenborg.info> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <56244.193.173.147.3.1139578250.squirrel@webmail.sterenborg.info> Content-Disposition: inline List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii" To: Rob Sterenborg Cc: "netfilter@lists.netfilter.org" Hi, iptables provides facilites to queue packets that traverse the kernel to a user space application. You can specify rules that define which packets are sent to user space. Furthermore, you can modify packet data to be reinjected into the kernel. I would suggest reading the manpage of libipq, providing a simple API to receive the packets. A very simple example application can be found there as well. As to reinjection, read the ipq_set_verdict man page. Hope that helps a little bit. David 2006/2/10, Rob Sterenborg : > On Fri, February 10, 2006 05:35, aparna misri wrote: > > hello, > > I am doing a small project in networking.I read > > somewhere that I can use iptables to capture network > > data.I want to capture IP packets so that I can > > compress it and then send it to the receiver.Receiver > > decompresses it at its side.Is it possible to do it > > with iptables? > > I'd capture it with tcpdump, ethereal or something like that. These are p= acket > sniffers, iptables is not. I'm not sure if iptables can capture (and log)= all > packets just like a sniffer can. > > > Gr, > Rob > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rob Sterenborg" Subject: Re: Query Date: Fri, 10 Feb 2006 15:02:37 +0100 (CET) Message-ID: <60942.193.173.147.3.1139580157.squirrel@webmail.sterenborg.info> References: <20060210043532.26157.qmail@web8510.mail.in.yahoo.com> <56244.193.173.147.3.1139578250.squirrel@webmail.sterenborg.info> <859616420602100546w2f9870abi@mail.gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <859616420602100546w2f9870abi@mail.gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org On Fri, February 10, 2006 14:46, David Vogt wrote: > Hi, > > iptables provides facilites to queue packets that traverse the kernel > to a user space application. You can specify rules that define which > packets are sent to user space. Furthermore, you can modify packet > data to be reinjected into the kernel. > > I would suggest reading the manpage of libipq, providing a simple API > to receive the packets. A very simple example application can be found > there as well. > As to reinjection, read the ipq_set_verdict man page. > Hope that helps a little bit. Yes, but still : can you give me a reason why I would use iptables/netfilter/libipq to sniff and log packets when I can do it with tcpdump or something ? The OP says I want to capture IP packets so that I can compress it= and then send it to the receiver. If he just wants to capture packets= , it seems to me that using iptables for this is a bit more difficult. Gr, Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vogt Subject: Re: Query Date: Fri, 10 Feb 2006 15:05:56 +0100 Message-ID: <859616420602100605j42b14cfcy@mail.gmail.com> References: <20060210043532.26157.qmail@web8510.mail.in.yahoo.com> <56244.193.173.147.3.1139578250.squirrel@webmail.sterenborg.info> <859616420602100546w2f9870abi@mail.gmail.com> <60942.193.173.147.3.1139580157.squirrel@webmail.sterenborg.info> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <60942.193.173.147.3.1139580157.squirrel@webmail.sterenborg.info> Content-Disposition: inline List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii" To: Rob Sterenborg Cc: "netfilter@lists.netfilter.org" 2006/2/10, Rob Sterenborg : > On Fri, February 10, 2006 14:46, David Vogt wrote: > > Hi, > > > > iptables provides facilites to queue packets that traverse the kernel > > to a user space application. You can specify rules that define which > > packets are sent to user space. Furthermore, you can modify packet > > data to be reinjected into the kernel. > > > > I would suggest reading the manpage of libipq, providing a simple API > > to receive the packets. A very simple example application can be found > > there as well. > > As to reinjection, read the ipq_set_verdict man page. > > Hope that helps a little bit. > > Yes, but still : can you give me a reason why I would use > iptables/netfilter/libipq to sniff and log packets when I can do it with > tcpdump or something ? > The OP says I want to capture IP packets so that I can compress it= and > then send it to the receiver. If he just wants to capture packets= , it > seems to me that using iptables for this is a bit more difficult. > As far as I understood he wants to modify the packets and reinject them. Is this possible with pcdump and ethereal as well? I thought they were ... read-only? On the other hand ... if he takes care of the communication of the packets in any other way (socket or whatever), libipq would not by my first choice either. David David From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rob Sterenborg" Subject: Re: Query Date: Fri, 10 Feb 2006 15:28:22 +0100 (CET) Message-ID: <50988.193.173.147.3.1139581702.squirrel@webmail.sterenborg.info> References: <20060210043532.26157.qmail@web8510.mail.in.yahoo.com> <56244.193.173.147.3.1139578250.squirrel@webmail.sterenborg.info> <859616420602100546w2f9870abi@mail.gmail.com> <60942.193.173.147.3.1139580157.squirrel@webmail.sterenborg.info> <859616420602100605j42b14cfcy@mail.gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <859616420602100605j42b14cfcy@mail.gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org On Fri, February 10, 2006 15:05, David Vogt wrote: > 2006/2/10, Rob Sterenborg : >> Yes, but still : can you give me a reason why I would use >> iptables/netfilter/libipq to sniff and log packets when I can do it wi= th >> tcpdump or something ? >> The OP says I want to capture IP packets so that I can compress= it >> and >> then send it to the receiver. If he just wants to capture pack= ets, >> it >> seems to me that using iptables for this is a bit more difficult. >> > > As far as I understood he wants to modify the packets and reinject > them. Is this possible with pcdump and ethereal as well? I thought > they were ... read-only? > On the other hand ... if he takes care of the communication of the > packets in any other way (socket or whatever), libipq would not by my > first choice either. I want to capture IP packets so that I can compress it and then send it to the receiver. Receiver decompresses it at its side. Is it possible to do it with iptables? What I understand is that he wants to send (not specified how) packet log= s to somebody who can process those (also not specified how). Oh well, the OP can choose ;-) Gr, Rob From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3748098787592709802==" MIME-Version: 1.0 From: Kallumari Nagaraja Rao, RammohanX Subject: query Date: Tue, 28 Jul 2015 09:27:41 +0000 Message-ID: <222E70FA67D72A4FB8EEDF5AF01724ACCF22F3@BGSMSX102.gar.corp.intel.com> List-Id: To: ofono@ofono.org --===============3748098787592709802== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi All, I am trying to get ofono running on my Intel Edison board. We have Intel Arduino Board with Ublox Sara-G350 connected via ttyMFD1 devi= ce. 1. Placed necessary configuration files at the needed places. a. Ofono.conf b. Tun.conf c. Ofono.rules 2. Updated ofono.rules with the following, # Ublox SARA-G350 ATTRS{idVendor}=3D=3D"1546", ATTRS{idProduct}=3D=3D"1102", ENV{OFONO_DRIVER= }=3D"ublox" 3. tun.conf into modules-load.d, but when I do lsmod I do not see module= tun being loaded ! 4. when I try running ofonod, I get struck at BT stuff as attached. Please let me know if I am missing something. Regards, Ram. --===============3748098787592709802== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+CjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+ PCEtLQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseTpDYWxp YnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9udC1m YW1pbHk6VmVyZGFuYTsKCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbAoJ e21hcmdpbjowaW47CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEuMHB0OwoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9CmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpibHVlOwoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZAoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOnB1cnBsZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0OwoJbWFyZ2luLXRvcDowaW47Cglt YXJnaW4tcmlnaHQ6MGluOwoJbWFyZ2luLWJvdHRvbTowaW47CgltYXJnaW4tbGVmdDouNWluOwoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQpzcGFuLkVtYWlsU3R5bGUxNwoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7Cglmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiOwoJ Y29sb3I6d2luZG93dGV4dDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30KQHBhZ2UgV29yZFNl Y3Rpb24xCgl7c2l6ZTo4LjVpbiAxMS4waW47CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQovKiBMaXN0IERlZmlu aXRpb25zICovCkBsaXN0IGwwCgl7bXNvLWxpc3QtaWQ6MjA1MjkyMTY0NzsKCW1zby1saXN0LXR5 cGU6aHlicmlkOwoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05ODE1ODU5MzYgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTU7fQpAbGlzdCBsMDpsZXZlbDEKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsK CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0uMjVpbjt9CkBs aXN0IGwwOmxldmVsMgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0 ZXh0LWluZGVudDotLjI1aW47fQpAbGlzdCBsMDpsZXZlbDMKCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0IGwwOmxldmVs NAoJe21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0OwoJdGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDA6bGV2ZWw1Cgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0uMjVpbjt9CkBsaXN0IGww OmxldmVsNgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1p bmRlbnQ6LTkuMHB0O30KQGxpc3QgbDA6bGV2ZWw3Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1aW47fQpA bGlzdCBsMDpsZXZlbDgKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1z by1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJ dGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDA6bGV2ZWw5Cgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpvbAoJe21hcmdpbi1i b3R0b206MGluO30KdWwKCXttYXJnaW4tYm90dG9tOjBpbjt9Ci0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPgo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CjwvaGVhZD4KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIEFs bCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgYW0gdHJ5aW5nIHRvIGdl dCBvZm9ubyBydW5uaW5nIG9uIG15IEludGVsIEVkaXNvbiBib2FyZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPldlIGhhdmUgSW50ZWwgQXJkdWlubyBCb2FyZCB3aXRoIFVi bG94IFNhcmEtRzM1MCBjb25uZWN0ZWQgdmlhIHR0eU1GRDEgZGV2aWNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGxhY2VkIG5lY2Vzc2FyeSBj b25maWd1cmF0aW9uIGZpbGVzIGF0IHRoZSBuZWVkZWQgcGxhY2VzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBp bjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPgo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T2Zvbm8uY29uZjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPgo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VHVuLmNvbmY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5jLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9mb25vLnJ1bGVzPG86cD48L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlVwZGF0ZWQgb2Zvbm8ucnVsZXMgd2l0aCB0aGUgZm9sbG93 aW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IyBVYmxveCBTQVJB LUczNTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFUVFJTe2lkVmVu ZG9yfT09JnF1b3Q7MTU0NiZxdW90OywgQVRUUlN7aWRQcm9kdWN0fT09JnF1b3Q7MTEwMiZxdW90 OywgRU5We09GT05PX0RSSVZFUn09JnF1b3Q7dWJsb3gmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+dHVuLmNvbmYgaW50byBtb2R1bGVzLWxvYWQuZCwgYnV0IHdoZW4gSSBkbyBs c21vZCBJIGRvIG5vdCBzZWUgbW9kdWxlIHR1biBiZWluZyBsb2FkZWQgITxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij53aGVuIEkgdHJ5IHJ1bm5pbmcgb2Zvbm9kLCBJIGdldCBzdHJ1Y2sg YXQgQlQgc3R1ZmYgYXMgYXR0YWNoZWQuPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5QbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBhbSBtaXNzaW5nIHNvbWV0aGluZy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlJhbS48bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjwvYm9keT4KPC9odG1sPgo= --===============3748098787592709802== Content-Type: text/plain MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ofono_dbg.txt" DQpyb290QGVkaXNvbjovaG9tZS9vZm9ubyMgZXhwb3J0IE9GT05PX0FUX0RFQlVHPTENCnJvb3RA ZWRpc29uOi9ob21lL29mb25vIyAuL29mb25vZCAtbmQgJg0KWzFdIDMwNQ0Kcm9vdEBlZGlzb246 L2hvbWUvb2Zvbm8jIG9mb25vZFszMDVdOiBvRm9ubyB2ZXJzaW9uIDEuMTYNCm9mb25vZFszMDVd OiBzcmMvcGx1Z2luLmM6X19vZm9ub19wbHVnaW5faW5pdCgpDQpvZm9ub2RbMzA1XTogcGx1Z2lu cy9wdXNoLW5vdGlmaWNhdGlvbi5jOnB1c2hfbm90aWZpY2F0aW9uX2luaXQoKQ0Kb2Zvbm9kWzMw NV06IHBsdWdpbnMvc21hcnQtbWVzc2FnaW5nLmM6c21hcnRfbWVzc2FnaW5nX2luaXQoKQ0Kb2Zv bm9kWzMwNV06IHNyYy9jZG1hLXByb3Zpc2lvbi5jOm9mb25vX2NkbWFfcHJvdmlzaW9uX2RyaXZl cl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3ZTQwIG5hbWU6IENETUEgcHJvdmlzaW9uaW5nDQpv Zm9ub2RbMzA1XTogc3JjL2dwcnMtcHJvdmlzaW9uLmM6b2Zvbm9fZ3Byc19wcm92aXNpb25fZHJp dmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTdlMDAgbmFtZTogUHJvdmlzaW9uaW5nDQpvZm9u b2RbMzA1XTogcGx1Z2lucy9kdW5fZ3dfYmx1ZXo1LmM6ZHVuX2d3X2luaXQoKQ0Kb2Zvbm9kWzMw NV06IHNyYy9oYW5kc2ZyZWUtYXVkaW8uYzpvZm9ub19oYW5kc2ZyZWVfY2FyZF9kcml2ZXJfcmVn aXN0ZXIoKSBkcml2ZXI6IDB4ODE5N2M4MA0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25v X21vZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3Y2EwLCBuYW1lOiBoZnANCm9m b25vZFszMDVdOiBzcmMvbW9kZW0uYzpvZm9ub19tb2RlbV9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2 ZXI6IDB4ODE5N2MwMCwgbmFtZTogdWJsb3gNCm9mb25vZFszMDVdOiBzcmMvbW9kZW0uYzpvZm9u b19tb2RlbV9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5N2JhMCwgbmFtZTogcXVlY3Rl bA0Kb2Zvbm9kWzMwNV06IHBsdWdpbnMvaGU5MTAuYzpoZTkxMF9pbml0KCkNCm9mb25vZFszMDVd OiBzcmMvbW9kZW0uYzpvZm9ub19tb2RlbV9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5 N2I0MCwgbmFtZTogaGU5MTANCm9mb25vZFszMDVdOiBwbHVnaW5zL2Nvbm5tYW4uYzpjb25ubWFu X2luaXQoKQ0Kb2Zvbm9kWzMwNV06IHNyYy9wcml2YXRlLW5ldHdvcmsuYzpvZm9ub19wcml2YXRl X25ldHdvcmtfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTdiMDAsIG5hbWU6IENvbm5N YW4gUHJpdmF0ZSBOZXR3b3JrDQpvZm9ub2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9fbW9kZW1f ZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTdhYTAsIG5hbWU6IHNpbTkwMA0Kb2Zvbm9k WzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX21vZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjog MHg4MTk3YTQwLCBuYW1lOiBzYW1zdW5nDQpvZm9ub2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9f bW9kZW1fZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTc5ZTAsIG5hbWU6IHNwZWVkdXBj ZG1hDQpvZm9ub2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9fbW9kZW1fZHJpdmVyX3JlZ2lzdGVy KCkgZHJpdmVyOiAweDgxOTc5ODAsIG5hbWU6IHNwZWVkdXANCm9mb25vZFszMDVdOiBzcmMvbW9k ZW0uYzpvZm9ub19tb2RlbV9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NzkyMCwgbmFt ZTogYWxjYXRlbA0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX21vZGVtX2RyaXZlcl9y ZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3OGMwLCBuYW1lOiBpY2VyYQ0Kb2Zvbm9kWzMwNV06IHNy Yy9tb2RlbS5jOm9mb25vX21vZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3ODYw LCBuYW1lOiBsaW5rdG9wDQpvZm9ub2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9fbW9kZW1fZHJp dmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTc4MDAsIG5hbWU6IG5va2lhY2RtYQ0Kb2Zvbm9k WzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX21vZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjog MHg4MTk3N2EwLCBuYW1lOiBub2tpYQ0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX21v ZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3NzQwLCBuYW1lOiB0YzY1DQpvZm9u b2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9fbW9kZW1fZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVy OiAweDgxOTc2YTAsIG5hbWU6IHN0ZQ0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX21v ZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3NjQwLCBuYW1lOiBpZngNCm9mb25v ZFszMDVdOiBzcmMvbW9kZW0uYzpvZm9ub19tb2RlbV9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6 IDB4ODE5NzVlMCwgbmFtZTogcGFsbXByZQ0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25v X21vZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3NTgwLCBuYW1lOiBub3ZhdGVs DQpvZm9ub2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9fbW9kZW1fZHJpdmVyX3JlZ2lzdGVyKCkg ZHJpdmVyOiAweDgxOTc1MjAsIG5hbWU6IHNpZXJyYQ0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5j Om9mb25vX21vZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3NGEwLCBuYW1lOiBo dWF3ZWkNCm9mb25vZFszMDVdOiBzcmMvbW9kZW0uYzpvZm9ub19tb2RlbV9kcml2ZXJfcmVnaXN0 ZXIoKSBkcml2ZXI6IDB4ODE5NzQ0MCwgbmFtZTogenRlDQpvZm9ub2RbMzA1XTogc3JjL21vZGVt LmM6b2Zvbm9fbW9kZW1fZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTczZTAsIG5hbWU6 IGhzbw0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX21vZGVtX2RyaXZlcl9yZWdpc3Rl cigpIGRyaXZlcjogMHg4MTk3MzgwLCBuYW1lOiBtYm0NCm9mb25vZFszMDVdOiBzcmMvbW9kZW0u YzpvZm9ub19tb2RlbV9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NzMyMCwgbmFtZTog Y2FseXBzbw0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX21vZGVtX2RyaXZlcl9yZWdp c3RlcigpIGRyaXZlcjogMHg4MTk3MmMwLCBuYW1lOiB3YXZlY29tDQpvZm9ub2RbMzA1XTogc3Jj L21vZGVtLmM6b2Zvbm9fbW9kZW1fZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTcyNjAs IG5hbWU6IGcxDQpvZm9ub2RbMzA1XTogc3JjL2NkbWEtdm9pY2VjYWxsLmM6b2Zvbm9fY2RtYV92 b2ljZWNhbGxfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTcxZTAsIG5hbWU6IGNkbWFt b2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX2RldmluZm9fZHJpdmVyX3JlZ2lz dGVyKCkgZHJpdmVyOiAweDgxOTcyMDAsIG5hbWU6IGNkbWFtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNy Yy9jZG1hLWNvbm5tYW4uYzpvZm9ub19jZG1hX2Nvbm5tYW5fZHJpdmVyX3JlZ2lzdGVyKCkgZHJp dmVyOiAweDgxOTcyMjQsIG5hbWU6IGNkbWFtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5j Om9mb25vX21vZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3MTQwLCBuYW1lOiBw aG9uZXNpbQ0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9mb25vX21vZGVtX2RyaXZlcl9yZWdp c3RlcigpIGRyaXZlcjogMHg4MTk3MTgwLCBuYW1lOiBsb2NhbGhmcA0Kb2Zvbm9kWzMwNV06IHNy Yy9ncHJzLmM6b2Zvbm9fZ3Byc19jb250ZXh0X2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4 MTk3MTFjLCBuYW1lOiBwaG9uZXNpbQ0Kb2Zvbm9kWzMwNV06IHNyYy9jdG0uYzpvZm9ub19jdG1f ZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTcxMDgsIG5hbWU6IHBob25lc2ltDQpvZm9u b2RbMzA1XTogc3JjL3JhZGlvLXNldHRpbmdzLmM6b2Zvbm9fcmFkaW9fc2V0dGluZ3NfZHJpdmVy X3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTcwZTAsIG5hbWU6IHBob25lc2ltDQpvZm9ub2RbMzA1 XTogcGx1Z2lucy9waG9uZXNpbS5jOnBhcnNlX2NvbmZpZygpIGZpbGVuYW1lIC9ldGMvb2Zvbm8v cGhvbmVzaW0uY29uZg0Kb2Zvbm9kWzMwNV06IFJlYWRpbmcgb2YgL2V0Yy9vZm9uby9waG9uZXNp bS5jb25mIGZhaWxlZDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQ0Kb2Zvbm9kWzMwNV06IHNy Yy91c3NkLmM6b2Zvbm9fdXNzZF9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NzBhMCwg bmFtZTogc3BlZWR1cG1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL3ZvaWNlY2FsbC5jOm9mb25vX3Zv aWNlY2FsbF9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NmY0MCwgbmFtZTogaGZwbW9k ZW0NCm9mb25vZFszMDVdOiBzcmMvbW9kZW0uYzpvZm9ub19kZXZpbmZvX2RyaXZlcl9yZWdpc3Rl cigpIGRyaXZlcjogMHg4MTk2ZmZjLCBuYW1lOiBoZnBtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9u ZXR3b3JrLmM6b2Zvbm9fbmV0cmVnX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2ZmEw LCBuYW1lOiBoZnBtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9jYWxsLXZvbHVtZS5jOm9mb25vX2Nh bGxfdm9sdW1lX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2ZmQ0LCBuYW1lOiBoZnBt b2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9oYW5kc2ZyZWUuYzpvZm9ub19oYW5kc2ZyZWVfZHJpdmVy X3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTcwMjAsIG5hbWU6IGhmcG1vZGVtDQpvZm9ub2RbMzA1 XTogc3JjL3NpcmkuYzpvZm9ub19zaXJpX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk3 MDUwLCBuYW1lOiBoZnBtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9uZXR3b3JrLmM6b2Zvbm9fbmV0 cmVnX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2ZWEwLCBuYW1lOiBkdW5tb2RlbQ0K b2Zvbm9kWzMwNV06IHNyYy9ncHJzLmM6b2Zvbm9fZ3Byc19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2 ZXI6IDB4ODE5NmVjYywgbmFtZTogZHVubW9kZW0NCm9mb25vZFszMDVdOiBzcmMvdm9pY2VjYWxs LmM6b2Zvbm9fdm9pY2VjYWxsX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2ZGMwLCBu YW1lOiBzdGVtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9ncHJzLmM6b2Zvbm9fZ3Byc19jb250ZXh0 X2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2ZTUwLCBuYW1lOiBzdGVtb2RlbQ0Kb2Zv bm9kWzMwNV06IHNyYy9yYWRpby1zZXR0aW5ncy5jOm9mb25vX3JhZGlvX3NldHRpbmdzX2RyaXZl cl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2ZTIwLCBuYW1lOiBzdGVtb2RlbQ0Kb2Zvbm9kWzMw NV06IHNyYy92b2ljZWNhbGwuYzpvZm9ub192b2ljZWNhbGxfZHJpdmVyX3JlZ2lzdGVyKCkgZHJp dmVyOiAweDgxOTZjODAsIG5hbWU6IGlmeG1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL2F1ZGlvLXNl dHRpbmdzLmM6b2Zvbm9fYXVkaW9fc2V0dGluZ3NfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAw eDgxOTZjZDAsIG5hbWU6IGlmeG1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL3JhZGlvLXNldHRpbmdz LmM6b2Zvbm9fcmFkaW9fc2V0dGluZ3NfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTZk MDAsIG5hbWU6IGlmeG1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL2dwcnMuYzpvZm9ub19ncHJzX2Nv bnRleHRfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTZkMzAsIG5hbWU6IGlmeG1vZGVt DQpvZm9ub2RbMzA1XTogc3JjL3N0ay5jOm9mb25vX3N0a19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2 ZXI6IDB4ODE5NmQ1OCwgbmFtZTogaWZ4bW9kZW0NCm9mb25vZFszMDVdOiBzcmMvY3RtLmM6b2Zv bm9fY3RtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2ZDgwLCBuYW1lOiBpZnhtb2Rl bQ0Kb2Zvbm9kWzMwNV06IHNyYy9ncHJzLmM6b2Zvbm9fZ3Byc19jb250ZXh0X2RyaXZlcl9yZWdp c3RlcigpIGRyaXZlcjogMHg4MTk2YzAwLCBuYW1lOiBoc29tb2RlbQ0Kb2Zvbm9kWzMwNV06IHNy Yy9yYWRpby1zZXR0aW5ncy5jOm9mb25vX3JhZGlvX3NldHRpbmdzX2RyaXZlcl9yZWdpc3Rlcigp IGRyaXZlcjogMHg4MTk2YzIwLCBuYW1lOiBoc29tb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9sb2Nh dGlvbi1yZXBvcnRpbmcuYzpvZm9ub19sb2NhdGlvbl9yZXBvcnRpbmdfZHJpdmVyX3JlZ2lzdGVy KCkgZHJpdmVyOiAweDgxOTZiYTAsIG5hbWU6IHRlbGl0bW9kZW0NCm9mb25vZFszMDVdOiBzcmMv bG9jYXRpb24tcmVwb3J0aW5nLmM6b2Zvbm9fbG9jYXRpb25fcmVwb3J0aW5nX2RyaXZlcl9yZWdp c3RlcigpIGRyaXZlcjogMHg4MTk2YmEwIG5vdCBudWxsDQpvZm9ub2RbMzA1XTogc3JjL2dwcnMu YzpvZm9ub19ncHJzX2NvbnRleHRfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTZiMDAs IG5hbWU6IG1ibW1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL3N0ay5jOm9mb25vX3N0a19kcml2ZXJf cmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NmIyOCwgbmFtZTogbWJtbW9kZW0NCm9mb25vZFszMDVd OiBzcmMvbG9jYXRpb24tcmVwb3J0aW5nLmM6b2Zvbm9fbG9jYXRpb25fcmVwb3J0aW5nX2RyaXZl cl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2YjQ4LCBuYW1lOiBtYm1tb2RlbQ0Kb2Zvbm9kWzMw NV06IHNyYy9sb2NhdGlvbi1yZXBvcnRpbmcuYzpvZm9ub19sb2NhdGlvbl9yZXBvcnRpbmdfZHJp dmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTZiNDggbm90IG51bGwNCm9mb25vZFszMDVdOiBz cmMvdm9pY2VjYWxsLmM6b2Zvbm9fdm9pY2VjYWxsX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjog MHg4MTk2YTYwLCBuYW1lOiBjYWx5cHNvbW9kZW0NCm9mb25vZFszMDVdOiBzcmMvc3RrLmM6b2Zv bm9fc3RrX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2YWE4LCBuYW1lOiBjYWx5cHNv bW9kZW0NCm9mb25vZFszMDVdOiBzcmMvdXNzZC5jOm9mb25vX3Vzc2RfZHJpdmVyX3JlZ2lzdGVy KCkgZHJpdmVyOiAweDgxOTY5NDAsIG5hbWU6IGh1YXdlaW1vZGVtDQpvZm9ub2RbMzA1XTogc3Jj L3ZvaWNlY2FsbC5jOm9mb25vX3ZvaWNlY2FsbF9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4 ODE5Njk2MCwgbmFtZTogaHVhd2VpbW9kZW0NCm9mb25vZFszMDVdOiBzcmMvYXVkaW8tc2V0dGlu Z3MuYzpvZm9ub19hdWRpb19zZXR0aW5nc19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5 NjlhOCwgbmFtZTogaHVhd2VpbW9kZW0NCm9mb25vZFszMDVdOiBzcmMvcmFkaW8tc2V0dGluZ3Mu YzpvZm9ub19yYWRpb19zZXR0aW5nc19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5Njll MCwgbmFtZTogaHVhd2VpbW9kZW0NCm9mb25vZFszMDVdOiBzcmMvZ3Bycy5jOm9mb25vX2dwcnNf Y29udGV4dF9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NjliYywgbmFtZTogaHVhd2Vp bW9kZW0NCm9mb25vZFszMDVdOiBzcmMvY2RtYS1uZXRyZWcuYzpvZm9ub19jZG1hX25ldHJlZ19k cml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NmExMCwgbmFtZTogaHVhd2VpbW9kZW0NCm9m b25vZFszMDVdOiBzcmMvZ3Bycy5jOm9mb25vX2dwcnNfY29udGV4dF9kcml2ZXJfcmVnaXN0ZXIo KSBkcml2ZXI6IDB4ODE5NjhhMCwgbmFtZTogaWNlcmFtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9y YWRpby1zZXR0aW5ncy5jOm9mb25vX3JhZGlvX3NldHRpbmdzX2RyaXZlcl9yZWdpc3RlcigpIGRy aXZlcjogMHg4MTk2OGUwLCBuYW1lOiBpY2VyYW1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL3JhZGlv LXNldHRpbmdzLmM6b2Zvbm9fcmFkaW9fc2V0dGluZ3NfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVy OiAweDgxOTY4NDAsIG5hbWU6IHp0ZW1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL2dwcnMuYzpvZm9u b19ncHJzX2NvbnRleHRfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTY4MDAsIG5hbWU6 IHN3bW9kZW0NCm9mb25vZFszMDVdOiBzcmMvcmFkaW8tc2V0dGluZ3MuYzpvZm9ub19yYWRpb19z ZXR0aW5nc19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NjdhMCwgbmFtZTogbndtb2Rl bQ0Kb2Zvbm9kWzMwNV06IHNyYy92b2ljZWNhbGwuYzpvZm9ub192b2ljZWNhbGxfZHJpdmVyX3Jl Z2lzdGVyKCkgZHJpdmVyOiAweDgxOTY2MDAsIG5hbWU6IGF0bW9kZW0NCm9mb25vZFszMDVdOiBz cmMvbW9kZW0uYzpvZm9ub19kZXZpbmZvX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2 NmEwLCBuYW1lOiBhdG1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL2NhbGwtYmFycmluZy5jOm9mb25v X2NhbGxfYmFycmluZ19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NjY1OCwgbmFtZTog YXRtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9jYWxsLWZvcndhcmRpbmcuYzpvZm9ub19jYWxsX2Zv cndhcmRpbmdfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTYzODAsIG5hbWU6IGF0bW9k ZW0NCm9mb25vZFszMDVdOiBzcmMvY2FsbC1tZXRlci5jOm9mb25vX2NhbGxfbWV0ZXJfZHJpdmVy X3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTYzYzAsIG5hbWU6IGF0bW9kZW0NCm9mb25vZFszMDVd OiBzcmMvY2FsbC1zZXR0aW5ncy5jOm9mb25vX2NhbGxfc2V0dGluZ3NfZHJpdmVyX3JlZ2lzdGVy KCkgZHJpdmVyOiAweDgxOTYyODAsIG5hbWU6IGF0bW9kZW0NCm9mb25vZFszMDVdOiBzcmMvcGhv bmVib29rLmM6b2Zvbm9fcGhvbmVib29rX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2 Njc4LCBuYW1lOiBhdG1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL3Vzc2QuYzpvZm9ub191c3NkX2Ry aXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2NWM0LCBuYW1lOiBhdG1vZGVtDQpvZm9ub2Rb MzA1XTogc3JjL3Ntcy5jOm9mb25vX3Ntc19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5 NjMwMCwgbmFtZTogYXRtb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9zaW0uYzpvZm9ub19zaW1fZHJp dmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTY0ODAsIG5hbWU6IGF0bW9kZW0NCm9mb25vZFsz MDVdOiBzcmMvc2ltLmM6b2Zvbm9fc2ltX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2 NGUwLCBuYW1lOiBhdG1vZGVtLW5vZWYNCm9mb25vZFszMDVdOiBzcmMvc3RrLmM6b2Zvbm9fc3Rr X2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2NWE0LCBuYW1lOiBhdG1vZGVtDQpvZm9u b2RbMzA1XTogc3JjL25ldHdvcmsuYzpvZm9ub19uZXRyZWdfZHJpdmVyX3JlZ2lzdGVyKCkgZHJp dmVyOiAweDgxOTY0MjAsIG5hbWU6IGF0bW9kZW0NCm9mb25vZFszMDVdOiBzcmMvY2JzLmM6b2Zv bm9fY2JzX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2MzYwLCBuYW1lOiBhdG1vZGVt DQpvZm9ub2RbMzA1XTogc3JjL2NhbGwtdm9sdW1lLmM6b2Zvbm9fY2FsbF92b2x1bWVfZHJpdmVy X3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTY2YzQsIG5hbWU6IGF0bW9kZW0NCm9mb25vZFszMDVd OiBzcmMvZ3Bycy5jOm9mb25vX2dwcnNfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTY2 ZjQsIG5hbWU6IGF0bW9kZW0NCm9mb25vZFszMDVdOiBzcmMvZ3Bycy5jOm9mb25vX2dwcnNfY29u dGV4dF9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NjcxOCwgbmFtZTogYXRtb2RlbQ0K b2Zvbm9kWzMwNV06IHNyYy9zaW0tYXV0aC5jOm9mb25vX3NpbV9hdXRoX2RyaXZlcl9yZWdpc3Rl cigpIGRyaXZlcjogMHg4MTk2NzMwLCBuYW1lOiBhdG1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL2du c3MuYzpvZm9ub19nbnNzX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2NzQ4LCBuYW1l OiBhdG1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9fbW9kZW1fZHJpdmVyX3Jl Z2lzdGVyKCkgZHJpdmVyOiAweDgxOTYwNjAsIG5hbWU6IGdvYmkNCm9mb25vZFszMDVdOiBzcmMv bW9kZW0uYzpvZm9ub19kZXZpbmZvX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk1ZTIw LCBuYW1lOiBxbWltb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9uZXR3b3JrLmM6b2Zvbm9fbmV0cmVn X2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk1ZWEwLCBuYW1lOiBxbWltb2RlbQ0Kb2Zv bm9kWzMwNV06IHNyYy92b2ljZWNhbGwuYzpvZm9ub192b2ljZWNhbGxfZHJpdmVyX3JlZ2lzdGVy KCkgZHJpdmVyOiAweDgxOTVlNDAsIG5hbWU6IHFtaW1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL3Np bS5jOm9mb25vX3NpbV9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NWVlMCwgbmFtZTog cW1pbW9kZW0tbGVnYWN5DQpvZm9ub2RbMzA1XTogc3JjL3NpbS5jOm9mb25vX3NpbV9kcml2ZXJf cmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NWY0MCwgbmFtZTogcW1pbW9kZW0NCm9mb25vZFszMDVd OiBzcmMvc21zLmM6b2Zvbm9fc21zX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk1ZmEw LCBuYW1lOiBxbWltb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy91c3NkLmM6b2Zvbm9fdXNzZF9kcml2 ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NWZjMCwgbmFtZTogcW1pbW9kZW0NCm9mb25vZFsz MDVdOiBzcmMvZ3Bycy5jOm9mb25vX2dwcnNfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgx OTVmZDQsIG5hbWU6IHFtaW1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL2dwcnMuYzpvZm9ub19ncHJz X2NvbnRleHRfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTVmZTgsIG5hbWU6IHFtaW1v ZGVtDQpvZm9ub2RbMzA1XTogc3JjL3JhZGlvLXNldHRpbmdzLmM6b2Zvbm9fcmFkaW9fc2V0dGlu Z3NfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTYwMDAsIG5hbWU6IHFtaW1vZGVtDQpv Zm9ub2RbMzA1XTogc3JjL2xvY2F0aW9uLXJlcG9ydGluZy5jOm9mb25vX2xvY2F0aW9uX3JlcG9y dGluZ19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NjAyOCwgbmFtZTogcW1pbW9kZW0N Cm9mb25vZFszMDVdOiBzcmMvbG9jYXRpb24tcmVwb3J0aW5nLmM6b2Zvbm9fbG9jYXRpb25fcmVw b3J0aW5nX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk2MDI4IG5vdCBudWxsDQpvZm9u b2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9fbW9kZW1fZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVy OiAweDgxOTVkYzAsIG5hbWU6IHU4NTAwDQpvZm9ub2RbMzA1XTogc3JjL21vZGVtLmM6b2Zvbm9f ZGV2aW5mb19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NWRhMCwgbmFtZTogdTg1MDAN Cm9mb25vZFszMDVdOiBzcmMvbW9kZW0uYzpvZm9ub19tb2RlbV9kcml2ZXJfcmVnaXN0ZXIoKSBk cml2ZXI6IDB4ODE5NWQ0MCwgbmFtZTogbjkwMA0Kb2Zvbm9kWzMwNV06IHNyYy9tb2RlbS5jOm9m b25vX21vZGVtX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk1Y2UwLCBuYW1lOiBpc2l1 c2INCm9mb25vZFszMDVdOiBzcmMvbW9kZW0uYzpvZm9ub19kZXZpbmZvX2RyaXZlcl9yZWdpc3Rl cigpIGRyaXZlcjogMHg4MTk1OWQwLCBuYW1lOiBpc2ltb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9w aG9uZWJvb2suYzpvZm9ub19waG9uZWJvb2tfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgx OTU5YzAsIG5hbWU6IGlzaW1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL25ldHdvcmsuYzpvZm9ub19u ZXRyZWdfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTVhMDAsIG5hbWU6IGlzaW1vZGVt DQpvZm9ub2RbMzA1XTogc3JjL3ZvaWNlY2FsbC5jOm9mb25vX3ZvaWNlY2FsbF9kcml2ZXJfcmVn aXN0ZXIoKSBkcml2ZXI6IDB4ODE5NWE0MCwgbmFtZTogaXNpbW9kZW0NCm9mb25vZFszMDVdOiBz cmMvc21zLmM6b2Zvbm9fc21zX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk1YWEwLCBu YW1lOiBpc2ltb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9jYnMuYzpvZm9ub19jYnNfZHJpdmVyX3Jl Z2lzdGVyKCkgZHJpdmVyOiAweDgxOTVhYzAsIG5hbWU6IGlzaW1vZGVtDQpvZm9ub2RbMzA1XTog c3JjL3NpbS5jOm9mb25vX3NpbV9kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4ODE5NWFlMCwg bmFtZTogaXNpbW9kZW0NCm9mb25vZFszMDVdOiBzcmMvdXNzZC5jOm9mb25vX3Vzc2RfZHJpdmVy X3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTViMjgsIG5hbWU6IGlzaW1vZGVtDQpvZm9ub2RbMzA1 XTogc3JjL2NhbGwtZm9yd2FyZGluZy5jOm9mb25vX2NhbGxfZm9yd2FyZGluZ19kcml2ZXJfcmVn aXN0ZXIoKSBkcml2ZXI6IDB4ODE5NWI0MCwgbmFtZTogaXNpbW9kZW0NCm9mb25vZFszMDVdOiBz cmMvY2FsbC1zZXR0aW5ncy5jOm9mb25vX2NhbGxfc2V0dGluZ3NfZHJpdmVyX3JlZ2lzdGVyKCkg ZHJpdmVyOiAweDgxOTViNjAsIG5hbWU6IGlzaW1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL2NhbGwt YmFycmluZy5jOm9mb25vX2NhbGxfYmFycmluZ19kcml2ZXJfcmVnaXN0ZXIoKSBkcml2ZXI6IDB4 ODE5NWI5MCwgbmFtZTogaXNpbW9kZW0NCm9mb25vZFszMDVdOiBzcmMvY2FsbC1tZXRlci5jOm9m b25vX2NhbGxfbWV0ZXJfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTViYzAsIG5hbWU6 IGlzaW1vZGVtDQpvZm9ub2RbMzA1XTogc3JjL3JhZGlvLXNldHRpbmdzLmM6b2Zvbm9fcmFkaW9f c2V0dGluZ3NfZHJpdmVyX3JlZ2lzdGVyKCkgZHJpdmVyOiAweDgxOTVjMDAsIG5hbWU6IGlzaW1v ZGVtDQpvZm9ub2RbMzA1XTogc3JjL2dwcnMuYzpvZm9ub19ncHJzX2RyaXZlcl9yZWdpc3Rlcigp IGRyaXZlcjogMHg4MTk1YzI4LCBuYW1lOiBpc2ltb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9ncHJz LmM6b2Zvbm9fZ3Byc19jb250ZXh0X2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk1YzNj LCBuYW1lOiBpc2ltb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9hdWRpby1zZXR0aW5ncy5jOm9mb25v X2F1ZGlvX3NldHRpbmdzX2RyaXZlcl9yZWdpc3RlcigpIGRyaXZlcjogMHg4MTk1YzU0LCBuYW1l OiBpc2ltb2RlbQ0Kb2Zvbm9kWzMwNV06IHNyYy9zaW0uYzpvZm9ub19zaW1fZHJpdmVyX3JlZ2lz dGVyKCkgZHJpdmVyOiAweDgxOTVjNjAsIG5hbWU6IHdnbW9kZW0yLjUNCm9mb25vZFszMDVdOiBw bHVnaW5zL3VkZXZuZy5jOnVkZXZfc3RhcnQoKQ0Kb2Zvbm9kWzMwNV06IHBsdWdpbnMvdWRldm5n LmM6ZW51bWVyYXRlX2RldmljZXMoKQ0Kb2Zvbm9kWzMwNV06IHBsdWdpbnMvaGZwX2hmX2JsdWV6 NS5jOmNvbm5lY3RfaGFuZGxlcigpIFJlZ2lzdGVyaW5nIEV4dGVybmFsIFByb2ZpbGUgaGFuZGxl ciAuLi4NCm9mb25vZFszMDVdOiBwbHVnaW5zL2JsdWV6NS5jOmJ0X3JlZ2lzdGVyX3Byb2ZpbGUo KSBCbHVldG9vdGg6IFJlZ2lzdGVyaW5nIDAwMDAxMTFlLTAwMDAtMTAwMC04MDAwLTAwODA1Zjli MzRmYiAoaGZwX2hmKSBwcm9maWxlDQpvZm9ub2RbMzA1XTogcGx1Z2lucy9ibHVlejUuYzpwcm9m aWxlX3JlZ2lzdGVyX2NiKCkNCg0K --===============3748098787592709802==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============6128112288158520560==" MIME-Version: 1.0 From: Kallumari Nagaraja Rao, RammohanX Subject: RE: query Date: Wed, 29 Jul 2015 13:12:10 +0000 Message-ID: <222E70FA67D72A4FB8EEDF5AF01724ACCF24B7@BGSMSX102.gar.corp.intel.com> In-Reply-To: <222E70FA67D72A4FB8EEDF5AF01724ACCF22F3@BGSMSX102.gar.corp.intel.com> List-Id: To: ofono@ofono.org --===============6128112288158520560== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello All, As said below, I am using the Intel Edison board with a Ublox on a serial i= nterface. After doing some debugging got to know that the "/plugins/udevng.c:enumerat= e_devices()" does get struck and nothing happens after that. The function "udev_enumerate_get_list_entry" under "enumerate_devices" does= not Seem to return properly and there after nothing happens. 1. Check_device/check_usb_device does not get called 2. Create_modem won't happen. Please let me know if this is some issue with the udev libraries or somethi= ng else. Regards, Ram. From: ofono [mailto:ofono-bounces(a)ofono.org] On Behalf Of Kallumari Nagar= aja Rao, RammohanX Sent: Tuesday, July 28, 2015 2:58 PM To: ofono(a)ofono.org Subject: query Hi All, I am trying to get ofono running on my Intel Edison board. We have Intel Arduino Board with Ublox Sara-G350 connected via ttyMFD1 devi= ce. 1. Placed necessary configuration files at the needed places. a. Ofono.conf b. Tun.conf c. Ofono.rules 2. Updated ofono.rules with the following, # Ublox SARA-G350 ATTRS{idVendor}=3D=3D"1546", ATTRS{idProduct}=3D=3D"1102", ENV{OFONO_DRIVER= }=3D"ublox" 3. tun.conf into modules-load.d, but when I do lsmod I do not see module= tun being loaded ! 4. when I try running ofonod, I get struck at BT stuff as attached. Please let me know if I am missing something. Regards, Ram. --===============6128112288158520560== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+CjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+ PCEtLQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseTpDYWxp YnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9udC1m YW1pbHk6VGFob21hOwoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQpAZm9udC1mYWNl Cgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsKCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30K QGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgQ29uc29sZSI7CglwYW5vc2UtMToyIDEx IDYgOSA0IDUgNCAyIDIgNDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGluOwoJbWFyZ2luLWJvdHRvbTou MDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 OwoJY29sb3I6Ymx1ZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpw dXJwbGU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KcC5Nc29MaXN0UGFyYWdyYXBoLCBs aS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaAoJe21zby1zdHlsZS1wcmlv cml0eTozNDsKCW1hcmdpbi10b3A6MGluOwoJbWFyZ2luLXJpZ2h0OjBpbjsKCW1hcmdpbi1ib3R0 b206MGluOwoJbWFyZ2luLWxlZnQ6LjVpbjsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQt c2l6ZToxMS4wcHQ7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30Kc3Bhbi5F bWFpbFN0eWxlMTgKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsKCWZvbnQtZmFtaWx5OiJWZXJk YW5hIiwic2Fucy1zZXJpZiI7Cgljb2xvcjp3aW5kb3d0ZXh0O30Kc3Bhbi5FbWFpbFN0eWxlMTkK CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsKCWZvbnQtZmFtaWx5OiJWZXJkYW5hIiwi c2Fucy1zZXJpZiI7Cgljb2xvcjojMUY0OTdEO30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsKCWZvbnQtc2l6ZToxMC4wcHQ7fQpAcGFnZSBXb3JkU2VjdGlvbjEK CXtzaXplOjguNWluIDExLjBpbjsKCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9CmRp di5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci8qIExpc3QgRGVmaW5pdGlvbnMg Ki8KQGxpc3QgbDAKCXttc28tbGlzdC1pZDoxMzQ0OTUxMjg7Cgltc28tbGlzdC10eXBlOmh5YnJp ZDsKCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzU0MTUxMzE2IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1O30KQGxpc3QgbDA6bGV2ZWwxCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlzdCBsMDps ZXZlbDIKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10 YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRl bnQ6LS4yNWluO30KQGxpc3QgbDA6bGV2ZWwzCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMDpsZXZlbDQKCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRl eHQtaW5kZW50Oi0uMjVpbjt9CkBsaXN0IGwwOmxldmVsNQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlzdCBsMDpsZXZlbDYK CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3Rv cDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50Oi05 LjBwdDt9CkBsaXN0IGwwOmxldmVsNwoJe21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDA6 bGV2ZWw4Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5k ZW50Oi0uMjVpbjt9CkBsaXN0IGwwOmxldmVsOQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDEKCXttc28tbGlzdC1p ZDoyMDUyOTIxNjQ3OwoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTk4MTU4NTkzNiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwxOmxldmVsMQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 OwoJdGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDE6bGV2ZWwyCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0uMjVpbjt9CkBsaXN0IGwxOmxl dmVsMwoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRl bnQ6LTkuMHB0O30KQGxpc3QgbDE6bGV2ZWw0Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlz dCBsMTpsZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1s ZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4 dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDE6bGV2ZWw2Cgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMTpsZXZlbDcK CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsKCXRleHQtaW5kZW50Oi0uMjVpbjt9CkBsaXN0IGwxOmxldmVsOAoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlzdCBsMTps ZXZlbDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10 YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5k ZW50Oi05LjBwdDt9Cm9sCgl7bWFyZ2luLWJvdHRvbTowaW47fQp1bAoJe21hcmdpbi1ib3R0b206 MGluO30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4KPC9oZWFkPgo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBBbGwsPG86cD48L286cD48 L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMg c2FpZCBiZWxvdywgSSBhbSB1c2luZyB0aGUgSW50ZWwgRWRpc29uIGJvYXJkIHdpdGggYSBVYmxv eCBvbiBhIHNlcmlhbCBpbnRlcmZhY2UuPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWZ0ZXIgZG9pbmcgc29tZSBkZWJ1Z2dp bmcgZ290IHRvIGtub3cgdGhhdCB0aGUgJiM4MjIwOy9wbHVnaW5zL3VkZXZuZy5jOmVudW1lcmF0 ZV9kZXZpY2VzKCkmIzgyMjE7IGRvZXMgZ2V0IHN0cnVjayBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5ub3RoaW5nIGhhcHBlbnMgYWZ0ZXIgdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZnVuY3Rp b24gJiM4MjIwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90OyI+dWRldl9lbnVtZXJhdGVfZ2V0X2xpc3RfZW50 cnk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjODIy MTsKIHVuZGVyICYjODIyMDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDsiPmVudW1lcmF0ZV9kZXZpY2VzPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzgyMjE7IGRv ZXMgbm90PG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VlbSB0byByZXR1cm4gcHJvcGVy bHkgYW5kIHRoZXJlIGFmdGVyIG5vdGhpbmcgaGFwcGVucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWNrX2RldmljZS9jaGVja191 c2JfZGV2aWNlIGRvZXMgbm90IGdldCBjYWxsZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNyZWF0ZV9tb2RlbSB3b24mIzgyMTc7dCBo YXBwZW4uPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgaXMgc29tZSBpc3N1ZSB3 aXRoIHRoZSB1ZGV2IGxpYnJhcmllcyBvciBzb21ldGhpbmcgZWxzZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJhbS48bzpwPjwvbzpwPjwv c3Bhbj48L3U+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4K PGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gb2Zvbm8gW21haWx0bzpvZm9uby1ib3VuY2VzQG9mb25vLm9yZ10KPGI+ T24gQmVoYWxmIE9mIDwvYj5LYWxsdW1hcmkgTmFnYXJhamEgUmFvLCBSYW1tb2hhblg8YnI+Cjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDI4LCAyMDE1IDI6NTggUE08YnI+CjxiPlRvOjwvYj4g b2Zvbm9Ab2Zvbm8ub3JnPGJyPgo8Yj5TdWJqZWN0OjwvYj4gcXVlcnk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBhbSB0cnlpbmcg dG8gZ2V0IG9mb25vIHJ1bm5pbmcgb24gbXkgSW50ZWwgRWRpc29uIGJvYXJkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2UgaGF2ZSBJbnRlbCBBcmR1aW5vIEJvYXJkIHdp dGggVWJsb3ggU2FyYS1HMzUwIGNvbm5lY3RlZCB2aWEgdHR5TUZEMSBkZXZpY2UuPG86cD48L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QbGFjZWQgbmVjZXNz YXJ5IGNvbmZpZ3VyYXRpb24gZmlsZXMgYXQgdGhlIG5lZWRlZCBwbGFjZXMuPG86cD48L286cD48 L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+CjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PZm9uby5jb25mPG86cD48L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+Cjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UdW4uY29uZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzIiPgo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T2Zvbm8ucnVsZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VXBkYXRlZCBvZm9uby5ydWxlcyB3aXRoIHRoZSBm b2xsb3dpbmcsPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4jIFVibG94 IFNBUkEtRzM1MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QVRUUlN7 aWRWZW5kb3J9PT0mcXVvdDsxNTQ2JnF1b3Q7LCBBVFRSU3tpZFByb2R1Y3R9PT0mcXVvdDsxMTAy JnF1b3Q7LCBFTlZ7T0ZPTk9fRFJJVkVSfT0mcXVvdDt1YmxveCZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij50dW4uY29uZiBpbnRvIG1vZHVsZXMtbG9hZC5kLCBidXQgd2hlbiBJ IGRvIGxzbW9kIEkgZG8gbm90IHNlZSBtb2R1bGUgdHVuIGJlaW5nIGxvYWRlZCAhPG86cD48L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPndoZW4gSSB0cnkgcnVubmluZyBvZm9ub2QsIEkgZ2V0IHN0 cnVjayBhdCBCVCBzdHVmZiBhcyBhdHRhY2hlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlBsZWFzZSBsZXQgbWUga25vdyBpZiBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+UmFtLjxvOnA+PC9vOnA+PC9zcGFuPjwvdT48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+Cg== --===============6128112288158520560==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7718174762224309692==" MIME-Version: 1.0 From: Denis Kenzior Subject: Re: query Date: Wed, 29 Jul 2015 10:23:59 -0500 Message-ID: <55B8F00F.5030703@gmail.com> In-Reply-To: <222E70FA67D72A4FB8EEDF5AF01724ACCF22F3@BGSMSX102.gar.corp.intel.com> List-Id: To: ofono@ofono.org --===============7718174762224309692== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Ram, On 07/28/2015 04:27 AM, Kallumari Nagaraja Rao, RammohanX wrote: > Hi All, > > I am trying to get ofono running on my Intel Edison board. > > We have Intel Arduino Board with Ublox Sara-G350 connected via ttyMFD1 > device. > > 1.Placed necessary configuration files at the needed places. > > a.Ofono.conf > > b.Tun.conf > > c.Ofono.rules > > 2.Updated ofono.rules with the following, > > # Ublox SARA-G350 > > ATTRS{idVendor}=3D=3D"1546", ATTRS{idProduct}=3D=3D"1102", ENV{OFONO_DRIV= ER}=3D"ublox" > I don't know what this is doing, but in general ofono.rules is only used = for pure-serial devices. ublox driver is only setup to work via USB. = Is your modem hardware USB based? > 3.tun.conf into modules-load.d, but when I do lsmod I do not see module > tun being loaded ! > > 4.when I try running ofonod, I get struck at BT stuff as attached. > > Please let me know if I am missing something. > Regards, -Denis --===============7718174762224309692==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7982998440899348870==" MIME-Version: 1.0 From: Denis Kenzior Subject: Re: query Date: Wed, 29 Jul 2015 10:27:03 -0500 Message-ID: <55B8F0C7.6020807@gmail.com> In-Reply-To: <222E70FA67D72A4FB8EEDF5AF01724ACCF24B7@BGSMSX102.gar.corp.intel.com> List-Id: To: ofono@ofono.org --===============7982998440899348870== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Ram, On 07/29/2015 08:12 AM, Kallumari Nagaraja Rao, RammohanX wrote: > Hello All, > > As said below, I am using the Intel Edison board with a Ublox on a > serial interface. > > After doing some debugging got to know that the > =E2=80=9C/plugins/udevng.c:enumerate_devices()=E2=80=9D does get struck a= nd > > nothing happens after that. Since you have debug output after enumerate_devices() is called, this is = highly unlikely. Does your kernel support udev? You need to get your = kernel and system sorted out first. Regards, -Denis --===============7982998440899348870==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3857821206127504795==" MIME-Version: 1.0 From: Kallumari Nagaraja Rao, RammohanX Subject: RE: query Date: Thu, 30 Jul 2015 04:03:44 +0000 Message-ID: <222E70FA67D72A4FB8EEDF5AF01724ACCF259F@BGSMSX102.gar.corp.intel.com> In-Reply-To: <55B8F00F.5030703@gmail.com> List-Id: