Re: amr driver broken since March 12
> Danny Braniss wrote: > >> Danny Braniss wrote: > >>> it seems March 12 was a bit off :-) > >>> it took some time, but I managed to close the gap: > >>> 189100 ok > >>> 189150 fails > >>> I will continue tomorrow, but this should be helpful. > >>> > >>> > >> 189150 is in the middle of a big string of related commits. Try > >> updating to the following change numbers and retesting: > >> > >> 189088 > >> 189107 > >> 189161 > >> > >> If the last one does not work, try editing /sys/dev/amr/amr.c to change > >> > >> #define AMR_ENABLE_CAM 1 > >> > >> to > >> > >> #define AMR_ENABLE_CAM 0 > >> > >> Scott > > > > 189161 works, also for the iir > > now what? > > > > Next set to try: > > 189219 broken > 189229 broken any point in going on? danny > 189253 > 189402 > 189531 > 189569 > 189591 > > Scott ___ 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: amr driver broken since March 12
Danny Braniss wrote: Danny Braniss wrote: it seems March 12 was a bit off :-) it took some time, but I managed to close the gap: 189100 ok 189150 fails I will continue tomorrow, but this should be helpful. 189150 is in the middle of a big string of related commits. Try updating to the following change numbers and retesting: 189088 189107 189161 If the last one does not work, try editing /sys/dev/amr/amr.c to change #define AMR_ENABLE_CAM 1 to #define AMR_ENABLE_CAM 0 Scott 189161 works, also for the iir now what? Next set to try: 189219 189229 189253 189402 189531 189569 189591 Scott ___ 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: amr driver broken since March 12
Danny Braniss wrote: Danny Braniss wrote: Danny Braniss wrote: it seems March 12 was a bit off :-) it took some time, but I managed to close the gap: 189100 ok 189150 fails I will continue tomorrow, but this should be helpful. 189150 is in the middle of a big string of related commits. Try updating to the following change numbers and retesting: 189088 189107 189161 If the last one does not work, try editing /sys/dev/amr/amr.c to change #define AMR_ENABLE_CAM 1 to #define AMR_ENABLE_CAM 0 Scott 189161 works, also for the iir now what? Next set to try: 189219 broken 189229 broken Ok, so 189161 works, 189219 doesn't, correct? If so, did you also make the change to amr.c yet? Scott ___ 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: REQUEST FOR TESTERS: `devel/mingw32-gcc'
On Sat, 2009-03-28 at 20:37 -0500, Stephen Montgomery-Smith wrote: > Coleman Kane wrote: > > > I haven't seen any activity on the above email, and I am curious if: > > 1) It was missed (and this really does affect people) > > 2) Nobody cross-compiles using the mingw32-* ports (it is really very > > handy!) > > 3) Nobody really cares that mingw32-gcc will move from 3.4.5 --> 4.2.0 > > > > Please, if this affects you test out the above port tarball! Otherwise, > > this will end up going in and not take into account any problems that > > might arise in your environment. > > > > -- > > Coleman Kane > > > I just saw that this message is about two years old, and that the commit > must have been made years ago. > > Sorry for the noise. Thanks. It was handled off-line and we did the upgrade. -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
On 2009-Mar-27 14:19:16 -0400, Alexander Sack wrote: >On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp 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. gettimeofday is likely to be a mixture of global and per-core data so possibly a 3rd page containing per-core data is warranted. >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. >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. > 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. -- Peter Jeremy pgpBbi5qSVT3w.pgp Description: PGP signature
Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
On 2009-Mar-29 08:35:45 +0800, David Xu wrote: >Julian Elischer wrote: >> interestingly it is even feasible to have a per-thread page.. >> it requires that the scheduler change a page table entry tough. > >I will knock his door at midnight if he added such a heavy weight >task in the scheduler, TLB shutdown is horrible, and big code size >squeezing out data from CPU cache is not idea model. >scheduler should be as simple as just a context switching routine. If the TSC is not consistent between all cores (which is probably the most common situation at present), then using the TSC implies knowing which core you are executing on. From a userland perspective, the easiest way to do this is to have a page of data that varies depending on which core you are executing on. -- Peter Jeremy pgpEvuHXzCTQZ.pgp Description: PGP signature
ping6 and traceroute6 trouble
Hi Current and Hackers, I have only seen this recently and was wondering if anyone else can confirm this as a bug or perhaps a setup problem on my end. I think it started to appear with 8-Current from about the 25th of march. Any time I do a ping6 or traceroute6 I receive an error stating "Invalid value for hints." However, I am able to do all other functions (telnet, ssh, etc.) feathers# ping6 ipv6.google.com ping6: Invalid value for hints feathers# traceroute6 ipv6.google.com traceroute6: Invalid value for hints my If config looks like: re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:1d:7d:07:24:1a inet 78.33.110.3 netmask 0xffe0 broadcast 78.33.110.31 inet6 fe80::21d:7dff:fe07:241a%re0 prefixlen 64 scopeid 0x1 inet6 2001:4d48:ad51:32:21d:7dff:fe07:241a prefixlen 64 autoconf media: Ethernet autoselect (100baseTX ) status: active Thanks in advance, Peg ___ 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: ping6 and traceroute6 trouble
Hi,
> On Sun, 29 Mar 2009 18:26:04 +
> Pegasus Mc Cleaft said:
ken>I have only seen this recently and was wondering if anyone else can
confirm
ken> this as a bug or perhaps a setup problem on my end. I think it started to
ken> appear with 8-Current from about the 25th of march.
ken>Any time I do a ping6 or traceroute6 I receive an error stating
"Invalid
ken> value for hints." However, I am able to do all other functions (telnet,
ssh,
ken> etc.)
ken> feathers# ping6 ipv6.google.com
ken> ping6: Invalid value for hints
ken> feathers# traceroute6 ipv6.google.com
ken> traceroute6: Invalid value for hints
I've committed the change to lib/libc/net/getaddrinfo.c little while
ago that also fixed the problem. Please re-cvsup and try it.
http://svn.freebsd.org/viewvc/base/head/lib/libc/net/getaddrinfo.c?r1=190416&r2=190525&view=patch
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
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 wrote: > On 2009-Mar-27 14:19:16 -0400, Alexander Sack 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"
the web site
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just had to see if I could locate if there was a gnome project page by looking at the FreeBSD web pages. Why don't you try that yourself? I'll tell you, it's really FAR from being obvious. I'm just saying, even if folks don't want to change the web page, then a TOC-like section should be added near the bottom, to make navigation easier. I've tried my own hand at the web page design. I think I only proved to myself that I'm no artist, but it wouldn't maek things TOO ugly just to add a section at the bottom, would it? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknP6s4ACgkQz62J6PPcoOkwzgCfXJtkN/PRNhRqvApSJCzjS6uj vW0An1yPG0wzG3d3i3njO5H3gJ2p8w9I =aBYh -END PGP SIGNATURE- ___ 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: ping6 and traceroute6 trouble
Hi Hajimu, > ken> Any time I do a ping6 or traceroute6 I receive an error stating > "Invalid ken> value for hints." However, I am able to do all other > functions (telnet, ssh, ken> etc.) > > ken> feathers# ping6 ipv6.google.com > ken> ping6: Invalid value for hints > > ken> feathers# traceroute6 ipv6.google.com > ken> traceroute6: Invalid value for hints > > I've committed the change to lib/libc/net/getaddrinfo.c little while > ago that also fixed the problem. Please re-cvsup and try it. > > http://svn.freebsd.org/viewvc/base/head/lib/libc/net/getaddrinfo.c?r1=19041 >6&r2=190525&view=patch Yes, that fixed things nicely. Thank you. Best regards, Peg ___ 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"
Shared Disk/Transactional/Distributed file system (GSoC Proposal)
I have been giving some thought lately on some ideas I would like to do for Google Summer of Code. I haven't posted my application yet, as I hope to get some feedback first. I want to make an OpenVMS inspired file system. The key elements would be record oriented I/O, transaction processing and asynchronous I/O. Ideally, the file system will have redundancy features (for high availability) implemented through clustering. The file system should be a shared disk file system, usable in a SAN environment with multiple clients that use the exported block devices simultaneously. The first design issue is weather spreading the file system over a number of machines on the network is a feature that's relevant today or not. OpenVMS did that and it provided redundancy (you could mirror data between nodes) and performance (multiple machines could be serving you data at the same time). This days people tent to centralize storage in a SAN. The SAN provides it's own redundancy, and so far performance is not an issue, as SANs seem to handle scalability extremely well. Even though the idea of spreading the file system through the network seems to have some potential theoretical performance advantages, the current network throughputs are a bottleneck for taking advantage of it. A current hard drive is faster then Gigabit Ethernet, 10Gigabit which still has a prohibitive price today is easily saturated in a small cluster of only a few machines. Other network technologies are again, prohibitively priced. In the past, you could not put to much storage on one machine, so the ability to spread storage across multiple machines was important, but today storage is almost free and usually you can scale it enough in a SAN. Another question is whether to make it a pure record oriented I/O file system, or also implement traditional I/O. A pure record oriented I/O file system would make the distributed lock manager's job much simpler, as there is a simpler mapping between raw bits from the block device and the resources (files/records/fields) the DLM manages. Of course, the VFS interface would be just for convenience for such a system, as the abstraction it provides would add no value to such a file system. But for such a file system to be really useful needs to be used by the transactional, record oriented I/O API anyway. The other option would be to make it a mixed file system, like Files-11 in OpenVMS, with traditional I/O and record oriented I/O. In that case, I would probably use UFS on-disk structure, so it would be more likely an addition to UFS than a new file system. But then of course, FreeBSD has ZFS which has a really nice layered architecture, so I could just use the ZFS lower layers that deal with block devices and can be used for things like redundancy and implement a file system on this architecture. But FreeBSD also has GEOM, and with some clever programming I can also use that. There are many options of doing things. One other thing I like to address is asynchronous I/O. In a way it's just fancy buffered I/O, but from the perspective of the programmer that uses the API, it is much more than that. There are a lot of cases where you want to make lots of unrelated commits to the resource pool, and this I/O operations rarely fail. Or there is the case where you make a big commit that takes time and you want to make smaller commits in the same time that are more crucial to be finished first than the big one and you don't want the big commit to block the smaller ones. Of course you can solve this issues in multiple ways, but with ASYNC I/O it makes the job much easier to the programmer. You just make transactions, install handlers for Asynchronous System Traps that manage aborted transactions, or finished transactions etc. The AST mechanism works in a way like UNIX signals, but the ASTs don't stop system calls and can be queued with some mechanism. There is also the question about how to solve the issue of cache coherency between different nodes. With ASYNC I/O, caching write operations is not that important, but I think that caching read operations is important. This must be implemented in the distributed lock manager. Simply put, what is not locked by anybody should be current in the local cache and can be accessed from there after you make a request to the DLM and the DLM grants the read lock. The distributed lock manager maintains a directory of requested resources, either in concurrent read mode, concurrent write mode, protected read mode, protected write mode and exclusive lock mode. When transactions are made, it is the responsibility of the DLM to invalidate caches. This implementation is pretty expensive in terms of time spend in the round trip to the DLM, but I think the time necessary to make a request can be less then 0.75ms for LANs, and disk access time is in the order of 5ms for fast disks, so that would not be an issue. >From a high level programmer perspective things work like this: 1) You make a req
Re: Shared Disk/Transactional/Distributed file system (GSoC Proposal)
Aram Havarneanu wrote: I have been giving some thought lately on some ideas I would like to do for Google Summer of Code. I haven't posted my application yet, as I hope to get some feedback first. An interesting idea, but it sounds much too ambitious for a six-week summer project. I suggest you try to come up with something rather a bit smaller. There are a couple of proposals on the FreeBSD Summer of Code site for small projects that deal with filesystem issues. Especially if you've not worked with the FreeBSD kernel before, it's probably advisable to first tackle a small project that would fix some issues with existing file system implementations so you can learn what a real FS implementation looks like. Once you know your way around the kernel and the filesystem interfaces, then there will be plenty of time to tackle designing your own file system from scratch. There's a suggestion on the FreeBSD Summer of Code page, if I recall correctly, to fix some issues with the msdosfs file system implementation, and I seem to recall some people asking recently about zisofs support for the iso9660 driver. Of course, a lot depends on your particular background. You didn't say how much work of this sort you'd done in the past. Cheers, Tim Kientzle ___ 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)
Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will allocate it and put some interesting thing in it by scheduler etcs, these code may be useful. ___ 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)
David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will allocate it and put some interesting thing in it by scheduler etcs, these code may be useful. FYI: http://people.freebsd.org/~davidxu/schedctl/ ___ 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: the web site
On Sun, 29 Mar 2009 17:40:30 -0400 Chuck Robey wrote: > I just had to see if I could locate if there was a gnome project page > by looking at the FreeBSD web pages. Why don't you try that > yourself? I'll tell you, it's really FAR from being obvious. I'm > just saying, even if folks don't want to change the web page, then a > TOC-like section should be added near the bottom, to make navigation > easier. If you click on "site map", at the bottom of the page, the gnome link is on the first line. ___ 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)
David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will allocate it and put some interesting thing in it by scheduler etcs, these code may be useful. FYI: http://people.freebsd.org/~davidxu/schedctl/ reading this quickly, you allocate a separately addressed page for each thread, but, how do you use it? ___ 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)
Julian Elischer wrote: David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will allocate it and put some interesting thing in it by scheduler etcs, these code may be useful. FYI: http://people.freebsd.org/~davidxu/schedctl/ reading this quickly, you allocate a separately addressed page for each thread, but, how do you use it? I store the address in userland TLS area, then get it when I want to check some scheduling informations. ___ 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)
David Xu wrote: Julian Elischer wrote: David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will allocate it and put some interesting thing in it by scheduler etcs, these code may be useful. FYI: http://people.freebsd.org/~davidxu/schedctl/ reading this quickly, you allocate a separately addressed page for each thread, but, how do you use it? I store the address in userland TLS area, then get it when I want to check some scheduling informations. and the scheduler writes out interesting information to that location?... ___ 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)
Julian Elischer wrote: David Xu wrote: Julian Elischer wrote: David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will allocate it and put some interesting thing in it by scheduler etcs, these code may be useful. FYI: http://people.freebsd.org/~davidxu/schedctl/ reading this quickly, you allocate a separately addressed page for each thread, but, how do you use it? I store the address in userland TLS area, then get it when I want to check some scheduling informations. and the scheduler writes out interesting information to that location?... Yes. ___ 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: the web site
RW wrote: On Sun, 29 Mar 2009 17:40:30 -0400 Chuck Robey wrote: I just had to see if I could locate if there was a gnome project page by looking at the FreeBSD web pages. Why don't you try that yourself? I'll tell you, it's really FAR from being obvious. I'm just saying, even if folks don't want to change the web page, then a TOC-like section should be added near the bottom, to make navigation easier. If you click on "site map", at the bottom of the page, the gnome link is on the first line. There is also the handy "search" feature which will tell you the following: Search Results The archive www contains the following items relevant to `gnome': Didn't get what you expected? Look here for searching hints. Return to the search page Nothing found. ___ 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"
