[head tinderbox] failure on amd64/amd64
TB --- 2013-04-09 00:40:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-09 00:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-09 00:40:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-04-09 00:40:18 - cleaning the object tree TB --- 2013-04-09 00:40:18 - /usr/local/bin/svn stat /src TB --- 2013-04-09 00:40:22 - At svn revision 249291 TB --- 2013-04-09 00:40:23 - building world TB --- 2013-04-09 00:40:23 - CROSS_BUILD_TESTING=YES TB --- 2013-04-09 00:40:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-09 00:40:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-09 00:40:23 - SRCCONF=/dev/null TB --- 2013-04-09 00:40:23 - TARGET=amd64 TB --- 2013-04-09 00:40:23 - TARGET_ARCH=amd64 TB --- 2013-04-09 00:40:23 - TZ=UTC TB --- 2013-04-09 00:40:23 - __MAKE_CONF=/dev/null TB --- 2013-04-09 00:40:23 - cd /src TB --- 2013-04-09 00:40:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Apr 9 00:40:28 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Apr 9 04:00:24 UTC 2013 TB --- 2013-04-09 04:00:24 - generating LINT kernel config TB --- 2013-04-09 04:00:24 - cd /src/sys/amd64/conf TB --- 2013-04-09 04:00:24 - /usr/bin/make -B LINT TB --- 2013-04-09 04:00:24 - cd /src/sys/amd64/conf TB --- 2013-04-09 04:00:24 - /usr/sbin/config -m LINT TB --- 2013-04-09 04:00:24 - building LINT kernel TB --- 2013-04-09 04:00:24 - CROSS_BUILD_TESTING=YES TB --- 2013-04-09 04:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-09 04:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-09 04:00:24 - SRCCONF=/dev/null TB --- 2013-04-09 04:00:24 - TARGET=amd64 TB --- 2013-04-09 04:00:24 - TARGET_ARCH=amd64 TB --- 2013-04-09 04:00:24 - TZ=UTC TB --- 2013-04-09 04:00:24 - __MAKE_CONF=/dev/null TB --- 2013-04-09 04:00:24 - cd /src TB --- 2013-04-09 04:00:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 9 04:00: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 >>> Kernel build for LINT completed on Tue Apr 9 04:29:45 UTC 2013 TB --- 2013-04-09 04:29:45 - cd /src/sys/amd64/conf TB --- 2013-04-09 04:29:45 - /usr/sbin/config -m LINT-NOINET TB --- 2013-04-09 04:29:45 - building LINT-NOINET kernel TB --- 2013-04-09 04:29:45 - CROSS_BUILD_TESTING=YES TB --- 2013-04-09 04:29:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-09 04:29:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-09 04:29:45 - SRCCONF=/dev/null TB --- 2013-04-09 04:29:45 - TARGET=amd64 TB --- 2013-04-09 04:29:45 - TARGET_ARCH=amd64 TB --- 2013-04-09 04:29:45 - TZ=UTC TB --- 2013-04-09 04:29:45 - __MAKE_CONF=/dev/null TB --- 2013-04-09 04:29:45 - cd /src TB --- 2013-04-09 04:29:45 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Apr 9 04:29:45 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 >>> Kernel build for LINT-NOINET completed on Tue Apr 9 04:57:50 UTC 2013 TB --- 2013-04-09 04:57:50 - cd /src/sys/amd64/conf TB --- 2013-04-09 04:57:50 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-04-09 04:57:50 - building LINT-NOINET6 kernel TB --- 2013-04-09 04:57:50 - CROSS_BUILD_TESTING=YES TB --- 2013-04-09 04:57:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-09 04:57:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-09 04:57:50 - SRCCONF=/dev/null TB --- 2013-04-09 04:57:50 - TARGET=amd64 TB --- 2013-04-09 04:57:50 - TARGET_ARCH=amd64 TB --- 2013-04-09 04:57:50 - TZ=UTC TB --- 2013-04-09 04:57:50 - __MAKE_CONF=/dev/null TB --- 2013-04-09 04:57:50 - cd /src TB --- 2013-04-09 04:57:50 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Apr 9 04:57:50 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 >>> Kernel build for LINT-NOINET6 completed on Tue Apr 9 05:26:13 UTC 2013 TB --- 2013-04-09 05:26:13 - cd /src/sys/amd64/conf TB --- 2013-04-09 05:26:13 - /usr/sbin/confi
[head tinderbox] failure on i386/i386
TB --- 2013-04-09 00:40:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-09 00:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-09 00:40:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-04-09 00:40:18 - cleaning the object tree TB --- 2013-04-09 00:40:18 - /usr/local/bin/svn stat /src TB --- 2013-04-09 00:40:22 - At svn revision 249291 TB --- 2013-04-09 00:40:23 - building world TB --- 2013-04-09 00:40:23 - CROSS_BUILD_TESTING=YES TB --- 2013-04-09 00:40:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-09 00:40:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-09 00:40:23 - SRCCONF=/dev/null TB --- 2013-04-09 00:40:23 - TARGET=i386 TB --- 2013-04-09 00:40:23 - TARGET_ARCH=i386 TB --- 2013-04-09 00:40:23 - TZ=UTC TB --- 2013-04-09 00:40:23 - __MAKE_CONF=/dev/null TB --- 2013-04-09 00:40:23 - cd /src TB --- 2013-04-09 00:40:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Apr 9 00:40:28 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 Apr 9 03:26:01 UTC 2013 TB --- 2013-04-09 03:26:01 - generating LINT kernel config TB --- 2013-04-09 03:26:01 - cd /src/sys/i386/conf TB --- 2013-04-09 03:26:01 - /usr/bin/make -B LINT TB --- 2013-04-09 03:26:01 - cd /src/sys/i386/conf TB --- 2013-04-09 03:26:01 - /usr/sbin/config -m LINT TB --- 2013-04-09 03:26:01 - building LINT kernel TB --- 2013-04-09 03:26:01 - CROSS_BUILD_TESTING=YES TB --- 2013-04-09 03:26:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-09 03:26:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-09 03:26:01 - SRCCONF=/dev/null TB --- 2013-04-09 03:26:01 - TARGET=i386 TB --- 2013-04-09 03:26:01 - TARGET_ARCH=i386 TB --- 2013-04-09 03:26:01 - TZ=UTC TB --- 2013-04-09 03:26:01 - __MAKE_CONF=/dev/null TB --- 2013-04-09 03:26:01 - cd /src TB --- 2013-04-09 03:26:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 9 03:26:01 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 >>> Kernel build for LINT completed on Tue Apr 9 03:57:28 UTC 2013 TB --- 2013-04-09 03:57:28 - cd /src/sys/i386/conf TB --- 2013-04-09 03:57:28 - /usr/sbin/config -m LINT-NOINET TB --- 2013-04-09 03:57:28 - building LINT-NOINET kernel TB --- 2013-04-09 03:57:28 - CROSS_BUILD_TESTING=YES TB --- 2013-04-09 03:57:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-09 03:57:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-09 03:57:28 - SRCCONF=/dev/null TB --- 2013-04-09 03:57:28 - TARGET=i386 TB --- 2013-04-09 03:57:28 - TARGET_ARCH=i386 TB --- 2013-04-09 03:57:28 - TZ=UTC TB --- 2013-04-09 03:57:28 - __MAKE_CONF=/dev/null TB --- 2013-04-09 03:57:28 - cd /src TB --- 2013-04-09 03:57:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Apr 9 03:57:28 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 >>> Kernel build for LINT-NOINET completed on Tue Apr 9 04:26:12 UTC 2013 TB --- 2013-04-09 04:26:12 - cd /src/sys/i386/conf TB --- 2013-04-09 04:26:12 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-04-09 04:26:12 - building LINT-NOINET6 kernel TB --- 2013-04-09 04:26:12 - CROSS_BUILD_TESTING=YES TB --- 2013-04-09 04:26:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-09 04:26:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-09 04:26:12 - SRCCONF=/dev/null TB --- 2013-04-09 04:26:12 - TARGET=i386 TB --- 2013-04-09 04:26:12 - TARGET_ARCH=i386 TB --- 2013-04-09 04:26:12 - TZ=UTC TB --- 2013-04-09 04:26:12 - __MAKE_CONF=/dev/null TB --- 2013-04-09 04:26:12 - cd /src TB --- 2013-04-09 04:26:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Apr 9 04:26:12 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 >>> Kernel build for LINT-NOINET6 completed on Tue Apr 9 04:56:03 UTC 2013 TB --- 2013-04-09 04:56:03 - cd /src/sys/i386/conf TB --- 2013-04-09 04:56:03 - /usr/sbin/config -m LINT-NOIP TB --- 2013-04-09 04:56:03 - building LINT-NOI
Re: rebooting nvidia + keyboard issues
On Mon, 08 Apr 2013 05:52:31 -0700, Sean Bruno wrote: > >patch was applied yesterday-ish to ports. > >Sean > > Awesome thanks for the info, trying it out now. thought it was the .32 patches. I didn't realize it's the updated 310.44 driver. -- Waitman Gobble San Jose California USA +1.5108307875 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel output interleaved on boot
.. assuming you stay _on_ that CPU for the entirety of your runtime and you don't yield and get rescheduled on another CPU. Just saying. adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problems with axe(4) and checksum offloading
Hi YongHyeon, output from verbose boot ugen3.2: at usbus3 axe0: on usbus3 axe0: PHYADDR 0xe0:0x10 miibus1: on axe0 ukphy0: PHY 16 on miibus1 ukphy0: OUI 0x007063, model 0x0008, rev. 1 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow ue0: on axe0 ue0: bpf attached ue0: Ethernet address: 00:60:6e:42:5b:53 ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP Apart from what I originally described... Networking does work, but not when packets pass through ipfw and nat. If I add my ipfw rules before the divert natd rule networking works as expected, without the SYN,ACK response packets are not accepted if I e.g. connect to something on the axe interface. I have validated the ipfw ruleset with the onboard realtek NIC and it then works as expected. # usbconfig -u 3 -a 2 dump_info ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) Kind regards, Spil. On Mon, Apr 8, 2013 at 8:35 AM, YongHyeon PYUN wrote: > On Sun, Apr 07, 2013 at 09:14:16PM +0200, Spil Oss wrote: > > Hi all, > > > > With checksum offloading enabled I cannot use my axe NIC (ASIX AX88772B). > > > > ifconfig ue0 -txcsum -rxcsum > > will make dhclient ue0 return > > > > if I re-enable txcsum and rxcsum I get an immediate response from the > dhcp > > server. > > > > Tried to remove the csum features by commenting out > > ifp->if_capabilities |= IFCAP_TXCSUM | IFCAP_RXCSUM; > > ifp->if_hwassist = AXE_CSUM_FEATURES; > > (lines 855 and 856 in /usr/src/sys/dev/usb/net/if_axe.c) > > and rebuild the module. This does remove RXCSUM and TXCSUM from options > and > > behaves the same as disabling the features with ifconfig (i.e. does not > > work) > > > > 10.0-CURRENT r248351 > > > > Hope someone can help me... Spil. > > Last time I tried, checksum offloading worked as expected. > Would you show me the verbose dmesg output after attaching the > axe(4) NIC? > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel output interleaved on boot
I have discussed this problem for years now -- over 5 years, to be exact. As if I haven't sounded like a broken record before, I surely do now. Start here, under section "Kernel", item "Scrambled or garbled kernel output": https://wiki.freebsd.org/BugBusting/Commonly_reported_issues The problem has not gone away. It has not been solved. It has not been worked around. PRINTF_BUFR_SIZE does not solve the problem, and rarely helps relieve it. I have discussed this issue more recently (2010) with John Baldwin as well: http://lists.freebsd.org/pipermail/freebsd-questions/2010-March/214412.html http://lists.freebsd.org/pipermail/freebsd-questions/2010-March/214423.html And in December 2011 too -- particularly an important read if you think increasing the number is a wise idea: http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/065158.html Bottom line: there is no solution other than to switch OSes. And yes, I am aware of how GSoC works, but this really should have become a GSoC project by now, otherwise the Foundation should have funded someone to fix this. It makes kernel debugging basically worthless. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RE: rebooting nvidia + keyboard issues
On Wed, 2013-04-03 at 11:07 -0700, Adrian Chadd wrote: > Hi, > > can you guys please ensure a PR is filed with all the information > you've just included? > > the clang team would likely love to have this much information in a bug > report. > > Thanks! > > > > adrian > I've started a p/r for this as I get 100% reproducible panics on boot with clang compiled nvidia-driver at the point of "entropy harvesting" I'll get an actual panic string in a moment. Sean http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177710 signature.asc Description: This is a digitally signed message part
Re: rebooting nvidia + keyboard issues
On Sun, 2013-03-31 at 00:25 -0700, Waitman Gobble wrote: > I noticed the machine rebooting randomly every 20 seconds to 5 > minutes. Disabling the nvidia driver seems to fix the problem, and I > was able to update after applying ports/177459 patch. The updated > nvidia driver seems to have solved the rebooting issue. (it could > (also?) be related to linux.ko?) If people are using the nvidia driver > and are experiencing a constant reboot issue, it might be good to pop > in that patch ASAP patch was applied yesterday-ish to ports. Sean signature.asc Description: This is a digitally signed message part
X220 note: crash at shutdown -p now
Hi, I noticed frequent crashes when i power off my X220. I got used to it until I did some reboots without a single crash. I shut down the machine with shutdown -p now uname says: FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #23: Sat Feb 23 17:24:19 WIT 2013 er...@x220.ovitrap.com:/usr/obj/usr/src/sys/X220 amd64 I noticed that very often, the file /boot/loader.conf is empty when the machine is started again later. Is there a way I could help to find the source of the problem? Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel output interleaved on boot
On 04/07/2013 23:20, Andreas Nilsson wrote:
On Sun, Apr 7, 2013 at 9:36 PM, deeptech71 mailto:deeptec...@gmail.com>> wrote:
options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed.
And here I thought that it was added to mitigate the "interspersed output"
problem, and I remember that adding to the conf on previous version help address the
problem.
And you were right. AFAICT, the problem was that the threads were writing single
characters ("putc()ing") at a time, and would get preempted by other such
threads in between. Thus, such tasks would get interleaved at character granularity.
Proposals were:
(a) use a stack array in printf()'s body to do line buffering; some argued
that kernel stack sizes are fairly limited, others argued that this should not
be a limitation even on embedded platforms;
(b) allow a printf() task to fully finish before allowing other printf()
tasks to start.
The (a) solution was chosen, with an amendment that the array would be specifiable by a
kernel configuration option. GENERIC kernels have "options
PRINTF_BUFR_SIZE=128".
If the original poster had removed the PRINTF_BUFR_SIZE option from his kernel
configuration, then I see his complaint as invalid.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel output interleaved on boot
Hello, Jeremy. You wrote 8 апреля 2013 г., 8:52:37: JC> And yes, I am aware of how GSoC works, but this really should have JC> become a GSoC project by now, otherwise the Foundation should have JC> funded someone to fix this. It makes kernel debugging basically JC> worthless. Ok, here is several noob questions about low-level kernel implementation: (1) Do we have some very low-level thread-local variables, which could be used here? (2) Do cpu-local variables helps here? Is here guarantee, that printf() could not be preempted (I afraid, answer is no)? (3) What is lowest level, which could call printf()? i.e., could printf() allocate, say, one page of mapped kernel memory (I hope, answer is yes)? Init UMA zone and allocate block in UMA zone (I think, answer is no)? What I want to say, that lock-less (and block-less) multiple-writers ring buffer is "possible" data structure, as far as I know (we use lock-less and block-less data structures a lot at work for massive-parallel programming, but not at such low level, of course), but I need to understand, what printf() could and what couldn't do. I understand, that it could not use any lock, as it is called from anywhere, but should be it limited to stack and/or static data structures? And, by the way, is here generic mechanism in kernel (loader?), which automatically (on load) allocate per-CPU static structures? And why output is garbaged, if printf() uses _stack_ based buffer, at first place?! Stack is thread-local by definition! -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel D2500CC motherboard and strange RS232/UART behavior
Hello, Poul-Henning. You wrote 8 апреля 2013 г., 0:15:01: >>It doesn't look so. And uart1 and uart3 doesn't have interrupt >>according to `vmstat -i' (but share irq4 according to boot messages). PHK> Ohh, there you go... I'll try to turn off uart2 and uart3 in BIOS and give different IRQs to uart0 and uart1. Fortunately, I don't need ALL of them. PHK> Interrupt sharing on ISA requires special magic... But it will be nice to fix this, and I could provide any informaton and debugging I can, but I need to know hwere to start. -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
