From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 15:01:48 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5327C106566C; Sun, 20 Apr 2008 15:01:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2E78FC13; Sun, 20 Apr 2008 15:01:47 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.133.152] (account mc467741@c2i.net [62.113.133.152] verified) by mailfe03.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 910387411; Sun, 20 Apr 2008 16:01:28 +0200 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Date: Sun, 20 Apr 2008 16:02:39 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804201602.40517.hselasky@c2i.net> Cc: John Baldwin Subject: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2008 15:01:48 -0000 Hi John, I'm sorry to say that a recent patch done by you has broken at least the AT91RM9200 target in 8-current. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/arm/arm/intr.c.diff?r1=1.19;r2=1.20 I spent spent several hours today scratching my head why the platform didn't boot. I added a couple of prints into the code: void arm_handler_execute(struct trapframe *frame, int irqnb) { struct intr_event *event; struct thread *td = curthread; int i; PCPU_INC(cnt.v_intr); td->td_intr_nesting_level++; while ((i = arm_get_next_irq()) != -1) { intrcnt[intrcnt_tab[i]]++; event = intr_events[i]; XXX printf("i%u", i); if (intr_event_handle(event, frame) != 0) { /* XXX: Log stray IRQs */ arm_mask_irq(i); } } td->td_intr_nesting_level--; } void arm_mask_irq(uintptr_t nb) { XXX printf("m%u\n", (uint8_t *)nb - (uint8_t *)0); bus_space_write_4(at91_softc->sc_st, at91_softc->sc_sys_sh, IC_IDCR, 1 << nb); } void arm_unmask_irq(uintptr_t nb) { XXX printf("u%u\n", (uint8_t *)nb - (uint8_t *)0); bus_space_write_4(at91_softc->sc_st, at91_softc->sc_sys_sh, IC_IECR, 1 << nb); bus_space_write_4(at91_softc->sc_st, at91_softc->sc_sys_sh, IC_EOICR, 0); } All I get during bootup is "i1". Then the platform hangs. By modifying the "arm_handler_execute" things work again: void arm_handler_execute(struct trapframe *frame, int irqnb) { struct intr_event *event; struct thread *td = curthread; int i; PCPU_INC(cnt.v_intr); td->td_intr_nesting_level++; while ((i = arm_get_next_irq()) != -1) { intrcnt[intrcnt_tab[i]]++; event = intr_events[i]; XXX arm_mask_irq(i); if (intr_event_handle(event, frame) != 0) { /* XXX: Log stray IRQs */ } XXX arm_unmask_irq(i); } td->td_intr_nesting_level--; } I understand that the mask and unmask functions should be called by the factored out code, but they are not called in the same manner like before. How can we fix this ? --HPS From owner-freebsd-arm@FreeBSD.ORG Sun Apr 20 23:31:06 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6831F1065672; Sun, 20 Apr 2008 23:31:06 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (dong.ci0.org [IPv6:2001:7a8:2066:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A84A58FC20; Sun, 20 Apr 2008 23:31:05 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.14.1/8.13.8) with ESMTP id m3L14981058613; Mon, 21 Apr 2008 03:04:09 +0200 (CEST) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.14.1/8.13.8/Submit) id m3L147qV058612; Mon, 21 Apr 2008 03:04:08 +0200 (CEST) (envelope-from mlfbsd) Date: Mon, 21 Apr 2008 03:04:06 +0200 From: Olivier Houchard To: Hans Petter Selasky Message-ID: <20080421010405.GA58580@ci0.org> References: <200804201602.40517.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200804201602.40517.hselasky@c2i.net> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org, John Baldwin Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2008 23:31:06 -0000 On Sun, Apr 20, 2008 at 04:02:39PM +0200, Hans Petter Selasky wrote: > Hi John, > > I'm sorry to say that a recent patch done by you has broken at least the > AT91RM9200 target in 8-current. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/arm/arm/intr.c.diff?r1=1.19;r2=1.20 > > I spent spent several hours today scratching my head why the platform didn't > boot. I added a couple of prints into the code: > Hi, I believe I just fixed that problem, it was indeed AT91RM92-specific (sort of). Thanks a lot for reporting and investigating ! Olivier From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 15:54:29 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E66761065675; Mon, 21 Apr 2008 15:54:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 561C18FC21; Mon, 21 Apr 2008 15:54:28 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.133.152] (account mc467741@c2i.net [62.113.133.152] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 904344343; Mon, 21 Apr 2008 17:54:27 +0200 From: Hans Petter Selasky To: Olivier Houchard Date: Mon, 21 Apr 2008 17:55:42 +0200 User-Agent: KMail/1.9.7 References: <200804201602.40517.hselasky@c2i.net> <20080421010405.GA58580@ci0.org> In-Reply-To: <20080421010405.GA58580@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804211755.44697.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, John Baldwin Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2008 15:54:30 -0000 Hi Olivier, Thanks for the prompt fix. I just compiled a new kernel, booted my AT91RM9200 and I can confirm that your patch works! --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 20:21:41 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE6841065672; Mon, 21 Apr 2008 20:21:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 27DB28FC29; Mon, 21 Apr 2008 20:21:40 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.133.152] (account mc467741@c2i.net [62.113.133.152] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 885560315; Mon, 21 Apr 2008 22:21:39 +0200 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Date: Mon, 21 Apr 2008 22:22:55 +0200 User-Agent: KMail/1.9.7 References: <200804201602.40517.hselasky@c2i.net> <20080421010405.GA58580@ci0.org> <200804211755.44697.hselasky@c2i.net> In-Reply-To: <200804211755.44697.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804212222.57503.hselasky@c2i.net> Cc: John Baldwin Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit (more) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2008 20:21:41 -0000 Hi Olivier, I've found a new issue :-( The OHCI driver does not work in 8-current when using the USB P4 project. I get garbage data when I do USB transfers. I suspect that there is something wrong with the cache flush and invalidate stuff in relation to bus_dma. I have carefully reviewed the OHCI driver and it uses the "bus_dmamap_sync" function properly. Using my USB patchset to build the same USB code on 7-current does not yield these problems. I see that there has been a lot of changes to "sys/arm/arm/pmap.c" for example. Do you have a clue about what is causing this ? --HPS Output from 7-current: usb0: 12Mbps Full Speed USB v1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uplcom0: on usb0 usbd_alloc_device: set address 3 failed (ignored) usbd_alloc_device: getting device descriptor at addr 3 failed! uhub0:uhub_reattach_port: could not allocate new device! mmc0: setting transfer rate to 30.000MHz Output from 8-current: uplcom0: on usb1 uplcom0: failed to set configuration, error=USBD_ERR_SHORT_XFER device_attach: uplcom0 attach returned 6 From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 17:08:23 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 308C1106564A; Tue, 22 Apr 2008 17:08:23 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id ACD0E8FC14; Tue, 22 Apr 2008 17:08:22 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id m3MGom7u081639; Tue, 22 Apr 2008 11:50:48 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1208883048; bh=TbTEOUPe8qNCDjJ9zfQ358naPe4=; h=Date: From:Message-Id:To:Subject:Cc:In-Reply-To; b=SeAK5SRyDnQ5nICXJwMuF 1qamroVTX9qZwdnbnypeRPaZ3yvOQUIhjmYOYLqR4Op0XCB/s1KdpExwyze+o1gBS25 1c1gP9IDJ9DVOygaXL/ktKi5otEoqkphSzPmi9fehaL2C7jbd2w39F4uS1b7r1uJ5Lp rlfeM7bfy0KKBz/c= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id m3MGol5o081637; Tue, 22 Apr 2008 11:50:47 -0500 (CDT) (envelope-from tinguely) Date: Tue, 22 Apr 2008 11:50:47 -0500 (CDT) From: Mark Tinguely Message-Id: <200804221650.m3MGol5o081637@casselton.net> To: freebsd-arm@freebsd.org, hselasky@c2i.net In-Reply-To: <200804212222.57503.hselasky@c2i.net> Cc: jhb@freebsd.org Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit (more) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 17:08:23 -0000 > I've found a new issue :-( > > The OHCI driver does not work in 8-current when using the USB P4 project. I > get garbage data when I do USB transfers. I suspect that there is something > wrong with the cache flush and invalidate stuff in relation to bus_dma. I > have carefully reviewed the OHCI driver and it uses the "bus_dmamap_sync" > function properly. > > Using my USB patchset to build the same USB code on 7-current does not yield > these problems. > > I see that there has been a lot of changes to "sys/arm/arm/pmap.c" for > example. I quickly looked at the new_usb_1_7_3 code and noticed that it should be allocation memory with BUS_DMA_COHERENT flag set. What this means is after the memory is allocated, a new, non-cachable VM address is allocated and used in the place of the original address. I *think* this new address lives in DMA S/G lists and should not be mapped into an address space except to temporarily to copy data in/out. I will assume this assumption is incorrect and look through the pmap code all over again. > Do you have a clue about what is causing this ? > > --HPS > > Output from 7-current: > > usb0: 12Mbps Full Speed USB v1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uplcom0: 1.10/4.00, addr 2> on usb0 > usbd_alloc_device: set address 3 failed (ignored) > usbd_alloc_device: getting device descriptor at addr 3 failed! > uhub0:uhub_reattach_port: could not allocate new device! > mmc0: setting transfer rate to 30.000MHz > > Output from 8-current: > > uplcom0: on usb1 > uplcom0: failed to set configuration, error=USBD_ERR_SHORT_XFER > device_attach: uplcom0 attach returned 6 There are two clues of short transfers - could that be a clue? 1) attach's descriptor string is only 17 character rather than expected 48 - and the 17 characters are not Unicode. 2) set configuration has a USBD_ERR_SHORT_XFER error. I don't know if turning on USB debug printing will give more clues. I will look through the pmap code and see if I can chase up something. --Mark. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 17:59:42 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AE76106564A; Tue, 22 Apr 2008 17:59:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id A89388FC13; Tue, 22 Apr 2008 17:59:41 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.133.152] (account mc467741@c2i.net [62.113.133.152] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 907780916; Tue, 22 Apr 2008 19:59:40 +0200 From: Hans Petter Selasky To: Mark Tinguely Date: Tue, 22 Apr 2008 20:00:51 +0200 User-Agent: KMail/1.9.7 References: <200804221650.m3MGol5o081637@casselton.net> In-Reply-To: <200804221650.m3MGol5o081637@casselton.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804222000.55016.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, jhb@freebsd.org Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit (more) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 17:59:42 -0000 Hi Mark, On Tuesday 22 April 2008, Mark Tinguely wrote: > > I've found a new issue :-( > > > > The OHCI driver does not work in 8-current when using the USB P4 > > project. I get garbage data when I do USB transfers. I suspect that there > > is something wrong with the cache flush and invalidate stuff in relation > > to bus_dma. I have carefully reviewed the OHCI driver and it uses the > > "bus_dmamap_sync" function properly. > > > > Using my USB patchset to build the same USB code on 7-current does not > > yield these problems. > > > > I see that there has been a lot of changes to "sys/arm/arm/pmap.c" for > > example. > > I quickly looked at the new_usb_1_7_3 code and noticed that it should be > allocation memory with BUS_DMA_COHERENT flag set. What this means is > after the memory is allocated, a new, non-cachable VM address is allocated > and used in the place of the original address. That is the NetBSD specific part of the code. In the FreeBSD specific part of the code I have: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb/usb%5fsubr.c&REV=104 Line 2730: /* allocate memory */ if (bus_dmamem_alloc( utag->tag, &ptr, (BUS_DMA_WAITOK | BUS_DMA_COHERENT), &map)) { goto error; } > > I *think* this new address lives in DMA S/G lists and should not be mapped > into an address space except to temporarily to copy data in/out. I will > assume this assumption is incorrect and look through the pmap code all over > again. Is there a function I can call that will tell if the memory I get is in cache enabled memory or not ? If there are any prints you want me to add in the kernel code I can easily do that within short time. > > > Do you have a clue about what is causing this ? > > > > --HPS > > > > Output from 7-current: > > > > usb0: 12Mbps Full Speed USB v1.0 > > uhub0: on usb0 > > uhub0: 2 ports with 2 removable, self powered > > uplcom0: > rev 1.10/4.00, addr 2> on usb0 > > usbd_alloc_device: set address 3 failed (ignored) > > usbd_alloc_device: getting device descriptor at addr 3 failed! > > uhub0:uhub_reattach_port: could not allocate new device! > > mmc0: setting transfer rate to 30.000MHz > > > > Output from 8-current: > > > > uplcom0: on usb1 > > uplcom0: failed to set configuration, error=USBD_ERR_SHORT_XFER > > device_attach: uplcom0 attach returned 6 > > There are two clues of short transfers - could that be a clue? > 1) attach's descriptor string is only 17 character rather than > expected 48 - and the 17 characters are not Unicode. I think what has happend is that when the USB code is reading back the OHCI transfer descriptors after that the transfer has completed we are still looking at the old length field which then tells the USB stack that the transfer is short. It is not "SET_CONFIG" that fails, but probably reading the USB descriptors. > 2) set configuration has a USBD_ERR_SHORT_XFER error. > > I don't know if turning on USB debug printing will give more clues. If I turn on full debugging the problem disappears, which I think is because the CPU cache is used up due to the excessive prints which the following debug level settings cause: sysctl hw.usb.ohci.debug=16 sysctl hw.usb.debug=15 > > I will look through the pmap code and see if I can chase up something. I see one problem: "malloc" is used by BUS-DMA to allocate DMA memory having a size less than PAGE_SIZE. What happens when you have multiple DMA allocations in the same PAGE and you then turn on/off the CPU caching on a per allocation/free basis ? Mark, I really appreciate that you look into this. --HPS PS: If you need to talk I have AIM/ICQ/MSN/Jabber/IRC and SIP. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 18:15:53 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C32301065674 for ; Tue, 22 Apr 2008 18:15:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB2A8FC2C for ; Tue, 22 Apr 2008 18:15:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id 386411A4D89; Tue, 22 Apr 2008 10:58:15 -0700 (PDT) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m3MHvtVJ017349; Tue, 22 Apr 2008 13:58:04 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Olivier Houchard Date: Tue, 22 Apr 2008 13:35:23 -0400 User-Agent: KMail/1.9.7 References: <200804201602.40517.hselasky@c2i.net> <20080421010405.GA58580@ci0.org> In-Reply-To: <20080421010405.GA58580@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804221335.23809.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 22 Apr 2008 13:58:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6880/Tue Apr 22 10:13:41 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arm@freebsd.org Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 18:15:53 -0000 On Sunday 20 April 2008 09:04:06 pm Olivier Houchard wrote: > On Sun, Apr 20, 2008 at 04:02:39PM +0200, Hans Petter Selasky wrote: > > Hi John, > > > > I'm sorry to say that a recent patch done by you has broken at least the > > AT91RM9200 target in 8-current. > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/arm/arm/intr.c.diff?r1=1.19;r2=1.20 > > > > I spent spent several hours today scratching my head why the platform didn't > > boot. I added a couple of prints into the code: > > > > Hi, > > I believe I just fixed that problem, it was indeed AT91RM92-specific (sort of). > Thanks a lot for reporting and investigating ! > > Olivier Thanks for fixing it! -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 20:24:36 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3E09106564A; Tue, 22 Apr 2008 20:24:36 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 51E058FC19; Tue, 22 Apr 2008 20:24:36 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id m3MKOXUD097471; Tue, 22 Apr 2008 15:24:33 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1208895873; bh=d0uhiNvLKJeSj3DFzWaJxC1Xv14=; h=Date: From:Message-Id:To:Subject:Cc:In-Reply-To; b=DvjMFp2jD2OfQ9y2KAl02 17TbLvIG5wv8ucJn8/8HzSjFxQRmSxavsuXK7UKCaPvi1NEMVaHF4zZK0IHgzBArf12 u8WZtbqemw2puvq3HDAlH2XDOJvknV5xI1y1Oj1dZpLRQo2wGN0zgE0m4pYnTcAFFAq /ZRoFobQVlS5etMo= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id m3MKOXZN097466; Tue, 22 Apr 2008 15:24:33 -0500 (CDT) (envelope-from tinguely) Date: Tue, 22 Apr 2008 15:24:33 -0500 (CDT) From: Mark Tinguely Message-Id: <200804222024.m3MKOXZN097466@casselton.net> To: hselasky@c2i.net, tinguely@casselton.net In-Reply-To: <200804222000.55016.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, jhb@freebsd.org Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit (more) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 20:24:36 -0000 > Line 2730: > > /* allocate memory */ > if (bus_dmamem_alloc( > utag->tag, &ptr, (BUS_DMA_WAITOK | BUS_DMA_COHERENT), &map)) { > goto error; > } > > > > I *think* this new address lives in DMA S/G lists and should not be mapped > > into an address space except to temporarily to copy data in/out. I will > > assume this assumption is incorrect and look through the pmap code all over > > again. > > Is there a function I can call that will tell if the memory I get is in cache > enabled memory or not ? > > If there are any prints you want me to add in the kernel code I can easily do > that within short time. /* Assuming the calling VA is mapped into the KVM - put into arm/pmap.c * * kva is the kernel virtual address of the page to test. * * pvh_attrs/pv_flags are listed in include/pmap.h * the PDE/PTE will have cache information too. * */ void dumppv(vm_offset_t kva) { struct pv_entry *pv; pd_entry_t *pde; pt_entry_t *pte; vm_paddr_t pa; struct vm_page pg; vm_page_lock_queues(); /* XXX paranoid XXX */ /* get the physical address */ pa = pmap_kextract(kva); if (pa == 0) { printf("dumppv: 0x%08x no mapping\n", kva); vm_page_unlock_queues(); return; } /* find the vm_page for physical address */ pg = PHYS_TO_VM_PAGE(pa); if (pg == NULL) { printf("dumppv: 0x%08x 0x%08x no vm_page\n", kva, pa); vm_page_unlock_queues(); return; } /* dump the vm_page attributes */ printf("dumppv attrs: 0x%08x\n", pg->md.pvh_attrs); /* run through all those that share the page */ TAILQ_FOREACH(pv, pg->md.pv_list, pv_list) { /* indicate kernel or user mapping */ if (pv->pv_pmap == pmap_kernel()) printf ("dumppv kpv: "); else printf ("dumppv upv: "); /* print entry */ printf("0x%08x 0x%08x 0x%08x ", pv->pv_pmap, pv->pv_va, pv->pv_flags); /* print the PDE or PTE which will hold caching */ if (pmap_get_pde_pte(pv->pv_pmap, pv->pv_va, &pde, &pte)) { if (pmap_pde_section(pde)) printf("sec: 0x%08x", *pde); else printf("pte: 0x%08x 0x%08x", *pde, *pte); } printf("\n"); } vm_page_unlock_queues(); } Warning Will Rogers .... This is crude attempt using existing routines. Untested, Uncompiled - do not use in a routine that already locked the the pmap and vm_page. > > I think what has happend is that when the USB code is reading back the OHCI > transfer descriptors after that the transfer has completed we are still > looking at the old length field which then tells the USB stack that the > transfer is short. It is not "SET_CONFIG" that fails, but probably reading > the USB descriptors. > > > 2) set configuration has a USBD_ERR_SHORT_XFER error. > > > > I don't know if turning on USB debug printing will give more clues. > > If I turn on full debugging the problem disappears, which I think is because > the CPU cache is used up due to the excessive prints which the following > debug level settings cause: > > sysctl hw.usb.ohci.debug=16 > sysctl hw.usb.debug=15 > Strange that the debug cause things to work. filling the cache does not not make sense to me. adding another process map to mix would. Does it start working with the debug levels are very small (like 1)? > > I will look through the pmap code and see if I can chase up something. > > I see one problem: > > "malloc" is used by BUS-DMA to allocate DMA memory having a size less than > PAGE_SIZE. What happens when you have multiple DMA allocations in the same > PAGE and you then turn on/off the CPU caching on a per allocation/free > basis ? > > Mark, I really appreciate that you look into this. Walking through the pmap stuff will take a long, long time (days). I guess I need to chase down how add a COHERENT mapping. Maybe the dumppv() will find something and not crash on you. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Tue Apr 22 21:00:12 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A9E71065675; Tue, 22 Apr 2008 21:00:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 996AE8FC14; Tue, 22 Apr 2008 21:00:11 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.133.152] (account mc467741@c2i.net [62.113.133.152] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 908033428; Tue, 22 Apr 2008 23:00:09 +0200 From: Hans Petter Selasky To: Mark Tinguely Date: Tue, 22 Apr 2008 23:01:28 +0200 User-Agent: KMail/1.9.7 References: <200804222024.m3MKOXZN097466@casselton.net> In-Reply-To: <200804222024.m3MKOXZN097466@casselton.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804222301.28841.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, jhb@freebsd.org Subject: Re: AT91RM9200 and possibly other ARM targets are broken in 8-current after recent commit (more) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2008 21:00:12 -0000 Hi Mark, Here is the modified and compiled code: #define USBD_P2U POINTER_TO_UNSIGNED static void dumppv(vm_offset_t kva) { struct pv_entry *pv; pd_entry_t *pde; pt_entry_t *pte; vm_paddr_t pa; struct vm_page *pg; printf("dumping 0x%08x ", kva); vm_page_lock_queues(); /* XXX paranoid XXX */ /* get the physical address */ pa = pmap_kextract(kva); if (pa == 0) { printf("dumppv: 0x%08x no mapping\n", kva); vm_page_unlock_queues(); return; } /* find the vm_page for physical address */ pg = PHYS_TO_VM_PAGE(pa); if (pg == NULL) { printf("dumppv: 0x%08x 0x%08x no vm_page\n", kva, pa); vm_page_unlock_queues(); return; } /* dump the vm_page attributes */ printf("dumppv attrs: 0x%08x\n", pg->md.pvh_attrs); /* run through all those that share the page */ TAILQ_FOREACH(pv, &(pg->md.pv_list), pv_list) { /* indicate kernel or user mapping */ if (pv->pv_pmap == pmap_kernel()) printf ("dumppv kpv: "); else printf ("dumppv upv: "); /* print entry */ printf("0x%08x 0x%08x 0x%08x ", USBD_P2U(pv->pv_pmap), pv->pv_va, pv->pv_flags); /* print the PDE or PTE which will hold caching */ if (pmap_get_pde_pte(pv->pv_pmap, pv->pv_va, &pde, &pte)) { if (pmap_pde_section(pde)) printf("sec: 0x%08x", *pde); else printf("pte: 0x%08x 0x%08x", *pde, *pte); } printf("\n"); } vm_page_unlock_queues(); return; } This is what I get: usbd_pc_alloc_mem: dumping 0xcc009500 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc00a480 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc00b400 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc00c380 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc00d300 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc00e280 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc00f200 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc010180 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc011100 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc012080 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc013000 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc014e80 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc015e00 dumppv attrs: 0x00000000 usbd_pc_alloc_mem: dumping 0xcc016d80 dumppv attrs: 0x00000000 usbd_pc_load_mem: dumping 0xc1544150 dumppv attrs: 0x00000000 usbd_pc_load_mem: dumping 0xc1544148 dumppv attrs: 0x00000000 usbd_pc_load_mem: dumping 0xc1544150 dumppv attrs: 0x00000000 Does it make any sense to you? Looks like the page structure is not initialised. --HPS On Tuesday 22 April 2008, Mark Tinguely wrote: > > Line 2730: > > > > /* allocate memory */ > > if (bus_dmamem_alloc( > > utag->tag, &ptr, (BUS_DMA_WAITOK | BUS_DMA_COHERENT), &map)) > > { goto error; > > } > > > > > I *think* this new address lives in DMA S/G lists and should not be > > > mapped into an address space except to temporarily to copy data > > > in/out. I will assume this assumption is incorrect and look through > > > the pmap code all over again. > > > > Is there a function I can call that will tell if the memory I get is in > > cache enabled memory or not ? > > > > If there are any prints you want me to add in the kernel code I can > > easily do that within short time. > > /* Assuming the calling VA is mapped into the KVM - put into arm/pmap.c > * > * kva is the kernel virtual address of the page to test. > * > * pvh_attrs/pv_flags are listed in include/pmap.h > * the PDE/PTE will have cache information too. > * > */ > void > dumppv(vm_offset_t kva) > { > struct pv_entry *pv; > pd_entry_t *pde; > pt_entry_t *pte; > vm_paddr_t pa; > struct vm_page pg; > > vm_page_lock_queues(); /* XXX paranoid XXX */ > /* get the physical address */ > pa = pmap_kextract(kva); > if (pa == 0) { > printf("dumppv: 0x%08x no mapping\n", kva); > vm_page_unlock_queues(); > return; > } > /* find the vm_page for physical address */ > pg = PHYS_TO_VM_PAGE(pa); > if (pg == NULL) { > printf("dumppv: 0x%08x 0x%08x no vm_page\n", kva, pa); > vm_page_unlock_queues(); > return; > } > > /* dump the vm_page attributes */ > printf("dumppv attrs: 0x%08x\n", pg->md.pvh_attrs); > > /* run through all those that share the page */ > TAILQ_FOREACH(pv, pg->md.pv_list, pv_list) { > /* indicate kernel or user mapping */ > if (pv->pv_pmap == pmap_kernel()) > printf ("dumppv kpv: "); > else > printf ("dumppv upv: "); > /* print entry */ > printf("0x%08x 0x%08x 0x%08x ", pv->pv_pmap, pv->pv_va, > pv->pv_flags); /* print the PDE or PTE which will hold caching */ > if (pmap_get_pde_pte(pv->pv_pmap, pv->pv_va, &pde, &pte)) { > if (pmap_pde_section(pde)) > printf("sec: 0x%08x", *pde); > else > printf("pte: 0x%08x 0x%08x", *pde, *pte); > } > printf("\n"); > } > vm_page_unlock_queues(); > } > > Warning Will Rogers .... This is crude attempt using existing routines. > Untested, Uncompiled - do not use in a routine that already locked the > the pmap and vm_page. > > > I think what has happend is that when the USB code is reading back the > > OHCI transfer descriptors after that the transfer has completed we are > > still looking at the old length field which then tells the USB stack that > > the transfer is short. It is not "SET_CONFIG" that fails, but probably > > reading the USB descriptors. > > > > > 2) set configuration has a USBD_ERR_SHORT_XFER error. > > > > > > I don't know if turning on USB debug printing will give more clues. > > > > If I turn on full debugging the problem disappears, which I think is > > because the CPU cache is used up due to the excessive prints which the > > following debug level settings cause: > > > > sysctl hw.usb.ohci.debug=16 > > sysctl hw.usb.debug=15 > > Strange that the debug cause things to work. filling the cache does not not > make sense to me. adding another process map to mix would. Does it start > working with the debug levels are very small (like 1)? > > > > I will look through the pmap code and see if I can chase up something. > > > > I see one problem: > > > > "malloc" is used by BUS-DMA to allocate DMA memory having a size less > > than PAGE_SIZE. What happens when you have multiple DMA allocations in > > the same PAGE and you then turn on/off the CPU caching on a per > > allocation/free basis ? > > > > Mark, I really appreciate that you look into this. > > Walking through the pmap stuff will take a long, long time (days). > I guess I need to chase down how add a COHERENT mapping. > > Maybe the dumppv() will find something and not crash on you. > > --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Wed Apr 23 03:00:02 2008 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5E081065675 for ; Wed, 23 Apr 2008 03:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 91F5E8FC1C for ; Wed, 23 Apr 2008 03:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3N302Jj013912 for ; Wed, 23 Apr 2008 03:00:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3N302Ew013905; Wed, 23 Apr 2008 03:00:02 GMT (envelope-from gnats) Resent-Date: Wed, 23 Apr 2008 03:00:02 GMT Resent-Message-Id: <200804230300.m3N302Ew013905@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Mark Linimon Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D98AC106566B for ; Wed, 23 Apr 2008 02:58:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C71EC8FC0C for ; Wed, 23 Apr 2008 02:58:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3N2wsYV013797 for ; Wed, 23 Apr 2008 02:58:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3N2wsxu013796; Wed, 23 Apr 2008 02:58:54 GMT (envelope-from linimon) Message-Id: <200804230258.m3N2wsxu013796@freefall.freebsd.org> Date: Wed, 23 Apr 2008 02:58:54 GMT From: Mark Linimon To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: arm/123002: test of new GNATS category 'arm' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2008 03:00:02 -0000 >Number: 123002 >Category: arm >Synopsis: test of new GNATS category 'arm' >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Apr 23 03:00:02 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Mark Linimon >Release: FreeBSD 7.0-STABLE i386 >Organization: FreeBSD >Environment: System: FreeBSD freefall.freebsd.org 7.0-STABLE FreeBSD 7.0-STABLE #34: Sat Apr 12 11:52:18 UTC 2008 simon@freefall.freebsd.org:/usr/src/sys/i386/compile/FREEFALL i386 >Description: Test of new GNATS category 'arm' >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Wed Apr 23 03:03:57 2008 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 977B11065676; Wed, 23 Apr 2008 03:03:57 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8693C8FC23; Wed, 23 Apr 2008 03:03:57 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3N33v6c014233; Wed, 23 Apr 2008 03:03:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3N33vLu014229; Wed, 23 Apr 2008 03:03:57 GMT (envelope-from linimon) Date: Wed, 23 Apr 2008 03:03:57 GMT Message-Id: <200804230303.m3N33vLu014229@freefall.freebsd.org> To: linimon@FreeBSD.org, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: arm/123002: test of new GNATS category 'arm' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2008 03:03:57 -0000 Synopsis: test of new GNATS category 'arm' State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Wed Apr 23 03:02:54 UTC 2008 State-Changed-Why: Now working. Thanks to peter. http://www.freebsd.org/cgi/query-pr.cgi?pr=123002 From owner-freebsd-arm@FreeBSD.ORG Wed Apr 23 06:20:03 2008 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9729C1065676 for ; Wed, 23 Apr 2008 06:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8356F8FC21 for ; Wed, 23 Apr 2008 06:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3N6K2ma038344 for ; Wed, 23 Apr 2008 06:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3N6K2bq038343; Wed, 23 Apr 2008 06:20:02 GMT (envelope-from gnats) Date: Wed, 23 Apr 2008 06:20:02 GMT Message-Id: <200804230620.m3N6K2bq038343@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: "Bjoern Koenig" Cc: Subject: Re: arm/123002: test of new GNATS category 'arm' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bjoern Koenig List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2008 06:20:03 -0000 The following reply was made to PR arm/123002; it has been noted by GNATS. From: "Bjoern Koenig" To: bug-followup@freebsd.org Cc: linimon@FreeBSD.org Subject: Re: arm/123002: test of new GNATS category 'arm' Date: Wed, 23 Apr 2008 08:11:08 +0200 (CEST) Thank you, Mark. ;-) Björn From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 14:40:53 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A3AA106567C for ; Fri, 25 Apr 2008 14:40:53 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (d-link-145.cs0-nan.kv.wnet.ua [217.20.171.145]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4768FC23 for ; Fri, 25 Apr 2008 14:40:53 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from [192.168.10.90] (helo=terran.mk.farlep.net) by dlink.ua with smtp (Exim 4.63) (envelope-from ) id 1JpOf9-00011O-3X for freebsd-arm@freebsd.org; Fri, 25 Apr 2008 17:12:31 +0300 Date: Fri, 25 Apr 2008 17:21:22 +0300 From: Alexandr Rybalko To: freebsd-arm@freebsd.org Message-Id: <20080425172122.5d7d723b.ray@dlink.ua> Organization: D-Link X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.5; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: FreeBSD on PXA255 board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 14:40:53 -0000 Good time of day to all. I`m trying to run FreeBSD 7.0 on PXA255 chip (board Palm Tungsten C). Machine depended code partially write by me, and kernel started, but I have big problem. Can`t resolve problem without experience in internals of kernel. So I put to kernel code many printf`s, and can see this picture: KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #130: Fri Apr 25 16:58:58 EEST 2008 ray@terran.mk.farlep.net:/usr/home/ray/Projects/ARM/Palm_TC/NanoBSD/Nano-BSD-obj/arm/usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/PALMTC WARNING: DIAGNOSTIC option enabled, expect reduced performance. subsystem 900000 0xc02670f8(0)... done. subsystem 1000000 0xc03806fc(0)... vm_mem_init: vm_set_page_size vm_page_startup: new_end=a3fcf000 end=a3fff000 boot_pages=30 UMA_SLAB_SIZE=1000 /usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/vm/vm_page.c:277 vm_page_startup: new_end = trunc_page(new_end) = a3fcf000 /usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/vm/vm_page.c:279 IN SOURCE CODE THERE: mapped = pmap_map(&vaddr, new_end, end, VM_PROT_READ | VM_PROT_WRITE); vm_page_startup: pmap_map(&vaddr=C00FBE7C, new_end=A3FCF000,end=A3FFF000, VM_PROT_READ | VM_PROT_WRITE) = bfecf000 (vaddr=C0544000) /usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/vm/vm_page.c:284 IN SOURCE CODE THERE: bzero((void *)mapped, end - new_end); vm_page_startup: call uma_startup(bfecf000, 00000030) /usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/vm/vm_page.c:287 IN SOURCE CODE THERE: uma_startup((void *)mapped, boot_pages); __END__ last message about 'call uma_startup' in many boot try, dos not appear. So I think problem in page pointed by variable 'mapped'. Kernel don`t panic, machine only freeze. Maybe somebody know what`s is it? Help please. Thanks -- Alex RAY From owner-freebsd-arm@FreeBSD.ORG Fri Apr 25 16:51:01 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF25D1065686 for ; Fri, 25 Apr 2008 16:51:01 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 48FC48FC2F for ; Fri, 25 Apr 2008 16:51:01 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id m3PGoubr009560; Fri, 25 Apr 2008 11:50:56 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1209142256; bh=JzIWkBv2XsA/mHah68+lMRSepG8=; h=Date: From:Message-Id:To:Subject:In-Reply-To; b=Mt9fAST9aFV0pxgGaITt/sOw TvhE8JRqmB9GIS1qvMiuZo7Sb9cAtFy804mWSvRQ6wSxKdPx13r4M+oaWgmpoAQxSw4 0DXh/6/n6WuvL7/RUBcu08UdVC8cdAgWc/2/y+ts62KlVm4JVIYbdfwXOGS0F3gGyJY x0r6glWwN0Hx0= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id m3PGotrp009557; Fri, 25 Apr 2008 11:50:55 -0500 (CDT) (envelope-from tinguely) Date: Fri, 25 Apr 2008 11:50:55 -0500 (CDT) From: Mark Tinguely Message-Id: <200804251650.m3PGotrp009557@casselton.net> To: freebsd-arm@freebsd.org, ray@dlink.ua In-Reply-To: <20080425172122.5d7d723b.ray@dlink.ua> Cc: Subject: Re: FreeBSD on PXA255 board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2008 16:51:01 -0000 > I`m trying to run FreeBSD 7.0 on PXA255 chip (board Palm Tungsten C). > Machine depended code partially write by me, and kernel started, but I > have big problem. Can`t resolve problem without experience in > internals of kernel. > So I put to kernel code many printf`s, and can see this picture: > > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights > reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-STABLE #130: Fri Apr 25 16:58:58 EEST 2008 > ray@terran.mk.farlep.net:/usr/home/ray/Projects/ARM/Palm_TC/NanoBSD/Nano-BSD-obj/arm/usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/PALMTC > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > subsystem 900000 > 0xc02670f8(0)... done. > subsystem 1000000 > 0xc03806fc(0)... vm_mem_init: vm_set_page_size > vm_page_startup: new_end=a3fcf000 end=a3fff000 boot_pages=30 UMA_SLAB_SIZE=1000 /usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/vm/vm_page.c:277 > vm_page_startup: new_end = trunc_page(new_end) = a3fcf000 /usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/vm/vm_page.c:279 > IN SOURCE CODE THERE: mapped = pmap_map(&vaddr, new_end, end, VM_PROT_READ | VM_PROT_WRITE); > vm_page_startup: pmap_map(&vaddr=C00FBE7C, new_end=A3FCF000,end=A3FFF000, VM_PROT_READ | VM_PROT_WRITE) = bfecf000 (vaddr=C0544000) /usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/vm/vm_page.c:284 > IN SOURCE CODE THERE: bzero((void *)mapped, end - new_end); > vm_page_startup: call uma_startup(bfecf000, 00000030) /usr/home/ray/Projects/ARM/Palm_TC/FreeBSD/src/sys/vm/vm_page.c:287 > IN SOURCE CODE THERE: uma_startup((void *)mapped, boot_pages); > > __END__ Did you specify enough kernel page tables to map the kernel, the device mappings and the vm_page structures? The vm_page structure is being built in this routine at the top of physical memory. The more RAM that is on the board the more vm_page entries are in this structure and the larger number of kernel page tables are needed to be defined. I don't understand that mapped == 0xbfecf000. KVA usually starts at 0xc000X000, though I remeber some Xscale use ARM_USE_SMALL_ALLOC and map some things just below the KVA. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Sat Apr 26 19:16:40 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BED106566C for ; Sat, 26 Apr 2008 19:16:40 +0000 (UTC) (envelope-from errors@mail6.reachmail.net) Received: from mail6.reachmail.net (mail6.reachmail.net [216.177.115.3]) by mx1.freebsd.org (Postfix) with ESMTP id F23468FC1A for ; Sat, 26 Apr 2008 19:16:24 +0000 (UTC) (envelope-from errors@mail6.reachmail.net) From: "Veracity USA, Inc." To: "Interop 2008 Attendee" Date: Sat, 26 Apr 2008 15:03:26 -0400 Message-ID: <20080426-15032608-1498@rmmailer.colo.reachmail.com> X-BPS1: 237056 X-BPS2: 2495 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=FBCCB990BBE642C68CF1_3662_552C_0B1D" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Visit Veracity at INTEROP 2008 in Booth #2401 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Veracity USA, Inc." List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2008 19:16:40 -0000 ----=FBCCB990BBE642C68CF1_3662_552C_0B1D Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 8bit This email is being sent to freebsd-arm@freebsd.org. Use this link to be deleted or to update your email address http://go.reachmail.net/r.asp?l=64772&ee=2495!free&s=237056,237056 _________________________________________________________________ You can choose to not receive further mailings by clicking on the link above. If you have trouble with this link, simply forward this message to rem@reachmail.com with "#RM#237056,237056" in the subject line. ReachMail does not tolerate spam. Please notify us via email at abuse@reachmail.com regarding any spam issues. If you have trouble with any of these methods, you can reach us toll-free at 800-404-6885. This message was sent by Veracity USA, Inc. using ReachMail. Read our Privacy Policy: http://reachmail.net/privacy.htm ----=FBCCB990BBE642C68CF1_3662_552C_0B1D--