Re: Reverse engineering; How to...
On Fri, Mar 30, 2012 at 12:49:31AM -0400, Jason Hellenthal wrote: On Thu, Mar 29, 2012 at 09:20:27AM +0100, Anton Shterenlikht wrote: On Wed, Mar 28, 2012 at 04:33:17PM -0400, Brandon Falk wrote: Reverse engineering a whole driver could take a very long time, even with the proper tools. If it's possible, return the adapter, and buy a new one and verify that the chipset is supported before you buy it. Last time I bought a wireless card I sat in the store looking at the Wireless support list for BSD before buying. http://www.freebsd.org/relnotes/CURRENT/hardware/support.html#WLAN I very strongly suggest that you get a card with an Atheros chipset, as those are by far the best supported on BSD. sure, but how? I've tried very hard to get a pccard with an atheros chip, but you just can't trust the label. Guides like e.g. this: http://atheros.rapla.net/ are unreliable. I've bought several cards, which supposedly have an atheros chip in them, only to discover they had something else inside. Can you recommend a pccard model that is guaranteed to have a supported atheros chip inside? Linksys WMP110 Sorry, I was asking about a Pccard (for a laptop). This is PCI. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: Context Switch
On Thu, Mar 29, 2012 at 7:18 PM, Mahesh Babu maheshbab...@yahoo.co.in wrote: Which part of the source code in FreeBSD 9 is responsible for making context switching i.e. storing and restoring the process state. Context switch is split up in machine indipendent code (MI Code) and machine dependent code (MD Code) For MI part take a look at mi_switch in sys/kern/kern_sync.c sched_switch in sys/kern/sched_ule.c and sys/kern_4bsd.c depending on configurated scheduler in the kernel config file. For MD part search for symbol cpu_switch inside the specific arch directory. -- Gianni ___ 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: Context Switch
On 03/30/12 15:36, Giovanni Trematerra wrote: On Thu, Mar 29, 2012 at 7:18 PM, Mahesh Babumaheshbab...@yahoo.co.in wrote: Which part of the source code in FreeBSD 9 is responsible for making context switching i.e. storing and restoring the process state. Context switch is split up in machine indipendent code (MI Code) and machine dependent code (MD Code) For MI part take a look at mi_switch in sys/kern/kern_sync.c sched_switch in sys/kern/sched_ule.c and sys/kern_4bsd.c depending on configurated scheduler in the kernel config file. For MD part search for symbol cpu_switch inside the specific arch directory. For background information you could read The Book (a bit dated but still quite relevant): http://www.informit.com/store/product.aspx?isbn=0201702452 And you are especially lucky, since the chapter that is the most relevant to you is freely available on-line: http://www.informit.com/articles/article.aspx?p=366888 Kind regards, Hans Ottevanger ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 3/29/2012 7:01 AM, Joe Greco wrote: On 3/28/2012 1:59 PM, Mark Felder wrote: FreeBSD 8-STABLE, 8.3, and 9.0 are untested As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. Doug So you're saying that he should have been using 8.3-RELEASE, then. That isn't what I said at all, sorry if I wasn't clear. The OP mentioned 9.0-RELEASE, and in the context of his message (which I snipped) he mentioned 8-stable. That's what I was referring to. And since both the poster and I made it clear that this doesn't seem to be a case of it fails reliably on a machine of your choosing, just installing random other versions and hoping that it's going to cause a fail ... well, let's just say that doesn't make a whole lot of sense. Or at least it's a recipe for a hell of a lot of busywork, busywork not guaranteed to return any sort of useful result. What you suggest is a fine solution for My ASUS Sempron box fails when I do X! -- in such a case, Try a different version of FreeBSD makes lots of sense. The problem is, in a virtualization environment, theoretically the virtual hosts are all the same sort of hardware (modulo any specific configuration changes of course), so when someone presents a problem that afflicts only a percentage of their VM's, it is important to keep in mind that you are not interacting with physical hardware, and that reinstalling an OS on a problem VM...? Well, let's just say I like real hardware better for many reasons. In the meantime, it's unrealistic to tell people to use supported releases, to wait fifteen months between releases, and then to criticize people complaining about problems with a supported release for using old code. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 19:27:31 -0500, Joe Greco jgr...@ns.sol.net wrote: It also doesn't explain the experience here, where one VM basically crapped out but only after a migration - and then stayed crapped out. It would be interesting to hear about your datastore, how busy it is, what technology, whether you're using thin, etc. I just have this real strong feeling that it's some sort of corruption with the vmfs3 and thin provisioned disk format, but it'd be interesting to know if that's totally off-track. We've ruled out SAN, but we haven't ruled out VMFS. Even FreeBSD Guests on standalone ESXi servers with no SAN exhibit this crash. For the record, we only use thick provisioning and if it was corruption I'm not sure what layer the corruption could be at. The crashy servers show no abnormalities when I run either `freebsd-update IPS` or `pkg_libchk` to confirm checksums of all installed programs. Now the other data on there... it's not exactly verified, but our backups via rsnapshot seem to prove there is no issue there or we'd have lots of new files each run. Crud, there goes part of my theory :-) Have you migrated these hosts, or were they installed in-place and never moved? fwiw the apparent integrity of things on the VM is consistent with our experience too. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Fri, 30 Mar 2012 09:44:47 -0500, Joe Greco jgr...@ns.sol.net wrote: Have you migrated these hosts, or were they installed in-place and never moved? fwiw the apparent integrity of things on the VM is consistent with our experience too. VMMotion and StorageVMMotion does not seem to affect the stability. Even deleting the VM, rebuilding from scratch, re-installing all packages from scratch, copying over a few configs and then copying in any other data (perhaps website data) does not solve the problem. However, our two most notorious for crashing happen to be webservers. We moved one to hardware. We simply rsync'd the exact data (entire OS and files) off the VM onto hardware, made a few config changes (fstab, network interface) and it's been running for 4+ months now with zero crashes. I don't think it's corruption :/ ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Fri, 30 Mar 2012 09:44:47 -0500, Joe Greco jgr...@ns.sol.net wrote: Have you migrated these hosts, or were they installed in-place and never moved? fwiw the apparent integrity of things on the VM is consistent with our experience too. VMMotion and StorageVMMotion does not seem to affect the stability. Even deleting the VM, rebuilding from scratch, re-installing all packages from scratch, copying over a few configs and then copying in any other data (perhaps website data) does not solve the problem. On the same vmdk files? Deleting the VM makes it sound like not. However, our two most notorious for crashing happen to be webservers. We moved one to hardware. We simply rsync'd the exact data (entire OS and files) off the VM onto hardware, made a few config changes (fstab, network interface) and it's been running for 4+ months now with zero crashes. That part doesn't shock me at all. I don't think it's corruption :/ Then it is hard to see what it is. From my perspective: We had a perfectly functional, nearly zero-traffic VM, since Jabber traffic averages no more than a few messages per hour. It was working for quite some time. We moved it from a local datastore to an iSCSI datastore that ended up getting periodically crushed by the load (in particular during the periodic daily load imposed by a bunch of VM's all running at once). At this point, this one VM started hanging on I/O. We expected that this would clear up upon return to a host with a local datastore. It did not. This ended up as a broken VM, one that would hang up overnite, maybe not every night, but several times a week at least. But wait: None of the other VM's, even the VM's that had been abused in this horribly insensitive manner of being placed on intolerably slow iSCSI, developed this condition. There are dozens of other VM's running on these hosts, alongside the one that was exhibiting this behaviour. The VM continued to exhibit this behaviour even after having been moved onto a different ESXi platform and architecture (Opteron-Xeon). For the problem to follow the VM in this manner, and afflict *only* the one VM, strongly suggests that it is something that is contained within the VM files that constitute this VM. That is consistent with the observation that the problem arose at a point where the VM is known to have had all those files moved from one location to a dodgy location. That's why I believe the evidence points to corruption of some sort. Of course, your case makes this all interesting. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Fri, 30 Mar 2012 11:53:10 -0500, Joe Greco jgr...@ns.sol.net wrote: On the same vmdk files? Deleting the VM makes it sound like not. Fresh new VMDK files every time, and always thick provisioned. None of the other VM's, even the VM's that had been abused in this horribly insensitive manner of being placed on intolerably slow iSCSI, developed this condition. We've seen similar results. Baffling how VMs you know are worse off never develop this condition. There are dozens of other VM's running on these hosts, alongside the one that was exhibiting this behaviour. The VM continued to exhibit this behaviour even after having been moved onto a different ESXi platform and architecture (Opteron-Xeon). For the problem to follow the VM in this manner, and afflict *only* the one VM, strongly suggests that it is something that is contained within the VM files that constitute this VM. That is consistent with the observation that the problem arose at a point where the VM is known to have had all those files moved from one location to a dodgy location. We were hoping that was the explanation as well, but rebuilding the VM entirely from scratch on a new host and seeing the crash come back was a big blow to morale. :( That's why I believe the evidence points to corruption of some sort. Of course, your case makes this all interesting. For the last year I've been convinced it's something hidden inside ESXi's I/O virtualization layer that happens to trigger on only certain VMs. ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Mark Felder wrote: On Thu, 29 Mar 2012 12:24:30 -0500, je...@seibercom.net wrote: I just started reading this tread, but I am wondering if I missed something here. What does this have to do with Windows 7? I emailed him off-list but I'm guessing he thought this was on VMWare Workstation or another product that would virtualize FreeBSD on top of Windows as the host OS. ___ Correct...My bad. jim ___ 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: mlock(2) man page errata
mlock(2) says: A single process can mlock() the minimum of a system-wide ``wired pages'' limit and the per-process RLIMIT_MEMLOCK resource limit. Shouldn't this say maximum rather than minimum? I don't think so. The minimum of the two would be the limit that you will hit first, and presumably is the point at which you cannot mlock any more pages. Ok, but can mlock() the minimum of is easy to misread as can mlock() at least. Perhaps it would be more clear to say something like The amount of memory that a process can mlock() is limited by the per-process RLIMIT_MEMLOCK resource limit, and by a system-wide ``wired pages'' limit. ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Subsequent inspection suggested that it was happening during the periodic daily, though we never managed to get it to happen by manually forcing periodic daily, so that's only a theory. Perhaps due to a bunch of VMs all running periodic daily at the same time? We had a perfectly functional, nearly zero-traffic VM, since Jabber traffic averages no more than a few messages per hour. It was working for quite some time. We moved it from a local datastore to an iSCSI datastore that ended up getting periodically crushed by the load (in particular during the periodic daily load imposed by a bunch of VM's all running at once). At this point, this one VM started hanging on I/O. We expected that this would clear up upon return to a host with a local datastore. It did not. This ended up as a broken VM, one that would hang up overnite, maybe not every night, but several times a week at least. ... For the problem to follow the VM in this manner, and afflict *only* the one VM, strongly suggests that it is something that is contained within the VM files that constitute this VM. That is consistent with the observation that the problem arose at a point where the VM is known to have had all those files moved from one location to a dodgy location. That's why I believe the evidence points to corruption of some sort. Compare a backup of the VM before it broke to a backup of the same VM after it broke. Hopefully the haystack of insignificant differences isn't too large, or the significant difference needle might be a lot of fun to find. ___ 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: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
There's no guarantee that upgarding a VM or rebooting it won't change the config of said VM. Don't forget to diff the vm config file.. 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
