[head tinderbox] failure on i386/i386
TB --- 2012-03-07 07:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-07 07:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-03-07 07:40:00 - cleaning the object tree TB --- 2012-03-07 07:40:18 - cvsupping the source tree TB --- 2012-03-07 07:40:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-03-07 07:40:47 - building world TB --- 2012-03-07 07:40:47 - CROSS_BUILD_TESTING=YES TB --- 2012-03-07 07:40:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-07 07:40:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-07 07:40:47 - SRCCONF=/dev/null TB --- 2012-03-07 07:40:47 - TARGET=i386 TB --- 2012-03-07 07:40:47 - TARGET_ARCH=i386 TB --- 2012-03-07 07:40:47 - TZ=UTC TB --- 2012-03-07 07:40:47 - __MAKE_CONF=/dev/null TB --- 2012-03-07 07:40:47 - cd /src TB --- 2012-03-07 07:40:47 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 7 07:40:47 UTC 2012 >>> 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 Mar 7 09:46:07 UTC 2012 TB --- 2012-03-07 09:46:07 - generating LINT kernel config TB --- 2012-03-07 09:46:07 - cd /src/sys/i386/conf TB --- 2012-03-07 09:46:07 - /usr/bin/make -B LINT TB --- 2012-03-07 09:46:08 - cd /src/sys/i386/conf TB --- 2012-03-07 09:46:08 - /usr/sbin/config -m LINT TB --- 2012-03-07 09:46:08 - building LINT kernel TB --- 2012-03-07 09:46:08 - CROSS_BUILD_TESTING=YES TB --- 2012-03-07 09:46:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-07 09:46:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-07 09:46:08 - SRCCONF=/dev/null TB --- 2012-03-07 09:46:08 - TARGET=i386 TB --- 2012-03-07 09:46:08 - TARGET_ARCH=i386 TB --- 2012-03-07 09:46:08 - TZ=UTC TB --- 2012-03-07 09:46:08 - __MAKE_CONF=/dev/null TB --- 2012-03-07 09:46:08 - cd /src TB --- 2012-03-07 09:46:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 7 09:46:08 UTC 2012 >>> 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 Wed Mar 7 10:17:54 UTC 2012 TB --- 2012-03-07 10:17:54 - cd /src/sys/i386/conf TB --- 2012-03-07 10:17:54 - /usr/sbin/config -m LINT-NOINET TB --- 2012-03-07 10:17:54 - building LINT-NOINET kernel TB --- 2012-03-07 10:17:54 - CROSS_BUILD_TESTING=YES TB --- 2012-03-07 10:17:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-07 10:17:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-07 10:17:54 - SRCCONF=/dev/null TB --- 2012-03-07 10:17:54 - TARGET=i386 TB --- 2012-03-07 10:17:54 - TARGET_ARCH=i386 TB --- 2012-03-07 10:17:54 - TZ=UTC TB --- 2012-03-07 10:17:54 - __MAKE_CONF=/dev/null TB --- 2012-03-07 10:17:54 - cd /src TB --- 2012-03-07 10:17:54 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Mar 7 10:17:54 UTC 2012 >>> 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 Wed Mar 7 10:48:11 UTC 2012 TB --- 2012-03-07 10:48:11 - cd /src/sys/i386/conf TB --- 2012-03-07 10:48:11 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-03-07 10:48:11 - building LINT-NOINET6 kernel TB --- 2012-03-07 10:48:11 - CROSS_BUILD_TESTING=YES TB --- 2012-03-07 10:48:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-07 10:48:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-07 10:48:11 - SRCCONF=/dev/null TB --- 2012-03-07 10:48:11 - TARGET=i386 TB --- 2012-03-07 10:48:11 - TARGET_ARCH=i386 TB --- 2012-03-07 10:48:11 - TZ=UTC TB --- 2012-03-07 10:48:11 - __MAKE_CONF=/dev/null TB --- 2012-03-07 10:48:11 - cd /src TB --- 2012-03-07 10:48:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Mar 7 10:48:11 UTC 2012 >>> 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 Wed Mar 7 11:19:08 UTC 2012 TB --- 2012-03-07 11:19:08 - cd /src/sys/i386/conf TB --- 2012-03-07 11:19:08 - /usr/sbin/config -m LINT-NOIP TB --- 2012-03-07 11:19:08 - building LINT-NOIP kernel TB --- 2012-03-07 11:19:08 - CROSS_BUILD_TESTING=YES TB --- 2012-03-07 11:19:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-07 11:19:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2
Re: Migrating from FreeBSD 9.0-STABLE/amd to 10.0-CURRENT/amd64?
On 03/06/12 20:08, Dimitry Andric wrote: > On 2012-03-06 17:09, O. Hartmann wrote: > ... >> Well, I tried to switch by doing a "svn switch" in /usr/src, building a >> kernel, restarting the kernel in single user mode and then trying to >> build the world. At some point in /usr/src/share (I forgot were exactly, >> it was somewhere with lots of locale stuff), the buildworld process >> fails so I couldn't build a world. > > Try doing a fresh checkout instead. And don't try to build the latest > head with clang, it's unfortunately broken at the moment. Use r232569 > if you want to use clang. Mmmm I still end up here building "buildworld": 5 warnings generated. sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp clang -m32 -c boot2.s clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mllvm -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -m32 -c /usr/src/sys/boot/i386/boot2/sio.S clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=15a1 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e31 text=200 data=1c31 org=0 entry=0 -49 bytes available *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. signature.asc Description: OpenPGP digital signature
Re: patches for if_iwi and wlan for WEP mode
> I'd rather you file a PR first describing what you just did, then > commit the fix and close the PR. OK, I've just submitted a PR. I'll follow the procedure you suggested. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165819 Thanks ___ 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: patches for if_iwi and wlan for WEP mode
> > In RELENG_7, data frame is transmitted by iwi_tx_start() like this. > > > > ether_output > > ether_output_frame > > IFQ_HANDOFF/IFQ_HANDOFF_ADJ > > if_start > > iwi_start > > iwi_tx_start > > > > After 8.0-RELEASE, device specific if_transmit() is called via net80211 > > layer. > > > > ether_output > > ether_output_frame > > if_transmit > > IFQ_HANDOFF/IFQ_HANDOFF_ADJ > > if_start > > ieee80211_start > > parent->if_transmit(ie. iwi_transmit()) > > > > There was not if_transmit method in iwi(4), so I add it. > > On if_qflush(), CURRENT kernel complains that `transmit and qflush > > must both either be set or both be NULL' from if.c. > > I wrote iwi_qflush(), but actually never tested it... > > Hmm, it still is the case for >= 8 afaik, there is a default > if_transmit() which is used for all wireless drivers which seems to > work pretty well. That's why I'm wondering, iwi(4) would be the first > driver to have it's own if_transmit() function. I'm not aware of any > technical reason for adding one, or did I miss something? If not I'd > rather not have one added, for sake of consistency. By your this comment, I noticed that my understanding on iwi_start() call stack > 8.0 was wrong a bit, correct one is like this; ether_output ether_output_frame if_transmit IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start ieee80211_start parent->if_transmit(ie. if_transmit()) IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start iwi_start iwi_start_locked iwi_tx_start So iwi_transmit and iwi_qflush would not be necessary. Today's version of patches at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120307.diff This would be the final version I hope. Thanks! ___ 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: patches for if_iwi and wlan for WEP mode
Hi, I'd rather you didn't commit iwi_update_mcast() unless you absolutely know that the NIC doesn't need to be notified of multicast group membership changes. If so, please commit that as a separate fix. I'll look at iwi later and give you feedback on that particular change. Thanks for chasing this down! 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: x220 notes
On 03/07/2012 01:25, Любомир Григоров wrote: I will be buying a X220 soon and have some questions: 1. Which wireless has better support? ThinkPad 11b/g/n Wireless (Realtek RTL8192SE / RTL8188CE) Intel Centrino Wireless-N 1000 2. I've read bad reviews about webcam having poor quality on GNU/Linux, so I would assume it will be the same on FreeBSD with webcamd and not worth the $30? (which also frees up space for 3x3 antenna) 3. Any disadvantages in usage for turning off the UEFI? 4. How far is the AMD64 kernel suspend/resume? What do you mean by video doesn't resume? 5. I'll be getting the IPS screen and want to make sure all the brightness issues won't f it up. Is there yet a working way to control brightness without interrupting the fan? Hi Любомир, i'll be answering the 1,2 questions from my experience with the X220: I bought my X220 with the Realtek wireless and the webcam. I tried running -CURRENT a couple of months ago, (just after the bump to 10-CURRENT) but the wifi was a no-go, so yeah, I'd suggest getting the intel adapter too. As for the camera, I've been running Arch linux, and the performance (resolution, refresh rate) have been fine, as far as I know at least. I've used it for some skype conferencing and it worked fine. No flickering, no issues at all. Without knowing about the webcamd compatibility of the specific model, I am happy about choosing the camera instead of the antenna, as I never have any problems connecting to my access point, even when I am far away with 4-5 walls in between. As for the rest, I can't comment on, as I did not install freebsd at all, and as such I did not test the other parts. The wireless was a big issue for me you see. just my 0.02$ -vid ___ 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: patches for if_iwi and wlan for WEP mode
On Wednesday 07 March 2012 16:38:44 Mitsuru IWASAKI wrote: > So iwi_transmit and iwi_qflush would not be necessary. correct > Today's version of patches at: > http://people.freebsd.org/~iwasaki/iwi/iwi-20120307.diff > > This would be the final version I hope. I gave it a quick spin, works for me. You can add "Tested/Reviewed by: bschmidt" if you like. Thanks! -- Bernhard ___ 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: patches for if_iwi and wlan for WEP mode
On Tuesday 06 March 2012 21:12:55 Adrian Chadd wrote: > .. except that the default if_transmit handling breaks fragments. Sigh. > > So we're going to have to implement if_transmit for all net80211 > drivers soon and fix fragment handling. Not saying that you are wrong, it is unrelated to the issue at hand though and I'm not even sure it can be fixed just by replacing if_transmit(). Anyways, a bug going unnoticed for 3 years or something isn't that high on my priority list. -- Bernhard ___ 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: patches for if_iwi and wlan for WEP mode
On 7 March 2012 11:17, Bernhard Schmidt wrote: > On Tuesday 06 March 2012 21:12:55 Adrian Chadd wrote: >> .. except that the default if_transmit handling breaks fragments. Sigh. >> >> So we're going to have to implement if_transmit for all net80211 >> drivers soon and fix fragment handling. > > Not saying that you are wrong, it is unrelated to the issue at hand > though and I'm not even sure it can be fixed just by replacing > if_transmit(). Anyways, a bug going unnoticed for 3 years or something > isn't that high on my priority list. Oh, it's absolutely not a requirement here. It was more a comment that he didn't need to implement if_transmit just yet in order to fix this bug, but it's likely a good idea moving forward. I have recently acquired an iwi(4) NIC so I'll also test this out. Don't let me stop you though. :) 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: patches for if_iwi and wlan for WEP mode
On Wednesday 07 March 2012 19:45:11 Adrian Chadd wrote: > Hi, > > I'd rather you didn't commit iwi_update_mcast() unless you absolutely > know that the NIC doesn't need to be notified of multicast group > membership changes. If so, please commit that as a separate fix. Oh well, iwi(4) receives multicast frames just fine, they are discarded somewhere else though last time I've checked, another offtopic issue ;) > I'll look at iwi later and give you feedback on that particular change. I did look into this once for ipw it was I guess, the firmware doesn't support filtering based on addresses so everything one could achieve here is enable/disable filtering of all multicast frames. Check iwi_configuration.enable_multicast_filtering, which is a bool actually not an uint8_t. -- Bernhard ___ 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: patches for if_iwi and wlan for WEP mode
It's on topic because he included that in his patch. :) Adrian Sent from my Palm Pre on AT&T On Mar 7, 2012 12:18 PM, Bernhard Schmidtwrote: On Wednesday 07 March 2012 19:45:11 Adrian Chadd wrote: > Hi, > > I'd rather you didn't commit iwi_update_mcast() unless you absolutely > know that the NIC doesn't need to be notified of multicast group > membership changes. If so, please commit that as a separate fix. Oh well, iwi(4) receives multicast frames just fine, they are discarded somewhere else though last time I've checked, another offtopic issue ;) > I'll look at iwi later and give you feedback on that particular change. I did look into this once for ipw it was I guess, the firmware doesn't support filtering based on addresses so everything one could achieve here is enable/disable filtering of all multicast frames. Check iwi_configuration.enable_multicast_filtering, which is a bool actually not an uint8_t. -- Bernhard ___ 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: boot2 overflow when building with clang
>From sources csup'ed this morning, I have the same problem. Is there a fix for folks that don't use SVN? -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ 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: boot2 overflow when building with clang
On 2012-03-07 20:36, Derek Tattersall wrote: >>From sources csup'ed this morning, I have the same problem. > Is there a fix for folks that don't use SVN? Assuming you are using CVS, use: "cvs up -r 1.99 sys/boot/i386/boot2/boot2.c" ___ 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: add k3772z 3g modem support for FreeBSD-9
Hi! Would you please submit this as a PR? That way it Doesn't get (as) lost. Thanks! adrian On 6 March 2012 16:53, Oliver Pinter wrote: > Hi all! > > I wrote a patch, to add support for Vodafone K3772-Z 3g modem. > > -- > Oliver Pinter > (Tresorium) > > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ 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: add k3772z 3g modem support for FreeBSD-9
Hi! usb/165815 On 3/7/12, Adrian Chadd wrote: > Hi! > > Would you please submit this as a PR? > > That way it Doesn't get (as) lost. > > Thanks! > > > adrian > > On 6 March 2012 16:53, Oliver Pinter wrote: >> Hi all! >> >> I wrote a patch, to add support for Vodafone K3772-Z 3g modem. >> >> -- >> Oliver Pinter >> (Tresorium) >> >> ___ >> freebsd-sta...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ > 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" > ___ 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: boot2 overflow when building with clang
On Tuesday 06 March 2012 11:51 pm, Jia-Shiun Li wrote: > I am not familiar with boot2, but it looks like allocated size for > boot2 is not enough to hold code generated by clang. Reverting > r232570 fixes it. > > ===> sys/boot/i386/boot2 (all) > objcopy -S -O binary boot1.out boot1 > dd if=/dev/zero of=boot2.ldr bs=512 count=1 > clang -Os -fno-guess-branch-probability -fomit-frame-pointer > -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 > -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 > -DSIOFMT=0x3 -DSIOSPD=9600 > -I/usr/src/sys/boot/i386/boot2/../../common > -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall > -Waggregate-return -Wbad-function-cast -Wcast-align > -Wmissing-declarations -Wmissing-prototypes -Wnested-externs > -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings > -Winline --param max-inline-insns-single=100 -mllvm > -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm > -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float > -std=gnu99-S -o boot2.s.tmp > /usr/src/sys/boot/i386/boot2/boot2.c > sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s > rm -f boot2.s.tmp > clang -c boot2.s > clang -Os -fno-guess-branch-probability -fomit-frame-pointer > -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 > -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 > -DSIOFMT=0x3 -DSIOSPD=9600 > -I/usr/src/sys/boot/i386/boot2/../../common > -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall > -Waggregate-return -Wbad-function-cast -Wcast-align > -Wmissing-declarations -Wmissing-prototypes -Wnested-externs > -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings > -Winline --param max-inline-insns-single=100 -mllvm > -stack-alignment=8 -mllvm -inline-threshold=3 -mllvm > -enable-load-pre=false -ffreestanding -mpreferred-stack-boundary=2 > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float > -std=gnu99 -c > /usr/src/sys/boot/i386/boot2/sio.S > ld -static -N --gc-sections -nostdlib -Ttext 0x2000 -o boot2.out > /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o > sio.o objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b > /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr > -o boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=15a1 text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1e31 text=200 data=1c31 org=0 entry=0 > -49 bytes available > *** [boot2] Error code 1 > > Stop in /usr/src/sys/boot/i386/boot2. > *** [all] Error code 1 > > Stop in /usr/src/sys/boot/i386. > *** [all] Error code 1 > > Stop in /usr/src/sys/boot. > *** [all] Error code 1 > > Stop in /usr/src/sys. > *** [sys.all__D] Error code 1 > > Stop in /usr/src. > *** [everything] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. Here is a patch to work around the problem: http://people.freebsd.org/~jkim/boot2.diff Please note this patch creates two separate boot codes, one for UFS1 and one for UFS2. To generate previous boot code (i.e., UFS1+UFS2) with GCC, clean objects, add the following line to your /etc/make.conf, rebuild, and install: BOOT2_UFS=UFS1_AND_UFS2 Cheers, Jung-uk Kim Index: sys/boot/i386/Makefile === --- sys/boot/i386/Makefile (revision 232670) +++ sys/boot/i386/Makefile (working copy) @@ -2,8 +2,8 @@ .include -SUBDIR=mbr pmbr boot0 boot0sio btx boot2 cdboot gptboot kgzldr \ - libi386 libfirewire loader +SUBDIR=mbr pmbr boot0 boot0sio btx boot2 boot2ufs1 cdboot gptboot \ + kgzldr libi386 libfirewire loader # special boot programs, 'self-extracting boot2+loader' SUBDIR+= pxeldr Index: sys/boot/i386/boot2/Makefile === --- sys/boot/i386/boot2/Makefile(revision 232670) +++ sys/boot/i386/boot2/Makefile(working copy) @@ -2,8 +2,10 @@ .include -FILES= boot boot1 boot2 +FILES= boot${BOOT_SUFFIX} boot2${BOOT2_SUFFIX} +SRCDIR=${.CURDIR}/../boot2 + NM?= nm # A value of 0x80 enables LBA support. @@ -18,10 +20,22 @@ ORG1= 0x7c00 ORG2= 0x2000 # Decide level of UFS support. -BOOT2_UFS?=UFS1_AND_UFS2 -#BOOT2_UFS?= UFS2_ONLY -#BOOT2_UFS?= UFS1_ONLY +BOOT2_UFS?=UFS2_ONLY +#BOOT2_UFS?= UFS1_AND_UFS2 +.if ${BOOT2_UFS} != UFS1_ONLY +FILES+=boot1 +.endif +.if ${BOOT2_UFS} == UFS1_ONLY +BOOT_SUFFIX= .ufs1 +BOOT2_SUFFIX= ufs1 +.elif ${BOOT2_UFS} == UFS2_ONLY +BOOT_SUFFIX= .ufs2 +BOOT2_SUFFIX= ufs2 +LINKS= ${BINDIR}/boot${BOOT_SUFFIX} ${BINDIR}/boot \ + ${BINDIR}/boot2${BOOT2_SUFFIX} ${BINDIR}/boot2 +.endif + CFLAGS=-Os \ -fno-guess-branch-probability
Re: Processes getting stuck in state tmpfs
On 01.03.2012 23:25, Florian Smeets wrote: On 01.03.12 20:31, Gleb Kurtsou wrote: Could you test the patch attached. It's also available here as seperate commits: https://github.com/glk/freebsd-head/commits/tmpfs-rename The test that used to hang within a minute has now been running successfully for almost 2 hours. Looks good to me. I have also re-enabled tmpfs on redports.org main tinderbox with this patch applied and it runs smooth so far! Very good work. Thanks a lot! FreeBSD tb3.bluelife.at 10.0-CURRENT FreeBSD 10.0-CURRENT #3: Wed Mar 7 23:47:56 CET 2012 r...@tb3.bluelife.at:/usr/obj/usr/src/sys/GENERIC amd64 -- Bernhard Froehlich http://www.bluelife.at/ ___ 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: Processes getting stuck in state tmpfs
On (08/03/2012 01:20), Bernhard Froehlich wrote: > On 01.03.2012 23:25, Florian Smeets wrote: > > On 01.03.12 20:31, Gleb Kurtsou wrote: > >> Could you test the patch attached. > >> > >> It's also available here as seperate commits: > >> https://github.com/glk/freebsd-head/commits/tmpfs-rename > >> > > > > The test that used to hang within a minute has now been running > > successfully for almost 2 hours. > > > > Looks good to me. > > I have also re-enabled tmpfs on redports.org main tinderbox with > this patch applied and it runs smooth so far! Very good work. > Thanks a lot! Thanks, Patch is under review now. And will be committed afterwards. > > FreeBSD tb3.bluelife.at 10.0-CURRENT FreeBSD 10.0-CURRENT #3: Wed Mar > 7 23:47:56 CET 2012 > r...@tb3.bluelife.at:/usr/obj/usr/src/sys/GENERIC amd64 > > -- > Bernhard Froehlich > http://www.bluelife.at/ ___ 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"