From tom at tomjudge.com Fri Oct 2 06:13:57 2009 From: tom at tomjudge.com (Tom Judge) Date: Fri Oct 2 06:14:03 2009 Subject: [patch] Compilation problems in sys/arm/arm/pmap.c when PMAP_DEBUG is defined. Message-ID: <4AC599FC.1070304@tomjudge.com> Hi, I ran into some issues this evening while I was building some kernels with PMAP_DEBUG defined. I have attached a patch that addresses the problems with the DPRINTF sections. (The first 2 hunks should probably be ignored). However there are 2 warnings about unused functions when PMAP_INLINE is defined as "". I did not know what the correct fix for this was so I defined PMAP_INLINE to __inline even when PMAP_DEBUG was set, which seemed to hide the problem again. Tom -------------- next part -------------- Index: sys/arm/arm/pmap.c =================================================================== --- sys/arm/arm/pmap.c (revision 197472) +++ sys/arm/arm/pmap.c (working copy) @@ -142,6 +142,7 @@ * Special compilation symbols * PMAP_DEBUG - Build in pmap_debug_level code */ +#define PMAP_DEBUG /* Include header files */ #include "opt_vm.h" @@ -183,8 +184,9 @@ ((_stat_)) #define dprintf printf -int pmap_debug_level = 0; -#define PMAP_INLINE +int pmap_debug_level = 1; +#define PMAP_INLINE __inline +//#define PMAP_INLINE #else /* PMAP_DEBUG */ #define PDEBUG(_lev_,_stat_) /* Nothing */ #define dprintf(x, arg...) @@ -1914,7 +1916,7 @@ { int shpgperproc = PMAP_SHPGPERPROC; - PDEBUG(1, printf("pmap_init: phys_start = %08x\n")); + PDEBUG(1, printf("pmap_init: phys_start = %08x\n",PHYSADDR )); /* * init the pv free list @@ -2373,8 +2375,8 @@ vm_size_t size; int l1idx, l2idx, l2next = 0; - PDEBUG(1, printf("firstaddr = %08x, loadaddr = %08x\n", - firstaddr, loadaddr)); + PDEBUG(1, printf("firstaddr = %08x, lastaddr = %08x\n", + firstaddr, lastaddr)); virtual_avail = firstaddr; kernel_pmap->pm_l1 = l1; From yohanes at gmail.com Fri Oct 2 06:28:27 2009 From: yohanes at gmail.com (Yohanes Nugroho) Date: Fri Oct 2 06:28:39 2009 Subject: FreeBSD ARM network speed Message-ID: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Hi All, I am continuing my work on CNX11XX/STR91XX (more info about the work: http://tinyhack.com/2009/09/28/cnx11xxstr91xx-freebsd-progress/), two important things left are the Flash/CFI driver, and network problem. The Flash/CFI in theory should be easy, but I will read more about it to make sure that I will not mess the boot loader part. And now about the network. The network speed is now around half of Linux on the same hardware. FTP-ing from the device to my computer (uploading 30 mb file), the speed is about 1.6-2 megabyte/second (the high speed is on the second time when the data is already cached). On Linux, I can upload the same file with the speed of about 3-4 megabyte/second. Some info about the device: RAM: 64 Mb, CPU FA526 (ARM4, no thumb instruction), Speed 200Mhz. MAC is part of SoC, PHY is ICPLUS IP101A I have two question: 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? If it is slower, then how much slower is it? I can not find a comparison of network speed on Freebsd arm and Linux ARM. I am interested if anyone can provide me the comparison between Linux and Freebsd on NSLU2 or some other device. Just for information, changing some kernel options in the Linux version (such as the scheduler used) makes the network speed varies greatly (i think the variation is more than 30%, so in certain configuration it can be a slow as the current FreeBSD version). The network in Linux 2.4 kernel is faster than Linux 2.6. 2. What should I do to make the network faster (especially the sending from device part, to make it usable as a media server)? Here are the things that I have done: - using the scatter/gather feature of the hardware (this improves the speed a little bit) - using checksum offloading feature of the hardware (this improves the speed a little bit) - using task_queue for sending (this improves the speed a lot) - I have disabled spinlock debugging, and other debugging except for the DDB - I have used the -O2 optimization flag - I have checked that there is no error/retransmission (using wireshark), so all the packets are sent and received correctly - I have disabled IPV6 (here is my current configuration: http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/conf/CNS11XXNAS&REV=3) The specification for the STR9104 SoC is available on Cavium website for those who are interested, but it is not very clear, so in developing the network driver, I followed the logic used by the Linux driver (the initialization sequence, etc). The current code is at http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/econa/if_ece.c&REV=4 Here is how the sending part works on STR9104: - In the initialization part, I allocate a ring, the size of the ring is 256 entries (same as Linux version). - When being asked to send a packet, I will do the following thing: - stop the network TX DMA - put the address of each segment of the packet to the ring, and set a flag so that the entry in the ring will be sent by hardware - start the network TX DMA obviously there is a cleaning up part (freeing mbuf) that should be done. The network driver can generate interrupt when a packet has been sent (but can't tell which entry was sent). In the Linux version, this interrupt is not used, the clean up is done just after starting the TX DMA, at the send of the sending function, and I do the same in the FreeBSD driver . Usually only one entry that needs to be removed, so it is quite fast. Is there something obvious (or not so obvius) that I've missed? -- Regards Yohanes http://yohan.es/ From rpaulo at freebsd.org Fri Oct 2 08:38:15 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Fri Oct 2 08:38:21 2009 Subject: FreeBSD ARM network speed In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Message-ID: On 2 Oct 2009, at 06:58, Yohanes Nugroho wrote: > Hi All, > > I am continuing my work on CNX11XX/STR91XX (more info about the work: > http://tinyhack.com/2009/09/28/cnx11xxstr91xx-freebsd-progress/), two > important things left are the Flash/CFI driver, and network problem. > The Flash/CFI in theory should be easy, but I will read more about it > to make sure that I will not mess the boot loader part. And now about > the network. > > The network speed is now around half of Linux on the same hardware. > FTP-ing from the device to my computer (uploading 30 mb file), the > speed is about 1.6-2 megabyte/second (the high speed is on the second > time when the data is already cached). On Linux, I can upload the same > file with the speed of about 3-4 megabyte/second. > > Some info about the device: RAM: 64 Mb, CPU FA526 (ARM4, no thumb > instruction), Speed 200Mhz. MAC is part of SoC, PHY is ICPLUS IP101A > > I have two question: > 1. Is the network speed in Freebsd ARM currently slower than Linux > ARM? I see no problems on my ARM boards running FreeBSD. -- Rui Paulo From stas at FreeBSD.org Fri Oct 2 09:35:47 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Oct 2 09:35:53 2009 Subject: FreeBSD ARM network speed In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Message-ID: <20091002133559.283d377f.stas@FreeBSD.org> On Fri, 2 Oct 2009 12:58:38 +0700 Yohanes Nugroho mentioned: > I have two question: > 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? > I don't think so. Our network stack is arch-independent and should perform equally well on all platforms. I've been able to acchieve speeds up to 70 Mbps on my 180Mhz AT91 based board which uses very plain and dumb ethernet controller (although, DMA is supported). > Here is how the sending part works on STR9104: > > - In the initialization part, I allocate a ring, the size of the ring > is 256 entries (same as Linux version). > - When being asked to send a packet, I will do the following thing: > - stop the network TX DMA > - put the address of each segment of the packet to the ring, and set > a flag so that the entry in the ring will be sent by hardware > - start the network TX DMA > This looks weird. Why do you stop the TX engine to add more packets in the ring? This thing definitely can kill the network performace as the controller unable to transmit anything during the time you're filling the ring. You should not also generally transmit only one packet a time as in this case your driver will do a lot of extra work and, considering that you're stopping the TX engine when filling the ring, will prevent the adapter doing any useful work. The main strategy of the driver should be to keep the ring filled, waking up when some reasonable amount of space in the ring become available, and sleeping all other time when the adapter is working. I'm not sure why Linux doesn't use interrupt, but this looks really wrong. I'd suggest you to ananlyze the performance of network driver either by using the profiling tools available (kgmon, hardware counters (if any)) or/and via system monitoring tools (top, etc). Top, in particular, will allow you to see where all the CPU time went. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20091002/e028db3a/attachment.pgp From stas at FreeBSD.org Fri Oct 2 11:56:08 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Oct 2 11:56:14 2009 Subject: [patch] Compilation problems in sys/arm/arm/pmap.c when PMAP_DEBUG is defined. In-Reply-To: <4AC599FC.1070304@tomjudge.com> References: <4AC599FC.1070304@tomjudge.com> Message-ID: <20091002155600.2c2f615d.stas@FreeBSD.org> On Fri, 02 Oct 2009 06:13:16 +0000 Tom Judge mentioned: > Hi, > > I ran into some issues this evening while I was building some kernels > with PMAP_DEBUG defined. > > I have attached a patch that addresses the problems with the DPRINTF > sections. (The first 2 hunks should probably be ignored). > > However there are 2 warnings about unused functions when PMAP_INLINE is > defined as "". I did not know what the correct fix for this was so I > defined PMAP_INLINE to __inline even when PMAP_DEBUG was set, which > seemed to hide the problem again. > Actually, these two functions with PMAP_INLINE prefixes are unused. I believe we can drop them. Olivier, what do you think about the following patch? Index: sys/arm/arm/pmap.c =================================================================== --- sys/arm/arm/pmap.c (revision 197707) +++ sys/arm/arm/pmap.c (working copy) @@ -203,7 +203,6 @@ static void pmap_fix_cache(struct vm_page *, pmap_t, vm_offset_t); static void pmap_alloc_l1(pmap_t); static void pmap_free_l1(pmap_t); -static void pmap_use_l1(pmap_t); static int pmap_clearbit(struct vm_page *, u_int); @@ -829,47 +828,6 @@ mtx_unlock(&l1_lru_lock); } -static PMAP_INLINE void -pmap_use_l1(pmap_t pm) -{ - struct l1_ttable *l1; - - /* - * Do nothing if we're in interrupt context. - * Access to an L1 by the kernel pmap must not affect - * the LRU list. - */ - if (pm == pmap_kernel()) - return; - - l1 = pm->pm_l1; - - /* - * If the L1 is not currently on the LRU list, just return - */ - if (l1->l1_domain_use_count == PMAP_DOMAINS) - return; - - mtx_lock(&l1_lru_lock); - - /* - * Check the use count again, now that we've acquired the lock - */ - if (l1->l1_domain_use_count == PMAP_DOMAINS) { - mtx_unlock(&l1_lru_lock); - return; - } - - /* - * Move the L1 to the back of the LRU list - */ - TAILQ_REMOVE(&l1_lru_list, l1, l1_lru); - TAILQ_INSERT_TAIL(&l1_lru_list, l1, l1_lru); - - mtx_unlock(&l1_lru_lock); -} - - /* * Returns a pointer to the L2 bucket associated with the specified pmap * and VA, or NULL if no L2 bucket exists for the address. @@ -1311,16 +1269,6 @@ } } -static PMAP_INLINE void -pmap_dcache_wbinv_all(pmap_t pm) -{ - - if (pmap_is_current(pm)) { - cpu_dcache_wbinv_all(); - cpu_l2cache_wbinv_all(); - } -} - /* * PTE_SYNC_CURRENT: * @@ -1914,7 +1862,7 @@ { int shpgperproc = PMAP_SHPGPERPROC; - PDEBUG(1, printf("pmap_init: phys_start = %08x\n")); + PDEBUG(1, printf("pmap_init: phys_start = %08x\n", PHYSADDR)); /* * init the pv free list @@ -2373,8 +2321,8 @@ vm_size_t size; int l1idx, l2idx, l2next = 0; - PDEBUG(1, printf("firstaddr = %08x, loadaddr = %08x\n", - firstaddr, loadaddr)); + PDEBUG(1, printf("firstaddr = %08x, lastaddr = %08x\n", + firstaddr, lastaddr)); virtual_avail = firstaddr; kernel_pmap->pm_l1 = l1; @@ -4246,96 +4194,7 @@ pmap_zero_page(m); } -#if 0 /* - * pmap_clean_page() - * - * This is a local function used to work out the best strategy to clean - * a single page referenced by its entry in the PV table. It's used by - * pmap_copy_page, pmap_zero page and maybe some others later on. - * - * Its policy is effectively: - * o If there are no mappings, we don't bother doing anything with the cache. - * o If there is one mapping, we clean just that page. - * o If there are multiple mappings, we clean the entire cache. - * - * So that some functions can be further optimised, it returns 0 if it didn't - * clean the entire cache, or 1 if it did. - * - * XXX One bug in this routine is that if the pv_entry has a single page - * mapped at 0x00000000 a whole cache clean will be performed rather than - * just the 1 page. Since this should not occur in everyday use and if it does - * it will just result in not the most efficient clean for the page. - */ -static int -pmap_clean_page(struct pv_entry *pv, boolean_t is_src) -{ - pmap_t pm, pm_to_clean = NULL; - struct pv_entry *npv; - u_int cache_needs_cleaning = 0; - u_int flags = 0; - vm_offset_t page_to_clean = 0; - - if (pv == NULL) { - /* nothing mapped in so nothing to flush */ - return (0); - } - - /* - * Since we flush the cache each time we change to a different - * user vmspace, we only need to flush the page if it is in the - * current pmap. - */ - if (curthread) - pm = vmspace_pmap(curproc->p_vmspace); - else - pm = pmap_kernel(); - - for (npv = pv; npv; npv = TAILQ_NEXT(npv, pv_list)) { - if (npv->pv_pmap == pmap_kernel() || npv->pv_pmap == pm) { - flags |= npv->pv_flags; - /* - * The page is mapped non-cacheable in - * this map. No need to flush the cache. - */ - if (npv->pv_flags & PVF_NC) { -#ifdef DIAGNOSTIC - if (cache_needs_cleaning) - panic("pmap_clean_page: " - "cache inconsistency"); -#endif - break; - } else if (is_src && (npv->pv_flags & PVF_WRITE) == 0) - continue; - if (cache_needs_cleaning) { - page_to_clean = 0; - break; - } else { - page_to_clean = npv->pv_va; - pm_to_clean = npv->pv_pmap; - } - cache_needs_cleaning = 1; - } - } - if (page_to_clean) { - if (PV_BEEN_EXECD(flags)) - pmap_idcache_wbinv_range(pm_to_clean, page_to_clean, - PAGE_SIZE); - else - pmap_dcache_wb_range(pm_to_clean, page_to_clean, - PAGE_SIZE, !is_src, (flags & PVF_WRITE) == 0); - } else if (cache_needs_cleaning) { - if (PV_BEEN_EXECD(flags)) - pmap_idcache_wbinv_all(pm); - else - pmap_dcache_wbinv_all(pm); - return (1); - } - return (0); -} -#endif - -/* * pmap_copy_page copies the specified (machine independent) * page by mapping the page into virtual memory and using * bcopy to copy the page, one machine dependent page at a -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20091002/f53ec0fd/attachment.pgp From yohanes at gmail.com Fri Oct 2 12:24:59 2009 From: yohanes at gmail.com (Yohanes Nugroho) Date: Fri Oct 2 12:25:05 2009 Subject: FreeBSD ARM network speed In-Reply-To: <20091002133559.283d377f.stas@FreeBSD.org> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> <20091002133559.283d377f.stas@FreeBSD.org> Message-ID: <260bb65e0910020524p374a7706r21c72a12b8ce93fb@mail.gmail.com> On Fri, Oct 2, 2009 at 4:35 PM, Stanislav Sedov wrote: > On Fri, 2 Oct 2009 12:58:38 +0700 > Yohanes Nugroho mentioned: > >> I have two question: >> 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? >> > > I don't think so. ?Our network stack is arch-independent and should perform > equally well on all platforms. ?I've been able to acchieve speeds up to > 70 Mbps on my 180Mhz AT91 based board which uses very plain and dumb > ethernet controller (although, DMA is supported). Ok, glad to hear that :) because the first time I asked about a problem in the USB, it turns out that there was a problem in the latest source code in busdma, and I have spent several days thinking it was my bug. > > This looks weird. ?Why do you stop the TX engine to add more packets > in the ring? ?This thing definitely can kill the network performace yes, you are right, that is weird, I will have a look at it again. > The main strategy of the driver should be to keep the ring filled, > waking up when some reasonable amount of space in the ring become > available, and sleeping all other time when the adapter is working. Thank you for your enlightenment. > I'm not sure why Linux doesn't use interrupt, but this looks really > wrong. It is because the driver comes from a vendor (very messy code), not in the mainline kernel yet. the background story: - I have a cheap chinese NAS device (Agestar NCB3AST, cost about $50, now you can get it for about $40), comes with linux kernel 2.4, no source code was given. SoC used is Starsemi 9104 - I found out that there is a Linux source code for this SoC but for different device (with different hardware around the SoC). - Based on the source code, I ported it to work on Linux kernel 2.6, I didn't bother to try to clean up the source code - I am thinking of trying to add my code to mainline kernel, I realized that I didn't understand most of the source code - Bruce Simpson offered a device with same SoC (NSD-100) and I tried to port FreeBSD to it, thinking that I will understand the SoC better when rewriting the code - Starsemi was bought by cavium, the SoC is renamed to Econa CNS1102, and the datasheet was released. The datasheet is not very clear, so I am still basing some of my code on the Linux code (just the logic, not copy pasting, I understand about the license implication). > I'd suggest you to ananlyze the performance of network driver > either by using the profiling tools available (kgmon, hardware > counters (if any)) or/and via system monitoring tools (top, etc). > Top, in particular, will allow you to see where all the CPU time > went. I am testing in single user mode. Last time i tested using kgmon, it doesn't show any particular area that might cause the slowdown. Once again, thank you, I now have some ideas on what to do this weekend. -- Regards Yohanes http://yohan.es/ From pyunyh at gmail.com Fri Oct 2 20:47:29 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Oct 2 20:47:35 2009 Subject: FreeBSD ARM network speed In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Message-ID: <20091002201400.GJ1512@michelle.cdnetworks.com> On Fri, Oct 02, 2009 at 12:58:38PM +0700, Yohanes Nugroho wrote: > Hi All, > Hi, [...] > The specification for the STR9104 SoC is available on Cavium website > for those who are interested, but it is not very clear, so in > developing the network driver, I followed the logic used by the Linux > driver (the initialization sequence, etc). The current code is at > http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/econa/if_ece.c&REV=4 > > Here is how the sending part works on STR9104: > > - In the initialization part, I allocate a ring, the size of the ring > is 256 entries (same as Linux version). If ethernet controller does not support 1000baseT(I think it's fastethernt because ICPlus IP101A is 10/100 PHY) allocating 256 descriptors are waste of resource especially on 64MB systems, I think. > - When being asked to send a packet, I will do the following thing: > - stop the network TX DMA > - put the address of each segment of the packet to the ring, and set > a flag so that the entry in the ring will be sent by hardware > - start the network TX DMA > > obviously there is a cleaning up part (freeing mbuf) that should be > done. The network driver can generate interrupt when a packet has been > sent (but can't tell which entry was sent). In the Linux version, this > interrupt is not used, the clean up is done just after starting the TX > DMA, at the send of the sending function, and I do the same in the > FreeBSD driver . Usually only one entry that needs to be removed, so > it is quite fast. > > Is there something obvious (or not so obvius) that I've missed? > I briefly looked over the driver code and I can see missing bus_dmamap_sync(9) in several places as well as incorrect use of bus_dma(9). This may also affect performance because checking OWN bit wouldn't be correct in CPU's view without bus_dmamap_sync(9). Another poor performance might come from m_devget(9), I don't know whether controller really needs this type of copying(sorry, have no time to read data sheet) but m_devget(9) is really slow and time consuming operation because it has to copy entire frame to new mbuf. If you had to use m_devget(9) to align buffers on ETHER_ALIGN boundary I guess you can pass the alignment restriction to bus_dma(9). Of course, this requires the controller have ability to receive frames on even address boundary or no Rx buffer alignment limitation. I believe you should not stop DMA before sending another frame as you did in Rx handler. Basically you should make controller as busy as you can to get maximum performance and should reclaim transmitted buffers as soon as you noticed. Stopping DMA may take time since it may have to drain active DMA cycles. If the controller does not generate Tx completion interrupt after sending a frame, which is not likely, you may have to implement a kind of polling in separate thread or should use polling(9). Good luck! From cognet at ci0.org Sun Oct 4 22:28:22 2009 From: cognet at ci0.org (Olivier Houchard) Date: Sun Oct 4 22:28:28 2009 Subject: [patch] Compilation problems in sys/arm/arm/pmap.c when PMAP_DEBUG is defined. In-Reply-To: <20091002155600.2c2f615d.stas@FreeBSD.org> References: <4AC599FC.1070304@tomjudge.com> <20091002155600.2c2f615d.stas@FreeBSD.org> Message-ID: <20091004223035.GA72827@ci0.org> On Fri, Oct 02, 2009 at 03:56:00PM +0400, Stanislav Sedov wrote: > On Fri, 02 Oct 2009 06:13:16 +0000 > Tom Judge mentioned: > > > Hi, > > > > I ran into some issues this evening while I was building some kernels > > with PMAP_DEBUG defined. > > > > I have attached a patch that addresses the problems with the DPRINTF > > sections. (The first 2 hunks should probably be ignored). > > > > However there are 2 warnings about unused functions when PMAP_INLINE is > > defined as "". I did not know what the correct fix for this was so I > > defined PMAP_INLINE to __inline even when PMAP_DEBUG was set, which > > seemed to hide the problem again. > > > > Actually, these two functions with PMAP_INLINE prefixes are unused. I > believe we can drop them. > > Olivier, what do you think about the following patch? > Hi Stanislav, Removing pmap_use_l1() is fine, but please just comment pmap_dcache_wbinv_all() for now, and keep pmap_clean_page(), it's here to remember we still write back/invalidate the whole cache in pmap_copy_page() which is suboptimal. Regards, Olivier From bugmaster at FreeBSD.org Mon Oct 5 11:06:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:07:20 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200910051106.n95B6l6l088607@freefall.freebsd.org> 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 arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From kelly.gata22 at gmail.com Tue Oct 6 03:50:26 2009 From: kelly.gata22 at gmail.com (Kelly) Date: Tue Oct 6 03:50:32 2009 Subject: Quer me conhecer ? Message-ID: <200910060252.n962qOGx032096@redwood.invision.net> #[1]ICRA labels [2]Swingers, Chat Adulto Gratuito & Site de Relacionamento Adulto - Adult FriendFinder Swingers, Chat Adulto Gratuito & Site de Relacionamento Adulto [glean.gif?rand=6127&site=ffadult&session=GNAbECd%40K%3B%3Eh+124593067 2+189.31.62.94+&pwsid=&pagename=ttp%3A%2F%2Fwww.google.com.br%2Fsearch &pagestate=&country=Brazil&city=&lang=portuguese&level=&gpid=g314429&p id=g314429.subgoogle4] [3]Conheça uma parceira sexual ou outros swingers como ela hoje à noite e participe Adult FriendFinder. Olhe sua fonte final para Rede Social Adulta, Sensual Namoros e Sexo Pessoal. [4]Encontre sócios reais de sexo está noite! Junta-se ao Adult FriendFinder, a maior rede de encontros sociais do mundo, Sexy Encontros e Sexy Pessoas, gratuito com mais de 20 milhões de usuários. [5]Quer encontrar uma parceira sexual como ela hoje à noite? Junte-se à Adult FriendFinder e navegue gratuitamente e encontre aquela compatibilidade excitada para você! References Visible links 1. http://graphics.pop6.com/images/ICRA_labels_rdf_adult.rdf 2. http://adultfriendfinder.com/go/g1114408 3. http://adultfriendfinder.com/go/g1114408 4. http://adultfriendfinder.com/go/g1114408 5. http://adultfriendfinder.com/go/g1114408 Hidden links: 6. http://adultfriendfinder.com/p/register.cgi?who=UmFuZG9tSVYUpehifN_D7VR_QVUJhm03H9VYqf/SWm4B3Z53sbIy7YIP/gbo2jcwKyJkLdHRy5BC1OkN6e5tfFR0sbFpAFZB0bQ5IRrl0uhTpA5Ox4O6LaMq8UA2akqTHYSkAwny9YGQTZcSFwtRsP24v30Iz6H_9RfhQXiCUyJCqvLnofBNWc67Wa1IHcTv3Shd4y1lq/Kl8FwJ79/dcBV1Ka2rV_cjKpodVxU6iP4-&site=ffadult From quickembed at gmail.com Tue Oct 6 10:30:01 2009 From: quickembed at gmail.com (quickembed) Date: Tue Oct 6 10:30:07 2009 Subject: friendly arm board Message-ID: find types of ARM board here: http://www.quickembed.com/Tools/Shop/ARM/Index.html They provide linux support, like mini 2440 and it is said that also android is supported by 6410 now! From ticso at cicely7.cicely.de Tue Oct 6 15:41:24 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Tue Oct 6 15:41:32 2009 Subject: friendly arm board In-Reply-To: References: Message-ID: <20091006154118.GE27530@cicely7.cicely.de> On Tue, Oct 06, 2009 at 05:59:18PM +0800, quickembed wrote: > find types of ARM board here: > http://www.quickembed.com/Tools/Shop/ARM/Index.html > They provide linux support, like mini 2440 and it is said that also > android is supported by 6410 now! "They"? You mean "You", at least your sender address makes it obvious. I don't think many people on this list have problems with vendors presenting their products, but it is better to play with open cards. Of course it would also be better to know something about FreeBSD support, since this is what this list is about - Linux is nice, but this is a FreeBSD list and FreeBSD-friendliness is what people prefer to read here. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From quickembed at gmail.com Tue Oct 6 16:56:51 2009 From: quickembed at gmail.com (quickembed) Date: Tue Oct 6 16:56:58 2009 Subject: friendly arm board In-Reply-To: <20091006154118.GE27530@cicely7.cicely.de> References: <20091006154118.GE27530@cicely7.cicely.de> Message-ID: You are right and I only want to bring some information here to you all, if someone has interest of porting FreeBSD to the ARM9 platforms, that will be great. I do find someone talked about working on FreeBSP on similar ARM platforms, that is the reason I posted here. Thanks for your kind notice. On Tue, Oct 6, 2009 at 11:41 PM, Bernd Walter wrote: > On Tue, Oct 06, 2009 at 05:59:18PM +0800, quickembed wrote: >> find types of ARM board here: >> http://www.quickembed.com/Tools/Shop/ARM/Index.html >> They provide linux support, like mini 2440 and it is said that also >> android is supported by 6410 now! > > "They"? > You mean "You", at least your sender address makes it obvious. > > I don't think many people on this list have problems with vendors > presenting their products, but it is better to play with open cards. > Of course it would also be better to know something about FreeBSD > support, since this is what this list is about - Linux is nice, but > this is a FreeBSD list and FreeBSD-friendliness is what people prefer > to read here. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > From stas at FreeBSD.org Tue Oct 6 17:10:22 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Oct 6 17:10:28 2009 Subject: friendly arm board In-Reply-To: References: <20091006154118.GE27530@cicely7.cicely.de> Message-ID: <20091006211019.d26c6f7c.stas@FreeBSD.org> On Wed, 7 Oct 2009 00:56:50 +0800 quickembed mentioned: > You are right and I only want to bring some information here to you > all, if someone has interest of porting FreeBSD to the ARM9 platforms, > that will be great. > I do find someone talked about working on FreeBSP on similar ARM > platforms, that is the reason I posted here. > Thanks for your kind notice. > It'd be great if this company could provide some sample boards to the FreeBSD Foundation so developers can work on bringing them up with FreeBSD. In any case thank for information on this boards, but I think this is unappropriate list for this kind of information. Maybe freebsd-misc list or FreeBSD forums will fit better. Best regards, -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20091006/e3bb848b/attachment.pgp From andrew at fubar.geek.nz Tue Oct 6 20:55:48 2009 From: andrew at fubar.geek.nz (Andrew Turner) Date: Tue Oct 6 20:55:54 2009 Subject: friendly arm board In-Reply-To: References: Message-ID: <20091007095550.5cec1f93@fubar.geek.nz> On Tue, 6 Oct 2009 17:59:18 +0800 quickembed wrote: > find types of ARM board here: > http://www.quickembed.com/Tools/Shop/ARM/Index.html > They provide linux support, like mini 2440 and it is said that also > android is supported by 6410 now! I have a mini2440 sitting on my desk that I have had running FreeBSD to single-user mode. I'm unable to boot FreeBSD with USB support on it though so I haven't managed multi-user mode. As far as I know there is nobody working on S3C6410 support. I don't know how similar the peripherals on the chip are to the S3C24x0 chips to know how difficult it would be to port FreeBSD to it. Andrew From ray at dlink.ua Wed Oct 7 09:15:36 2009 From: ray at dlink.ua (Alexandr Rybalko) Date: Wed Oct 7 09:15:42 2009 Subject: [ARM+NFS] panic while copying across NFS In-Reply-To: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com> References: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com> Message-ID: <20091007114612.00408f53.ray@dlink.ua> Hi All! Testing on Orion like board (D-Link DNS-323) I get same result, panic on copy file across NFS. panic: vm_page_insert: offset already allocated backtrace - same. On Fri, 12 Jun 2009 13:19:22 -0700 Marcel Moolenaar wrote: >> I just ran into the following panic: >> >> panic: vm_page_insert: offset already allocated >> >> I was copying a kernel across NFS at the time: >> >> orion% cd /nfs/netboot/arm >> orion% ls >> kernel-save.bin kernel.bin ubldr >> orion% sudo cp kernel.bin kernel-save.bin >> orion% sudo cp /usr/obj/nfs/freebsd/base/head/sys/ORION/kernel.bin >> kernel.bin >> >> (/usr/obj is on a local disk) >> >> With this backtrace: >> >> db> bt >> Tracing pid 26585 tid 100073 td 0xc22bd6f0 >> db_trace_thread() at db_trace_thread+0x10 >> scp=0xc0ae66e8 rlv=0xc0914d78 (db_command_init+0x484) >> rsp=0xc8492878 rfp=0xc8492898 >> r10=0x00000001 r9=0xc0bb3e94 >> r8=0xc0babdc8 r7=0xc0bab59c r6=0x00000010 r5=0x00000000 >> r4=0xc22bd6f0 >> db_command_init() at db_command_init+0x404 >> scp=0xc0914cf8 rlv=0xc09145b4 (db_skip_to_eol+0x38c) >> rsp=0xc849289c rfp=0xc8492940 >> r6=0x00000002 r5=0x00000000 >> r4=0xc0b8bb80 >> db_skip_to_eol() at db_skip_to_eol+0x1d0 >> scp=0xc09143f8 rlv=0xc09147d0 (db_command_loop+0x50) >> rsp=0xc8492944 rfp=0xc8492954 >> r10=0x00000001 r8=0x00000000 >> r7=0xc8492b1c r6=0xc0bb3e90 r5=0x00000000 r4=0xc0bab598 >> db_command_loop() at db_command_loop+0x18 >> scp=0xc0914798 rlv=0xc0916960 (X_db_sym_numargs+0xa0) >> rsp=0xc8492958 rfp=0xc8492a74 >> r4=0xc849295c >> X_db_sym_numargs() at X_db_sym_numargs+0x18 >> scp=0xc09168d8 rlv=0xc09bcb98 (kdb_trap+0xb0) >> rsp=0xc8492a78 rfp=0xc8492aa0 >> r4=0x000000c0 >> kdb_trap() at kdb_trap+0x10 >> scp=0xc09bcaf8 rlv=0xc0af76cc (undefinedinstruction+0x124) >> rsp=0xc8492aa4 rfp=0xc8492b18 >> r10=0xc22bd6f0 r9=0x00000000 >> r8=0xc09bc88c r7=0xe7ffffff r6=0xc8492b1c r5=0x00000000 >> r4=0x00000000 >> undefinedinstruction() at undefinedinstruction+0x10 >> scp=0xc0af75b8 rlv=0xc0ae8174 (address_exception_entry+0x50) >> rsp=0xc8492b1c rfp=0xc8492b7c >> r10=0xc0d147c8 r8=0x00000000 >> r7=0xc22bd6f0 r6=0xc0bb00c0 r5=0xffff1004 r4=0x00000000 >> kdb_enter() at kdb_enter+0x14 >> scp=0xc09bc858 rlv=0xc09955f4 (panic+0xa0) >> rsp=0xc8492b80 rfp=0xc8492b94 >> r5=0xc0b4c994 r4=0x00000100 >> panic() at panic+0x1c >> scp=0xc0995570 rlv=0xc0ad8de0 (vm_page_insert+0x164) >> rsp=0xc8492ba8 rfp=0xc8492bc8 >> vm_page_insert() at vm_page_insert+0x10 >> scp=0xc0ad8c8c rlv=0xc0ad90f4 (vm_page_alloc+0x304) >> rsp=0xc8492bcc rfp=0xc8492bf4 >> r8=0x00001e03 r7=0x00000061 >> r6=0x00000001 r5=0xc0fe25c8 r4=0x00000000 >> vm_page_alloc() at vm_page_alloc+0x10 >> scp=0xc0ad8e00 rlv=0xc0acd740 (kmem_malloc+0x2b4) >> rsp=0xc8492bf8 rfp=0xc8492c48 >> r10=0x00000000 r9=0x00001000 >> r8=0x00000103 r7=0xc0e3a088 r6=0x01e03000 r5=0x00000061 >> r4=0xc1e03000 >> kmem_malloc() at kmem_malloc+0x14 >> scp=0xc0acd4a0 rlv=0xc0ac77bc (uma_zcreate+0xd0) >> rsp=0xc8492c4c rfp=0xc8492c88 >> r10=0xc0ac5efc r9=0xc0e36640 >> r8=0x00000103 r7=0xc1dfd000 r6=0xc1dfd000 r5=0x00000003 >> r4=0xc0e2d280 >> uma_zcreate() at uma_zcreate+0x70 >> scp=0xc0ac775c rlv=0xc0ac7d28 (uma_prealloc+0x198) >> rsp=0xc8492c8c rfp=0xc8492cac >> r10=0xc0e319d8 r9=0x00000020 >> r8=0xc0e36640 r7=0x00000000 r6=0xc0e36640 r5=0x00000203 >> r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0xd4 >> scp=0xc0ac7c64 rlv=0xc0ac7fe8 (uma_prealloc+0x458) >> rsp=0xc8492cb0 rfp=0xc8492cc8 >> r7=0x00000002 r6=0xc0e36640 >> r5=0x00000003 r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0x42c >> scp=0xc0ac7fbc rlv=0xc0ac9230 (uma_zalloc_arg+0x32c) >> rsp=0xc8492ccc rfp=0xc8492d10 >> r6=0xc1a5dcc0 r5=0x00000013 >> r4=0x00000013 >> uma_zalloc_arg() at uma_zalloc_arg+0x10 >> scp=0xc0ac8f14 rlv=0xc0a86710 (nfsm_uiotombuf+0xec) >> rsp=0xc8492d14 rfp=0xc8492d5c >> r10=0xc4bc0fcc r9=0x00008000 >> r8=0x00006034 r7=0xc8492df4 r6=0xc1976800 r5=0x00000800 >> r4=0x00000000 >> nfsm_uiotombuf() at nfsm_uiotombuf+0x10 >> scp=0xc0a86634 rlv=0xc0a8e8f4 (nfs_writerpc+0x1a8) >> rsp=0xc8492d60 rfp=0xc8492ddc >> r10=0xc3884910 r9=0x00008000 >> r8=0xc1acb000 r7=0x00008000 r6=0xc8492df4 r5=0xc1979900 >> r4=0x00000000 >> nfs_writerpc() at nfs_writerpc+0x10 >> scp=0xc0a8e75c rlv=0xc0a7f680 (nfs_doio+0x204) >> rsp=0xc8492de0 rfp=0xc8492e4c >> r10=0xc3884910 r9=0xc235cca8 >> r8=0x00008000 r7=0x00000000 r6=0x00000000 r5=0x000000c0 >> r4=0x00000000 >> nfs_doio() at nfs_doio+0x10 >> scp=0xc0a7f48c rlv=0xc0a871d8 (nfs_nfsiodnew+0x3c4) >> rsp=0xc8492e50 rfp=0xc8492e80 >> r10=0x00000000 r9=0xc0d13ab4 >> r8=0xc0d13990 r7=0x00000006 r6=0x00000000 r5=0xc1acb000 >> r4=0xc3884910 >> nfs_nfsiodnew() at nfs_nfsiodnew+0x2ac >> scp=0xc0a870c0 rlv=0xc0974b84 (fork_exit+0x64) >> rsp=0xc8492e84 rfp=0xc8492ea8 >> r10=0xc0a870b0 r9=0xc0d1f6c0 >> r8=0xc0d13368 r7=0xc1c6a828 r6=0xc8492eac r5=0xc0d1f6c0 >> r4=0xc22bd6f0 >> fork_exit() at fork_exit+0x10 >> scp=0xc0974b30 rlv=0xc0af6190 (fork_trampoline+0x14) >> rsp=0xc8492eac rfp=0x00000000 >> r10=0xc0d1f6c0 r8=0x00000104 >> r7=0xc0ae7f4c r6=0xc8492eac r5=0xc0d13368 r4=0xc0a870b0 >> >> >> FYI, >> >> -- >> Marcel Moolenaar >> xcllnt@mac.com >> >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Alexandr Rybalko From quickembed at gmail.com Thu Oct 8 04:12:57 2009 From: quickembed at gmail.com (quickembed) Date: Thu Oct 8 04:13:03 2009 Subject: friendly arm board In-Reply-To: <20091007095550.5cec1f93@fubar.geek.nz> References: <20091007095550.5cec1f93@fubar.geek.nz> Message-ID: Glad to hear that you boot up FreeBSD on the board, however making each driver work does take effort, like usb, lcd, speaker etc. maybe you can merge some some code from the package of the board. 6410 is different, it is ARM11, 2440 is ARM9, so expect difference. On Wed, Oct 7, 2009 at 4:55 AM, Andrew Turner wrote: > On Tue, 6 Oct 2009 17:59:18 +0800 > quickembed wrote: > >> find types of ARM board here: >> http://www.quickembed.com/Tools/Shop/ARM/Index.html >> They provide linux support, like mini 2440 and it is said that also >> android is supported by 6410 now! > I have a mini2440 sitting on my desk that I have had running FreeBSD to > single-user mode. I'm unable to boot FreeBSD with USB support on it > though so I haven't managed multi-user mode. > > As far as I know there is nobody working on S3C6410 support. I don't > know how similar the peripherals on the chip are to the S3C24x0 chips > to know how difficult it would be to port FreeBSD to it. > > Andrew > From gballet at gmail.com Thu Oct 8 14:18:56 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Thu Oct 8 14:19:03 2009 Subject: Adding members to struct cpu_functions Message-ID: Hello list, I am continuing my effort to port FreeBSD to the BeagleBoard. I reached the point where the system prompts for the root filesystem. I am therefore cleaning up my code and will then post it to this list for comments. I still have a few hacky fixups to remove before it becomes readable :) I know that Mark Tinguely, whose help has been precious in this endeavor, has some patches ready for ARMv6 cache management, so I did not focus on this. At the moment, I am using backward-compatibility for the TLB format. I want to start using the ARMv6 TLB format. My current problem is that most of the arch-dependent code uses macros that are defined to match the pre-ARMv6 TLB format. There are several ways of fixing this, including defining these macros depending on some symbol such as _ARM_ARCH_* or CPU_ARM*. I am however no friend of heavy preprocessor flagging. What if instead, cpu_functions was extended to include fields like the prototype for TLB entries of each size? For example, take this patch to the following excerpt from pmap_map_chunk in sys/arm/arm/pmap.c: /* See if we can use a L2 large page mapping. */ if (L2_L_MAPPABLE_P(va, pa, resid)) { #ifdef VERBOSE_INIT_ARM printf("L"); #endif for (i = 0; i < 16; i++) { pte[l2pte_index(va) + i] = - L2_L_PROTO | pa | + cpufuncs.cf_l2_l_proto | pa | - L2_L_PROT(PTE_KERNEL, prot) | f2l; + cpufuncs.l2_l_prot(PTE_KERNEL, prot) | f2l; PTE_SYNC(&pte[l2pte_index(va) + i]); } va += L2_L_SIZE; pa += L2_L_SIZE; resid -= L2_L_SIZE; continue; } Would that be acceptable? Now, assuming people agree with this change, that would only be a first step because all values for cpufuncs are defined in the same file (cpufunc.c), which is guarded with as many CPU_ARMx defines as there are cpu flavors. Is there a specific reason for all these structures to be defined in a same file, instead of defining it in a platform- or cpu-specific file and using the files.* to select the appropriate cpufunc flavor in the build system? Guillaume From tinguely at casselton.net Thu Oct 8 16:13:57 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Thu Oct 8 16:14:03 2009 Subject: Adding members to struct cpu_functions In-Reply-To: Message-ID: <200910081613.n98GDt7r053539@casselton.net> > I am continuing my effort to port FreeBSD to the BeagleBoard. I > reached the point where the system prompts for the root filesystem. I > am therefore cleaning up my code and will then post it to this list > for comments. I still have a few hacky fixups to remove before it > becomes readable :) Congratulations. > I know that Mark Tinguely, whose help has been precious in this > endeavor, has some patches ready for ARMv6 cache management, so I did > not focus on this. It is all untested. I am wondering to myself with small number of TBL on the OMAP, should we use the new ASID process identifier and not flush the TBLs or just flush them on context switch. > At the moment, I am using backward-compatibility for the TLB format. I > want to start using the ARMv6 TLB format. My current problem is that > most of the arch-dependent code uses macros that are defined to match > the pre-ARMv6 TLB format. There are several ways of fixing this, > including defining these macros depending on some symbol such as > _ARM_ARCH_* or CPU_ARM*. I am however no friend of heavy preprocessor > flagging. What if instead, cpu_functions was extended to include > fields like the prototype for TLB entries of each size? For example, > take this patch to the following excerpt from pmap_map_chunk in > sys/arm/arm/pmap.c: [deleted example] > Now, assuming people agree with this change, that would only be a > first step because all values for cpufuncs are defined in the same > file (cpufunc.c), which is guarded with as many CPU_ARMx defines as > there are cpu flavors. Is there a specific reason for all these > structures to be defined in a same file, instead of defining it in a > platform- or cpu-specific file and using the files.* to select the > appropriate cpufunc flavor in the build system? I have been pondering the current L1/L2 (in this context we mean Page Directory entries and Page Table entries, not cache levels) values for cache, protection, the C/B/TEX (and now the global, secure, and no execute) and masks for a while. Some of these values are variables and some are defines. It can be confusing to track down a value for a ARCH/board. ARM kernels are very specific for processor and board. IMO, we should be moving some of these settings into a processor [and board] directories/files and make them more consistant. I am not saying anything bad about NetBSD that originate these files nor the additions that have been made since, what I am saying is it would be nice to have a big reorganization; that takes time and therefore money. -- on a tangent about the future -- Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs ARMv6/7 questions, the most important is should we break the new ARM chips with their physical tagged caches to another subbranch or define it into the existing code? One example of the existing pmap code that does not mesh well with ARMv6/7 is the exisiting flush of the level 2 cache because the old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, and would not be flushed until DMA time. A simple solution would be if an arch needs to flush the level 2 cache when it flushes the level 1 cache, then it should do so in the level 1 cache flushing routine. --Mark Tinguely. From xcllnt at mac.com Sat Oct 10 18:16:49 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Oct 10 18:16:54 2009 Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap Message-ID: Hardware: o Marvell DB-78XXX o 500GB USB disk (da0, mounted /) o 500GB SATA disk (ad0, mounted /mnt) o 1Gb ethernet (NFS mounted /nfs) While running rsync from da0p1 to ad0p1 without crossing file systems (i.e. NFS not involved) I got the following panic: # sudo rsync -alHv --delete --one-file-system / /mnt/ sending incremental file list ./ .cshrc .profile ... usr/local/man/man1/pod2html.1.gz usr/local/man/man1/pod2latex.1.gz usr/local/man/man1/pod2man.1.gz panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap @ / zmirror/nfs/freebsd/base/head/sys/arm/arm/pmap.c:1916 KDB: enter: panic [thread pid 857 tid 100051 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! db> It looks like cron is the culprit: db> show alllocks Process 857 (cron) thread 0xc3984d80 (100051) exclusive sleep mutex pmap (pmap) r = 0 (0xc3a330b0) locked @ /zmirror/ nfs/freebsd/base/head/sys/arm/arm/pmap.c:3254 exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 1 (0xc0d897c0) locked @ /zmirror/nfs/freebsd/base/head/sys/arm/arm/ pmap.c:1915 exclusive sx user map (user map) r = 0 (0xc3a7752c) locked @ /zmirror/ nfs/freebsd/base/head/sys/vm/vm_map.c:2981 exclusive sx user map (user map) r = 0 (0xc3a33048) locked @ /zmirror/ nfs/freebsd/base/head/sys/vm/vm_map.c:2973 db> bt Tracing pid 857 tid 100051 td 0xc3984d80 db_trace_thread() at db_trace_thread+0x10 scp=0xc0b47420 rlv=0xc0919f8c (db_command_init+0x4d4) rsp=0xd1c6b83c rfp=0xd1c6b85c r10=0x00000001 r9=0xc0c290b0 r8=0xc0c20e4c r7=0xc0c20620 r6=0x00000010 r5=0x00000000 r4=0xc3984d80 db_command_init() at db_command_init+0x454 scp=0xc0919f0c rlv=0xc0919738 (db_skip_to_eol+0x38c) rsp=0xd1c6b860 rfp=0xd1c6b904 r6=0x00000002 r5=0x00000000 r4=0xc0bfb5c8 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc091957c rlv=0xc0919954 (db_command_loop+0x50) rsp=0xd1c6b908 rfp=0xd1c6b918 r10=0x00000001 r8=0x00000000 r7=0xd1c6bae4 r6=0xc0c290ac r5=0x000000c0 r4=0xc0c2061c db_command_loop() at db_command_loop+0x18 scp=0xc091991c rlv=0xc091bb9c (X_db_sym_numargs+0xa0) rsp=0xd1c6b91c rfp=0xd1c6ba38 r4=0xd1c6b920 X_db_sym_numargs() at X_db_sym_numargs+0x18 scp=0xc091bb14 rlv=0xc09fe9a8 (kdb_trap+0xb0) rsp=0xd1c6ba3c rfp=0xd1c6ba64 r4=0x000000c0 kdb_trap() at kdb_trap+0x10 scp=0xc09fe908 rlv=0xc0b57ed0 (undefinedinstruction+0x124) rsp=0xd1c6ba68 rfp=0xd1c6bae0 r10=0xc3984d80 r9=0xc0d94e80 r8=0xc09fe69c r7=0xe7ffffff r6=0xd1c6bae4 r5=0x00000000 r4=0x00000000 undefinedinstruction() at undefinedinstruction+0x10 scp=0xc0b57dbc rlv=0xc0b48ea8 (address_exception_entry+0x50) rsp=0xd1c6bae4 rfp=0xd1c6bb44 r10=0xc0d94e80 r9=0x00000001 r8=0x0000077c r7=0xc3984d80 r6=0xc0c252f8 r5=0xffff1004 r4=0x00000000 kdb_enter() at kdb_enter+0x14 scp=0xc09fe668 rlv=0xc09d2304 (panic+0xa0) rsp=0xd1c6bb48 rfp=0xd1c6bb5c r5=0xc0b936f8 r4=0x00000100 panic() at panic+0x1c scp=0xc09d2280 rlv=0xc09c410c (_mtx_lock_sleep+0x130) rsp=0xd1c6bb70 rfp=0xd1c6bb88 _mtx_lock_sleep() at _mtx_lock_sleep+0x10 scp=0xc09c3fec rlv=0xc09c41ec (_mtx_lock_flags+0xd4) rsp=0xd1c6bb8c rfp=0xd1c6bbb4 r6=0x00000000 r5=0xc3a330b0 r4=0x00000000 _mtx_lock_flags() at _mtx_lock_flags+0x10 scp=0xc09c4128 rlv=0xc0b4dfe4 (pmap_fault_fixup+0x48) rsp=0xd1c6bbb8 rfp=0xd1c6bbec r10=0xd1c6bc94 r8=0x00000001 r7=0xc3984d80 r6=0x00019000 r5=0xc3a330b0 r4=0x00000000 pmap_fault_fixup() at pmap_fault_fixup+0x10 scp=0xc0b4dfac rlv=0xc0b571a8 (data_abort_handler+0x16c) rsp=0xd1c6bbf0 rfp=0xd1c6bc90 r10=0xd1c6bc94 r9=0xd1c6bef8 r8=0x00000001 r7=0xc3984d80 r6=0x000e7000 r5=0x00019000 r4=0x00000007 data_abort_handler() at data_abort_handler+0x10 scp=0xc0b5704c rlv=0xc0b48ea8 (address_exception_entry+0x50) rsp=0xd1c6bc94 rfp=0xd1c6bd20 r10=0xc3a330b0 r9=0x00100000 r8=0x000e9000 r7=0x00019000 r6=0x000e7000 r5=0xffff1004 r4=0x00017000 pmap_protect() at pmap_protect+0x10 scp=0xc0b50970 rlv=0xc0b2f460 (vmspace_fork+0x420) rsp=0xd1c6bd24 rfp=0xd1c6bd60 r10=0xc3a33000 r9=0x00008000 r8=0xc3a774e4 r7=0x00000001 r6=0xc3a1c168 r5=0xc3a5cca8 r4=0x00000000 vmspace_fork() at vmspace_fork+0x10 scp=0xc0b2f050 rlv=0xc09ad6cc (fork1+0x100) rsp=0xd1c6bd64 rfp=0xd1c6bdbc r10=0xc397f834 r9=0xc3984d80 r8=0x00000014 r7=0xd1c6beac r6=0xc3a30af0 r5=0x00000002 r4=0x00000000 fork1() at fork1+0x10 scp=0xc09ad5dc rlv=0xc09ae848 (fork+0x24) rsp=0xd1c6bdc0 rfp=0xd1c6bdd8 r10=0xc397f834 r9=0x00000000 r8=0xc0c05360 r7=0xd1c6beac r6=0x00000002 r5=0xc3984d80 r4=0xc3984d80 fork() at fork+0x10 scp=0xc09ae834 rlv=0xc0b57674 (swi_handler+0x128) rsp=0xd1c6bddc rfp=0xd1c6bea8 r4=0x00000000 swi_handler() at swi_handler+0x10 scp=0xc0b5755c rlv=0xc0b48c80 (swi_entry+0x40) rsp=0xd1c6beac rfp=0xbfffed20 r10=0x0000000b r9=0x00000000 r8=0x00000000 r7=0x000187c8 r6=0x00000000 r5=0x20215028 r4=0x20216040 db> ps pid ppid pgrp uid state wmesg wchan cmd 970 969 968 0 R+ rsync 969 968 968 0 S+ select 0xc3a21324 rsync 968 907 968 0 R+ rsync 907 906 907 501 S+ pause 0xc38d388c tcsh 906 1 906 0 Ss+ wait 0xc3a302bc login 884 1 884 0 Ss select 0xc38f8be4 inetd 857 1 857 0 Rs CPU 0 cron 851 1 851 25 Ss pause 0xc3a30058 sendmail 847 1 847 0 Ss select 0xc3a203a4 sendmail 842 1 842 0 Ss select 0xc3a201a4 sshd 811 1 811 1 Ss sbwait 0xc3a22254 rwhod 781 1 781 0 Ss select 0xc38c7764 ntpd 717 1 717 0 Ss rpcsvc 0xc38ec910 NLM: master 711 1 711 0 Ss select 0xc38dfae4 rpc.statd 636 1 636 0 Ss select 0xc38ec624 ypbind 618 1 618 0 Ss select 0xc38f8064 rpcbind 598 1 598 0 Ss select 0xc38ecb64 syslogd 482 1 482 0 Ss select 0xc37589e4 devd 481 1 481 65 Ss select 0xc386c6e4 dhclient 441 1 441 0 Ss select 0xc38ecd24 dhclient 16 0 0 0 SL - 0xc0c25554 [schedcpu] 15 0 0 0 SL syncer 0xc0d83f38 [syncer] 14 0 0 0 SL vlruwt 0xc38d3000 [vnlru] 9 0 0 0 SL psleep 0xc0d83cb4 [bufdaemon] 8 0 0 0 SL pgzero 0xc0d89d4c [pagezero] 7 0 0 0 SL pollid 0xc0c24de4 [idlepoll] 6 0 0 0 SL psleep 0xc0d89848 [pagedaemon] 13 0 0 0 SL (threaded) [usb] 100032 D - 0xc3679d0c [usbus2] 100031 D - 0xc3679cdc [usbus2] 100030 D - 0xc3679cac [usbus2] 100029 D - 0xc3679c7c [usbus2] 100027 D - 0xc3657d0c [usbus1] 100026 D - 0xc3657cdc [usbus1] 100025 D - 0xc3657cac [usbus1] 100024 D - 0xc3657c7c [usbus1] 100022 D - 0xc3634d0c [usbus0] 100021 D - 0xc3634cdc [usbus0] 100020 D - 0xc3634cac [usbus0] 100019 D - 0xc3634c7c [usbus0] 5 0 0 0 SL ccb_scan 0xc0c1fa24 [xpt_thrd] 12 0 0 0 SL - 0xc0c25554 [yarrow] 4 0 0 0 SL - 0xc0c22de8 [g_down] 3 0 0 0 SL - 0xc0c22de4 [g_up] 2 0 0 0 SL - 0xc0c22ddc [g_event] 11 0 0 0 WL (threaded) [intr] 100037 I [intr26: sata0] 100036 I [intr46: mge1] 100035 I [intr45: mge1] 100034 I [intr42: mge0] 100033 I [intr41: mge0] 100028 I [intr18: ehci2] 100023 I [intr17: ehci1] 100018 I [intr16: ehci0] 100017 I [swi0: uart uart] 100015 I [swi2: cambio] 100013 I [swi6: task queue] 100012 I [swi6: Giant taskq] 100010 I [swi5: +] 100005 I [swi4: clock] 100004 I [swi3: vm] 100003 I [swi1: netisr 0] 10 0 0 0 RL [idle] 1 0 1 0 SLs wait 0xc35bf000 [init] 0 0 0 0 SLs (threaded) [kernel] 100016 D - 0xc361cd80 [kqueue taskq] 100011 D - 0xc361d140 [thread taskq] 100000 D sched 0xc0c22e38 [swapper] db> show intrcnt irq8: timer0 90926 irq12: uart0 37904 irq16: ehci0 75948 irq41: mge0 679 irq42: mge0 660 irq26: sata0 265343 FYI, -- Marcel Moolenaar xcllnt@mac.com From bugmaster at FreeBSD.org Mon Oct 12 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:07:36 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200910121106.n9CB6mju036317@freefall.freebsd.org> 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 arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From raj at semihalf.com Mon Oct 12 11:15:44 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Oct 12 11:16:00 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <200910081613.n98GDt7r053539@casselton.net> References: <200910081613.n98GDt7r053539@casselton.net> Message-ID: <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> On 2009-10-08, at 18:13, Mark Tinguely wrote: > -- on a tangent about the future -- > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs > ARMv6/7 > questions, the most important is should we break the new ARM chips > with > their physical tagged caches to another subbranch or define it into > the > existing code? One example of the existing pmap code that does not > mesh > well with ARMv6/7 is the exisiting flush of the level 2 cache > because the > old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, > and would not be flushed until DMA time. A simple solution would be if > an arch needs to flush the level 2 cache when it flushes the level 1 > cache, then it should do so in the level 1 cache flushing routine. I was wondering whether a separate pmap module for ARMv6-7 would not be the best approach. After all v6-7 should be considered an entirely new architecture variation, and we would avoid the very likely #ifdefs hell in case of a single pmap.c. Rafal From stas at deglitch.com Mon Oct 12 11:36:37 2009 From: stas at deglitch.com (Stanislav Sedov) Date: Mon Oct 12 11:36:43 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> Message-ID: <20091012153628.9196951f.stas@deglitch.com> On Mon, 12 Oct 2009 13:15:41 +0200 Rafal Jaworowski mentioned: > > On 2009-10-08, at 18:13, Mark Tinguely wrote: > > > -- on a tangent about the future -- > > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs > > ARMv6/7 > > questions, the most important is should we break the new ARM chips > > with > > their physical tagged caches to another subbranch or define it into > > the > > existing code? One example of the existing pmap code that does not > > mesh > > well with ARMv6/7 is the exisiting flush of the level 2 cache > > because the > > old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, > > and would not be flushed until DMA time. A simple solution would be if > > an arch needs to flush the level 2 cache when it flushes the level 1 > > cache, then it should do so in the level 1 cache flushing routine. > > I was wondering whether a separate pmap module for ARMv6-7 would not > be the best approach. After all v6-7 should be considered an entirely > new architecture variation, and we would avoid the very likely #ifdefs > hell in case of a single pmap.c. > Yeah, I think that would be the best solution. We could conditionally select the right pmap.c file based on the target CPU selected (just like we do for board variations for at91/marvell). -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20091012/27150354/attachment.pgp From gballet at gmail.com Mon Oct 12 12:29:21 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Mon Oct 12 12:29:28 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <20091012153628.9196951f.stas@deglitch.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> Message-ID: On Mon, Oct 12, 2009 at 1:36 PM, Stanislav Sedov wrote: > On Mon, 12 Oct 2009 13:15:41 +0200 > Rafal Jaworowski mentioned: > >> >> On 2009-10-08, at 18:13, Mark Tinguely wrote: >> >> > ? ? ? ? ? ? ? ? ? ? -- on a tangent about the future -- >> > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs >> > ARMv6/7 >> > questions, the most important is should we break the new ARM chips >> > with >> > their physical tagged caches to another subbranch or define it into >> > the >> > existing code? One example of the existing pmap code that does not >> > mesh >> > well with ARMv6/7 is the exisiting flush of the level 2 cache >> > because the >> > old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, >> > and would not be flushed until DMA time. A simple solution would be if >> > an arch needs to flush the level 2 cache when it flushes the level 1 >> > cache, then it should do so in the level 1 cache flushing routine. >> >> I was wondering whether a separate pmap module for ARMv6-7 would not >> be the best approach. After all v6-7 should be considered an entirely >> new architecture variation, and we would avoid the very likely #ifdefs >> hell in case of a single pmap.c. >> > > Yeah, I think that would be the best solution. ?We could conditionally > select the right pmap.c file based on the target CPU selected (just > like we do for board variations for at91/marvell). > pmap.c is a very large file that seems to change very often. I fear having several versions is going to be difficult to maintain. Granted, I haven't read the whole file line after line. Yet it seems to me its content can be abstracted to rely on arch-specific functions that would be found in cpufuncs instead of hardcoded macros. Is there something fundamentally wrong with enhancing struct cpufunc in order to let the portmeisters decide what the MMU and caching bits should look like? This is a blocking issue for me, since it looks like the omap has some problem with backward compatibility mode. Without fixing up the TLBs in my initarm function, it doesn't work. Speaking of #ifdef hell, why not breaking cpufuncs.c into several cpufuncs_.c? That would be a good way to start that reorganization Mark has been talking about in his email. Guillaume From nwhitehorn at freebsd.org Mon Oct 12 14:22:02 2009 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Mon Oct 12 14:22:35 2009 Subject: Adding members to struct cpu_functions In-Reply-To: References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> Message-ID: <4AD32D76.3090401@freebsd.org> Guillaume Ballet wrote: > On Mon, Oct 12, 2009 at 1:36 PM, Stanislav Sedov wrote: > >> On Mon, 12 Oct 2009 13:15:41 +0200 >> Rafal Jaworowski mentioned: >> >> >>> On 2009-10-08, at 18:13, Mark Tinguely wrote: >>> >>> >>>> -- on a tangent about the future -- >>>> Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs >>>> ARMv6/7 >>>> questions, the most important is should we break the new ARM chips >>>> with >>>> their physical tagged caches to another subbranch or define it into >>>> the >>>> existing code? One example of the existing pmap code that does not >>>> mesh >>>> well with ARMv6/7 is the exisiting flush of the level 2 cache >>>> because the >>>> old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, >>>> and would not be flushed until DMA time. A simple solution would be if >>>> an arch needs to flush the level 2 cache when it flushes the level 1 >>>> cache, then it should do so in the level 1 cache flushing routine. >>>> >>> I was wondering whether a separate pmap module for ARMv6-7 would not >>> be the best approach. After all v6-7 should be considered an entirely >>> new architecture variation, and we would avoid the very likely #ifdefs >>> hell in case of a single pmap.c. >>> >>> >> Yeah, I think that would be the best solution. We could conditionally >> select the right pmap.c file based on the target CPU selected (just >> like we do for board variations for at91/marvell). >> >> > > pmap.c is a very large file that seems to change very often. I fear > having several versions is going to be difficult to maintain. Granted, > I haven't read the whole file line after line. Yet it seems to me its > content can be abstracted to rely on arch-specific functions that > would be found in cpufuncs instead of hardcoded macros. Is there > something fundamentally wrong with enhancing struct cpufunc in order > to let the portmeisters decide what the MMU and caching bits should > look like? This is a blocking issue for me, since it looks like the > omap has some problem with backward compatibility mode. Without fixing > up the TLBs in my initarm function, it doesn't work. > > Speaking of #ifdef hell, why not breaking cpufuncs.c into several > cpufuncs_.c? That would be a good way to start that > reorganization Mark has been talking about in his email. > One thing that might be worth looking at while thinking about this is how this is done on PowerPC. We have run-time selectable PMAP modules using KOBJ to handle CPUs with different MMU designs, as well as a platform module scheme, again using KOBJ, to pick the appropriate PMAP for the board as well as determine the physical memory layout and such things. One of the nice things about the approach is that it is easy to subclass if you have a new, marginally different, design, and it avoids #ifdef hell as well as letting you build a GENERIC kernel with support for multiple MMU designs and board types (the last less of a concern on ARM, though). -Nathan From raj at semihalf.com Mon Oct 12 15:07:37 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Oct 12 15:07:43 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <4AD32D76.3090401@freebsd.org> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> Message-ID: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> On 2009-10-12, at 15:21, Nathan Whitehorn wrote: >>>> I was wondering whether a separate pmap module for ARMv6-7 would >>>> not >>>> be the best approach. After all v6-7 should be considered an >>>> entirely >>>> new architecture variation, and we would avoid the very likely >>>> #ifdefs >>>> hell in case of a single pmap.c. >>>> >>>> >>> Yeah, I think that would be the best solution. We could >>> conditionally >>> select the right pmap.c file based on the target CPU selected (just >>> like we do for board variations for at91/marvell). >>> >>> >> >> pmap.c is a very large file that seems to change very often. I fear >> having several versions is going to be difficult to maintain. >> Granted, >> I haven't read the whole file line after line. Yet it seems to me its >> content can be abstracted to rely on arch-specific functions that >> would be found in cpufuncs instead of hardcoded macros. Is there >> something fundamentally wrong with enhancing struct cpufunc in order >> to let the portmeisters decide what the MMU and caching bits should >> look like? This is a blocking issue for me, since it looks like the >> omap has some problem with backward compatibility mode. Without >> fixing >> up the TLBs in my initarm function, it doesn't work. >> >> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >> cpufuncs_.c? That would be a good way to start that >> reorganization Mark has been talking about in his email. >> > One thing that might be worth looking at while thinking about this > is how this is done on PowerPC. We have run-time selectable PMAP > modules using KOBJ to handle CPUs with different MMU designs, as > well as a platform module scheme, again using KOBJ, to pick the > appropriate PMAP for the board as well as determine the physical > memory layout and such things. One of the nice things about the > approach is that it is easy to subclass if you have a new, > marginally different, design, and it avoids #ifdef hell as well as > letting you build a GENERIC kernel with support for multiple MMU > designs and board types (the last less of a concern on ARM, though). What always concerned me was the performance cost this imposes, and it would be a really useful exercise to measure what is the actual impact of KOBJ-tized pmap we have in PowerPC; with an often-called interface like pmap it might occur the penalty is not that little.. Rafal From gballet at gmail.com Mon Oct 12 20:35:28 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Mon Oct 12 20:35:35 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> Message-ID: On Mon, Oct 12, 2009 at 5:07 PM, Rafal Jaworowski wrote: > > On 2009-10-12, at 15:21, Nathan Whitehorn wrote: > >>>>> I was wondering whether a separate pmap module for ARMv6-7 would not >>>>> be the best approach. After all v6-7 should be considered an entirely >>>>> new architecture variation, and we would avoid the very likely #ifdefs >>>>> hell in case of a single pmap.c. >>>>> >>>>> >>>> Yeah, I think that would be the best solution. ?We could conditionally >>>> select the right pmap.c file based on the target CPU selected (just >>>> like we do for board variations for at91/marvell). >>>> >>>> >>> >>> pmap.c is a very large file that seems to change very often. I fear >>> having several versions is going to be difficult to maintain. Granted, >>> I haven't read the whole file line after line. Yet it seems to me its >>> content can be abstracted to rely on arch-specific functions that >>> would be found in cpufuncs instead of hardcoded macros. Is there >>> something fundamentally wrong with enhancing struct cpufunc in order >>> to let the portmeisters decide what the MMU and caching bits should >>> look like? This is a blocking issue for me, since it looks like the >>> omap has some problem with backward compatibility mode. Without fixing >>> up the TLBs in my initarm function, it doesn't work. >>> >>> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >>> cpufuncs_.c? That would be a good way to start that >>> reorganization Mark has been talking about in his email. >>> >> One thing that might be worth looking at while thinking about this is how >> this is done on PowerPC. We have run-time selectable PMAP modules using KOBJ >> to handle CPUs with different MMU designs, as well as a platform module >> scheme, again using KOBJ, to pick the appropriate PMAP for the board as well >> as determine the physical memory layout and such things. One of the nice >> things about the approach is that it is easy to subclass if you have a new, >> marginally different, design, and it avoids #ifdef hell as well as letting >> you build a GENERIC kernel with support for multiple MMU designs and board >> types (the last less of a concern on ARM, though). > > What always concerned me was the performance cost this imposes, and it would > be a really useful exercise to measure what is the actual impact of > KOBJ-tized pmap we have in PowerPC; with an often-called interface like pmap > it might occur the penalty is not that little.. > > Rafal > > Good point. Using KOBJs this way is really cool, but the overhead is going to be a concern if it is used by an application that allocates memory very often. This is not the case of most embedded appliances I worked with, still one should not assume anything about the userland at kernel level. As a result, extending the struct cpu_functions is not a good thing either, for the same reason. The compiler can not inline a call through a function pointer. In which case, why not create a bunch of headers files with the pattern cpufunc_myarch.h, in which all functions would be declared inline? Something like: static inline l2_l_entry(vm_addr_t pa, int prot, int cache); static inline l2_s_entry(vm_addr_t pa, int prot, int cache); ... which would then be included by pmap.c and friends. One problem is that such a change affects all platforms at the same time, and therefore requires all portmeisters to implement the functions that are needed. That should not be too difficult, though, because so far it was the same macros that were used by all platforms. Another problem is that it requires some build script magic to make sure the correct header is included depending on the arch. I wonder if this is easy? Guillaume From tom at tomjudge.com Mon Oct 12 20:46:22 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Oct 12 20:46:29 2009 Subject: i80321 PCI Memory Allocations Fix Message-ID: <4AD39573.2060403@tomjudge.com> Hi, While I was porting FreeBSD to my Intel SS4000-E NAS unit I came across what seems a bug in the PCI memory allocation routings for the i80321. Here is the patch that I have used to fix the issue: http://svn.tomjudge.com/freebsd/patches/ss4000-e/i80321_pci.patch Does this seem correct (functionally it seems to work ok for me)? Thanks PS: Anyone interested can track my project progress here: http://www.tomjudge.com/index.php/SS4000-E From tinguely at casselton.net Mon Oct 12 21:29:25 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Mon Oct 12 21:29:30 2009 Subject: Adding members to struct cpu_functions In-Reply-To: Message-ID: <200910122129.n9CLTHsp087996@casselton.net> > As a result, extending the struct cpu_functions is not a good thing > either, for the same reason. The compiler can not inline a call > through a function pointer. > > In which case, why not create a bunch of headers files with the > pattern cpufunc_myarch.h, in which all functions would be declared > inline? Something like: > > static inline l2_l_entry(vm_addr_t pa, int prot, int cache); > static inline l2_s_entry(vm_addr_t pa, int prot, int cache); > ... > which would then be included by pmap.c and friends. I think they need to be regular function calls because assembly routines call the per-cpu functions. A few simple macros would save the branch to NOP functions. > One problem is that such a change affects all platforms at the same > time, and therefore requires all portmeisters to implement the > functions that are needed. That should not be too difficult, though, > because so far it was the same macros that were used by all platforms. > Another problem is that it requires some build script magic to make > sure the correct header is included depending on the arch. I wonder if > this is easy? --Mark Tinguely From nwhitehorn at freebsd.org Mon Oct 12 21:47:20 2009 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Mon Oct 12 21:47:26 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> Message-ID: <4AD39C78.5050309@freebsd.org> Rafal Jaworowski wrote: > > On 2009-10-12, at 15:21, Nathan Whitehorn wrote: > >>>>> I was wondering whether a separate pmap module for ARMv6-7 would not >>>>> be the best approach. After all v6-7 should be considered an entirely >>>>> new architecture variation, and we would avoid the very likely >>>>> #ifdefs >>>>> hell in case of a single pmap.c. >>>>> >>>>> >>>> Yeah, I think that would be the best solution. We could conditionally >>>> select the right pmap.c file based on the target CPU selected (just >>>> like we do for board variations for at91/marvell). >>>> >>>> >>> >>> pmap.c is a very large file that seems to change very often. I fear >>> having several versions is going to be difficult to maintain. Granted, >>> I haven't read the whole file line after line. Yet it seems to me its >>> content can be abstracted to rely on arch-specific functions that >>> would be found in cpufuncs instead of hardcoded macros. Is there >>> something fundamentally wrong with enhancing struct cpufunc in order >>> to let the portmeisters decide what the MMU and caching bits should >>> look like? This is a blocking issue for me, since it looks like the >>> omap has some problem with backward compatibility mode. Without fixing >>> up the TLBs in my initarm function, it doesn't work. >>> >>> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >>> cpufuncs_.c? That would be a good way to start that >>> reorganization Mark has been talking about in his email. >>> >> One thing that might be worth looking at while thinking about this is >> how this is done on PowerPC. We have run-time selectable PMAP modules >> using KOBJ to handle CPUs with different MMU designs, as well as a >> platform module scheme, again using KOBJ, to pick the appropriate >> PMAP for the board as well as determine the physical memory layout >> and such things. One of the nice things about the approach is that it >> is easy to subclass if you have a new, marginally different, design, >> and it avoids #ifdef hell as well as letting you build a GENERIC >> kernel with support for multiple MMU designs and board types (the >> last less of a concern on ARM, though). > > What always concerned me was the performance cost this imposes, and it > would be a really useful exercise to measure what is the actual impact > of KOBJ-tized pmap we have in PowerPC; with an often-called interface > like pmap it might occur the penalty is not that little.. Using the KOBJ cache means that it is only marginally more expensive than a standard function pointer call. There's a 9-year-old note in the commit log for sys/sys/kobj.h that it takes about 30% longer to call a function that does nothing via KOBJ versus a direct call on a 300 MHz P2 (a 10 ns time difference). Given that and that pmap methods do, in fact, do things besides get called and immediately return, I suspect non-KOBJ related execution time will dwarf any time loss from the indirection. I'll try to repeat the measurement in the next few days, however, since this is important to know. -Nathan From tinderbox at freebsd.org Mon Oct 12 23:44:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 23:44:54 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-10-12 23:30:00 - cleaning the object tree TB --- 2009-10-12 23:30:11 - cvsupping the source tree TB --- 2009-10-12 23:30:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-10-12 23:30:42 - building world TB --- 2009-10-12 23:30:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:30:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:30:42 - TARGET=arm TB --- 2009-10-12 23:30:42 - TARGET_ARCH=arm TB --- 2009-10-12 23:30:42 - TZ=UTC TB --- 2009-10-12 23:30:42 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:30:42 - cd /src TB --- 2009-10-12 23:30:42 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:30:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 23:44:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 23:44:45 - ERROR: failed to build world TB --- 2009-10-12 23:44:45 - 645.96 user 159.28 system 885.73 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From quickembed at gmail.com Tue Oct 13 00:43:04 2009 From: quickembed at gmail.com (quickembed) Date: Tue Oct 13 00:43:23 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> Message-ID: this error shows you have not indicate how to compile libgssapi.a file. CC is for .c file, you need to tell what's for .a (assembly) file. On Tue, Oct 13, 2009 at 7:44 AM, FreeBSD Tinderbox wrote: > TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for arm/arm > TB --- 2009-10-12 23:30:00 - cleaning the object tree > TB --- 2009-10-12 23:30:11 - cvsupping the source tree > TB --- 2009-10-12 23:30:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile > TB --- 2009-10-12 23:30:42 - building world > TB --- 2009-10-12 23:30:42 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-10-12 23:30:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-10-12 23:30:42 - TARGET=arm > TB --- 2009-10-12 23:30:42 - TARGET_ARCH=arm > TB --- 2009-10-12 23:30:42 - TZ=UTC > TB --- 2009-10-12 23:30:42 - __MAKE_CONF=/dev/null > TB --- 2009-10-12 23:30:42 - cd /src > TB --- 2009-10-12 23:30:42 - /usr/bin/make -B buildworld >>>> World build started on Mon Oct 12 23:30:42 UTC 2009 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries > [...] > cc -fpic -DPIC -O -pipe ?-I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 ?-c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So > cc -fpic -DPIC -O -pipe ?-I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 ?-c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' > make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop > *** Error code 2 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-10-12 23:44:45 - WARNING: /usr/bin/make returned exit code ?1 > TB --- 2009-10-12 23:44:45 - ERROR: failed to build world > TB --- 2009-10-12 23:44:45 - 645.96 user 159.28 system 885.73 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From tinderbox at freebsd.org Tue Oct 13 04:09:39 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:09:45 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <200910130409.n9D49c48060977@freebsd-current.sentex.ca> TB --- 2009-10-13 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 03:55:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-10-13 03:55:00 - cleaning the object tree TB --- 2009-10-13 03:55:05 - cvsupping the source tree TB --- 2009-10-13 03:55:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-10-13 03:55:29 - building world TB --- 2009-10-13 03:55:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 03:55:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 03:55:29 - TARGET=arm TB --- 2009-10-13 03:55:29 - TARGET_ARCH=arm TB --- 2009-10-13 03:55:29 - TZ=UTC TB --- 2009-10-13 03:55:29 - __MAKE_CONF=/dev/null TB --- 2009-10-13 03:55:29 - cd /src TB --- 2009-10-13 03:55:29 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 03:55:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:09:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:09:38 - ERROR: failed to build world TB --- 2009-10-13 04:09:38 - 644.73 user 158.41 system 878.05 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From des at des.no Tue Oct 13 18:50:57 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Oct 13 18:51:04 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: (quickembed@gmail.com's message of "Tue, 13 Oct 2009 08:19:06 +0800") References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> Message-ID: <86vdijdu0r.fsf@ds4.des.no> quickembed writes: > this error shows you have not indicate how to compile libgssapi.a file. > CC is for .c file, you need to tell what's for .a (assembly) file. No, the command line is correct. Assembler sources end in .s or .S; .a is a static library. DES -- Dag-Erling Sm?rgrav - des@des.no From quickembed at gmail.com Tue Oct 13 23:28:30 2009 From: quickembed at gmail.com (quickembed) Date: Tue Oct 13 23:28:36 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: <86vdijdu0r.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> Message-ID: Then it should be indicated how to "link". 2009/10/14 Dag-Erling Sm?rgrav : > quickembed writes: >> this error shows you have not indicate how to compile libgssapi.a file. >> CC is for .c file, you need to tell what's for .a (assembly) file. > > No, the command line is correct. ?Assembler sources end in .s or .S; .a > is a static library. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > From des at des.no Tue Oct 13 23:47:53 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Oct 13 23:48:01 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: (quickembed@gmail.com's message of "Wed, 14 Oct 2009 07:28:29 +0800") References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> Message-ID: <86my3uetzr.fsf@ds4.des.no> quickembed writes: > Dag-Erling Sm?rgrav writes: > > quickembed writes: > > > this error shows you have not indicate how to compile libgssapi.a > > > file. CC is for .c file, you need to tell what's for .a > > > (assembly) file. > > No, the command line is correct. Assembler sources end in .s or .S; > > .a is a static library. > Then it should be indicated how to "link". No. The Makefile is fine. One of the source files was missing an #include that contained inline functions or macros, which the compiler then assumed were external functions. DES -- Dag-Erling Sm?rgrav - des@des.no From quickembed at gmail.com Tue Oct 13 23:53:24 2009 From: quickembed at gmail.com (quickembed) Date: Tue Oct 13 23:53:36 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: <86my3uetzr.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> Message-ID: should not it say "unresolved external function...." etc if the compiler can not find the function body? 2009/10/14 Dag-Erling Sm?rgrav : > quickembed writes: >> Dag-Erling Sm?rgrav writes: >> > quickembed writes: >> > > this error shows you have not indicate how to compile libgssapi.a >> > > file. ?CC is for .c file, you need to tell what's for .a >> > > (assembly) file. >> > No, the command line is correct. ?Assembler sources end in .s or .S; >> > .a is a static library. >> Then it should be indicated how to "link". > > No. ?The Makefile is fine. ?One of the source files was missing an > #include that contained inline functions or macros, which the compiler > then assumed were external functions. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > From des at des.no Wed Oct 14 00:06:45 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Oct 14 00:06:56 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: (quickembed@gmail.com's message of "Wed, 14 Oct 2009 07:53:23 +0800") References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> Message-ID: <86aazuet4c.fsf@ds4.des.no> quickembed writes: > should not it say "unresolved external function...." etc if the > compiler can not find the function body? Yes, that's exactly what it does: /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' DES -- Dag-Erling Sm?rgrav - des@des.no From bland at FreeBSD.org Wed Oct 14 07:05:44 2009 From: bland at FreeBSD.org (Alexander Nedotsukov) Date: Wed Oct 14 07:05:56 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: <86aazuet4c.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> <86aazuet4c.fsf@ds4.des.no> Message-ID: Heh. You just repeat my mistake (presumably with a bit of help from my side though). Those warning lines are really provoking :-) While missed #include issue still true it was not a source of build failure. libgssapi_krb5 now have libgssapi as a dependency but stay first in the _prebuild_libs list and nothing said build framework why it must build it in a different order. I committed the fix yesterday: http://svn.freebsd.org/viewvc/base?view=revision&revision=198020 Alexander. ps. I noticed that mails from tinderbox.freebsd.org contains link to not existed tinderbox.des.no host. On Wed, 14 Oct 2009 02:06:43 +0200, Dag-Erling Sm?rgrav wrote: > quickembed writes: >> should not it say "unresolved external function...." etc if the >> compiler can not find the function body? > > Yes, that's exactly what it does: > > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function > 'gsskrb5_extract_authz_data_from_sec_context': > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit > declaration of function 'der_get_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit > declaration of function 'der_free_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit > declaration of function 'der_length_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit > declaration of function 'der_put_oid' > > DES From asientrade at freenet.de Thu Oct 15 13:40:19 2009 From: asientrade at freenet.de (daniel) Date: Thu Oct 15 13:40:36 2009 Subject: Twitter-endlich Geldverdienen-kostenlos und sofort startklar Message-ID: <20091015154032A38C60EA7A$50739F2991@DANIELPC> ?Offers stand below as an English available Hallo- ??????????????????????????????????????? verdiene endlich Geld durch Twitterwenn ein Twitter Account vorhanden sein sollte dann gehts sofort los mit Verdienen.sollte keine Account vorhanden sein dann einfach alles kostenlos erstellen und verdienen.?mit besten Empfehlungen eure Danielleichter kann man sein ?Geld nicht verdienen- alles kostenlos wenn sie einen Twitteraccount haben.Also schnell handel-bei weiterem Interesse und lust an gratis produkten einfach kurz anmelden-oder abmelden-- danke??Anmelden?????? ?Abmelden?24 Std. Blitzangebot?nur begrenzt f?r?24 Stunden aktiv danach ausverkauft--- http://www.affiliateverkaufen.de/blitzangebot.html???? 10,-?(The Logo Creator hilft beim Erstellen qualitativ hochwertiger Logos. Ganz nach dem Motto "Your Logo is your business" gestaltet der Nutzer mit diesem Programm Blickf?nger f?r Webseiten)?(?bersetzen Sie ganz einfach und mit wenigen Klicks Texte oder sogar komplette Webseiten in 31 Sprachen. )nur 28,-??oder Aktionspreis 30,-??? f?r Logocreator v5 und PDF-Converter 6.0 dt.?Oder m?chten sie lieber effektiv heute noch Geld verdienen und Zahlungen wenn m?glich sofort erwirtschaften-?? dann mit diesem angebot was f?r mich selbstbehauptet das beste ?berhaupt war und ist--Geld durch Emails verdienen-aber keine centbetr?ge sondern sofort 10-20,-? sofort-zahlung innerhalb weniger minuten, ich habe zur zeit zwischen 5 und 20 Kunden pro tag (weltweit) bei einem verdienst pro email von ca. 15,-? und ich betreibe keinerlei werbung oder verkaufe durchs telefon nein die Kunden kommen zu mir und ich verdiene sehr gut-aber lesen sie selbst wenn ihr interesse noch vorhanden ist weiter im Angebot 2.erfolgreiches Handeln w?nsche ich auf diesem Wege-bei weiteren Interessen k?nnen sie sichwiederholt eintragen um weitere Angebote und Gratis Geschenke zu erhalten........................(oder Abmelden).... Anmelden???? Abmelden ?Hello- finally earn money by Twitterthen immediately feels wrong with earning if a Twitter account should be available. no-one should account be available simply then everything free of charge make and earn. with best recommendations yours Danielone can more easily money not earning everything be ' free if they have a Twitteraccount. -therefore act fast simply registering or cancelling at broader interest and desire at free products briefly, thank youBookingCancelling24 hour lightning supply?sold off according to that actively for 24 hours only restrictedly - http://www.affiliateverkaufen.de/blitzangebot.html 10. ? (A The logo Creator helps to make high-quality logos. According to the motto "Your logo is your business" the user completely forms with this programme eye-catcher for web pages.) ? (Translate texts or even complete web pages for only simply and a few clicks into 31 languages.) only 28. ? or special-offer price 30. ? for Logocreator v5 and PDF-Converter of 6.0 dt. -or they would rather, today, still earn money effectively and immediately gain payments if possible? with this supply did but no cent amounts what was self claimed for me the best at all and is? I have 10-20,- ? immediately payment within less minutes, between 5 and 20 customers per day (worldwide) at an income per e-mail from approx. 15. ? at the moment by the telephone the customers no come to me and I earn very well and I operate no advertising or sell but read them even if their interest is still further existing in the supply 2. Angebot 2.I wish on this at broader interests be able to do them himself a successful action waystyping repeated ........................ in to receive further offers and free presents. (or cancel ) ..... Booking? Cancelling???? From gballet at gmail.com Sun Oct 18 11:36:28 2009 From: gballet at gmail.com (Guillaume Ballet) Date: Sun Oct 18 11:36:34 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <200910122129.n9CLTHsp087996@casselton.net> References: <200910122129.n9CLTHsp087996@casselton.net> Message-ID: On Mon, Oct 12, 2009 at 11:29 PM, Mark Tinguely wrote: > >> ?As a result, extending the struct cpu_functions is not a good thing >> ?either, for the same reason. The compiler can not inline a call >> ?through a function pointer. >> >> ?In which case, why not create a bunch of headers files with the >> ?pattern cpufunc_myarch.h, in which all functions would be declared >> ?inline? Something like: >> >> ?static inline l2_l_entry(vm_addr_t pa, int prot, int cache); >> ?static inline l2_s_entry(vm_addr_t pa, int prot, int cache); >> ?... >> ?which would then be included by pmap.c and friends. > > I think they need to be regular function calls because assembly routines > call the per-cpu functions. A few simple macros would save the branch to NOP > functions. > I'm not sure what you mean by that: would macros be ok, in your opinion? I am a bit puzzled because I see a contradiction with the previous sentence that requires the functions to be callable from the assembly code. Obviously I am misinterpreting, so would you mind clarifying, please? I think it is important to notice that even though cache management relies a lot on assembly function, I haven't found any page table management done in assembly past locore.S. I think using macros for page table management functions can be done. For cache management, however, I agree that having different pmap.c files is probably the way to go. In both cases, I am still curious to see what Nathan will come up with. I took a more thorough look at pmap, and there is indeed lots of machine-specific code, especially at the beginning. And when it comes to cpufunc, it's all about #ifdefs. Since I'm still working on the cleanup for the beagleboard, I will declare cpufuncs in an armv6-specific file. Let's call it cpufunc_armv6.c. I am struggling with another MMU problem at the moment, but I'll try to come up asap with a patch for pmap.c. It will replace hardcoded values with machine-defined macros, for reference. Guillaume From tinguely at casselton.net Sun Oct 18 14:05:50 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Sun Oct 18 14:05:56 2009 Subject: Adding members to struct cpu_functions In-Reply-To: Message-ID: <200910181405.n9IE5gsi093570@casselton.net> > >> =A0either, for the same reason. The compiler can not inline a call > >> =A0through a function pointer. > >> > >> =A0In which case, why not create a bunch of headers files with the > >> =A0pattern cpufunc_myarch.h, in which all functions would be declared > >> =A0inline? Something like: > >> > >> =A0static inline l2_l_entry(vm_addr_t pa, int prot, int cache); > >> =A0static inline l2_s_entry(vm_addr_t pa, int prot, int cache); > >> =A0... > >> =A0which would then be included by pmap.c and friends. > > > > I think they need to be regular function calls because assembly routines > > call the per-cpu functions. A few simple macros would save the branch to = > NOP > > functions. > > > > I'm not sure what you mean by that: would macros be ok, in your > opinion? I am a bit puzzled because I see a contradiction with the > previous sentence that requires the functions to be callable from the > assembly code. Obviously I am misinterpreting, so would you mind > clarifying, please? > > I think it is important to notice that even though cache management > relies a lot on assembly function, I haven't found any page table > management done in assembly past locore.S. I think using macros for > page table management functions can be done. For cache management, > however, I agree that having different pmap.c files is probably the > way to go. In both cases, I am still curious to see what Nathan will > come up with. You are correct, the page tables routines are pmap.c oriented. I extended clean up thought to all the cpu specific functions. There are cpu specific functions that are NOPs that we branch to and back again. I was just throwing out a global re-organization thought. > I took a more thorough look at pmap, and there is indeed lots of > machine-specific code, especially at the beginning. And when it comes > to cpufunc, it's all about #ifdefs. Since I'm still working on the > cleanup for the beagleboard, I will declare cpufuncs in an > armv6-specific file. Let's call it cpufunc_armv6.c. I am struggling > with another MMU problem at the moment, but I'll try to come up asap > with a patch for pmap.c. It will replace hardcoded values with > machine-defined macros, for reference. I think you are running that processor in v5 mode. There is still some individuals looking at a cache problem with recent code. I still believe, we need to add the PVF_REF flag when adding the new unmanaged (PVF_UNMAN) pv_entry, so pmap_fix_cache() will clean write back the cache and remove the tlb. That and the changes to remove dangling allocations. --Mark. From nwhitehorn at freebsd.org Sun Oct 18 15:49:19 2009 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Sun Oct 18 15:54:58 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <4AD39C78.5050309@freebsd.org> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> <4AD39C78.5050309@freebsd.org> Message-ID: <4ADB38FA.2080604@freebsd.org> Nathan Whitehorn wrote: > Rafal Jaworowski wrote: >> >> On 2009-10-12, at 15:21, Nathan Whitehorn wrote: >> >>>>>> I was wondering whether a separate pmap module for ARMv6-7 would not >>>>>> be the best approach. After all v6-7 should be considered an >>>>>> entirely >>>>>> new architecture variation, and we would avoid the very likely >>>>>> #ifdefs >>>>>> hell in case of a single pmap.c. >>>>>> >>>>>> >>>>> Yeah, I think that would be the best solution. We could >>>>> conditionally >>>>> select the right pmap.c file based on the target CPU selected (just >>>>> like we do for board variations for at91/marvell). >>>>> >>>>> >>>> >>>> pmap.c is a very large file that seems to change very often. I fear >>>> having several versions is going to be difficult to maintain. Granted, >>>> I haven't read the whole file line after line. Yet it seems to me its >>>> content can be abstracted to rely on arch-specific functions that >>>> would be found in cpufuncs instead of hardcoded macros. Is there >>>> something fundamentally wrong with enhancing struct cpufunc in order >>>> to let the portmeisters decide what the MMU and caching bits should >>>> look like? This is a blocking issue for me, since it looks like the >>>> omap has some problem with backward compatibility mode. Without fixing >>>> up the TLBs in my initarm function, it doesn't work. >>>> >>>> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >>>> cpufuncs_.c? That would be a good way to start that >>>> reorganization Mark has been talking about in his email. >>>> >>> One thing that might be worth looking at while thinking about this >>> is how this is done on PowerPC. We have run-time selectable PMAP >>> modules using KOBJ to handle CPUs with different MMU designs, as >>> well as a platform module scheme, again using KOBJ, to pick the >>> appropriate PMAP for the board as well as determine the physical >>> memory layout and such things. One of the nice things about the >>> approach is that it is easy to subclass if you have a new, >>> marginally different, design, and it avoids #ifdef hell as well as >>> letting you build a GENERIC kernel with support for multiple MMU >>> designs and board types (the last less of a concern on ARM, though). >> >> What always concerned me was the performance cost this imposes, and >> it would be a really useful exercise to measure what is the actual >> impact of KOBJ-tized pmap we have in PowerPC; with an often-called >> interface like pmap it might occur the penalty is not that little.. > Using the KOBJ cache means that it is only marginally more expensive > than a standard function pointer call. There's a 9-year-old note in > the commit log for sys/sys/kobj.h that it takes about 30% longer to > call a function that does nothing via KOBJ versus a direct call on a > 300 MHz P2 (a 10 ns time difference). Given that and that pmap methods > do, in fact, do things besides get called and immediately return, I > suspect non-KOBJ related execution time will dwarf any time loss from > the indirection. I'll try to repeat the measurement in the next few > days, however, since this is important to know. > -Nathan I just did the measurements on a 1.8 GHz PowerPC G5. There were four tests, each repeated 1 million times. "Load and store" involves incrementing a volatile int from 0 to 1e6 inline. "Direct calls" involves a branch to a function that returns 0 and does nothing else. "Function ptr" calls the same function via a pointer stored in a register, and "KOBJ calls" calls it via KOBJ. Here are the results (errors are +/- 0.5 ns for the function call measurements due to compiler optimization jitter, and 0 for load and store, since that takes a deterministic number of clock cycles): 32-bit kernel: Load and store: 26.1 ns Direct calls: 7.2 ns Function ptr: 8.4 ns KOBJ calls: 17.8 ns 64-bit kernel: Load and store: 9.2 ns Direct calls: 6.1 ns Function ptr: 8.3 ns KOBJ calls: 40.5 ns ABI changes make a large difference, as you can see. The cost of calling via KOBJ is non-negligible, but small, especially compared to the cost of doing anything involving memory. I don't know how this changes with ARM calling conventions. -Nathan From bugmaster at FreeBSD.org Mon Oct 19 11:06:49 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:07:37 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200910191106.n9JB6mkl063381@freefall.freebsd.org> 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 arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From raj at semihalf.com Mon Oct 19 15:34:03 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Oct 19 15:34:09 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <4ADB38FA.2080604@freebsd.org> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> <4AD39C78.5050309@freebsd.org> <4ADB38FA.2080604@freebsd.org> Message-ID: <05B19969-B238-4E3A-8326-624067F0362B@semihalf.com> On 2009-10-18, at 17:49, Nathan Whitehorn wrote: >>>> One thing that might be worth looking at while thinking about >>>> this is how this is done on PowerPC. We have run-time selectable >>>> PMAP modules using KOBJ to handle CPUs with different MMU >>>> designs, as well as a platform module scheme, again using KOBJ, >>>> to pick the appropriate PMAP for the board as well as determine >>>> the physical memory layout and such things. One of the nice >>>> things about the approach is that it is easy to subclass if you >>>> have a new, marginally different, design, and it avoids #ifdef >>>> hell as well as letting you build a GENERIC kernel with support >>>> for multiple MMU designs and board types (the last less of a >>>> concern on ARM, though). >>> >>> What always concerned me was the performance cost this imposes, >>> and it would be a really useful exercise to measure what is the >>> actual impact of KOBJ-tized pmap we have in PowerPC; with an often- >>> called interface like pmap it might occur the penalty is not that >>> little.. >> Using the KOBJ cache means that it is only marginally more >> expensive than a standard function pointer call. There's a 9-year- >> old note in the commit log for sys/sys/kobj.h that it takes about >> 30% longer to call a function that does nothing via KOBJ versus a >> direct call on a 300 MHz P2 (a 10 ns time difference). Given that >> and that pmap methods do, in fact, do things besides get called and >> immediately return, I suspect non-KOBJ related execution time will >> dwarf any time loss from the indirection. I'll try to repeat the >> measurement in the next few days, however, since this is important >> to know. >> -Nathan > I just did the measurements on a 1.8 GHz PowerPC G5. There were four > tests, each repeated 1 million times. "Load and store" involves > incrementing a volatile int from 0 to 1e6 inline. "Direct calls" > involves a branch to a function that returns 0 and does nothing > else. "Function ptr" calls the same function via a pointer stored in > a register, and "KOBJ calls" calls it via KOBJ. Here are the results > (errors are +/- 0.5 ns for the function call measurements due to > compiler optimization jitter, and 0 for load and store, since that > takes a deterministic number of clock cycles): > > 32-bit kernel: > Load and store: 26.1 ns > Direct calls: 7.2 ns > Function ptr: 8.4 ns > KOBJ calls: 17.8 ns > > 64-bit kernel: > Load and store: 9.2 ns > Direct calls: 6.1 ns > Function ptr: 8.3 ns > KOBJ calls: 40.5 ns > > ABI changes make a large difference, as you can see. The cost of > calling via KOBJ is non-negligible, but small, especially compared > to the cost of doing anything involving memory. I don't know how > this changes with ARM calling conventions. Very interesting, thanks! Could you elaborate on the testing details and share the diagnostic code so we could repeat this with other CPU variations like Book-E PowerPC, or ARM? Rafal From imp at bsdimp.com Mon Oct 19 15:54:13 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Oct 19 15:54:19 2009 Subject: Adding members to struct cpu_functions In-Reply-To: <05B19969-B238-4E3A-8326-624067F0362B@semihalf.com> References: <4AD39C78.5050309@freebsd.org> <4ADB38FA.2080604@freebsd.org> <05B19969-B238-4E3A-8326-624067F0362B@semihalf.com> Message-ID: <20091019.094758.-2092524312.imp@bsdimp.com> In message: <05B19969-B238-4E3A-8326-624067F0362B@semihalf.com> Rafal Jaworowski writes: : On 2009-10-18, at 17:49, Nathan Whitehorn wrote: [[ trimmed ]] : > I just did the measurements on a 1.8 GHz PowerPC G5. There were four : > tests, each repeated 1 million times. "Load and store" involves : > incrementing a volatile int from 0 to 1e6 inline. "Direct calls" : > involves a branch to a function that returns 0 and does nothing : > else. "Function ptr" calls the same function via a pointer stored in : > a register, and "KOBJ calls" calls it via KOBJ. Here are the results : > (errors are +/- 0.5 ns for the function call measurements due to : > compiler optimization jitter, and 0 for load and store, since that : > takes a deterministic number of clock cycles): : > : > 32-bit kernel: : > Load and store: 26.1 ns : > Direct calls: 7.2 ns : > Function ptr: 8.4 ns : > KOBJ calls: 17.8 ns : > : > 64-bit kernel: : > Load and store: 9.2 ns : > Direct calls: 6.1 ns : > Function ptr: 8.3 ns : > KOBJ calls: 40.5 ns : > : > ABI changes make a large difference, as you can see. The cost of : > calling via KOBJ is non-negligible, but small, especially compared : > to the cost of doing anything involving memory. I don't know how : > this changes with ARM calling conventions. : : Very interesting, thanks! Could you elaborate on the testing details : and share the diagnostic code so we could repeat this with other CPU : variations like Book-E PowerPC, or ARM? I'd love to see this on MIPS too... KOBJ is a big win for device configuration, where one memory I/O can take 60 times these call numbers... Warner From ruidc at yahoo.com Mon Oct 19 20:35:45 2009 From: ruidc at yahoo.com (RuiDC) Date: Mon Oct 19 20:35:51 2009 Subject: Sheevaplug: booting from tftp/nfs has root as read-only Message-ID: <25964915.post@talk.nabble.com> Hi, I am using a Sheevaplug and 8.0-RC1 and I've followed the instructions here: http://wiki.freebsd.org/FreeBSDMarvell /etc/exports on my FreeBSD server is set up as follows: /usr/nfsroot/arm-8-le -mapall=0 -alldirs -network 0.0.0.0 -mask 0.0.0.0 If i access the NFS share from an ubuntu client, it's read/write but following the above instructions from the sheevaplug, although it boots fine otherwise, the root is mounted read-only. Any suggestions as to how i can debug and fix this? RuiDC -- View this message in context: http://www.nabble.com/Sheevaplug%3A-booting-from-tftp-nfs-has-root-as-read-only-tp25964915p25964915.html Sent from the freebsd-arm mailing list archive at Nabble.com. From raj at semihalf.com Tue Oct 20 09:15:32 2009 From: raj at semihalf.com (Rafal Jaworowski) Date: Tue Oct 20 09:15:39 2009 Subject: Sheevaplug: booting from tftp/nfs has root as read-only In-Reply-To: <25964915.post@talk.nabble.com> References: <25964915.post@talk.nabble.com> Message-ID: <2A3CAAF1-FD37-4F3B-B670-FD8BC38D8CF4@semihalf.com> On 2009-10-19, at 22:16, RuiDC wrote: > I am using a Sheevaplug and 8.0-RC1 and I've followed the > instructions here: > http://wiki.freebsd.org/FreeBSDMarvell > > /etc/exports on my FreeBSD server is set up as follows: > /usr/nfsroot/arm-8-le -mapall=0 -alldirs -network 0.0.0.0 -mask > 0.0.0.0 > > If i access the NFS share from an ubuntu client, it's read/write but > following the above instructions from the sheevaplug, although it > boots fine > otherwise, the root is mounted read-only. > > Any suggestions as to how i can debug and fix this? Are you running in multiuser? Does your /etc/fstab allow for RW? Rafal From ruidc at yahoo.com Tue Oct 20 12:51:34 2009 From: ruidc at yahoo.com (RuiDC) Date: Tue Oct 20 12:51:40 2009 Subject: Sheevaplug: booting from tftp/nfs has root as read-only In-Reply-To: <2A3CAAF1-FD37-4F3B-B670-FD8BC38D8CF4@semihalf.com> References: <25964915.post@talk.nabble.com> <2A3CAAF1-FD37-4F3B-B670-FD8BC38D8CF4@semihalf.com> Message-ID: <25974519.post@talk.nabble.com> Solved, thanks to Rafal: Rafal Jaworowski wrote: > > > Are you running in multiuser? > > Does your /etc/fstab allow for RW? > > /etc/fstab was fine: 192.168.2.233:/usr/nfsroot/arm-8-le / nfs rw 0 0 but i was running single-user. After using ^D after reading init(8) it came up read-write. Thanks, R -- View this message in context: http://www.nabble.com/Sheevaplug%3A-booting-from-tftp-nfs-has-root-as-read-only-tp25964915p25974519.html Sent from the freebsd-arm mailing list archive at Nabble.com. From ruidc at yahoo.com Tue Oct 20 15:12:55 2009 From: ruidc at yahoo.com (RuiDC) Date: Tue Oct 20 15:13:07 2009 Subject: Sheevaplug: preparing to boot from USB stick Message-ID: <25976957.post@talk.nabble.com> I have followed http://wiki.freebsd.org/FreeBSDMarvell and am booting fine via tftp/NFS but now wish to switch to using USB stick so that the plug operates without a server. In the absence of a guide as to how to proceed, i was following from step 7 onwards from: http://bsdimp.blogspot.com/2007/12/building-bootable-arm-sd.html step7: # fdisk -I da0 ******* Working on device da0 ******* fdisk: /boot/mbr: No such file or directory Should i be using on of these instead: # ls -l boot ... -r--r--r-- 1 root wheel 13320 Sep 28 09:57 loader.help -r-xr-xr-x 1 root wheel 165864 Sep 28 09:57 ubldr And if so, what preparation do i need for the USB stick? ie. swapping is disabled on the kernel config, can i just use a single large UFS partition/slice ? as below or do i need a FAT32 partition to make it accessible from u-boot? # fdisk da0 ******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=972 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=972 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 62, size 15620218 (7627 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 63; end: cyl 972/ head 80/ sector 60 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Thanks, RuiDC -- View this message in context: http://www.nabble.com/Sheevaplug%3A-preparing-to-boot-from-USB-stick-tp25976957p25976957.html Sent from the freebsd-arm mailing list archive at Nabble.com. From jack.avenger at gmail.com Tue Oct 20 15:28:01 2009 From: jack.avenger at gmail.com (Jack Avenger) Date: Tue Oct 20 15:28:09 2009 Subject: Can't boot Marvel Sheevaplug from USB In-Reply-To: <33436772.1965231256048531425.JavaMail.nabble@isper.nabble.com> References: <33436772.1965231256048531425.JavaMail.nabble@isper.nabble.com> Message-ID: <62E4AC76-198B-4C74-8318-E3399B4B35C7@gmail.com> No. It doesn't work. See link: http://www.freebsd.org/cgi/query-pr.cgi?pr=138798 On 20 ????. 2009, at 17:22, ruidc@yahoo.com wrote: > Hi, did you eventually get this to work? > If so, how? > > RuiDC > > Jack Avenger wrote: >> >> Which options should be included in kernel configuration to boot 8- >> CURRENT on SHEEVAPLUG? >> >> I tried options ROOTDEVNAME="ufs:/dev/da0s1a", but no success: >> >> usbus0: 480Mbps High Speed USB v2.0 >> Root mount waiting for: usbus0 >> ugen0.1: at usbus0 >> uhub0: on >> usbus0 >> uhub0: 1 port with 1 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.2: at usbus0 >> umass0: on >> usbus0 >> umass0: SCSI over Bulk-Only; quirks = 0x0000 >> Root mount waiting for: usbus0 >> umass0:0:0:-1: Attached to scbus0 >> Trying to mount root from ufs:/dev/da0a >> ROOT MOUNT ERROR: >> If you have invalid mount options, reboot, and first try the >> following >> from >> the loader prompt: >> >> set vfs.root.mountfrom.options=rw >> >> and then remove invalid mount options from /etc/fstab. >> >> Loader variables: >> vfs.root.mountfrom= >> vfs.root.mountfrom.options= >> >> Manual root filesystem specification: >> : Mount using filesystem >> eg. ufs:/dev/da0s1a >> eg. cd9660:/dev/acd0 >> This is equivalent to: mount -t cd9660 /dev/ >> acd0 / >> >> ? List valid disk boot devices >> Abort manual input >> >> mountroot> >> >> it seems like there is an error accessing USB Flash, but it work when >> boot from NFS is compiled into kernel. >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm- >> unsubscribe@freebsd.org" >> >> > Quoted from: > http://www.nabble.com/Can%27t-boot-Marvel-Sheevaplug-from-USB-tp25368842p25368842.html > Yurij Burak jack.avenger@gmail.com From ray at dlink.ua Fri Oct 23 13:31:02 2009 From: ray at dlink.ua (Alexandr Rybalko) Date: Fri Oct 23 13:31:09 2009 Subject: [ARM+NFS] panic while copying across NFS In-Reply-To: <200910071636.n97GaF11095976@casselton.net> References: <20091007114612.00408f53.ray@dlink.ua> <200910071636.n97GaF11095976@casselton.net> Message-ID: <20091023155825.381728f4.ray@dlink.ua> Hi Mark! With your patch works fine. # dd if=/swap.file of=/mnt/swap.file bs=1M 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 231.294150 secs (4642322 bytes/sec) But still slow. Maybe someone know why slow? (Marvell 88F5182 rev A2) On Wed, 7 Oct 2009 11:36:15 -0500 (CDT) Mark Tinguely wrote: >> >> (CC -arm and -current removed) >> >> Have you tried to remove the dangling allocations? I can't say that this >> will change anything, I would just feel better to eliminate them. >> >> ---- >> >> Revisions 181296 and 195779 added the cache fixes. >> >> Below are a couple more. We should remove the dangling allocations so >> they do not un-necessarily turn off the cache in the future. >> >> ---- >> >> Index: arm/arm/vm_machdep.c >> =================================================================== >> --- arm/arm/vm_machdep.c (revision 196359) >> +++ arm/arm/vm_machdep.c (working copy) >> @@ -172,6 +172,9 @@ sf_buf_free(struct sf_buf *sf) >> if (sf->ref_count == 0) { >> TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); >> nsfbufsused--; >> + pmap_kremove(sf->kva); >> + sf->m = NULL; >> + LIST_REMOVE(sf, list_entry); >> if (sf_buf_alloc_want > 0) >> wakeup_one(&sf_buf_freelist); >> } >> @@ -452,9 +455,12 @@ arm_unmap_nocache(void *addr, vm_size_t size) >> >> size = round_page(size); >> i = (raddr - arm_nocache_startaddr) / (PAGE_SIZE); >> - for (; size > 0; size -= PAGE_SIZE, i++) >> + for (; size > 0; size -= PAGE_SIZE, i++) { >> arm_nocache_allocated[i / BITS_PER_INT] &= ~(1 << (i % >> BITS_PER_INT)); >> + pmap_kremove(raddr); >> + raddr += PAGE_SIZE; >> + } >> } >> >> #ifdef ARM_USE_SMALL_ALLOC -- Alexandr Rybalko From tinguely at casselton.net Fri Oct 23 15:22:54 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Fri Oct 23 15:23:00 2009 Subject: [ARM+NFS] panic while copying across NFS In-Reply-To: <20091023155825.381728f4.ray@dlink.ua> Message-ID: <200910231522.n9NFMlE3002301@casselton.net> > Hi Mark! > With your patch works fine. > > # dd if=/swap.file of=/mnt/swap.file bs=1M > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 231.294150 secs (4642322 bytes/sec) > > But still slow. Maybe someone know why slow? (Marvell 88F5182 rev A2) Here is what I think is the complete update to the revisions 181296 and 195779 cache fixes. 1) vm_machdep.c: remove the dangling allocations so they do not un-necessarily turn off the cache in the future. (this is the patch that worked for you. 2-3 are two more) 2) busdma_machdep.c: remove the same amount than shadow mapped. 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF is set by a trap when the page is really use. kernel pages should assume it is immediately used. In ARMv5 pmap, we should manage every RAM physical page. Without a profiling the kernel, it would be tough to say were performance issues are orginating. (device driver, in the fs code, or machine level). Ideas about the machine level code: I think freeing the memory from the level page table descriptors for general use should improve things. More usuable RAM is always a good thing. There is some code in trap and other places that looks to see if the level 1 pde is for this memory space or shared memory space. we can keep a few level pde around for forks. downside a fork could fail the 16K contig buffer; which it can in other archs too. This is a pretty big change. There are tests/fixes (switch/pmap) for low vector page that can be removed with define statement for high vector kernels. In fact if we are not sharing the level 1 pd, this set only in pmap initialization. Simple change "#ifdef LOW_VECTOR", minor savings. Are we cleaning caches too much? ARMv6/7 will be a big game changer. Should put a ton of effort into ARMv5, put the effort into optimizing, or do both? Index: arm/arm/vm_machdep.c =================================================================== --- arm/arm/vm_machdep.c (revision 198246) +++ arm/arm/vm_machdep.c (working copy) @@ -169,6 +169,9 @@ sf_buf_free(struct sf_buf *sf) if (sf->ref_count == 0) { TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); nsfbufsused--; + pmap_kremove(sf->kva); + sf->m = NULL; + LIST_REMOVE(sf, list_entry); if (sf_buf_alloc_want > 0) wakeup_one(&sf_buf_freelist); } @@ -449,9 +452,12 @@ arm_unmap_nocache(void *addr, vm_size_t size) size = round_page(size); i = (raddr - arm_nocache_startaddr) / (PAGE_SIZE); - for (; size > 0; size -= PAGE_SIZE, i++) + for (; size > 0; size -= PAGE_SIZE, i++) { arm_nocache_allocated[i / BITS_PER_INT] &= ~(1 << (i % BITS_PER_INT)); + pmap_kremove(raddr); + raddr += PAGE_SIZE; + } } #ifdef ARM_USE_SMALL_ALLOC Index: arm/arm/busdma_machdep.c =================================================================== --- arm/arm/busdma_machdep.c (revision 198246) +++ arm/arm/busdma_machdep.c (working copy) @@ -649,7 +649,8 @@ bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, b KASSERT(map->allocbuffer == vaddr, ("Trying to freeing the wrong DMA buffer")); vaddr = map->origbuffer; - arm_unmap_nocache(map->allocbuffer, dmat->maxsize); + arm_unmap_nocache(map->allocbuffer, + dmat->maxsize + ((vm_offset_t)vaddr & PAGE_MASK)); } if (dmat->maxsize <= PAGE_SIZE && dmat->alignment < dmat->maxsize && Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 198246) +++ arm/arm/pmap.c (working copy) @@ -1643,7 +1643,7 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry /* PMAP_ASSERT_LOCKED(pmap_kernel()); */ pve->pv_pmap = pmap_kernel(); pve->pv_va = pg->md.pv_kva; - pve->pv_flags = PVF_WRITE | PVF_UNMAN; + pve->pv_flags = PVF_WRITE | PVF_UNMAN | PVF_REF; pg->md.pv_kva = 0; TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); @@ -2870,7 +2870,7 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p vm_page_lock_queues(); PMAP_LOCK(pmap_kernel()); pmap_enter_pv(m, pve, pmap_kernel(), va, - PVF_WRITE | PVF_UNMAN); + PVF_WRITE | PVF_UNMAN | PVF_REF); pmap_fix_cache(m, pmap_kernel(), va); PMAP_UNLOCK(pmap_kernel()); } else { @@ -3538,7 +3538,7 @@ do_l2b_alloc: if (!TAILQ_EMPTY(&m->md.pv_list) || m->md.pv_kva) { KASSERT(pve != NULL, ("No pv")); - nflags |= PVF_UNMAN; + nflags |= PVF_UNMAN | PVF_REF; pmap_enter_pv(m, pve, pmap, va, nflags); } else m->md.pv_kva = va; From xcllnt at mac.com Fri Oct 23 16:03:55 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Oct 23 16:04:14 2009 Subject: [ARM+NFS] panic while copying across NFS In-Reply-To: <200910231522.n9NFMlE3002301@casselton.net> References: <200910231522.n9NFMlE3002301@casselton.net> Message-ID: On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: > 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF > is set by a trap when the page is really use. kernel pages should > assume it is immediately used. This causes problems for me, so I don't think this is quite right. FYI, -- Marcel Moolenaar xcllnt@mac.com From tinguely at casselton.net Fri Oct 23 16:41:25 2009 From: tinguely at casselton.net (Mark Tinguely) Date: Fri Oct 23 16:41:31 2009 Subject: [ARM+NFS] panic while copying across NFS In-Reply-To: Message-ID: <200910231641.n9NGfN1a006721@casselton.net> > > On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: > > > 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF > > is set by a trap when the page is really use. kernel pages should > > assume it is immediately used. > > This causes problems for me, so I don't think this is quite right. > FYI, > > -- > Marcel Moolenaar > xcllnt@mac.com Thank-you for the information. Hmmm, how odd. I will give that some thought. To everyone else, I read my last post and a big sorry for incomplete sentences. It was just a quick list of things that could be changed to streamline the machine dependant portion of the code. --Mark Tinguely. From xcllnt at mac.com Fri Oct 23 16:48:42 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Oct 23 16:48:48 2009 Subject: [ARM+NFS] panic while copying across NFS In-Reply-To: <200910231641.n9NGfN1a006721@casselton.net> References: <200910231641.n9NGfN1a006721@casselton.net> Message-ID: <0C359698-59A4-4213-BC22-9F1483611EB5@mac.com> On Oct 23, 2009, at 9:41 AM, Mark Tinguely wrote: > >> >> On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: >> >>> 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. >>> PVF_REF >>> is set by a trap when the page is really use. kernel pages should >>> assume it is immediately used. >> >> This causes problems for me, so I don't think this is quite right. >> FYI, >> >> -- >> Marcel Moolenaar >> xcllnt@mac.com > > Thank-you for the information. Hmmm, how odd. I will give that some > thought. > > To everyone else, I read my last post and a big sorry for incomplete > sentences. > It was just a quick list of things that could be changed to > streamline the > machine dependant portion of the code. Also to everyone: There's a huge amount of instability in the ARM VM/PMAP code. Things are slightly better when the L2 cache is configured for write-through, but there's at least 2 issues left: 1. Clustered I/O causes incoherency and pretty much makes the box useless when you want to run what you just built. 2. PMAP panics in one or two places, typically after a few minutes/hours of uptime when doing builds. With a L2 cache the problems are a bit more severe as it adds I-cache incoherency to the mix, which even prevents running init(8). I think w e need to rethink the PMAP layer, because if we keep trying to patch it, performance will probably worse from what it is now. Plus, we'll have to deal with physically indexed and physically tagged caches ASAP, so better modularization helps. FYI, -- Marcel Moolenaar xcllnt@mac.com From kzjdrsde at tknmqhia.com Sun Oct 25 08:00:14 2009 From: kzjdrsde at tknmqhia.com (rwpwzita) Date: Sun Oct 25 08:00:47 2009 Subject: arm/139949: rwpwzita Message-ID: <200910250751.n9P7pmbE066148@www.freebsd.org> >Number: 139949 >Category: arm >Synopsis: rwpwzita >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: maintainer-update >Submitter-Id: current-users >Arrival-Date: Sun Oct 25 08:00:13 UTC 2009 >Closed-Date: >Last-Modified: >Originator: rwpwzita >Release: rwpwzita >Organization: rwpwzita >Environment: rwpwzita >Description: deonxybk [URL=http://mmvnvfhw.com]jlvvyamy[/URL] uekmngep http://gpphxjei.com dvnfcwps xtslfzbc >How-To-Repeat: rwpwzita >Fix: rwpwzita >Release-Note: >Audit-Trail: >Unformatted: From vyubbzwu at ybnxylhy.com Sun Oct 25 08:00:19 2009 From: vyubbzwu at ybnxylhy.com (alyfmagb) Date: Sun Oct 25 08:01:33 2009 Subject: arm/139958: alyfmagb Message-ID: <200910250755.n9P7tI3X069222@www.freebsd.org> >Number: 139958 >Category: arm >Synopsis: alyfmagb >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Oct 25 08:00:18 UTC 2009 >Closed-Date: >Last-Modified: >Originator: alyfmagb >Release: alyfmagb >Organization: alyfmagb >Environment: alyfmagb >Description: jgxsukft http://gbsreogl.com pqslasiu wdnhourq >How-To-Repeat: alyfmagb >Fix: alyfmagb >Release-Note: >Audit-Trail: >Unformatted: From linimon at FreeBSD.org Sun Oct 25 08:38:11 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Oct 25 08:38:17 2009 Subject: junk/139949: rwpwzita Message-ID: <200910250838.n9P8cBeR038595@freefall.freebsd.org> Synopsis: rwpwzita State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Oct 25 08:36:59 UTC 2009 State-Changed-Why: garbage http://www.freebsd.org/cgi/query-pr.cgi?pr=139949 From linimon at FreeBSD.org Sun Oct 25 08:40:34 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Oct 25 08:40:39 2009 Subject: junk/139958: alyfmagb Message-ID: <200910250840.n9P8eXYD042992@freefall.freebsd.org> Synopsis: alyfmagb State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Oct 25 08:40:06 UTC 2009 State-Changed-Why: garbage http://www.freebsd.org/cgi/query-pr.cgi?pr=139958 From bugmaster at FreeBSD.org Mon Oct 26 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:07:34 2009 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org Message-ID: <200910261106.n9QB6sTM043698@freefall.freebsd.org> 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 arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From ruidc at yahoo.com Wed Oct 28 16:54:59 2009 From: ruidc at yahoo.com (RuiDC) Date: Wed Oct 28 16:56:25 2009 Subject: Can't boot Marvel Sheevaplug from USB In-Reply-To: <62E4AC76-198B-4C74-8318-E3399B4B35C7@gmail.com> References: <62E4AC76-198B-4C74-8318-E3399B4B35C7@gmail.com> Message-ID: <26098220.post@talk.nabble.com> Jack Avenger wrote: > > See link: http://www.freebsd.org/cgi/query-pr.cgi?pr=138798 > I get the same problem as you, although the problem report you link to seems to show the device being detected after attempted root mount, which is different to your log and mine. I'm running 8-RC1 usbus0: 480Mbps High Speed USB v2.0 Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus0 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/da0s2a ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. Loader variables: vfs.root.mountfrom= vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/acd0 / ? List valid disk boot devices Abort manual input mountroot> -- View this message in context: http://www.nabble.com/Re%3A-Can%27t-boot-Marvel-Sheevaplug-from-USB-tp25977274p26098220.html Sent from the freebsd-arm mailing list archive at Nabble.com. From ruidc at yahoo.com Wed Oct 28 19:46:53 2009 From: ruidc at yahoo.com (RuiDC) Date: Wed Oct 28 19:46:59 2009 Subject: Can't boot Marvel Sheevaplug from USB In-Reply-To: <26098220.post@talk.nabble.com> References: <62E4AC76-198B-4C74-8318-E3399B4B35C7@gmail.com> <26098220.post@talk.nabble.com> Message-ID: <26101005.post@talk.nabble.com> It looks like the thread with patches looking at this issue is here: http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012361.html http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012361.html I'm trying to establish whether a fix has been included in 8-RC2 which was released today. -- View this message in context: http://www.nabble.com/Re%3A-Can%27t-boot-Marvel-Sheevaplug-from-USB-tp25977274p26101005.html Sent from the freebsd-arm mailing list archive at Nabble.com.