From owner-freebsd-arm@FreeBSD.ORG Sun May 5 13:00:13 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E1F28147 for ; Sun, 5 May 2013 13:00:13 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id C7847D4C for ; Sun, 5 May 2013 13:00:13 +0000 (UTC) Received: from bender (cpc24-aztw24-2-0-cust99.18-1.cable.virginmedia.com [92.237.65.100]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 1222F5E1F5; Sun, 5 May 2013 13:00:06 +0000 (UTC) Date: Sun, 5 May 2013 14:00:06 +0100 From: Andrew Turner To: Tim Kientzle Subject: Re: Is this related to the general panic discussed in freebsd-current? Message-ID: <20130505140006.0d671ba5@bender> In-Reply-To: <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 05 May 2013 13:00:13 -0000 On Sat, 4 May 2013 15:44:37 -0700 Tim Kientzle wrote: > I'm baffled. If I insert a printf into the loop in stack_capture, > the kernel boots. But the generated assembly looks perfectly correct > to me in either case. So inserting the printf must have some > side-effect. > > The stack does end up aligned differently: The failing version puts > 16 bytes on the stack, the working version puts 24 bytes. But I > can't figure out how that would explain what I'm seeing... It feels like an alignment issue but those stack sizes should both be valid. Are you able to send me the asm for the working and broken versions of the function? Also which ABI are you using? I have not been able to reproduce it with EABI, but that may have been because I have a patched clang I've been using to track down another issue. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun May 5 16:37:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC6A7C93 for ; Sun, 5 May 2013 16:37:57 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 90553327 for ; Sun, 5 May 2013 16:37:56 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r45Gbncc027804; Sun, 5 May 2013 16:37:49 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id heqvz7bnhxg7f7y354hds6jjan; Sun, 05 May 2013 16:37:49 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Is this related to the general panic discussed in freebsd-current? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130505140006.0d671ba5@bender> Date: Sun, 5 May 2013 09:37:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 05 May 2013 16:37:57 -0000 On May 5, 2013, at 6:00 AM, Andrew Turner wrote: > On Sat, 4 May 2013 15:44:37 -0700 > Tim Kientzle wrote: >> I'm baffled. If I insert a printf into the loop in stack_capture, >> the kernel boots. But the generated assembly looks perfectly correct >> to me in either case. So inserting the printf must have some >> side-effect. >>=20 >> The stack does end up aligned differently: The failing version puts >> 16 bytes on the stack, the working version puts 24 bytes. But I >> can't figure out how that would explain what I'm seeing... >=20 > It feels like an alignment issue but those stack sizes should both be > valid. Are you able to send me the asm for the working and broken > versions of the function? >=20 > Also which ABI are you using? I have not been able to reproduce it = with > EABI, but that may have been because I have a patched clang I've been > using to track down another issue. I'm using whatever the default is in FreeBSD-CURRENT. I've seen this consistently with both RaspberryPi and BeagleBone kernels for the last few weeks. The disassembly is below. The interleaved C is my attempt to reverse-engineer the assembly into C syntax, which is why it's not quite the same as the code in sys/arm/arm/stack_machdep.c. The working version adds=20 printf("%s: frame=3D%p\n", __func__, frame);=20 just before the !INKERNEL(frame) check. If you see anything actually wrong with the "Broken version", I'm very curious. I spent much of yesterday afternoon staring at it and cannot for the life of me see a problem with it. I have experimented with other variations on the C code and have found a bunch of other variations that work or fail to work but have yet to explain why. Cheers, Tim /* Working version */ c0519d20 : void stack_save(struct stack *st) { c0519d20: e92d48f0 push {r4, r5, r6, r7, fp, lr} c0519d24: e28db010 add fp, sp, #16 ; 0x10 u_int32_t *frame; /* r7 */ stack_zero(st); c0519d28: e1a04000 mov r4, r0 c0519d2c: ebf9ca49 bl c038c658 printf("%s: frame=3D%p\n", __func__, frame);=20 c0519d30: e59f0054 ldr r0, [pc, #84] ; c0519d8c = <_end+0xffd94e70> c0519d34: e59f1054 ldr r1, [pc, #84] ; c0519d90 = <_end+0xffd94e74> c0519d38: e1a0200b mov r2, fp c0519d3c: ebf9a87d bl c0383f38 if (!INKERNEL(frame)) break; /* =3D=3D=3D> return */=20 c0519d40: e35b0103 cmp fp, #-1073741824 ; = 0xc0000000 c0519d44: 38bd88f0 popcc {r4, r5, r6, r7, fp, pc} c0519d48: e59f503c ldr r5, [pc, #60] ; c0519d8c = <_end+0xffd94e70> c0519d4c: e59f603c ldr r6, [pc, #60] ; c0519d90 = <_end+0xffd94e74> frame =3D (u_int32_t *)__builtin_frame_address(0); c0519d50: e1a0700b mov r7, fp do { callpc =3D frame[FR_SCP]; c0519d54: e5971000 ldr r1, [r7] if (stack_put(st, callpc) =3D=3D -1) break; /* =3D=3D> return */ c0519d58: e1a00004 mov r0, r4 c0519d5c: ebf9ca2c bl c038c614 c0519d60: e3700001 cmn r0, #1 ; 0x1 c0519d64: 0a000007 beq c0519d88 frame =3D (u_int32_t *)(frame[FR_RFP]); /* FR_RFP =3D=3D = -3 */ c0519d68: e247000c sub r0, r7, #12 ; 0xc c0519d70: e5907000 ldr r7, [r0] printf("%s: frame=3D%p\n", __func__, frame);=20 c0519d6c: e1a01006 mov r1, r6 c0519d74: e1a00005 mov r0, r5 c0519d78: e1a02007 mov r2, r7 c0519d7c: ebf9a86d bl c0383f38 } while (INKERNEL(frame)); c0519d80: e3570103 cmp r7, #-1073741824 ; = 0xc0000000 c0519d84: 2afffff2 bcs c0519d54 } c0519d88: e8bd88f0 pop {r4, r5, r6, r7, fp, pc} /* Broken version */ c0519cec : void stack_save(struct stack *st) { c0519cec: e92d4830 push {r4, r5, fp, lr} c0519cf0: e28db008 add fp, sp, #8 ; 0x8 u_int32_t *frame; /* r5 */ stack_zero(st); c0519cf4: e1a04000 mov r4, r0 c0519cf8: ebf9ca56 bl c038c658 if (!INKERNEL(frame)) break; c0519cfc: e35b0103 cmp fp, #-1073741824 ; = 0xc0000000 c0519d00: 38bd8830 popcc {r4, r5, fp, pc} frame =3D (u_int32_t *)__builtin_frame_address(0); c0519d04: e1a0500b mov r5, fp do { callpc =3D frame[FR_SCP]; c0519d08: e5951000 ldr r1, [r5] if (stack_put(st, callpc) =3D=3D -1) break; c0519d0c: e1a00004 mov r0, r4 c0519d10: ebf9ca3f bl c038c614 c0519d14: e3700001 cmn r0, #1 ; 0x1 c0519d18: 0a000003 beq c0519d2c frame =3D (u_int32_t *)(frame[FR_RFP]); c0519d1c: e245000c sub r0, r5, #12 ; 0xc c0519d20: e5905000 ldr r5, [r0] } while (INKERNEL(frame)); c0519d24: e3550103 cmp r5, #-1073741824 ; = 0xc0000000 c0519d28: 2afffff6 bcs c0519d08 } c0519d2c: e8bd8830 pop {r4, r5, fp, pc} From owner-freebsd-arm@FreeBSD.ORG Sun May 5 22:37:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8E63C00 for ; Sun, 5 May 2013 22:37:34 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id ADFF6FD5 for ; Sun, 5 May 2013 22:37:34 +0000 (UTC) Received: from bender.lan (46-37-55-91.dsl.cnl.uk.net [46.37.55.91]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 053E85E1F5; Sun, 5 May 2013 22:37:32 +0000 (UTC) Date: Sun, 5 May 2013 23:37:29 +0100 From: Andrew Turner To: Tim Kientzle Subject: Re: Is this related to the general panic discussed in freebsd-current? Message-ID: <20130505233729.63ac23bc@bender.lan> In-Reply-To: References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 05 May 2013 22:37:34 -0000 On Sun, 5 May 2013 09:37:48 -0700 Tim Kientzle wrote: > On May 5, 2013, at 6:00 AM, Andrew Turner wrote: > > > On Sat, 4 May 2013 15:44:37 -0700 > > Tim Kientzle wrote: > >> I'm baffled. If I insert a printf into the loop in stack_capture, > >> the kernel boots. But the generated assembly looks perfectly > >> correct to me in either case. So inserting the printf must have > >> some side-effect. > >> > >> The stack does end up aligned differently: The failing version > >> puts 16 bytes on the stack, the working version puts 24 bytes. > >> But I can't figure out how that would explain what I'm seeing... > > > > It feels like an alignment issue but those stack sizes should both > > be valid. Are you able to send me the asm for the working and broken > > versions of the function? > > > > Also which ABI are you using? I have not been able to reproduce it > > with EABI, but that may have been because I have a patched clang > > I've been using to track down another issue. > > I'm using whatever the default is in FreeBSD-CURRENT. I've seen > this consistently with both RaspberryPi and BeagleBone kernels > for the last few weeks. Ok, it's the old ABI. I note this function may be broken with EABI as it make assumptions on the layout of each frame. > If you see anything actually wrong with the "Broken version", > I'm very curious. I spent much of yesterday afternoon staring > at it and cannot for the life of me see a problem with it. I can't see anything different with the asm that can't be explained by the added printf call. > /* Broken version */ > c0519cec : > void > stack_save(struct stack *st) > { > c0519cec: e92d4830 push {r4, r5, fp, lr} This stack layout is incorrect. It should store (from a low address to high address) r4, r5, fp, ip, lr and pc. The unwind code following is incorrect for this stack layout. In your working code how deep is the stack you are printing? I suspect you are getting lucky with the data on the stack. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun May 5 23:20:31 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1AB426E4 for ; Sun, 5 May 2013 23:20:31 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id E2B5E1C2 for ; Sun, 5 May 2013 23:20:30 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r45NKTuF030208; Sun, 5 May 2013 23:20:29 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id hr6w4sdvtj26egpxnyk2kzgezw; Sun, 05 May 2013 23:20:29 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Is this related to the general panic discussed in freebsd-current? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130505233729.63ac23bc@bender.lan> Date: Sun, 5 May 2013 16:20:28 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> To: Andrew Turner X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 05 May 2013 23:20:31 -0000 On May 5, 2013, at 3:37 PM, Andrew Turner wrote: > On Sun, 5 May 2013 09:37:48 -0700 > Tim Kientzle wrote: >> On May 5, 2013, at 6:00 AM, Andrew Turner wrote: >> >>> On Sat, 4 May 2013 15:44:37 -0700 >>> Tim Kientzle wrote: >>>> I'm baffled. If I insert a printf into the loop in stack_capture, >>>> the kernel boots. But the generated assembly looks perfectly >>>> correct to me in either case. So inserting the printf must have >>>> some side-effect. >>>> >>>> The stack does end up aligned differently: The failing version >>>> puts 16 bytes on the stack, the working version puts 24 bytes. >>>> But I can't figure out how that would explain what I'm seeing... >>> >>> It feels like an alignment issue but those stack sizes should both >>> be valid. Are you able to send me the asm for the working and broken >>> versions of the function? >>> >>> Also which ABI are you using? I have not been able to reproduce it >>> with EABI, but that may have been because I have a patched clang >>> I've been using to track down another issue. >> >> I'm using whatever the default is in FreeBSD-CURRENT. I've seen >> this consistently with both RaspberryPi and BeagleBone kernels >> for the last few weeks. > Ok, it's the old ABI. I note this function may be broken with EABI as > it make assumptions on the layout of each frame. Thought so. >> /* Broken version */ >> c0519cec : >> void >> stack_save(struct stack *st) >> { >> c0519cec: e92d4830 push {r4, r5, fp, lr} > > This stack layout is incorrect. It should store (from a low address to > high address) r4, r5, fp, ip, lr and pc. If I understand right, you're claiming that Clang is generating a wrong preamble for OABI functions which is manifesting as crashes in the stack-walking code. I'm not sure I understand the frame layout you're saying it should use, though. Pushing PC seems a very strange thing to do on ARM. (Though it would seem to match sys/arm/include/stack.h.) It doesn't look like Clang/OABI is using the layout you suggest anywhere in the kernel code: I grepped through the kernel disassembly and found only a single instance of "fp, ip, lr, pc" and that was from assembly. It also looks like sys/arm/include/stack.h needs to be taught about the difference between EABI and OABI. > The unwind code following is > incorrect for this stack layout. Ah. I'll take another look. I hadn't tried to match up the offsets to see if they made sense for the stack layout. I could probably change this stack-walking code to match the frame layout being used by Clang here, but I'm not sure whether that's the "right" fix. > In your working code how deep is the stack you are printing? I > suspect you are getting lucky with the data on the stack. Yes, almost certainly it's a matter of luck here. I had noticed that when I added the printf, it became apparent that the function never walked more than one frame. Now I understand why. Tim From owner-freebsd-arm@FreeBSD.ORG Mon May 6 05:40:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 381B1DEA for ; Mon, 6 May 2013 05:40:00 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 0A47AFCE for ; Mon, 6 May 2013 05:39:59 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r465dw9b032288; Mon, 6 May 2013 05:39:58 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id epqsv7tixpa5i5cih4v9hti5sn; Mon, 06 May 2013 05:39:57 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Is this related to the general panic discussed in freebsd-current? From: Tim Kientzle In-Reply-To: Date: Sun, 5 May 2013 22:39:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> To: freebsd-arm@freebsd.org, Andrew Turner X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 05:40:00 -0000 On May 5, 2013, at 4:20 PM, Tim Kientzle wrote: >=20 > On May 5, 2013, at 3:37 PM, Andrew Turner wrote: >=20 >> On Sun, 5 May 2013 09:37:48 -0700 >> Tim Kientzle wrote: >>> On May 5, 2013, at 6:00 AM, Andrew Turner wrote: >>>=20 >>>> On Sat, 4 May 2013 15:44:37 -0700 >>>> Tim Kientzle wrote: >>>>> I'm baffled. If I insert a printf into the loop in stack_capture, >>>>> the kernel boots. But the generated assembly looks perfectly >>>>> correct to me in either case. So inserting the printf must have >>>>> some side-effect. >>>>>=20 >>>>> The stack does end up aligned differently: The failing version >>>>> puts 16 bytes on the stack, the working version puts 24 bytes. >>>>> But I can't figure out how that would explain what I'm seeing... >>>>=20 >>>> It feels like an alignment issue but those stack sizes should both >>>> be valid. Are you able to send me the asm for the working and = broken >>>> versions of the function? >>>>=20 >>>> Also which ABI are you using? I have not been able to reproduce it >>>> with EABI, but that may have been because I have a patched clang >>>> I've been using to track down another issue. >>>=20 >>> I'm using whatever the default is in FreeBSD-CURRENT. I've seen >>> this consistently with both RaspberryPi and BeagleBone kernels >>> for the last few weeks. >> Ok, it's the old ABI. I note this function may be broken with EABI as >> it make assumptions on the layout of each frame. >=20 > Thought so. >=20 >>> /* Broken version */ >>> c0519cec : >>> void >>> stack_save(struct stack *st) >>> { >>> c0519cec: e92d4830 push {r4, r5, fp, lr} >>=20 >> This stack layout is incorrect. It should store (from a low address = to >> high address) r4, r5, fp, ip, lr and pc. >=20 > If I understand right, you're claiming that Clang is generating > a wrong preamble for OABI functions which is manifesting > as crashes in the stack-walking code. >=20 > I'm not sure I understand the frame layout you're saying it > should use, though. Pushing PC seems a very strange thing > to do on ARM. (Though it would seem to match = sys/arm/include/stack.h.) >=20 > It doesn't look like Clang/OABI is using the layout you suggest > anywhere in the kernel code: I grepped through the kernel > disassembly and found only a single instance of "fp, ip, lr, pc" > and that was from assembly. >=20 > It also looks like sys/arm/include/stack.h needs to be taught > about the difference between EABI and OABI. >=20 >> The unwind code following is >> incorrect for this stack layout. >=20 > Ah. I'll take another look. I hadn't tried to match up the offsets > to see if they made sense for the stack layout. >=20 > I could probably change this stack-walking code to > match the frame layout being used by Clang here, > but I'm not sure whether that's the "right" fix. Here's a version of stack_capture that allows a Clang-built OABI kernel with WITNESS enabled to boot: /* In sys/arm/arm/stack_machdep.c */ static void stack_capture(struct stack *st, u_int32_t *frame) { vm_offset_t callpc; stack_zero(st); while (INKERNEL(frame)) { callpc =3D frame[1]; if (stack_put(st, callpc) =3D=3D -1) break; frame =3D (u_int32_t *)(frame[0]); } } =46rom the above, it sounds like this should not be committed; rather, we should fix Clang's OABI support to emit the right frame layout. I've not yet started to look through Clang to try to figure out how to do that=85. Any pointers? ;-) Tim From owner-freebsd-arm@FreeBSD.ORG Mon May 6 05:44:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A3995E43 for ; Mon, 6 May 2013 05:44:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 82A1AFE1 for ; Mon, 6 May 2013 05:44:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r465ihvL032326 for freebsd-arm@freebsd.org; Mon, 6 May 2013 05:44:43 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 4wnr7swhe5j67aqcgqf9djmhun; for freebsd-arm@freebsd.org; Mon, 06 May 2013 05:44:42 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Is this related to the general panic discussed in freebsd-current? From: Tim Kientzle In-Reply-To: <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> Date: Sun, 5 May 2013 22:44:42 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 05:44:43 -0000 On May 5, 2013, at 10:39 PM, Tim Kientzle wrote: > > Here's a version of stack_capture that allows a Clang-built > OABI kernel with WITNESS enabled to boot: > > /* In sys/arm/arm/stack_machdep.c */ > static void > stack_capture(struct stack *st, u_int32_t *frame) > { > vm_offset_t callpc; > > stack_zero(st); > while (INKERNEL(frame)) { > callpc = frame[1]; > if (stack_put(st, callpc) == -1) > break; > frame = (u_int32_t *)(frame[0]); > } > } On a related note: With this change, a Crochet-built BeagleBone image does boot on BeagleBone Black. ;-) Tim From owner-freebsd-arm@FreeBSD.ORG Mon May 6 07:22:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DDEB3F56 for ; Mon, 6 May 2013 07:22:43 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 730CB682 for ; Mon, 6 May 2013 07:22:42 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 45BB4C8230; Mon, 6 May 2013 09:22:34 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 7U6Xp-4sVYIH; Mon, 6 May 2013 09:22:33 +0200 (CEST) Received: from [10.0.0.93] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 78D91C5DF7; Mon, 6 May 2013 09:22:33 +0200 (CEST) Message-ID: <518775B4.1010308@semihalf.com> Date: Mon, 06 May 2013 11:19:48 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120127 Thunderbird/3.1.16 MIME-Version: 1.0 To: Olivier Houchard Subject: Re: RFC: Patches with AXP support and pmap&smp fixes. References: <517E8610.5050204@semihalf.com> <20130430142701.5bbfec2b@bender.lan> <20130430143311.GA71966@ci0.org> In-Reply-To: <20130430143311.GA71966@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 07:22:43 -0000 On 04/30/13 16:33, Olivier Houchard wrote: > On Tue, Apr 30, 2013 at 02:27:01PM +0100, Andrew Turner wrote: >> On Mon, 29 Apr 2013 16:39:12 +0200 >> Grzegorz Bernacki wrote: >> >>> Hi, >>> >>> I am going to submit some changes related to Armada XP support and >>> some general ARM fixes. You can find them at: >>> http://people.freebsd.org/~gber/armada >>> >>> It would be good if someone could review changes in generic ARM code >>> i.e.: 1) >>> http://people.freebsd.org/~gber/armada/0004-arm-smp-Fix-AP-processors-initialization-procedure.patch >>> >>> This patch fixes race condition in pcpu_init function. pcpu_init >>> performs operation on signly-linked tail queue and the queue can be >>> corrupted by secondary cpus initialization. >> >> > From this patch I can infer you have used FreeBSD ARM with SMP. Have >> you tried with WITNESS enabled? If not can you try? >> >> There is a known issue where accessing curthread is non-atomic when it >> is required to be. In it's current state mutexes may fail when they are >> unlocked. Olivier Houchard had a patch a few months ago to rework how >> the data is stored. My understanding is this helped but I have not seen >> or tried the patch. >> >> Olivier, is the above correct, and are we able to get this work into >> the tree so we can work on making SMP stable? >> >> Andrew > > Hi Andrew, > > That's true, the patch helped a lot, by storing curthread and curpcb on the > stack, and disabling interrupts while accessing less used pcpu entries. > However something was still wrong, after maybe between 30 minutes and 1 hour > of building port, I would get a random panic, usually from the VM, that I was > unable to diagnose so far. > I can dust of the patch, and share it anyway, even if it's still more a proof > of concept than anything else, if somebody is willing to work with me on the > remaining issues. > Also, it was my understanding that Semihalf also had an alternative patch to > solve the very same issue, did I get that wrong ? > > Regards, > > Olivier Hi, Our patch fixes only initialization of pcpu in pcpu_init(). In 4 cores setup it is possible the at least two cores simultaneously updating queue of pcpus which causes corruption. I am not aware of any other problems with SMP. Let us try setup with WITNESS enabled and we'll see if we have the same problem. Olivier, could you share your patch? In case we have the problem we would like to have it. thanks, grzesiek From owner-freebsd-arm@FreeBSD.ORG Mon May 6 07:26:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5ED79FE8 for ; Mon, 6 May 2013 07:26:57 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton2.metanet.ch [80.74.158.131]) by mx1.freebsd.org (Postfix) with ESMTP id C14216AC for ; Mon, 6 May 2013 07:26:56 +0000 (UTC) Received: (qmail 30671 invoked from network); 6 May 2013 09:26:48 +0200 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 6 May 2013 09:26:48 +0200 Message-ID: <51875B37.8060802@thieprojects.ch> Date: Mon, 06 May 2013 09:26:47 +0200 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: Is this related to the general panic discussed in freebsd-current? References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 07:26:57 -0000 On 5/6/13 7:44 AM, Tim Kientzle wrote: > On May 5, 2013, at 10:39 PM, Tim Kientzle wrote: >> >> Here's a version of stack_capture that allows a Clang-built >> OABI kernel with WITNESS enabled to boot: >> >> /* In sys/arm/arm/stack_machdep.c */ >> static void >> stack_capture(struct stack *st, u_int32_t *frame) >> { >> vm_offset_t callpc; >> >> stack_zero(st); >> while (INKERNEL(frame)) { >> callpc = frame[1]; >> if (stack_put(st, callpc) == -1) >> break; >> frame = (u_int32_t *)(frame[0]); >> } >> } > > On a related note: With this change, a Crochet-built BeagleBone > image does boot on BeagleBone Black. ;-) Hi Tim Thxs for the nudge with the config.sh, I'm really not into shell programming. Yesterday I did an image with WITNESS disabled and the only observation I can share is, that FreeBSD crashes silently and is highly instable when the BeagleBone is powered by USB only, switching to the 5V external power supply its now building python27 just ok right now. Werner From owner-freebsd-arm@FreeBSD.ORG Mon May 6 11:06:42 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F3FB493B for ; Mon, 6 May 2013 11:06:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CC4BF9EF for ; Mon, 6 May 2013 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r46B6fDb023705 for ; Mon, 6 May 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r46B6ffN023703 for freebsd-arm@FreeBSD.org; Mon, 6 May 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 May 2013 11:06:41 GMT Message-Id: <201305061106.r46B6ffN023703@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 11:06:42 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177685 arm [kernel] [patch] Correct return type and usage of at91 o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/176424 arm Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODU o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on p arm/134338 arm [patch] Lock GPIO accesses on ixp425 23 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon May 6 11:33:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 31F75B5A for ; Mon, 6 May 2013 11:33:06 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0A85DE12 for ; Mon, 6 May 2013 11:33:05 +0000 (UTC) Received: from bender.lan (46-37-55-91.dsl.cnl.uk.net [46.37.55.91]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 1FBF75E1F5; Mon, 6 May 2013 11:33:03 +0000 (UTC) Date: Mon, 6 May 2013 12:33:01 +0100 From: Andrew Turner To: Tim Kientzle Subject: Re: Is this related to the general panic discussed in freebsd-current? Message-ID: <20130506123301.397bbfcd@bender.lan> In-Reply-To: References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 11:33:06 -0000 On Sun, 5 May 2013 16:20:28 -0700 Tim Kientzle wrote: > > On May 5, 2013, at 3:37 PM, Andrew Turner wrote: > > > On Sun, 5 May 2013 09:37:48 -0700 > > Tim Kientzle wrote: > >> On May 5, 2013, at 6:00 AM, Andrew Turner wrote: > >> > >>> On Sat, 4 May 2013 15:44:37 -0700 > >>> Tim Kientzle wrote: > >>>> I'm baffled. If I insert a printf into the loop in > >>>> stack_capture, the kernel boots. But the generated assembly > >>>> looks perfectly correct to me in either case. So inserting the > >>>> printf must have some side-effect. > >>>> > >>>> The stack does end up aligned differently: The failing version > >>>> puts 16 bytes on the stack, the working version puts 24 bytes. > >>>> But I can't figure out how that would explain what I'm seeing... > >>> > >>> It feels like an alignment issue but those stack sizes should both > >>> be valid. Are you able to send me the asm for the working and > >>> broken versions of the function? > >>> > >>> Also which ABI are you using? I have not been able to reproduce it > >>> with EABI, but that may have been because I have a patched clang > >>> I've been using to track down another issue. > >> > >> I'm using whatever the default is in FreeBSD-CURRENT. I've seen > >> this consistently with both RaspberryPi and BeagleBone kernels > >> for the last few weeks. > > Ok, it's the old ABI. I note this function may be broken with EABI > > as it make assumptions on the layout of each frame. > > Thought so. > > >> /* Broken version */ > >> c0519cec : > >> void > >> stack_save(struct stack *st) > >> { > >> c0519cec: e92d4830 push {r4, r5, fp, lr} > > > > This stack layout is incorrect. It should store (from a low address > > to high address) r4, r5, fp, ip, lr and pc. > > If I understand right, you're claiming that Clang is generating > a wrong preamble for OABI functions which is manifesting > as crashes in the stack-walking code. Clang is generating an invalid preample for APCS (ARM Procedure Call Standard), at least according to the documentation I've read. > > I'm not sure I understand the frame layout you're saying it > should use, though. Pushing PC seems a very strange thing > to do on ARM. (Though it would seem to match > sys/arm/include/stack.h.) The stack structure is described at [1]. The documentation I have says storing pc is to find the function the stack frame belongs to. > It doesn't look like Clang/OABI is using the layout you suggest > anywhere in the kernel code: I grepped through the kernel > disassembly and found only a single instance of "fp, ip, lr, pc" > and that was from assembly. > > It also looks like sys/arm/include/stack.h needs to be taught > about the difference between EABI and OABI. Yes, EABI will be difficult, it either needs to use the unwind code, decode the stack instructions, we tell clang to add a frame pointer, or we stop implementing the two functions saving the stack. IA64 takes the last approach. I'm not sure how difficult it would be to teach clang to store the frame pointer for us to use, from a quick test it appears to be more difficult than adding -fno-omit-frame-pointer to the command. > > The unwind code following is > > incorrect for this stack layout. > > Ah. I'll take another look. I hadn't tried to match up the offsets > to see if they made sense for the stack layout. > > I could probably change this stack-walking code to > match the frame layout being used by Clang here, > but I'm not sure whether that's the "right" fix. I suspect the right fix is to move to EABI. I have one bug to fix in clang before this can be done, where the stack is incorrectly aligned in 'leaf' functions accessing thread local data. I have a work around for it and may commit this until a better solution can be found. This may also explain why backtrace is also broken. It is likely expecting the same frame layout. > > In your working code how deep is the stack you are printing? I > > suspect you are getting lucky with the data on the stack. > > Yes, almost certainly it's a matter of luck here. I had noticed that > when I added the printf, it became apparent that the function never > walked more than one frame. Now I understand why. Welcome to the world of debugging stack issues where adding function calls can magically fix things. Andrew [1] http://www.heyrick.co.uk/assembler/apcsintro.html From owner-freebsd-arm@FreeBSD.ORG Mon May 6 11:47:13 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D281E2C; Mon, 6 May 2013 11:47:13 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 60792E87; Mon, 6 May 2013 11:47:12 +0000 (UTC) Received: from bender.lan (46-37-55-91.dsl.cnl.uk.net [46.37.55.91]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 1F8385E1F5; Mon, 6 May 2013 11:47:11 +0000 (UTC) Date: Mon, 6 May 2013 12:47:11 +0100 From: Andrew Turner To: Tim Kientzle Subject: Re: Is this related to the general panic discussed in freebsd-current? Message-ID: <20130506124711.23978ec8@bender.lan> In-Reply-To: <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 11:47:13 -0000 On Sun, 5 May 2013 22:39:56 -0700 Tim Kientzle wrote: > Here's a version of stack_capture that allows a Clang-built > OABI kernel with WITNESS enabled to boot: > > /* In sys/arm/arm/stack_machdep.c */ > static void > stack_capture(struct stack *st, u_int32_t *frame) > { > vm_offset_t callpc; > > stack_zero(st); > while (INKERNEL(frame)) { > callpc = frame[1]; > if (stack_put(st, callpc) == -1) > break; > frame = (u_int32_t *)(frame[0]); > } > } It looks like this should work in most cases where fp and lr are next to each other (ip and sp are between them but doesn't need to be saved). > > > From the above, it sounds like this should not be committed; > rather, we should fix Clang's OABI support to emit the right > frame layout. I've not yet started to look through Clang to > try to figure out how to do that…. Any pointers? ;-) Disable this stack unwind code? I'll fix the clang EABI issue and switch the ABI. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon May 6 13:41:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 33F6D52D for ; Mon, 6 May 2013 13:41:55 +0000 (UTC) (envelope-from cognet@ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id CB76068E for ; Mon, 6 May 2013 13:41:54 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r46DfUxK060163; Mon, 6 May 2013 15:41:30 +0200 (CEST) (envelope-from cognet@ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r46DfTgk060162; Mon, 6 May 2013 15:41:29 +0200 (CEST) (envelope-from cognet@ci0.org) X-Authentication-Warning: kanar.ci0.org: doginou set sender to cognet@ci0.org using -f Date: Mon, 6 May 2013 15:41:29 +0200 From: Olivier Houchard To: Grzegorz Bernacki Subject: Re: RFC: Patches with AXP support and pmap&smp fixes. Message-ID: <20130506134129.GA60131@ci0.org> References: <517E8610.5050204@semihalf.com> <20130430142701.5bbfec2b@bender.lan> <20130430143311.GA71966@ci0.org> <518775B4.1010308@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <518775B4.1010308@semihalf.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 13:41:55 -0000 On Mon, May 06, 2013 at 11:19:48AM +0200, Grzegorz Bernacki wrote: > > Hi, > > Our patch fixes only initialization of pcpu in pcpu_init(). In 4 cores > setup it is possible the at least two cores simultaneously updating > queue of pcpus which causes corruption. > I am not aware of any other problems with SMP. Let us try setup with > WITNESS enabled and we'll see if we have the same problem. > Olivier, could you share your patch? In case we have the problem we > would like to have it. > Hi, Sure I will dust it off, and send it. Maybe not before Sunday though, I'll be mostly MIA for the week. I'm quite interested in you guys having a look at it. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Mon May 6 17:56:50 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E909632F for ; Mon, 6 May 2013 17:56:50 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton2.metanet.ch [80.74.158.131]) by mx1.freebsd.org (Postfix) with ESMTP id 56BBB6C2 for ; Mon, 6 May 2013 17:56:49 +0000 (UTC) Received: (qmail 31486 invoked from network); 6 May 2013 19:56:48 +0200 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 6 May 2013 19:56:48 +0200 Message-ID: <5187EEE0.906@thieprojects.ch> Date: Mon, 06 May 2013 19:56:48 +0200 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andrew Turner Subject: Re: Is this related to the general panic discussed in freebsd-current? References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> <20130506124711.23978ec8@bender.lan> In-Reply-To: <20130506124711.23978ec8@bender.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 06 May 2013 17:56:51 -0000 Hi all With WITNESS disabled, the BeagleBone runs more or less ok, just had Python from ports coming up, Python 2.7.3 (default, May 5 2013, 16:49:13) [GCC 4.2.1 Compatible FreeBSD Clang 3.3 (trunk 178860)] on freebsd10 but closer looks showed, that ctypes fails to build because of Undefined symbol "__clear_cache" Googling does not reveal all to much, is this a problem connected with the ARM platform? Thxs, Werner On 5/6/13 1:47 PM, Andrew Turner wrote: > On Sun, 5 May 2013 22:39:56 -0700 > Tim Kientzle wrote: >> Here's a version of stack_capture that allows a Clang-built >> OABI kernel with WITNESS enabled to boot: >> >> /* In sys/arm/arm/stack_machdep.c */ >> static void >> stack_capture(struct stack *st, u_int32_t *frame) >> { >> vm_offset_t callpc; >> >> stack_zero(st); >> while (INKERNEL(frame)) { >> callpc = frame[1]; >> if (stack_put(st, callpc) == -1) >> break; >> frame = (u_int32_t *)(frame[0]); >> } >> } > It looks like this should work in most cases where fp and lr are next > to each other (ip and sp are between them but doesn't need to be saved). >> >> >> From the above, it sounds like this should not be committed; >> rather, we should fix Clang's OABI support to emit the right >> frame layout. I've not yet started to look through Clang to >> try to figure out how to do that…. Any pointers? ;-) > Disable this stack unwind code? I'll fix the clang EABI issue and > switch the ABI. > > Andrew > _______________________________________________ > 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 owner-freebsd-arm@FreeBSD.ORG Mon May 6 21:41:26 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72F268D5; Mon, 6 May 2013 21:41:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 965A691D; Mon, 6 May 2013 21:41:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r46LXPfj061414; Mon, 6 May 2013 17:33:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r46LXP6c061408; Mon, 6 May 2013 21:33:25 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 6 May 2013 21:33:25 GMT Message-Id: <201305062133.r46LXP6c061408@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 21:41:26 -0000 TB --- 2013-05-06 18:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-06 18:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-06 18:20:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-05-06 18:20:17 - cleaning the object tree TB --- 2013-05-06 18:20:17 - /usr/local/bin/svn stat /src TB --- 2013-05-06 18:20:22 - At svn revision 250303 TB --- 2013-05-06 18:20:23 - building world TB --- 2013-05-06 18:20:23 - CROSS_BUILD_TESTING=YES TB --- 2013-05-06 18:20:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-06 18:20:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-06 18:20:23 - SRCCONF=/dev/null TB --- 2013-05-06 18:20:23 - TARGET=arm TB --- 2013-05-06 18:20:23 - TARGET_ARCH=arm TB --- 2013-05-06 18:20:23 - TZ=UTC TB --- 2013-05-06 18:20:23 - __MAKE_CONF=/dev/null TB --- 2013-05-06 18:20:23 - cd /src TB --- 2013-05-06 18:20:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon May 6 18:20:27 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 6 21:18:05 UTC 2013 TB --- 2013-05-06 21:18:05 - generating LINT kernel config TB --- 2013-05-06 21:18:05 - cd /src/sys/arm/conf TB --- 2013-05-06 21:18:05 - /usr/bin/make -B LINT TB --- 2013-05-06 21:18:05 - cd /src/sys/arm/conf TB --- 2013-05-06 21:18:05 - /usr/sbin/config -m LINT TB --- 2013-05-06 21:18:05 - building LINT kernel TB --- 2013-05-06 21:18:05 - CROSS_BUILD_TESTING=YES TB --- 2013-05-06 21:18:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-06 21:18:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-06 21:18:05 - SRCCONF=/dev/null TB --- 2013-05-06 21:18:05 - TARGET=arm TB --- 2013-05-06 21:18:05 - TARGET_ARCH=arm TB --- 2013-05-06 21:18:05 - TZ=UTC TB --- 2013-05-06 21:18:05 - __MAKE_CONF=/dev/null TB --- 2013-05-06 21:18:05 - cd /src TB --- 2013-05-06 21:18:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 6 21:18:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ~~~~~~~~~~~~~~~~~ ^ ~ /src/sys/arm/mv/common.c:1765:21: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare] if (wintab->remap >= 0 && win_cpu_can_remap(i) != 1) { ~~~~~~~~~~~~~ ^ ~ /src/sys/arm/mv/common.c:884:1: error: unused function 'decode_win_sdram_fixup' [-Werror,-Wunused-function] decode_win_sdram_fixup(void) ^ 4 warnings and 1 error generated. *** [common.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-05-06 21:33:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-06 21:33:25 - ERROR: failed to build LINT kernel TB --- 2013-05-06 21:33:25 - 9268.09 user 1640.77 system 11587.39 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 7 08:28:52 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C01A615C; Tue, 7 May 2013 08:28:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 987FE84C; Tue, 7 May 2013 08:28:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r478SpHW017613; Tue, 7 May 2013 04:28:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r478SpZq017606; Tue, 7 May 2013 08:28:51 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 7 May 2013 08:28:51 GMT Message-Id: <201305070828.r478SpZq017606@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 08:28:52 -0000 TB --- 2013-05-07 05:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-07 05:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-07 05:10:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-05-07 05:10:19 - cleaning the object tree TB --- 2013-05-07 05:11:34 - /usr/local/bin/svn stat /src TB --- 2013-05-07 05:11:37 - At svn revision 250322 TB --- 2013-05-07 05:11:38 - building world TB --- 2013-05-07 05:11:38 - CROSS_BUILD_TESTING=YES TB --- 2013-05-07 05:11:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-07 05:11:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-07 05:11:38 - SRCCONF=/dev/null TB --- 2013-05-07 05:11:38 - TARGET=arm TB --- 2013-05-07 05:11:38 - TARGET_ARCH=arm TB --- 2013-05-07 05:11:38 - TZ=UTC TB --- 2013-05-07 05:11:38 - __MAKE_CONF=/dev/null TB --- 2013-05-07 05:11:38 - cd /src TB --- 2013-05-07 05:11:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue May 7 05:11:43 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 7 08:13:24 UTC 2013 TB --- 2013-05-07 08:13:24 - generating LINT kernel config TB --- 2013-05-07 08:13:24 - cd /src/sys/arm/conf TB --- 2013-05-07 08:13:24 - /usr/bin/make -B LINT TB --- 2013-05-07 08:13:24 - cd /src/sys/arm/conf TB --- 2013-05-07 08:13:24 - /usr/sbin/config -m LINT TB --- 2013-05-07 08:13:24 - building LINT kernel TB --- 2013-05-07 08:13:24 - CROSS_BUILD_TESTING=YES TB --- 2013-05-07 08:13:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-07 08:13:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-07 08:13:24 - SRCCONF=/dev/null TB --- 2013-05-07 08:13:24 - TARGET=arm TB --- 2013-05-07 08:13:24 - TARGET_ARCH=arm TB --- 2013-05-07 08:13:24 - TZ=UTC TB --- 2013-05-07 08:13:24 - __MAKE_CONF=/dev/null TB --- 2013-05-07 08:13:24 - cd /src TB --- 2013-05-07 08:13:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 7 08:13:24 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ~~~~~~~~~~~~~~~~~ ^ ~ /src/sys/arm/mv/common.c:1765:21: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare] if (wintab->remap >= 0 && win_cpu_can_remap(i) != 1) { ~~~~~~~~~~~~~ ^ ~ /src/sys/arm/mv/common.c:884:1: error: unused function 'decode_win_sdram_fixup' [-Werror,-Wunused-function] decode_win_sdram_fixup(void) ^ 4 warnings and 1 error generated. *** [common.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-05-07 08:28:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-07 08:28:51 - ERROR: failed to build LINT kernel TB --- 2013-05-07 08:28:51 - 9289.93 user 1641.05 system 11911.67 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed May 8 06:23:02 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 903116D; Wed, 8 May 2013 06:23:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 67F3E8BB; Wed, 8 May 2013 06:23:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r486N1a3040116; Wed, 8 May 2013 02:23:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r486Muqp039913; Wed, 8 May 2013 06:22:56 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 May 2013 06:22:56 GMT Message-Id: <201305080622.r486Muqp039913@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 06:23:02 -0000 TB --- 2013-05-08 03:10:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-08 03:10:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-08 03:10:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-05-08 03:10:19 - cleaning the object tree TB --- 2013-05-08 03:10:19 - /usr/local/bin/svn stat /src TB --- 2013-05-08 03:10:24 - At svn revision 250347 TB --- 2013-05-08 03:10:25 - building world TB --- 2013-05-08 03:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-05-08 03:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-08 03:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-08 03:10:25 - SRCCONF=/dev/null TB --- 2013-05-08 03:10:25 - TARGET=arm TB --- 2013-05-08 03:10:25 - TARGET_ARCH=arm TB --- 2013-05-08 03:10:25 - TZ=UTC TB --- 2013-05-08 03:10:25 - __MAKE_CONF=/dev/null TB --- 2013-05-08 03:10:25 - cd /src TB --- 2013-05-08 03:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed May 8 03:10:29 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed May 8 06:08:09 UTC 2013 TB --- 2013-05-08 06:08:09 - generating LINT kernel config TB --- 2013-05-08 06:08:09 - cd /src/sys/arm/conf TB --- 2013-05-08 06:08:09 - /usr/bin/make -B LINT TB --- 2013-05-08 06:08:10 - cd /src/sys/arm/conf TB --- 2013-05-08 06:08:10 - /usr/sbin/config -m LINT TB --- 2013-05-08 06:08:10 - building LINT kernel TB --- 2013-05-08 06:08:10 - CROSS_BUILD_TESTING=YES TB --- 2013-05-08 06:08:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-08 06:08:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-08 06:08:10 - SRCCONF=/dev/null TB --- 2013-05-08 06:08:10 - TARGET=arm TB --- 2013-05-08 06:08:10 - TARGET_ARCH=arm TB --- 2013-05-08 06:08:10 - TZ=UTC TB --- 2013-05-08 06:08:10 - __MAKE_CONF=/dev/null TB --- 2013-05-08 06:08:10 - cd /src TB --- 2013-05-08 06:08:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 8 06:08:10 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -ffreestanding -Werror /src/sys/vm/vm_phys.c /src/sys/vm/vm_phys.c:467:5: error: 'VM_NDOMAIN' is not defined, evaluates to 0 [-Werror,-Wundef] #if VM_NDOMAIN > 1 ^ /src/sys/vm/vm_phys.c:480:5: error: 'VM_NDOMAIN' is not defined, evaluates to 0 [-Werror,-Wundef] #if VM_NDOMAIN > 1 ^ 2 errors generated. *** [vm_phys.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-05-08 06:22:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-08 06:22:56 - ERROR: failed to build LINT kernel TB --- 2013-05-08 06:22:56 - 9258.30 user 1619.19 system 11556.77 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed May 8 08:59:09 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ABC8F7FD for ; Wed, 8 May 2013 08:59:09 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 6854CF30 for ; Wed, 8 May 2013 08:59:09 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 0DBD5EBDB4; Wed, 8 May 2013 10:59:02 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id v87yXXvZI4f4; Wed, 8 May 2013 10:59:01 +0200 (CEST) Received: from [10.0.2.117] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 8891FC5A29; Wed, 8 May 2013 10:59:01 +0200 (CEST) Message-ID: <518A13D5.9030904@semihalf.com> Date: Wed, 08 May 2013 10:59:01 +0200 From: Zbyszek Bodek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: Re: New PV entry allocator for pmap-v6.c References: <518545A0.5020107@semihalf.com> In-Reply-To: <518545A0.5020107@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 08:59:09 -0000 On 04.05.2013 19:30, Zbyszek Bodek wrote: > Hello everyone, > > As a part of Semihalf work on Superpages support, > we've made some pmap-v6.c improvements and clean-ups. > > We would like to start integrating our code to the mainline FreeBSD, > therefore I'm happy to introduce the new PV entry allocator for > pmap-v6.c ported from amd64/i386/mips. > > Alan Cox (alc) was so kind to review the code. > > If there are no objections, then we will commit this patch to the HEAD > around Monday/Tuesday. > > Please check out the attachment for details. > Hello again, Does anyone have any comments and/or remarks regarding the mentioned patch? I was testing it on the multicore ARMv7 machine however, it would be good if someone test it on available ARMv6/ARMv7 platforms. Best regards Zbyszek Bodek From owner-freebsd-arm@FreeBSD.ORG Wed May 8 09:18:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3558FDEA for ; Wed, 8 May 2013 09:18:56 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id AC0316E for ; Wed, 8 May 2013 09:18:54 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r488x6NV099027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 May 2013 18:59:07 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r488x1lo098681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 May 2013 18:59:01 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r488x1p1098680 for freebsd-arm@freebsd.org; Wed, 8 May 2013 18:59:01 +1000 (EST) (envelope-from peter) Date: Wed, 8 May 2013 18:59:01 +1000 From: Peter Jeremy To: freebsd-arm@freebsd.org Subject: Sawtooth ping RTT on RPi Message-ID: <20130508085901.GA90732@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 09:18:56 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've noticed a sawtooth-shaped cyclic pattern in ping RTTs to my RPi (running r249590M): 64 bytes from 192.168.123.231: icmp_seq=3D22 ttl=3D64 time=3D1.321 ms 64 bytes from 192.168.123.231: icmp_seq=3D23 ttl=3D64 time=3D10.312 ms 64 bytes from 192.168.123.231: icmp_seq=3D24 ttl=3D64 time=3D9.328 ms 64 bytes from 192.168.123.231: icmp_seq=3D25 ttl=3D64 time=3D8.335 ms 64 bytes from 192.168.123.231: icmp_seq=3D26 ttl=3D64 time=3D7.411 ms 64 bytes from 192.168.123.231: icmp_seq=3D27 ttl=3D64 time=3D6.448 ms 64 bytes from 192.168.123.231: icmp_seq=3D28 ttl=3D64 time=3D5.497 ms 64 bytes from 192.168.123.231: icmp_seq=3D29 ttl=3D64 time=3D4.508 ms 64 bytes from 192.168.123.231: icmp_seq=3D30 ttl=3D64 time=3D3.540 ms 64 bytes from 192.168.123.231: icmp_seq=3D31 ttl=3D64 time=3D2.588 ms 64 bytes from 192.168.123.231: icmp_seq=3D32 ttl=3D64 time=3D1.635 ms 64 bytes from 192.168.123.231: icmp_seq=3D33 ttl=3D64 time=3D0.738 ms 64 bytes from 192.168.123.231: icmp_seq=3D34 ttl=3D64 time=3D9.770 ms 64 bytes from 192.168.123.231: icmp_seq=3D35 ttl=3D64 time=3D8.805 ms 64 bytes from 192.168.123.231: icmp_seq=3D36 ttl=3D64 time=3D7.833 ms 64 bytes from 192.168.123.231: icmp_seq=3D37 ttl=3D64 time=3D6.843 ms 64 bytes from 192.168.123.231: icmp_seq=3D38 ttl=3D64 time=3D5.869 ms This doesn't appear with Linux (which has a RTT of 0.42ms with very little variance). What is causing the RTT pattern on FreeBSD? Haw does Linux manage to respond so much faster? --=20 Peter Jeremy --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGKE9UACgkQ/opHv/APuIfvZQCgg62OWwxeBZwSPXeSvSVJz5Yb 53UAoILLTeYfxPSIo7dUR4PqDQhfYIU9 =Zqk+ -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-arm@FreeBSD.ORG Wed May 8 09:35:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAC47229 for ; Wed, 8 May 2013 09:35:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 581C514E for ; Wed, 8 May 2013 09:35:12 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id p60so1506179wes.7 for ; Wed, 08 May 2013 02:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7vZuAL0xg93eOs0Zjh17Iv+lzbyXNTQwJLmWItt/q5k=; b=XSzTNUc8UCfNX153fsINp1YZQmeYvvr6bqpGOhZ7bDjuW1NVRgfM/YI6RlbMAERnLZ 1rOKpvSsSZNncrQzpA4faTkor0l1fXCywv37ZZo2xxB29N2p7kIRDqyecF3oj1vd+l5U zYZTnNWkEbbM0fQwzoLoa8djjhrb4xt1TtQIrXKWB9UaAyfceeXjLvwYb7T023vdSz7a DtKqG6TeeXNtpM8urCjGEN9u+/szks60u6qWzVeahKAUBP8IPSpmgDxweri5G9S2wcS9 NTmEAjSPOL76NiyRvRZ3Djd/U8raeRZHUE4yKGW2hyFfxRRyfdFGIEpXK+pOVi+cjYeS kqjQ== MIME-Version: 1.0 X-Received: by 10.194.248.200 with SMTP id yo8mr9174137wjc.36.1368005706932; Wed, 08 May 2013 02:35:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Wed, 8 May 2013 02:35:06 -0700 (PDT) In-Reply-To: <20130508085901.GA90732@server.rulingia.com> References: <20130508085901.GA90732@server.rulingia.com> Date: Wed, 8 May 2013 02:35:06 -0700 X-Google-Sender-Auth: YAB7TnlOCcTKtkT0qjXQylDdY2s Message-ID: Subject: Re: Sawtooth ping RTT on RPi From: Adrian Chadd To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 09:35:12 -0000 CAn you run that for a minute or two, just to capture a few cycles? Adrian On 8 May 2013 01:59, Peter Jeremy wrote: > I've noticed a sawtooth-shaped cyclic pattern in ping RTTs to my RPi > (running r249590M): > 64 bytes from 192.168.123.231: icmp_seq=22 ttl=64 time=1.321 ms > 64 bytes from 192.168.123.231: icmp_seq=23 ttl=64 time=10.312 ms > 64 bytes from 192.168.123.231: icmp_seq=24 ttl=64 time=9.328 ms > 64 bytes from 192.168.123.231: icmp_seq=25 ttl=64 time=8.335 ms > 64 bytes from 192.168.123.231: icmp_seq=26 ttl=64 time=7.411 ms > 64 bytes from 192.168.123.231: icmp_seq=27 ttl=64 time=6.448 ms > 64 bytes from 192.168.123.231: icmp_seq=28 ttl=64 time=5.497 ms > 64 bytes from 192.168.123.231: icmp_seq=29 ttl=64 time=4.508 ms > 64 bytes from 192.168.123.231: icmp_seq=30 ttl=64 time=3.540 ms > 64 bytes from 192.168.123.231: icmp_seq=31 ttl=64 time=2.588 ms > 64 bytes from 192.168.123.231: icmp_seq=32 ttl=64 time=1.635 ms > 64 bytes from 192.168.123.231: icmp_seq=33 ttl=64 time=0.738 ms > 64 bytes from 192.168.123.231: icmp_seq=34 ttl=64 time=9.770 ms > 64 bytes from 192.168.123.231: icmp_seq=35 ttl=64 time=8.805 ms > 64 bytes from 192.168.123.231: icmp_seq=36 ttl=64 time=7.833 ms > 64 bytes from 192.168.123.231: icmp_seq=37 ttl=64 time=6.843 ms > 64 bytes from 192.168.123.231: icmp_seq=38 ttl=64 time=5.869 ms > > This doesn't appear with Linux (which has a RTT of 0.42ms with > very little variance). > > What is causing the RTT pattern on FreeBSD? > Haw does Linux manage to respond so much faster? > > -- > Peter Jeremy From owner-freebsd-arm@FreeBSD.ORG Wed May 8 09:53:05 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 409EF90C for ; Wed, 8 May 2013 09:53:05 +0000 (UTC) (envelope-from Daan@vitsch.nl) Received: from Prakkezator.VEHosting.nl (Prakkezator6.VEHosting.nl [IPv6:2001:1af8:2100:b020::142]) by mx1.freebsd.org (Postfix) with ESMTP id BBBB524A for ; Wed, 8 May 2013 09:53:04 +0000 (UTC) Received: from [192.168.72.13] (124-54.bbned.dsl.internl.net [92.254.54.124]) (authenticated bits=0) by Prakkezator.VEHosting.nl (8.14.2/8.14.2) with ESMTP id r489r0lU082198; Wed, 8 May 2013 11:53:01 +0200 (CEST) (envelope-from Daan@vitsch.nl) From: Daan Vreeken Organization: Daan - Vitsch Electronics To: Peter Jeremy Subject: Re: Sawtooth ping RTT on RPi Date: Wed, 8 May 2013 11:52:58 +0200 User-Agent: KMail/1.9.10 References: <1368004745-2722398601.ad1d31edc9@bliksem.vehosting.nl> <20130508085901.GA90732@server.rulingia.com> In-Reply-To: <20130508085901.GA90732@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201305081153.00407.Daan@vitsch.nl> x-ve-auth-version: mi-1.1.7 2011-02-21 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on Prakkezator.VEHosting.nl Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 09:53:05 -0000 Hi Peter, On Wednesday 08 May 2013 10:59:01 Peter Jeremy wrote: > I've noticed a sawtooth-shaped cyclic pattern in ping RTTs to my RPi > (running r249590M): > 64 bytes from 192.168.123.231: icmp_seq=22 ttl=64 time=1.321 ms > 64 bytes from 192.168.123.231: icmp_seq=23 ttl=64 time=10.312 ms > 64 bytes from 192.168.123.231: icmp_seq=24 ttl=64 time=9.328 ms > 64 bytes from 192.168.123.231: icmp_seq=25 ttl=64 time=8.335 ms > 64 bytes from 192.168.123.231: icmp_seq=26 ttl=64 time=7.411 ms > 64 bytes from 192.168.123.231: icmp_seq=27 ttl=64 time=6.448 ms > 64 bytes from 192.168.123.231: icmp_seq=28 ttl=64 time=5.497 ms > 64 bytes from 192.168.123.231: icmp_seq=29 ttl=64 time=4.508 ms > 64 bytes from 192.168.123.231: icmp_seq=30 ttl=64 time=3.540 ms > 64 bytes from 192.168.123.231: icmp_seq=31 ttl=64 time=2.588 ms > 64 bytes from 192.168.123.231: icmp_seq=32 ttl=64 time=1.635 ms > 64 bytes from 192.168.123.231: icmp_seq=33 ttl=64 time=0.738 ms > 64 bytes from 192.168.123.231: icmp_seq=34 ttl=64 time=9.770 ms > 64 bytes from 192.168.123.231: icmp_seq=35 ttl=64 time=8.805 ms > 64 bytes from 192.168.123.231: icmp_seq=36 ttl=64 time=7.833 ms > 64 bytes from 192.168.123.231: icmp_seq=37 ttl=64 time=6.843 ms > 64 bytes from 192.168.123.231: icmp_seq=38 ttl=64 time=5.869 ms > > This doesn't appear with Linux (which has a RTT of 0.42ms with > very little variance). > > What is causing the RTT pattern on FreeBSD? > Haw does Linux manage to respond so much faster? This would typically be caused by something polling for packets every 10ms (instead of using an interrupt to gather the packet(s) right at the moment they are received). Sometimes your echo request is sent just before a polling interval and you'll see a low RTT. Sometimes the echo request is sent just after a polling interval and the response will only be sent after the next polling interval, increasing the RTT by the polling interval (which seems to be 10ms here). When you're pinging continuously, you'll see the RTT vary between the two extremes as shown above. To summarize: I guess FreeBSD uses polling (at 100Hz) instead of interrupts for the (USB connected?) Ethernet port on the RPi. Regards, -- Ing. Daan Vreeken Vitsch Electronics http://Vitsch.nl/ http://VitschVPN.nl/ tel: +31-(0)40-7113051 KvK nr: 17174380 -- Machines en netwerken op afstand beheren? Vitsch VPN oplossing! Kijk voor meer informatie op: http://www.VitschVPN.nl/ From owner-freebsd-arm@FreeBSD.ORG Wed May 8 09:54:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DADF8976; Wed, 8 May 2013 09:54:23 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 60EC7269; Wed, 8 May 2013 09:54:22 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r489sLBb099177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 May 2013 19:54:21 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r489sFsH063404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 19:54:15 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r489sFl2063403; Wed, 8 May 2013 19:54:15 +1000 (EST) (envelope-from peter) Date: Wed, 8 May 2013 19:54:14 +1000 From: Peter Jeremy To: Adrian Chadd Subject: Re: Sawtooth ping RTT on RPi Message-ID: <20130508095414.GB90732@server.rulingia.com> References: <20130508085901.GA90732@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 09:54:23 -0000 --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-May-08 02:35:06 -0700, Adrian Chadd wrote: >On 8 May 2013 01:59, Peter Jeremy wrote: >> I've noticed a sawtooth-shaped cyclic pattern in ping RTTs to my RPi >> (running r249590M): =2E.. >CAn you run that for a minute or two, just to capture a few cycles? Apart from the outliers at 0 and 23, the following is a regular sawtooth for 2 mins. PING rpi1.rulingia.com (192.168.123.231): 56 data bytes 64 bytes from 192.168.123.231: icmp_seq=3D0 ttl=3D64 time=3D19.996 ms 64 bytes from 192.168.123.231: icmp_seq=3D1 ttl=3D64 time=3D10.306 ms 64 bytes from 192.168.123.231: icmp_seq=3D2 ttl=3D64 time=3D9.342 ms 64 bytes from 192.168.123.231: icmp_seq=3D3 ttl=3D64 time=3D8.361 ms 64 bytes from 192.168.123.231: icmp_seq=3D4 ttl=3D64 time=3D7.365 ms 64 bytes from 192.168.123.231: icmp_seq=3D5 ttl=3D64 time=3D6.491 ms 64 bytes from 192.168.123.231: icmp_seq=3D6 ttl=3D64 time=3D5.477 ms 64 bytes from 192.168.123.231: icmp_seq=3D7 ttl=3D64 time=3D4.507 ms 64 bytes from 192.168.123.231: icmp_seq=3D8 ttl=3D64 time=3D3.590 ms 64 bytes from 192.168.123.231: icmp_seq=3D9 ttl=3D64 time=3D2.537 ms 64 bytes from 192.168.123.231: icmp_seq=3D10 ttl=3D64 time=3D1.627 ms 64 bytes from 192.168.123.231: icmp_seq=3D11 ttl=3D64 time=3D10.738 ms 64 bytes from 192.168.123.231: icmp_seq=3D12 ttl=3D64 time=3D9.709 ms 64 bytes from 192.168.123.231: icmp_seq=3D13 ttl=3D64 time=3D8.708 ms 64 bytes from 192.168.123.231: icmp_seq=3D14 ttl=3D64 time=3D7.790 ms 64 bytes from 192.168.123.231: icmp_seq=3D15 ttl=3D64 time=3D6.832 ms 64 bytes from 192.168.123.231: icmp_seq=3D16 ttl=3D64 time=3D5.853 ms 64 bytes from 192.168.123.231: icmp_seq=3D17 ttl=3D64 time=3D4.928 ms 64 bytes from 192.168.123.231: icmp_seq=3D18 ttl=3D64 time=3D2.948 ms 64 bytes from 192.168.123.231: icmp_seq=3D19 ttl=3D64 time=3D2.027 ms 64 bytes from 192.168.123.231: icmp_seq=3D20 ttl=3D64 time=3D1.015 ms 64 bytes from 192.168.123.231: icmp_seq=3D21 ttl=3D64 time=3D10.042 ms 64 bytes from 192.168.123.231: icmp_seq=3D22 ttl=3D64 time=3D9.156 ms 64 bytes from 192.168.123.231: icmp_seq=3D23 ttl=3D64 time=3D18.039 ms 64 bytes from 192.168.123.231: icmp_seq=3D24 ttl=3D64 time=3D7.217 ms 64 bytes from 192.168.123.231: icmp_seq=3D25 ttl=3D64 time=3D6.196 ms 64 bytes from 192.168.123.231: icmp_seq=3D26 ttl=3D64 time=3D5.287 ms 64 bytes from 192.168.123.231: icmp_seq=3D27 ttl=3D64 time=3D4.321 ms 64 bytes from 192.168.123.231: icmp_seq=3D28 ttl=3D64 time=3D3.350 ms 64 bytes from 192.168.123.231: icmp_seq=3D29 ttl=3D64 time=3D2.440 ms 64 bytes from 192.168.123.231: icmp_seq=3D30 ttl=3D64 time=3D1.385 ms 64 bytes from 192.168.123.231: icmp_seq=3D31 ttl=3D64 time=3D10.386 ms 64 bytes from 192.168.123.231: icmp_seq=3D32 ttl=3D64 time=3D9.469 ms 64 bytes from 192.168.123.231: icmp_seq=3D33 ttl=3D64 time=3D8.527 ms 64 bytes from 192.168.123.231: icmp_seq=3D34 ttl=3D64 time=3D7.161 ms 64 bytes from 192.168.123.231: icmp_seq=3D35 ttl=3D64 time=3D6.565 ms 64 bytes from 192.168.123.231: icmp_seq=3D36 ttl=3D64 time=3D5.629 ms 64 bytes from 192.168.123.231: icmp_seq=3D37 ttl=3D64 time=3D4.205 ms 64 bytes from 192.168.123.231: icmp_seq=3D38 ttl=3D64 time=3D3.697 ms 64 bytes from 192.168.123.231: icmp_seq=3D39 ttl=3D64 time=3D2.720 ms 64 bytes from 192.168.123.231: icmp_seq=3D40 ttl=3D64 time=3D1.748 ms 64 bytes from 192.168.123.231: icmp_seq=3D41 ttl=3D64 time=3D0.851 ms 64 bytes from 192.168.123.231: icmp_seq=3D42 ttl=3D64 time=3D9.869 ms 64 bytes from 192.168.123.231: icmp_seq=3D43 ttl=3D64 time=3D8.913 ms 64 bytes from 192.168.123.231: icmp_seq=3D44 ttl=3D64 time=3D6.915 ms 64 bytes from 192.168.123.231: icmp_seq=3D45 ttl=3D64 time=3D4.986 ms 64 bytes from 192.168.123.231: icmp_seq=3D46 ttl=3D64 time=3D4.045 ms 64 bytes from 192.168.123.231: icmp_seq=3D47 ttl=3D64 time=3D3.069 ms 64 bytes from 192.168.123.231: icmp_seq=3D48 ttl=3D64 time=3D2.137 ms 64 bytes from 192.168.123.231: icmp_seq=3D49 ttl=3D64 time=3D1.168 ms 64 bytes from 192.168.123.231: icmp_seq=3D50 ttl=3D64 time=3D10.172 ms 64 bytes from 192.168.123.231: icmp_seq=3D51 ttl=3D64 time=3D9.254 ms 64 bytes from 192.168.123.231: icmp_seq=3D52 ttl=3D64 time=3D8.272 ms 64 bytes from 192.168.123.231: icmp_seq=3D53 ttl=3D64 time=3D7.328 ms 64 bytes from 192.168.123.231: icmp_seq=3D54 ttl=3D64 time=3D6.375 ms 64 bytes from 192.168.123.231: icmp_seq=3D55 ttl=3D64 time=3D5.390 ms 64 bytes from 192.168.123.231: icmp_seq=3D56 ttl=3D64 time=3D4.037 ms 64 bytes from 192.168.123.231: icmp_seq=3D57 ttl=3D64 time=3D3.425 ms 64 bytes from 192.168.123.231: icmp_seq=3D58 ttl=3D64 time=3D2.435 ms 64 bytes from 192.168.123.231: icmp_seq=3D59 ttl=3D64 time=3D1.542 ms 64 bytes from 192.168.123.231: icmp_seq=3D60 ttl=3D64 time=3D10.591 ms 64 bytes from 192.168.123.231: icmp_seq=3D61 ttl=3D64 time=3D9.581 ms 64 bytes from 192.168.123.231: icmp_seq=3D62 ttl=3D64 time=3D8.686 ms 64 bytes from 192.168.123.231: icmp_seq=3D63 ttl=3D64 time=3D7.721 ms 64 bytes from 192.168.123.231: icmp_seq=3D64 ttl=3D64 time=3D6.804 ms 64 bytes from 192.168.123.231: icmp_seq=3D65 ttl=3D64 time=3D5.764 ms 64 bytes from 192.168.123.231: icmp_seq=3D66 ttl=3D64 time=3D4.777 ms 64 bytes from 192.168.123.231: icmp_seq=3D67 ttl=3D64 time=3D3.857 ms 64 bytes from 192.168.123.231: icmp_seq=3D68 ttl=3D64 time=3D2.934 ms 64 bytes from 192.168.123.231: icmp_seq=3D69 ttl=3D64 time=3D0.928 ms 64 bytes from 192.168.123.231: icmp_seq=3D70 ttl=3D64 time=3D9.007 ms 64 bytes from 192.168.123.231: icmp_seq=3D71 ttl=3D64 time=3D8.053 ms 64 bytes from 192.168.123.231: icmp_seq=3D72 ttl=3D64 time=3D7.651 ms 64 bytes from 192.168.123.231: icmp_seq=3D73 ttl=3D64 time=3D6.105 ms 64 bytes from 192.168.123.231: icmp_seq=3D74 ttl=3D64 time=3D5.113 ms 64 bytes from 192.168.123.231: icmp_seq=3D75 ttl=3D64 time=3D4.188 ms 64 bytes from 192.168.123.231: icmp_seq=3D76 ttl=3D64 time=3D3.270 ms 64 bytes from 192.168.123.231: icmp_seq=3D77 ttl=3D64 time=3D2.271 ms 64 bytes from 192.168.123.231: icmp_seq=3D78 ttl=3D64 time=3D1.284 ms 64 bytes from 192.168.123.231: icmp_seq=3D79 ttl=3D64 time=3D1.263 ms 64 bytes from 192.168.123.231: icmp_seq=3D80 ttl=3D64 time=3D10.384 ms 64 bytes from 192.168.123.231: icmp_seq=3D81 ttl=3D64 time=3D9.392 ms 64 bytes from 192.168.123.231: icmp_seq=3D82 ttl=3D64 time=3D8.461 ms 64 bytes from 192.168.123.231: icmp_seq=3D83 ttl=3D64 time=3D7.516 ms 64 bytes from 192.168.123.231: icmp_seq=3D84 ttl=3D64 time=3D6.152 ms 64 bytes from 192.168.123.231: icmp_seq=3D85 ttl=3D64 time=3D5.575 ms 64 bytes from 192.168.123.231: icmp_seq=3D86 ttl=3D64 time=3D4.635 ms 64 bytes from 192.168.123.231: icmp_seq=3D87 ttl=3D64 time=3D3.626 ms 64 bytes from 192.168.123.231: icmp_seq=3D88 ttl=3D64 time=3D2.728 ms 64 bytes from 192.168.123.231: icmp_seq=3D89 ttl=3D64 time=3D1.751 ms 64 bytes from 192.168.123.231: icmp_seq=3D90 ttl=3D64 time=3D0.758 ms 64 bytes from 192.168.123.231: icmp_seq=3D91 ttl=3D64 time=3D9.798 ms 64 bytes from 192.168.123.231: icmp_seq=3D92 ttl=3D64 time=3D8.824 ms 64 bytes from 192.168.123.231: icmp_seq=3D93 ttl=3D64 time=3D7.890 ms 64 bytes from 192.168.123.231: icmp_seq=3D94 ttl=3D64 time=3D6.932 ms 64 bytes from 192.168.123.231: icmp_seq=3D95 ttl=3D64 time=3D4.977 ms 64 bytes from 192.168.123.231: icmp_seq=3D96 ttl=3D64 time=3D4.015 ms 64 bytes from 192.168.123.231: icmp_seq=3D97 ttl=3D64 time=3D3.049 ms 64 bytes from 192.168.123.231: icmp_seq=3D98 ttl=3D64 time=3D2.093 ms 64 bytes from 192.168.123.231: icmp_seq=3D99 ttl=3D64 time=3D1.111 ms 64 bytes from 192.168.123.231: icmp_seq=3D100 ttl=3D64 time=3D10.213 ms 64 bytes from 192.168.123.231: icmp_seq=3D101 ttl=3D64 time=3D9.263 ms 64 bytes from 192.168.123.231: icmp_seq=3D102 ttl=3D64 time=3D8.283 ms 64 bytes from 192.168.123.231: icmp_seq=3D103 ttl=3D64 time=3D8.312 ms 64 bytes from 192.168.123.231: icmp_seq=3D104 ttl=3D64 time=3D7.379 ms 64 bytes from 192.168.123.231: icmp_seq=3D105 ttl=3D64 time=3D6.411 ms 64 bytes from 192.168.123.231: icmp_seq=3D106 ttl=3D64 time=3D5.409 ms 64 bytes from 192.168.123.231: icmp_seq=3D107 ttl=3D64 time=3D4.457 ms 64 bytes from 192.168.123.231: icmp_seq=3D108 ttl=3D64 time=3D3.472 ms 64 bytes from 192.168.123.231: icmp_seq=3D109 ttl=3D64 time=3D2.561 ms 64 bytes from 192.168.123.231: icmp_seq=3D110 ttl=3D64 time=3D1.598 ms 64 bytes from 192.168.123.231: icmp_seq=3D111 ttl=3D64 time=3D10.610 ms 64 bytes from 192.168.123.231: icmp_seq=3D112 ttl=3D64 time=3D9.636 ms 64 bytes from 192.168.123.231: icmp_seq=3D113 ttl=3D64 time=3D8.659 ms 64 bytes from 192.168.123.231: icmp_seq=3D114 ttl=3D64 time=3D7.661 ms 64 bytes from 192.168.123.231: icmp_seq=3D115 ttl=3D64 time=3D6.762 ms 64 bytes from 192.168.123.231: icmp_seq=3D116 ttl=3D64 time=3D5.771 ms 64 bytes from 192.168.123.231: icmp_seq=3D117 ttl=3D64 time=3D4.816 ms 64 bytes from 192.168.123.231: icmp_seq=3D118 ttl=3D64 time=3D3.888 ms 64 bytes from 192.168.123.231: icmp_seq=3D119 ttl=3D64 time=3D2.909 ms 64 bytes from 192.168.123.231: icmp_seq=3D120 ttl=3D64 time=3D0.936 ms ^C --- rpi1.rulingia.com ping statistics --- 121 packets transmitted, 121 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 0.758/5.921/19.996/3.362 ms --=20 Peter Jeremy --qcHopEYAB45HaUaB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGKIMYACgkQ/opHv/APuIcj7gCgkv3brwwR1g0nUOgTz9rxrgN2 lYoAn13GyAs01qVxKJv4YgUlZyy08lLu =tGOf -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB-- From owner-freebsd-arm@FreeBSD.ORG Wed May 8 10:12:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 74A3BD3A for ; Wed, 8 May 2013 10:12:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCB4306 for ; Wed, 8 May 2013 10:12:47 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hm14so1720162wib.5 for ; Wed, 08 May 2013 03:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=q9FEBN5YjHmBPjXch7gjS+21b9RaDsotCc5Ppf3+M7k=; b=ITvEYT7xicFvhKFrP0lbGi7jZIvPWo4bRtlCaxpNG8Q70VQDpu7g6+uZxOm3bnpuOU ZD2jpjcDvvZtXopT63ZwVAMCYA6WfgfTRA656qMGlGjyQNRa1/uLfCnr27hLNnNpZFvk Zz26ZWwqlWb9xAmpgbr5mcOQFMS66wdapSOF+81BcTRWKWnl6CjKPrtuCeOiVvLeJr1f wNBECk3XkFvl5Ek7iHbXM1Z7Sv5MDLmWQS7gHAYsvH0MizMICe1vBoTa3aNDzCpgPCoi Zj1+xum05uw+1D5dVaLXBsJHITw5ydaNTdCUx1LZW4HqbTgZ5uNv2SoYSuPipQezOI8q NMdA== MIME-Version: 1.0 X-Received: by 10.194.248.200 with SMTP id yo8mr9426373wjc.36.1368007963699; Wed, 08 May 2013 03:12:43 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Wed, 8 May 2013 03:12:43 -0700 (PDT) In-Reply-To: <20130508095414.GB90732@server.rulingia.com> References: <20130508085901.GA90732@server.rulingia.com> <20130508095414.GB90732@server.rulingia.com> Date: Wed, 8 May 2013 03:12:43 -0700 X-Google-Sender-Auth: 1Doc-kC2qYqt9tU1drREvNAOsw0 Message-ID: Subject: Re: Sawtooth ping RTT on RPi From: Adrian Chadd To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 10:12:48 -0000 yup, that looks like two almost-but-not-in-sync sampling periods (one being poll, one being ping) beating against each other. Is the USB stuff being polled? Adrian On 8 May 2013 02:54, Peter Jeremy wrote: > On 2013-May-08 02:35:06 -0700, Adrian Chadd wrote: >>On 8 May 2013 01:59, Peter Jeremy wrote: >>> I've noticed a sawtooth-shaped cyclic pattern in ping RTTs to my RPi >>> (running r249590M): > ... >>CAn you run that for a minute or two, just to capture a few cycles? > > Apart from the outliers at 0 and 23, the following is a regular > sawtooth for 2 mins. > > PING rpi1.rulingia.com (192.168.123.231): 56 data bytes > 64 bytes from 192.168.123.231: icmp_seq=0 ttl=64 time=19.996 ms > 64 bytes from 192.168.123.231: icmp_seq=1 ttl=64 time=10.306 ms > 64 bytes from 192.168.123.231: icmp_seq=2 ttl=64 time=9.342 ms > 64 bytes from 192.168.123.231: icmp_seq=3 ttl=64 time=8.361 ms > 64 bytes from 192.168.123.231: icmp_seq=4 ttl=64 time=7.365 ms > 64 bytes from 192.168.123.231: icmp_seq=5 ttl=64 time=6.491 ms > 64 bytes from 192.168.123.231: icmp_seq=6 ttl=64 time=5.477 ms > 64 bytes from 192.168.123.231: icmp_seq=7 ttl=64 time=4.507 ms > 64 bytes from 192.168.123.231: icmp_seq=8 ttl=64 time=3.590 ms > 64 bytes from 192.168.123.231: icmp_seq=9 ttl=64 time=2.537 ms > 64 bytes from 192.168.123.231: icmp_seq=10 ttl=64 time=1.627 ms > 64 bytes from 192.168.123.231: icmp_seq=11 ttl=64 time=10.738 ms > 64 bytes from 192.168.123.231: icmp_seq=12 ttl=64 time=9.709 ms > 64 bytes from 192.168.123.231: icmp_seq=13 ttl=64 time=8.708 ms > 64 bytes from 192.168.123.231: icmp_seq=14 ttl=64 time=7.790 ms > 64 bytes from 192.168.123.231: icmp_seq=15 ttl=64 time=6.832 ms > 64 bytes from 192.168.123.231: icmp_seq=16 ttl=64 time=5.853 ms > 64 bytes from 192.168.123.231: icmp_seq=17 ttl=64 time=4.928 ms > 64 bytes from 192.168.123.231: icmp_seq=18 ttl=64 time=2.948 ms > 64 bytes from 192.168.123.231: icmp_seq=19 ttl=64 time=2.027 ms > 64 bytes from 192.168.123.231: icmp_seq=20 ttl=64 time=1.015 ms > 64 bytes from 192.168.123.231: icmp_seq=21 ttl=64 time=10.042 ms > 64 bytes from 192.168.123.231: icmp_seq=22 ttl=64 time=9.156 ms > 64 bytes from 192.168.123.231: icmp_seq=23 ttl=64 time=18.039 ms > 64 bytes from 192.168.123.231: icmp_seq=24 ttl=64 time=7.217 ms > 64 bytes from 192.168.123.231: icmp_seq=25 ttl=64 time=6.196 ms > 64 bytes from 192.168.123.231: icmp_seq=26 ttl=64 time=5.287 ms > 64 bytes from 192.168.123.231: icmp_seq=27 ttl=64 time=4.321 ms > 64 bytes from 192.168.123.231: icmp_seq=28 ttl=64 time=3.350 ms > 64 bytes from 192.168.123.231: icmp_seq=29 ttl=64 time=2.440 ms > 64 bytes from 192.168.123.231: icmp_seq=30 ttl=64 time=1.385 ms > 64 bytes from 192.168.123.231: icmp_seq=31 ttl=64 time=10.386 ms > 64 bytes from 192.168.123.231: icmp_seq=32 ttl=64 time=9.469 ms > 64 bytes from 192.168.123.231: icmp_seq=33 ttl=64 time=8.527 ms > 64 bytes from 192.168.123.231: icmp_seq=34 ttl=64 time=7.161 ms > 64 bytes from 192.168.123.231: icmp_seq=35 ttl=64 time=6.565 ms > 64 bytes from 192.168.123.231: icmp_seq=36 ttl=64 time=5.629 ms > 64 bytes from 192.168.123.231: icmp_seq=37 ttl=64 time=4.205 ms > 64 bytes from 192.168.123.231: icmp_seq=38 ttl=64 time=3.697 ms > 64 bytes from 192.168.123.231: icmp_seq=39 ttl=64 time=2.720 ms > 64 bytes from 192.168.123.231: icmp_seq=40 ttl=64 time=1.748 ms > 64 bytes from 192.168.123.231: icmp_seq=41 ttl=64 time=0.851 ms > 64 bytes from 192.168.123.231: icmp_seq=42 ttl=64 time=9.869 ms > 64 bytes from 192.168.123.231: icmp_seq=43 ttl=64 time=8.913 ms > 64 bytes from 192.168.123.231: icmp_seq=44 ttl=64 time=6.915 ms > 64 bytes from 192.168.123.231: icmp_seq=45 ttl=64 time=4.986 ms > 64 bytes from 192.168.123.231: icmp_seq=46 ttl=64 time=4.045 ms > 64 bytes from 192.168.123.231: icmp_seq=47 ttl=64 time=3.069 ms > 64 bytes from 192.168.123.231: icmp_seq=48 ttl=64 time=2.137 ms > 64 bytes from 192.168.123.231: icmp_seq=49 ttl=64 time=1.168 ms > 64 bytes from 192.168.123.231: icmp_seq=50 ttl=64 time=10.172 ms > 64 bytes from 192.168.123.231: icmp_seq=51 ttl=64 time=9.254 ms > 64 bytes from 192.168.123.231: icmp_seq=52 ttl=64 time=8.272 ms > 64 bytes from 192.168.123.231: icmp_seq=53 ttl=64 time=7.328 ms > 64 bytes from 192.168.123.231: icmp_seq=54 ttl=64 time=6.375 ms > 64 bytes from 192.168.123.231: icmp_seq=55 ttl=64 time=5.390 ms > 64 bytes from 192.168.123.231: icmp_seq=56 ttl=64 time=4.037 ms > 64 bytes from 192.168.123.231: icmp_seq=57 ttl=64 time=3.425 ms > 64 bytes from 192.168.123.231: icmp_seq=58 ttl=64 time=2.435 ms > 64 bytes from 192.168.123.231: icmp_seq=59 ttl=64 time=1.542 ms > 64 bytes from 192.168.123.231: icmp_seq=60 ttl=64 time=10.591 ms > 64 bytes from 192.168.123.231: icmp_seq=61 ttl=64 time=9.581 ms > 64 bytes from 192.168.123.231: icmp_seq=62 ttl=64 time=8.686 ms > 64 bytes from 192.168.123.231: icmp_seq=63 ttl=64 time=7.721 ms > 64 bytes from 192.168.123.231: icmp_seq=64 ttl=64 time=6.804 ms > 64 bytes from 192.168.123.231: icmp_seq=65 ttl=64 time=5.764 ms > 64 bytes from 192.168.123.231: icmp_seq=66 ttl=64 time=4.777 ms > 64 bytes from 192.168.123.231: icmp_seq=67 ttl=64 time=3.857 ms > 64 bytes from 192.168.123.231: icmp_seq=68 ttl=64 time=2.934 ms > 64 bytes from 192.168.123.231: icmp_seq=69 ttl=64 time=0.928 ms > 64 bytes from 192.168.123.231: icmp_seq=70 ttl=64 time=9.007 ms > 64 bytes from 192.168.123.231: icmp_seq=71 ttl=64 time=8.053 ms > 64 bytes from 192.168.123.231: icmp_seq=72 ttl=64 time=7.651 ms > 64 bytes from 192.168.123.231: icmp_seq=73 ttl=64 time=6.105 ms > 64 bytes from 192.168.123.231: icmp_seq=74 ttl=64 time=5.113 ms > 64 bytes from 192.168.123.231: icmp_seq=75 ttl=64 time=4.188 ms > 64 bytes from 192.168.123.231: icmp_seq=76 ttl=64 time=3.270 ms > 64 bytes from 192.168.123.231: icmp_seq=77 ttl=64 time=2.271 ms > 64 bytes from 192.168.123.231: icmp_seq=78 ttl=64 time=1.284 ms > 64 bytes from 192.168.123.231: icmp_seq=79 ttl=64 time=1.263 ms > 64 bytes from 192.168.123.231: icmp_seq=80 ttl=64 time=10.384 ms > 64 bytes from 192.168.123.231: icmp_seq=81 ttl=64 time=9.392 ms > 64 bytes from 192.168.123.231: icmp_seq=82 ttl=64 time=8.461 ms > 64 bytes from 192.168.123.231: icmp_seq=83 ttl=64 time=7.516 ms > 64 bytes from 192.168.123.231: icmp_seq=84 ttl=64 time=6.152 ms > 64 bytes from 192.168.123.231: icmp_seq=85 ttl=64 time=5.575 ms > 64 bytes from 192.168.123.231: icmp_seq=86 ttl=64 time=4.635 ms > 64 bytes from 192.168.123.231: icmp_seq=87 ttl=64 time=3.626 ms > 64 bytes from 192.168.123.231: icmp_seq=88 ttl=64 time=2.728 ms > 64 bytes from 192.168.123.231: icmp_seq=89 ttl=64 time=1.751 ms > 64 bytes from 192.168.123.231: icmp_seq=90 ttl=64 time=0.758 ms > 64 bytes from 192.168.123.231: icmp_seq=91 ttl=64 time=9.798 ms > 64 bytes from 192.168.123.231: icmp_seq=92 ttl=64 time=8.824 ms > 64 bytes from 192.168.123.231: icmp_seq=93 ttl=64 time=7.890 ms > 64 bytes from 192.168.123.231: icmp_seq=94 ttl=64 time=6.932 ms > 64 bytes from 192.168.123.231: icmp_seq=95 ttl=64 time=4.977 ms > 64 bytes from 192.168.123.231: icmp_seq=96 ttl=64 time=4.015 ms > 64 bytes from 192.168.123.231: icmp_seq=97 ttl=64 time=3.049 ms > 64 bytes from 192.168.123.231: icmp_seq=98 ttl=64 time=2.093 ms > 64 bytes from 192.168.123.231: icmp_seq=99 ttl=64 time=1.111 ms > 64 bytes from 192.168.123.231: icmp_seq=100 ttl=64 time=10.213 ms > 64 bytes from 192.168.123.231: icmp_seq=101 ttl=64 time=9.263 ms > 64 bytes from 192.168.123.231: icmp_seq=102 ttl=64 time=8.283 ms > 64 bytes from 192.168.123.231: icmp_seq=103 ttl=64 time=8.312 ms > 64 bytes from 192.168.123.231: icmp_seq=104 ttl=64 time=7.379 ms > 64 bytes from 192.168.123.231: icmp_seq=105 ttl=64 time=6.411 ms > 64 bytes from 192.168.123.231: icmp_seq=106 ttl=64 time=5.409 ms > 64 bytes from 192.168.123.231: icmp_seq=107 ttl=64 time=4.457 ms > 64 bytes from 192.168.123.231: icmp_seq=108 ttl=64 time=3.472 ms > 64 bytes from 192.168.123.231: icmp_seq=109 ttl=64 time=2.561 ms > 64 bytes from 192.168.123.231: icmp_seq=110 ttl=64 time=1.598 ms > 64 bytes from 192.168.123.231: icmp_seq=111 ttl=64 time=10.610 ms > 64 bytes from 192.168.123.231: icmp_seq=112 ttl=64 time=9.636 ms > 64 bytes from 192.168.123.231: icmp_seq=113 ttl=64 time=8.659 ms > 64 bytes from 192.168.123.231: icmp_seq=114 ttl=64 time=7.661 ms > 64 bytes from 192.168.123.231: icmp_seq=115 ttl=64 time=6.762 ms > 64 bytes from 192.168.123.231: icmp_seq=116 ttl=64 time=5.771 ms > 64 bytes from 192.168.123.231: icmp_seq=117 ttl=64 time=4.816 ms > 64 bytes from 192.168.123.231: icmp_seq=118 ttl=64 time=3.888 ms > 64 bytes from 192.168.123.231: icmp_seq=119 ttl=64 time=2.909 ms > 64 bytes from 192.168.123.231: icmp_seq=120 ttl=64 time=0.936 ms > ^C > --- rpi1.rulingia.com ping statistics --- > 121 packets transmitted, 121 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.758/5.921/19.996/3.362 ms > > -- > Peter Jeremy From owner-freebsd-arm@FreeBSD.ORG Wed May 8 10:44:53 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 272D74E1; Wed, 8 May 2013 10:44:53 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id B4869690; Wed, 8 May 2013 10:44:51 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r48AinkI099348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 May 2013 20:44:50 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r48AifGs064020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 20:44:42 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r48AifT6064019; Wed, 8 May 2013 20:44:41 +1000 (EST) (envelope-from peter) Date: Wed, 8 May 2013 20:44:41 +1000 From: Peter Jeremy To: Adrian Chadd Subject: Re: Sawtooth ping RTT on RPi Message-ID: <20130508104441.GC90732@server.rulingia.com> References: <20130508085901.GA90732@server.rulingia.com> <20130508095414.GB90732@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i7F3eY7HS/tUJxUd" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 10:44:53 -0000 --i7F3eY7HS/tUJxUd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-May-08 03:12:43 -0700, Adrian Chadd wrote: >yup, that looks like two almost-but-not-in-sync sampling periods (one >being poll, one being ping) beating against each other. That seems like a reasonable hypothesis. >Is the USB stuff being polled? I'm not sure. I don't think so. dmesg says: dwcotg0: mem 0x20980000-0x2099ffff = irq 17 on simplebus0 usbus0 on dwcotg0 smsc0: on usbus0 ue0: on smsc0 So there's an interrupt available and nothing else is using irq 17. And systat shows that the interrupt rate on irq 17 goes up with network traffic (though it idles at ~500 interrupts/sec - which seems excessive). --=20 Peter Jeremy --i7F3eY7HS/tUJxUd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGKLJkACgkQ/opHv/APuIdq/ACgndhF1asSAun3k5USRo17lIw6 RLkAn0UfZ1QbaC4eAJXYViQuLRRhgcK+ =JVbO -----END PGP SIGNATURE----- --i7F3eY7HS/tUJxUd-- From owner-freebsd-arm@FreeBSD.ORG Wed May 8 11:47:27 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A3C28F7 for ; Wed, 8 May 2013 11:47:27 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id EEE57966 for ; Wed, 8 May 2013 11:47:26 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id D49BAC4927; Wed, 8 May 2013 14:47:18 +0300 (EEST) Date: Wed, 8 May 2013 14:47:18 +0300 From: Aleksandr Rybalko To: Zbyszek Bodek Subject: Re: New PV entry allocator for pmap-v6.c Message-Id: <20130508144718.7ed355d7e0860a1abbe8955b@freebsd.org> In-Reply-To: <518A13D5.9030904@semihalf.com> References: <518545A0.5020107@semihalf.com> <518A13D5.9030904@semihalf.com> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 11:47:27 -0000 On Wed, 08 May 2013 10:59:01 +0200 Zbyszek Bodek wrote: > On 04.05.2013 19:30, Zbyszek Bodek wrote: > > Hello everyone, > > > > As a part of Semihalf work on Superpages support, > > we've made some pmap-v6.c improvements and clean-ups. > > > > We would like to start integrating our code to the mainline FreeBSD, > > therefore I'm happy to introduce the new PV entry allocator for > > pmap-v6.c ported from amd64/i386/mips. > > > > Alan Cox (alc) was so kind to review the code. > > > > If there are no objections, then we will commit this patch to the HEAD > > around Monday/Tuesday. > > > > Please check out the attachment for details. > > > > Hello again, > > Does anyone have any comments and/or remarks regarding the mentioned patch? > > I was testing it on the multicore ARMv7 machine however, it would be > good if someone test it on available ARMv6/ARMv7 platforms. > > Best regards > Zbyszek Bodek > > > _______________________________________________ > 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" Hi Zbyszek! I've not done deep review, but fail to compile it on fresh head: cc -c -O -pipe -march=armv6 -DARM_ARCH_6=1 -std=c99 -g -Wall -Wredundant-decls - Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winli ne -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include -dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empt y-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/home/ray/work/Free BSD/CLEAN/head/sys -I/usr/home/ray/work/FreeBSD/CLEAN/head/sys/contrib/altq -I/u sr/home/ray/work/FreeBSD/CLEAN/head/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_O PTION_HEADERS -include opt_global.h -ffreestanding -Werror /usr/home/ray/work$ FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c /usr/home/ray/work/FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c:908:9: error: no member named 'pvh_attrs' in 'struct md_page' pg->md.pvh_attrs &= ~(maskbits & (PVF_MOD | PVF_REF)); ~~~~~~^ /usr/home/ray/work/FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c:1001:9: error: no member named 'pvh_attrs' in 'struct md_page' pg->md.pvh_attrs |= flags & (PVF_REF | PVF_MOD); ~~~~~~ ^ 18 errors total. Thanks a lot! P.S. how far from full ARM SMP support Semihalf now? WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Wed May 8 12:41:28 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D74879C; Wed, 8 May 2013 12:41:28 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 64C62CC9; Wed, 8 May 2013 12:41:26 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 5D608D6AC1; Wed, 8 May 2013 14:41:24 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 602g22sx70zD; Wed, 8 May 2013 14:41:21 +0200 (CEST) Received: from [10.0.2.117] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 44C1FD5F34; Wed, 8 May 2013 14:41:21 +0200 (CEST) Message-ID: <518A47F0.9020106@semihalf.com> Date: Wed, 08 May 2013 14:41:20 +0200 From: Zbyszek Bodek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Aleksandr Rybalko Subject: Re: New PV entry allocator for pmap-v6.c References: <518545A0.5020107@semihalf.com> <518A13D5.9030904@semihalf.com> <20130508144718.7ed355d7e0860a1abbe8955b@freebsd.org> In-Reply-To: <20130508144718.7ed355d7e0860a1abbe8955b@freebsd.org> Content-Type: multipart/mixed; boundary="------------000202080302010800010605" Cc: freebsd-arm@FreeBSD.org, Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 12:41:28 -0000 This is a multi-part message in MIME format. --------------000202080302010800010605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08.05.2013 13:47, Aleksandr Rybalko wrote: > On Wed, 08 May 2013 10:59:01 +0200 > Zbyszek Bodek wrote: > >> On 04.05.2013 19:30, Zbyszek Bodek wrote: >>> Hello everyone, >>> >>> As a part of Semihalf work on Superpages support, >>> we've made some pmap-v6.c improvements and clean-ups. >>> >>> We would like to start integrating our code to the mainline FreeBSD, >>> therefore I'm happy to introduce the new PV entry allocator for >>> pmap-v6.c ported from amd64/i386/mips. >>> >>> Alan Cox (alc) was so kind to review the code. >>> >>> If there are no objections, then we will commit this patch to the HEAD >>> around Monday/Tuesday. >>> >>> Please check out the attachment for details. >>> >> >> Hello again, >> >> Does anyone have any comments and/or remarks regarding the mentioned patch? >> >> I was testing it on the multicore ARMv7 machine however, it would be >> good if someone test it on available ARMv6/ARMv7 platforms. >> >> Best regards >> Zbyszek Bodek >> >> >> _______________________________________________ >> 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" > > Hi Zbyszek! > > I've not done deep review, but fail to compile it on fresh head: > > cc -c -O -pipe -march=armv6 -DARM_ARCH_6=1 -std=c99 -g -Wall > -Wredundant-decls - Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winli ne -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include -dirs > -fdiagnostics-show-option -Wno-error-tautological-compare > -Wno-error-empt y-body -Wno-error-parentheses-equality -nostdinc -I. > -I/usr/home/ray/work/Free BSD/CLEAN/head/sys > -I/usr/home/ray/work/FreeBSD/CLEAN/head/sys/contrib/altq -I/u > sr/home/ray/work/FreeBSD/CLEAN/head/sys/contrib/libfdt -D_KERNEL > -DHAVE_KERNEL_O PTION_HEADERS -include opt_global.h -ffreestanding > -Werror /usr/home/ray/work$ > FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c /usr/home/ray/work/FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c:908:9: > > error: no member named 'pvh_attrs' in 'struct md_page' pg->md.pvh_attrs > &= ~(maskbits & (PVF_MOD | PVF_REF)); ~~~~~~^ > /usr/home/ray/work/FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c:1001:9: > > error: no member named 'pvh_attrs' in 'struct md_page' pg->md.pvh_attrs > |= flags & (PVF_REF | PVF_MOD); ~~~~~~ ^ > > 18 errors total. > > Thanks a lot! > > P.S. how far from full ARM SMP support Semihalf now? > > WBW > Hello Aleksandr, Thank for pointing that out. This was because we have other changes on our development branch that btw. we intend to post soon. I'm attaching the patch that works for me on the current "vanilla" HEAD. Please send your feedback. Regarding SMP support, then we are able to boot 4-core SMP system. I was stressing the system with multiple, simultaneous build-world (-j5) and it survived overnight tests. We can successfully build kernel, stress testing suit is also working fine. But please be advised that I was mainly focused on tests that might give me basic information about memory operations and I was using only one type of target machine. Best regards Zbyszek Bodek --------------000202080302010800010605 Content-Type: text/x-patch; name="0001-arm-Port-the-new-PV-entry-allocator-from-amd64-i386-.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-arm-Port-the-new-PV-entry-allocator-from-amd64-i386-.pa"; filename*1="tch" >From d9d963b2992a59d9a064f9526853b1df5c305dc4 Mon Sep 17 00:00:00 2001 From: Zbigniew Bodek Date: Fri, 29 Mar 2013 16:16:26 +0100 Subject: [PATCH] arm: Port the new PV entry allocator from amd64/i386/mips PV entries are now roughly half the size. Instead of using a shared UMA zone for 28 byte pv entries (two 8-byte tailq nodes, a 4 byte pointer, a 4 byte address and 4 byte flags), we allocate a page at a time per process. This provides 252 pv entries per process (actually, per pmap address space) and eliminates one of the 8-byte tailq entries since we now can track per-process pv entries implicitly. The pointer to the pmap can be eliminated by doing address arithmetic to find the metadata on the page headers to find a single pointer shared by all 252 entries. There is an 8-int bitmap for the freelist of those 252 entries. When in serious low memory condition, allocation of another pv_chunk is possible by freeing some pages in pmap_pv_reclaim(). Added pv_entry/pv_chunk related statistics to pmap. pv_entry/pv_chunk statistics can be accessed via sysctl vm.pmap. Ported PTE freelist of KVA allocation and maintenance from i386. Using an idea from Stephan Uphoff, use the empty pte's that correspond to the unused kva in the pv memory block to thread a freelist through. This allows us to free pages that used to be used for pv entry chunks since we can now track holes in the kva memory block. As both ARM pmap.c and pmap-v6.c use the same header and pv_entry, pmap and md_page structures are different, it was needed to separate code designed for ARMv6/7 from the one for other ARMs. --- sys/arm/arm/pmap-v6.c | 522 +++++++++++++++++++++++++++++++++++++++++-------- sys/arm/include/pmap.h | 27 ++- sys/conf/options.arm | 1 + 3 files changed, 471 insertions(+), 79 deletions(-) diff --git a/sys/arm/arm/pmap-v6.c b/sys/arm/arm/pmap-v6.c index a1351ed..1174660 100644 --- a/sys/arm/arm/pmap-v6.c +++ b/sys/arm/arm/pmap-v6.c @@ -141,6 +141,7 @@ /* Include header files */ #include "opt_vm.h" +#include "opt_pmap.h" #include __FBSDID("$FreeBSD$"); @@ -158,6 +159,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -193,6 +195,12 @@ int pmap_debug_level = 0; #define PMAP_INLINE __inline #endif /* PMAP_DEBUG */ +#ifdef PV_STATS +#define PV_STAT(x) do { x ; } while (0) +#else +#define PV_STAT(x) do { } while (0) +#endif + #ifdef ARM_L2_PIPT #define pmap_l2cache_wbinv_range(va, pa, size) cpu_l2cache_wbinv_range((pa), (size)) #define pmap_l2cache_inv_range(va, pa, size) cpu_l2cache_inv_range((pa), (size)) @@ -206,8 +214,11 @@ extern struct pv_addr systempage; /* * Internal function prototypes */ -static void pmap_free_pv_entry (pv_entry_t); -static pv_entry_t pmap_get_pv_entry(void); + +static void pmap_free_pv_chunk(struct pv_chunk *pc); +static void pmap_free_pv_entry(pmap_t pmap, pv_entry_t pv); +static pv_entry_t pmap_get_pv_entry(pmap_t pmap, boolean_t try); +static vm_page_t pmap_pv_reclaim(pmap_t locked_pmap); static void pmap_enter_locked(pmap_t, vm_offset_t, vm_page_t, vm_prot_t, boolean_t, int); @@ -386,13 +397,73 @@ int pmap_needs_pte_sync; #define pmap_is_current(pm) ((pm) == pmap_kernel() || \ curproc->p_vmspace->vm_map.pmap == (pm)) -static uma_zone_t pvzone = NULL; + +/* + * Data for the pv entry allocation mechanism + */ +static TAILQ_HEAD(pch, pv_chunk) pv_chunks = TAILQ_HEAD_INITIALIZER(pv_chunks); +static int pv_entry_count, pv_entry_max, pv_entry_high_water; +static int shpgperproc = PMAP_SHPGPERPROC; + +struct pv_chunk *pv_chunkbase; /* KVA block for pv_chunks */ +int pv_maxchunks; /* How many chunks we have KVA for */ +vm_offset_t pv_vafree; /* Freelist stored in the PTE */ + +static __inline struct pv_chunk * +pv_to_chunk(pv_entry_t pv) +{ + + return ((struct pv_chunk *)((uintptr_t)pv & ~(uintptr_t)PAGE_MASK)); +} + +#define PV_PMAP(pv) (pv_to_chunk(pv)->pc_pmap) + +CTASSERT(sizeof(struct pv_chunk) == PAGE_SIZE); +CTASSERT(_NPCM == 8); +CTASSERT(_NPCPV == 252); + +#define PC_FREE0_6 0xfffffffful /* Free values for index 0 through 6 */ +#define PC_FREE7 0x0ffffffful /* Free values for index 7 */ + +static const uint32_t pc_freemask[_NPCM] = { + PC_FREE0_6, PC_FREE0_6, PC_FREE0_6, + PC_FREE0_6, PC_FREE0_6, PC_FREE0_6, + PC_FREE0_6, PC_FREE7 +}; + +static SYSCTL_NODE(_vm, OID_AUTO, pmap, CTLFLAG_RD, 0, "VM/pmap parameters"); + +SYSCTL_INT(_vm_pmap, OID_AUTO, pv_entry_count, CTLFLAG_RD, &pv_entry_count, 0, + "Current number of pv entries"); + +#ifdef PV_STATS +static int pc_chunk_count, pc_chunk_allocs, pc_chunk_frees, pc_chunk_tryfail; + +SYSCTL_INT(_vm_pmap, OID_AUTO, pc_chunk_count, CTLFLAG_RD, &pc_chunk_count, 0, + "Current number of pv entry chunks"); +SYSCTL_INT(_vm_pmap, OID_AUTO, pc_chunk_allocs, CTLFLAG_RD, &pc_chunk_allocs, 0, + "Current number of pv entry chunks allocated"); +SYSCTL_INT(_vm_pmap, OID_AUTO, pc_chunk_frees, CTLFLAG_RD, &pc_chunk_frees, 0, + "Current number of pv entry chunks frees"); +SYSCTL_INT(_vm_pmap, OID_AUTO, pc_chunk_tryfail, CTLFLAG_RD, &pc_chunk_tryfail, 0, + "Number of times tried to get a chunk page but failed."); + +static long pv_entry_frees, pv_entry_allocs; +static int pv_entry_spare; + +SYSCTL_LONG(_vm_pmap, OID_AUTO, pv_entry_frees, CTLFLAG_RD, &pv_entry_frees, 0, + "Current number of pv entry frees"); +SYSCTL_LONG(_vm_pmap, OID_AUTO, pv_entry_allocs, CTLFLAG_RD, &pv_entry_allocs, 0, + "Current number of pv entry allocs"); +SYSCTL_INT(_vm_pmap, OID_AUTO, pv_entry_spare, CTLFLAG_RD, &pv_entry_spare, 0, + "Current number of spare pv entries"); +#endif + uma_zone_t l2zone; static uma_zone_t l2table_zone; static vm_offset_t pmap_kernel_l2dtable_kva; static vm_offset_t pmap_kernel_l2ptp_kva; static vm_paddr_t pmap_kernel_l2ptp_phys; -static int pv_entry_count=0, pv_entry_max=0, pv_entry_high_water=0; static struct rwlock pvh_global_lock; int l1_mem_types[] = { @@ -846,7 +917,7 @@ pmap_clearbit(struct vm_page *pg, u_int maskbits) */ TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) { va = pv->pv_va; - pm = pv->pv_pmap; + pm = PV_PMAP(pv); oflags = pv->pv_flags; pv->pv_flags &= ~maskbits; @@ -923,12 +994,10 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry *pve, pmap_t pm, rw_assert(&pvh_global_lock, RA_WLOCKED); PMAP_ASSERT_LOCKED(pm); - pve->pv_pmap = pm; pve->pv_va = va; pve->pv_flags = flags; TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); - TAILQ_INSERT_HEAD(&pm->pm_pvlist, pve, pv_plist); pg->md.pvh_attrs |= flags & (PVF_REF | PVF_MOD); if (pve->pv_flags & PVF_WIRED) ++pm->pm_stats.wired_count; @@ -948,7 +1017,7 @@ pmap_find_pv(struct vm_page *pg, pmap_t pm, vm_offset_t va) rw_assert(&pvh_global_lock, RA_WLOCKED); TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) - if (pm == pv->pv_pmap && va == pv->pv_va) + if (pm == PV_PMAP(pv) && va == pv->pv_va) break; return (pv); } @@ -1014,7 +1083,6 @@ pmap_nuke_pv(struct vm_page *pg, pmap_t pm, struct pv_entry *pve) PMAP_ASSERT_LOCKED(pm); TAILQ_REMOVE(&pg->md.pv_list, pve, pv_list); - TAILQ_REMOVE(&pm->pm_pvlist, pve, pv_plist); if (pve->pv_flags & PVF_WIRED) --pm->pm_stats.wired_count; @@ -1047,7 +1115,7 @@ pmap_remove_pv(struct vm_page *pg, pmap_t pm, vm_offset_t va) pve = TAILQ_FIRST(&pg->md.pv_list); while (pve) { - if (pve->pv_pmap == pm && pve->pv_va == va) { /* match? */ + if (PV_PMAP(pve) == pm && pve->pv_va == va) { /* match? */ pmap_nuke_pv(pg, pm, pve); break; } @@ -1142,6 +1210,48 @@ pmap_page_init(vm_page_t m) m->md.pv_memattr = VM_MEMATTR_DEFAULT; } +static vm_offset_t +pmap_ptelist_alloc(vm_offset_t *head) +{ + pt_entry_t *pte; + vm_offset_t va; + + va = *head; + if (va == 0) + return (va); /* Out of memory */ + pte = vtopte(va); + *head = *pte; + if ((*head & L2_TYPE_MASK) != L2_TYPE_INV) + panic("%s: va is not L2_TYPE_INV!", __func__); + *pte = 0; + return (va); +} + +static void +pmap_ptelist_free(vm_offset_t *head, vm_offset_t va) +{ + pt_entry_t *pte; + + if ((va & L2_TYPE_MASK) != L2_TYPE_INV) + panic("%s: freeing va that is not L2_TYPE INV!", __func__); + pte = vtopte(va); + *pte = *head; /* virtual! L2_TYPE is L2_TYPE_INV though */ + *head = va; +} + +static void +pmap_ptelist_init(vm_offset_t *head, void *base, int npages) +{ + int i; + vm_offset_t va; + + *head = 0; + for (i = npages - 1; i >= 0; i--) { + va = (vm_offset_t)base + i * PAGE_SIZE; + pmap_ptelist_free(head, va); + } +} + /* * Initialize the pmap module. * Called by vm_init, to initialize any structures that the pmap @@ -1150,7 +1260,6 @@ pmap_page_init(vm_page_t m) void pmap_init(void) { - int shpgperproc = PMAP_SHPGPERPROC; PDEBUG(1, printf("pmap_init: phys_start = %08x\n", PHYSADDR)); @@ -1160,21 +1269,35 @@ pmap_init(void) NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_VM | UMA_ZONE_NOFREE); /* - * Initialize the PV entry allocator. + * Initialize the address space for the pv chunks. */ - pvzone = uma_zcreate("PV ENTRY", sizeof (struct pv_entry), NULL, NULL, - NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_VM | UMA_ZONE_NOFREE); + TUNABLE_INT_FETCH("vm.pmap.shpgperproc", &shpgperproc); pv_entry_max = shpgperproc * maxproc + cnt.v_page_count; - uma_zone_reserve_kva(pvzone, pv_entry_max); + TUNABLE_INT_FETCH("vm.pmap.pv_entries", &pv_entry_max); + pv_entry_max = roundup(pv_entry_max, _NPCPV); pv_entry_high_water = 9 * (pv_entry_max / 10); + pv_maxchunks = MAX(pv_entry_max / _NPCPV, maxproc); + pv_chunkbase = (struct pv_chunk *)kmem_alloc_nofault(kernel_map, + PAGE_SIZE * pv_maxchunks); + + if (pv_chunkbase == NULL) + panic("pmap_init: not enough kvm for pv chunks"); + + pmap_ptelist_init(&pv_vafree, pv_chunkbase, pv_maxchunks); + /* * Now it is safe to enable pv_table recording. */ PDEBUG(1, printf("pmap_init: done!\n")); } +SYSCTL_INT(_vm_pmap, OID_AUTO, pv_entry_max, CTLFLAG_RD, &pv_entry_max, 0, + "Max number of PV entries"); +SYSCTL_INT(_vm_pmap, OID_AUTO, shpgperproc, CTLFLAG_RD, &shpgperproc, 0, + "Page share factor per proc"); + int pmap_fault_fixup(pmap_t pm, vm_offset_t va, vm_prot_t ftype, int user) { @@ -1656,7 +1779,7 @@ pmap_bootstrap(vm_offset_t firstaddr, struct pv_addr *l1pt) PMAP_LOCK_INIT(kernel_pmap); CPU_FILL(&kernel_pmap->pm_active); kernel_pmap->pm_domain = PMAP_DOMAIN_KERNEL; - TAILQ_INIT(&kernel_pmap->pm_pvlist); + TAILQ_INIT(&kernel_pmap->pm_pvchunk); /* * Initialize the global pv list lock. @@ -1924,38 +2047,61 @@ pmap_growkernel(vm_offset_t addr) void pmap_remove_pages(pmap_t pmap) { - struct pv_entry *pv, *npv; - struct l2_bucket *l2b = NULL; - vm_page_t m; - pt_entry_t *pt; - - rw_wlock(&pvh_global_lock); - PMAP_LOCK(pmap); - for (pv = TAILQ_FIRST(&pmap->pm_pvlist); pv; pv = npv) { - if (pv->pv_flags & PVF_WIRED) { - /* Cannot remove wired pages now. */ - npv = TAILQ_NEXT(pv, pv_plist); - continue; + struct pv_entry *pv; + struct l2_bucket *l2b = NULL; + vm_page_t m; + pt_entry_t *pt; + struct pv_chunk *pc, *npc; + uint32_t inuse, bitmask; + int allfree, bit, field, idx; + + rw_wlock(&pvh_global_lock); + PMAP_LOCK(pmap); + + TAILQ_FOREACH_SAFE(pc, &pmap->pm_pvchunk, pc_list, npc) { + allfree = 1; + for (field = 0; field < _NPCM; field++) { + inuse = ~pc->pc_map[field] & pc_freemask[field]; + while (inuse != 0) { + bit = ffs(inuse) - 1; + bitmask = 1ul << bit; + idx = field * sizeof(inuse) * NBBY + bit; + pv = &pc->pc_pventry[idx]; + inuse &= ~bitmask; + if (pv->pv_flags & PVF_WIRED) { + /* Cannot remove wired pages now. */ + allfree = 0; + continue; + } + l2b = pmap_get_l2_bucket(pmap, pv->pv_va); + KASSERT(l2b != NULL, ("No L2 bucket in pmap_remove_pages")); + pt = &l2b->l2b_kva[l2pte_index(pv->pv_va)]; + m = PHYS_TO_VM_PAGE(*pt & L2_ADDR_MASK); + KASSERT((vm_offset_t)m >= KERNBASE, ("Trying to access non-existent page va %x pte %x", pv->pv_va, *pt)); + *pt = 0; + PTE_SYNC(pt); + + /* Mark free */ + PV_STAT(pv_entry_frees++); + PV_STAT(pv_entry_spare++); + pv_entry_count--; + pmap->pm_stats.resident_count--; + pc->pc_map[field] |= bitmask; + pmap_nuke_pv(m, pmap, pv); + pmap_free_l2_bucket(pmap, l2b, 1); + } } - pmap->pm_stats.resident_count--; - l2b = pmap_get_l2_bucket(pmap, pv->pv_va); - KASSERT(l2b != NULL, ("No L2 bucket in pmap_remove_pages")); - pt = &l2b->l2b_kva[l2pte_index(pv->pv_va)]; - m = PHYS_TO_VM_PAGE(*pt & L2_ADDR_MASK); - KASSERT((vm_offset_t)m >= KERNBASE, ("Trying to access non-existent page va %x pte %x", pv->pv_va, *pt)); - *pt = 0; - PTE_SYNC(pt); - npv = TAILQ_NEXT(pv, pv_plist); - pmap_nuke_pv(m, pmap, pv); - if (TAILQ_EMPTY(&m->md.pv_list)) - vm_page_aflag_clear(m, PGA_WRITEABLE); - pmap_free_pv_entry(pv); - pmap_free_l2_bucket(pmap, l2b, 1); + if (allfree) { + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + pmap_free_pv_chunk(pc); + } + } - rw_wunlock(&pvh_global_lock); - cpu_tlb_flushID(); - cpu_cpwait(); - PMAP_UNLOCK(pmap); + + rw_wunlock(&pvh_global_lock); + cpu_tlb_flushID(); + cpu_cpwait(); + PMAP_UNLOCK(pmap); } @@ -2306,6 +2452,7 @@ void pmap_remove_all(vm_page_t m) { pv_entry_t pv; + pmap_t pmap; pt_entry_t *ptep; struct l2_bucket *l2b; boolean_t flush = FALSE; @@ -2320,25 +2467,26 @@ pmap_remove_all(vm_page_t m) rw_wlock(&pvh_global_lock); curpm = vmspace_pmap(curproc->p_vmspace); while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) { - if (flush == FALSE && (pv->pv_pmap == curpm || - pv->pv_pmap == pmap_kernel())) + pmap = PV_PMAP(pv); + if (flush == FALSE && (pmap == curpm || + pmap == pmap_kernel())) flush = TRUE; - PMAP_LOCK(pv->pv_pmap); - l2b = pmap_get_l2_bucket(pv->pv_pmap, pv->pv_va); + PMAP_LOCK(pmap); + l2b = pmap_get_l2_bucket(pmap, pv->pv_va); KASSERT(l2b != NULL, ("No l2 bucket")); ptep = &l2b->l2b_kva[l2pte_index(pv->pv_va)]; if (L2_S_WRITABLE(*ptep)) vm_page_dirty(m); *ptep = 0; - if (pmap_is_current(pv->pv_pmap)) + if (pmap_is_current(pmap)) PTE_SYNC(ptep); - pmap_free_l2_bucket(pv->pv_pmap, l2b, 1); - pv->pv_pmap->pm_stats.resident_count--; + pmap_free_l2_bucket(pmap, l2b, 1); + pmap->pm_stats.resident_count--; flags |= pv->pv_flags; - pmap_nuke_pv(m, pv->pv_pmap, pv); - PMAP_UNLOCK(pv->pv_pmap); - pmap_free_pv_entry(pv); + pmap_nuke_pv(m, pmap, pv); + pmap_free_pv_entry(pmap, pv); + PMAP_UNLOCK(pmap); } m->md.pvh_attrs &= ~(PVF_MOD | PVF_REF); @@ -2694,15 +2842,13 @@ do_l2b_alloc: if ((pve = pmap_remove_pv(opg, pmap, va))) { oflags = pve->pv_flags; - if (m && ((m->oflags & VPO_UNMANAGED))) { - pmap_free_pv_entry(pve); - pve = NULL; - } + if (m && ((m->oflags & VPO_UNMANAGED))) + pmap_free_pv_entry(pmap, pve); } } if ((m && !(m->oflags & VPO_UNMANAGED))) { - if ((!pve) && (pve = pmap_get_pv_entry()) == NULL) + if ((!pve) && (pve = pmap_get_pv_entry(pmap, FALSE)) == NULL) panic("pmap_enter: no pv entries"); KASSERT(va < kmi.clean_sva || va >= kmi.clean_eva, @@ -3024,7 +3170,7 @@ pmap_pinit(pmap_t pmap) CPU_ZERO(&pmap->pm_active); - TAILQ_INIT(&pmap->pm_pvlist); + TAILQ_INIT(&pmap->pm_pvchunk); bzero(&pmap->pm_stats, sizeof pmap->pm_stats); pmap->pm_stats.resident_count = 1; if (vector_page < KERNBASE) { @@ -3040,31 +3186,253 @@ pmap_pinit(pmap_t pmap) * page management routines. ***************************************************/ +/* + * We are in a serious low memory condition. Resort to + * drastic measures to free some pages so we can allocate + * another pv entry chunk. + */ +static vm_page_t +pmap_pv_reclaim(pmap_t locked_pmap) +{ + struct pch newtail; + struct pv_chunk *pc; + struct l2_bucket *l2b = NULL; + pmap_t pmap; + pt_entry_t *pt; + pv_entry_t pv; + vm_offset_t va; + vm_page_t free, m, m_pc; + uint32_t inuse; + int bit, field, freed, idx; + + PMAP_ASSERT_LOCKED(locked_pmap); + pmap = NULL; + free = m_pc = NULL; + TAILQ_INIT(&newtail); + while ((pc = TAILQ_FIRST(&pv_chunks)) != NULL && (pv_vafree == 0 || + free == NULL)) { + TAILQ_REMOVE(&pv_chunks, pc, pc_lru); + if (pmap != pc->pc_pmap) { + if (pmap != NULL) { + cpu_tlb_flushID(); + cpu_cpwait(); + if (pmap != locked_pmap) + PMAP_UNLOCK(pmap); + } + pmap = pc->pc_pmap; + /* Avoid deadlock and lock recursion. */ + if (pmap > locked_pmap) + PMAP_LOCK(pmap); + else if (pmap != locked_pmap && !PMAP_TRYLOCK(pmap)) { + pmap = NULL; + TAILQ_INSERT_TAIL(&newtail, pc, pc_lru); + continue; + } + } + + /* + * Destroy every non-wired, 4 KB page mapping in the chunk. + */ + freed = 0; + for (field = 0; field < _NPCM; field++) { + for (inuse = ~pc->pc_map[field] & pc_freemask[field]; + inuse != 0; inuse &= ~(1UL << bit)) { + bit = ffs(inuse) - 1; + idx = field * sizeof(inuse) * NBBY + bit; + pv = &pc->pc_pventry[idx]; + if (pv->pv_flags & PVF_WIRED) + continue; + + va = pv->pv_va; + l2b = pmap_get_l2_bucket(pmap, va); + KASSERT(l2b != NULL, ("No l2 bucket")); + pt = &l2b->l2b_kva[l2pte_index(va)]; + m = PHYS_TO_VM_PAGE(l2pte_pa(*pt)); + KASSERT((vm_offset_t)m >= KERNBASE, + ("Trying to access non-existent page " + "va %x pte %x in %s", va, *pt)); + *pt = 0; + PTE_SYNC(pt); + pmap_nuke_pv(m, pmap, pv); + pc->pc_map[field] |= 1UL << bit; + freed++; + } + } + if (freed == 0) { + TAILQ_INSERT_TAIL(&newtail, pc, pc_lru); + continue; + } + /* Every freed mapping is for a 4 KB page. */ + pmap->pm_stats.resident_count -= freed; + PV_STAT(pv_entry_frees += freed); + PV_STAT(pv_entry_spare += freed); + pv_entry_count -= freed; + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + for (field = 0; field < _NPCM; field++) + if (pc->pc_map[field] != pc_freemask[field]) { + TAILQ_INSERT_HEAD(&pmap->pm_pvchunk, pc, + pc_list); + TAILQ_INSERT_TAIL(&newtail, pc, pc_lru); + + /* + * One freed pv entry in locked_pmap is + * sufficient. + */ + if (pmap == locked_pmap) + goto out; + break; + } + if (field == _NPCM) { + PV_STAT(pv_entry_spare -= _NPCPV); + PV_STAT(pc_chunk_count--); + PV_STAT(pc_chunk_frees++); + /* Entire chunk is free; return it. */ + m_pc = PHYS_TO_VM_PAGE(pmap_kextract((vm_offset_t)pc)); + pmap_qremove((vm_offset_t)pc, 1); + pmap_ptelist_free(&pv_vafree, (vm_offset_t)pc); + break; + } + } +out: + TAILQ_CONCAT(&pv_chunks, &newtail, pc_lru); + if (pmap != NULL) { + cpu_tlb_flushID(); + cpu_cpwait(); + if (pmap != locked_pmap) + PMAP_UNLOCK(pmap); + } + return (m_pc); +} + +/* + * free the pv_entry back to the free list + */ static void -pmap_free_pv_entry(pv_entry_t pv) +pmap_free_pv_entry(pmap_t pmap, pv_entry_t pv) { + struct pv_chunk *pc; + int bit, field, idx; + + rw_assert(&pvh_global_lock, RA_WLOCKED); + PMAP_ASSERT_LOCKED(pmap); + PV_STAT(pv_entry_frees++); + PV_STAT(pv_entry_spare++); pv_entry_count--; - uma_zfree(pvzone, pv); + pc = pv_to_chunk(pv); + idx = pv - &pc->pc_pventry[0]; + field = idx / (sizeof(u_long) * NBBY); + bit = idx % (sizeof(u_long) * NBBY); + pc->pc_map[field] |= 1ul << bit; + for (idx = 0; idx < _NPCM; idx++) + if (pc->pc_map[idx] != pc_freemask[idx]) { + /* + * 98% of the time, pc is already at the head of the + * list. If it isn't already, move it to the head. + */ + if (__predict_false(TAILQ_FIRST(&pmap->pm_pvchunk) != + pc)) { + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + TAILQ_INSERT_HEAD(&pmap->pm_pvchunk, pc, + pc_list); + } + return; + } + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + pmap_free_pv_chunk(pc); } +static void +pmap_free_pv_chunk(struct pv_chunk *pc) +{ + vm_page_t m; + + TAILQ_REMOVE(&pv_chunks, pc, pc_lru); + PV_STAT(pv_entry_spare -= _NPCPV); + PV_STAT(pc_chunk_count--); + PV_STAT(pc_chunk_frees++); + /* entire chunk is free, return it */ + m = PHYS_TO_VM_PAGE(pmap_kextract((vm_offset_t)pc)); + pmap_qremove((vm_offset_t)pc, 1); + vm_page_unwire(m, 0); + vm_page_free(m); + pmap_ptelist_free(&pv_vafree, (vm_offset_t)pc); + +} -/* - * get a new pv_entry, allocating a block from the system - * when needed. - * the memory allocation is performed bypassing the malloc code - * because of the possibility of allocations at interrupt time. - */ static pv_entry_t -pmap_get_pv_entry(void) +pmap_get_pv_entry(pmap_t pmap, boolean_t try) { - pv_entry_t ret_value; + static const struct timeval printinterval = { 60, 0 }; + static struct timeval lastprint; + struct pv_chunk *pc; + pv_entry_t pv; + vm_page_t m; + int bit, field, idx; + rw_assert(&pvh_global_lock, RA_WLOCKED); + PMAP_ASSERT_LOCKED(pmap); + PV_STAT(pv_entry_allocs++); pv_entry_count++; + if (pv_entry_count > pv_entry_high_water) - pagedaemon_wakeup(); - ret_value = uma_zalloc(pvzone, M_NOWAIT); - return ret_value; + if (ratecheck(&lastprint, &printinterval)) + printf("%s: Approaching the limit on PV entries.\n", + __func__); +retry: + pc = TAILQ_FIRST(&pmap->pm_pvchunk); + if (pc != NULL) { + for (field = 0; field < _NPCM; field++) { + if (pc->pc_map[field]) { + bit = ffs(pc->pc_map[field]) - 1; + break; + } + } + if (field < _NPCM) { + idx = field * sizeof(pc->pc_map[field]) * NBBY + bit; + pv = &pc->pc_pventry[idx]; + pc->pc_map[field] &= ~(1ul << bit); + /* If this was the last item, move it to tail */ + for (field = 0; field < _NPCM; field++) + if (pc->pc_map[field] != 0) { + PV_STAT(pv_entry_spare--); + return (pv); /* not full, return */ + } + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + TAILQ_INSERT_TAIL(&pmap->pm_pvchunk, pc, pc_list); + PV_STAT(pv_entry_spare--); + return (pv); + } + } + /* + * Access to the ptelist "pv_vafree" is synchronized by the pvh + * global lock. If "pv_vafree" is currently non-empty, it will + * remain non-empty until pmap_ptelist_alloc() completes. + */ + if (pv_vafree == 0 || (m = vm_page_alloc(NULL, 0, VM_ALLOC_NORMAL | + VM_ALLOC_NOOBJ | VM_ALLOC_WIRED)) == NULL) { + if (try) { + pv_entry_count--; + PV_STAT(pc_chunk_tryfail++); + return (NULL); + } + m = pmap_pv_reclaim(pmap); + if (m == NULL) + goto retry; + } + PV_STAT(pc_chunk_count++); + PV_STAT(pc_chunk_allocs++); + pc = (struct pv_chunk *)pmap_ptelist_alloc(&pv_vafree); + pmap_qenter((vm_offset_t)pc, &m, 1); + pc->pc_pmap = pmap; + pc->pc_map[0] = pc_freemask[0] & ~1ul; /* preallocated bit 0 */ + for (field = 1; field < _NPCM; field++) + pc->pc_map[field] = pc_freemask[field]; + TAILQ_INSERT_TAIL(&pv_chunks, pc, pc_lru); + pv = &pc->pc_pventry[0]; + TAILQ_INSERT_HEAD(&pmap->pm_pvchunk, pc, pc_list); + PV_STAT(pv_entry_spare += _NPCPV - 1); + return (pv); } /* @@ -3142,7 +3510,7 @@ pmap_remove(pmap_t pm, vm_offset_t sva, vm_offset_t eva) if (pve) { is_exec = PV_BEEN_EXECD(pve->pv_flags); is_refd = PV_BEEN_REFD(pve->pv_flags); - pmap_free_pv_entry(pve); + pmap_free_pv_entry(pm, pve); } } @@ -3385,7 +3753,7 @@ pmap_page_exists_quick(pmap_t pmap, vm_page_t m) rv = FALSE; rw_wlock(&pvh_global_lock); TAILQ_FOREACH(pv, &m->md.pv_list, pv_list) { - if (pv->pv_pmap == pmap) { + if (PV_PMAP(pv) == pmap) { rv = TRUE; break; } diff --git a/sys/arm/include/pmap.h b/sys/arm/include/pmap.h index 1b35ab9..3a4726f 100644 --- a/sys/arm/include/pmap.h +++ b/sys/arm/include/pmap.h @@ -116,6 +116,7 @@ struct pv_addr { }; struct pv_entry; +struct pv_chunk; struct md_page { int pvh_attrs; @@ -152,7 +153,11 @@ struct pmap { pd_entry_t *pm_pdir; /* KVA of page directory */ cpuset_t pm_active; /* active on cpus */ struct pmap_statistics pm_stats; /* pmap statictics */ +#if (ARM_MMU_V6 + ARM_MMU_V7) != 0 + TAILQ_HEAD(,pv_chunk) pm_pvchunk; /* list of mappings in pmap */ +#else TAILQ_HEAD(,pv_entry) pm_pvlist; /* list of mappings in pmap */ +#endif }; typedef struct pmap *pmap_t; @@ -180,13 +185,31 @@ extern struct pmap kernel_pmap_store; * mappings of that page. An entry is a pv_entry_t, the list is pv_list. */ typedef struct pv_entry { - pmap_t pv_pmap; /* pmap where mapping lies */ vm_offset_t pv_va; /* virtual address for mapping */ TAILQ_ENTRY(pv_entry) pv_list; - TAILQ_ENTRY(pv_entry) pv_plist; int pv_flags; /* flags (wired, etc...) */ +#if (ARM_MMU_V6 + ARM_MMU_V7) == 0 + pmap_t pv_pmap; /* pmap where mapping lies */ + TAILQ_ENTRY(pv_entry) pv_plist; +#endif } *pv_entry_t; +/* + * pv_entries are allocated in chunks per-process. This avoids the + * need to track per-pmap assignments. + */ +#define _NPCM 8 +#define _NPCPV 252 + +struct pv_chunk { + pmap_t pc_pmap; + TAILQ_ENTRY(pv_chunk) pc_list; + uint32_t pc_map[_NPCM]; /* bitmap; 1 = free */ + uint32_t pc_dummy[3]; /* aligns pv_chunk to 4KB */ + TAILQ_ENTRY(pv_chunk) pc_lru; + struct pv_entry pc_pventry[_NPCPV]; +}; + #ifdef _KERNEL boolean_t pmap_get_pde_pte(pmap_t, vm_offset_t, pd_entry_t **, pt_entry_t **); diff --git a/sys/conf/options.arm b/sys/conf/options.arm index 37be6f4..70dccf8 100644 --- a/sys/conf/options.arm +++ b/sys/conf/options.arm @@ -36,6 +36,7 @@ LINUX_BOOT_ABI opt_global.h LOADERRAMADDR opt_global.h NO_EVENTTIMERS opt_timer.h PHYSADDR opt_global.h +PV_STATS opt_pmap.h QEMU_WORKAROUNDS opt_global.h SOC_MV_ARMADAXP opt_global.h SOC_MV_DISCOVERY opt_global.h -- 1.8.2 --------------000202080302010800010605-- From owner-freebsd-arm@FreeBSD.ORG Wed May 8 15:01:01 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0BB404EF; Wed, 8 May 2013 15:01:00 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 86DDB5ED; Wed, 8 May 2013 15:01:00 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Ua5rX-000MWt-GF; Wed, 08 May 2013 15:00:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r48F0tlx016921; Wed, 8 May 2013 09:00:56 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/u8sx0FZGFAuAEipDoKF/W Subject: Re: Sawtooth ping RTT on RPi From: Ian Lepore To: Peter Jeremy In-Reply-To: <20130508104441.GC90732@server.rulingia.com> References: <20130508085901.GA90732@server.rulingia.com> <20130508095414.GB90732@server.rulingia.com> <20130508104441.GC90732@server.rulingia.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 May 2013 09:00:55 -0600 Message-ID: <1368025255.1180.200.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 15:01:01 -0000 On Wed, 2013-05-08 at 20:44 +1000, Peter Jeremy wrote: > On 2013-May-08 03:12:43 -0700, Adrian Chadd wrote: > >yup, that looks like two almost-but-not-in-sync sampling periods (one > >being poll, one being ping) beating against each other. > > That seems like a reasonable hypothesis. > > >Is the USB stuff being polled? > > I'm not sure. I don't think so. dmesg says: > > dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 > usbus0 on dwcotg0 > smsc0: on usbus0 > ue0: on smsc0 > > So there's an interrupt available and nothing else is using irq 17. > And systat shows that the interrupt rate on irq 17 goes up with > network traffic (though it idles at ~500 interrupts/sec - which seems > excessive). > Just to make all of this even more confusing, my RPi results always look like this with kern.hz set to one of 100, 500, 1000, 2500: PING revolution.hippie.lan (172.22.42.240): 56 data bytes 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=7.739 ms 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=10.130 ms 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=10.115 ms 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=10.146 ms However, with kern.hz=250, I get this: PING revolution.hippie.lan (172.22.42.240): 56 data bytes 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=5.839 ms 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=8.169 ms 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=8.156 ms 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=8.145 ms And with kern.hz=333, it looks like this: PING revolution.hippie.lan (172.22.42.240): 56 data bytes 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=6.757 ms 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=9.126 ms 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=9.208 ms 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=9.252 ms Very strange. No matter what kern.hz is set to, I always get a shorter time on the first packet, and then after that the variance from one packet to the next is always within about 100us. My other arm systems running -current don't behave like this. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed May 8 19:14:08 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B699A9D; Wed, 8 May 2013 19:14:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id D2A40858; Wed, 8 May 2013 19:14:07 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id n5so2057721wev.25 for ; Wed, 08 May 2013 12:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YThnVooEQ//3KvjBsOMRkmrn2twsUVbnEyxDWuipX9U=; b=TVvRofvp2RyCGpuuNb+UGYr/ma5x0S7WAVPOq+WtY0HaU7TAEZLGNGIZjI+6UmJ9d1 bDa6BHF+/52MQQeQcpNfaWE1t56uE8Wg7+1Rdt3Me6KB94UO0uJNwpquCc2OQEFEbBnT tSTwcrkkpjmQw9YULQHcBkDzkCoAEF9IxvOxGL4HsjqfZ6kqiF0PxumqllgWsRaMUZNe QyV1WtS3NYqLcjXBEP4M/uF2vuyo3/+Zugy51Mo0RPvlarQ9XhueWmD4l0jtQrdB3qwY Pr5ISMiUUXNg7WHnK+PvSiIyRLMOopy/qSh5ywN33xdmbqjN0M+o2TtNR6BaQDJCTN5j qI5Q== MIME-Version: 1.0 X-Received: by 10.194.93.133 with SMTP id cu5mr12998122wjb.56.1368040446957; Wed, 08 May 2013 12:14:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Wed, 8 May 2013 12:14:06 -0700 (PDT) In-Reply-To: <1368025255.1180.200.camel@revolution.hippie.lan> References: <20130508085901.GA90732@server.rulingia.com> <20130508095414.GB90732@server.rulingia.com> <20130508104441.GC90732@server.rulingia.com> <1368025255.1180.200.camel@revolution.hippie.lan> Date: Wed, 8 May 2013 12:14:06 -0700 X-Google-Sender-Auth: 6YaFEfqOSMlxVkHPFlD0bcHqEM4 Message-ID: Subject: Re: Sawtooth ping RTT on RPi From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 08 May 2013 19:14:08 -0000 your other arm systems running -HEAD likely don't have USB ethernet.. :-) Adrian On 8 May 2013 08:00, Ian Lepore wrote: > On Wed, 2013-05-08 at 20:44 +1000, Peter Jeremy wrote: >> On 2013-May-08 03:12:43 -0700, Adrian Chadd wrote: >> >yup, that looks like two almost-but-not-in-sync sampling periods (one >> >being poll, one being ping) beating against each other. >> >> That seems like a reasonable hypothesis. >> >> >Is the USB stuff being polled? >> >> I'm not sure. I don't think so. dmesg says: >> >> dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 >> usbus0 on dwcotg0 >> smsc0: on usbus0 >> ue0: on smsc0 >> >> So there's an interrupt available and nothing else is using irq 17. >> And systat shows that the interrupt rate on irq 17 goes up with >> network traffic (though it idles at ~500 interrupts/sec - which seems >> excessive). >> > > Just to make all of this even more confusing, my RPi results always look > like this with kern.hz set to one of 100, 500, 1000, 2500: > > PING revolution.hippie.lan (172.22.42.240): 56 data bytes > 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=7.739 ms > 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=10.130 ms > 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=10.115 ms > 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=10.146 ms > > However, with kern.hz=250, I get this: > > PING revolution.hippie.lan (172.22.42.240): 56 data bytes > 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=5.839 ms > 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=8.169 ms > 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=8.156 ms > 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=8.145 ms > > And with kern.hz=333, it looks like this: > > PING revolution.hippie.lan (172.22.42.240): 56 data bytes > 64 bytes from 172.22.42.240: icmp_seq=0 ttl=64 time=6.757 ms > 64 bytes from 172.22.42.240: icmp_seq=1 ttl=64 time=9.126 ms > 64 bytes from 172.22.42.240: icmp_seq=2 ttl=64 time=9.208 ms > 64 bytes from 172.22.42.240: icmp_seq=3 ttl=64 time=9.252 ms > > Very strange. No matter what kern.hz is set to, I always get a shorter > time on the first packet, and then after that the variance from one > packet to the next is always within about 100us. > > My other arm systems running -current don't behave like this. > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Fri May 10 01:47:05 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD088B27 for ; Fri, 10 May 2013 01:47:05 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 4C64CFB1 for ; Fri, 10 May 2013 01:47:05 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id z16so1957008ead.41 for ; Thu, 09 May 2013 18:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=GX1JNBvaeP0vwevCEJtPESaWAE5RGYptAdtCU1vNBIs=; b=Ii/n+dOtP9f5KnnHVibaT34DMxLlHCip0b0tJvNzwogNMnJFQcac1R6pswRg8NYEJj vSgIT/lbLyEREivCM8isHpiU/3tokA54RpJPbGdYiQ383ozRq0+aPvrOVWMAT0MEu0BD QfNV8zasyIh8yyBYAJ02hDJXvENuWl7G/PF0SYrNLIDg/WMSzUH/6bRrrhSoz6FWDEQX rY331nPMSCJE1XiSMepyMM/lX7xMjm+G9t5fpF69NnExCtiNJLr5pZQFNBJ0Vxtn/S4K H6kEOBOsT6VxsTKFP4ucms3PquF7CGSLh2JIX8F3BYb78Se8TUaydULwFwRxp1LIflLX 5z9g== MIME-Version: 1.0 X-Received: by 10.14.87.9 with SMTP id x9mr20415193eee.3.1368150424369; Thu, 09 May 2013 18:47:04 -0700 (PDT) Received: by 10.14.130.66 with HTTP; Thu, 9 May 2013 18:47:04 -0700 (PDT) Date: Thu, 9 May 2013 18:47:04 -0700 Message-ID: Subject: Connecting to Beablebone From: hiren panchasara To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 01:47:05 -0000 Hi list, I've built img using crotchet scripts (great work!) a few days back from HEAD and followed instructions at https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack. Now, After powering up I connected the debug USB cable from BB to my laptop (running HEAD). dmesg shows: ugen0.5: at usbus0 umodem0: on usbus0 umodem0: data interface 1, has no CM over data, has no break /dev shows following new entries: crw-rw---- 1 uucp dialer 0x97 May 9 18:13 cuaU0 crw-rw---- 1 uucp dialer 0x98 May 9 18:13 cuaU0.init crw-rw---- 1 uucp dialer 0x99 May 9 18:13 cuaU0.lock crw------- 1 root wheel 0x94 May 9 18:13 ttyU0 crw------- 1 root wheel 0x95 May 9 18:13 ttyU0.init crw------- 1 root wheel 0x96 May 9 18:13 ttyU0.lock lrwxr-xr-x 1 root wheel 9B May 9 18:13 ugen0.5 -> usb/0.5.0 crw-rw-rw- 1 root wheel 0xe May 9 18:11 null crw------- 1 root wheel 0x1b May 9 18:10 bpf Trying to connecting to it: % sudo cu -l /dev/cuaU0 Connected Its stays stuck there without doing anything. Same with ttyU0. Is that not how you connect to this thing? In my quest of understanding /dev entries, I found: ttyU0 is actual tty device and cuaU0 is a callback device? Also, I am not getting those blue usb lights turned on. Not sure if that means something. I am sure I must be doing something really silly. Any help would be great. cheers, Hiren From owner-freebsd-arm@FreeBSD.ORG Fri May 10 01:51:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36661DA2 for ; Fri, 10 May 2013 01:51:48 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 0D975FF2 for ; Fri, 10 May 2013 01:51:48 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id 9so6988036iec.22 for ; Thu, 09 May 2013 18:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8O3SDDwt9BH0LvUzpdYPkqvnEtO03uQjaorOTCTNgRI=; b=qJ9/meGmUCTlOedpxrPIiFAKKfNo8meCCbmRrp/i/AlKucXGHrrF7LVAiDop/jnDC6 SwgHHHcMHKauUnZQyBLkNfwuLGi+aZB5d9yyOBAz6+TNVk0APSSBYYWsLaqkWDcWOgzO l26NrsZr/50TJqaRSKAN5Y9gDuv8yyBZAtD9ELbXRY8oh0lSuCPceqiLB7mNGsBBYxbi Wenil+98j+IRruex3b+q7uraoBYbkIhKEBxJ4PDkTmNXkbs3f8TTaPsmBdwESz93QsX+ bfi7oj0xjzbdASqmLEoV3oWy1DW9j6TbHhfaV2tZgKVMXQ62Aeb1zjwPWAGN2AOpgqU2 tnwQ== MIME-Version: 1.0 X-Received: by 10.50.17.166 with SMTP id p6mr499650igd.12.1368150707806; Thu, 09 May 2013 18:51:47 -0700 (PDT) Received: by 10.64.8.113 with HTTP; Thu, 9 May 2013 18:51:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 May 2013 09:51:47 +0800 Message-ID: Subject: Re: Connecting to Beablebone From: Ganbold Tsagaankhuu To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 01:51:48 -0000 On Fri, May 10, 2013 at 9:47 AM, hiren panchasara < hiren.panchasara@gmail.com> wrote: > Hi list, > > I've built img using crotchet scripts (great work!) a few days back > from HEAD and followed instructions at > https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack. > > Now, > > After powering up I connected the debug USB cable from BB to my laptop > (running HEAD). > > dmesg shows: > > ugen0.5: at usbus0 > umodem0: 5> on usbus0 > umodem0: data interface 1, has no CM over data, has no break > > /dev shows following new entries: > > crw-rw---- 1 uucp dialer 0x97 May 9 18:13 cuaU0 > crw-rw---- 1 uucp dialer 0x98 May 9 18:13 cuaU0.init > crw-rw---- 1 uucp dialer 0x99 May 9 18:13 cuaU0.lock > crw------- 1 root wheel 0x94 May 9 18:13 ttyU0 > crw------- 1 root wheel 0x95 May 9 18:13 ttyU0.init > crw------- 1 root wheel 0x96 May 9 18:13 ttyU0.lock > lrwxr-xr-x 1 root wheel 9B May 9 18:13 ugen0.5 -> usb/0.5.0 > crw-rw-rw- 1 root wheel 0xe May 9 18:11 null > crw------- 1 root wheel 0x1b May 9 18:10 bpf > > Trying to connecting to it: > > % sudo cu -l /dev/cuaU0 > Connected > No need to set speed? Ganbold > > Its stays stuck there without doing anything. Same with ttyU0. Is that > not how you connect to this thing? > > In my quest of understanding /dev entries, I found: ttyU0 is actual > tty device and cuaU0 is a callback device? > > Also, I am not getting those blue usb lights turned on. Not sure if > that means something. > > I am sure I must be doing something really silly. Any help would be great. > > cheers, > Hiren > _______________________________________________ > 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 owner-freebsd-arm@FreeBSD.ORG Fri May 10 02:12:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AABDE18D for ; Fri, 10 May 2013 02:12:16 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 45A2110B for ; Fri, 10 May 2013 02:12:16 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id o10so1879483eaj.36 for ; Thu, 09 May 2013 19:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tFTTb5mSaJpH3H7HDhaa5Kv2kZ72/jLZ2oQVRXY7y+M=; b=UbdDSq0EQWBnmdMzbKzQ9HXESCM/5Ruj/N4lY242ROdZB9OuppwPcGr0Y75xtNFseA YHuPEAobM+fmNBA77YpSvi4/RDqjJpdZJJLKAJR11J5O3OrzSmMva9s1jl/ZJUWgJsFt vhc98+cIhbyG6gc3y+RDL9c7iFACryBiWEQK7Rpt2tLzfW8nC8QE6hABUKiFpLAu2THd Z5CHYc8PLpqcFNOLITQLHBW40mDkOAhPPsrsMAiroF8hCHJkUfZnPC4wJOt3m6f7GzqI WtwYOSxhRHfucU7fFSZCSda82wOVj1I9yZG1Zp8YcEqSltcpPw1+ooflgLdTBVn+Eg2y WHgg== MIME-Version: 1.0 X-Received: by 10.15.52.70 with SMTP id o46mr35970525eew.14.1368151935381; Thu, 09 May 2013 19:12:15 -0700 (PDT) Received: by 10.14.130.66 with HTTP; Thu, 9 May 2013 19:12:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 May 2013 19:12:15 -0700 Message-ID: Subject: Re: Connecting to Beablebone From: hiren panchasara To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 02:12:16 -0000 On Thu, May 9, 2013 at 6:51 PM, Ganbold Tsagaankhuu wrote: > > > > On Fri, May 10, 2013 at 9:47 AM, hiren panchasara > wrote: >> >> Hi list, >> >> I've built img using crotchet scripts (great work!) a few days back >> from HEAD and followed instructions at >> https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack. >> >> Now, >> >> After powering up I connected the debug USB cable from BB to my laptop >> (running HEAD). >> >> dmesg shows: >> >> ugen0.5: at usbus0 >> umodem0: > 5> on usbus0 >> umodem0: data interface 1, has no CM over data, has no break >> >> /dev shows following new entries: >> >> crw-rw---- 1 uucp dialer 0x97 May 9 18:13 cuaU0 >> crw-rw---- 1 uucp dialer 0x98 May 9 18:13 cuaU0.init >> crw-rw---- 1 uucp dialer 0x99 May 9 18:13 cuaU0.lock >> crw------- 1 root wheel 0x94 May 9 18:13 ttyU0 >> crw------- 1 root wheel 0x95 May 9 18:13 ttyU0.init >> crw------- 1 root wheel 0x96 May 9 18:13 ttyU0.lock >> lrwxr-xr-x 1 root wheel 9B May 9 18:13 ugen0.5 -> usb/0.5.0 >> crw-rw-rw- 1 root wheel 0xe May 9 18:11 null >> crw------- 1 root wheel 0x1b May 9 18:10 bpf >> >> Trying to connecting to it: >> >> % sudo cu -l /dev/cuaU0 >> Connected > > > > No need to set speed? This is what I had: % sudo stty -f /dev/ttyU0 speed 9600 baud; lflags: echoe echoke echoctl oflags: tab0 cflags: cs8 -parenb I tried setting to different ones without success: flymockour-l7% sudo stty -f /dev/ttyU0 speed 115200 baud; lflags: -icanon -isig -echo echoe echok echoke echoctl iflags: -icrnl -ixany -imaxbel ignpar oflags: -opost -onlcr tab0 cflags: cs8 -parenb -hupcl clocal Thanks, Hiren > > Ganbold > > >> >> >> Its stays stuck there without doing anything. Same with ttyU0. Is that >> not how you connect to this thing? >> >> In my quest of understanding /dev entries, I found: ttyU0 is actual >> tty device and cuaU0 is a callback device? >> >> Also, I am not getting those blue usb lights turned on. Not sure if >> that means something. >> >> I am sure I must be doing something really silly. Any help would be great. >> >> cheers, >> Hiren >> _______________________________________________ >> 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 owner-freebsd-arm@FreeBSD.ORG Fri May 10 02:42:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A3ED17D8 for ; Fri, 10 May 2013 02:42:44 +0000 (UTC) (envelope-from john@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 82B0821F for ; Fri, 10 May 2013 02:42:44 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 938D1FB21; Thu, 9 May 2013 19:42:43 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 81811-09; Thu, 9 May 2013 19:42:34 -0700 (PDT) Received: from thinkbsd.divinix.org (unknown [10.8.0.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 2000AFB10; Thu, 9 May 2013 19:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1368153754; bh=An2vwtVq2xNqAyx9QTCLh7uJJk8N9yiErP69hMzm1qU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=uxZNtoyH9XiaYjgHQdPaYcM7GmIeUTRlfUfdWMjQ6T0Mf+jniP/ISm4XH4kJ1CWqr f8X2hYlLvkiOdJuCXJAH9hGyITjoKq9JXtJ7tF8j0Hzoj+knBb6aWWuJ7ZhhWI6xVD qEkN2geKNhkf+1O5Nd0KoZdq/3vFQAseo70sT6sI= Date: Thu, 9 May 2013 19:42:32 -0700 From: John Hixson To: hiren panchasara Subject: Re: Connecting to Beablebone Message-ID: <20130510024232.GA10543@thinkbsd.divinix.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 02:42:44 -0000 On Thu, May 09, 2013 at 07:12:15PM -0700, hiren panchasara wrote: > On Thu, May 9, 2013 at 6:51 PM, Ganbold Tsagaankhuu wrote: > > > > > > > > On Fri, May 10, 2013 at 9:47 AM, hiren panchasara > > wrote: > >> > >> Hi list, > >> > >> I've built img using crotchet scripts (great work!) a few days back > >> from HEAD and followed instructions at > >> https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack. > >> > >> Now, > >> > >> After powering up I connected the debug USB cable from BB to my laptop > >> (running HEAD). > >> > >> dmesg shows: > >> > >> ugen0.5: at usbus0 > >> umodem0: >> 5> on usbus0 > >> umodem0: data interface 1, has no CM over data, has no break > >> > >> /dev shows following new entries: > >> > >> crw-rw---- 1 uucp dialer 0x97 May 9 18:13 cuaU0 > >> crw-rw---- 1 uucp dialer 0x98 May 9 18:13 cuaU0.init > >> crw-rw---- 1 uucp dialer 0x99 May 9 18:13 cuaU0.lock > >> crw------- 1 root wheel 0x94 May 9 18:13 ttyU0 > >> crw------- 1 root wheel 0x95 May 9 18:13 ttyU0.init > >> crw------- 1 root wheel 0x96 May 9 18:13 ttyU0.lock > >> lrwxr-xr-x 1 root wheel 9B May 9 18:13 ugen0.5 -> usb/0.5.0 > >> crw-rw-rw- 1 root wheel 0xe May 9 18:11 null > >> crw------- 1 root wheel 0x1b May 9 18:10 bpf > >> > >> Trying to connecting to it: > >> > >> % sudo cu -l /dev/cuaU0 > >> Connected > > > > > > > > No need to set speed? > > This is what I had: > > % sudo stty -f /dev/ttyU0 > speed 9600 baud; > lflags: echoe echoke echoctl > oflags: tab0 > cflags: cs8 -parenb > > I tried setting to different ones without success: > > flymockour-l7% sudo stty -f /dev/ttyU0 > speed 115200 baud; > lflags: -icanon -isig -echo echoe echok echoke echoctl > iflags: -icrnl -ixany -imaxbel ignpar > oflags: -opost -onlcr tab0 > cflags: cs8 -parenb -hupcl clocal > > Thanks, > Hiren > > > > Ganbold > > > > > >> > >> > >> Its stays stuck there without doing anything. Same with ttyU0. Is that > >> not how you connect to this thing? > >> > >> In my quest of understanding /dev entries, I found: ttyU0 is actual > >> tty device and cuaU0 is a callback device? > >> > >> Also, I am not getting those blue usb lights turned on. Not sure if > >> that means something. > >> > >> I am sure I must be doing something really silly. Any help would be great. > >> > >> cheers, > >> Hiren > >> _______________________________________________ I got one of these and it works fine: http://www.adafruit.com/products/954 - John From owner-freebsd-arm@FreeBSD.ORG Fri May 10 03:39:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8FB53B4B for ; Fri, 10 May 2013 03:39:25 +0000 (UTC) (envelope-from contact@ijtemt.org) Received: from Host1.yourdomainname.com (50.22.181.244-static.reverse.softlayer.com [50.22.181.244]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA8F90F for ; Fri, 10 May 2013 03:39:25 +0000 (UTC) X-Sender: "Editor IJTEMT" X-Receiver: freebsd-arm@freebsd.org From: "Editor IJTEMT" To: freebsd-arm@freebsd.org Date: 9 May 2013 20:37:30 -0700 Subject: Call for Papers IJTEMT. Kindly impart in your University/Organization/College/Colleagues/Academia/Circle. Priority: urgent Importance: normal Message-Id: <20130510033925.8FB53B4B@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Editor IJTEMT List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 03:39:25 -0000 INTERNATIONAL JOURNAL OF TRENDS IN ECONOMICS MANAGEMENT & TECHNOLOGY IJTEMT invites you to submit your research paper for publishing in Volume II, Issue II ( June 2013). CALL FOR PAPERS VOLUME II, ISSUE II www.ijtemt.org About IJTEMT International Journal of Trends in Economics Management and Technology (IJTEMT) in an International Academic Journal e-published bimonthly in India and open to the world. In this present interdisciplinary era, here at IJTEMT, a group of intellectual came together to find a common platform for three major components of any economy i.e., Economics, Management and Technology. Here we provide a forum to bridge the gap between the brushed-up professional in their respective fields and the new researcher which will results in better understanding and fruitful outcomes. The focus of this journal is to publish paper on economics management and technology. Submitted papers are reviewed by a full double blind manner by the technical committee of the journal. The audience for the journal is professionals from related fields, academicians and new students & research scholars. All submitted articles should report original, previously unpublished research results, experimental or theoretical, and will be peer-reviewed. Articles submitted to the journal should meet these criteria and must not be under consideration for publication elsewhere. Manuscripts should follow the style of the journal and are subject to both review and editing. Why Select IJTEMT Journal IJTEMT Provides E-Certificates to Author's if Needed.IJTEMT is Globally Approved International Journal having Strong Editorial Board. This is Online Open Journal .Author's can Download Paper from Library of Journal at any Time from Anywhere.IJTEMT is a Association of Eminent Scientist, Researchers and Experienced Members of More than 20 Countries.IJTEMT Publishes High Quality Papers which are Peer Reviewed by International/National Reviewers. Author's Query can be solved within 18 Hours. Subject Category: ECONOMICS, MANAGEMENT & TECHNOLOGY. Important Dates: Paper Submission: 15th May 2013 Review Results (Acceptance/Rejection) Notification: Within two weeks after submitting manuscript. Guidelines for submission and Review Process: IJTEMT welcomes author submission of papers concerning any branch of the economics, management and technology and their applications in business, industry and other subjects relevant. The review process goes through following phases which can take time from ten days to two months: a.. Each manuscript will be initially evaluated by the editorial board / editor, who may make use of appropriate software to examine the originality of the contents of the manuscript. b. The manuscripts passed through screening at above noted level will be forwarded to two referees for blind peer review, each of whom will make a recommendation to publish the article in its present form/edit/reject. During this period referees shall treat the contents of papers under review as privileged information. c. The reviewers' recommendations determine whether a paper will be accepted / accepted subject to change / subject to resubmission with significant changes / rejected. d. For papers which require changes, the same reviewers will be used to ensure that the quality of the revised paper is acceptable. e. All papers are refereed, and the Editor-in-Chief reserves the right to refuse any typescript, whether on invitation or otherwise, and to make suggestions and/or modifications before publication. Submission of Paper will takes place in two phases: a. Initial Paper Submission: Prospective author (s) is/are encouraged to submit their manuscript including charts, tables, figures and appendixes in ..pdf and .doc (both) format to e-mail: [1]submit@ijtemt.org. All submitted articles should report original, previously unpublished research results, experimental or theoretical. Articles submitted to the IJIMT should meet these criteria and must not be under consideration for publication elsewhere. b. Camera Ready Paper Submission:On the acceptance of the paper after completion of the review process the author (s) is/are has to submit camera ready full text paper in .doc and .pdf (both) format to e-mail: [2]submitfinal@ijtemt.org along with the corresponding signed copy of copyright transfer form and scanned copy of payment slip. Publication fees Each accepted paper will be charged, for publication and paper handling, 100 USD per paper (for a maximum of 8 pages, above which 10 USD will be charged for every additional page) which is to be paid as per the instructions mentioned in the letter of acceptance of the manuscript submitted. Editor International Journal of Trends in Economics Management & Technology Website: [3]www.ijtemt.org Email: [4]editor@ijtemt.org, [5]coedtech@ijtemt.org, [6]contact@ijtemt.org. Paper Submission Email: [7]submit@ijtemt.org. References 1. mailto:submit@ijtemt.org 2. mailto:submitfinal@ijtemt.org 3. http://www.ijtemt.org/ 4. mailto:editor@ijtemt.org 5. mailto:coedtech@ijtemt.org 6. mailto:contact@ijtemt.org 7. mailto:submit@ijtemt.org From owner-freebsd-arm@FreeBSD.ORG Fri May 10 04:49:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C99EF22 for ; Fri, 10 May 2013 04:49:16 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C740ACC7 for ; Fri, 10 May 2013 04:49:15 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r4A4n9UN067212; Fri, 10 May 2013 04:49:09 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 32dem44pa6cmvjj59geuhc9k3i; Fri, 10 May 2013 04:49:09 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Connecting to Beablebone Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Thu, 9 May 2013 21:49:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4856F924-8C9B-4F52-8C22-56F808DB7D81@kientzle.com> References: To: hiren panchasara X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 04:49:16 -0000 Which "debug USB cable" do you mean? If you mean you're connecting a USB cable from your laptop to the mini-USB connector on the board (like you would do with the old BeagleBone), that won't work. The new BBBlack no longer has the built-in serial-to-USB adapter. You'll need something like http://www.adafruit.com/products/954 to get a working serial console for the BB Black. (Just look carefully at the picture on that web page to see how to connect it.) Of course, SSH is also an option=85 ;-) Tim On May 9, 2013, at 6:47 PM, hiren panchasara wrote: > Hi list, >=20 > I've built img using crotchet scripts (great work!) a few days back > from HEAD and followed instructions at > https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack. >=20 > Now, >=20 > After powering up I connected the debug USB cable from BB to my laptop > (running HEAD). >=20 > dmesg shows: >=20 > ugen0.5: at usbus0 > umodem0: 5> on usbus0 > umodem0: data interface 1, has no CM over data, has no break >=20 > /dev shows following new entries: >=20 > crw-rw---- 1 uucp dialer 0x97 May 9 18:13 cuaU0 > crw-rw---- 1 uucp dialer 0x98 May 9 18:13 cuaU0.init > crw-rw---- 1 uucp dialer 0x99 May 9 18:13 cuaU0.lock > crw------- 1 root wheel 0x94 May 9 18:13 ttyU0 > crw------- 1 root wheel 0x95 May 9 18:13 ttyU0.init > crw------- 1 root wheel 0x96 May 9 18:13 ttyU0.lock > lrwxr-xr-x 1 root wheel 9B May 9 18:13 ugen0.5 -> = usb/0.5.0 > crw-rw-rw- 1 root wheel 0xe May 9 18:11 null > crw------- 1 root wheel 0x1b May 9 18:10 bpf >=20 > Trying to connecting to it: >=20 > % sudo cu -l /dev/cuaU0 > Connected >=20 > Its stays stuck there without doing anything. Same with ttyU0. Is that > not how you connect to this thing? >=20 > In my quest of understanding /dev entries, I found: ttyU0 is actual > tty device and cuaU0 is a callback device? >=20 > Also, I am not getting those blue usb lights turned on. Not sure if > that means something. >=20 > I am sure I must be doing something really silly. Any help would be = great. >=20 > cheers, > Hiren > _______________________________________________ > 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 owner-freebsd-arm@FreeBSD.ORG Fri May 10 05:17:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5B3D7335 for ; Fri, 10 May 2013 05:17:12 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 205AAD6E for ; Fri, 10 May 2013 05:17:11 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r4A5HAQD067362; Fri, 10 May 2013 05:17:10 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id xaz5abrea4i376vhymdsgbvk4e; Fri, 10 May 2013 05:17:10 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: Is this related to the general panic discussed in freebsd-current? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <20130506124711.23978ec8@bender.lan> Date: Thu, 9 May 2013 22:17:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> <20130506124711.23978ec8@bender.lan> To: Andrew Turner X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 05:17:12 -0000 On May 6, 2013, at 4:47 AM, Andrew Turner wrote: > On Sun, 5 May 2013 22:39:56 -0700 > Tim Kientzle wrote: >> Here's a version of stack_capture that allows a Clang-built >> OABI kernel with WITNESS enabled to boot: >>=20 >> /* In sys/arm/arm/stack_machdep.c */ >> static void >> stack_capture(struct stack *st, u_int32_t *frame) >> { >> vm_offset_t callpc; >>=20 >> stack_zero(st); >> while (INKERNEL(frame)) { >> callpc =3D frame[1]; >> if (stack_put(st, callpc) =3D=3D -1) >> break; >> frame =3D (u_int32_t *)(frame[0]); >> } >> } > It looks like this should work in most cases where fp and lr are next > to each other (ip and sp are between them but doesn't need to be = saved). Disassembling an EABI kernel, there are 7930 'push' instructions with fp and lr next to each other and only 220 without, so it looks like the = EABI kernel uses this frame convention as well. So what do you think of the following? #if defined(__ARM_EABI__) static void stack_capture(struct stack *st, u_int32_t *frame) { vm_offset_t callpc; stack_zero(st); while (INKERNEL(frame)) { callpc =3D frame[1]; if (stack_put(st, callpc) =3D=3D -1) break; frame =3D (u_int32_t *)(frame[0]); } } #elif !defined(__clang__) =85 old stack_capture code that works for OABI with gcc =85 #else /* * Clang doesn't yet produce compliant stack frames for OABI. */ static void stack_capture(=85) { /* empty */ } #endif From owner-freebsd-arm@FreeBSD.ORG Fri May 10 05:20:22 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B986436 for ; Fri, 10 May 2013 05:20:22 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 023EBD95 for ; Fri, 10 May 2013 05:20:21 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id n15so2025517ead.0 for ; Thu, 09 May 2013 22:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=jYetSuXPYtgfWWbwINQnOjqUHp0YYAPmhmFoX4F+hM8=; b=fImRbmXe0oTX26T/e7Vfau9Y7k/mT/NlUrsK6A9NUyyoTWnHG0CfdaaAYs8qYcNQQH Kly3pcTDTPXx/shw4UZ1fgfTtb7CIwDrA+EwymFYCbFpcJDHCikz6nZe3ep+QTomNZvv e/dOtOYnJzYtv41D/tA/RJNzM+kMWm3Z1W47S9nGsFQP3Opt3U7AMTihshtTbihkHWBe PeJUtbE+QDI5sqQxR//MncVM2iXtaRWt5XpK9qKU7ekNGnNNJskVtzQ8NGHf77MByRCX +nVlMlVSEhuZNjQMDEykDTKUqM0W+vbW1kU7QCNFHAwmB9Cfun4/eJDeyV4VJPz+wiVr CWVw== MIME-Version: 1.0 X-Received: by 10.14.126.5 with SMTP id a5mr36849253eei.46.1368163221042; Thu, 09 May 2013 22:20:21 -0700 (PDT) Received: by 10.14.130.66 with HTTP; Thu, 9 May 2013 22:20:20 -0700 (PDT) In-Reply-To: <4856F924-8C9B-4F52-8C22-56F808DB7D81@kientzle.com> References: <4856F924-8C9B-4F52-8C22-56F808DB7D81@kientzle.com> Date: Thu, 9 May 2013 22:20:20 -0700 Message-ID: Subject: Re: Connecting to Beablebone From: hiren panchasara To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 05:20:22 -0000 On Thu, May 9, 2013 at 9:49 PM, Tim Kientzle wrote: > Which "debug USB cable" do you mean? > > If you mean you're connecting a USB cable from your laptop > to the mini-USB connector on the board (like you would do > with the old BeagleBone), that won't work. The new BBBlack > no longer has the built-in serial-to-USB adapter. > > You'll need something like > http://www.adafruit.com/products/954 > to get a working serial console for the BB Black. > (Just look carefully at the picture on that web page to > see how to connect it.) Thanks! Hiren > > Of course, SSH is also an option=E2=80=A6 ;-) > > Tim > > > On May 9, 2013, at 6:47 PM, hiren panchasara wrote: > >> Hi list, >> >> I've built img using crotchet scripts (great work!) a few days back >> from HEAD and followed instructions at >> https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack. >> >> Now, >> >> After powering up I connected the debug USB cable from BB to my laptop >> (running HEAD). >> >> dmesg shows: >> >> ugen0.5: at usbus0 >> umodem0: > 5> on usbus0 >> umodem0: data interface 1, has no CM over data, has no break >> >> /dev shows following new entries: >> >> crw-rw---- 1 uucp dialer 0x97 May 9 18:13 cuaU0 >> crw-rw---- 1 uucp dialer 0x98 May 9 18:13 cuaU0.init >> crw-rw---- 1 uucp dialer 0x99 May 9 18:13 cuaU0.lock >> crw------- 1 root wheel 0x94 May 9 18:13 ttyU0 >> crw------- 1 root wheel 0x95 May 9 18:13 ttyU0.init >> crw------- 1 root wheel 0x96 May 9 18:13 ttyU0.lock >> lrwxr-xr-x 1 root wheel 9B May 9 18:13 ugen0.5 -> usb/0.5.0 >> crw-rw-rw- 1 root wheel 0xe May 9 18:11 null >> crw------- 1 root wheel 0x1b May 9 18:10 bpf >> >> Trying to connecting to it: >> >> % sudo cu -l /dev/cuaU0 >> Connected >> >> Its stays stuck there without doing anything. Same with ttyU0. Is that >> not how you connect to this thing? >> >> In my quest of understanding /dev entries, I found: ttyU0 is actual >> tty device and cuaU0 is a callback device? >> >> Also, I am not getting those blue usb lights turned on. Not sure if >> that means something. >> >> I am sure I must be doing something really silly. Any help would be grea= t. >> >> cheers, >> Hiren >> _______________________________________________ >> 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 owner-freebsd-arm@FreeBSD.ORG Fri May 10 05:22:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF65B4A3 for ; Fri, 10 May 2013 05:22:09 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD45DAF for ; Fri, 10 May 2013 05:22:09 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id q15so57444ead.9 for ; Thu, 09 May 2013 22:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UvuWNbJLY2OmvEFtBZvvkCuC06UgQJSyDgtzUOH21K8=; b=H/ZB4exlLBRyGpQVwM+Fnp3vLORqn+BIB+KwuQas0w++uZjtY2WMI0cPKx1b7WD12q Ku3vQv9rGchuTqbDwQ5uYF+KvLVpHTOiJ0yJ5xSp2PRQ3Um5L1EhFzo7esOPH/BmwAxF 8hu0KWxI83czLcboQnvJ6MTW+yndVvK5rIB2GMSD16p0+4eBMa9aMmjWtzox8y6M5CV6 J2hQoYLPgyJdx7HKP7eIIvSNW/Db4ORT3XRiqysqesanzygQ3+h6g46SBWbxI1FCm2+e 2mOfS1amM5CwSd3wvLZLWSe5ZYuC2z6Wbg+fzQctlLTM6wspNLOKBS1a7TV9ujlRsYFV 8GJA== MIME-Version: 1.0 X-Received: by 10.14.42.9 with SMTP id i9mr37146595eeb.18.1368163328534; Thu, 09 May 2013 22:22:08 -0700 (PDT) Received: by 10.14.130.66 with HTTP; Thu, 9 May 2013 22:22:08 -0700 (PDT) In-Reply-To: <20130510024232.GA10543@thinkbsd.divinix.org> References: <20130510024232.GA10543@thinkbsd.divinix.org> Date: Thu, 9 May 2013 22:22:08 -0700 Message-ID: Subject: Re: Connecting to Beablebone From: hiren panchasara To: John Hixson Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 05:22:09 -0000 On Thu, May 9, 2013 at 7:42 PM, John Hixson wrote: > On Thu, May 09, 2013 at 07:12:15PM -0700, hiren panchasara wrote: >> On Thu, May 9, 2013 at 6:51 PM, Ganbold Tsagaankhuu wrote: >> > >> > >> > >> > On Fri, May 10, 2013 at 9:47 AM, hiren panchasara >> > wrote: >> >> >> >> Hi list, >> >> >> >> I've built img using crotchet scripts (great work!) a few days back >> >> from HEAD and followed instructions at >> >> https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack. >> >> >> >> Now, >> >> >> >> After powering up I connected the debug USB cable from BB to my laptop >> >> (running HEAD). >> >> >> >> dmesg shows: >> >> >> >> ugen0.5: at usbus0 >> >> umodem0: > >> 5> on usbus0 >> >> umodem0: data interface 1, has no CM over data, has no break >> >> >> >> /dev shows following new entries: >> >> >> >> crw-rw---- 1 uucp dialer 0x97 May 9 18:13 cuaU0 >> >> crw-rw---- 1 uucp dialer 0x98 May 9 18:13 cuaU0.init >> >> crw-rw---- 1 uucp dialer 0x99 May 9 18:13 cuaU0.lock >> >> crw------- 1 root wheel 0x94 May 9 18:13 ttyU0 >> >> crw------- 1 root wheel 0x95 May 9 18:13 ttyU0.init >> >> crw------- 1 root wheel 0x96 May 9 18:13 ttyU0.lock >> >> lrwxr-xr-x 1 root wheel 9B May 9 18:13 ugen0.5 -> usb/0.5.0 >> >> crw-rw-rw- 1 root wheel 0xe May 9 18:11 null >> >> crw------- 1 root wheel 0x1b May 9 18:10 bpf >> >> >> >> Trying to connecting to it: >> >> >> >> % sudo cu -l /dev/cuaU0 >> >> Connected >> > >> > >> > >> > No need to set speed? >> >> This is what I had: >> >> % sudo stty -f /dev/ttyU0 >> speed 9600 baud; >> lflags: echoe echoke echoctl >> oflags: tab0 >> cflags: cs8 -parenb >> >> I tried setting to different ones without success: >> >> flymockour-l7% sudo stty -f /dev/ttyU0 >> speed 115200 baud; >> lflags: -icanon -isig -echo echoe echok echoke echoctl >> iflags: -icrnl -ixany -imaxbel ignpar >> oflags: -opost -onlcr tab0 >> cflags: cs8 -parenb -hupcl clocal >> >> Thanks, >> Hiren >> > >> > Ganbold >> > >> > >> >> >> >> >> >> Its stays stuck there without doing anything. Same with ttyU0. Is that >> >> not how you connect to this thing? >> >> >> >> In my quest of understanding /dev entries, I found: ttyU0 is actual >> >> tty device and cuaU0 is a callback device? >> >> >> >> Also, I am not getting those blue usb lights turned on. Not sure if >> >> that means something. >> >> >> >> I am sure I must be doing something really silly. Any help would be great. >> >> >> >> cheers, >> >> Hiren >> >> _______________________________________________ > > > I got one of these and it works fine: > > http://www.adafruit.com/products/954 Thanks John, I guess I am ordering that one :-) cheers, Hiren > > - John From owner-freebsd-arm@FreeBSD.ORG Fri May 10 08:51:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1AE549D0; Fri, 10 May 2013 08:51:57 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id F1142AF4; Fri, 10 May 2013 08:51:56 +0000 (UTC) Received: from bender.lan (46-37-44-135.dsl.cnl.uk.net [46.37.44.135]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id CC5155E1F1; Fri, 10 May 2013 08:51:49 +0000 (UTC) Date: Fri, 10 May 2013 09:51:50 +0100 From: Andrew Turner To: Tim Kientzle Subject: Re: Is this related to the general panic discussed in freebsd-current? Message-ID: <20130510095150.481feca7@bender.lan> In-Reply-To: References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> <20130506124711.23978ec8@bender.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 08:51:57 -0000 On Thu, 9 May 2013 22:17:09 -0700 Tim Kientzle wrote: > > On May 6, 2013, at 4:47 AM, Andrew Turner wrote: > > > On Sun, 5 May 2013 22:39:56 -0700 > > Tim Kientzle wrote: > >> Here's a version of stack_capture that allows a Clang-built > >> OABI kernel with WITNESS enabled to boot: > >> > >> /* In sys/arm/arm/stack_machdep.c */ > >> static void > >> stack_capture(struct stack *st, u_int32_t *frame) > >> { > >> vm_offset_t callpc; > >> > >> stack_zero(st); > >> while (INKERNEL(frame)) { > >> callpc = frame[1]; > >> if (stack_put(st, callpc) == -1) > >> break; > >> frame = (u_int32_t *)(frame[0]); > >> } > >> } > > It looks like this should work in most cases where fp and lr are > > next to each other (ip and sp are between them but doesn't need to > > be saved). > > Disassembling an EABI kernel, there are 7930 'push' instructions with > fp and lr next to each other and only 220 without, so it looks like > the EABI kernel uses this frame convention as well. It looks like this is a product of cang/llvm. There is no mention of the frame pointer that I can find in the EABI documentation and gcc doesn't appear to generate the 'push' instruction with fp. We can't rely on fp being stored or valid on EABI. > So what do you think of the following? I suspect we need to call stack_zero in all cases. I would thing the following would work: static void stack_capture(struct stack *st, u_int32_t *frame) { #if !defined(__ARM_EABI__) && !defined(__clang__) vm_offset_t callpc; #endif stack_zero(st); #if !defined(__ARM_EABI__) && !defined(__clang__) while (1) { if (!INKERNEL(frame)) break; callpc = frame[FR_SCP]; if (stack_put(st, callpc) == -1) break; frame = (u_int32_t *)(frame[FR_RFP]); } #endif } Alternatively the call to stack_zero could be pushed up into the two functions that call stack_capture. Looking at the code it appears stack_save_td also uses the frame pointer to get the stack location, however as this would be unused this is less of an issue. Andrew From owner-freebsd-arm@FreeBSD.ORG Fri May 10 09:17:23 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A276EF9B; Fri, 10 May 2013 09:17:23 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 1A194C3E; Fri, 10 May 2013 09:17:22 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id C1827EBDD9; Fri, 10 May 2013 11:17:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id crom8pw-RZ7S; Fri, 10 May 2013 11:17:20 +0200 (CEST) Received: from [10.0.2.117] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 0E210EBDB4; Fri, 10 May 2013 11:17:19 +0200 (CEST) Message-ID: <518CBB1F.7040408@semihalf.com> Date: Fri, 10 May 2013 11:17:19 +0200 From: Zbyszek Bodek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Aleksandr Rybalko Subject: Re: New PV entry allocator for pmap-v6.c References: <518545A0.5020107@semihalf.com> <518A13D5.9030904@semihalf.com> <20130508144718.7ed355d7e0860a1abbe8955b@freebsd.org> <518A47F0.9020106@semihalf.com> In-Reply-To: <518A47F0.9020106@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 09:17:23 -0000 On 08.05.2013 14:41, Zbyszek Bodek wrote: > On 08.05.2013 13:47, Aleksandr Rybalko wrote: >> On Wed, 08 May 2013 10:59:01 +0200 >> Zbyszek Bodek wrote: >> >>> On 04.05.2013 19:30, Zbyszek Bodek wrote: >>>> Hello everyone, >>>> >>>> As a part of Semihalf work on Superpages support, >>>> we've made some pmap-v6.c improvements and clean-ups. >>>> >>>> We would like to start integrating our code to the mainline FreeBSD, >>>> therefore I'm happy to introduce the new PV entry allocator for >>>> pmap-v6.c ported from amd64/i386/mips. >>>> >>>> Alan Cox (alc) was so kind to review the code. >>>> >>>> If there are no objections, then we will commit this patch to the HEAD >>>> around Monday/Tuesday. >>>> >>>> Please check out the attachment for details. >>>> >>> >>> Hello again, >>> >>> Does anyone have any comments and/or remarks regarding the mentioned >>> patch? >>> >>> I was testing it on the multicore ARMv7 machine however, it would be >>> good if someone test it on available ARMv6/ARMv7 platforms. >>> >>> Best regards >>> Zbyszek Bodek >>> >>> >>> _______________________________________________ >>> 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" >> >> Hi Zbyszek! >> >> I've not done deep review, but fail to compile it on fresh head: >> >> cc -c -O -pipe -march=armv6 -DARM_ARCH_6=1 -std=c99 -g -Wall >> -Wredundant-decls - Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winli ne -Wcast-qual -Wundef >> -Wno-pointer-sign -fformat-extensions -Wmissing-include -dirs >> -fdiagnostics-show-option -Wno-error-tautological-compare >> -Wno-error-empt y-body -Wno-error-parentheses-equality -nostdinc -I. >> -I/usr/home/ray/work/Free BSD/CLEAN/head/sys >> -I/usr/home/ray/work/FreeBSD/CLEAN/head/sys/contrib/altq -I/u >> sr/home/ray/work/FreeBSD/CLEAN/head/sys/contrib/libfdt -D_KERNEL >> -DHAVE_KERNEL_O PTION_HEADERS -include opt_global.h -ffreestanding >> -Werror /usr/home/ray/work$ >> FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c >> /usr/home/ray/work/FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c:908:9: >> >> error: no member named 'pvh_attrs' in 'struct md_page' pg->md.pvh_attrs >> &= ~(maskbits & (PVF_MOD | PVF_REF)); ~~~~~~^ >> /usr/home/ray/work/FreeBSD/CLEAN/head/sys/arm/arm/pmap-v6.c:1001:9: >> >> error: no member named 'pvh_attrs' in 'struct md_page' pg->md.pvh_attrs >> |= flags & (PVF_REF | PVF_MOD); ~~~~~~ ^ >> >> 18 errors total. >> >> Thanks a lot! >> >> P.S. how far from full ARM SMP support Semihalf now? >> >> WBW >> > > Hello Aleksandr, > > Thank for pointing that out. This was because we have other changes on > our development branch that btw. we intend to post soon. > > I'm attaching the patch that works for me on the current "vanilla" HEAD. > Please send your feedback. > > Regarding SMP support, then we are able to boot 4-core SMP system. > I was stressing the system with multiple, simultaneous build-world (-j5) > and it survived overnight tests. We can successfully build kernel, > stress testing suit is also working fine. > But please be advised that I was mainly focused on tests that might give > me basic information about memory operations and I was using only one > type of target machine. > > Best regards > Zbyszek Bodek > > Hello again Aleksandr and everyone, Do you have any update in this topic? Does anyone tried the new patch as has any remarks or findings? Best regards Zbyszek Bodek From owner-freebsd-arm@FreeBSD.ORG Fri May 10 21:30:00 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C9F8B446 for ; Fri, 10 May 2013 21:30:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id AB2FD951 for ; Fri, 10 May 2013 21:30:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4ALU0AQ028874 for ; Fri, 10 May 2013 21:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4ALU0iC028873; Fri, 10 May 2013 21:30:00 GMT (envelope-from gnats) Resent-Date: Fri, 10 May 2013 21:30:00 GMT Resent-Message-Id: <201305102130.r4ALU0iC028873@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, Andreas Schwarz Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 954D23A8 for ; Fri, 10 May 2013 21:25:25 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.FreeBSD.org (oldred.freebsd.org [8.8.178.121]) by mx1.freebsd.org (Postfix) with ESMTP id 875A192E for ; Fri, 10 May 2013 21:25:25 +0000 (UTC) Received: from oldred.FreeBSD.org ([127.0.1.6]) by oldred.FreeBSD.org (8.14.5/8.14.5) with ESMTP id r4ALPOYD020183 for ; Fri, 10 May 2013 21:25:24 GMT (envelope-from nobody@oldred.FreeBSD.org) Received: (from nobody@localhost) by oldred.FreeBSD.org (8.14.5/8.14.5/Submit) id r4ALPOFw020182; Fri, 10 May 2013 21:25:24 GMT (envelope-from nobody) Message-Id: <201305102125.r4ALPOFw020182@oldred.FreeBSD.org> Date: Fri, 10 May 2013 21:25:24 GMT From: Andreas Schwarz To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/178495: buildworld fail on arm/raspberry pi X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 10 May 2013 21:30:00 -0000 >Number: 178495 >Category: arm >Synopsis: buildworld fail on arm/raspberry pi >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: Fri May 10 21:30:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Andreas Schwarz >Release: 10.0-CURRENT >Organization: >Environment: FreeBSD pizelot.schwarzes.net 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Fri May 10 02:30:14 CEST 2013 root@pizelot.schwarzes.net:/usr/obj/usr/src/sys/RPI-B-ASC arm >Description: Building the world fail in the beginning when building llvm. A cross compile at amd64/i386 works without any problems. c++ -O -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"armv6-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp -o APFloat.o Assertion failed: ((PtrVal & ((1 << PtrTraits::NumLowBitsAvailable)-1)) == 0 && "Pointer is not sufficiently aligned"), function initWithPointer, file /usr/home/asc/donotbackup/hardware/Raspberry_Pi/build/src/FreeBSD/head/lib/clang/libclangsema/../../../contrib/llvm/include/llvm/ADT/PointerIntPair.h, line 100. Stack dump: 0. Program arguments: /usr/bin/c++ -cc1 -triple armv6-unknown-freebsd10.0 -S -disable-free -main-file-name APFloat.cpp -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing -mconstructor-aliases -target-abi apcs-gnu -target-cpu arm1136jf-s -msoft-float -mfloat-abi soft -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -coverage-file /tmp/APFloat-fMJVrL.s -resource-dir /usr/bin/../lib/clang/3.3 -D LLVM_ON_UNIX -D LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -D LLVM_DEFAULT_TARGET_TRIPLE="armv6-unknown-freebsd10.0" -D LLVM_HOSTTRIPLE="armv6-unknown-freebsd10.0" -D DEFAULT_SYSROOT="" -I /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I . -I /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -I /usr/obj/usr/src/tmp/legacy/usr/inclu de -O2 -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport -ferror-limit 19 -fmessage-length 101 -mstackrealign -fno-rtti -fno-signed-char -fobjc-runtime=gnustep -fobjc-default-synthesize-properties -fsjlj-exceptions -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/APFloat-fMJVrL.s -x c++ /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp 1. /usr/include/c++/4.2/bits/basic_string.tcc:978:43: current parser token ';' 2. /usr/include/c++/4.2/bits/basic_string.tcc:48:1 : parsing namespace 'std' c++: error: unable to execute command: Abort trap (core dumped) c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.3 (trunk 178860) 20130405 Target: armv6-unknown-freebsd10.0 Thread model: posix c++: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: Error generating preprocessed source(s). *** [APFloat.o] Error code 254 Stop in /usr/src/lib/clang/libllvmsupport. *** [bootstrap-tools] Error code 1 Stop in /usr/src. *** [_bootstrap-tools] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. >How-To-Repeat: cd /usr/src make buildworld >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Fri May 10 23:38:53 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C7E9E74; Fri, 10 May 2013 23:38:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 51A9FE24; Fri, 10 May 2013 23:38:53 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r4ANcqeR062171; Fri, 10 May 2013 23:38:52 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r4ANcqSN062168; Fri, 10 May 2013 23:38:52 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 10 May 2013 23:38:52 GMT Message-Id: <201305102338.r4ANcqSN062168@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:38:53 -0000 TB --- 2013-05-10 23:05:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-05-10 23:05:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-10 23:05:12 - starting RELENG_8 tinderbox run for arm/arm TB --- 2013-05-10 23:05:12 - cleaning the object tree TB --- 2013-05-10 23:05:12 - /usr/local/bin/svn stat /src TB --- 2013-05-10 23:05:15 - At svn revision 250487 TB --- 2013-05-10 23:05:16 - building world TB --- 2013-05-10 23:05:16 - CROSS_BUILD_TESTING=YES TB --- 2013-05-10 23:05:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-10 23:05:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-10 23:05:16 - SRCCONF=/dev/null TB --- 2013-05-10 23:05:16 - TARGET=arm TB --- 2013-05-10 23:05:16 - TARGET_ARCH=arm TB --- 2013-05-10 23:05:16 - TZ=UTC TB --- 2013-05-10 23:05:16 - __MAKE_CONF=/dev/null TB --- 2013-05-10 23:05:16 - cd /src TB --- 2013-05-10 23:05:16 - /usr/bin/make -B buildworld >>> World build started on Fri May 10 23:05:17 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -c /src/usr.sbin/ndp/../../contrib/tcpdump/gmt2local.c cc -O -pipe -I. -I/src/usr.sbin/ndp -I/src/usr.sbin/ndp/../../contrib/tcpdump -D_U_="" -std=gnu99 -o ndp ndp.o gmt2local.o gzip -cn /src/usr.sbin/ndp/ndp.8 > ndp.8.gz ===> usr.sbin/newsyslog (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/newsyslog.c cc1: warnings being treated as errors /src/usr.sbin/newsyslog/newsyslog.c: In function 'delete_oldest_timelog': /src/usr.sbin/newsyslog/newsyslog.c:1511: warning: unused variable 'valid' *** [newsyslog.o] Error code 1 Stop in /src/usr.sbin/newsyslog. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2013-05-10 23:38:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-10 23:38:52 - ERROR: failed to build world TB --- 2013-05-10 23:38:52 - 1672.59 user 375.45 system 2020.77 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat May 11 07:59:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2ACB080D for ; Sat, 11 May 2013 07:59:20 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id B9A1ACFB for ; Sat, 11 May 2013 07:59:19 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id b57so563806eek.31 for ; Sat, 11 May 2013 00:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=NUgGglf0FNFAsoj0iOv9hI5Wm5gfoQ35Xi8OkfxEks4=; b=m/UoqOV2ccD5zZUedWaEQN0EULYuH7O9LQGd41CoEAke7Rq2MUaeDuxDlb39EF3qqG rEZVelSi05T4+ezJ68SUC5n5QCHPj4aeZNYxdG7cnsuvaYT2Uz0TKW8/3K7wLxk2cZy0 pWFBcusJeVqzui7pnnTNKnvOU/S/Y4UQZO8BGoG0+VXP3/5bkXuj5oqHf+5Ap+sltMQN ly6q3InNDe0NPwzfAWw/ug4tdLKFGdX2jdFnS2QAPM2I9V3OadpBAm8x49+AkAZWVKVg 1ApY14bfShCq74qjgwVgI8wlVB5ZTKZ/Iyzr1gvdUlk+piIf0ICwLcE4JPjb4ECHSFz7 j3Bg== MIME-Version: 1.0 X-Received: by 10.15.73.197 with SMTP id h45mr10369874eey.46.1368259158449; Sat, 11 May 2013 00:59:18 -0700 (PDT) Received: by 10.14.130.66 with HTTP; Sat, 11 May 2013 00:59:18 -0700 (PDT) In-Reply-To: References: <20130510024232.GA10543@thinkbsd.divinix.org> Date: Sat, 11 May 2013 00:59:18 -0700 Message-ID: Subject: Re: Connecting to Beablebone From: hiren panchasara To: freebsd-arm , Tim Kientzle Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 07:59:20 -0000 I found one of these: http://www.amazon.com/gp/product/B006JKNWLE/ref=oh_details_o06_s00_i00?ie=UTF8&psc=1 And I've connected it to laptop as shown in: http://www.strugglingcoder.info/pics/bb1.jpg and on beaglebone as shown in: http://www.strugglingcoder.info/pics/bb2.jpg As per the schematic info I derived: Pin 1: GND Pin 4: RX Pin 5: TX I can still not see anything after connecting to "cu -l cuaU0". Am I still missing something? Cheers, Hiren From owner-freebsd-arm@FreeBSD.ORG Sat May 11 16:11:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00944BBD for ; Sat, 11 May 2013 16:11:45 +0000 (UTC) (envelope-from kientzle@acm.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D3D2BE63 for ; Sat, 11 May 2013 16:11:45 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r4BGBdo3079049; Sat, 11 May 2013 16:11:39 GMT (envelope-from kientzle@acm.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 778wyuwr3xh2bqtqxjtptzmxts; Sat, 11 May 2013 16:11:39 +0000 (UTC) (envelope-from kientzle@acm.org) Subject: Re: Connecting to Beablebone Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 11 May 2013 09:11:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130510024232.GA10543@thinkbsd.divinix.org> To: hiren panchasara X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 16:11:46 -0000 On May 11, 2013, at 12:59 AM, hiren panchasara wrote: > I found one of these: > = http://www.amazon.com/gp/product/B006JKNWLE/ref=3Doh_details_o06_s00_i00?i= e=3DUTF8&psc=3D1 >=20 > And I've connected it to laptop as shown in: > http://www.strugglingcoder.info/pics/bb1.jpg > and on beaglebone as shown in: = http://www.strugglingcoder.info/pics/bb2.jpg >=20 > As per the schematic info I derived: > Pin 1: GND > Pin 4: RX > Pin 5: TX >=20 > I can still not see anything after connecting to "cu -l cuaU0". You probably need to set the speed: cu -s 115200 -l cuaU0 Tim From owner-freebsd-arm@FreeBSD.ORG Sat May 11 20:30:07 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CBB45E00 for ; Sat, 11 May 2013 20:30:07 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 650107DD for ; Sat, 11 May 2013 20:30:07 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id o10so2790151eaj.8 for ; Sat, 11 May 2013 13:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tA3US18cPp0TKVP0YXC9RdN4DGc6FyDo4lnI0AGr6UM=; b=S6TwSCU2Ms/6JfcUbhGWdkYklB+0P6RdqLLyqBzegJeZOtnp7+mZNA7UdjU+Yztyho HaltxZqqlokQUNjDFJaVEm6WmQTncBAclOCjV4YuSQD084GVdyx+8Ah7i/tZxqwaDAZ0 HW2pMCb+a+RtuC8KaX5t21m1y7AWaJ/haN898FXdJ4amYkeGkqXhBYWFRtxZdE/VjrnI cwxNwZaa0AjuxGxbJCsKlLPLnLTjuSfvwhJqEv8lU0RFCHxyopXYU1Npe0NvfrhC2jRg 79N9IONGgbIExqyCodmfMUklLl/uXKPulQZSRfbT6ZXFv91MUv010GueM038+sm1ukIs TePg== MIME-Version: 1.0 X-Received: by 10.15.52.70 with SMTP id o46mr58362476eew.14.1368304206472; Sat, 11 May 2013 13:30:06 -0700 (PDT) Received: by 10.14.130.66 with HTTP; Sat, 11 May 2013 13:30:06 -0700 (PDT) In-Reply-To: References: <20130510024232.GA10543@thinkbsd.divinix.org> Date: Sat, 11 May 2013 13:30:06 -0700 Message-ID: Subject: Re: Connecting to Beablebone From: hiren panchasara To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 20:30:07 -0000 On Sat, May 11, 2013 at 9:11 AM, Tim Kientzle wrote: > > On May 11, 2013, at 12:59 AM, hiren panchasara wrote: > >> I found one of these: >> http://www.amazon.com/gp/product/B006JKNWLE/ref=oh_details_o06_s00_i00?ie=UTF8&psc=1 >> >> And I've connected it to laptop as shown in: >> http://www.strugglingcoder.info/pics/bb1.jpg >> and on beaglebone as shown in: http://www.strugglingcoder.info/pics/bb2.jpg >> >> As per the schematic info I derived: >> Pin 1: GND >> Pin 4: RX >> Pin 5: TX >> >> I can still not see anything after connecting to "cu -l cuaU0". > > You probably need to set the speed: > > cu -s 115200 -l cuaU0 Doesn't seem to help. I've been following instructions at https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack Hiren > > Tim > From owner-freebsd-arm@FreeBSD.ORG Sat May 11 22:44:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8821CACD for ; Sat, 11 May 2013 22:44:46 +0000 (UTC) (envelope-from kientzle@acm.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 4B133D81 for ; Sat, 11 May 2013 22:44:45 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r4BMiir1081009; Sat, 11 May 2013 22:44:44 GMT (envelope-from kientzle@acm.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id wsj2hbqg5z2kh3fr3adb7xx9q2; Sat, 11 May 2013 22:44:44 +0000 (UTC) (envelope-from kientzle@acm.org) Subject: Re: Connecting to Beablebone Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 11 May 2013 15:44:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130510024232.GA10543@thinkbsd.divinix.org> To: hiren panchasara X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 22:44:46 -0000 On May 11, 2013, at 1:30 PM, hiren panchasara wrote: > On Sat, May 11, 2013 at 9:11 AM, Tim Kientzle = wrote: >>=20 >> On May 11, 2013, at 12:59 AM, hiren panchasara wrote: >>=20 >>> I found one of these: >>> = http://www.amazon.com/gp/product/B006JKNWLE/ref=3Doh_details_o06_s00_i00?i= e=3DUTF8&psc=3D1 >>>=20 >>> And I've connected it to laptop as shown in: >>> http://www.strugglingcoder.info/pics/bb1.jpg >>> and on beaglebone as shown in: = http://www.strugglingcoder.info/pics/bb2.jpg There's no DNS entry for struggling.dyndns-home.com >>> As per the schematic info I derived: >>> Pin 1: GND >>> Pin 4: RX >>> Pin 5: TX >>>=20 >>> I can still not see anything after connecting to "cu -l cuaU0". >>=20 >> You probably need to set the speed: >>=20 >> cu -s 115200 -l cuaU0 >=20 > Doesn't seem to help. I've been following instructions at > https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack I have noticed with the Adafruit cable that the serial connection sometimes just stops when I reboot or cycle the power. The following seems to reliably restart the serial port: * Leave the serial cable connected. * Remove power from the BBB * Press and hold the boot switch * Plug power back in while holding the boot switch. * Count to three and release the boot switch Finally, of course, are you sure that your cable is supported by your laptop? USB-to-serial adapters seem to be surprisingly variable. Tim