Re: geli(8) breaks after a couple hours of uptime
Pawel Jakub Dawidek p...@freebsd.org wrote: On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote: I think that PAGE_SIZE (or at most a small multiple of it) should be sufficient. I don't think that we currently have (or expect to see in the near future) algorithms where keys with more than 4096 size provide any additional security. geli(8) deals just fine with files that are larger than buffers, so even with smaller buffer it can read the data in few steps. The proposed patch is here if someone would like to give it a try: http://people.freebsd.org/~pjd/patches/geom_eli.c.patch Works for me, thanks a lot. I tested with a couple of geli providers ranging from v3 AES-CBC 128 bit to v7 AES-XTS 256 bit and didn't get any crashes. Fabian signature.asc Description: PGP signature
Re: 7+ days of dogfood
Steve Kargl s...@troutmask.apl.washington.edu wrote: In a long thread started by Peter Wemm on developers@, he described the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10. A part of his description included the need to test top-of-tree under actual real-world conditions. In his words, FreeBSD should eat its own dogfood. The new installation on FreeBSD.org, of course, would test FreeBSD-10 under (heavy) server load. Sounds like an interesting thread, too bad that it happened behind closed doors. Unfortunately, trying to build firefox with debugging leads reveals a broken port and building chrome with debugging leads to a file system full issue (because it is a laptop with only limited disk space). I usually build everything (except the known-to-be-broken png) with debugging and while Firefox indeed seems to crash even more often than usual the port isn't completely broken for me. I disable some of the more crash-prone options, though. The remaining crashes mostly happen upon exit so they are easy to ignore. While I have the space to save the core dumps my system is too slow to conveniently look at them with gdb and I have given up on Firefox anyway. I intend to deflect to chromium once I find a more powerful replacement for my current (pun intended) laptop. My conclusion: on at least my not-so-new laptop, FreeBSD-10 can be used in a desktop environment if one takes some care during the installation. I'm using CURRENT on my also-no-so-new laptop since FreeBSD 7 (I think) and came to the same conclusion. It's unfortunate that the builworld time roughly trippled since 2010 but I guess that's progress and a more powerful system should fix it. I certainly welcome clang in general, though. Fabian signature.asc Description: PGP signature
on amd64 r246552: iwn0: Intel Wireless WiFi Link 4965: fatal firmware error
This is a T61p 6459 laptop with (from pciconf -lv): iwn0@pci0:3:0:0:class=0x028000 card=0x11108086 chip=0x42308086 rev=0x61 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 4965 AG or AGN [Kedron] Network Connection' class = network or (from dmesg): iwn0: Intel Wireless WiFi Link 4965 mem 0xdf2fe000-0xdf2f irq 17 at device 0.0 on pci3 I use it with device iwn # Intel 4965/1000/5000/6000 wireless NICs. device iwn4965fw in the kernel. From time to time, and I think under some load, e.g. rsync a partition in one windown and svn up /usr/ports in another, I get this failure: iwn0: iwn_intr: fatal firmware error firmware error log: error type = NMI_INTERRUPT_WDG (0x0004) program counter = 0x046C source line = 0x00D0 error data = 0x00020703 branch link = 0x837004C2 interrupt link = 0x06DA18B8 time= 2858416859 driver status: tx ring 0: qid=0 cur=96 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=16 queued=0 tx ring 4: qid=4 cur=163 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 rx ring: cur=14 I then have to restart the network via /etc/rc.d/netif restart and it's back to normal. From ifconfig: iwn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:21:5c:50:68:c3 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:21:5c:50:68:c3 inet 172.21.222.82 netmask 0xfc00 broadcast 255.255.255.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g status: associated ssid eduroam channel 1 (2412 MHz 11g) bssid 00:3a:98:62:cd:a0 country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 14 bmiss 10 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL I use it with wpa_supplicant: /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant.conf -D bsd -P /var/run/wpa_supplicant/wlan0.pid Please advise Thanks Anton ___ 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: on amd64 r246552: iwn0: Intel Wireless WiFi Link 4965: fatal firmware error
Yesterday I had something similar - it was cause by a radio switch flip: iwn0: RF switch: radio disabled ubt0: ubt_bulk_read_callback:867: bulk-in transfer failed: USB_ERR_STALLED ubt0: ubt_intr_read_callback:767: interrupt transfer failed: USB_ERR_STALLED ugen1.4: Dell Computer Corp at usbus1 (disconnected) ubt0: at uhub3, port 7, addr 4 (disconnected) iwn0: iwn_intr: fatal firmware error firmware error log: error type = SYSASSERT (0x0005) program counter = 0x0001EFD8 source line = 0x012E error data = 0x branch link = 0x0001EEE40001EEE4 interrupt link = 0x1532 time= 767402829 driver status: tx ring 0: qid=0 cur=194 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=18 queued=0 tx ring 4: qid=4 cur=58 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=1 FreeBSD mercury 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Fri Feb 8 23:26:37 CET 2013 root@mercury:/usr/obj/usr/src/sys/CeDeROM-MERCURY amd64 % pciconf -lv iwn0@pci0:2:0:0:class=0x028000 card=0x13218086 chip=0x422c8086 rev=0x35 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6200' class = network Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: on amd64 r246552: iwn0: Intel Wireless WiFi Link 4965: fatal firmware error
From tomek.ce...@gmail.com Mon Feb 11 11:11:23 2013 Yesterday I had something similar - it was cause by a radio switch flip: iwn0: RF switch: radio disabled ubt0: ubt_bulk_read_callback:867: bulk-in transfer failed: USB_ERR_STALLED ubt0: ubt_intr_read_callback:767: interrupt transfer failed: USB_ERR_STALLED ugen1.4: Dell Computer Corp at usbus1 (disconnected) ubt0: at uhub3, port 7, addr 4 (disconnected) iwn0: iwn_intr: fatal firmware error firmware error log: error type = SYSASSERT (0x0005) program counter = 0x0001EFD8 source line = 0x012E error data = 0x branch link = 0x0001EEE40001EEE4 interrupt link = 0x1532 time= 767402829 driver status: tx ring 0: qid=0 cur=194 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=18 queued=0 tx ring 4: qid=4 cur=58 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=1 FreeBSD mercury 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Fri Feb 8 23:26:37 CET 2013 root@mercury:/usr/obj/usr/src/sys/CeDeROM-MERCURY amd64 % pciconf -lv iwn0@pci0:2:0:0:class=0x028000 card=0x13218086 chip=0x422c8086 rev=0x35 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6200' class = network Best regards, Tomek Yes, I can reproduce this on amd64 -current. I had to flip the switch twice to cause this: iwn0: RF switch: radio disabled wlan0: link state changed to DOWN iwn0: RF switch: radio enabled wlan0: link state changed to UP iwn0: RF switch: radio disabled wlan0: link state changed to DOWN iwn0: RF switch: radio enabled iwn0: iwn_intr: fatal firmware error firmware error log: error type = NMI_INTERRUPT_WDG (0x0004) program counter = 0x046C source line = 0x00D0 error data = 0x00020703 branch link = 0x837004C2 interrupt link = 0x06DA18B8 time= 200035 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=3 queued=1 tx ring 4: qid=4 cur=97 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 rx ring: cur=47 in6_purgeaddr: err=65, destination address delete failed However, in my earlier report I got to this error with no flipping the switch at all. Anton ___ 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: on amd64 r246552: iwn0: Intel Wireless WiFi Link 4965: fatal firmware error
On Mon, Feb 11, 2013 at 12:18 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: Yes, I can reproduce this on amd64 -current. I had to flip the switch twice to cause this: (..) However, in my earlier report I got to this error with no flipping the switch at all. Uhm, on some networks I also very often get information in the dmesg that wlan0: link state changed to DOWN and then wlan0: link state changed to DOWN, maybe this produce issues similar to radio flip switch..? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: Time to kill fdc ?
On Sun, Feb 10, 2013 at 3:55 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: But I just did an experiment on an old Pentium 4 system here, using the fdc driver and 8.3-STABLE as of early December (r243900). I read several diskettes using dd /dev/fd0 /dev/null and everything went flawlessly. Could you try: dd if=/dev/fd0 of=/dev/null bs=1048576 That consistently exploded 7.x and 8.x here yesterday... I've just tried this on my FreeBSD 9.1 amd64 r244903 system 10 times in a row, and nothing bad happened. Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: 7+ days of dogfood
Hi, On Mon, 11 Feb 2013 11:48:11 +0100 Fabian Keil freebsd-lis...@fabiankeil.de wrote: Steve Kargl s...@troutmask.apl.washington.edu wrote: My conclusion: on at least my not-so-new laptop, FreeBSD-10 can be used in a desktop environment if one takes some care during the installation. I'm using CURRENT on my also-no-so-new laptop since FreeBSD 7 (I think) and came to the same conclusion. I did this during 6.x time but got stuck then with 6.x and never went back until last May/June. It's unfortunate that the builworld time roughly trippled since 2010 but I guess that's progress and a more powerful system should fix it. I certainly welcome clang in general, though. Trippled? Are you sure? I have the feeling it is much worse than this. Was it in 2009 when I could compile world in a few minutes on my quad core. The same machine takes now hours despite having more memory. I run currently my desktop and my notebook on 10. If I stick with my policy, I would stay with 10 until 12 would be available. On the other side, it feels so outdated not to have something like the most current version. 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: 7+ days of dogfood
Erich, Den 11/02/2013 kl. 00.38 skrev Erich Dollansky erichsfreebsdl...@alogt.com: On Sun, 10 Feb 2013 15:57:01 +0100 Erik Cederstrand e...@cederstrand.dk wrote: And as long as there is no automatic can taster doing quality assurance of the produced cans, then foul cans will go unnoticed until a dog pukes all over the carpet :-) Isn't this the idea of HEAD? It's certainly not the idea of HEAD that everyone should experience the same bugs, compile errors, runtime errors and even have old bugs pop up again repeatedly. It may be the consequence of running HEAD, but certainly not the idea. For this to change, we really need to catch up on years of neglect in e.g. src/tools/regression/. I really applaud the people doing the thankless job of changing this. I do not believe that this all can be automated. I'm not saying that testing is all-or-nothing. OS testing is not easy, and many tests are impractical or expensive if they require real hardware in complicated setups. How do you reliably test an IEEE 802.11s mesh implementation? Or scheduling on huge servers that are too expensive to purchase? I think that is one of the reasons that FreeBSD has not caught up on automated testing and continuous integration. But regression tests are useful even though they don't give 100% code coverage. Currently, you can't even make test in src/tools/regression/ and run the tests that are there. Apart from the compile-tests done by the tinderboxes, I'm not aware of any coordinated effort to systematically do runtime or even performance testing of FreeBSD. Thanks, Erik ___ 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: 7+ days of dogfood
Hi Erik, On Mon, 11 Feb 2013 12:43:17 +0100 Erik Cederstrand e...@cederstrand.dk wrote: = Den 11/02/2013 kl. 00.38 skrev Erich Dollansky erichsfreebsdl...@alogt.com: On Sun, 10 Feb 2013 15:57:01 +0100 Erik Cederstrand e...@cederstrand.dk wrote: And as long as there is no automatic can taster doing quality assurance of the produced cans, then foul cans will go unnoticed until a dog pukes all over the carpet :-) Isn't this the idea of HEAD? It's certainly not the idea of HEAD that everyone should experience the same bugs, compile errors, runtime errors and even have old bugs pop up again repeatedly. It may be the consequence of running HEAD, but certainly not the idea. ok, I agree that developers could react faster some times. But, isn't it more important that the errors are caught at all? For this to change, we really need to catch up on years of neglect in e.g. src/tools/regression/. I really applaud the people doing the thankless job of changing this. I do not believe that this all can be automated. I'm not saying that testing is all-or-nothing. OS testing is not easy, and many tests are impractical or expensive if they require real hardware in complicated setups. How do you reliably test an IEEE 802.11s mesh implementation? Or scheduling on huge servers that are too expensive to purchase? I think that is one of the reasons that FreeBSD has not caught up on automated testing and continuous integration. But regression tests are useful even though they don't give 100% code coverage. Currently, you can't even make test in src/tools/regression/ and run the tests that are there. Apart from the compile-tests done by the tinderboxes, I'm not aware of any coordinated effort to systematically do runtime or even performance testing of FreeBSD. So, the best is still if people like me are eating dog food and start complaining? Do not get me wrong here. I do not complain about the fact that there might be an error, I want to help poin-point the error with my complaint. 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: 7+ days of dogfood
Erich Dollansky erichsfreebsdl...@alogt.com wrote: On Mon, 11 Feb 2013 11:48:11 +0100 Fabian Keil freebsd-lis...@fabiankeil.de wrote: It's unfortunate that the builworld time roughly trippled since 2010 but I guess that's progress and a more powerful system should fix it. I certainly welcome clang in general, though. Trippled? Are you sure? I have the feeling it is much worse than this. I'm sure it depends on lots of factors and our worlds probably don't even match. I intend to eventually plot the numbers I've collected over the years (mainly to have a baseline for ZFS tuning) but so far I haven't and just looked at the first and last ones: -- Kernel build for ZOEY completed on Mon May 31 17:18:12 CEST 2010 -- real10m42.935s user8m16.834s sys 1m22.951s -- World build completed on Mon May 31 18:38:59 CEST 2010 -- real71m16.524s user51m55.771s sys 12m24.944s # FreeBSD r500.local 10.0-CURRENT FreeBSD 10.0-CURRENT #543 r+b74c91e: Sun Feb 3 17:17:03 CET 2013 fk@r500.local:/usr/obj/usr/src/sys/ZOEY amd64 -- World build completed on Tue Feb 5 21:33:55 CET 2013 -- real261m25.904s user189m2.690s sys 22m46.777s # FreeBSD r500.local 10.0-CURRENT FreeBSD 10.0-CURRENT #547 r+21d959a: Sun Feb 10 16:00:14 CET 2013 fk@r500.local:/usr/obj/usr/src/sys/ZOEY amd64 -- Kernel build for ZOEY completed on Sun Feb 10 21:41:31 CET 2013 -- real18m34.822s user12m13.900s sys 2m14.028s fk@r500 ~ $expr 261 / 71 3 I agree that it feels worse, though. Disclaimer: These aren't benchmark results, I didn't create them in single-user mode and various relevant factors vary. I also didn't run the numbers through ministat and don't intend to either. Was it in 2009 when I could compile world in a few minutes on my quad core. The same machine takes now hours despite having more memory. I'm using a Core(TM)2 Duo CPU T5870 @ 2.00GHz and don't remember ever being able to compile world in a few minutes. The bottle neck on my system seems to be the puny 2 GB of RAM the linker has to share with ZFS. At least I can still buildworld without first attaching an USB stick for additional swap space which is necessary for Firefox ... Fabian signature.asc Description: PGP signature
[RFC] USB keyboard and devd.conf
Hi,
Does anyone need these lines in /etc/devd.conf ?
=== etc/devd.conf
==
--- etc/devd.conf (revision 246620)
+++ etc/devd.conf (local)
@@ -105,16 +105,6 @@
# action sleep 2 /usr/sbin/ath3kfw -d $device-name -f
/usr/local/etc/ath3k-1.fw;
#};
-# When a USB keyboard arrives, attach it as the console keyboard.
-attach 100 {
- device-name ukbd0;
- action /etc/rc.d/syscons setkeyboard /dev/ukbd0;
-};
-detach 100 {
- device-name ukbd0;
- action /etc/rc.d/syscons setkeyboard /dev/kbd0;
-};
-
notify 100 {
match system DEVFS;
match subsystem CDEV;
I plan to remove the lines marked with minus, because we now have kbdmux.
--HPS
___
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: 7+ days of dogfood
On 11 Feb 2013, at 10:48, Fabian Keil freebsd-lis...@fabiankeil.de wrote: It's unfortunate that the builworld time roughly trippled since 2010 but I guess that's progress and a more powerful system should fix it. I certainly welcome clang in general, though. In that case, it's worth noting that you can shave a fair bit off the build time by not building gcc. WITHOUT_GCC=yes in src.conf is worthwhile. WITHOUT_GDB=yes is probably also sensible, as the gdb in base is so old that it doesn't understand most of the DWARF that clang uses. We should have lldb ready for import in a few months, but until then using gdb from ports is more sensible if you plan on actually doing any debugging. As we transition to a GPL-free base system, we're going to have some fairly long windows where we have the old GNU tool and its replacement both in base. Over time, the old ones will be removed, but not until the newer ones are well tested. This, of course, happens faster if people are running systems where they are the only option... David ___ 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: 7+ days of dogfood
Den 11/02/2013 kl. 13.07 skrev Erich Dollansky erichsfreebsdl...@alogt.com: ok, I agree that developers could react faster some times. But, isn't it more important that the errors are caught at all? Yes. As long as there is no alternative, the best motivation to fix a bug is when you just spent 20 minutes recovering your laptop from a crash. I just believe more people would be motivated to run CURRENT if there was at least some basic runtime resting. Just like the tinderboxes save developer CPU cycles by saying Don't bother with this revision, it doesn't compile, I think runtime tests would save real developer time by saying Don't bother with this revision, it doesn't boot or Don't bother with this revision, gcc can't compile hello-world.cpp. Which doesn't imply that automated testing would catch all errors. So, the best is still if people like me are eating dog food and start complaining? Do not get me wrong here. I do not complain about the fact that there might be an error, I want to help poin-point the error with my complaint. As I started out, I admire the work you and others are doing by running CURRENT and reporting and fixing errors. At the same time, I look to e.g. LLVM and their no commit without a regression test goal and think we could do way better :-) Erik ___ 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
svn guid
hi, can anyone help me how i can download this code, i tried to downlaod differnect id by using svn but still fail, i think i am missing something from basics http://zrouter.org/hg/FreeBSD/head/file/a7c552e1ed7f/head/sys/dev/switch/ar8x16_switch.c 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: svn guid
On Mon, 11 Feb 2013 08:36:04 -0500 Yasir hussan kolya...@gmail.com wrote: hi, can anyone help me how i can download this code, i tried to downlaod differnect id by using svn but still fail, i think i am missing something from basics http://zrouter.org/hg/FreeBSD/head/file/a7c552e1ed7f/head/sys/dev/switch/ar8x16_switch.c devel/mercurial Thanks -- wbr, tiger ___ 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: svn guid
On Mon, 11 Feb 2013 08:36:04 -0500 Yasir hussan kolya...@gmail.com wrote: hi, can anyone help me how i can download this code, i tried to downlaod differnect id by using svn but still fail, i think i am missing something from basics http://zrouter.org/hg/FreeBSD/head/file/a7c552e1ed7f/head/sys/dev/switch/ar8x16_switch.c 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 Hello Yasir! Heh, I glad to know what somebody use zrouter.org repo for something :) But have to say: 1. http://zrouter.org/hg/FreeBSD/ is not FreeBSD official repository 2. It is in Mercurial (hg), but not Subversion (svn) If you want to look into FreeBSD ar8216/ar8316 driver, get it by: svn co http://svn.freebsd.org/base/head/sys/dev/etherswitch/ If you want to get ZRouter.org one, you will need to fetch whole repo: hg clone http://zrouter.org/hg/FreeBSD/head/ Thanks. WBW -- Aleksandr Rybalko r...@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: 7+ days of dogfood
David Chisnall thera...@freebsd.org wrote: On 11 Feb 2013, at 10:48, Fabian Keil freebsd-lis...@fabiankeil.de wrote: It's unfortunate that the builworld time roughly trippled since 2010 but I guess that's progress and a more powerful system should fix it. I certainly welcome clang in general, though. In that case, it's worth noting that you can shave a fair bit off the build time by not building gcc. Those gcc bits are shaved off already, that's why the buildworld finishes so quickly now ... My last result with both clang and gcc seems to be: -- World build completed on Mon Dec 24 22:55:21 CET 2012 -- real350m42.363s user253m5.477s sys 50m0.024s WITHOUT_GCC=yes in src.conf is worthwhile. WITHOUT_GDB=yes is probably also sensible, as the gdb in base is so old that it doesn't understand most of the DWARF that clang uses. We should have lldb ready for import in a few months, but until then using gdb from ports is more sensible if you plan on actually doing any debugging. So far I didn't consider not building gdb, but I agree that it's not too useful when compiling with clang and am already using gdb751 for debugging anyway. My impression was that the base gdb compiles rather quickly (compared to more recent versions) and that it thus wouldn't matter, but I'll give it a try. Thanks for the suggestion. Fabian signature.asc Description: PGP signature
Re: svn guid
On 02/11/2013 04:36 PM, Yasir hussan wrote: can anyone help me how i can download this code, i tried to downlaod differnect id by using svn but still fail, i think i am missing something from basics http://zrouter.org/hg/FreeBSD/head/file/a7c552e1ed7f/head/sys/dev/switch/ar8x16_switch.c Click the raw link. By the way, it's via hg, not svn. -- RMA. ___ 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: 7+ days of dogfood
On Mon, Feb 11, 2013 at 02:56:47PM +0100, Fabian Keil wrote: WITHOUT_GCC=yes in src.conf is worthwhile. WITHOUT_GDB=yes is probably also sensible, as the gdb in base is so old that it doesn't understand most of the DWARF that clang uses. We should have lldb ready for import in a few months, but until then using gdb from ports is more sensible if you plan on actually doing any debugging. So far I didn't consider not building gdb, but I agree that it's not too useful when compiling with clang and am already using gdb751 for debugging anyway. My impression was that the base gdb compiles rather quickly (compared to more recent versions) and that it thus wouldn't matter, but I'll give it a try. Thanks for the suggestion. You might also want to try MALLOC_PRODUCTION=1 in make.conf. This took my buildworld/buildkernel times from 35/15 minutes to 8/5 minutes, respectively. Glen pgpJUPpTb_txy.pgp Description: PGP signature
Re: 7+ days of dogfood
On Mon, 2013-02-11 at 09:15 -0500, Glen Barber wrote: On Mon, Feb 11, 2013 at 02:56:47PM +0100, Fabian Keil wrote: WITHOUT_GCC=yes in src.conf is worthwhile. WITHOUT_GDB=yes is probably also sensible, as the gdb in base is so old that it doesn't understand most of the DWARF that clang uses. We should have lldb ready for import in a few months, but until then using gdb from ports is more sensible if you plan on actually doing any debugging. So far I didn't consider not building gdb, but I agree that it's not too useful when compiling with clang and am already using gdb751 for debugging anyway. My impression was that the base gdb compiles rather quickly (compared to more recent versions) and that it thus wouldn't matter, but I'll give it a try. Thanks for the suggestion. You might also want to try MALLOC_PRODUCTION=1 in make.conf. This took my buildworld/buildkernel times from 35/15 minutes to 8/5 minutes, respectively. Glen Actually, anyone who is routinely setting MALLOC_PRODUCTION to run -current, please considering trying again without it. One particular sanity check enabled without MALLOC_PRODUCTION was responsible for virtually all of the performance degradation, and the recent import of a new jemalloc reworked that code to eliminate the problem (it was needlessly validating that freshly mmap'd memory was zeroed; now it only does that validation if it internally recycles a block, and I think it never even does that on freebsd). -- Ian ___ 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: geli(8) breaks after a couple hours of uptime
On Sun, 2013-02-10 at 00:35 +0100, Pawel Jakub Dawidek wrote: On Sat, Feb 09, 2013 at 06:00:53PM +0200, Andriy Gapon wrote: on 09/02/2013 17:04 Andrey Zonov said the following: On 2/9/13 5:07 PM, Fabian Keil wrote: This would at least prevent the segfault. I see two possibilities to get segfault: - no checking for result from memory allocation functions - too big stack I have no found any broken memory allocation checking, but I found two big objects on the stack. One is buf[MAXPHYS] in eli_genkey_files() and another is passbuf[MAXPHYS] in eli_genkey_passphrase(). If we change these two to malloc(), then we can handle error from malloc(), print some useful message and prevent segfault. I'd rather do what Kostik suggested and Fabian mentioned: instead of mlockall(MCL_FUTURE) the code should mlock only the (explicitly designated) buffers that can contain sensitive data. geli(8) almost exclusively deals with sensitive data. Even mlocking MAXPHYS would fail with current limits, but this is bad idea. With mlockall() I am sure I didn't miss anything - be it forgetting about mlocking some buffer or zeroing it before munlock. I'm also sure someone else who can modify geli(8) in the future won't miss anything too. geli(8) is relatively simple program, it doesn't allocate megabytes of memory for different pruposes and just needs few pages for sensitive data. As I said most of the memory it uses is for sensitive data. The obvious problem is allocating MAXPHYS on the stack. This has to be changed, especially that we may want to rise MAXPHYS in the future. Other than that I expect thing would be tuned properly so that geli(8) can work by default. I'm happy to use smaller buffers than MAXPHYS - keyfiles are far smaller usually than 128kB, so there shouldn't be any issue with this. If geli(8) uses relatively little memory and mlockall(MCL_FUTURE), you should consider adding a jemalloc tuning string to it, similar to what I did for watchdogd in r245949. It doesn't help with locking code when you only really need the data protected, but it does at least reduce the amount of wired memory to just what the program really needs. -- Ian ___ 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: 7+ days of dogfood
On 11 Feb 2013, at 13:56, Fabian Keil freebsd-lis...@fabiankeil.de wrote: real350m42.363s user253m5.477s sys 50m0.024s These numbers look a bit wrong. You've got 300 minutes of CPU time, but 350 minutes of real time. In an ideal world, on your dual-core system you'd see 150 minutes of real time. Seeing more than 300 implies that you're spending a lot of time waiting for I/O. The normal recommendation is to use -j x where x is 1.5 times the number of cores, or 1x the number of GBs of RAM, whichever is smaller. With only 2GB of RAM you might have linking problems with -j3, but it's still worth trying. One of the more serious problems with our current build system is that it doesn't scale well to large numbers of cores. On a 32-core system, with -j64, we're very rarely managing to have even 8 things able to run in parallel. This should be addressed when the bmake import is fully integrated and we can use meta mode for better dependency tracking. Ninja has a concept of pools, so you can say 'only run one link job at a time, but you can do two C++ compile jobs or 4 C compile jobs', and it might be interesting to look at adding something similar to bmake, as this can improve scalability a lot. David ___ 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: 7+ days of dogfood
David Chisnall david.chisn...@cl.cam.ac.uk wrote: On 11 Feb 2013, at 13:56, Fabian Keil freebsd-lis...@fabiankeil.de wrote: real350m42.363s user253m5.477s sys 50m0.024s These numbers look a bit wrong. You've got 300 minutes of CPU time, but 350 minutes of real time. In an ideal world, on your dual-core system you'd see 150 minutes of real time. Seeing more than 300 implies that you're spending a lot of time waiting for I/O. The normal recommendation is to use -j x where x is 1.5 times the number of cores, or 1x the number of GBs of RAM, whichever is smaller. With only 2GB of RAM you might have linking problems with -j3, but it's still worth trying. With only 2 GB of RAM (parts of which are needed elsewhere) I'm already having linking problems without using -j at all and the I/O I'm waiting for is the disk serving the swap partition. I've used -j2 and occasionally -j4 when building world with gcc in the past, but when using clang I'd risk temporarily having three (or more) processes compete for swap space and bandwidth, so I stopped doing that. I'd expect that another 2 GB of RAM would prevent the swapping and thus reduce the buildworld time quite a bit, but as I intend to replace the system anyway I can't be bothered to investigate what kind of RAM I'd need and where to get it. One of the more serious problems with our current build system is that it doesn't scale well to large numbers of cores. On a 32-core system, with -j64, we're very rarely managing to have even 8 things able to run in parallel. This should be addressed when the bmake import is fully integrated and we can use meta mode for better dependency tracking. Ninja has a concept of pools, so you can say 'only run one link job at a time, but you can do two C++ compile jobs or 4 C compile jobs', and it might be interesting to look at adding something similar to bmake, as this can improve scalability a lot. Unfortunately I don't have these issues (yet). Fabian signature.asc Description: PGP signature
Re: 7+ days of dogfood
Glen Barber g...@freebsd.org wrote: On Mon, Feb 11, 2013 at 02:56:47PM +0100, Fabian Keil wrote: WITHOUT_GCC=yes in src.conf is worthwhile. WITHOUT_GDB=yes is probably also sensible, as the gdb in base is so old that it doesn't understand most of the DWARF that clang uses. We should have lldb ready for import in a few months, but until then using gdb from ports is more sensible if you plan on actually doing any debugging. So far I didn't consider not building gdb, but I agree that it's not too useful when compiling with clang and am already using gdb751 for debugging anyway. My impression was that the base gdb compiles rather quickly (compared to more recent versions) and that it thus wouldn't matter, but I'll give it a try. Thanks for the suggestion. You might also want to try MALLOC_PRODUCTION=1 in make.conf. This took my buildworld/buildkernel times from 35/15 minutes to 8/5 minutes, respectively. I've been using MALLOC_PRODUCTION since before I started collecting build times and don't remember the impact, but I think the difference was less impressive than in your case and the massive slowdowns that are now supposed to be fixed only happened recently (after 2010) and thus never affected me. Thanks, though. Fabian signature.asc Description: PGP signature
Time to kill fdc ?
When was the last time anybody tried that with a FreeBSD release ? Routinely :) Often archiving piles of floppies as images too. Imagine the legacy gaming crowd does this as well to use, while preventing loss. Also, fdformat(1), fdcontrol(8), fdread(1), and fdwrite(1) are important complimentary tools for people too! I even use fdformat -F. I intend to dust of my axe and cut it from the tree later this spring. Please don't. I also think there are motherboards still shipping with real floppy interfaces. ___ 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: Time to kill fdc ?
... I notice how people haven't quoted how much RAM they have, since that may influence whether or not things get bounced, double bounced or such. Adrian On 11 February 2013 03:28, C. P. Ghost cpgh...@cordula.ws wrote: On Sun, Feb 10, 2013 at 3:55 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: But I just did an experiment on an old Pentium 4 system here, using the fdc driver and 8.3-STABLE as of early December (r243900). I read several diskettes using dd /dev/fd0 /dev/null and everything went flawlessly. Could you try: dd if=/dev/fd0 of=/dev/null bs=1048576 That consistently exploded 7.x and 8.x here yesterday... I've just tried this on my FreeBSD 9.1 amd64 r244903 system 10 times in a row, and nothing bad happened. Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: [RFC] USB keyboard and devd.conf
.. as long as we can attach/detach keyboards without there actually
_being_ a physical console keyboard at boot, sure.
adrian
On 11 February 2013 04:43, Hans Petter Selasky hsela...@c2i.net wrote:
Hi,
Does anyone need these lines in /etc/devd.conf ?
=== etc/devd.conf
==
--- etc/devd.conf (revision 246620)
+++ etc/devd.conf (local)
@@ -105,16 +105,6 @@
# action sleep 2 /usr/sbin/ath3kfw -d $device-name -f
/usr/local/etc/ath3k-1.fw;
#};
-# When a USB keyboard arrives, attach it as the console keyboard.
-attach 100 {
- device-name ukbd0;
- action /etc/rc.d/syscons setkeyboard /dev/ukbd0;
-};
-detach 100 {
- device-name ukbd0;
- action /etc/rc.d/syscons setkeyboard /dev/kbd0;
-};
-
notify 100 {
match system DEVFS;
match subsystem CDEV;
I plan to remove the lines marked with minus, because we now have kbdmux.
--HPS
___
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: 7+ days of dogfood
On 11 February 2013 09:45, Fabian Keil freebsd-lis...@fabiankeil.de wrote: You might also want to try MALLOC_PRODUCTION=1 in make.conf. This took my buildworld/buildkernel times from 35/15 minutes to 8/5 minutes, respectively. I've been using MALLOC_PRODUCTION since before I started collecting build times and don't remember the impact, but I think the difference was less impressive than in your case and the massive slowdowns that are now supposed to be fixed only happened recently (after 2010) and thus never affected me. Thanks, though. If you're running a recent multicore box with large quantities of very fast RAM - no, you would've have seen it. If you do a buildworld on a HT Atom CPU in a netbook .. holy crap do you notice it. 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: Time to kill fdc ?
On Mon, Feb 11, 2013 at 7:36 PM, Adrian Chadd adr...@freebsd.org wrote: ... I notice how people haven't quoted how much RAM they have, since that may influence whether or not things get bounced, double bounced or such. 4 GB RAM installed here: real memory = 4294967296 (4096 MB) avail memory = 3832922112 (3655 MB) Adrian -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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
vlan testing using etherswitchcfg
hi, is there anyone who knows how i can test vlan feature using *etherswitchcfg*, it tried to set and get vlan configraton for chip ar8316 it shows me right output, but i still dont know how i should test it with its limited commands. Plz anyone who knows kindly inform me detailed setup to test vlan 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
7+ days of dogfood
sgk So, I decided to test FreeBSD-10 under a user desktop condition. In so doing, I upgraded the circa August 2012 FreeBSD-current that ran on my Dell Latitude D530 (which ran rock-solid) to top-of-tree. This included re-installing all ports under the pkgng paradigm. phk First a hat-tip for even doing this in the first place, if more committers ran -current, -current would work better. Though not making any particular suggestion, the OpenBSD folks have gained similar benefit from eating their own dog food as well. You can search for something like OpenBSD Release Engineering video Theo presented where they talk about some of this eating, why they do it, and to what result. ___ 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: [RFC/RFT] calloutng
[trimmed old mails] Here's a new version of the patch: http://people.freebsd.org/~davide/patches/calloutng-11022012.diff Significant bits changed (after wider discussion and suggestion by phk@): - Introduction of the new sbintime_t type (32.32 fixed point) with the respective conversion (sbintime2bintime, sbintime2timeval etc...) - switch from 64.64 (struct bintime) format to measure time to sbintime_t - Use sbintime_t to represent expected sleep time instead of measuring it in microseconds (cpu_idle_acpi(), cpu_idle_spin() ...). Thanks, Davide ___ 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: 7+ days of dogfood
On Mon, Feb 11, 2013 at 01:17:41PM +0100, Fabian Keil wrote: Erich Dollansky erichsfreebsdl...@alogt.com wrote: On Mon, 11 Feb 2013 11:48:11 +0100 Fabian Keil freebsd-lis...@fabiankeil.de wrote: It's unfortunate that the builworld time roughly trippled since 2010 but I guess that's progress and a more powerful system should fix it. I certainly welcome clang in general, though. Trippled? Are you sure? I have the feeling it is much worse than this. I'm sure it depends on lots of factors and our worlds probably don't even match. I intend to eventually plot the numbers I've collected over the years (mainly to have a baseline for ZFS tuning) but so far I haven't and just looked at the first and last ones: -- Kernel build for ZOEY completed on Mon May 31 17:18:12 CEST 2010 -- real10m42.935s user8m16.834s sys 1m22.951s -- World build completed on Mon May 31 18:38:59 CEST 2010 -- real71m16.524s user51m55.771s sys 12m24.944s # FreeBSD r500.local 10.0-CURRENT FreeBSD 10.0-CURRENT #543 r+b74c91e: Sun Feb 3 17:17:03 CET 2013 fk@r500.local:/usr/obj/usr/src/sys/ZOEY amd64 -- World build completed on Tue Feb 5 21:33:55 CET 2013 -- real 261m25.904s user 189m2.690s sys 22m46.777s # FreeBSD r500.local 10.0-CURRENT FreeBSD 10.0-CURRENT #547 r+21d959a: Sun Feb 10 16:00:14 CET 2013 fk@r500.local:/usr/obj/usr/src/sys/ZOEY amd64 -- Kernel build for ZOEY completed on Sun Feb 10 21:41:31 CET 2013 -- real 18m34.822s user 12m13.900s sys 2m14.028s fk@r500 ~ $expr 261 / 71 3 I agree that it feels worse, though. Disclaimer: These aren't benchmark results, I didn't create them in single-user mode and various relevant factors vary. I also didn't run the numbers through ministat and don't intend to either. Was it in 2009 when I could compile world in a few minutes on my quad core. The same machine takes now hours despite having more memory. I'm using a Core(TM)2 Duo CPU T5870 @ 2.00GHz and don't remember ever being able to compile world in a few minutes. The bottle neck on my system seems to be the puny 2 GB of RAM the linker has to share with ZFS. At least I can still buildworld without first attaching an USB stick for additional swap space which is necessary for Firefox ... I also dislike that src build times increased over the years since I run CURRENT on my notebooks (starting 7-CURRENT, now 10-CURRENT). Wouldn't it be possible to add a DO_NOT_BUILD_CLANG_AND_GCC_IF_NOTHING_CHANGED= yes switch to src.conf? Building clang takes ages and gcc is also pretty big... pgpcnKaD8bz2Q.pgp Description: PGP signature
Re: use of undeclared identifier 'IEEE80211_MESHRT_FLAGS_GATE'
clang -O2 -pipe -march=native -DINET6 -DINET -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -c /path/to/src/sbin/ifconfig/ifieee80211.c /path/to/src/sbin/ifconfig/ifieee80211.c:4029:21: error: use of undeclared identifier 'IEEE80211_MESHRT_FLAGS_GATE' (rt-imr_flags IEEE80211_MESHRT_FLAGS_GATE) ? ^ 1 error generated. *** [ifieee80211.o] Error code 1 Stop in /gpath/to/src/sbin/ifconfig. *** [ifconfig_make] Error code 1 Stop in /usr/obj/path/to/src/rescue/rescue. *** [objs] Error code 1 ... ___ 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: HEAD memsticks broken? [USB/CAM Problems?]
On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. -- Joel ___ 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: 7+ days of dogfood
On Mon, Feb 11, 2013 at 01:29:12PM +, David Chisnall wrote: On 11 Feb 2013, at 10:48, Fabian Keil freebsd-lis...@fabiankeil.de wrote: It's unfortunate that the builworld time roughly trippled since 2010 but I guess that's progress and a more powerful system should fix it. I certainly welcome clang in general, though. In that case, it's worth noting that you can shave a fair bit off the build time by not building gcc. WITHOUT_GCC=yes in src.conf is worthwhile. While not building a part of the base system will obviously speed up bulidworld, it seems to me that you're being a little too generous here. The buildworld-speed issue is clearly a problem with clang/llvm. On my very lightly loaded, 4-core opteron system with 16 GB of memory, I see WITH_CLANG=YES WITH_GCC=YES rm -rf /usr/obj/* time make -j4 buildworld 3634.55 real 9784.21 user 1286.08 sys WITH_CLANG=YES WITHOUT_GCC=YES rm -rf /usr/obj/* time make -j4 buildworld 3489.40 real 9413.90 user 1324.72 sys WITHOUT_CLANG=YES WITH_GCC=YES rm -rf /usr/obj/* time make -j4 buildworld 1928.38 real 5254.85 user 1075.68 sys -- Steve ___ 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
error: use of undeclared identifier 'DOSPTYP_HFS'
clang -O2 -pipe -march=native -DLOADER_NFS_SUPPORT -DBOOT_FORTH
-I/path/to/src/sys/boot/i386/loader/../../ficl
-I/path/to/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT
-DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT
-I/path/to/src/sys/boot/i386/loader/../../common -I. -Wall
-I/path/to/src/sys/boot/i386/loader/..
-I/path/to/src/sys/boot/i386/loader/../btx/lib -march=i386 -ffreestanding
-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3
-msoft-float -std=gnu99 -Qunused-arguments -c
/path/to/src/sys/boot/i386/loader/../../common/part.c
/path/to/src/sys/boot/i386/loader/../../common/part.c:648:23: error: use of
undeclared identifier 'DOSPTYP_HFS'
if (dp[1].dp_typ != DOSPTYP_HFS) {
...
Stop in /gk/freebsd_src/sys/boot/i386/loader.
...
___
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: Physbio changes final call for tests and reviews
On Sat, Feb 02, 2013 at 10:47:09PM +0100, Marius Strobl wrote: On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: Hi, I finished the last (insignificant) missed bits in the Jeff' physbio work. Now I am asking for the last round of testing and review, esp. for the !x86 architectures. Another testing focus are the SCSI HBAs and RAID controllers which drivers are changed by the patchset. Please do test this before the patchset is committed into HEAD ! The plan is to commit the patch somewhere in two weeks from this moment. The patch is required for the finalizing of the unmapped I/O work for UFS I did in parallel, which I hope to finish shortly after the commit. Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff First tests on sparc64 with ata(4), mpt(4) and sym(4) look good (to be sure I still need to test with a machine using a streaming buffer in addition to the IOMMU, though). FYI, the latter case is also fine. Marius ___ 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 82574 issue reported on Slashdot
On Fri, 2013-02-08 at 10:16 -0800, Jack Vogel wrote: For those that may have run across the story on Slashdot about this NIC, here is our statement: Recently there were a few stories published, based on a blog post by an end-user, suggesting specific network packets may cause the Intel® 82574L Gigabit Ethernet Controller to become unresponsive until corrected by a full platform power cycle. Intel was made aware of this issue in September 2012 by the blogs author. Intel worked with the author as well as the original motherboard manufacturer to investigate and determine root cause. Intel root caused the issue to the specific vendor’s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer. It is Intel’s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller. Intel has not observed this issue with any implementations which follow Intel’s published design guidelines. Intel recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted. Here is the link: http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement Any questions or concerns may be sent to me. Cheers, Jack Thanks for the info. I'm sure there were some *interesting* debugging sessions during this. Sean ___ 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: HEAD memsticks broken? [USB/CAM Problems?]
On Monday 11 February 2013 23:21:05 Joel Dahl wrote: On 10-02-2013 0:09, Joel Dahl wrote: On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. Just a quick update on this: I've built quite a few releases now and managed to track down the problem to somewhere between r235789 and r237855. It'll probably take me another day or two before I know which commit actually broke it. Hi, I don't see any relevant USB+UMASS patches for your issue in this interval, but many patches in the SCSI/CAM area. --HPS ___ 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
