Re: considering i386 as a tier 1 architecture
On 01/04/13 20:31, Adrian Chadd wrote: Why stop there? Noone runs FreeBSD on real hardware anymore. Except, say netflix. Let's just drop actual native hardware support and instead support only the bare minimum needed to boot inside vmware, virtualbox and xen. Anyone needing real hardware support can install NetBSD and xen. No need for NetBSD anymore, Xen is going to integrate the Linux tree and glibc, so you can build a full distro form the Xen tree: http://blog.xen.org/index.php/2013/04/01/bringing-open-source-communities-closer-together/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: boot time crash in if_detach_internal()
On Mon, Apr 01, 2013 at 03:45:19AM -0600, Chris Torek wrote: C I have been poking about with the bhyve virtualization code in C FreeBSD 10-current, and managed to crash FreeBSD during its C bootstrap process due to the fact that if_detach is called C from boot time configuration code, before the internal domain C system initialization has happened. C C I added the following patch to work around the problem. As C the large comment notes, it might not be quite correct but it C does allow the boot to proceed (of course the dead network C device is soon a problem anyway...). C C The fix mirrors (more or less) the code in if_attach_internal(). C Feel free to accept, ignore, or modify the patch. :-) C C Chris C C diff --git a/sys/net/if.c b/sys/net/if.c C --- a/sys/net/if.c C +++ b/sys/net/if.c C @@ -845,6 +845,15 @@ C C if_purgeaddrs(ifp); C C +/* C + * torek: it's not entirely clear to me where and how this C + * should go, but if domain_init_status 2 then there should C + * be no inet, inet6, etc items, and this is where the crash C + * happens during boot, so let's try this: C + */ C +if (domain_init_status 2) C +return; C + C #ifdef INET C in_ifdetach(ifp); C #endif Can you provide a backtrace that leads to this? -- Totus tuus, Glebius. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
Hello, Dag-Erling. You wrote 2 апреля 2013 г., 13:04:04: DES http://soekris.com/products/net6501.html This one is 64-bit capable according to their mailing list -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Smørgrav d...@des.no wrote: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Smørgrav - d...@des.no I am NOT able to understand the merit of these products with respect to their features and PRICES . It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Tue, Apr 2, 2013 at 1:10 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Smørgrav d...@des.no wrote: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Smørgrav - d...@des.no I am NOT able to understand the merit of these products with respect to their features and PRICES . It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . Power consumption. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Tue, Apr 2, 2013 at 1:29 PM, Achim Hut achim...@achimhut.de wrote: Am 02.04.2013 12:13, schrieb Kimmo Paasiala: On Tue, Apr 2, 2013 at 1:10 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Smørgrav d...@des.no wrote: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Smørgrav - d...@des.no I am NOT able to understand the merit of these products with respect to their features and PRICES . It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . Power consumption. ...Space - Price - temperature, easy to use, no Fans, no Noise... I was surprised about this discussion and first thought, its some kind of april joke. Everybody talks about cheap new 64 bit hardware But how about the hardware people are actualy using? In our datacenter we are running (beside 64bit machines) a large amount of 32bit servers. We have a room full of spare parts, spare servers... And we have no reason to change them to 64bit hardware. HP, IBM, they all run since years and i am shure, they make 5-10 more years :-) And we dont want to stop using FreeBSD after V9.x or so. Dont forget there are a lot of different people with different needs out there. Not everybody puts his focus on a cheap desktop PC thats thrown away after 3 years Achim It is in fact an April Fools Joke :D However, it does not invalidate some of the points made. ARM is going to dominate the desktop/laptop/tablet/smartphone market very soon and it would be very wise for FreeBSD to shift the focus to it as soon as possible. -Kimmo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Tue, Apr 02, 2013 at 03:10:56AM -0700, Mehmet Erol Sanliturk typed: On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm??rgrav d...@des.no wrote: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Sm??rgrav - d...@des.no I am NOT able to understand the merit of these products with respect to their features and PRICES . They are extremely stable and robust. It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . You can also get much bigger portions at MacDonald than what you get in a five star restaurant. Ruben ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
Am 02.04.2013 12:13, schrieb Kimmo Paasiala: On Tue, Apr 2, 2013 at 1:10 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Smørgrav d...@des.no wrote: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Smørgrav - d...@des.no I am NOT able to understand the merit of these products with respect to their features and PRICES . It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . Power consumption. ...Space - Price - temperature, easy to use, no Fans, no Noise... I was surprised about this discussion and first thought, its some kind of april joke. Everybody talks about cheap new 64 bit hardware But how about the hardware people are actualy using? In our datacenter we are running (beside 64bit machines) a large amount of 32bit servers. We have a room full of spare parts, spare servers... And we have no reason to change them to 64bit hardware. HP, IBM, they all run since years and i am shure, they make 5-10 more years :-) And we dont want to stop using FreeBSD after V9.x or so. Dont forget there are a lot of different people with different needs out there. Not everybody puts his focus on a cheap desktop PC thats thrown away after 3 years Achim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Call for FreeBSD 2013-Q1 status reports!
Hi all, On behalf of monthly@, I would like to inform you that the next submission date for the January to March quarterly status reports is April 21st, 2013 - less than a month away. They don't have to be very long - anything that lets people know what is going on inside FreeBSD is useful. Note that submission of reports is not restricted to committers - anyone who is doing anything interesting and FreeBSD-related can write one! The preferred and easiest submission method is to use the XML generator linked to from http://www.freebsd.org/news/status/status.html, with the result emailed as an attachment to mont...@freebsd.org. On that page, there is also a link to an XML template which can be filled out manually and attached if preferred. To enable compilation and publication of the Q1 report as soon as possible after the April 21st deadline, please be prompt with any report submissions you may have. I look forward to compiling the report for 2013 Q1. Many thanks, Isabell. (Hat: monthly@) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
Mehmet Erol Sanliturk m.e.sanlit...@gmail.com writes: I am NOT able to understand the merit of these products with respect to their features and PRICES. Please stop SHOUTING, and learn to accept and respect the fact that other people have other opinions and priorities than you do, and to stop trying to force your worldview on them. Maybe they know something you haven't learned yet. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Tue, Apr 2, 2013 at 4:41 AM, Dag-Erling Smørgrav d...@des.no wrote: Mehmet Erol Sanliturk m.e.sanlit...@gmail.com writes: I am NOT able to understand the merit of these products with respect to their features and PRICES. Please stop SHOUTING, and learn to accept and respect the fact that other people have other opinions and priorities than you do, and to stop trying to force your worldview on them. Maybe they know something you haven't learned yet. DES -- Dag-Erling Smørgrav - d...@des.no You are right , but my idea was in affirmative sense to understand the reasons . I know that persons are using such systems with respect to some advantages other than the cost and their producers have reasons to assign such prices in a free economic structure . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Apr 2, 2013, at 4:10 AM, Mehmet Erol Sanliturk wrote: On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Smørgrav d...@des.no wrote: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Smørgrav - d...@des.no I am NOT able to understand the merit of these products with respect to their features and PRICES . It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . Often times the power consumption is the most important bit, so much so you sacrifice speed and memory to get the power down to fit into a small power budget. Just because you have the ability to purchase a faster machine for less doesn't make that faster machine suitable for the job. Warner Thank you very much . Mehmet Erol Sanliturk ___ freebsd-a...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to freebsd-arch-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Tue, Apr 02, 2013 at 10:22:20AM +, Ruben de Groot wrote: On Tue, Apr 02, 2013 at 03:10:56AM -0700, Mehmet Erol Sanliturk typed: On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm??rgrav d...@des.no wrote: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Sm??rgrav - d...@des.no I am NOT able to understand the merit of these products with respect to their features and PRICES . They are extremely stable and robust. It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . You can also get much bigger portions at MacDonald than what you get in a five star restaurant. Soekris boards are perhaps not five star boards but at least they have four :) Although the thread started as an april fools day prank, it's getting serious now about the value of having i386 next to amd64. I'm using quite a number of net4501/net4801/net5501/net6501 in many places just because I haven't found anything that can to the same job with the same reliability at the same low power diet for a reasonable price. For people on a tight budget with lower reliability expectations there are the PC-engines Alix boards. Except for the net6501, none of these can run amd64. Even though the net6501 can run amd64, I prefer running i386 on them (and other boards where I do not need = 4GB of RAM or the large address space) instead of amd64 just because the system image is so much smaller, requiring less storage on your filesystem (often a small flash device), less time to upload changes over the Internet when doing remote upgrades and they are more efficient with virtual memory. Running amd64 when not really needed is just a waste of resources. There have been discussions in the past whether is would make sense to run a 32-bit userland on top of a amd64 kernel sou you can have 4GB of RAM but keep your userland relatively small. There are only few applications that really benefit from 64 bit address space, others could well be 32 bit apps. Just some random numbers to illustrate my point: i386$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc textdata bss dec hex filename 11153310487460 120041 1d4e9 /bin/sh 22808 572 396 237765ce0 /bin/ls 33098 7603392 372509182 /usr/bin/find 3148419376 18204 342421 53995 /usr/bin/cc amd64$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc textdata bss dec hex filename 1293711992 10272 141635 22943 /bin/sh 262551144 536 279356d1f /bin/ls 4346413524680 49496c158 /usr/bin/find 383330 15296 58664 457290 6fa4a /usr/bin/cc Kind regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: boot time crash in if_detach_internal()
Hi, - Original Message - From: Gleb Smirnoff gleb...@freebsd.org To: Chris Torek to...@torek.net Cc: freebsd-hackers@freebsd.org Sent: Tuesday, April 2, 2013 3:57:08 AM Subject: Re: boot time crash in if_detach_internal() On Mon, Apr 01, 2013 at 03:45:19AM -0600, Chris Torek wrote: C I have been poking about with the bhyve virtualization code in C FreeBSD 10-current, and managed to crash FreeBSD during its C bootstrap process due to the fact that if_detach is called C from boot time configuration code, before the internal domain C system initialization has happened. C C I added the following patch to work around the problem. As C the large comment notes, it might not be quite correct but it C does allow the boot to proceed (of course the dead network C device is soon a problem anyway...). C C The fix mirrors (more or less) the code in if_attach_internal(). C Feel free to accept, ignore, or modify the patch. :-) C C Chris C C diff --git a/sys/net/if.c b/sys/net/if.c C --- a/sys/net/if.c C +++ b/sys/net/if.c C @@ -845,6 +845,15 @@ C Cif_purgeaddrs(ifp); C C + /* C + * torek: it's not entirely clear to me where and how this C + * should go, but if domain_init_status 2 then there should C + * be no inet, inet6, etc items, and this is where the crash C + * happens during boot, so let's try this: C + */ C + if (domain_init_status 2) C + return; C + C #ifdef INET Cin_ifdetach(ifp); C #endif Can you provide a backtrace that leads to this? It is probably along the lines of ... vtnet0: cannot setup virtqueue interrupts Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x370 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8088039b stack pointer = 0x28:0x8182c4b0 frame pointer = 0x28:0x8182c550 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [ thread pid 0 tid 10 ] Stopped at __rw_rlock+0x23b: movl0x370(%r12),%eax db bt Tracing pid 0 tid 10 td 0x814fb200 __rw_rlock() at __rw_rlock+0x23b/frame 0x8182c550 in_pcbpurgeif0() at in_pcbpurgeif0+0x30/frame 0x8182c5a0 in_ifdetach() at in_ifdetach+0x1c/frame 0x8182c5d0 if_detach() at if_detach+0x19b/frame 0x8182c630 vtnet_attach() at vtnet_attach+0xb63/frame 0x8182c760 device_attach() at device_attach+0x396/frame 0x8182c7b0 vtpci_probe_and_attach_child() at vtpci_probe_and_attach_child+0x91/frame 0x8182c7f0 vtpci_attach() at vtpci_attach+0x23b/frame 0x8182c830 device_attach() at device_attach+0x396/frame 0x8182c880 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x8182c8a0 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x8182c8f0 device_attach() at device_attach+0x396/frame 0x8182c940 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x8182c960 acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x8182c9b0 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame 0x8182ca00 device_attach() at device_attach+0x396/frame 0x8182ca50 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x8182ca70 acpi_attach() at acpi_attach+0xdd6/frame 0x8182cb30 device_attach() at device_attach+0x396/frame 0x8182cb80 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x8182cba0 nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0x8182cbd0 device_attach() at device_attach+0x396/frame 0x8182cc20 bus_generic_new_pass() at bus_generic_new_pass+0x116/frame 0x8182cc50 bus_set_pass() at bus_set_pass+0x8f/frame 0x8182cc80 configure() at configure+0xa/frame 0x8182cc90 mi_startup() at mi_startup+0x118/frame 0x8182ccb0 btext() at btext+0x2c This is from neel@ for vtnet, but I recently saw the same crash at work on an igb (on 9.1 or 9-STABLE). I hadn't had time to look at it much. Not sure if the right answer is for drivers not to call ether_ifattach() until the point-of-no-failure (lots of drivers are wrong then) or initialize other parts earlier. -- Totus tuus, Glebius. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
On Apr 2, 2013, at 10:27 AM, Chris BeHanna wrote: Goodness gracious, did no one see the date on the original post? What's the limit on this fishing hole? Three internet Trolls, two wise old owls and a april fool in a pear tree from the looks of it. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
Goodness gracious, did no one see the date on the original post? What's the limit on this fishing hole? -- Chris BeHanna ch...@behanna.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: boot time crash in if_detach_internal()
Can you provide a backtrace that leads to this? Sure. In case it's not obvious, the __rw_rlock at the top of the trace is working on a lock that has never been initialized (the first of the two ipv4 PCBs). Chris Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #2: Sun Mar 31 01:32:38 MDT 2013 to...@dev.torek.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (3292.28-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9 Features=0x8fa3ab7fFPU,VME,DE,PSE,TSC,MSR,PAE,CX8,APIC,SEP,PGE,CMOV,PAT,PSE36,DTS,MMX,FXSR,SSE,SSE2,SS,PBE Features2=0xa1bae217SSE3,PCLMULQDQ,DTES64,DS_CPL,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,F16C,HV AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 536870912 (512 MB) avail memory = 472559616 (450 MB) Event timer LAPIC quality 400 ACPI APIC Table: BHYVE BVMADT FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded; using insecure entropy ioapic0: Changing APIC ID to 2 ioapic0 Version 1.1 irqs 0-16 on motherboard module_register_init: MOD_LOAD (vesa, 0x80c38e80, 0) error 19 kbd0 at kbdmux0 acpi0: BHYVE BVXSDT on motherboard atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 32-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: no PRT entry for 0.31.INTA virtio_pci0: VirtIO PCI Network adapter port 0x2000-0x201f at device 1.0 on pci0 vtnet0: VirtIO Networking Adapter on virtio_pci0 virtio_pci0: host features: 0x18020 Status,MrgRxBuf,MacAddress virtio_pci0: negotiated features: 0x18020 Status,MrgRxBuf,MacAddress vtnet0: Ethernet address: 00:a0:98:36:6d:e8 virtio_pci0: exhausted all interrupt allocation attempts vtnet0: cannot setup virtqueue interrupts Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x378 fault code = supervisor read data, page not present instruction pointer = 0x20:0x808894bb stack pointer = 0x28:0x818434b0 frame pointer = 0x28:0x81843550 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [ thread pid 0 tid 10 ] Stopped at __rw_rlock+0x23b: movl0x378(%r12),%eax db bt Tracing pid 0 tid 10 td 0x8150d370 __rw_rlock() at __rw_rlock+0x23b/frame 0x81843550 in_pcbpurgeif0() at in_pcbpurgeif0+0x30/frame 0x818435a0 in_ifdetach() at in_ifdetach+0x1c/frame 0x818435d0 if_detach() at if_detach+0x19b/frame 0x81843630 vtnet_attach() at vtnet_attach+0xb63/frame 0x81843760 device_attach() at device_attach+0x396/frame 0x818437b0 vtpci_probe_and_attach_child() at vtpci_probe_and_attach_child+0x91/frame 0x818437f0 vtpci_attach() at vtpci_attach+0x23b/frame 0x81843830 device_attach() at device_attach+0x396/frame 0x81843880 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x818438a0 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x818438f0 device_attach() at device_attach+0x396/frame 0x81843940 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81843960 acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x818439b0 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame 0x81843a00 device_attach() at device_attach+0x396/frame 0x81843a50 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81843a70 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: boot time crash in if_detach_internal()
Not sure if the right answer is for drivers not to call ether_ifattach() until the point-of-no-failure (lots of drivers are wrong then) or initialize other parts earlier. The other obvious method is to rearrange the sysinit priorities (/sys/sys/kernel.h) so that all network domains are initialized before invoking the device configuration code -- moving SI_SUB_PROTO* before SI_CONFIGURE -- but presumably this idea was tried and rejected earlier and hence the code in ether_ifattach to check the same global variable. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need advice on sys5 shm and zero copy sockets
On 2/8/13 4:22 AM, gary mazzaferro wrote: Hi, I was told to post this question here (Ken Merry), it would be a good place to get some help. I'm not sure this is doable without a kernel module, which I don't want to add. I'll explain what I'm attempting.. I'm designing a high speed rest motor for cloud execution environment. 1) I'd like to eliminate copy from the tcp stack to the application(s). 2) I'm also sharing the buffers across processes and jails. So I'd like to preserve the zero-copy in a msg pipe/unix socket 3) Some buffers will go to disk file systems. Wish list: 4) I'd like it to work with sctp because I like it for local networking :) 5) I'd like to provision memory pools on a per application/connection/ip port basis. Ultimate Goal: 6) Additionally, I'm injecting code from a foreign process into the workflow of another process (state machine). The connection between them will be a signal and shared state information. I'm assuming item (6) is a separate issue, but it may impact the direction.. I've tried shm with zero copy sockets with linux and it just will not work !! BTW, I'm returning to freebsd after far too many years cheers, gary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org this sound somewhat like what I did back in the 90s with BSD4.3 unfortunately it was not done with TCP (or sctp of course) what we did was to create a special shared memeory device driver. Then we added ioctls to the disk driver layer to write named blocks of memory from that device to the raw device (we didin't use a filesystem). We also changed the network drivers to use named blocks of memory in that device for packet reception. We added a special protocol which used recvmsg() and and sendmesg() to pass ownership of those named blocks between the process that had mmapped them and the protocol. The protocol had an IP header but also a small protocol specific header of our own.. we sent packets that were larger than a page. zero copy from disk-process, process-network and network-disk (and reverse of course) of course it was all on proprietary protocols so not of use to you. julian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: considering i386 as a tier 1 architecture
As far I can tell it's now April 2nd in all time zones. Can we now end this thread? thank you, -Alfred On 4/2/13 6:22 AM, Paul Schenkeveld wrote: On Tue, Apr 02, 2013 at 10:22:20AM +, Ruben de Groot wrote: On Tue, Apr 02, 2013 at 03:10:56AM -0700, Mehmet Erol Sanliturk typed: On Tue, Apr 2, 2013 at 2:04 AM, Dag-Erling Sm??rgrav d...@des.no wrote: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: Lev Serebryakov l...@freebsd.org writes: It is not exact so. Some Atoms on some motherboards with some firmwares are 64-bit CPU. don't know of any now in shops that are not http://soekris.com/products/net5501.html http://soekris.com/products/net6501.html DES -- Dag-Erling Sm??rgrav - d...@des.no I am NOT able to understand the merit of these products with respect to their features and PRICES . They are extremely stable and robust. It is possible to assemble much more cheaper full featured PC like systems ( DDR3 memory , 64-bit capable processors , with a disadvantage about power requirements ) . You can also get much bigger portions at MacDonald than what you get in a five star restaurant. Soekris boards are perhaps not five star boards but at least they have four :) Although the thread started as an april fools day prank, it's getting serious now about the value of having i386 next to amd64. I'm using quite a number of net4501/net4801/net5501/net6501 in many places just because I haven't found anything that can to the same job with the same reliability at the same low power diet for a reasonable price. For people on a tight budget with lower reliability expectations there are the PC-engines Alix boards. Except for the net6501, none of these can run amd64. Even though the net6501 can run amd64, I prefer running i386 on them (and other boards where I do not need = 4GB of RAM or the large address space) instead of amd64 just because the system image is so much smaller, requiring less storage on your filesystem (often a small flash device), less time to upload changes over the Internet when doing remote upgrades and they are more efficient with virtual memory. Running amd64 when not really needed is just a waste of resources. There have been discussions in the past whether is would make sense to run a 32-bit userland on top of a amd64 kernel sou you can have 4GB of RAM but keep your userland relatively small. There are only few applications that really benefit from 64 bit address space, others could well be 32 bit apps. Just some random numbers to illustrate my point: i386$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc textdata bss dec hex filename 11153310487460 120041 1d4e9 /bin/sh 22808 572 396 237765ce0 /bin/ls 33098 7603392 372509182 /usr/bin/find 3148419376 18204 342421 53995 /usr/bin/cc amd64$ size /bin/sh /bin/ls /usr/bin/find /usr/bin/cc textdata bss dec hex filename 1293711992 10272 141635 22943 /bin/sh 262551144 536 279356d1f /bin/ls 4346413524680 49496c158 /usr/bin/find 383330 15296 58664 457290 6fa4a /usr/bin/cc Kind regards, Paul Schenkeveld ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: preemptive kernel
Thanks John, That is helpful. On Mon, Apr 1, 2013 at 2:33 PM, John Baldwin j...@freebsd.org wrote: On Friday, March 22, 2013 4:10:16 pm vasanth rao naik sabavat wrote: Hi Adrian, Just to clarify, is the kernel pre-emption involuntary? Let say I have a kernel thread processing a huge list of entries, would this thread get involuntarily context switched out because of kernel preemption? What is the time slice after which a kernel thread can involuntarily context switched out? Could you please point to the file in the source code which handles the kernel pre-emption. In-kernel preemption is driven by interrupts, not time slices. If an interrupt arrives that awakens a higher priority thread (e.g. an interrupt thread), or if your thread awakens a thread that has higher priority (e.g. due to wakeup() or cv_signal()), then your thread will be preempted. In general time-based preemptions are only done for user threads. -- John Baldwin -- Thanks, Vasanth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need advice on sys5 shm and zero copy sockets
On 2/8/13 4:22 AM, gary mazzaferro wrote: Hi, I was told to post this question here (Ken Merry), it would be a good place to get some help. I'm not sure this is doable without a kernel module, which I don't want to add. I'll explain what I'm attempting.. I'm designing a high speed rest motor for cloud execution environment. 1) I'd like to eliminate copy from the tcp stack to the application(s). 2) I'm also sharing the buffers across processes and jails. So I'd like to preserve the zero-copy in a msg pipe/unix socket 3) Some buffers will go to disk file systems. Wish list: 4) I'd like it to work with sctp because I like it for local networking :) 5) I'd like to provision memory pools on a per application/connection/ip port basis. Ultimate Goal: 6) Additionally, I'm injecting code from a foreign process into the workflow of another process (state machine). The connection between them will be a signal and shared state information. I'm assuming item (6) is a separate issue, but it may impact the direction.. I've tried shm with zero copy sockets with linux and it just will not work !! BTW, I'm returning to freebsd after far too many years cheers, gary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org this sound somewhat like what I did back in the 90s with BSD4.3 unfortunately it was not done with TCP (or sctp of course) what we did was to create a special shared memeory device driver. Then we added ioctls to the disk driver layer to write named blocks of memory from that device to the raw device (we didin't use a filesystem). We also changed the network drivers to use named blocks of memory in that device for packet reception. We added a special protocol which used recvmsg() and and sendmesg() to pass ownership of those named blocks between the process that had mmapped them and the protocol. The protocol had an IP header but also a small protocol specific header of our own.. we sent packets that were larger than a page. zero copy from disk-process, process-network and network-disk (and reverse of course) of course it was all on proprietary protocols so not of use to you. julian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need advice on sys5 shm and zero copy sockets
On 2 April 2013 20:07, Julian Elischer jul...@freebsd.org wrote: this sound somewhat like what I did back in the 90s with BSD4.3 unfortunately it was not done with TCP (or sctp of course) what we did was to create a special shared memeory device driver. Then we added ioctls to the disk driver layer to write named blocks of memory from that device to the raw device (we didin't use a filesystem). Funny that. I have to do something like this for this software radio NIC, that does a hundred or so megabytes a second of DMA. Eek. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
