From owner-freebsd-mips@FreeBSD.ORG Mon Jul 19 01:58:35 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A28106564A for ; Mon, 19 Jul 2010 01:58:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 22ED38FC14 for ; Mon, 19 Jul 2010 01:58:34 +0000 (UTC) Received: by iwn35 with SMTP id 35so5151928iwn.13 for ; Sun, 18 Jul 2010 18:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=aJvQCsTgKOJ7A6birC+r4VusywhovuViIL4ZuJ9VXk4=; b=rRDY3/hyAYA9Ofc8Z28dxKi6Qt/8v0mwVWhF/EcQlhEm35SKR7N/jD1q7Ta6Gq3fdX Z7c5G9mAXTj6csvJUS8Pk4MEFZKBpBlsnBW6fokXtUCmu+FCZpnu0CjawzmpkcOD20LA GH9F4OsGA6e1gx/8p/TCNswtFSWO0goWpmIac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EtX+4aAw2cCHOUL+tbKV7uF+ICHN2yS9X0IHQKxcspI98ffzJtuXBzmzpfVdaDB8/u bkR5DCPmIedYLUtZaRVF306pdp8TCg7lWw4k7i++t/ojeZlb66HtU7CYOfP+Z5tifmdS DUtjCGB+3j9RGYgT3dDCT1dQhnzmhthrivE3k= MIME-Version: 1.0 Received: by 10.231.148.195 with SMTP id q3mr4945209ibv.199.1279504714540; Sun, 18 Jul 2010 18:58:34 -0700 (PDT) Received: by 10.231.152.79 with HTTP; Sun, 18 Jul 2010 18:58:34 -0700 (PDT) Date: Mon, 19 Jul 2010 09:58:34 +0800 Message-ID: From: Adrian Chadd To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [patch]: probe extended device id for flash; support multiple S25* flash devices X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 01:58:35 -0000 Hi, According to the linux driver, the S25* series have multiple sector sizes for the same storage size (16 meg.) These devices share the same jedec manufacturer/device ids; they only differ on the extended device id. I've attemped to probe the extended device id (inspired by the linux probe routine) by trying to read two more bytes during the flash IDENT command. I've added extended id's for the four S25* devices found in the relevant linux flash driver. I don't have anything which supports the extended device id like this so I'd like some testing by someone who does before I commit it. The patch: http://people.freebsd.org/~adrian/rspro/mx25l_ext_id.diff Thanks, Adrian From owner-freebsd-mips@FreeBSD.ORG Mon Jul 19 07:19:35 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 305E6106564A for ; Mon, 19 Jul 2010 07:19:35 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2F48FC12 for ; Mon, 19 Jul 2010 07:19:33 +0000 (UTC) Received: by vws19 with SMTP id 19so5429338vws.13 for ; Mon, 19 Jul 2010 00:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=wZpykJ/7qYvFW6KAWuNxKlDeZ38akKiA6uyr18gxpw4=; b=nRa9GJV8orJQfQC0Ce6Q/pJJf3ZCcI3M6WSqVGs9+Zb2ho2L+Fj2zbH/s0S4bWCkCa oK63GCRfe8ZiwqLiXo1JPy2F21lor3Oa84iyVq1dyy8xDsO+BHmb7Y7NJDTWPXtp3zzh NY4U66yCIxNCxJbIkKahU4JTffQWraCZMSPgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X99GNEkipFSO9hclDD3T8W2npuJ0297bnBnXOxEzciQcjdAcvo78M/uwnAek0oTvG7 LkRrWhcu4zUd2qSXQivFpfO03jlZbGX9kOwbM5liLg61+YxGmF1VURAvYOxFo8gdYQ6O Q8y+W5FlDoqEkOezJuShlcJdX6uetRnvwjAko= MIME-Version: 1.0 Received: by 10.220.163.10 with SMTP id y10mr2763553vcx.63.1279523580911; Mon, 19 Jul 2010 00:13:00 -0700 (PDT) Received: by 10.220.188.138 with HTTP; Mon, 19 Jul 2010 00:13:00 -0700 (PDT) In-Reply-To: <4C3E0144.50402@cs.rice.edu> References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <4C0DE424.9080601@cs.rice.edu> <4C3E0144.50402@cs.rice.edu> Date: Mon, 19 Jul 2010 12:43:00 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: multipart/mixed; boundary=0014853d013085a1e1048bb84c56 Cc: freebsd-mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 07:19:35 -0000 --0014853d013085a1e1048bb84c56 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 14, 2010 at 11:56 PM, Alan Cox wrote: [....] > This makes sense. =A0I have the following requests. =A0All but 1.a. are s= imple, > mechanical changes. > > 1. Move vm_phys_page_alloc() to vm_page.c and rename it to > vm_page_alloc_freelist(). > > 1.a. The new vm_page_alloc_freelist() should really have a "req" paramete= r > like vm_page_alloc() and duplicate the following from vm_page_alloc(): > > =A0 mtx_lock(&vm_page_queue_free_mtx); > =A0 if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || > =A0 =A0 =A0 (page_req =3D=3D VM_ALLOC_SYSTEM && > =A0 =A0 =A0 cnt.v_free_count + cnt.v_cache_count > cnt.v_interrupt_free_m= in) || > =A0 =A0 =A0 (page_req =3D=3D VM_ALLOC_INTERRUPT && > =A0 =A0 =A0 cnt.v_free_count + cnt.v_cache_count > 0)) { > > In essence, user page table page allocation shouldn't be allowed to alloc= ate > the last available page. =A0Only pmap_growkernel() should use > VM_ALLOC_INTERRUPT. =A0(See either the amd64 or i386 pmap.) > > You could also drop the "pool" parameter and pass VM_FREEPOOL_DIRECT to > vm_phys_alloc_freelist_pages() from vm_page_alloc_freelist(). =A0(This is > consistent with what vm_page_alloc() does for VM_ALLOC_NOOBJ.) > > 2. Move vm_page_alloc_init() to vm_page.c as well. =A0(And add it to > vm_page.h.) > > 3. Make vm_phys_alloc_freelist_pages() extern. > > >> Since I had originally added the UMA zone for =A0page table >> pages for MIPS, which has the issues you had noted, I would like to >> fix this... > > > The patch introduces a few unnecessary blank lines. =A0Can you please rem= ove > these: [...] > > FreeBSD style(9) requires parentheses around the "m": [...] > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return m; [freebsd-mips cc-ed, for comments on MIPS side] Here's is the updated patch with the review comments taken care of. I have been testing this on MIPS, could not see any regression so far. -- Redo the page table page allocation on MIPS, based on suggestion from alc@. The current UMA zone based allocation can be replaced by a scheme that creates a new free list for the KSEG0 region, and a new function in sys/vm to allocate pages from a specific free page list. The changes are : - Revert the earlier changes in MIPS pmap.c that added UMA zone for page table pages. - Add a new freelist VM_FREELIST_HIGHMEM to vmparam.h for memory that is not directly mapped (in 32bit compilation). Normal page allocations will first try the HIGHMEM freelist and then the default freelist (which is for the KSEG0 direct mapped memory). - Add a new function 'vm_page_t vm_page_alloc_freelist(int flind, int order, int req)' to vm/vm_page.c to allocate a page from a specified freelist. The MIPS page table pages will be allocated using this function from the KSEG0 freelist. - Move the page initialization code from vm_phys_alloc_contig() to a new function vm_page_alloc_init(), and use this function to initialize pages in vm_page_alloc_freelist() too. - Split the vm_phys_alloc_pages(pool, order) to create vm_phys_alloc_freelist_pages(int flind, int pool, int order), and use this function from both vm_page_alloc_freelist() and vm_phys_alloc_pages(). -- Thanks, JC. --0014853d013085a1e1048bb84c56 Content-Type: text/x-patch; charset=US-ASCII; name="pmap-pagetable-page-alloc.patch" Content-Disposition: attachment; filename="pmap-pagetable-page-alloc.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gbsz8bmo0 SW5kZXg6IHN5cy9taXBzL2luY2x1ZGUvdm1wYXJhbS5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9taXBz L2luY2x1ZGUvdm1wYXJhbS5oCShyZXZpc2lvbiAyMTAxNTcpCisrKyBzeXMvbWlwcy9pbmNsdWRl L3ZtcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtMTEwLDYgKzExMCw3IEBACiAjZGVmaW5lCVZN X01BWFVTRVJfQUREUkVTUwkoKHZtX29mZnNldF90KTB4ODAwMDAwMDApCiAjZGVmaW5lCVZNX01J Tl9LRVJORUxfQUREUkVTUwkoKHZtX29mZnNldF90KTB4QzAwMDAwMDApCiAjZGVmaW5lCVZNX01B WF9LRVJORUxfQUREUkVTUwkoKHZtX29mZnNldF90KTB4RkZGRkMwMDApCisjZGVmaW5lCVZNX0hJ R0hNRU1fQUREUkVTUwkoKHZtX3BhZGRyX3QpMHgyMDAwMDAwMCkKICNlbmRpZgogI2lmIDAKICNk ZWZpbmUJS0VSTkJBU0UJCShWTV9NSU5fS0VSTkVMX0FERFJFU1MpCkBAIC0xMjUsNyArMTI2LDYg QEAKICNkZWZpbmUJVk1fTlJFU0VSVkxFVkVMCQkwCiAjZW5kaWYKIAotCiAvKiB2aXJ0dWFsIHNp emVzIChieXRlcykgZm9yIHZhcmlvdXMga2VybmVsIHN1Ym1hcHMgKi8KICNpZm5kZWYgVk1fS01F TV9TSVpFCiAjZGVmaW5lCVZNX0tNRU1fU0laRQkJKDEyICogMTAyNCAqIDEwMjQpCkBAIC0xNzQs MTMgKzE3NCwxOSBAQAogI2RlZmluZQlWTV9GUkVFUE9PTF9ESVJFQ1QJMQogCiAvKgotICogd2Ug c3VwcG9ydCAxIGZyZWUgbGlzdDoKKyAqIHdlIHN1cHBvcnQgMiBmcmVlIGxpc3RzOgogICoKLSAq CS0gREVGQVVMVCBmb3IgYWxsIHN5c3RlbXMKKyAqCS0gREVGQVVMVCBmb3IgZGlyZWN0IG1hcHBl ZCAoS1NFRzApIHBhZ2VzCisgKgktIEhJR0hNRU0gZm9yIG90aGVyIHBhZ2VzIAogICovCi0KKyNp ZmRlZiBfX21pcHNfbjY0CiAjZGVmaW5lCVZNX05GUkVFTElTVAkJMQogI2RlZmluZQlWTV9GUkVF TElTVF9ERUZBVUxUCTAKKyNlbHNlCisjZGVmaW5lCVZNX05GUkVFTElTVAkJMgorI2RlZmluZQlW TV9GUkVFTElTVF9ERUZBVUxUCTEKKyNkZWZpbmUJVk1fRlJFRUxJU1RfSElHSE1FTQkwCisjZW5k aWYKIAogLyoKICAqIFRoZSBsYXJnZXN0IGFsbG9jYXRpb24gc2l6ZSBpcyAxTUIuCkluZGV4OiBz eXMvbWlwcy9taXBzL3BtYXAuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbWlwcy9taXBzL3BtYXAuYwko cmV2aXNpb24gMjEwMTU3KQorKysgc3lzL21pcHMvbWlwcy9wbWFwLmMJKHdvcmtpbmcgY29weSkK QEAgLTE4Nyw4ICsxODcsOCBAQAogc3RhdGljIHZtX3BhZ2VfdCBfcG1hcF9hbGxvY3B0ZShwbWFw X3QgcG1hcCwgdW5zaWduZWQgcHRlcGluZGV4LCBpbnQgZmxhZ3MpOwogc3RhdGljIGludCBwbWFw X3VudXNlX3B0KHBtYXBfdCwgdm1fb2Zmc2V0X3QsIHZtX3BhZ2VfdCk7CiBzdGF0aWMgaW50IGlu aXRfcHRlX3Byb3Qodm1fb2Zmc2V0X3QgdmEsIHZtX3BhZ2VfdCBtLCB2bV9wcm90X3QgcHJvdCk7 Ci1zdGF0aWMgdm1fcGFnZV90IHBtYXBfYWxsb2NfcHRlX3BhZ2UocG1hcF90LCB1bnNpZ25lZCBp bnQsIGludCwgdm1fb2Zmc2V0X3QgKik7Ci1zdGF0aWMgdm9pZCBwbWFwX3JlbGVhc2VfcHRlX3Bh Z2Uodm1fcGFnZV90KTsKK3N0YXRpYyB2bV9wYWdlX3QgcG1hcF9hbGxvY19wdGVfcGFnZSh1bnNp Z25lZCBpbnQgaW5kZXgsIGludCByZXEpOworc3RhdGljIHZvaWQgcG1hcF9ncm93X3B0ZV9wYWdl X2NhY2hlKHZvaWQpOwogCiAjaWZkZWYgU01QCiBzdGF0aWMgdm9pZCBwbWFwX2ludmFsaWRhdGVf cGFnZV9hY3Rpb24odm9pZCAqYXJnKTsKQEAgLTE5NiwxMCArMTk2LDYgQEAKIHN0YXRpYyB2b2lk IHBtYXBfdXBkYXRlX3BhZ2VfYWN0aW9uKHZvaWQgKmFyZyk7CiAjZW5kaWYKIAotc3RhdGljIHZv aWQgcG1hcF9wdHBnem9uZV9kdG9yKHZvaWQgKm1lbSwgaW50IHNpemUsIHZvaWQgKmFyZyk7Ci1z dGF0aWMgdm9pZCAqcG1hcF9wdHBnem9uZV9hbGxvY2YodW1hX3pvbmVfdCwgaW50LCB1X2ludDhf dCAqLCBpbnQpOwotc3RhdGljIHVtYV96b25lX3QgcHRwZ3pvbmU7Ci0KICNpZiAhZGVmaW5lZChf X21pcHNfbjY0KQogc3RydWN0IGxvY2FsX3N5c21hcHMgewogCXZtX29mZnNldF90IGJhc2U7CkBA IC01MzksMTAgKzUzNSw2IEBACiAJcHZfZW50cnlfbWF4ID0gUE1BUF9TSFBHUEVSUFJPQyAqIG1h eHByb2MgKyBjbnQudl9wYWdlX2NvdW50OwogCXB2X2VudHJ5X2hpZ2hfd2F0ZXIgPSA5ICogKHB2 X2VudHJ5X21heCAvIDEwKTsKIAl1bWFfem9uZV9zZXRfb2JqKHB2em9uZSwgJnB2em9uZV9vYmos IHB2X2VudHJ5X21heCk7Ci0KLQlwdHBnem9uZSA9IHVtYV96Y3JlYXRlKCJQVCBFTlRSWSIsIFBB R0VfU0laRSwgTlVMTCwgcG1hcF9wdHBnem9uZV9kdG9yLAotCSAgICBOVUxMLCBOVUxMLCBQQUdF X1NJWkUgLSAxLCBVTUFfWk9ORV9OT0ZSRUUgfCBVTUFfWk9ORV9aSU5JVCk7Ci0JdW1hX3pvbmVf c2V0X2FsbG9jZihwdHBnem9uZSwgcG1hcF9wdHBnem9uZV9hbGxvY2YpOwogfQogCiAvKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCkBAIC04ODIsMTIg Kzg3NCw4IEBACiAJLyoKIAkgKiBJZiB0aGUgcGFnZSBpcyBmaW5hbGx5IHVud2lyZWQsIHNpbXBs eSBmcmVlIGl0LgogCSAqLworCXZtX3BhZ2VfZnJlZV96ZXJvKG0pOwogCWF0b21pY19zdWJ0cmFj dF9pbnQoJmNudC52X3dpcmVfY291bnQsIDEpOwotCVBNQVBfVU5MT0NLKHBtYXApOwotCXZtX3Bh Z2VfdW5sb2NrX3F1ZXVlcygpOwotCXBtYXBfcmVsZWFzZV9wdGVfcGFnZShtKTsKLQl2bV9wYWdl X2xvY2tfcXVldWVzKCk7Ci0JUE1BUF9MT0NLKHBtYXApOwogCXJldHVybiAoMSk7CiB9CiAKQEAg LTk0Nyw5NSArOTM1LDMwIEBACiB9CiAKIHN0YXRpYyB2b2lkCi1wbWFwX3B0cGd6b25lX2R0b3Io dm9pZCAqbWVtLCBpbnQgc2l6ZSwgdm9pZCAqYXJnKQorcG1hcF9ncm93X3B0ZV9wYWdlX2NhY2hl KCkKIHsKLSNpZmRlZiBJTlZBUklBTlRTCi0Jc3RhdGljIGNoYXIgemVyb3BhZ2VbUEFHRV9TSVpF XTsKLQotCUtBU1NFUlQoc2l6ZSA9PSBQQUdFX1NJWkUsCi0JCSgicG1hcF9wdHBnem9uZV9kdG9y OiBpbnZhbGlkIHNpemUgJWQiLCBzaXplKSk7Ci0JS0FTU0VSVChiY21wKG1lbSwgemVyb3BhZ2Us IFBBR0VfU0laRSkgPT0gMCwKLQkJKCJwbWFwX3B0cGd6b25lX2R0b3I6IGZyZWVpbmcgYSBub24t emVyb2VkIHBhZ2UiKSk7Ci0jZW5kaWYKKwl2bV9jb250aWdfZ3Jvd19jYWNoZSgzLCAwLCBNSVBT X0tTRUcwX0xBUkdFU1RfUEhZUyk7CiB9CiAKLXN0YXRpYyB2b2lkICoKLXBtYXBfcHRwZ3pvbmVf YWxsb2NmKHVtYV96b25lX3Qgem9uZSwgaW50IGJ5dGVzLCB1X2ludDhfdCAqZmxhZ3MsIGludCB3 YWl0KQotewotCXZtX3BhZ2VfdCBtOwotCXZtX3BhZGRyX3QgcGFkZHI7Ci0JaW50IHRyaWVzOwot CQotCUtBU1NFUlQoYnl0ZXMgPT0gUEFHRV9TSVpFLAotCQkoInBtYXBfcHRwZ3pvbmVfYWxsb2Nm OiBpbnZhbGlkIGFsbG9jYXRpb24gc2l6ZSAlZCIsIGJ5dGVzKSk7Ci0KLQkqZmxhZ3MgPSBVTUFf U0xBQl9QUklWOwotCXRyaWVzID0gMDsKLXJldHJ5OgotCW0gPSB2bV9waHlzX2FsbG9jX2NvbnRp ZygxLCAwLCBNSVBTX0tTRUcwX0xBUkdFU1RfUEhZUywKLQkgICAgUEFHRV9TSVpFLCBQQUdFX1NJ WkUpOwotCWlmIChtID09IE5VTEwpIHsKLSAgICAgICAgICAgICAgICBpZiAodHJpZXMgPCAoKHdh aXQgJiBNX05PV0FJVCkgIT0gMCA/IDEgOiAzKSkgewotCQkJdm1fY29udGlnX2dyb3dfY2FjaGUo dHJpZXMsIDAsIE1JUFNfS1NFRzBfTEFSR0VTVF9QSFlTKTsKLQkJCXRyaWVzKys7Ci0JCQlnb3Rv IHJldHJ5OwotCQl9IGVsc2UKLQkJCXJldHVybiAoTlVMTCk7Ci0JfQotCi0JcGFkZHIgPSBWTV9Q QUdFX1RPX1BIWVMobSk7Ci0JcmV0dXJuICgodm9pZCAqKU1JUFNfUEhZU19UT19LU0VHMChwYWRk cikpOwotfQkKLQogc3RhdGljIHZtX3BhZ2VfdAotcG1hcF9hbGxvY19wdGVfcGFnZShwbWFwX3Qg cG1hcCwgdW5zaWduZWQgaW50IGluZGV4LCBpbnQgd2FpdCwgdm1fb2Zmc2V0X3QgKnZhcCkKK3Bt YXBfYWxsb2NfcHRlX3BhZ2UodW5zaWduZWQgaW50IGluZGV4LCBpbnQgcmVxKQogewotCXZtX3Bh ZGRyX3QgcGFkZHI7Ci0Jdm9pZCAqdmE7CiAJdm1fcGFnZV90IG07Ci0JaW50IGxvY2tlZDsKIAot CWxvY2tlZCA9IG10eF9vd25lZCgmcG1hcC0+cG1fbXR4KTsKLQlpZiAobG9ja2VkKSB7Ci0JCW10 eF9hc3NlcnQoJnZtX3BhZ2VfcXVldWVfbXR4LCBNQV9PV05FRCk7Ci0JCVBNQVBfVU5MT0NLKHBt YXApOwotCQl2bV9wYWdlX3VubG9ja19xdWV1ZXMoKTsKLQl9Ci0JdmEgPSB1bWFfemFsbG9jKHB0 cGd6b25lLCB3YWl0KTsKLQlpZiAobG9ja2VkKSB7Ci0JCXZtX3BhZ2VfbG9ja19xdWV1ZXMoKTsK LQkJUE1BUF9MT0NLKHBtYXApOwotCX0KLQlpZiAodmEgPT0gTlVMTCkKKwltID0gdm1fcGFnZV9h bGxvY19mcmVlbGlzdChWTV9GUkVFTElTVF9ERUZBVUxULCAwLCByZXEpOworCWlmIChtID09IE5V TEwpCiAJCXJldHVybiAoTlVMTCk7CiAKLQlwYWRkciA9IE1JUFNfS1NFRzBfVE9fUEhZUyh2YSk7 Ci0JbSA9IFBIWVNfVE9fVk1fUEFHRShwYWRkcik7Ci0JCi0JaWYgKCFsb2NrZWQpCi0JCXZtX3Bh Z2VfbG9ja19xdWV1ZXMoKTsKKwlpZiAoKG0tPmZsYWdzICYgUEdfWkVSTykgPT0gMCkKKwkJcG1h cF96ZXJvX3BhZ2UobSk7CisKIAltLT5waW5kZXggPSBpbmRleDsKIAltLT52YWxpZCA9IFZNX1BB R0VfQklUU19BTEw7Ci0JbS0+d2lyZV9jb3VudCA9IDE7Ci0JaWYgKCFsb2NrZWQpCi0JCXZtX3Bh Z2VfdW5sb2NrX3F1ZXVlcygpOwotCiAJYXRvbWljX2FkZF9pbnQoJmNudC52X3dpcmVfY291bnQs IDEpOwotCSp2YXAgPSAodm1fb2Zmc2V0X3QpdmE7CisJbS0+d2lyZV9jb3VudCA9IDE7CiAJcmV0 dXJuIChtKTsKIH0KIAotc3RhdGljIHZvaWQKLXBtYXBfcmVsZWFzZV9wdGVfcGFnZSh2bV9wYWdl X3QgbSkKLXsKLQl2b2lkICp2YTsKLQl2bV9wYWRkcl90IHBhZGRyOwotCi0JcGFkZHIgPSBWTV9Q QUdFX1RPX1BIWVMobSk7Ci0JdmEgPSAodm9pZCAqKU1JUFNfUEhZU19UT19LU0VHMChwYWRkcik7 Ci0JdW1hX3pmcmVlKHB0cGd6b25lLCB2YSk7Ci19Ci0KIC8qCiAgKiBJbml0aWFsaXplIGEgcHJl YWxsb2NhdGVkIGFuZCB6ZXJvZWQgcG1hcCBzdHJ1Y3R1cmUsCiAgKiBzdWNoIGFzIG9uZSBpbiBh IHZtc3BhY2Ugc3RydWN0dXJlLgpAQCAtMTA1MiwxMCArOTc1LDEwIEBACiAJLyoKIAkgKiBhbGxv Y2F0ZSB0aGUgcGFnZSBkaXJlY3RvcnkgcGFnZQogCSAqLwotCXB0ZHBnID0gcG1hcF9hbGxvY19w dGVfcGFnZShwbWFwLCBOVVNFUlBHVEJMUywgTV9XQUlUT0ssICZwdGR2YSk7Ci0JaWYgKHB0ZHBn ID09IE5VTEwpCi0JCXJldHVybiAoMCk7CisJd2hpbGUgKChwdGRwZyA9IHBtYXBfYWxsb2NfcHRl X3BhZ2UoTlVTRVJQR1RCTFMsIFZNX0FMTE9DX05PUk1BTCkpID09IE5VTEwpCisJICAgICAgIHBt YXBfZ3Jvd19wdGVfcGFnZV9jYWNoZSgpOwogCisJcHRkdmEgPSBNSVBTX1BIWVNfVE9fS1NFRzAo Vk1fUEFHRV9UT19QSFlTKHB0ZHBnKSk7CiAJcG1hcC0+cG1fc2VndGFiID0gKHBkX2VudHJ5X3Qg KilwdGR2YTsKIAlwbWFwLT5wbV9hY3RpdmUgPSAwOwogCXBtYXAtPnBtX3B0cGhpbnQgPSBOVUxM OwpAQCAtMTA4NiwxNSArMTAwOSwyOCBAQAogCS8qCiAJICogRmluZCBvciBmYWJyaWNhdGUgYSBu ZXcgcGFnZXRhYmxlIHBhZ2UKIAkgKi8KLQltID0gcG1hcF9hbGxvY19wdGVfcGFnZShwbWFwLCBw dGVwaW5kZXgsIGZsYWdzLCAmcHRldmEpOwotCWlmIChtID09IE5VTEwpCisJaWYgKChtID0gcG1h cF9hbGxvY19wdGVfcGFnZShwdGVwaW5kZXgsIFZNX0FMTE9DX05PUk1BTCkpID09IE5VTEwpIHsK KwkJaWYgKGZsYWdzICYgTV9XQUlUT0spIHsKKwkJCVBNQVBfVU5MT0NLKHBtYXApOworCQkJdm1f cGFnZV91bmxvY2tfcXVldWVzKCk7CisJCQlwbWFwX2dyb3dfcHRlX3BhZ2VfY2FjaGUoKTsKKwkJ CXZtX3BhZ2VfbG9ja19xdWV1ZXMoKTsKKwkJCVBNQVBfTE9DSyhwbWFwKTsKKwkJfQorCisJCS8q CisJCSAqIEluZGljYXRlIHRoZSBuZWVkIHRvIHJldHJ5LglXaGlsZSB3YWl0aW5nLCB0aGUgcGFn ZQorCQkgKiB0YWJsZSBwYWdlIG1heSBoYXZlIGJlZW4gYWxsb2NhdGVkLgorCQkgKi8KIAkJcmV0 dXJuIChOVUxMKTsKKwl9CiAKIAkvKgogCSAqIE1hcCB0aGUgcGFnZXRhYmxlIHBhZ2UgaW50byB0 aGUgcHJvY2VzcyBhZGRyZXNzIHNwYWNlLCBpZiBpdAogCSAqIGlzbid0IGFscmVhZHkgdGhlcmUu CiAJICovCiAKKwlwdGV2YSA9IE1JUFNfUEhZU19UT19LU0VHMChWTV9QQUdFX1RPX1BIWVMobSkp OwogCXBtYXAtPnBtX3N0YXRzLnJlc2lkZW50X2NvdW50Kys7CiAJcG1hcC0+cG1fc2VndGFiW3B0 ZXBpbmRleF0gPSAocGRfZW50cnlfdClwdGV2YTsKIApAQCAtMTE5MCw3ICsxMTI2LDcgQEAKIAog CXB0ZHBnLT53aXJlX2NvdW50LS07CiAJYXRvbWljX3N1YnRyYWN0X2ludCgmY250LnZfd2lyZV9j b3VudCwgMSk7Ci0JcG1hcF9yZWxlYXNlX3B0ZV9wYWdlKHB0ZHBnKTsKKwl2bV9wYWdlX2ZyZWVf emVybyhwdGRwZyk7CiAJUE1BUF9MT0NLX0RFU1RST1kocG1hcCk7CiB9CiAKQEAgLTEyMDAsNyAr MTEzNiw2IEBACiB2b2lkCiBwbWFwX2dyb3drZXJuZWwodm1fb2Zmc2V0X3QgYWRkcikKIHsKLQl2 bV9vZmZzZXRfdCBwYWdldmE7CiAJdm1fcGFnZV90IG5rcGc7CiAJcHRfZW50cnlfdCAqcHRlOwog CWludCBpOwpAQCAtMTIzNSwxNCArMTE3MCwxMyBAQAogCQkvKgogCQkgKiBUaGlzIGluZGV4IGlz IGJvZ3VzLCBidXQgb3V0IG9mIHRoZSB3YXkKIAkJICovCi0JCW5rcGcgPSBwbWFwX2FsbG9jX3B0 ZV9wYWdlKGtlcm5lbF9wbWFwLCBua3B0LCBNX05PV0FJVCwgJnBhZ2V2YSk7Ci0KKyAJCW5rcGcg PSBwbWFwX2FsbG9jX3B0ZV9wYWdlKG5rcHQsIFZNX0FMTE9DX0lOVEVSUlVQVCk7CiAJCWlmICgh bmtwZykKIAkJCXBhbmljKCJwbWFwX2dyb3drZXJuZWw6IG5vIG1lbW9yeSB0byBncm93IGtlcm5l bCIpOwogCiAJCW5rcHQrKzsKLQkJcHRlID0gKHB0X2VudHJ5X3QgKilwYWdldmE7Ci0JCXNlZ3Rh Yl9wZGUoa2VybmVsX3NlZ21hcCwga2VybmVsX3ZtX2VuZCkgPSBwdGU7CisgCQlwdGUgPSAocHRf ZW50cnlfdCAqKU1JUFNfUEhZU19UT19LU0VHMChWTV9QQUdFX1RPX1BIWVMobmtwZykpOworICAJ CXNlZ3RhYl9wZGUoa2VybmVsX3NlZ21hcCwga2VybmVsX3ZtX2VuZCkgPSAocGRfZW50cnlfdClw dGU7CiAKIAkJLyoKIAkJICogVGhlIFJbNC03XT8wMCBzdG9yZXMgb25seSBvbmUgY29weSBvZiB0 aGUgR2xvYmFsIGJpdCBpbgpJbmRleDogc3lzL3ZtL3ZtX3BoeXMuYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvdm0vdm1fcGh5cy5jCShyZXZpc2lvbiAyMTAxNTcpCisrKyBzeXMvdm0vdm1fcGh5cy5jCSh3 b3JraW5nIGNvcHkpCkBAIC0zMDEsNDkgKzMwMSw2NyBAQAogdm1fcGFnZV90CiB2bV9waHlzX2Fs bG9jX3BhZ2VzKGludCBwb29sLCBpbnQgb3JkZXIpCiB7CisJdm1fcGFnZV90IG07CisJaW50IGZs aW5kOworCisJZm9yIChmbGluZCA9IDA7IGZsaW5kIDwgdm1fbmZyZWVsaXN0czsgZmxpbmQrKykg eworCQltID0gdm1fcGh5c19hbGxvY19mcmVlbGlzdF9wYWdlcyhmbGluZCwgcG9vbCwgb3JkZXIp OworCQlpZiAobSAhPSBOVUxMKQorCQkJcmV0dXJuIChtKTsKKwl9CisJcmV0dXJuIChOVUxMKTsK K30KKworLyoKKyAqIEZpbmQgYW5kIGRlcXVldWUgYSBmcmVlIHBhZ2Ugb24gdGhlIGdpdmVuIGZy ZWUgbGlzdCwgd2l0aCB0aGUgCisgKiBzcGVjaWZpZWQgcG9vbCBhbmQgb3JkZXIKKyAqLwordm1f cGFnZV90Cit2bV9waHlzX2FsbG9jX2ZyZWVsaXN0X3BhZ2VzKGludCBmbGluZCwgaW50IHBvb2ws IGludCBvcmRlcikKK3sJCiAJc3RydWN0IHZtX2ZyZWVsaXN0ICpmbDsKIAlzdHJ1Y3Qgdm1fZnJl ZWxpc3QgKmFsdDsKLQlpbnQgZmxpbmQsIG9pbmQsIHBpbmQ7CisJaW50IG9pbmQsIHBpbmQ7CiAJ dm1fcGFnZV90IG07CiAKKwlLQVNTRVJUKGZsaW5kIDwgVk1fTkZSRUVMSVNULAorCSAgICAoInZt X3BoeXNfYWxsb2NfZnJlZWxpc3RfcGFnZXM6IGZyZWVsaXN0ICVkIGlzIG91dCBvZiByYW5nZSIs IGZsaW5kKSk7CiAJS0FTU0VSVChwb29sIDwgVk1fTkZSRUVQT09MLAotCSAgICAoInZtX3BoeXNf YWxsb2NfcGFnZXM6IHBvb2wgJWQgaXMgb3V0IG9mIHJhbmdlIiwgcG9vbCkpOworCSAgICAoInZt X3BoeXNfYWxsb2NfZnJlZWxpc3RfcGFnZXM6IHBvb2wgJWQgaXMgb3V0IG9mIHJhbmdlIiwgcG9v bCkpOwogCUtBU1NFUlQob3JkZXIgPCBWTV9ORlJFRU9SREVSLAotCSAgICAoInZtX3BoeXNfYWxs b2NfcGFnZXM6IG9yZGVyICVkIGlzIG91dCBvZiByYW5nZSIsIG9yZGVyKSk7CisJICAgICgidm1f cGh5c19hbGxvY19mcmVlbGlzdF9wYWdlczogb3JkZXIgJWQgaXMgb3V0IG9mIHJhbmdlIiwgb3Jk ZXIpKTsKIAltdHhfYXNzZXJ0KCZ2bV9wYWdlX3F1ZXVlX2ZyZWVfbXR4LCBNQV9PV05FRCk7Ci0J Zm9yIChmbGluZCA9IDA7IGZsaW5kIDwgdm1fbmZyZWVsaXN0czsgZmxpbmQrKykgewotCQlmbCA9 IHZtX3BoeXNfZnJlZV9xdWV1ZXNbZmxpbmRdW3Bvb2xdOwotCQlmb3IgKG9pbmQgPSBvcmRlcjsg b2luZCA8IFZNX05GUkVFT1JERVI7IG9pbmQrKykgewotCQkJbSA9IFRBSUxRX0ZJUlNUKCZmbFtv aW5kXS5wbCk7CisJZmwgPSB2bV9waHlzX2ZyZWVfcXVldWVzW2ZsaW5kXVtwb29sXTsKKwlmb3Ig KG9pbmQgPSBvcmRlcjsgb2luZCA8IFZNX05GUkVFT1JERVI7IG9pbmQrKykgeworCQltID0gVEFJ TFFfRklSU1QoJmZsW29pbmRdLnBsKTsKKwkJaWYgKG0gIT0gTlVMTCkgeworCQkJVEFJTFFfUkVN T1ZFKCZmbFtvaW5kXS5wbCwgbSwgcGFnZXEpOworCQkJZmxbb2luZF0ubGNudC0tOworCQkJbS0+ b3JkZXIgPSBWTV9ORlJFRU9SREVSOworCQkJdm1fcGh5c19zcGxpdF9wYWdlcyhtLCBvaW5kLCBm bCwgb3JkZXIpOworCQkJcmV0dXJuIChtKTsKKwkJfQorCX0KKworCS8qCisJICogVGhlIGdpdmVu IHBvb2wgd2FzIGVtcHR5LiAgRmluZCB0aGUgbGFyZ2VzdAorCSAqIGNvbnRpZ3VvdXMsIHBvd2Vy LW9mLXR3by1zaXplZCBzZXQgb2YgcGFnZXMgaW4gYW55CisJICogcG9vbC4gIFRyYW5zZmVyIHRo ZXNlIHBhZ2VzIHRvIHRoZSBnaXZlbiBwb29sLCBhbmQKKwkgKiB1c2UgdGhlbSB0byBzYXRpc2Z5 IHRoZSBhbGxvY2F0aW9uLgorCSAqLworCWZvciAob2luZCA9IFZNX05GUkVFT1JERVIgLSAxOyBv aW5kID49IG9yZGVyOyBvaW5kLS0pIHsKKwkJZm9yIChwaW5kID0gMDsgcGluZCA8IFZNX05GUkVF UE9PTDsgcGluZCsrKSB7CisJCQlhbHQgPSB2bV9waHlzX2ZyZWVfcXVldWVzW2ZsaW5kXVtwaW5k XTsKKwkJCW0gPSBUQUlMUV9GSVJTVCgmYWx0W29pbmRdLnBsKTsKIAkJCWlmIChtICE9IE5VTEwp IHsKLQkJCQlUQUlMUV9SRU1PVkUoJmZsW29pbmRdLnBsLCBtLCBwYWdlcSk7Ci0JCQkJZmxbb2lu ZF0ubGNudC0tOworCQkJCVRBSUxRX1JFTU9WRSgmYWx0W29pbmRdLnBsLCBtLCBwYWdlcSk7CisJ CQkJYWx0W29pbmRdLmxjbnQtLTsKIAkJCQltLT5vcmRlciA9IFZNX05GUkVFT1JERVI7CisJCQkJ dm1fcGh5c19zZXRfcG9vbChwb29sLCBtLCBvaW5kKTsKIAkJCQl2bV9waHlzX3NwbGl0X3BhZ2Vz KG0sIG9pbmQsIGZsLCBvcmRlcik7CiAJCQkJcmV0dXJuIChtKTsKIAkJCX0KIAkJfQotCi0JCS8q Ci0JCSAqIFRoZSBnaXZlbiBwb29sIHdhcyBlbXB0eS4gIEZpbmQgdGhlIGxhcmdlc3QKLQkJICog Y29udGlndW91cywgcG93ZXItb2YtdHdvLXNpemVkIHNldCBvZiBwYWdlcyBpbiBhbnkKLQkJICog cG9vbC4gIFRyYW5zZmVyIHRoZXNlIHBhZ2VzIHRvIHRoZSBnaXZlbiBwb29sLCBhbmQKLQkJICog dXNlIHRoZW0gdG8gc2F0aXNmeSB0aGUgYWxsb2NhdGlvbi4KLQkJICovCi0JCWZvciAob2luZCA9 IFZNX05GUkVFT1JERVIgLSAxOyBvaW5kID49IG9yZGVyOyBvaW5kLS0pIHsKLQkJCWZvciAocGlu ZCA9IDA7IHBpbmQgPCBWTV9ORlJFRVBPT0w7IHBpbmQrKykgewotCQkJCWFsdCA9IHZtX3BoeXNf ZnJlZV9xdWV1ZXNbZmxpbmRdW3BpbmRdOwotCQkJCW0gPSBUQUlMUV9GSVJTVCgmYWx0W29pbmRd LnBsKTsKLQkJCQlpZiAobSAhPSBOVUxMKSB7Ci0JCQkJCVRBSUxRX1JFTU9WRSgmYWx0W29pbmRd LnBsLCBtLCBwYWdlcSk7Ci0JCQkJCWFsdFtvaW5kXS5sY250LS07Ci0JCQkJCW0tPm9yZGVyID0g Vk1fTkZSRUVPUkRFUjsKLQkJCQkJdm1fcGh5c19zZXRfcG9vbChwb29sLCBtLCBvaW5kKTsKLQkJ CQkJdm1fcGh5c19zcGxpdF9wYWdlcyhtLCBvaW5kLCBmbCwgb3JkZXIpOwotCQkJCQlyZXR1cm4g KG0pOwotCQkJCX0KLQkJCX0KLQkJfQogCX0KIAlyZXR1cm4gKE5VTEwpOwogfQpAQCAtNTkyLDcg KzYxMCw3IEBACiB7CiAJc3RydWN0IHZtX2ZyZWVsaXN0ICpmbDsKIAlzdHJ1Y3Qgdm1fcGh5c19z ZWcgKnNlZzsKLQl2bV9vYmplY3RfdCBtX29iamVjdDsKKwlzdHJ1Y3Qgdm5vZGUgKnZwOwogCXZt X3BhZGRyX3QgcGEsIHBhX2xhc3QsIHNpemU7CiAJdm1fcGFnZV90IGRlZmVycmVkX3Zkcm9wX2xp c3QsIG0sIG1fcmV0OwogCWludCBmbGluZCwgaSwgb2luZCwgb3JkZXIsIHBpbmQ7CkBAIC02ODcs NTAgKzcwNSwxOSBAQAogCXZtX3BoeXNfc3BsaXRfcGFnZXMobV9yZXQsIG9pbmQsIGZsLCBvcmRl cik7CiAJZm9yIChpID0gMDsgaSA8IG5wYWdlczsgaSsrKSB7CiAJCW0gPSAmbV9yZXRbaV07Ci0J CUtBU1NFUlQobS0+cXVldWUgPT0gUFFfTk9ORSwKLQkJICAgICgidm1fcGh5c19hbGxvY19jb250 aWc6IHBhZ2UgJXAgaGFzIHVuZXhwZWN0ZWQgcXVldWUgJWQiLAotCQkgICAgbSwgbS0+cXVldWUp KTsKLQkJS0FTU0VSVChtLT53aXJlX2NvdW50ID09IDAsCi0JCSAgICAoInZtX3BoeXNfYWxsb2Nf Y29udGlnOiBwYWdlICVwIGlzIHdpcmVkIiwgbSkpOwotCQlLQVNTRVJUKG0tPmhvbGRfY291bnQg PT0gMCwKLQkJICAgICgidm1fcGh5c19hbGxvY19jb250aWc6IHBhZ2UgJXAgaXMgaGVsZCIsIG0p KTsKLQkJS0FTU0VSVChtLT5idXN5ID09IDAsCi0JCSAgICAoInZtX3BoeXNfYWxsb2NfY29udGln OiBwYWdlICVwIGlzIGJ1c3kiLCBtKSk7Ci0JCUtBU1NFUlQobS0+ZGlydHkgPT0gMCwKLQkJICAg ICgidm1fcGh5c19hbGxvY19jb250aWc6IHBhZ2UgJXAgaXMgZGlydHkiLCBtKSk7Ci0JCUtBU1NF UlQocG1hcF9wYWdlX2dldF9tZW1hdHRyKG0pID09IFZNX01FTUFUVFJfREVGQVVMVCwKLQkJICAg ICgidm1fcGh5c19hbGxvY19jb250aWc6IHBhZ2UgJXAgaGFzIHVuZXhwZWN0ZWQgbWVtYXR0ciAl ZCIsCi0JCSAgICBtLCBwbWFwX3BhZ2VfZ2V0X21lbWF0dHIobSkpKTsKLQkJaWYgKChtLT5mbGFn cyAmIFBHX0NBQ0hFRCkgIT0gMCkgewotCQkJbS0+dmFsaWQgPSAwOwotCQkJbV9vYmplY3QgPSBt LT5vYmplY3Q7Ci0JCQl2bV9wYWdlX2NhY2hlX3JlbW92ZShtKTsKLQkJCWlmIChtX29iamVjdC0+ dHlwZSA9PSBPQkpUX1ZOT0RFICYmCi0JCQkgICAgbV9vYmplY3QtPmNhY2hlID09IE5VTEwpIHsK LQkJCQkvKgotCQkJCSAqIEVucXVldWUgdGhlIHZub2RlIGZvciBkZWZlcnJlZCB2ZHJvcCgpLgot CQkJCSAqCi0JCQkJICogVW5tYW5hZ2VkIHBhZ2VzIGRvbid0IHVzZSAicGFnZXEiLCBzbyBpdAot CQkJCSAqIGNhbiBiZSBzYWZlbHkgYWJ1c2VkIHRvIGNvbnN0cnVjdCBhIHNob3J0LQotCQkJCSAq IGxpdmVkIHF1ZXVlIG9mIHZub2Rlcy4KLQkJCQkgKi8KLQkJCQltLT5wYWdlcS50cWVfcHJldiA9 IG1fb2JqZWN0LT5oYW5kbGU7Ci0JCQkJbS0+cGFnZXEudHFlX25leHQgPSBkZWZlcnJlZF92ZHJv cF9saXN0OwotCQkJCWRlZmVycmVkX3Zkcm9wX2xpc3QgPSBtOwotCQkJfQotCQl9IGVsc2Ugewot CQkJS0FTU0VSVChWTV9QQUdFX0lTX0ZSRUUobSksCi0JCQkgICAgKCJ2bV9waHlzX2FsbG9jX2Nv bnRpZzogcGFnZSAlcCBpcyBub3QgZnJlZSIsIG0pKTsKLQkJCUtBU1NFUlQobS0+dmFsaWQgPT0g MCwKLQkJCSAgICAoInZtX3BoeXNfYWxsb2NfY29udGlnOiBmcmVlIHBhZ2UgJXAgaXMgdmFsaWQi LCBtKSk7Ci0JCQljbnQudl9mcmVlX2NvdW50LS07CisJCXZtX3BhZ2VfYWxsb2NfaW5pdChtLCAm dnApOworCQlpZiAodnAgIT0gTlVMTCkgeworCQkJLyoKKwkJCSAqIEVucXVldWUgdGhlIHZub2Rl IGZvciBkZWZlcnJlZCB2ZHJvcCgpLgorCQkJICoKKwkJCSAqIFVubWFuYWdlZCBwYWdlcyBkb24n dCB1c2UgInBhZ2VxIiwgc28gaXQKKwkJCSAqIGNhbiBiZSBzYWZlbHkgYWJ1c2VkIHRvIGNvbnN0 cnVjdCBhIHNob3J0LQorCQkJICogbGl2ZWQgcXVldWUgb2Ygdm5vZGVzLgorCQkJICovCisJCQlt LT5wYWdlcS50cWVfcHJldiA9ICh2b2lkICopdnA7CisJCQltLT5wYWdlcS50cWVfbmV4dCA9IGRl ZmVycmVkX3Zkcm9wX2xpc3Q7CisJCQlkZWZlcnJlZF92ZHJvcF9saXN0ID0gbTsKIAkJfQotCQlp ZiAobS0+ZmxhZ3MgJiBQR19aRVJPKQotCQkJdm1fcGFnZV96ZXJvX2NvdW50LS07Ci0JCS8qIERv bid0IGNsZWFyIHRoZSBQR19aRVJPIGZsYWc7IHdlJ2xsIG5lZWQgaXQgbGF0ZXIuICovCi0JCW0t PmZsYWdzID0gUEdfVU5NQU5BR0VEIHwgKG0tPmZsYWdzICYgUEdfWkVSTyk7Ci0JCW0tPm9mbGFn cyA9IDA7Ci0JCS8qIFVubWFuYWdlZCBwYWdlcyBkb24ndCB1c2UgImFjdF9jb3VudCIuICovCiAJ fQogCWZvciAoOyBpIDwgcm91bmR1cDIobnBhZ2VzLCAxIDw8IGltaW4ob2luZCwgb3JkZXIpKTsg aSsrKSB7CiAJCW0gPSAmbV9yZXRbaV07CkluZGV4OiBzeXMvdm0vdm1fcGh5cy5oCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHN5cy92bS92bV9waHlzLmgJKHJldmlzaW9uIDIxMDE1NykKKysrIHN5cy92bS92bV9w aHlzLmgJKHdvcmtpbmcgY29weSkKQEAgLTQ1LDYgKzQ1LDcgQEAKICAgICB2bV9wYWRkcl90IGxv dywgdm1fcGFkZHJfdCBoaWdoLAogICAgIHVuc2lnbmVkIGxvbmcgYWxpZ25tZW50LCB1bnNpZ25l ZCBsb25nIGJvdW5kYXJ5KTsKIHZtX3BhZ2VfdCB2bV9waHlzX2FsbG9jX3BhZ2VzKGludCBwb29s LCBpbnQgb3JkZXIpOwordm1fcGFnZV90IHZtX3BoeXNfYWxsb2NfZnJlZWxpc3RfcGFnZXMoaW50 IGZsaW5kLCBpbnQgcG9vbCwgaW50IG9yZGVyKTsKIHZtX3BhZGRyX3Qgdm1fcGh5c19ib290c3Ry YXBfYWxsb2Modm1fc2l6ZV90IHNpemUsIHVuc2lnbmVkIGxvbmcgYWxpZ25tZW50KTsKIHZvaWQg dm1fcGh5c19mcmVlX3BhZ2VzKHZtX3BhZ2VfdCBtLCBpbnQgb3JkZXIpOwogdm9pZCB2bV9waHlz X2luaXQodm9pZCk7CkluZGV4OiBzeXMvdm0vdm1fcGFnZS5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy92 bS92bV9wYWdlLmMJKHJldmlzaW9uIDIxMDE1NykKKysrIHN5cy92bS92bV9wYWdlLmMJKHdvcmtp bmcgY29weSkKQEAgLTEzNTUsNiArMTM1NSw5MyBAQAogfQogCiAvKgorICogSW5pdGlhbGl6ZSBh IHBhZ2UgdGhhdCBoYXMgYmVlbiBmcmVzaGx5IGRlcXVldWVkIGZyb20gYSBmcmVlbGlzdC4KKyAq IFRoZSBjYWxsZXIgaGFzIHRvIGRyb3AgdGhlIHZub2RlIHJldHVuZWQgaW4gZHJvcCwgaWYgaXQg aXMgbm90IE5VTEwuCisgKgorICogVG8gYmUgY2FsbGVkIHdpdGggdm1fcGFnZV9xdWV1ZV9mcmVl X210eCBoZWxkLgorICovCit2b2lkCit2bV9wYWdlX2FsbG9jX2luaXQodm1fcGFnZV90IG0sIHN0 cnVjdCB2bm9kZSAqKmRyb3ApCit7CisJdm1fb2JqZWN0X3QgbV9vYmplY3Q7CisKKwlLQVNTRVJU KG0tPnF1ZXVlID09IFBRX05PTkUsCisJICAgICgidm1fcGFnZV9hbGxvY19pbml0OiBwYWdlICVw IGhhcyB1bmV4cGVjdGVkIHF1ZXVlICVkIiwKKwkgICAgbSwgbS0+cXVldWUpKTsKKwlLQVNTRVJU KG0tPndpcmVfY291bnQgPT0gMCwKKwkgICAgKCJ2bV9wYWdlX2FsbG9jX2luaXQ6IHBhZ2UgJXAg aXMgd2lyZWQiLCBtKSk7CisJS0FTU0VSVChtLT5ob2xkX2NvdW50ID09IDAsCisJICAgICgidm1f cGFnZV9hbGxvY19pbml0OiBwYWdlICVwIGlzIGhlbGQiLCBtKSk7CisJS0FTU0VSVChtLT5idXN5 ID09IDAsCisJICAgICgidm1fcGFnZV9hbGxvY19pbml0OiBwYWdlICVwIGlzIGJ1c3kiLCBtKSk7 CisJS0FTU0VSVChtLT5kaXJ0eSA9PSAwLAorCSAgICAoInZtX3BhZ2VfYWxsb2NfaW5pdDogcGFn ZSAlcCBpcyBkaXJ0eSIsIG0pKTsKKwlLQVNTRVJUKHBtYXBfcGFnZV9nZXRfbWVtYXR0cihtKSA9 PSBWTV9NRU1BVFRSX0RFRkFVTFQsCisJICAgICgidm1fcGFnZV9hbGxvY19pbml0OiBwYWdlICVw IGhhcyB1bmV4cGVjdGVkIG1lbWF0dHIgJWQiLAorCSAgICBtLCBwbWFwX3BhZ2VfZ2V0X21lbWF0 dHIobSkpKTsKKwltdHhfYXNzZXJ0KCZ2bV9wYWdlX3F1ZXVlX2ZyZWVfbXR4LCBNQV9PV05FRCk7 CisJKmRyb3AgPSBOVUxMOworCWlmICgobS0+ZmxhZ3MgJiBQR19DQUNIRUQpICE9IDApIHsKKwkJ bS0+dmFsaWQgPSAwOworCQltX29iamVjdCA9IG0tPm9iamVjdDsKKwkJdm1fcGFnZV9jYWNoZV9y ZW1vdmUobSk7CisJCWlmIChtX29iamVjdC0+dHlwZSA9PSBPQkpUX1ZOT0RFICYmCisJCSAgICBt X29iamVjdC0+Y2FjaGUgPT0gTlVMTCkKKwkJCSpkcm9wID0gbV9vYmplY3QtPmhhbmRsZTsKKwl9 IGVsc2UgeworCQlLQVNTRVJUKFZNX1BBR0VfSVNfRlJFRShtKSwKKwkJICAgICgidm1fcGFnZV9h bGxvY19pbml0OiBwYWdlICVwIGlzIG5vdCBmcmVlIiwgbSkpOworCQlLQVNTRVJUKG0tPnZhbGlk ID09IDAsCisJCSAgICAoInZtX3BhZ2VfYWxsb2NfaW5pdDogZnJlZSBwYWdlICVwIGlzIHZhbGlk IiwgbSkpOworCQljbnQudl9mcmVlX2NvdW50LS07CisJfQorCWlmIChtLT5mbGFncyAmIFBHX1pF Uk8pCisJCXZtX3BhZ2VfemVyb19jb3VudC0tOworCS8qIERvbid0IGNsZWFyIHRoZSBQR19aRVJP IGZsYWc7IHdlJ2xsIG5lZWQgaXQgbGF0ZXIuICovCisJbS0+ZmxhZ3MgPSBQR19VTk1BTkFHRUQg fCAobS0+ZmxhZ3MgJiBQR19aRVJPKTsKKwltLT5vZmxhZ3MgPSAwOworCS8qIFVubWFuYWdlZCBw YWdlcyBkb24ndCB1c2UgImFjdF9jb3VudCIuICovCit9CisKKy8qCisgKiAJdm1fcGFnZV9hbGxv Y19mcmVlbGlzdDoKKyAqIAorICoJQWxsb2NhdGUgYSBwYWdlIGZyb20gdGhlIHNwZWNpZmllZCBm cmVlbGlzdCB3aXRoIHNwZWNpZmllZCBvcmRlci4KKyAqCU9ubHkgdGhlIEFMTE9DX0NMQVNTIHZh bHVlcyBpbiByZXEgYXJlIGhvbm9yZWQsIG90aGVyIHJlcXVlc3QgZmxhZ3MKKyAqCWFyZSBpZ25v cmVkLgorICovCit2bV9wYWdlX3QKK3ZtX3BhZ2VfYWxsb2NfZnJlZWxpc3QoaW50IGZsaW5kLCBp bnQgb3JkZXIsIGludCByZXEpCit7CisJc3RydWN0IHZub2RlICpkcm9wOworCXZtX3BhZ2VfdCBt OworCWludCBwYWdlX3JlcTsKKworCW0gPSBOVUxMOworCXBhZ2VfcmVxID0gcmVxICYgVk1fQUxM T0NfQ0xBU1NfTUFTSzsKKwltdHhfbG9jaygmdm1fcGFnZV9xdWV1ZV9mcmVlX210eCk7CisJLyoK KwkgKiBEbyBub3QgYWxsb2NhdGUgcmVzZXJ2ZWQgcGFnZXMgdW5sZXNzIHRoZSByZXEgaGFzIGFz a2VkIGZvciBpdAorCSAqLworCWlmIChjbnQudl9mcmVlX2NvdW50ICsgY250LnZfY2FjaGVfY291 bnQgPiBjbnQudl9mcmVlX3Jlc2VydmVkIHx8CisJICAgIChwYWdlX3JlcSA9PSBWTV9BTExPQ19T WVNURU0gJiYgCisJICAgIGNudC52X2ZyZWVfY291bnQgKyBjbnQudl9jYWNoZV9jb3VudCA+IGNu dC52X2ludGVycnVwdF9mcmVlX21pbikgfHwKKwkgICAgKHBhZ2VfcmVxID09IFZNX0FMTE9DX0lO VEVSUlVQVCAmJgorCSAgICBjbnQudl9mcmVlX2NvdW50ICsgY250LnZfY2FjaGVfY291bnQgPiAw KSkgeworCQltID0gdm1fcGh5c19hbGxvY19mcmVlbGlzdF9wYWdlcyhmbGluZCwgVk1fRlJFRVBP T0xfRElSRUNULCBvcmRlcik7CisJfQorCWlmIChtID09IE5VTEwpIHsKKwkJbXR4X3VubG9jaygm dm1fcGFnZV9xdWV1ZV9mcmVlX210eCk7CisJCXJldHVybiAoTlVMTCk7CisJfQorCXZtX3BhZ2Vf YWxsb2NfaW5pdChtLCAmZHJvcCk7CisJbXR4X3VubG9jaygmdm1fcGFnZV9xdWV1ZV9mcmVlX210 eCk7CisJaWYgKGRyb3ApCisJCXZkcm9wKGRyb3ApOworCXJldHVybiAobSk7Cit9CisKKy8qCiAg Kgl2bV93YWl0OgkoYWxzbyBzZWUgVk1fV0FJVCBtYWNybykKICAqCiAgKglCbG9jayB1bnRpbCBm cmVlIHBhZ2VzIGFyZSBhdmFpbGFibGUgZm9yIGFsbG9jYXRpb24KSW5kZXg6IHN5cy92bS92bV9w YWdlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gc3lzL3ZtL3ZtX3BhZ2UuaAkocmV2aXNpb24gMjEwMTU3KQor Kysgc3lzL3ZtL3ZtX3BhZ2UuaAkod29ya2luZyBjb3B5KQpAQCAtMjYyLDYgKzI2Miw3IEBACiAg KgogICovCiAKK3N0cnVjdCB2bm9kZTsKIGV4dGVybiBpbnQgdm1fcGFnZV96ZXJvX2NvdW50Owog CiBleHRlcm4gdm1fcGFnZV90IHZtX3BhZ2VfYXJyYXk7CQkvKiBGaXJzdCByZXNpZGVudCBwYWdl IGluIHRhYmxlICovCkBAIC0zMzksNiArMzQwLDggQEAKIAogdm9pZCB2bV9wYWdlX2FjdGl2YXRl ICh2bV9wYWdlX3QpOwogdm1fcGFnZV90IHZtX3BhZ2VfYWxsb2MgKHZtX29iamVjdF90LCB2bV9w aW5kZXhfdCwgaW50KTsKK3ZtX3BhZ2VfdCB2bV9wYWdlX2FsbG9jX2ZyZWVsaXN0KGludCwgaW50 LCBpbnQpOwordm9pZCB2bV9wYWdlX2FsbG9jX2luaXQgKHZtX3BhZ2VfdCwgc3RydWN0IHZub2Rl ICoqKTsKIHZtX3BhZ2VfdCB2bV9wYWdlX2dyYWIgKHZtX29iamVjdF90LCB2bV9waW5kZXhfdCwg aW50KTsKIHZvaWQgdm1fcGFnZV9jYWNoZSh2bV9wYWdlX3QpOwogdm9pZCB2bV9wYWdlX2NhY2hl X2ZyZWUodm1fb2JqZWN0X3QsIHZtX3BpbmRleF90LCB2bV9waW5kZXhfdCk7Cg== --0014853d013085a1e1048bb84c56-- From owner-freebsd-mips@FreeBSD.ORG Mon Jul 19 11:07:01 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28F93106566B for ; Mon, 19 Jul 2010 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F20CB8FC1B for ; Mon, 19 Jul 2010 11:07:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6JB70CD065764 for ; Mon, 19 Jul 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6JB70gr065762 for freebsd-mips@FreeBSD.org; Mon, 19 Jul 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Jul 2010 11:07:00 GMT Message-Id: <201007191107.o6JB70gr065762@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-mips@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-mips@FreeBSD.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 11:07:01 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/147471 mips [headers] [patch] whitespace discrepancy in sys/mips/i 1 problem total. From owner-freebsd-mips@FreeBSD.ORG Mon Jul 19 15:18:53 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08E51065673 for ; Mon, 19 Jul 2010 15:18:53 +0000 (UTC) (envelope-from waynegong83@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A51F88FC2A for ; Mon, 19 Jul 2010 15:18:53 +0000 (UTC) Received: by vws19 with SMTP id 19so5920423vws.13 for ; Mon, 19 Jul 2010 08:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=nR+TN+7lJm++IZeshl3ZvIcSrEVYdvTfl3GGTFJqv3U=; b=gyblP3cdnvj6oCKbazl12L64zUZdpGg8MzQ6SbFN5wjMxmbZ2GPkREglLz3dO+au1D Tc7BnnpsfdAhL2VVgoEJHrxF0hIXVByd6R62UJMTRgGUVzl7dKYm/jOS6Sam6JTOxTiC LrQrlK5Je6L5DWMqK+5XvoUzU9D26YZYHnWOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Oc0SPqrmCj1QysIQB496OKs0RQIv+U1ZF0c0fg7z4GjTImCP+rquRWaaOQVCPSbJrD gkFbNFXcA3I+G9Pcrolg6YMOXVIWveLcv+J8SR+YQneBtxKrjekmjegyeIr+y0tjXA0F FtRzp3QaffrDQDQxLuynvo2gqCrEihmJlVsoo= MIME-Version: 1.0 Received: by 10.220.99.21 with SMTP id s21mr3288851vcn.82.1279552732728; Mon, 19 Jul 2010 08:18:52 -0700 (PDT) Received: by 10.220.203.1 with HTTP; Mon, 19 Jul 2010 08:18:52 -0700 (PDT) Date: Mon, 19 Jul 2010 20:48:52 +0530 Message-ID: From: waynegong L To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Image activator for N64 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 15:18:54 -0000 Hi Julie, Is image activator created for N64? In your last mail you mentioned that N64 worlds are not supported currently with N64 kernels. Can you please let me the know what state it is in right now? Thanks, Wayne. From owner-freebsd-mips@FreeBSD.ORG Mon Jul 19 16:45:47 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2AF81065676 for ; Mon, 19 Jul 2010 16:45:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5C98FC18 for ; Mon, 19 Jul 2010 16:45:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o6JGdOmT038958; Mon, 19 Jul 2010 10:39:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 19 Jul 2010 10:39:51 -0600 (MDT) Message-Id: <20100719.103951.1033552815255184453.imp@bsdimp.com> To: waynegong83@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@FreeBSD.org Subject: Re: Image activator for N64 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 16:45:48 -0000 In message: waynegong L writes: : Hi Julie, : : Is image activator created for N64? No. : In your last mail you mentioned that N64 worlds are not supported currently : with N64 kernels. Can you please let : me the know what state it is in right now? pmap work is necessary to support 64-bit mappings and page tables. Right now, there's only enough 64-bit support in the pmap to handle the kernel. Warner From owner-freebsd-mips@FreeBSD.ORG Mon Jul 19 17:01:52 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80D191065678 for ; Mon, 19 Jul 2010 17:01:52 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 33B2B8FC1A for ; Mon, 19 Jul 2010 17:01:51 +0000 (UTC) Received: by vws19 with SMTP id 19so6053532vws.13 for ; Mon, 19 Jul 2010 10:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cPmPj3iufSxnha4d2qjK5Xa6MLxI3h+rJEmAkYk2Oxc=; b=XN1av9Jc+JaM3tagxohrHDVBvktCcFx4xGiuA4udr98T+V0woFmgMe11S4HtMD6Kb2 MSF/JoQvkmLhj9gWyJMUNa1BL1ySsO6r82s4NNHxtX1FO6rWP+4CfnCEDT05oeIpnxqc WvS6UoR1giISjBSxzEHDGv6J6fRyg1kR3OtZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=U5ft6j7n/8crp4yITbkJpfd8Rlce3TMRTKG6QjkBEW5XiBoOs/Tehm0F+L70JcCJ7f Lw8IXM4fpy3WckLyAQdFh6f6T1fw0GT+PO6XkZTybaHQ7o3SWT8q4rVLUlJjoP9abdgb CqfOAqrl3QK5LQ0LCM8YTO7kvs95aqrPMHcTs= MIME-Version: 1.0 Received: by 10.220.62.201 with SMTP id y9mr2637979vch.220.1279558911339; Mon, 19 Jul 2010 10:01:51 -0700 (PDT) Received: by 10.220.188.138 with HTTP; Mon, 19 Jul 2010 10:01:51 -0700 (PDT) In-Reply-To: <20100719.103951.1033552815255184453.imp@bsdimp.com> References: <20100719.103951.1033552815255184453.imp@bsdimp.com> Date: Mon, 19 Jul 2010 22:31:51 +0530 Message-ID: From: "Jayachandran C." To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: Image activator for N64 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:01:52 -0000 On Mon, Jul 19, 2010 at 10:09 PM, M. Warner Losh wrote: > In message: > =A0 =A0 =A0 =A0 =A0 =A0waynegong L writes: > : Hi Julie, > : > : Is image activator created for N64? > > No. > > : In your last mail you mentioned that N64 worlds are not supported curre= ntly > : with N64 kernels. Can you please let > : me the know what state it is in right now? > > pmap work is necessary to support 64-bit mappings and page tables. > Right now, there's only enough 64-bit support in the pmap to handle > the kernel. I'm working on adding 3 level page table support into the kernel, and also supporting 64 bit user-space. pmap.c work is mostly done, but still more work is needed before I can get a 64-bit init to run. Hope to post something useful in a week or two. JC. From owner-freebsd-mips@FreeBSD.ORG Tue Jul 20 06:56:03 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55E081065673 for ; Tue, 20 Jul 2010 06:56:03 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 143FE8FC16 for ; Tue, 20 Jul 2010 06:56:02 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 85E342C2ACE; Tue, 20 Jul 2010 01:56:02 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BPTfpZ4DahVo; Tue, 20 Jul 2010 01:55:54 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 6664D2C2A91; Tue, 20 Jul 2010 01:55:53 -0500 (CDT) Message-ID: <4C454878.4070001@cs.rice.edu> Date: Tue, 20 Jul 2010 01:55:52 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: "Jayachandran C." References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <4C0DE424.9080601@cs.rice.edu> <4C3E0144.50402@cs.rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 06:56:03 -0000 Jayachandran C. wrote: > On Wed, Jul 14, 2010 at 11:56 PM, Alan Cox wrote: > [....] > >> This makes sense. I have the following requests. All but 1.a. are simple, >> mechanical changes. >> >> 1. Move vm_phys_page_alloc() to vm_page.c and rename it to >> vm_page_alloc_freelist(). >> >> 1.a. The new vm_page_alloc_freelist() should really have a "req" parameter >> like vm_page_alloc() and duplicate the following from vm_page_alloc(): >> >> mtx_lock(&vm_page_queue_free_mtx); >> if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || >> (page_req == VM_ALLOC_SYSTEM && >> cnt.v_free_count + cnt.v_cache_count > cnt.v_interrupt_free_min) || >> (page_req == VM_ALLOC_INTERRUPT && >> cnt.v_free_count + cnt.v_cache_count > 0)) { >> >> In essence, user page table page allocation shouldn't be allowed to allocate >> the last available page. Only pmap_growkernel() should use >> VM_ALLOC_INTERRUPT. (See either the amd64 or i386 pmap.) >> >> You could also drop the "pool" parameter and pass VM_FREEPOOL_DIRECT to >> vm_phys_alloc_freelist_pages() from vm_page_alloc_freelist(). (This is >> consistent with what vm_page_alloc() does for VM_ALLOC_NOOBJ.) >> >> 2. Move vm_page_alloc_init() to vm_page.c as well. (And add it to >> vm_page.h.) >> >> 3. Make vm_phys_alloc_freelist_pages() extern. >> >> >> >>> Since I had originally added the UMA zone for page table >>> pages for MIPS, which has the issues you had noted, I would like to >>> fix this... >>> >> The patch introduces a few unnecessary blank lines. Can you please remove >> these: >> > [...] > >> FreeBSD style(9) requires parentheses around the "m": >> > [...] > >> + return m; >> > > [freebsd-mips cc-ed, for comments on MIPS side] > > Here's is the updated patch with the review comments taken care of. I > have been testing this on MIPS, could not see any regression so far. > > -- > Redo the page table page allocation on MIPS, based on suggestion from > alc@. The current UMA zone based allocation can be replaced by a > scheme that creates a new free list for the KSEG0 region, and a new > function in sys/vm to allocate pages from a specific free page list. > > The changes are : > - Revert the earlier changes in MIPS pmap.c that added UMA zone for > page table pages. > - Add a new freelist VM_FREELIST_HIGHMEM to vmparam.h for memory that > is not directly mapped (in 32bit compilation). Normal page allocations > will first try the HIGHMEM freelist and then the default freelist > (which is for the KSEG0 direct mapped memory). > - Add a new function 'vm_page_t vm_page_alloc_freelist(int flind, int > order, int req)' to vm/vm_page.c to allocate a page from a specified > freelist. The MIPS page table pages will be allocated using this > function from the KSEG0 freelist. > - Move the page initialization code from vm_phys_alloc_contig() to a > new function vm_page_alloc_init(), and use this function to initialize > pages in vm_page_alloc_freelist() too. > - Split the vm_phys_alloc_pages(pool, order) to create > vm_phys_alloc_freelist_pages(int flind, int pool, int order), and use > this function from both vm_page_alloc_freelist() and > vm_phys_alloc_pages(). > -- > The patch looks good. After the following stylistic changes are made, please go ahead and commit the patch. @@ -110,6 +110,7 @@ #define VM_MAXUSER_ADDRESS ((vm_offset_t)0x80000000) #define VM_MIN_KERNEL_ADDRESS ((vm_offset_t)0xC0000000) #define VM_MAX_KERNEL_ADDRESS ((vm_offset_t)0xFFFFC000) +#define VM_HIGHMEM_ADDRESS ((vm_paddr_t)0x20000000) #endif #if 0 #define KERNBASE (VM_MIN_KERNEL_ADDRESS) VM_HIGHMEM_ADDRESS is a physical address whereas the other constants defined here are virtual addresses. I would move VM_HIGHMEM_ADDRESS to the same block of definitions where VM_FREELIST_HIGHMEM is defined. static void -pmap_ptpgzone_dtor(void *mem, int size, void *arg) +pmap_grow_pte_page_cache() { -#ifdef INVARIANTS - static char zeropage[PAGE_SIZE]; - - KASSERT(size == PAGE_SIZE, - ("pmap_ptpgzone_dtor: invalid size %d", size)); - KASSERT(bcmp(mem, zeropage, PAGE_SIZE) == 0, - ("pmap_ptpgzone_dtor: freeing a non-zeroed page")); -#endif + vm_contig_grow_cache(3, 0, MIPS_KSEG0_LARGEST_PHYS); } Style(9) calls for a blank line between the opening "{" and the "vm_contig_grow_cache()" call. static vm_page_t -pmap_alloc_pte_page(pmap_t pmap, unsigned int index, int wait, vm_offset_t *vap) +pmap_alloc_pte_page(unsigned int index, int req) { ... - if (va == NULL) + m = vm_page_alloc_freelist(VM_FREELIST_DEFAULT, 0, req); + if (m == NULL) return (NULL); For clarity of intent here, I would suggest #define'ing an alias for VM_FREELIST_DEFAULT called VM_FREELIST_DIRECT in vmparam.h and use that alias here. While having VM_FREELIST_DEFAULT defined as a non-zero value works, it still makes me a little queasy. That queasiness would be lessened by using VM_FREELIST_DIRECT here instead of VM_FREELIST_DEFAULT. Moreover, the notion of VM_FREELIST_DEFAULT may have to change with the addition of NUMA support, having and using VM_FREELIST_DIRECT may shield MIPS from those changes. m->pindex = index; m->valid = VM_PAGE_BITS_ALL; - m->wire_count = 1; - if (!locked) - vm_page_unlock_queues(); - You can eliminate the assignment to "->valid". This field is not meaningful for VM_ALLOC_NOOBJ pages, like page table pages. vm_page_t vm_phys_alloc_pages(int pool, int order); +vm_page_t vm_phys_alloc_freelist_pages(int flind, int pool, int order); Please swap the above two declarations so that alphabetical ordering is preserved. + * The caller has to drop the vnode retuned in drop, if it is not NULL. "retuned" should be "returned" +void +vm_page_alloc_init(vm_page_t m, struct vnode **drop) I think that the patch would be simpler if vm_page_alloc_init() returned a "struct vnode *" + * Do not allocate reserved pages unless the req has asked for it Please add a period to the end of the sentence. +void vm_page_alloc_init (vm_page_t, struct vnode **); Please remove the space between "init" and "(". (The similar spaces in some of nearby declarations are historical artifacts that new code needn't duplicate.) From owner-freebsd-mips@FreeBSD.ORG Tue Jul 20 08:49:07 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C4A81065673 for ; Tue, 20 Jul 2010 08:49:07 +0000 (UTC) (envelope-from waynegong83@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3FA028FC1C for ; Tue, 20 Jul 2010 08:49:06 +0000 (UTC) Received: by vws19 with SMTP id 19so7159641vws.13 for ; Tue, 20 Jul 2010 01:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1NBdVBTRE0qztZfnuQrRexl8RheVwFiQtLRlUIqXIH4=; b=RIaUnAAVTJSRY5XKLOsGlNaAW97KMEQVgTkt/I6t78gfzjimMTgm/QptZhwklo06X8 4SJvOCwSrRkqz8sCESo9xVgP69Sxi5bbK3ohLuJ5/6fFnSgzHQg3w/4W87dj8WwWbVsd rxj6KA79dkrzvCMAwGaJg6YA/sQb2l6dZHJJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LraZ/sxKpPB8eAyt5FQzptyk6Tpshi0LmWHorhUkbbhzfCRMkQktYLTHin0qzkLMrF ABBFk6i1hHzbuqVO+EzoYgYpEt1GXVxiwe/gi7f1g9PEs3tWhe+iJNKzgz2VgRrj7uMT Z6uqamadxeOX+ohzGdKAC16ba2gKJg+A321mM= MIME-Version: 1.0 Received: by 10.220.123.198 with SMTP id q6mr3225780vcr.99.1279615746279; Tue, 20 Jul 2010 01:49:06 -0700 (PDT) Received: by 10.220.203.1 with HTTP; Tue, 20 Jul 2010 01:49:06 -0700 (PDT) In-Reply-To: References: <20100719.103951.1033552815255184453.imp@bsdimp.com> Date: Tue, 20 Jul 2010 14:19:06 +0530 Message-ID: From: waynegong L To: "Jayachandran C." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-mips@freebsd.org Subject: Re: Image activator for N64 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 08:49:07 -0000 Thanks warner and Jayachandran for the info. Regards, Wayne. On Mon, Jul 19, 2010 at 10:31 PM, Jayachandran C. wrote: > On Mon, Jul 19, 2010 at 10:09 PM, M. Warner Losh wrote: > > In message: < > AANLkTilJT4QlOkFfbKKs9W77-H77NsJ_WW7mcQ56beyl@mail.gmail.com> > > waynegong L writes: > > : Hi Julie, > > : > > : Is image activator created for N64? > > > > No. > > > > : In your last mail you mentioned that N64 worlds are not supported > currently > > : with N64 kernels. Can you please let > > : me the know what state it is in right now? > > > > pmap work is necessary to support 64-bit mappings and page tables. > > Right now, there's only enough 64-bit support in the pmap to handle > > the kernel. > > I'm working on adding 3 level page table support into the kernel, and > also supporting 64 bit user-space. pmap.c work is mostly done, but > still more work is needed before I can get a 64-bit init to run. Hope > to post something useful in a week or two. > > JC. > From owner-freebsd-mips@FreeBSD.ORG Tue Jul 20 19:13:45 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F9AE10657C5; Tue, 20 Jul 2010 19:13:45 +0000 (UTC) (envelope-from phcoder@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D27B08FC1E; Tue, 20 Jul 2010 19:13:44 +0000 (UTC) Received: by fxm13 with SMTP id 13so3431499fxm.13 for ; Tue, 20 Jul 2010 12:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type; bh=yTQR4vbnreK4AF3BLGrinvgPtWmJB/6cw2RQxa4GFHI=; b=DFFwDaXbHI6BrLJv57JwVukNf9JdWw84qIBwwWEMY1D5zwTiOhhpB8SQlLsjNiGWnZ h/PWbi+GX266koLnUCRhv4EB0U7GCBxo9el/2f7hUaDwn4/vvcluWgMEHbidP4tnwsZQ duYuN2zGCBKu+dKgKFvtsUlHNm4fH6Vzm5jxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; b=FKfjKvVk4ZkIDET4vnWmpTO90BB2qMJXinm2dsugz5gbz6aIjFn9dxqXcYU2LxRJGN MnEvdXZpqoYm6DBPbIQ3wPRyTukMYBR0aSRZDKsNvL+apdg9DIptpUrwTCctFLyaXi7l UZZ6A7ZUjjhuZQBPEiRzdjVw+nBNIhdgHQnpc= Received: by 10.223.111.200 with SMTP id t8mr5845074fap.31.1279653222796; Tue, 20 Jul 2010 12:13:42 -0700 (PDT) Received: from debian.bg45.phnet (vpn-global-dhcp3-221.ethz.ch [129.132.210.221]) by mx.google.com with ESMTPS id c5sm1012908fac.19.2010.07.20.12.13.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 12:13:42 -0700 (PDT) Message-ID: <4C45F55F.5000507@gmail.com> Date: Tue, 20 Jul 2010 21:13:35 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5 MIME-Version: 1.0 To: soc-status@freebsd.org, freebsd-mips@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0329B59BEF07CBAD1372ADA3" Cc: Subject: Yeeloong status report X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:13:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0329B59BEF07CBAD1372ADA3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. Thanks to help from my mentor I was able to buildworld for yeeloong. The current problem is that for some obscure reason I'm figuring out no 32-bit imgact was compiled. So no it fails with error 8 on launching init. On bright side now it communicates with bootloader and so detects 256 Mib of memory (using whole 1GiB is another problem due to architecture). AT keyboard attaches but has problems due to interrupt routing. I'm currently trying to figure out imgact and how to use genfb with my sm712 driver. Next steps will be figuring out the cache problems and writing more device drivers --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig0329B59BEF07CBAD1372ADA3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkxF9V8ACgkQNak7dOguQglfcgEAro8ONSXkk3uv9stGYyR0nuoW dlQDqvdPsaq4ssP3hXEBAJ6rRTVKCDHdGDHy9gnhU+b9Fp128RGJURKbRO9msdQ0 =gWhS -----END PGP SIGNATURE----- --------------enig0329B59BEF07CBAD1372ADA3-- From owner-freebsd-mips@FreeBSD.ORG Tue Jul 20 19:50:20 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D46B5106566C; Tue, 20 Jul 2010 19:50:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 970648FC14; Tue, 20 Jul 2010 19:50:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o6KJjOjj062045; Tue, 20 Jul 2010 13:45:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jul 2010 13:45:53 -0600 (MDT) Message-Id: <20100720.134553.522292379390520228.imp@bsdimp.com> To: phcoder@gmail.com From: "M. Warner Losh" In-Reply-To: <4C45F55F.5000507@gmail.com> References: <4C45F55F.5000507@gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: soc-status@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: Yeeloong status report X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:50:20 -0000 SW4gbWVzc2FnZTogPDRDNDVGNTVGLjUwMDA1MDdAZ21haWwuY29tPg0KICAgICAgICAgICAgVmxh ZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28gPHBoY29kZXJAZ21haWwuY29tPiB3 cml0ZXM6DQo6IEhlbGxvLiBUaGFua3MgdG8gaGVscCBmcm9tIG15IG1lbnRvciBJIHdhcyBhYmxl IHRvIGJ1aWxkd29ybGQgZm9yDQo6IHllZWxvb25nLg0KDQpDb29sIQ0KDQo6IFRoZSBjdXJyZW50 IHByb2JsZW0gaXMgdGhhdCBmb3Igc29tZSBvYnNjdXJlIHJlYXNvbiBJJ20NCjogZmlndXJpbmcg b3V0IG5vIDMyLWJpdCBpbWdhY3Qgd2FzIGNvbXBpbGVkLiBTbyBubyBpdCBmYWlscyB3aXRoIGVy cm9yIDgNCjogb24gbGF1bmNoaW5nIGluaXQuDQoNCjggaXMgRU5PRVhFQyBvciBleGVjIGZvcm1h dCBlcnJvci4uLg0KDQo6IE9uIGJyaWdodCBzaWRlIG5vdyBpdCBjb21tdW5pY2F0ZXMgd2l0aCBi b290bG9hZGVyDQo6IGFuZCBzbyBkZXRlY3RzIDI1NiBNaWIgb2YgbWVtb3J5ICh1c2luZyB3aG9s ZSAxR2lCIGlzIGFub3RoZXIgcHJvYmxlbQ0KOiBkdWUgdG8gYXJjaGl0ZWN0dXJlKS4NCg0KQ29v bCEgIFRoZXJlJ3MgY29kZSBpbiB0aGUgb2N0ZW9uIHBvcnQgdG8gZGVhbCB3aXRoIG1lbW9yeSBh Ym92ZQ0KNTEyTUIuICBJcyB0aGlzIG1lbW9yeSBqdXN0IG1hcHBlZCBpbiBhbiBvZGQgbG9jYXRp b24sIG9yIGlzIHRoZXJlDQpzb21lIG90aGVyIHJlYXNvbi4uLg0KDQo6IEFUIGtleWJvYXJkIGF0 dGFjaGVzIGJ1dCBoYXMgcHJvYmxlbXMgZHVlIHRvDQo6IGludGVycnVwdCByb3V0aW5nLg0KDQpU aG9zZSBhcmUgYWx3YXlzIGZ1biA6KQ0KDQo6IEknbSBjdXJyZW50bHkgdHJ5aW5nIHRvIGZpZ3Vy ZSBvdXQgaW1nYWN0IGFuZCBob3cgdG8NCjogdXNlIGdlbmZiIHdpdGggbXkgc203MTIgZHJpdmVy LiBOZXh0IHN0ZXBzIHdpbGwgYmUgZmlndXJpbmcgb3V0IHRoZQ0KOiBjYWNoZSBwcm9ibGVtcyBh bmQgd3JpdGluZyBtb3JlIGRldmljZSBkcml2ZXJzDQoNCkknbGwgYmUgYXJvdW5kIG9uIElSQyBp ZiB5b3UgbmVlIG1lIDopDQoNCldhcm5lcg0K From owner-freebsd-mips@FreeBSD.ORG Tue Jul 20 20:05:26 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50E7D1065674; Tue, 20 Jul 2010 20:05:26 +0000 (UTC) (envelope-from phcoder@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9573A8FC13; Tue, 20 Jul 2010 20:05:25 +0000 (UTC) Received: by fxm13 with SMTP id 13so3463264fxm.13 for ; Tue, 20 Jul 2010 13:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=dibF/Hfbc65owrIskPb2j2HTw1fVlJrymxfwhfOwBbU=; b=vLkPzk/KQcI1rKUqRZYskZSvc3F2wG18tGgFGwxmr7celm8tP9T37OfBa4QKr1PkKc n7gK+zPa2s3st8QiOSARGpYaDzgHjuTgLPGBaBliWYExEDdAXWwA65qhPqj9Zspyw6YK AYTqk3+BwB+3c1nZ6UnkfAmCWjH0f3UTdTuxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=sNIW9vsBo+9rQLwWglqDkqIaAZfPoOTRRT9dcE3LwKpC7FxxdUqQYYORgZ055JL5oS mWLPXuBXnFbdll9BjN5n8rTLPtmbJJIvFWxqkt61IFJG5+I17Cu4NBvBTjcuBIgIgt5Z 5+JpJu94TnBd9xfA6G+yDbAfbn/o8vG7TWndA= Received: by 10.103.160.10 with SMTP id m10mr675729muo.109.1279656324372; Tue, 20 Jul 2010 13:05:24 -0700 (PDT) Received: from debian.bg45.phnet (vpn-global-dhcp3-221.ethz.ch [129.132.210.221]) by mx.google.com with ESMTPS id l19sm2579813fap.9.2010.07.20.13.05.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 13:05:23 -0700 (PDT) Message-ID: <4C460180.4020903@gmail.com> Date: Tue, 20 Jul 2010 22:05:20 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5 MIME-Version: 1.0 To: "M. Warner Losh" References: <4C45F55F.5000507@gmail.com> <20100720.134553.522292379390520228.imp@bsdimp.com> In-Reply-To: <20100720.134553.522292379390520228.imp@bsdimp.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig68610F2BD37F6C670F724577" Cc: soc-status@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: Yeeloong status report X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:05:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68610F2BD37F6C670F724577 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/20/2010 09:45 PM, M. Warner Losh wrote: > In message: <4C45F55F.5000507@gmail.com> > Vladimir '=CF=86-coder/phcoder' Serbinenko writes: > : Hello. Thanks to help from my mentor I was able to buildworld for > : yeeloong. > > Cool! > > =20 Thanks > : The current problem is that for some obscure reason I'm > : figuring out no 32-bit imgact was compiled. So no it fails with error= 8 > : on launching init. > > 8 is ENOEXEC or exec format error... > =20 Yes, I know :( > : On bright side now it communicates with bootloader > : and so detects 256 Mib of memory (using whole 1GiB is another problem= > : due to architecture). > > Cool! There's code in the octeon port to deal with memory above > 512MB. Is this memory just mapped in an odd location, or is there > some other reason... > > =20 Just not got around to look into it. Spec mentions the need to configure special windows for it. > : AT keyboard attaches but has problems due to > : interrupt routing. > > Those are always fun :) > > =20 Yes, I'm trying to get to Lemote guys for that info. > : I'm currently trying to figure out imgact and how to > : use genfb with my sm712 driver. Next steps will be figuring out the > : cache problems and writing more device drivers > > I'll be around on IRC if you nee me :) > > =20 A thing I don't understand is that it seems that driver uses genfb. That seems weird. Why not genfb would automatically attach to any gfx driver available? Would save sizeable amount of code in long run. > Warner > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig68610F2BD37F6C670F724577 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkxGAYAACgkQNak7dOguQglUmgEArIfGtncA2L4ztMZ3eP88Ad2D xQX9fjZO9ZUQ+eDYkboA/2o99T82gerX0sjE/svtgIfeiwM1usF5ycoDl+WRLfwO =9/uT -----END PGP SIGNATURE----- --------------enig68610F2BD37F6C670F724577-- From owner-freebsd-mips@FreeBSD.ORG Wed Jul 21 06:52:15 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAC12106566B for ; Wed, 21 Jul 2010 06:52:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 789D68FC17 for ; Wed, 21 Jul 2010 06:52:15 +0000 (UTC) Received: by fxm13 with SMTP id 13so3633776fxm.13 for ; Tue, 20 Jul 2010 23:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=BWRaT7hOZn+otR5lutmXItHI65WKLApGC3NEHPtpPXk=; b=SJpDDbC5SkAQdBAJswgIvDiQGHdl41cxBt+lBs12xKXhK+gsCs16QS+vpTqTdcWm1w up8op/VL/pyHRaLXgMts9y4soIYU/rCL2VRnGiZgY2A6//B4ABPyYIHTq+XSjp34K552 7QDu2KRRHDF5UFDVoSz1TsPXZlwlwabWqfPWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Ql9tQbQ+8T70dLD35lV/xiKq43SPKJUvh9QH9wXr55GT32+wvTxfEWTXl0KjT0Y75e sVgJidsILx6z+Ivmbt8n7eLpnGK/N1XICIpTtptWdoOAdJ/TUX96A6PgWzbbDFip2esz yWeiEThAfDSehmH6tcGEKXaFSpdI7A7SQk6G0= Received: by 10.223.109.140 with SMTP id j12mr6356065fap.22.1279695134238; Tue, 20 Jul 2010 23:52:14 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y2sm2766369fau.12.2010.07.20.23.52.11 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 23:52:12 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C4698D6.2090104@FreeBSD.org> Date: Wed, 21 Jul 2010 09:51:02 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: freebsd-mips@freebsd.org References: <4C41A248.8090605@FreeBSD.org> In-Reply-To: <4C41A248.8090605@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 06:52:16 -0000 Alexander Motin wrote: > I've made a patch, updating MIPS timer code (except RMI) to utilize new > MI event timer infrastructure. I've successfully built QEMU and XLR > kernels with the patch. Unluckily I can't test how it works, unless > somebody teach me how to cook QEMU to run it. I also haven't ported RMI > timers drivers, as I am not sure how that hardware is intended to work. > > Patch for HEAD can be found here: > http://people.freebsd.org/~mav/timers_mips.patch Slightly updated version for fresh HEAD: http://people.freebsd.org/~mav/timers_mips2.patch -- Alexander Motin From owner-freebsd-mips@FreeBSD.ORG Wed Jul 21 18:19:41 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA6741065670 for ; Wed, 21 Jul 2010 18:19:41 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7BF8FC08 for ; Wed, 21 Jul 2010 18:19:40 +0000 (UTC) Received: by vws19 with SMTP id 19so9444578vws.13 for ; Wed, 21 Jul 2010 11:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NQ4MtUB9IlJfDzx5Q68I4jMlAlUqQEKTgDVssUapS2U=; b=Efn+hsFbGT0B5W0l/zkcbOJpc/NMUOA8pA6xUGZ3kCUKDYyOW0BYirZMBo+Ze1aDZA EKME8AVIlBxektP4XPbnkslyNdbReAQymIfsoM/Bf/F1G/8OXN4zgm+ITcBd7J6AYMMq Iqnl+AC0ZUd9YCCxdP7Nmo1YRcnHRtr48VDNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cRGA2+NxQL/p7pLkKbjePYDblyGJi7RjrijOZ2fsxmr3pC0Srq9IC2pQQksTSjy2BM QQCfx2SI1CFHEMqA7iFECI+w5mFDLGrUlst0PYq1Jti5ZLjQwKT6I59Md8ithQIrEdSS WI4w+OI++SYimHQeS9t1TTQk/FzflD1XdwmSY= MIME-Version: 1.0 Received: by 10.220.125.22 with SMTP id w22mr306465vcr.18.1279736379886; Wed, 21 Jul 2010 11:19:39 -0700 (PDT) Received: by 10.220.188.138 with HTTP; Wed, 21 Jul 2010 11:19:39 -0700 (PDT) In-Reply-To: <4C454878.4070001@cs.rice.edu> References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <4C0DE424.9080601@cs.rice.edu> <4C3E0144.50402@cs.rice.edu> <4C454878.4070001@cs.rice.edu> Date: Wed, 21 Jul 2010 23:49:39 +0530 Message-ID: From: "Jayachandran C." To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:19:41 -0000 On Tue, Jul 20, 2010 at 12:25 PM, Alan Cox wrote: > Jayachandran C. wrote: >> >> On Wed, Jul 14, 2010 at 11:56 PM, Alan Cox wrote: >> [....] >> >>> >>> This makes sense. =A0I have the following requests. =A0All but 1.a. are >>> simple, >>> mechanical changes. I have made the changes below, and the code is checked in with revision r210327. I have tested this on XLR, but let me know if this causes any regression on other platform. Also, many thanks to alc for patiently reviewing the changes. JC. >>> >>> 1. Move vm_phys_page_alloc() to vm_page.c and rename it to >>> vm_page_alloc_freelist(). >>> >>> 1.a. The new vm_page_alloc_freelist() should really have a "req" >>> parameter >>> like vm_page_alloc() and duplicate the following from vm_page_alloc(): >>> >>> =A0mtx_lock(&vm_page_queue_free_mtx); >>> =A0if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || >>> =A0 =A0 =A0(page_req =3D=3D VM_ALLOC_SYSTEM && >>> =A0 =A0 =A0cnt.v_free_count + cnt.v_cache_count > cnt.v_interrupt_free_= min) || >>> =A0 =A0 =A0(page_req =3D=3D VM_ALLOC_INTERRUPT && >>> =A0 =A0 =A0cnt.v_free_count + cnt.v_cache_count > 0)) { >>> >>> In essence, user page table page allocation shouldn't be allowed to >>> allocate >>> the last available page. =A0Only pmap_growkernel() should use >>> VM_ALLOC_INTERRUPT. =A0(See either the amd64 or i386 pmap.) >>> >>> You could also drop the "pool" parameter and pass VM_FREEPOOL_DIRECT to >>> vm_phys_alloc_freelist_pages() from vm_page_alloc_freelist(). =A0(This = is >>> consistent with what vm_page_alloc() does for VM_ALLOC_NOOBJ.) >>> >>> 2. Move vm_page_alloc_init() to vm_page.c as well. =A0(And add it to >>> vm_page.h.) >>> >>> 3. Make vm_phys_alloc_freelist_pages() extern. >>> >>> >>> >>>> >>>> Since I had originally added the UMA zone for =A0page table >>>> pages for MIPS, which has the issues you had noted, I would like to >>>> fix this... >>>> >>> >>> The patch introduces a few unnecessary blank lines. =A0Can you please >>> remove >>> these: >>> >> >> [...] >> >>> >>> FreeBSD style(9) requires parentheses around the "m": >>> >> >> [...] >> >>> >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return m; >>> >> >> [freebsd-mips cc-ed, for comments on MIPS side] >> >> Here's is the updated patch with the review comments taken care of. I >> have been testing this on MIPS, could not see any regression so far. >> >> -- >> Redo the page table page allocation on MIPS, based on suggestion from >> alc@. The current UMA zone based allocation can be replaced by a >> scheme that creates a new free list for the KSEG0 region, and a new >> function in sys/vm to allocate pages from a specific free page list. >> >> The changes are : >> - Revert the earlier changes in MIPS pmap.c that added UMA zone for >> page table pages. >> - Add a new freelist VM_FREELIST_HIGHMEM to vmparam.h for memory that >> is not directly mapped (in 32bit compilation). Normal page allocations >> will first try the HIGHMEM freelist and then the default freelist >> (which is for the KSEG0 direct mapped memory). >> - Add a new function 'vm_page_t vm_page_alloc_freelist(int flind, int >> order, int req)' to vm/vm_page.c to allocate a page from a specified >> freelist. =A0The MIPS page table pages will be allocated using this >> function from the KSEG0 freelist. >> - Move the page initialization code from =A0vm_phys_alloc_contig() to a >> new function vm_page_alloc_init(), and use this function to initialize >> pages in vm_page_alloc_freelist() too. >> - =A0Split the =A0vm_phys_alloc_pages(pool, order) to create >> vm_phys_alloc_freelist_pages(int flind, int pool, int order), and use >> this function from both vm_page_alloc_freelist() and >> vm_phys_alloc_pages(). >> -- >> > > The patch looks good. =A0After the following stylistic changes are made, > please go ahead and commit the patch. > > @@ -110,6 +110,7 @@ > #define =A0 =A0 =A0 =A0VM_MAXUSER_ADDRESS =A0 =A0 =A0((vm_offset_t)0x8000= 0000) > #define =A0 =A0 =A0 =A0VM_MIN_KERNEL_ADDRESS =A0 ((vm_offset_t)0xC0000000= ) > #define =A0 =A0 =A0 =A0VM_MAX_KERNEL_ADDRESS =A0 ((vm_offset_t)0xFFFFC000= ) > +#define =A0 =A0 =A0 =A0VM_HIGHMEM_ADDRESS =A0 =A0 =A0((vm_paddr_t)0x2000= 0000) > #endif > #if 0 > #define =A0 =A0 =A0 =A0KERNBASE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(VM_MIN_KE= RNEL_ADDRESS) > > VM_HIGHMEM_ADDRESS is a physical address whereas the other constants defi= ned > here are virtual addresses. =A0I would move VM_HIGHMEM_ADDRESS to the sam= e > block of definitions where VM_FREELIST_HIGHMEM is defined. > > static void > -pmap_ptpgzone_dtor(void *mem, int size, void *arg) > +pmap_grow_pte_page_cache() > { > -#ifdef INVARIANTS > - =A0 =A0 =A0 static char zeropage[PAGE_SIZE]; > - > - =A0 =A0 =A0 KASSERT(size =3D=3D PAGE_SIZE, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ("pmap_ptpgzone_dtor: invalid size %d", siz= e)); > - =A0 =A0 =A0 KASSERT(bcmp(mem, zeropage, PAGE_SIZE) =3D=3D 0, > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ("pmap_ptpgzone_dtor: freeing a non-zeroed = page")); > -#endif > + =A0 =A0 =A0 vm_contig_grow_cache(3, 0, MIPS_KSEG0_LARGEST_PHYS); > } > > Style(9) calls for a blank line between the opening "{" and the > "vm_contig_grow_cache()" call. > > > static vm_page_t > -pmap_alloc_pte_page(pmap_t pmap, unsigned int index, int wait, vm_offset= _t > *vap) > +pmap_alloc_pte_page(unsigned int index, int req) > { > ... > - =A0 =A0 =A0 if (va =3D=3D NULL) > + =A0 =A0 =A0 m =3D vm_page_alloc_freelist(VM_FREELIST_DEFAULT, 0, req); > + =A0 =A0 =A0 if (m =3D=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (NULL); > > For clarity of intent here, I would suggest #define'ing an alias for > VM_FREELIST_DEFAULT called VM_FREELIST_DIRECT in vmparam.h and use that > alias here. > > While having VM_FREELIST_DEFAULT defined as a non-zero value works, it st= ill > makes me a little queasy. =A0That queasiness would be lessened by using > VM_FREELIST_DIRECT here instead of VM_FREELIST_DEFAULT. =A0Moreover, the > notion of VM_FREELIST_DEFAULT may have to change with the addition of NUM= A > support, having and using VM_FREELIST_DIRECT may shield MIPS from those > changes. > > > =A0 =A0 =A0 m->pindex =3D index; > =A0 =A0 =A0 m->valid =3D VM_PAGE_BITS_ALL; > - =A0 =A0 =A0 m->wire_count =3D 1; > - =A0 =A0 =A0 if (!locked) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 vm_page_unlock_queues(); > - > > You can eliminate the assignment to "->valid". =A0This field is not meani= ngful > for VM_ALLOC_NOOBJ pages, like page table pages. > > > vm_page_t vm_phys_alloc_pages(int pool, int order); > +vm_page_t vm_phys_alloc_freelist_pages(int flind, int pool, int order); > > Please swap the above two declarations so that alphabetical ordering is > preserved. > > > + * The caller has to drop the vnode retuned in drop, if it is not NULL. > > "retuned" should be "returned" > > > +void > +vm_page_alloc_init(vm_page_t m, struct vnode **drop) > > I think that the patch would be simpler if vm_page_alloc_init() returned = a > "struct vnode *" > > > + =A0 =A0 =A0 =A0* Do not allocate reserved pages unless the req has aske= d for it > > Please add a period to the end of the sentence. > > > +void vm_page_alloc_init (vm_page_t, struct vnode **); > > Please remove the space between "init" and "(". =A0(The similar spaces in= some > of nearby declarations are historical artifacts that new code needn't > duplicate.) > > From owner-freebsd-mips@FreeBSD.ORG Thu Jul 22 03:22:37 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10C4C106564A; Thu, 22 Jul 2010 03:22:37 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D74EB8FC12; Thu, 22 Jul 2010 03:22:36 +0000 (UTC) Received: by pwj9 with SMTP id 9so3352313pwj.13 for ; Wed, 21 Jul 2010 20:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=W4qmqXYqlv1lVkxqzzw9pCMchgQbZjlpjHtzR6EhDnY=; b=JWNvaSwLCVoWaGvXTbVRCQbsrGXYxexWdW5TTa2ebPpT8caNJQ9ScIwJxCh2NbZJOg p5sR6/QG0GSxJe0S364TYL+2Wj1sZ8H743y4PAMT+fbc0hxY7pPSx38n59lwn+mP5i3b XPIm/90auT3pDa16dLxRkELUMZ8+Fq7uTW448= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EJqcepKNLHZYXrdgm7FJW3P6zZ86RzC/QJ7SqbkfAU6zQnc5Bq/GDqdw7GU6txSRu/ y9AmTVqzsXUZGYnftSxlZ4UdPEK+/D77JAV/Wk4Enlm4suWISpRY2sGOE7jraSE+1x6E T0oOQp1bsXjShvKiqN6DeYrlt5uAF3fsurLlI= MIME-Version: 1.0 Received: by 10.142.231.14 with SMTP id d14mr1426265wfh.308.1279768956158; Wed, 21 Jul 2010 20:22:36 -0700 (PDT) Received: by 10.142.139.19 with HTTP; Wed, 21 Jul 2010 20:22:36 -0700 (PDT) In-Reply-To: <4C4698D6.2090104@FreeBSD.org> References: <4C41A248.8090605@FreeBSD.org> <4C4698D6.2090104@FreeBSD.org> Date: Wed, 21 Jul 2010 20:22:36 -0700 Message-ID: From: Neel Natu To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 03:22:37 -0000 Hi Alexander, Your patch works fine on a Sibyte. I verified that wall clock time is progressing as expected. Is there any other test that you recommend? I have a few comments about the patch: 1. set_cputicker() in clock_attach() should be moved back up to mips_timer_init_params(). Otherwise the platform-specific CPU tickers used by Sibyte, Octeon and RMI will be overwritten by the mips32 ticker. 2. The local variable 'cycles_per_tick' in clock_intr() can now be a uint32_t. 3. Is there a race between setting 'cycles_per_tick' in clock_start() and clock_intr()? Would it be better to write the compare register first and then set 'cycles_per_tick' to a non-zero value? If I understand the code correctly we are liable to get clock interrupts even afer the clock is stopped when the CP0 COUNT register matches 0xffffffff. 4. We need to update the DPCPU(compare_ticks) value when we start the timer in clock_start(). 5. I think the entire 'lost_ticks' processing in clock_intr() should be conditional on (cycles_per_tick > 0). Without this we may incorrectly update the value of DPCPU(lost_ticks). 6. Can you a couple of lines of explaining the computatation of 'et_min_period' and 'et_max_period'? It is not completely obvious to me. best Neel 2010/7/20 Alexander Motin : > Alexander Motin wrote: >> I've made a patch, updating MIPS timer code (except RMI) to utilize new >> MI event timer infrastructure. I've successfully built QEMU and XLR >> kernels with the patch. Unluckily I can't test how it works, unless >> somebody teach me how to cook QEMU to run it. I also haven't ported RMI >> timers drivers, as I am not sure how that hardware is intended to work. >> >> Patch for HEAD can be found here: >> http://people.freebsd.org/~mav/timers_mips.patch > > Slightly updated version for fresh HEAD: > http://people.freebsd.org/~mav/timers_mips2.patch > > -- > Alexander Motin > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-mips@FreeBSD.ORG Thu Jul 22 05:36:19 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04511106566C for ; Thu, 22 Jul 2010 05:36:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 818398FC19 for ; Thu, 22 Jul 2010 05:36:17 +0000 (UTC) Received: by fxm13 with SMTP id 13so4454215fxm.13 for ; Wed, 21 Jul 2010 22:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=xu1Zb24p7qw0t7NnHwnLJEYjiCmOorXNmornBqJ7ElE=; b=QLo934TSJbXS+3lITq6BImOtpq6rrY2oUCPQLxSQTpWGU292l04x5GRrdrZJWjNOcf 4DXpaVBna+k/LEAEwzMQy/DZdHPiXViaNHIRPjQXD7etUaMSA8ia8TcvojxeYmBLahyf KNzOMy+PvcyL3Mj1PNE+Qzk9DKzmgOBb7peOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=QwPs5SPCnzx+gASvqa0RmU2Zx7+odsKSj6BuFPYarqZPhnZIoHwY0RSy7yOcaSJPFv lJ39zipEulP9HRXFSEf0DifP9952RZ1GTAe2i6ia5e36ZI+qHzxeIOdwPngMpQy7/a/b eSM1b+eIfciwENIlfFto8pHoiq76fRTgCDTrM= Received: by 10.223.126.84 with SMTP id b20mr1226850fas.98.1279776976580; Wed, 21 Jul 2010 22:36:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r2sm3177313faq.4.2010.07.21.22.36.15 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 22:36:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C47D8CD.7020209@FreeBSD.org> Date: Thu, 22 Jul 2010 08:36:13 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Neel Natu References: <4C41A248.8090605@FreeBSD.org> <4C4698D6.2090104@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 05:36:19 -0000 Hi. Neel Natu wrote: > Your patch works fine on a Sibyte. I verified that wall clock time is > progressing as expected. Is there any other test that you recommend? > > I have a few comments about the patch: > > 1. set_cputicker() in clock_attach() should be moved back up to > mips_timer_init_params(). Otherwise the platform-specific CPU tickers > used by Sibyte, Octeon and RMI will be overwritten by the mips32 ticker. Fixed. > 2. The local variable 'cycles_per_tick' in clock_intr() can now be a uint32_t. Fixed. > 3. Is there a race between setting 'cycles_per_tick' in clock_start() and > clock_intr()? Would it be better to write the compare register first > and then set 'cycles_per_tick' to a non-zero value? And how does it help? > If I understand the code correctly we are liable to get clock interrupts > even afer the clock is stopped when the CP0 COUNT register matches > 0xffffffff. You mean we can receive interrupt from previous clock_start() after new one? Theoretically I think it is possible, but what can we do about it? > 4. We need to update the DPCPU(compare_ticks) value when we start the timer > in clock_start(). Fixed. > 5. I think the entire 'lost_ticks' processing in clock_intr() should be > conditional on (cycles_per_tick > 0). Without this we may incorrectly > update the value of DPCPU(lost_ticks). Fixed. Indeed, in one-shot mode extra callback can be confusing. > 6. Can you a couple of lines of explaining the computatation of > 'et_min_period' and 'et_max_period'? It is not completely obvious to me. Minimal period is set artificialy to reduce possibility to lost very short time interval during comparator programming. I've done it after marius@ asked to do the same for sparc64. If this comparator is more clever to handle missed time, it may not be needed. Maximal period is calculated from maximal counter value, minus one to possibly avoid some rounding overflows. Again, if this comparator is "clever" may be it need to be reduced. I don't have documentation for this hardware, so fix me if I am wrong. New patch: http://people.freebsd.org/~mav/timers_mips3.patch Thank you! -- Alexander Motin From owner-freebsd-mips@FreeBSD.ORG Thu Jul 22 06:33:13 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 994681065676; Thu, 22 Jul 2010 06:33:13 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 680B08FC24; Thu, 22 Jul 2010 06:33:13 +0000 (UTC) Received: by pxi8 with SMTP id 8so3554475pxi.13 for ; Wed, 21 Jul 2010 23:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FL4L/Ll2QM+zxg8vobWxYDNyYPDJxxTOLCi4fbrLAps=; b=eNtKP1l9Bnx5F4Jy3pgZKEVd/zj7BHsI6J8Ra3WznDv4+QfXN7EQYCMPyLDOHKWWch Bn+O9zuH2fHB2bDwEeur8ef9pdGzGgQvDd4kQYSFKf2c7e2RJrFMduWAqU5/qyMzmq+Y S66Aq5gXu8xIhxbg4nULY4lp6IM+xI+FbwuBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EFH7TeWHk3aan9SMvRmY7Ip4Jwo45zjU1mDhcJ+vh9877VRRw2cRVmn2mXF0loyiF7 2NlP9cwwV6wJIkxP0zxwutNqxb3HGKJsrX8M4sQR+rHVlHk9UAj6lRTz3n76vnOTLhik 3Damw/Zprt4gjhkMI5o8YG8s3+DZbPV3qrwk8= MIME-Version: 1.0 Received: by 10.142.199.21 with SMTP id w21mr1749937wff.140.1279780391179; Wed, 21 Jul 2010 23:33:11 -0700 (PDT) Received: by 10.142.139.19 with HTTP; Wed, 21 Jul 2010 23:33:10 -0700 (PDT) In-Reply-To: <4C47D8CD.7020209@FreeBSD.org> References: <4C41A248.8090605@FreeBSD.org> <4C4698D6.2090104@FreeBSD.org> <4C47D8CD.7020209@FreeBSD.org> Date: Wed, 21 Jul 2010 23:33:10 -0700 Message-ID: From: Neel Natu To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:33:13 -0000 Hi Alexander, On Wed, Jul 21, 2010 at 10:36 PM, Alexander Motin wrote: > Hi. > > Neel Natu wrote: >> Your patch works fine on a Sibyte. I verified that wall clock time is >> progressing as expected. Is there any other test that you recommend? >> >> I have a few comments about the patch: >> >> 1. set_cputicker() in clock_attach() should be moved back up to >> =A0 =A0 mips_timer_init_params(). Otherwise the platform-specific CPU ti= ckers >> =A0 =A0used by Sibyte, Octeon and RMI will be overwritten by the mips32 = ticker. > > Fixed. > >> 2. The local variable 'cycles_per_tick' in clock_intr() can now be a uin= t32_t. > > Fixed. > >> 3. Is there a race between setting 'cycles_per_tick' in clock_start() an= d >> =A0 =A0 clock_intr()? Would it be better to write the compare register f= irst >> =A0 =A0 and then set 'cycles_per_tick' to a non-zero value? > > And how does it help? > So, the timeline I have in mind is this: A: clock_stop() sets compare register to 0xffffffff and cycles_per_tick to = 0 B: clock_start() is called and we update cycles_per_tick to a non-zero value but we have not updated the compare register yet C: the COUNT register is a free running counter and it happens to reach 0xffffffff exactly at this time D: the clock_intr() handler sees a non-zero cycles_per_tick value and proceeds as if this was a legitimate interrupt (when in reality it is not) If we update the cycles_per_tick at the very end then it is guaranteed that any interrupt that happens while it is zero is essentially ignored. And any interrupt that happens after it has been updated to a non-zero value is legitimate. >> =A0 =A0 If I understand the code correctly we are liable to get clock in= terrupts >> =A0 =A0 even afer the clock is stopped when the CP0 COUNT register match= es >> =A0 =A0 0xffffffff. > > You mean we can receive interrupt from previous clock_start() after new > one? Theoretically I think it is possible, but what can we do about it? > I don't think we can do anything about it. I was referring to the race when the clock was stopped and we are in the process of restarting it. See above. >> 4. We need to update the DPCPU(compare_ticks) value when we start the ti= mer >> =A0 =A0 in clock_start(). > > Fixed. > >> 5. I think the entire 'lost_ticks' processing in clock_intr() should be >> =A0 =A0 conditional on (cycles_per_tick > 0). Without this we may incorr= ectly >> =A0 =A0 update the value of DPCPU(lost_ticks). > > Fixed. Indeed, in one-shot mode extra callback can be confusing. > >> 6. Can you a couple of lines of explaining the computatation of >> =A0 =A0 'et_min_period' and 'et_max_period'? It is not completely obviou= s to me. > > Minimal period is set artificialy to reduce possibility to lost very > short time interval during comparator programming. I've done it after > marius@ asked to do the same for sparc64. If this comparator is more > clever to handle missed time, it may not be needed. > Maximal period is calculated from maximal counter value, minus one to > possibly avoid some rounding overflows. Again, if this comparator is > "clever" may be it need to be reduced. > I don't have documentation for this hardware, so fix me if I am wrong. > I see. Thanks for the explanation. > New patch: http://people.freebsd.org/~mav/timers_mips3.patch > In clock_intr() it would seem that the last 'et_event_cb()' should be called conditionally only if (cycles_per_tick > 0). Of course, this is necessary only if my explanation about spurious clock_intr() invocations is correct. I have tested the latest patch on the Sibyte as well and it works correctly= . best Neel > Thank you! > > -- > Alexander Motin > From owner-freebsd-mips@FreeBSD.ORG Thu Jul 22 09:01:26 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 363621065676 for ; Thu, 22 Jul 2010 09:01:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AF9378FC12 for ; Thu, 22 Jul 2010 09:01:25 +0000 (UTC) Received: by fxm13 with SMTP id 13so4541228fxm.13 for ; Thu, 22 Jul 2010 02:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=ANoQFH2x1Qq4OCWXnotW+O8Zb/xGra7WQWNWt/h/VGE=; b=iKHmIFwIo5PBre4jhb+8xteZuTeP8ryUYzfmuqTPTMaH9R5r+2COk/TgX+tJ9V/QJ1 u33vYFhkPlVidFuQnim5pkhraeKx63SpY15ZNS7PTyMithp0iMKJ+uznsPD3Wirwl8R5 D5BAGqWnVys8bSjOGoa1LM67lAicjmx3nWteA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UXDBSRspNma+RE3foGN2jT56wa30K4GKDbaodY/nSTKnyjmQkjqbb8sMm2eWmJMaWa Yen4OJxhkwqLXMvPlm7l12FOSghyoE/zT3bIzklFiGYpmUXOsJuMhe6tik1PanDJxIqo UZVIQJVKGhUti40IlrGrqGF3QJunV7x6HsWac= Received: by 10.223.108.204 with SMTP id g12mr1543131fap.21.1279789284153; Thu, 22 Jul 2010 02:01:24 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r27sm3238326faa.24.2010.07.22.02.01.22 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 02:01:23 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C48089C.1010503@FreeBSD.org> Date: Thu, 22 Jul 2010 12:00:12 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Neel Natu References: <4C41A248.8090605@FreeBSD.org> <4C4698D6.2090104@FreeBSD.org> <4C47D8CD.7020209@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 09:01:26 -0000 Neel Natu wrote: > On Wed, Jul 21, 2010 at 10:36 PM, Alexander Motin wrote: >> New patch: http://people.freebsd.org/~mav/timers_mips3.patch > > In clock_intr() it would seem that the last 'et_event_cb()' should be > called conditionally only if (cycles_per_tick > 0). Of course, this is > necessary only if my explanation about spurious clock_intr() > invocations is correct. cycles_per_tick == 0 except spurious interrupt may also mean one-shot timer operation mode. In such case callback should be called on interrupt, but timer should be stopped after that. To protect from counter still running after stop (if needed) - probably we need one more variable, or define some specific cycles_per_tick value. I am not actually sure if writing 0xffffffff stops timer. I've just seen it somewhere else. What is the proper way there to really stop the timer to avoid spurious interrupt? > I have tested the latest patch on the Sibyte as well and it works correctly. Thanks. -- Alexander Motin From owner-freebsd-mips@FreeBSD.ORG Thu Jul 22 16:01:39 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0263106566B; Thu, 22 Jul 2010 16:01:39 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0F28FC12; Thu, 22 Jul 2010 16:01:39 +0000 (UTC) Received: by pxi8 with SMTP id 8so3753940pxi.13 for ; Thu, 22 Jul 2010 09:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=n/8G0oW2i3E27Noy1GSorE5UyRaOHrzAEcsWai/odQc=; b=ow30u+sWiiKre1ZeDqH0Ytf2cu7BLomPFkEzXRdikWw/DEdD6b1vaE7eMSH14/7VhA pPFFjfDZ4vsyff7k5znbHltMUk5XGKU2YNU3L/JcOupmVZ4ZZyB879qCOkaiVp+UnzWr 4Nvqz9Awk7cYfA0C1xGk3ki+erH4khsgoec7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f0EJY6Dt13vH1mWjYDu7a6nP5oSnHCZYO1oMqKmWXR6O2H6fNV7wL1MyBWrXL8Xilz RgZ0U9FzKA1TXvZKZu2kan8V5Pwx2HqydOx13OBaGoJxUSbmGPrpyzJn7B4WYsYQcwfZ Qi3AFXicZm96vlL9XszTJKi6QBA6u6HH7nIE0= MIME-Version: 1.0 Received: by 10.142.204.17 with SMTP id b17mr2545794wfg.109.1279814498925; Thu, 22 Jul 2010 09:01:38 -0700 (PDT) Received: by 10.142.139.19 with HTTP; Thu, 22 Jul 2010 09:01:38 -0700 (PDT) In-Reply-To: <4C48089C.1010503@FreeBSD.org> References: <4C41A248.8090605@FreeBSD.org> <4C4698D6.2090104@FreeBSD.org> <4C47D8CD.7020209@FreeBSD.org> <4C48089C.1010503@FreeBSD.org> Date: Thu, 22 Jul 2010 09:01:38 -0700 Message-ID: From: Neel Natu To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 16:01:39 -0000 Hi Alexander, On Thu, Jul 22, 2010 at 2:00 AM, Alexander Motin wrote: > Neel Natu wrote: >> On Wed, Jul 21, 2010 at 10:36 PM, Alexander Motin wrote: >>> New patch: http://people.freebsd.org/~mav/timers_mips3.patch >> >> In clock_intr() it would seem that the last 'et_event_cb()' should be >> called conditionally only if (cycles_per_tick > 0). Of course, this is >> necessary only if my explanation about spurious clock_intr() >> invocations is correct. > > cycles_per_tick == 0 except spurious interrupt may also mean one-shot > timer operation mode. In such case callback should be called on > interrupt, but timer should be stopped after that. To protect from > counter still running after stop (if needed) - probably we need one more > variable, or define some specific cycles_per_tick value. > > I am not actually sure if writing 0xffffffff stops timer. I've just seen > it somewhere else. What is the proper way there to really stop the timer > to avoid spurious interrupt? > Writing 0xffffffff to compare register does not stop the timer nor the timer compare interrupt.The only way to stop the timer interrupt is to mask it in the status register. Having said that I cannot see why we would ever call clock_stop() for the mips timer. I think you should commit the code you have right now and then we can work offline to see if the spurious clock interrupt is really a problem in practice or just a theoretical possibility. best Neel >> I have tested the latest patch on the Sibyte as well and it works correctly. > > Thanks. > > -- > Alexander Motin >