Re: Patch for MS Hyper V (virtualization)
On Tue, Apr 7, 2009 at 9:21 AM, John Baldwin j...@freebsd.org wrote: On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: John Baldwin wrote: On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: 2009/4/6 John Baldwin j...@freebsd.org: On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: Hmm, the problem is we need to be able to write to BARs to size them. б Any OS needs to be able to do this to know what address space regions are being decoded by devices. б We can't avoid writing to BARs. I have only vague idea what BARs are and if it's the correct diagnosis in this case, but the fact is that other operating systems (Windows, Linux tested) work, so either there is a way around it or the original premise is wrong-ish. Every OS writes to BARs to size them during boot. It's the defined procedure for sizing them. A BAR is a base address register, and it is how a PCI device gets memory and I/O port resources. OS (or BIOS) writes a starting address into the register to tell the PCI device where a given resource starts. The OS doesn't have to write to the BAR if BIOS has already done it. And the BIOS in the Hyper-V VM is obviously special, so it doesn't trip on iself. Yes it does because we don't know how _big_ the BAR is. The OS has to know if the device is decoding 1MB or 64KB because we need to reserve the entire window to prevent any other devices from using it. We don't just write the existing value, we write all 1's to it and read it back. The lower N bits stick at zero and we use that to figure out the BAR's size. See pci_add_map() in sys/dev/pci/pci.c John is 100% correct. Every kernel PCI driver has to figure out how big the BAR is and IN FACT typically the BIOS assigns more address space than the register set you are mapping. This is straight out of the PCI spec. -aps ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Sun, Mar 29, 2009 at 2:07 PM, Peter Jeremy peterjer...@optushome.com.au wrote: On 2009-Mar-27 14:19:16 -0400, Alexander Sack pisym...@gmail.com wrote: I'm assuming folks are still in love with the TSC because it still the cheapest as oppose ACPI-fast or HPET to even contemplate this? That is its major advantage. It might be feasible to export all the data necessary to implement the complete CLOCK_*_FAST family. Understood. Also I thought at least PHK's comment (Sergey mentioned it) was true regardless of bus, that the TSC is not consistent across multiple packages (and for that matter I suppose cores) due to I *think* its ISA lineage so how does this work again? TSC is nothing to do with ISA. The easiest way to build a counter that runs at CPU clock rate is to put it very close to the CPU/core and have different counters for each CPU/core, without any synchronisation between the different counters. Understood thanks. I don't know why ISA and TSC are in my head. Please excuse. Won't the rate in which you tick up be sporadic over the course of the process scheduled on different cores? (i.e. depending on what core RDTSC happened to land on) RDTSC will wind up on the same core that your thread of execution is running on and this is defined by the scheduler. IE, it's up to the scheduler to ensure that the correct page of global (or per-cpu) data is mapped. OK. But then why not do what I *think* Solaris does in the first place, sync the cores using a master/slave to effectively create an invariant TSC i.e if you are going to buy the overhead in the scheduler why not do the dirty work at the source instead of all this overhead in either the scheduler or the logic to know that this thread of execution was on that core and is using this TSC etc. etc. I believe this topic has been re-hashed before I don't remember the outcome so again excuse... :D Thanks! -aps ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 49cd0405.1060...@samsco.org, Scott Long writes: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. Agreed, that is a good place to start. I'm assuming folks are still in love with the TSC because it still the cheapest as oppose ACPI-fast or HPET to even contemplate this? Also I thought at least PHK's comment (Sergey mentioned it) was true regardless of bus, that the TSC is not consistent across multiple packages (and for that matter I suppose cores) due to I *think* its ISA lineage so how does this work again? Won't the rate in which you tick up be sporadic over the course of the process scheduled on different cores? (i.e. depending on what core RDTSC happened to land on) -aps ___ 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
Building a DDB friendly kernel/drivers?
Hi Folks: I'm debugging an issue with a third-party driver that causes an NMI during driver initialization. It only occurs for one version of the driver thus far. I want to isolate what triggers the NMI and generally get a feel for the initialization of the hardware. I'm running a 6.x-amd64 kernel. Can someone explain to me why when I compile the kernel with default debugging options (makeoptions -g, options DDB/KDB etc. etc.) the kernel comes and boots BUT if I remove -O2 and -frename-registers (in an effort to make text even close to readible), the kernel boots and then double-faults on mounting root? I guess more importantly, what's the RIGHT way to build a DDB/KDB friendly kernel? I thought -O2 and/or -frename-registers could cause DDB to act up but perhaps I'm wrong. Thanks! -aps ___ 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
Long double support in FreeBSD?
Hello: I'm working with building the Boost libraries and Boost.Math has long double support stubbed out for FreeBSD (personally I don't need it but..). I believe looking at some historical threads about this over the weekend and a lot of it was due to compiler GNUish bugs handling long double math (I believe Bruce Evans had some patches at one point but mentioned it was still crappy). Can someone speak if the current compiler/BSD flavors support long double math on a 64-bit capable CPU (LM=1)? Thanks! -aps ___ 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: Long double support in FreeBSD?
On Mon, Mar 23, 2009 at 2:03 PM, David Schultz d...@freebsd.org wrote: On Mon, Mar 23, 2009, Alexander Sack wrote: I'm working with building the Boost libraries and Boost.Math has long double support stubbed out for FreeBSD (personally I don't need it but..). I believe looking at some historical threads about this over the weekend and a lot of it was due to compiler GNUish bugs handling long double math (I believe Bruce Evans had some patches at one point but mentioned it was still crappy). Can someone speak if the current compiler/BSD flavors support long double math on a 64-bit capable CPU (LM=1)? Long doubles are supported, except that long double versions of the following libm functions are missing: acoshl asinhl atanhl cbrtl coshl erfcl erfl expl expm1l lgammal log10l log1pl log2l logl powl sinhl tanhl tgammal The only other caveat is that on i386 we set the FPU to 53-bit precision so that gcc produces saner results in double precision. (See the archives for the gruesome details.) Of course, if you're running FreeBSD/amd64 on a 64-bit machine, this doesn't apply. Thank you so much David, that is what I needed to know (I just thought asking would be easier in this case than trying to parse through the many threads over the past about this topic). -aps ___ 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: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Fri, Oct 24, 2008 at 7:28 PM, Daniel O'Connor [EMAIL PROTECTED] wrote: On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: this will make system trying to bind 32-bit libs to 64-bit program. it can't work rtld shouldn't attempt to bind 32-bit libs to 64-bit programs. The same problem happens with the Linux run time linker - it merrily tries to link FreeBSD libraries to Linux binaries with predictable results.. One trick I use for that is to put a symlink in /compat/linux in the place the problematic FreeBSD library is.. That said it would be really nice if it ignored incompatible libraries :) Yea. Also you go tot realize that if it didn't pick up /usr/lib32 shared objects then /lib would be searched as a last resort I believe since its the default path. As a result, things again would have just worked. Is this a bug or not in FreeBSD's rtld? -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Sat, Oct 25, 2008 at 9:57 AM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Sat, 25 Oct 2008 08:49:19 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Is this a bug or not in FreeBSD's rtld? -aps It is not. In case it was not clear before, I maintain that you _ask_ rtld for wrong behaviour and you get back what you asked for, down to the letter. 'Tasting' libraries just because someone somewhere want to screw up their configuration does not seem right to me at all. I maintain that rtld should not load 32-bit libraries for a 64-bit binary. That is WRONG anyway you look at it. And again, if it checked the arch type and skipped libutil.so.5 in /usr/lib32 it would fall back to checking /lib and things would work. Moreover, if /usr/lib had major number links just like /usr/lib32 has, this would again have worked without issue. I believe this will be fixed on the other side of the fence (not setting LD_LIBRARY_PATH to include /usr/lib32 to begin wtih) but still, my point still stands. -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Hello: I have some weird behavior I'm trying to figure out and was wondering if someone can point me in the right direction. I'm running a FreeBSD 6.1-RELEASE-amd64 machine. If I add /usr/lib32 to my LD_LIBRARY_PATH it breaks all of my binaries on my 64-bit machine. For example: [EMAIL PROTECTED] ~]# file /bin/ls /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped [EMAIL PROTECTED] ~]# ldd /bin/ls /bin/ls: libutil.so.5 = /lib/libutil.so.5 (0x80063) libncurses.so.6 = /lib/libncurses.so.6 (0x80073d000) libc.so.6 = /lib/libc.so.6 (0x800896000) [EMAIL PROTECTED] ~]# ls -l /libexec/ total 306 -r-xr-xr-x 1 root wheel 163864 Aug 21 2007 ld-elf.so.1 -r-xr-xr-x 1 root wheel 146420 Aug 21 2007 ld-elf32.so.1 [EMAIL PROTECTED] ~]# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 [EMAIL PROTECTED] ~]# ls /libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout [EMAIL PROTECTED] ~]# unset LD_LIBRARY_PATH [EMAIL PROTECTED] ~]# ls (normal ls output) [EMAIL PROTECTED] ~]# ls -l /usr/lib/libut* -r--r--r-- 1 root wheel 100518 Aug 21 2007 /usr/lib/libutil.a lrwxrwxrwx 1 root wheel 17 Sep 11 11:44 /usr/lib/libutil.so - /lib/libutil.so.5 -r--r--r-- 1 root wheel 103846 Aug 21 2007 /usr/lib/libutil_p.a [EMAIL PROTECTED] ~]# file /lib/libutil.so.5 /lib/libutil.so.5: ELF 64-bit LSB shared object, AMD x86-64, version 1 (FreeBSD), stripped I would ASSUME that rtld would look at my LD_LIBRARY_PATH and use /usr/lib to find libraries, not /usr/lib32. Why does it insist on picking /usr/lib32 when /bin/ls is CLEARLY a 64-bit binary? This doesn't make complete sense to me just yet. Someone I'm sure is going don't do that and I agree. The issue is I'm porting a library/framework (boost) and it creates a runtime LD_LIBRARY_PATH for its gcc toolchain with the above which breaks the build ROYALLY on FreeBSD 64-bit machine. I'm trying to come up with the right heuristic here. Any help would be much appreciated! Thanks! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, Oct 23, 2008 at 9:23 PM, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: If you look at the rtld(1) man page, there are a number of environment variables you can set to debug the loader. I'm not sure how helpful they are, though. You can rebuild rtld(1) with debugging enabled: % cd /usr/src/libexec/rtld-elf % make clean % make DEBUG_FLAGS=-DDEBUG % make install % echo $LD_LIBRARY_PATH /home/des/lib:/opt/varnish/lib:/usr/local/lib % LD_DEBUG=1 /usr/bin/true /libexec/ld-elf.so.1 is initialized, base address = 0x80050 RTLD dynamic = 0x8006305b0 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libc.so.7 Trying /home/des/lib/libc.so.7 Trying /opt/varnish/lib/libc.so.7 Trying /usr/local/lib/libc.so.7 Trying /lib/libc.so.7 loading /lib/libc.so.7 Ignoring d_tag 1879048185 = 0x6ff9 0x80063b000 .. 0x80085efff: /lib/libc.so.7 checking for required versions initializing initial thread local storage relocating /usr/bin/true relocating /lib/libc.so.7 doing copy relocations initializing key program variables __progname: *0x5005e8 -- 0x7fffebc1 environ: *0x500878 -- 0x7fffe9a8 initializing thread locks calling init function for /lib/libc.so.7 at 0x800664da8 __sysctl in libc.so.7 == 0x80071ae00 in libc.so.7 reloc_jmpslot: *0x800845c78 = 0x80071ae00 transferring control to program entry point = 0x400420 atexit in true == 0x8006fac3e in libc.so.7 reloc_jmpslot: *0x500868 = 0x8006fac3e exit in true == 0x8006af118 in libc.so.7 reloc_jmpslot: *0x500860 = 0x8006af118 __cxa_finalize in libc.so.7 == 0x8006fa940 in libc.so.7 reloc_jmpslot: *0x800846140 = 0x8006fa940 rtld_exit() calling fini function for /lib/libc.so.7 at 0x80071ae60 _exit in libc.so.7 == 0x8006cfff0 in libc.so.7 reloc_jmpslot: *0x8008471d8 = 0x8006cfff0 DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] Thanks, comments most appreciated. Damn, I was looking for someone to go a ha, you can't do this because Alright, let me see why rtld on 6.1-amd64 is picking up /usr/lib32 stuff for a native 64-bit binary via debugging techniques. This seems very very wrong to me. I mean if /usr/lib is in my LD_LIBRARY_PATH and it comes before /usr/lib the /usr/lib32 *should* be innocuous, right? Feel free to use that last statement on my epitaph! :D -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Alright, well I found some weirdness: [EMAIL PROTECTED] ~]# export LD_LIBRARY_PATH=/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 [EMAIL PROTECTED] ~]# LD_DEBUG=1 ls /libexec/ld-elf.so.1 is initialized, base address = 0x800506000 RTLD dynamic = 0x80062ad78 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libutil.so.5 Trying /usr/bin/libutil.so.5 Trying /usr/lib/libutil.so.5 Trying /usr/lib32/libutil.so.5 loading /usr/lib32/libutil.so.5 /libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout That's because libutil.so.5 does not exist in /usr/lib only in /lib. The /usr/lib directory has: [EMAIL PROTECTED] ~]# ls -l /usr/lib/libutil* -r--r--r-- 1 root wheel 100518 Aug 21 2007 /usr/lib/libutil.a lrwxrwxrwx 1 root wheel 17 Sep 11 11:44 /usr/lib/libutil.so - /lib/libutil.so.5 -r--r--r-- 1 root wheel 103846 Aug 21 2007 /usr/lib/libutil_p.a So rtld is looking for major number 5 of libutil, without the standard /lib in my LD_LIBRARY_PATH it searches /usr/lib, doesn't find it but: [EMAIL PROTECTED] ~]# ls -l /usr/lib32/libutil* -r--r--r-- 1 root wheel 65274 Aug 21 2007 /usr/lib32/libutil.a lrwxrwxrwx 1 root wheel 12 Sep 11 11:45 /usr/lib32/libutil.so - libutil.so.5 -r--r--r-- 1 root wheel 46872 Aug 21 2007 /usr/lib32/libutil.so.5 -r--r--r-- 1 root wheel 66918 Aug 21 2007 /usr/lib32/libutil_p.a And whalah, I'm broke since there is a libutil.so.5 in there. So my question to anyone out there, WHY does /usr/lib32 contain major numbers but /usr/lib does not? This seems like a bug to me (FreeBSD 7.0-RELEASE is the same) or at least a dubious design decision. Thanks! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, Oct 23, 2008 at 10:09 PM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Thu, 23 Oct 2008 21:48:47 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Thanks, comments most appreciated. Damn, I was looking for someone to go a ha, you can't do this because Alright, let me see why rtld on 6.1-amd64 is picking up /usr/lib32 stuff for a native 64-bit binary via debugging techniques. This seems very very wrong to me. I mean if /usr/lib is in my LD_LIBRARY_PATH and it comes before /usr/lib the /usr/lib32 *should* be innocuous, right? Feel free to use that last statement on my epitaph! :D LD_LIBRARY_PATH is for native 64bit rtld. If you want a specific path added for use by 32-bit ld-elf.so.1 only, use LD_32_LIBRARY_PATH. Said that, your problem is likely caused by the fact that there is no /lib32, only /usr/lib32. So if 64-bit library lives in /lib, your LD_LIBRARY_PATH will cause loader to find its 32-bit equivalent in /usr/lib32 first. Try LD_LIBRARY_PATH=/lib:/usr/lib:/usr/lib32:/usr/lib64 for better results. Yes I figured that out on my own but my question still exists, why isn't /usr/lib similar in format to /usr/lib32 though with respect to major numbers? Actually now that I re-read your paragraph I suppose this isn't such a bad idea but for some reason I believe that if you have /usr/lib before /usr/lib32 it should *just* work. -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel HEAD userland 7.0-REL?
On Sun, Jul 6, 2008 at 7:43 AM, Robert Watson [EMAIL PROTECTED] wrote: On Fri, 4 Jul 2008, Matthias Apitz wrote: I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my laptops; I've been asked to check if a given driver problem in RELENG_7 is as well with HEAD... can I update the kernel to HEAD and let the userland (and all my compiled ports) as 7.0-REL; I know that this is not the intention, but it would cost me a lot of work if I should compile as well ~200 ports As a general rule, running old userspace on a new kernel works pretty well, but you should expect certain types of things to not work -- for example, monitoring tools that expect the kernel layout of data structures to be unchanged. Within a particular -STABLE branch this is a bit less volatile, but as you go from, say, 6-STABLE to a 7-STABLE kernel, the chances that some of the more obscure options to netstat, etc, will not work are pretty high. Likewise, be careful to disable any third-party kernel modules that may require recompiling but aren't caught by the base system build, or you'll get a nasty surprise when they panic. :-) Robert, really good point. I ran into this exact problem not so long ago (third-party driver not supporting newer kernels, chaos ensued). I also think Mike's nextboot suggestion is one I (and others) should pay attention too. I tend to just install my test kernel blindly and if it fails, reboot and interrupt the boot, etc. - I will use nextboot for sure! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel HEAD userland 7.0-REL?
On Sat, Jul 5, 2008 at 1:16 AM, Matthias Apitz [EMAIL PROTECTED] wrote: El día Friday, July 04, 2008 a las 08:12:58PM -0400, Alexander Sack escribió: On Fri, Jul 4, 2008 at 4:40 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Fri, 4 Jul 2008 14:42:27 +0200 Matthias Apitz [EMAIL PROTECTED] wrote: I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my laptops; I've been asked to check if a given driver problem in RELENG_7 is as well with HEAD... can I update the kernel to HEAD and let the userland (and all my compiled ports) as 7.0-REL; I know that this is not the intention, but it would cost me a lot of work if I should compile as well ~200 ports When you say HEAD, do you mean the HEAD of 8-CURRENT or 7-STABLE? In either case whether or not it works depends on whether something has changed in the kernel that has a required userland change. On the other hand, if you mean 7-STABLE, then the ports should work properly whether userland does or not. As a note, I just recently used HEAD on a 7_STABLE box to test changes recently to re for an updated PCIe revision NIC card on my Eee Box. It worked fine (both runtime and my NIC which I then patched my 7_STABLE tree which also worked, yea!). In a thread I started about cross platform building, it seems that historically FreeBSD has had a very stable ABI allowing multiple kernels to run underneath different versions of user land (this is certainly not the case for all *NIX variants). When I said HEAD, I mean HEAD in terms of CVS; and my situation is the same: I want to check some problem with ath / hal on my eeePC 900, if it is also in HEAD or only in RELENG_7 branch; Like I said, it should work. I did the EXACT same thing on Thursday to check the re driver on my Eee Box at work. -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel HEAD userland 7.0-REL?
On Fri, Jul 4, 2008 at 4:40 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Fri, 4 Jul 2008 14:42:27 +0200 Matthias Apitz [EMAIL PROTECTED] wrote: I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my laptops; I've been asked to check if a given driver problem in RELENG_7 is as well with HEAD... can I update the kernel to HEAD and let the userland (and all my compiled ports) as 7.0-REL; I know that this is not the intention, but it would cost me a lot of work if I should compile as well ~200 ports When you say HEAD, do you mean the HEAD of 8-CURRENT or 7-STABLE? In either case whether or not it works depends on whether something has changed in the kernel that has a required userland change. On the other hand, if you mean 7-STABLE, then the ports should work properly whether userland does or not. As a note, I just recently used HEAD on a 7_STABLE box to test changes recently to re for an updated PCIe revision NIC card on my Eee Box. It worked fine (both runtime and my NIC which I then patched my 7_STABLE tree which also worked, yea!). In a thread I started about cross platform building, it seems that historically FreeBSD has had a very stable ABI allowing multiple kernels to run underneath different versions of user land (this is certainly not the case for all *NIX variants). -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel HEAD userland 7.0-REL?
On Fri, Jul 4, 2008 at 8:27 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Fri, 4 Jul 2008 20:12:58 -0400 Alexander Sack [EMAIL PROTECTED] wrote: On Fri, Jul 4, 2008 at 4:40 PM, Mike Meyer [EMAIL PROTECTED] wrote: On Fri, 4 Jul 2008 14:42:27 +0200 Matthias Apitz [EMAIL PROTECTED] wrote: I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my laptops; I've been asked to check if a given driver problem in RELENG_7 is as well with HEAD... can I update the kernel to HEAD and let the userland (and all my compiled ports) as 7.0-REL; I know that this is not the intention, but it would cost me a lot of work if I should compile as well ~200 ports When you say HEAD, do you mean the HEAD of 8-CURRENT or 7-STABLE? In either case whether or not it works depends on whether something has changed in the kernel that has a required userland change. On the other hand, if you mean 7-STABLE, then the ports should work properly whether userland does or not. As a note, I just recently used HEAD on a 7_STABLE box to test changes recently to re for an updated PCIe revision NIC card on my Eee Box. It worked fine (both runtime and my NIC which I then patched my 7_STABLE tree which also worked, yea!). In a thread I started about cross platform building, it seems that historically FreeBSD has had a very stable ABI allowing multiple kernels to run underneath different versions of user land (this is certainly not the case for all *NIX variants). So stable that the things that break when you try and do this have made it into the FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#NLIST-FAILED Personally, I managed to try this once when the console driver needed a termcap entry change as well :-(. Oh c'mon nowif this is the worst of your problems, then you're doing pretty darn good. I believe Linux binaries rely on the version of glibc, an aux vec entry, and the way the kernel was actually built to figure out whether to use syscall or int to hop into the kernel. I mean things could be a lot worse!! :D! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7 64 bits kernel crash debugging
On Wed, Jul 2, 2008 at 12:50 PM, Fernando Apesteguía [EMAIL PROTECTED] wrote: Hi all, I'm experiencing several kernel crashes with the GENERIC kernel and with custom kernels as well. One of my MP3 players seems to be recognized, but if I disconnect it from the USB port (even without mounting the device), I got a kernel crash. I've tried to follow the instructions at http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html I have dumpdev and dumpdir properly set to my swap partition (ad0s2b) and to /var/crash. However, during the next boot, I got a message that indicates it is looking for a dump on such device but it couldn't find any. How can I track this error? Have you enabled at least KDB/DDB debugger support so you can look at a stack trace (t) and post this? This will at least give us/you some idea on what is crashing... Add minimally to your kernel build conf file: options DDB options KDB Rebuild, reboot, and test. I'm not sure why a crash dump is not working. Have you tried specifying your dump device in your kernel config file? Let us know, -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cross platform building best practices (building 6 on 7)
On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper [EMAIL PROTECTED] wrote: On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack [EMAIL PROTECTED] wrote: Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps (I'll stick to just hackers@ because I don't want to pollute questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). You touched on an important point. There were some code quality issues (I think) with 6.x that were resolved moving to 7.x, which caused gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! gcc-4.2.x requires a newer version of binutils, just because (for API / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. What you should probably do is create a jail then do your development for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) do 8.x development in yet a third. Jail's are a much better way to isolate things such that you don't have to worry about toolchain issues like these and are able to setup a sourcebase as the devs intended it (for the most part; you may run into issues with sysctls and virtual kernel stuff like that, but cest la vie... there isn't a better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b) -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cross platform building best practices (building 6 on 7)
On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer [EMAIL PROTECTED] wrote: Alexander Sack wrote: On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper [EMAIL PROTECTED] wrote: On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack [EMAIL PROTECTED] wrote: Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps (I'll stick to just hackers@ because I don't want to pollute questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). You touched on an important point. There were some code quality issues (I think) with 6.x that were resolved moving to 7.x, which caused gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! gcc-4.2.x requires a newer version of binutils, just because (for API / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. What you should probably do is create a jail then do your development for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) do 8.x development in yet a third. Jail's are a much better way to isolate things such that you don't have to worry about toolchain issues like these and are able to setup a sourcebase as the devs intended it (for the most part; you may run into issues with sysctls and virtual kernel stuff like that, but cest la vie... there isn't a better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b) One thing we always strive for in FreeBSD is an upgrade path. As a general rule, a newer system should be able to run a jail populated with an earlier system. There are some small exceptions, for example you may need a new version of netstat, ps and libkvm in your jail. possibly grab them from the /rescue on the new system so they are statically linked. also 8.x systems will require that threaded programs from 6.x be dynamically linked so that they can be remapped to use libthr instead of libkse as libkse is not supported in 8. So you are talking about binary/ABI compatibility yes? So I would assume what you are saying is I can take a 6.x system, create a filesystem tarball, drop it on a 7.x system
Re: Cross platform building best practices (building 6 on 7)
On Fri, Jun 20, 2008 at 6:02 PM, Julian Elischer [EMAIL PROTECTED] wrote: Alexander Sack wrote: On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer [EMAIL PROTECTED] wrote: Alexander Sack wrote: On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper [EMAIL PROTECTED] wrote: On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack [EMAIL PROTECTED] wrote: Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps (I'll stick to just hackers@ because I don't want to pollute questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). You touched on an important point. There were some code quality issues (I think) with 6.x that were resolved moving to 7.x, which caused gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! gcc-4.2.x requires a newer version of binutils, just because (for API / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. What you should probably do is create a jail then do your development for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) do 8.x development in yet a third. Jail's are a much better way to isolate things such that you don't have to worry about toolchain issues like these and are able to setup a sourcebase as the devs intended it (for the most part; you may run into issues with sysctls and virtual kernel stuff like that, but cest la vie... there isn't a better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b) One thing we always strive for in FreeBSD is an upgrade path. As a general rule, a newer system should be able to run a jail populated with an earlier system. There are some small exceptions, for example you may need a new version of netstat, ps and libkvm in your jail. possibly grab them from the /rescue on the new system so they are statically linked. also 8.x systems will require that threaded programs from 6.x be dynamically linked so that they can be remapped to use libthr instead of libkse as libkse is not supported in 8. So you are talking about binary/ABI compatibility yes? So I would
Cross platform building best practices (building 6 on 7)
Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How do I list what CPU core is on what package?
Hi Everybody: Simple question, if I want to know if a cpu X is on a particular package is there an easy way to list this? Normally my understanding is on most machines, every other LAPIC id is on the same package. So 0,2,4,6 would be on one package and 1,3,5,7 would be on another (say in a 2-way quad-core) and I am assuming (I haven't checked source) that the OS lists them in LAPIC order. Thanks! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CopyOut Size Limits
On Fri, Apr 25, 2008 at 9:59 AM, Adam [EMAIL PROTECTED] wrote:
Hi, I am writing a custom system call that needs to transfer 16kb of data
from the kernel to userspace. I am transferring the data out of the kernel
by using copyout. This seems to work for a small struct of data 4k.
int my_system_call(struct thread *td, struct my_system_call_args *uap)
{
my_structtype_t my_type;
copyout(my_type,uap-my_type,sizeof(my_type) ))!=0)
{
printf(\n copyout failed ret%d\n,error);
return error;
}
printf(exiting kernel %d\n,error);
return (0);
}
However once I expand my struct size beyond around 4k that I get a Fatal
Double Fault. It seems like I am overrunning the kernel stack. Does
copyout use memory from the kernel stack? What is the limit for copyout?
Is there some way to allocate additional space? Alternatively what is the
appropriate method for transferring kbs of data from kernel to userspace?
Thanks,
Adam
Adam,
I have no idea the context and Joerg hit it on the head but have you
considered using shared memory instead of a system call to achieve
what you want?
shmat(2) and its elk?
Thanks!
-aps
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
bge dropping packets issue
Hello: Sorry for cross posting but this seems to be both a driver and network/kernel issue so I figure I actually thought all lists seemed appropriate. I'm investigating an issue we are seeing with 6.1-RELEASE and the bge driver dropping packets sporadically at 100MBps speed. The machine is a 2-way Intel dual-core running 64-bit FreeBSD-6.1 Release with SMP/8GB RAM. I would post dmesg but currently I'm running a test and has a lot of instrumentation in it. Anyway, what I'm seeing with a SmartBit traffic generator connected to 4 bge cards (all BCOM_DEVICEID_BCM5704C) is sporadic packet drops as recorded by the firmware in its statistics structure (as pulled out by bge_tick()), i.e. this isn't malloc starvation of allocating mbuf clusters, etc. The firmware seems to just drop packets occasionally (depending on workload). Its get mainly aggravated when heavy disk I/O occurs from generating a network report which entails gzip'ing a very large dumpfile in /tmp and then anonymously ftping it via another interface (em). DEVICE_POLLING is being used: # sysctl -a | grep kern.polling kern.polling.idlepoll_sleeping: 1 kern.polling.stalled: 3 kern.polling.suspect: 1023 kern.polling.phase: 0 kern.polling.enable: 1 kern.polling.handlers: 6 kern.polling.residual_burst: 0 kern.polling.pending_polls: 0 kern.polling.lost_polls: 24436 kern.polling.short_ticks: 592 kern.polling.reg_frac: 20 kern.polling.user_frac: 50 kern.polling.idle_poll: 0 kern.polling.each_burst: 32 kern.polling.burst_max: 1000 kern.polling.burst: 1000 After looking at the driver for a bit, I believe the issue maybe from RX chain starvation which causes the firmware to drop packets when bge_rxeof() can not keep up. The driver uses a global locking scheme which may contribute to some of these robustness issues (this is a generalization on my part without hard facts so take it with a grain of salt, I just notice things like bge_tick() being called every cycle and competing with the ISR when it may not have too or may not have too for its entire duration, updating stats for example). My main question is currently the RX chain slots are set to a global define BGE_SSLOTS (if_bgedevreg.h) which is 256. Technically this card I believe can do up to 512 slots and the comment above said these are tunable yet not exposed via SYSCTL. Does anyone know why its not 512 by default? Is there any harm in setting it to 512 instead of 256? Why not make it tunable (512 as max)? I've increased the SSLOTS to 512 so there are more RX chain slots available (as I currently understand it, I don't have specs) and the kern.polling.each_burst to 150 (max) in an effort to try to keep the BGE driver in bge_rxeof() and to experiment a bit! This is the first exposure to this code so be gentle! :D! Has anyone seen this problem before with bge? Am I barking up the wrong tree with my initial investigation? Does anyone know if its even possible to achieve 100% packet capture with bge at its supported speeds (10/100/1000)? Thanks! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge dropping packets issue
Dieter: Thanks, at 20Mbps! That's pretty aweful. JK: Thanks again. Wow, I searched the list and didn't see much discussion with respect to bge and packet loss! I will try the rest of that patch including pushing the TCP receive buffer up (though I don't think that's going to help in this case). The above is based on just looking at code I guess some follow-up questions would be: 1) Why isn't BGE_SSLOTS tunable (to a point)? Why can't that be added the driver? I noticed that CURRENT has added a lot more SYSCTL information. Moreover it seems the Linux driver can set it up to 1024. 2) bge_tick() uses the same global mutex for its callout as the rest of the driver. Moreover, it really doesn't have to hold it while updating statistics, they are reads of volatile registers anyway (blocking the ISR doesn't prevent the firmware from updating its stat struct). Would there be any interest in using a separate mutex for the callout itself and then just hold the lock for the other small calls (bge_asf_driver_up(), bge_watchdog())? I'm experimenting with right now just dropping the BGE mutex around the bge_stats_update() calls to give more time to bge_rxeof() to drain rx_bd's. I admit that bge_tick doesn't do a whole lot but it seems this driver is very sensitive to resource starvation and I'm trying to get the BGE driver to drain as much rx_bd's as possible to avoid drops due to the firmware having no place to put them! 3) How does interrupt non-DEVICE_POLLING perform? Thanks guys! -aps On Wed, Apr 16, 2008 at 5:32 AM, Dieter [EMAIL PROTECTED] wrote: I'm investigating an issue we are seeing with 6.1-RELEASE and the bge driver dropping packets sporadically at 100MBps speed. Its get mainly aggravated when heavy disk I/O occurs Has anyone seen this problem before with bge? Am I barking up the wrong tree with my initial investigation? Does anyone know if its even possible to achieve 100% packet capture with bge at its supported speeds (10/100/1000)? I had a similar problem with bge and 6.0-RELEASE. Bge works great for me in 6.2-RELEASE. So far 7.0-RELEASE looks good as well (bge-wise, I do have unresolved issues with 7). My app is TCP, cranking the TCP receive buffer way up helped, as did turning off Nagle. My bge is 1000, but connected at 100 since that is what the other end is. I saw problems at less than 20 Mbps. There is still a problem that other drivers can lock out bge for too long. For example kern/118093: firewire bus reset. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Stupid driver build/debug questions
Hello: New to the FreeBSD kernel and I'm investigating a driver problem (wasn't sure what list this should go on). I was wondering how to make a driver statically built instead of a loadable module? Is this an artifact of the driver source build or the generic kernel configuration mechanism via options etc.? i.e. does a driver need to use something different than the bsd.kmod.mk template make file to build a static driver. What I am trying to do is break at attach time more easily than stepping through driver_probe_and_attach()/driver_attach_child() until the attach routine gets called. I realize I can add a kdb_enter() but I was trying to do this on a live system without rebuilding the kernel (I understand this contradicts my first question but I still want to know how to build drivers statically). Thanks! -aps -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stupid driver build/debug questions
On Thu, Mar 27, 2008 at 3:25 PM, Julian Elischer [EMAIL PROTECTED] wrote:
Alexander Sack wrote:
Hello:
New to the FreeBSD kernel and I'm investigating a driver problem
(wasn't sure what list this should go on).
I was wondering how to make a driver statically built instead of a
loadable module? Is this an artifact of the driver source build or
the generic kernel configuration mechanism via options etc.? i.e.
does a driver need to use something different than the bsd.kmod.mk
template make file to build a static driver.
What I am trying to do is break at attach time more easily than
stepping through driver_probe_and_attach()/driver_attach_child() until
the attach routine gets called. I realize I can add a kdb_enter() but
I was trying to do this on a live system without rebuilding the kernel
(I understand this contradicts my first question but I still want to
know how to build drivers statically).
put the filennames in /sys/conf/files or files.i386 (or whatever)
at one stage you could also have a files.{CONFIGNAME} but I haven't
tried that for a long time.
Thanks for the response. I will try this but I do have an obvious
question, the build scripts do not need to be edited at all with the
extra directory/files? It will just pickup my driver directory and
link against the kernel automagically?
-aps
--
What lies behind us and what lies in front of us is of little concern
to what lies within us. -Ralph Waldo Emerson
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stupid driver build/debug questions
On Thu, Mar 27, 2008 at 4:39 PM, pluknet [EMAIL PROTECTED] wrote:
On 27/03/2008, Alexander Sack [EMAIL PROTECTED] wrote:
On Thu, Mar 27, 2008 at 3:25 PM, Julian Elischer [EMAIL PROTECTED] wrote:
Alexander Sack wrote:
Hello:
New to the FreeBSD kernel and I'm investigating a driver problem
(wasn't sure what list this should go on).
I was wondering how to make a driver statically built instead of a
loadable module? Is this an artifact of the driver source build or
the generic kernel configuration mechanism via options etc.? i.e.
does a driver need to use something different than the bsd.kmod.mk
template make file to build a static driver.
What I am trying to do is break at attach time more easily than
stepping through driver_probe_and_attach()/driver_attach_child()
until
the attach routine gets called. I realize I can add a kdb_enter()
but
I was trying to do this on a live system without rebuilding the
kernel
(I understand this contradicts my first question but I still want to
know how to build drivers statically).
put the filennames in /sys/conf/files or files.i386 (or whatever)
at one stage you could also have a files.{CONFIGNAME} but I haven't
tried that for a long time.
Thanks for the response. I will try this but I do have an obvious
question, the build scripts do not need to be edited at all with the
extra directory/files? It will just pickup my driver directory and
link against the kernel automagically?
Yes, It will if you add them to standard files list (see conf/files).
(Otherwise if you want it as options directive in your kernel config
than you should mark its module name in conf/files and also put
an appropriate record into conf/options).
Thank you very much, that is what I thought regarding it as an options
directive instead of a driver - I just wanted some validation before
going down that path.
Again, thanks guys,
-aps
--
What lies behind us and what lies in front of us is of little concern
to what lies within us. -Ralph Waldo Emerson
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freebsd 7.0 on ASUS P4R8L - No Disks Found!
I suppose this should go to [EMAIL PROTECTED] But with that said, what mode is your SATA/IDE controller in? If there is an AHCI or Legacy mode, try it again. -aps On Mon, Mar 17, 2008 at 12:42 AM, Eddie Parra [EMAIL PROTECTED] wrote: (Newbie) I have FreeBSD 6.3 working on my Asus AB-2800. I just attempted a fresh install of 7.0 and it couldn't find my disks - No Disks Found! The Motherboard Chipset is ATI RS300 / IXP200. Any suggestions would be appreciated. Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: vkernel GSoC, some questions
On Sun, Mar 16, 2008 at 7:13 PM, Matthew Dillon [EMAIL PROTECTED] wrote: Basically DragonFly has a syscall API that allows a userland process to create and completely control any number of VM spaces, including the ability to pass execution control to a VM space and get it back, and control memory mappings within that VM space (and in the virtual kernel process itself) on a page-by-page basis, so only 'invalid' PTEs are passed through to the virtual kernel by the real kernel and the real kernel caches page mappings with real hardware pmaps. Any exception that occurs within a running VM space is routed back to the virtual kernel process by the real kernel. Any real signal (e.g. the vkernel's 'clock' interrupt) or exception that occurs also forces control to return to the vkernel process. Matt, I'm sorry I'm not trying to hijack this thread but isn't the vkernel approach very similar to VMWare's hosted architecture products (such as Fusion for the Mac and Client Workstation for windows)? As I understand it, they have a regular process like vkernel called vmware-vmx which provides the management of different VM contexts running along side the host OS. It also does a passthrough for invalid PTEs to the real kernel and manages contexts in I believe the same fashion you just described. There is also an I/O subsystem a long side it to reuse the hosted drivers to managed the virtualized filesystem and devices - not sure what Dragon does. I realize that their claim to fame is as you said x86 binary code translations but I believe VMWare's product is very close to what you are describing with respect to vkernels (please correct me if I'm wrong). Its just that this thread has devolved slightly into a hypervisor vs. hosted architecture world and I believe their is room for both. Thanks! -aps -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: vkernel GSoC, some questions
Some interesting reading for anyone who cares: http://citeseer.ist.psu.edu/rd/89980079%2C480988%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs/24361/http:zSzzSzwww.usenix.orgzSzpublicationszSzlibraryzSzproceedingszSzusenix01zSzsugermanzSzsugerman.pdf/venkitachalam01virtualizing.pdf These shortcuts are going to be considerably more efficient, resulting in better performance. It is also the claim to fame that a vkernel architecture has. In fact, XEN is really much closer to a vkernel architecture then it is to a hypervisor architecture. A vkernel can be thought of as the most generic and flexible implementation, with access to many system calls verses the fairly limited set XEN provides, and a hypervisor's access to the same subset is done by emulating hardware devices. I've never used XEN (paravirtualization) but I assume that the target OS then has special system calls or shortcuts to ask the underlying monitor/hypervisor to the right things (like allocate safe (virtual) memory instead of relying on a shadow/trap model etc.). In all three cases the emulated hardware -- disk and network basically, devolves down into calling read() or write() or the real-kernel equivalent. A hypervisor has the most work to do since it is trying to emulate a hardware interface (adding another layer). XEN has less work to do as it is really not trying to emulate hardware. A vkernel has even less work to do because it is running as a userland program and can simply make the appropriate system call to implement the back-end. I'm pretty sure this is what VMWare does for the their hosted product. Its a simple userland process that makes syscalls and traps interrupts which eventually devolve into reads and writes. I believe they do a lot of performance work in interrupt coalescing and doing their darnest to prevent world-wide context switches. There are more similarities then differences. I expect VMWare is feeling the pressure from having to hack their code so much to support multiple operating systems... I mean, literally, every time microsoft comes out with an update VMWare has to hack something new in. it's really amazing how hard it is to emulate a complete hardware environment, let alone do it efficiently. No doubt virtualization is a tough job and I'm wondering if future hardware enhancements will make software like VMWare/vkernel/XEN obsolete in the end. Frankly, I would love to see something like VMWare force an industry-wide API for machine access which bypasses the holy hell of a mess we have with the BIOS, and see BIOSes then respec to a new far cleaner API. The BIOS is the stinking pile of horseshit that has held back OS development for the last 15 years. EFI? Just kidding... -aps -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new SATA chipsets support
On Thu, Mar 13, 2008 at 2:16 PM, Gary Jennejohn [EMAIL PROTECTED] wrote: I can't speak to this, but why not use a board which is already known to work? I'm using a Gigabyte M61P-S3 myself. I think that drivers from ASUS ( http://support.asus.com/download/download.aspx?SLanguage=en-enmodel=M2N-SLI%20Deluxe) may not work with FreeBSD? These are guaranteed not to work, unless you want to port the Linux drivers. I see that 7.0-RELEASE has ATA Nvidia chipset support. Does that not cover the SATA nvidia chipsets of their unified MCP chipset? I'm just curious if this could be fixed by adding this particular chipset PCI information to struct ata_nvidia_ident in sys/dev/ata/ata-chipset.c. It looks MCP55 is certainly supported but again I'm stabbing slightly in the dark since I don't know SATA NV. Sorry if this is totally off. I'm new to the FreeBSD kernel but not SATA driver development in general. Its just a thought... Thanks! -aps -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new SATA chipsets support
On Thu, Mar 13, 2008 at 3:50 PM, Gary Jennejohn [EMAIL PROTECTED] wrote: On Thu, 13 Mar 2008 14:49:52 -0400 Alexander Sack [EMAIL PROTECTED] wrote: On Thu, Mar 13, 2008 at 2:16 PM, Gary Jennejohn [EMAIL PROTECTED] wrote: I can't speak to this, but why not use a board which is already known to work? I'm using a Gigabyte M61P-S3 myself. I think that drivers from ASUS ( http://support.asus.com/download/download.aspx?SLanguage=en-enmodel=M2N-SLI%20Deluxe ) may not work with FreeBSD? These are guaranteed not to work, unless you want to port the Linux drivers. I see that 7.0-RELEASE has ATA Nvidia chipset support. Does that not cover the SATA nvidia chipsets of their unified MCP chipset? I'm just curious if this could be fixed by adding this particular chipset PCI information to struct ata_nvidia_ident in sys/dev/ata/ata-chipset.c. It looks MCP55 is certainly supported but again I'm stabbing slightly in the dark since I don't know SATA NV. Sorry if this is totally off. I'm new to the FreeBSD kernel but not SATA driver development in general. Its just a thought... Well, according to man ata the nforce[23] MCP (among other nvidia chipsets) are supported. My motherboard has MCP61 which works just fine. But I'm no expert on nvidia chip sets and can't really evaluate whether just adding the PCI information will work. Yea I don't know either since I don't have an Nvidia spec laying around in front of me! What I would do is cross reference the PCI BoardId in the Linux SATA NV chipset driver and see if its supported. If so, there is a good chance that by adding the proper PCI information the ata infrastructure would just take over. Again, I don't know the exact MCP this motherboard is using. Cheers! -aps -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
