We can offer you the new and original IC Parts
Dear Sir and Madam, How are you? I am Cathy,hope everything is ok with you all along ! Now I am writing for keeping in touch with you for further business. if you have any new inquiry about Ics products, welcome here and I will try my best to satisfy you well with competitive price as per your request. our company(www.szmjd.com) have specialized in electronics for over ten years, so we believed that we can provide you the best service in ICs and it is our pleasure to serve your interest. so if any inquiry, please contact us,we will offer you the best price. Thanks and best regard. ShenZhen MingJiaDa Electronics CO.,LTD/ Mingjiada (HK) INDUSTRIAL Co.,Ltd. Add:B.22G Duhui 100 Building ,Zhonghang RD.,Futian ShenZhen China Tel:+86-755-83957301 ,83987616,83957536 61352644 Fax:+86-755-83957753 Email:[EMAIL PROTECTED] MSN : [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: experimental qemu-devel port update, please test!
Juergen Lock wrote: On Sun, Jul 08, 2007 at 01:15:35PM -0500, Eric Anderson wrote: On 07/07/07 09:02, Juergen Lock wrote: In article [EMAIL PROTECTED] you write: On 07/05/07 22:31, Eric Anderson wrote: [...] Although now I have the issue where using kqemu-kmod causes my system to reboot or power off. :( Any ideas? This seems to be a -current issue, it doesn't happen for me at least (6.2 and previously also 6.1.) You could check if it is dependent on the version of the used qemu (the 0.9.0 port, the version of qemu-devel in ports, or the not-yet-committed updated I posted), but I doubt it. What may help is finding out which commit to -current started kqemu to break (find an older version that worked, then binary-search), or at least a backtrace from a kernel compiled without -fomit-frame-pointer (putting DDB in the config seems to do that for amd64 at least, but rebuild the entire kernel.) There also is an open issue for kqemu on amd64 smp, http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 dunno if its related... Juergen My host is i386, SMP, and it also happens with the current qemu-devel port. It must have been something in -CURRENT that changed, probably since May15th-ish. I can't do a binary search anytime soon to find it. In the past, I've recompiled kqemu and that has done the trick. I have all the debugging built in, but that doesn't stop the system from rebooting or powering off. Hmm an UP kernel might be worth a try too... Juergen Hmm - with and without UP, I get a panic, but I managed to catch a panic in _vm_map_lock, something like: _vm_map_lock() vm_map_wire() kqemu_lock_user_page() mon_user_map() I'll try to get a real bt.. Eric ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: experimental qemu-devel port update, please test!
On 07/09/07 08:00, Eric Anderson wrote: Juergen Lock wrote: On Sun, Jul 08, 2007 at 01:15:35PM -0500, Eric Anderson wrote: On 07/07/07 09:02, Juergen Lock wrote: In article [EMAIL PROTECTED] you write: On 07/05/07 22:31, Eric Anderson wrote: [...] Although now I have the issue where using kqemu-kmod causes my system to reboot or power off. :( Any ideas? This seems to be a -current issue, it doesn't happen for me at least (6.2 and previously also 6.1.) You could check if it is dependent on the version of the used qemu (the 0.9.0 port, the version of qemu-devel in ports, or the not-yet-committed updated I posted), but I doubt it. What may help is finding out which commit to -current started kqemu to break (find an older version that worked, then binary-search), or at least a backtrace from a kernel compiled without -fomit-frame-pointer (putting DDB in the config seems to do that for amd64 at least, but rebuild the entire kernel.) There also is an open issue for kqemu on amd64 smp, http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 dunno if its related... Juergen My host is i386, SMP, and it also happens with the current qemu-devel port. It must have been something in -CURRENT that changed, probably since May15th-ish. I can't do a binary search anytime soon to find it. In the past, I've recompiled kqemu and that has done the trick. I have all the debugging built in, but that doesn't stop the system from rebooting or powering off. Hmm an UP kernel might be worth a try too... Juergen Hmm - with and without UP, I get a panic, but I managed to catch a panic in _vm_map_lock, something like: _vm_map_lock() vm_map_wire() kqemu_lock_user_page() mon_user_map() I'll try to get a real bt.. Eric Hmm - I suspect this commit or something near it is the issue: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_map.c.diff?r1=1.384;r2=1.385;sortby=date;f=h;f=u Or the 1.384 - 1.385 change by attilio@ (cc'ed). Eric ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: experimental qemu-devel port update, please test!
Eric Anderson wrote: On 07/09/07 08:00, Eric Anderson wrote: Juergen Lock wrote: On Sun, Jul 08, 2007 at 01:15:35PM -0500, Eric Anderson wrote: On 07/07/07 09:02, Juergen Lock wrote: In article [EMAIL PROTECTED] you write: On 07/05/07 22:31, Eric Anderson wrote: [...] Although now I have the issue where using kqemu-kmod causes my system to reboot or power off. :( Any ideas? This seems to be a -current issue, it doesn't happen for me at least (6.2 and previously also 6.1.) You could check if it is dependent on the version of the used qemu (the 0.9.0 port, the version of qemu-devel in ports, or the not-yet-committed updated I posted), but I doubt it. What may help is finding out which commit to -current started kqemu to break (find an older version that worked, then binary-search), or at least a backtrace from a kernel compiled without -fomit-frame-pointer (putting DDB in the config seems to do that for amd64 at least, but rebuild the entire kernel.) There also is an open issue for kqemu on amd64 smp, http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 dunno if its related... Juergen My host is i386, SMP, and it also happens with the current qemu-devel port. It must have been something in -CURRENT that changed, probably since May15th-ish. I can't do a binary search anytime soon to find it. In the past, I've recompiled kqemu and that has done the trick. I have all the debugging built in, but that doesn't stop the system from rebooting or powering off. Hmm an UP kernel might be worth a try too... Juergen Hmm - with and without UP, I get a panic, but I managed to catch a panic in _vm_map_lock, something like: _vm_map_lock() vm_map_wire() kqemu_lock_user_page() mon_user_map() I'll try to get a real bt.. Eric Hmm - I suspect this commit or something near it is the issue: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_map.c.diff?r1=1.384;r2=1.385;sortby=date;f=h;f=u don't think so, as it just does a 1:1 translation with the old code (passing 0 as argument and casting the return value). What kind of panic it is (what message it prints out)? Attilio ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
PORTS: net/nxserver and net/freenx - heads-up and help needed
PORTS: net/nxserver and net/freenx - heads-up and help needed very quick primer: nx is a great protocol which (among other things) suppresses network packet round-trips, resulting in X/VNC/rdesktop sessions that are quick and responsive over high-latency links. for example, using nx i frequently use 1280x1024 desktops with a 14.4k (and sometimes 9600bps) dial-up connection and find my session completely usable. the actual work is performed by nxserver libraries, and the sessions are handled by the freenx front-end. i am the freebsd ports maintainer for both the net/nxserver and net/freenx ports. due to the low maturity and aggressive growth of the underlying nx technology, i believe it's becoming necessary to split these ports into multiple versions (similar to bash). a few reasons are (more exist): - so far the only version of the nxserver backend i've been able to port completely is 1.4. differences between 1.4/1.5/2.x/3.x make them incompatible with each other. though freenx-0.7.0 has been released, the freenx port is stuck at 0.4.4 due to these incompatibilities. to make matters worse, the nxserver-1.4 port currently refuses to build due to some as of yet unresolved issue with the xorg update. - there is currently no freebsd-native nxclient available, and the only known freebsd-capable client (net/linux-nx-client) is maintained by someone else. the current version of this linux port is incompatible with the 1.4 libraries and freenx 0.4.4 management front-end. - 2x.com offers another linux client, but requires the nxserver-1.5 libraries and updated freenx frontend. - the latest freenx release, 0.7.0, requires nxserver-2.x libraries. - the latest (official) nomachine windows/mac/linux clients require the new nxserver-3.x libraries. so that pretty much explains why i think it'd be a good idea to have different versions of the backend libraries available. the next problem is that i have been unable to understand the code enough to port the newer versions properly to freebsd. i've worked on the 1.5 and 2.x libraries and they mostly compile now, but some of the libraries do not work as expected and must be debugged further. i am a lowly sysadmin and know very little C and even les s about X libraries, which is what these libraries are based on. i've been able to get fairly far (1.4 worked very well, and continues to work well through 6.2-RELEASE) with the help of a few special people and by googling and such. but at this point i'm far enough behind that i may never catch up without help. if you're knowledgeable about C and X, i'd greatly appreciate any help you could provide. one starting point would be the current nxserver-1.4 port. it builds fine with the ports tree prior to the xorg update, and is even available in package form for 6.2-RELEASE. following the xorg update, however, the build fails. i'll try to detail that in another message shortly. another starting point would the 1.5 or 2.1 ports at http://www.deweyonline.com/nx/freebsd.html ... these are both listed as alpha mostly because not all features work yet, though i think they are both fairly close to being finished. thanks for the help so far, and (hopefully) in the future. i can be reached several ways, but for this project i'd prefer the following email address: freenx(at)deweyonline(dot)com ... you can also find me on freenode in #nx as BugeyeD ... -dewey PS - over the years i have hacked together a ton of other sysadmin-type and miscellaneous stuff related to freebsd, a very small amount of which has been put online. feel free to peruse and use/fix/contribute while you're waiting for the nxserver libs to compile. :) the 6.2-release with encrypted root was my latest effort, and i'm happy to say it works great on two desktops and one laptop. http://www.deweyonline.com/freebsd/ -- Only two defining forces have ever offered to die for you, Jesus Christ and the American G.I. One died for your soul, the other for your freedom. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: squidGuard-1.2.0_1
Hello, I was wondering if there are any plans to update the squidGuard port from version 1.2.0_1 to 1.2.1? This would include the LDAP patches. Thanks. Brian E. Conklin, MCP+I, MCSE Director of Information Services voice: 360.427.3423 fax: 360.427.3433 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
field notes - dansguardian and tinyproxy
Just completed a setup of dansguardian w/ tinyproxy on 5.5-RELEASE-p11 and it works pretty well. Performance is a bit lackluster, but acceptable. I noticed that dansguardian requires squid via RUN_DEPENDS but that is a bit inflexible isn't it. I just commented out that line in the Makefile before make install. Dunno if that's the right way but it would be nice to have the option of toggling in tinyproxy (or whatever) instead of squid. Also, tinyproxy wasn't working for me on sparc64, it built/installed fine but using a mostly default config seemed to munge the IP address of the client, making the Allow ACLs in tinyproxy.conf useless. Is than an big vs. little-endian issue? e.g. 192.168.1.9 was being seen as 48.55.32.49 -- Said one park ranger, 'There is considerable overlap between the intelligence of the smartest bears and the dumbest tourists.' Mark D. Foster, CISSP [EMAIL PROTECTED] http://mark.foster.cc/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: field notes - dansguardian and tinyproxy
On July 9, 2007 12:02 pm Mark Foster wrote: Just completed a setup of dansguardian w/ tinyproxy on 5.5-RELEASE-p11 and it works pretty well. Performance is a bit lackluster, but acceptable. I noticed that dansguardian requires squid via RUN_DEPENDS but that is a bit inflexible isn't it. I just commented out that line in the Makefile before make install. Dunno if that's the right way but it would be nice to have the option of toggling in tinyproxy (or whatever) instead of squid. Also, tinyproxy wasn't working for me on sparc64, it built/installed fine but using a mostly default config seemed to munge the IP address of the client, making the Allow ACLs in tinyproxy.conf useless. Is than an big vs. little-endian issue? e.g. 192.168.1.9 was being seen as 48.55.32.49 I've tried getting DansGuardian to work with the latest versions of Tinyproxy, and have never succeeded. Keep getting malformed request responses from Tinyproxy. As such, I haven't changed the DG port to use anything other than Squid. I guess I could add an OPTIONS knob for Squid it, defaulting to on. Those that don't want Squid could disable it. -- Freddie Cash, LPIC-2 CCNT CCLP Network Support Technician School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: experimental qemu-devel port update, please test!
In article [EMAIL PROTECTED] you write: Eric Anderson wrote: On 07/09/07 09:28, Attilio Rao wrote: Eric Anderson wrote: On 07/09/07 08:00, Eric Anderson wrote: Juergen Lock wrote: On Sun, Jul 08, 2007 at 01:15:35PM -0500, Eric Anderson wrote: On 07/07/07 09:02, Juergen Lock wrote: In article [EMAIL PROTECTED] you write: On 07/05/07 22:31, Eric Anderson wrote: [...] Although now I have the issue where using kqemu-kmod causes my system to reboot or power off. :( Any ideas? This seems to be a -current issue, it doesn't happen for me at least (6.2 and previously also 6.1.) You could check if it is dependent on the version of the used qemu (the 0.9.0 port, the version of qemu-devel in ports, or the not-yet-committed updated I posted), but I doubt it. What may help is finding out which commit to -current started kqemu to break (find an older version that worked, then binary-search), or at least a backtrace from a kernel compiled without -fomit-frame-pointer (putting DDB in the config seems to do that for amd64 at least, but rebuild the entire kernel.) There also is an open issue for kqemu on amd64 smp, http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 dunno if its related... Juergen My host is i386, SMP, and it also happens with the current qemu-devel port. It must have been something in -CURRENT that changed, probably since May15th-ish. I can't do a binary search anytime soon to find it. In the past, I've recompiled kqemu and that has done the trick. I have all the debugging built in, but that doesn't stop the system from rebooting or powering off. Hmm an UP kernel might be worth a try too... Juergen Hmm - with and without UP, I get a panic, but I managed to catch a panic in _vm_map_lock, something like: _vm_map_lock() vm_map_wire() kqemu_lock_user_page() mon_user_map() I'll try to get a real bt.. Eric Hmm - I suspect this commit or something near it is the issue: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_map.c.diff?r1=1.384;r2=1.385;sortby=date;f=h;f=u don't think so, as it just does a 1:1 translation with the old code (passing 0 as argument and casting the return value). What kind of panic it is (what message it prints out)? Attilio Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x82 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0928f00 stack pointer = 0x28:0xe57b7a3c frame pointer = 0x28:0xe57b7a50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 69 (qemu) #9 0xc0928f00 in _vm_map_lock (map=0x1, file=0x0, line=0) at /usr/src/sys/vm/vm_map.c:421 #10 0xc092986d in vm_map_wire (map=0x1, start=677306368, end=677310464, flags=1) at /usr/src/sys/vm/vm_map.c:1964 Maybe not that exact file, but I think that series of commits is related. I believe before that everything worked fine (around May 15th or so). What else would you like me to try? Would you see if accesses to map structure are MPSAFE and don't present racy accesses? (Disclaimer: my kernel foo still leaves much to be desired :) Hmm is this something that has changed recently? kqemu has D_NEEDGIANT, and it only explicitly drops giant for kqemu_exec, but this seems to be happening inside kqemu_init already. (at least thats the only place that calls mon_user_map.) kqemu_init, kqemu_exec, and mon_user_map are in work/kqemu-1.3.0pre11/common/kernel.c in the kqemu-kmod port dir if you `make patch' there, kqemu_lock_user_page is in work/kqemu-1.3.0pre11/kqemu-freebsd.c . I also wonder how it is getting map=0x1 there, as you can see in kqemu_lock_user_page it is effectively passing curproc-p_vmspace-vm_map... Hmm I just saw kqemu_exec can call kqemu_lock_user_page as well as kqemu_alloc_zeroed_page and kqemu_unlock_user_page (which are all in work/kqemu-1.3.0pre11/kqemu-freebsd.c ), would it need to pick up giant for those first? (But since mon_user_map is in the backtrace that at least can't be the reason for _this_ crash...) Juergen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: experimental qemu-devel port update, please test!
In article [EMAIL PROTECTED] you write: 2007/7/9, Doug Rabson [EMAIL PROTECTED]: On Monday 09 July 2007, Attilio Rao wrote: 2007/7/9, Eric Anderson [EMAIL PROTECTED]: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x82 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0928f00 stack pointer = 0x28:0xe57b7a3c frame pointer = 0x28:0xe57b7a50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 69 (qemu) #9 0xc0928f00 in _vm_map_lock (map=0x1, file=0x0, line=0) at /usr/src/sys/vm/vm_map.c:421 #10 0xc092986d in vm_map_wire (map=0x1, start=677306368, end=677310464, flags=1) at /usr/src/sys/vm/vm_map.c:1964 Please also note that stack here seems highly corrupted since values passed to _vm_map_lock are not possible (or there is something serious going on with them). I had this exact same crash when attempting to use kqemu on a recent current. It appears as if the value it got for curproc was bad. Is kqemu messing with the kernel's %fs value perhaps? I don't know about kqemu, but in this case I would expect sorta of larger corruption due to the wider pcpu accesses done through %fs. Actually it might use %fs while in the monitor (for running guest code), but if I read the code right it doesn't let host kernel code run while in there (it catches interrupts and leaves the monitor, restoring state, to run them.) Also, it still seems to be in kqemu_init when this happened, and I don't think it enters the monitor from in there already. Juergen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
