update on dell precision 670 vs em death match
Whatever that last em commit was, it seems to have made the interrupt issues better. It still seems high, but it's a lot better than the 2000/s I was getting before. interrupt total rate irq1: atkbd0 54 0 irq6: fdc010 0 irq14: ata0 16 0 irq15: ata1 47 0 irq16: nvidia0+++1095231677 irq18: uhci2+ 3421 2 irq23: ehci0 1 0 irq48: em0115315 71 cpu0: timer 3230219 1997 cpu1: timer 3228221 1996 Total7672535 4744 -- Russell A. Jackson <[EMAIL PROTECTED]> Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
- Original Message - From: "Scott Long" <[EMAIL PROTECTED]> To: "Mike Tancsa" <[EMAIL PROTECTED]> Cc: "freebsd-net" ; <[EMAIL PROTECTED]>; ; "Jack Vogel" <[EMAIL PROTECTED]> Sent: Saturday, November 11, 2006 8:42 AM Subject: Re: Proposed 6.2 em RELEASE patch Mike Tancsa wrote: At 05:00 PM 11/10/2006, Jack Vogel wrote: On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Hi, The last set of tests I posted are ONLY with what is in today's RELENG_6-- i.e. the latest commit. I did a few variations on the driver-- first with #define EM_FAST_INTR 1 in if_em.c one without and one with polling in the kernel. With a decent packet rate passing through, the box will lockup. Not sure if I am just hitting the limits of the PCIe bus, or interrupt moderation is not kicking in, or this is a case of "Doctor, it hurts when I send a lot of packets through"... "Well, dont do that" Using polling prevents the lockup, but it will of course drop packets. This is for firewalls with a fairly high bandwidth rate, as well as I need it to be able to survive a decent DDoS attack. I am not looking for 1Mpps, but something more than 100Kpps ---Mike Hi, Thanks for all of the data. I know that a good amount of testing was done with single stream stress tests, but it's not clear how much was done with multiple streams prior to your efforts. So, I'm not terribly surprised by your results. I'm still a bit unclear on the exact topology of your setup, so if could explain it some more in private email, I'd appreciate it. For the short term, I don't think that there is anything that can be magically tweaked that will safely give better results. I know that Gleb has some ideas on a fairly simple change for the non-INTR_FAST, non-POLLING case, but I and several others worry that it's not robust in the face of real-world network problems. For the long term, I have a number of ideas for improving both the RX and TX paths in the driver. Some of it is specific to the if_em driver, some involve improvements in the FFWD and PFIL_HOOKS code as well as the driver. What will help me is if you can hook up a serial console to your machine and see if it can be made to drop to the debugger while it is under load and otherwise unresponsive. If you can, getting a process dump might help confirm where each CPU is spending its time. Scott I applied Jack's patch to the em driver and all seemed well until xl was giving me the same issues. Thanks Jack on my machine your first patch looks 100% Since my box does not take too much load and to me a slightly more loaded machine is better than an unstable one i re-complied the kernel without SMP so I have a dual CPU system with only one of the CPU's working. I've smacked it with about 50G of data using samba and FTP and it didn't blink. I am however using a fxp card for the live IP side but the xl's are still in the kernel and getting picked up. I have just not configured them with IP's for traffic. I don't think this is the issue tho. I'd say there's something to do with the SMP code that is causing these issues. I have another box with SMP on it. Same kind of setup with a Tyan Tiger instead of a Thunder motherboard. 2 Fxp NICs in it. Most of the time it's stable but if i throw a lot of traffic at it it locks up too. Next time it does I will post the console message, but there is no warnings about watchdog timeouts far as I can remember. It's running 5.5-RELEASE-p8 with SMP enabled. -Clay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
Mike Tancsa wrote: At 05:00 PM 11/10/2006, Jack Vogel wrote: On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Hi, The last set of tests I posted are ONLY with what is in today's RELENG_6-- i.e. the latest commit. I did a few variations on the driver-- first with #define EM_FAST_INTR 1 in if_em.c one without and one with polling in the kernel. With a decent packet rate passing through, the box will lockup. Not sure if I am just hitting the limits of the PCIe bus, or interrupt moderation is not kicking in, or this is a case of "Doctor, it hurts when I send a lot of packets through"... "Well, dont do that" Using polling prevents the lockup, but it will of course drop packets. This is for firewalls with a fairly high bandwidth rate, as well as I need it to be able to survive a decent DDoS attack. I am not looking for 1Mpps, but something more than 100Kpps ---Mike Hi, Thanks for all of the data. I know that a good amount of testing was done with single stream stress tests, but it's not clear how much was done with multiple streams prior to your efforts. So, I'm not terribly surprised by your results. I'm still a bit unclear on the exact topology of your setup, so if could explain it some more in private email, I'd appreciate it. For the short term, I don't think that there is anything that can be magically tweaked that will safely give better results. I know that Gleb has some ideas on a fairly simple change for the non-INTR_FAST, non-POLLING case, but I and several others worry that it's not robust in the face of real-world network problems. For the long term, I have a number of ideas for improving both the RX and TX paths in the driver. Some of it is specific to the if_em driver, some involve improvements in the FFWD and PFIL_HOOKS code as well as the driver. What will help me is if you can hook up a serial console to your machine and see if it can be made to drop to the debugger while it is under load and otherwise unresponsive. If you can, getting a process dump might help confirm where each CPU is spending its time. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic while starting OpenNTPD
Sources from today, right before the compile. I have paused the virtual machine if someone would like me to issue further db> commands. Thanks, Scott FreeBSD 6.2-PRERELEASE #0: Sat Nov 11 02:47:35 UTC 2006 [EMAIL PROTECTED]:/usr/obj.pfSense/usr/src/sys/pfSense_Dev.6 lock order reversal: (sleepable after non-sleepable) 1st 0xc0a57000 pf task mtx (pf task mtx) @ /usr/src/sys/contrib/pf/net/pf.c:6406 2nd 0xc0a787e4 user map (user map) @ /usr/src/sys/vm/vm_map.c:3074 KDB: stack backtrace: kdb_backtrace(0,,c0b59f08,c0b5b740,c0a03b2c,...) at kdb_backtrace+0x29 witness_checkorder(c0a787e4,9,c09a1f59,c02) at witness_checkorder+0x578 _sx_xlock(c0a787e4,c09a1f59,c02) at _sx_xlock+0x50 _vm_map_lock_read(c0a787a0,c09a1f59,c02,18e17c0,c25846b0,...) at _vm_map_lock_read+0x37 vm_map_lookup(cc1c4a4c,0,1,cc1c4a50,cc1c4a40,cc1c4a44,cc1c4a27,cc1c4a28) atvm_m ap_lookup+0x28 vm_fault(c0a787a0,0,1,0,c2585a80,...) at vm_fault+0x66 trap(cc1c4b14,0,104) at trap+0x65e trap(8,28,28,c27432c4,c26aee00,...) at trap+0x341 alltraps(1,c274e400,cc1c4c5c,0,0) at alltraps+0x1a pfioctl(0,cc1c4c5c,c274e400,1,0) at pfioctl+0x3dd7 pfil_run_hooks(c0b9c720,cc1c4cb0,c274e400,1,0) at pfil_run_hooks+0xc9 ip_input(c2743200) at ip_input+0x274 netisr_unregister(c0b99f78) at netisr_unregister+0x11e netisr_queue(0) at netisr_queue+0x146 ithread_destroy(c2584648,c25af480) at ithread_destroy+0xf6 ithread_destroy(c25648c0,cc1c4d38,c25648c0,c06b4b5c,0,...) at ithread_destroy+0x21b fork_exit(c06b4b5c,c25648c0,cc1c4d38) at fork_exit+0xd0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc1c4d6c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0489090 stack pointer = 0x28:0xcc1c4b54 frame pointer = 0x28:0xcc1c4c1c 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 = 13 (swi1: net) [thread pid 13 tid 13 ] Stopped at pf_test+0x968: cmpl$0,0x104(%eax) db> bt Tracing pid 13 tid 13 td 0xc2585a80 pf_test(1,c274e400,cc1c4c5c,0,0) at pf_test+0x968 pfioctl(0,cc1c4c5c,c274e400,1,0) at pfioctl+0x3dd7 pfil_run_hooks(c0b9c720,cc1c4cb0,c274e400,1,0) at pfil_run_hooks+0xc9 ip_input(c2743200) at ip_input+0x274 netisr_unregister(c0b99f78) at netisr_unregister+0x11e netisr_queue(0) at netisr_queue+0x146 ithread_destroy(c2584648,c25af480) at ithread_destroy+0xf6 ithread_destroy(c25648c0,cc1c4d38,c25648c0,c06b4b5c,0,...) at ithread_destroy+0x21b fork_exit(c06b4b5c,c25648c0,cc1c4d38) at fork_exit+0xd0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc1c4d6c, ebp = 0 --- db> Tracing pid 13 tid 13 td 0xc2585a80 pf_test(1,c274e400,cc1c4c5c,0,0) at pf_test+0x968 pfioctl(0,cc1c4c5c,c274e400,1,0) at pfioctl+0x3dd7 pfil_run_hooks(c0b9c720,cc1c4cb0,c274e400,1,0) at pfil_run_hooks+0xc9 ip_input(c2743200) at ip_input+0x274 netisr_unregister(c0b99f78) at netisr_unregister+0x11e netisr_queue(0) at netisr_queue+0x146 ithread_destroy(c2584648,c25af480) at ithread_destroy+0xf6 ithread_destroy(c25648c0,cc1c4d38,c25648c0,c06b4b5c,0,...) at ithread_destroy+0x21b fork_exit(c06b4b5c,c25648c0,cc1c4d38) at fork_exit+0xd0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc1c4d6c, ebp = 0 --- db> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compiler Options
On Sat, 11 Nov 2006 10:19:42 +1030 "Daniel O'Connor" <[EMAIL PROTECTED]> wrote: > On Saturday 11 November 2006 08:54, Jeremy Chadwick wrote: > > The kernel itself _will not_ use any SSE or MMX operations when > > built. This is because these optimisations are known to break the > > FreeBSD kernel. This applies to all i386 architectures, and > > probably 64-bit architectures too (not sure). > > I think this is mainly because the kernel has no FPU context so you > can't actually use any FPU operation (including SSE & MMX) without > potentially trashing userland data. If I remember correctly, this was the reason why some improvements from DragonFlyBSD were not ported to FreeBSD (or were ported but not committed). There was no conclusive evidence that the speed improvement for some operations would result in a net gain, due to register saving/restoring overhead during context switches. > (I could be wrong but the above is what I remember reading on various > lists over the years :) I think you remember right. Or I remember wrong too :) Joerg -- | /"\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against |0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | XHTML in email |.the next sentence is true. | | / \ and news | .the previous sentence was a lie.| signature.asc Description: PGP signature
Re: Compiler Options
On Saturday 11 November 2006 08:54, Jeremy Chadwick wrote: > The kernel itself _will not_ use any SSE or MMX operations when built. > This is because these optimisations are known to break the FreeBSD > kernel. This applies to all i386 architectures, and probably 64-bit > architectures too (not sure). I think this is mainly because the kernel has no FPU context so you can't actually use any FPU operation (including SSE & MMX) without potentially trashing userland data. Also, the cost of saving/restoring the context is quite high so potential benefits are largely negated. (I could be wrong but the above is what I remember reading on various lists over the years :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpFijRZHCXUv.pgp Description: PGP signature
Re: Running large DB's on FreeBSD
On Tue, 24 Oct 2006, Vivek Khera wrote: On Oct 24, 2006, at 12:27 PM, Nguyen Tam Chinh wrote: The size of your DB is not all that large. There are people running terabyte DB's under postgres. Our big DB is around 60Gb with hundreds of millions of rows spread across dozens of tables which are regularly joined with each other for reports. It is pounded on 24x7 with lots and lots of inserts, updates, and selects going on all the time. Could you share with us your servers' hardware specifics and configuration (tuning) of PostgreSQL? This would help many in making decision. My current favorites are the SunFire X4100 from Sun with an Adaptec 2230SLP dual channel U320 RAID card and a 14+ disk array. These are incredibly stable. The disk arrays I have right now are from Dell, and I would not recommend them. I don't think they're totally U320 compliant as some drives occasionally come up at U160 speed. The Adaptec card is the *only* dual channel U320 SCSI card availble in low-profile size; unfortunately LSI doesn't make a low-profile version of the 320-2X card... I have one box with 4Gb which is good for our smaller databases, and one which we are upgrading from 4Gb to 8Gb next week due to the high load it has. I use 1 disk from each SCSI channel to make a mirrored RAID volume for boot + OS + postgres transaction log, and the remaining disks in RAID10 with the disks on each mirror pair coming from opposite SCSI channels. For the pg configuration, I use this on a 4Gb box: max_connections = 100 shared_buffers = 7 # min 16 or max_connections*2, 8KB each work_mem = 262144 # min 64, size in KB maintenance_work_mem = 524288 # min 1024, size in KB max_fsm_pages = 180 # min max_fsm_relations*16, 6 bytes each vacuum_cost_delay = 25 # 0-1000 milliseconds checkpoint_segments = 256 checkpoint_timeout = 900 effective_cache_size = 27462# `sysctl -n vfs.hibufspace` / 8192 (BLKSZ) random_page_cost = 2 log_min_error_statement = error Thank you very much. And how did you set the semaphore's parameters? Do you have any trick or experience? I just think it's just weird to inceremently increase ipc.shm* and ipc.sem* to get the right values. The documentation of PostGreSQL gives us some examples but without explanation how they found those values. - With best regards, |The Power to Serve Nguyen Tam Chinh| http://www.FreeBSD.org Loc: sp.cs.msu.su | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Debugging a dump - need alternative?
On Fri, Nov 10, 2006 at 05:56:54AM -1000, Robert Marella wrote: > On Fri, 10 Nov 2006 10:33:44 -0500 > Vivek Khera <[EMAIL PROTECTED]> wrote: > > > > > On Nov 10, 2006, at 10:19 AM, Robert Marella wrote: > > > > > Thank you for your response. It seems unlikely that it is the power > > > supply because I can buildworld on the same machine with an i386 > > > install. The only difference is the i386 is on a SATA drive while > > > the AMD64 is on an IDE drive. > > > > The funny thing about hardware failure is that the symptoms often > > make no sense. > > > > Don't rule it out until you test the equipment. > > > I am planning to. > We were also having random crashes (mostly ATA related) on a number of AMD64 boxes here, until it was identified as insufficient powering. So yes, don't rule it out yet. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpuhUJft6p93.pgp Description: PGP signature
Re: EM stability
On 11/10/06, Barry Boes <[EMAIL PROTECTED]> wrote: Luck ran out. Hard "must press the reset button" hang. No console messages. The system was idle at the time. Is there anything you'd like me to do to attempt to narrow down the problem or get debugging output? I do not know if the freeze was related to em or something else. Is this a machine running some graphic head? If not can you see anything on the console? Are you sure the machine is dead, like can you get in over the network... ? One thing I often do when you are dealing with unpredictable hangs is run 'vmstat 3' on one of the virtual terminals. You might also define the kernel debugger into your kernel, its best to have a serial console for this, I've seen the hardware console be locked but the serial will still work. The only way we will track this down is thru repetitive reproduction I'm afraid. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
On Fri, Nov 10, 2006 at 04:28:30PM -0600, Barry Boes wrote: B> B> Luck ran out. Hard "must press the reset button" hang. No console B> messages. The system was idle at the time. B>Is there anything you'd like me to do to attempt to narrow down the B> problem or get debugging output? I do not know if the freeze was B> related to em or something else. In cases like this you need to prepare a kernel with debugger compiled in and try to exit into the debugger, when the hang occurs. You can try keyboard debugger sequence, and if it fails try serial break. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
Luck ran out. Hard "must press the reset button" hang. No console messages. The system was idle at the time. Is there anything you'd like me to do to attempt to narrow down the problem or get debugging output? I do not know if the freeze was related to em or something else. -Barry Barry Boes writes: > > So far so good. I updated to the latest, including jfv's revision > 1.65.2.21 from this AM. > > With the 6.1 ISO distribution, I would get watchdogs within seconds of > starting a file transfer (except giant locked which worked fine). > > With RELENG_6 I've transfered 100's of GB via ftp and NFS over both > ethernet ports and no problems yet. > > Thanks for all the hard work! > Barry > > > > Gleb Smirnoff writes: > > Hello Barry, > > > > On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: > > B>I see you listed on the EM stability issues list. I have a Tyan > > B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes > > B> without EM watchdog resets unless I use giant locks. > > B>Is there any way you'd like me to help you with testing the updated > > B> drivers? > > > > Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new > > kernel and report whether the problem is fixed or not. > > > > You see, I have added a o lot of people and two mailing lists to Cc. > > Please do not remove them, when replying. Thanks! > > > > -- > > Totus tuus, Glebius. > > GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compiler Options
On Fri, Nov 10, 2006 at 11:34:22AM -0800, Jason C. Wells wrote: > I have set CPUTYPE=p3 in make.conf. When I compile my kernel I see > -march=pentium3 as I expect. I also see -mno-mmx and -mno-sse are set > which I do not expect given that -march=pentium3 is used. I presume > that I want MMX and SSE since my processor supports it. What options do > I set and where do I set them to get a kernel properly tuned for pentium3? The kernel will "support" MMX and SSE -- that is, any programs (root or userland) which use MMX/SSE will work just fine. That is: any programs built with gcc can indeed support MMX and SSE operations. The kernel itself _will not_ use any SSE or MMX operations when built. This is because these optimisations are known to break the FreeBSD kernel. This applies to all i386 architectures, and probably 64-bit architectures too (not sure). CPUTYPE=p3 (or pentium4, or any other type) will not change this behaviour. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
At 05:00 PM 11/10/2006, Jack Vogel wrote: On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Hi, The last set of tests I posted are ONLY with what is in today's RELENG_6-- i.e. the latest commit. I did a few variations on the driver-- first with #define EM_FAST_INTR 1 in if_em.c one without and one with polling in the kernel. With a decent packet rate passing through, the box will lockup. Not sure if I am just hitting the limits of the PCIe bus, or interrupt moderation is not kicking in, or this is a case of "Doctor, it hurts when I send a lot of packets through"... "Well, dont do that" Using polling prevents the lockup, but it will of course drop packets. This is for firewalls with a fairly high bandwidth rate, as well as I need it to be able to survive a decent DDoS attack. I am not looking for 1Mpps, but something more than 100Kpps ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compiler Options
On Fri, 10 Nov 2006 11:34:22 -0800 "Jason C. Wells" <[EMAIL PROTECTED]> wrote: > I have set CPUTYPE=p3 in make.conf. When I compile my kernel I see > -march=pentium3 as I expect. I also see -mno-mmx and -mno-sse are > set which I do not expect given that -march=pentium3 is used. I > presume that I want MMX and SSE since my processor supports it. What > options do I set and where do I set them to get a kernel properly > tuned for pentium3? The FreeBSD kernel does not use MMX and SSE registers. That is why they are disabled, regardless of the chosen CPUTYPE. Joerg -- | /"\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against |0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | XHTML in email |.the next sentence is true. | | / \ and news | .the previous sentence was a lie.| signature.asc Description: PGP signature
Re: Compiler Options
Jason C. Wells wrote: I have set CPUTYPE=p3 in make.conf. When I compile my kernel I see -march=pentium3 as I expect. I also see -mno-mmx and -mno-sse are set which I do not expect given that -march=pentium3 is used. I presume that I want MMX and SSE since my processor supports it. What options do I set and where do I set them to get a kernel properly tuned for pentium3? Thanks, Jason C. Wells If i recall correctly, instructions taking advantage of sse, mmx etc. are purposefully disabled in the kernel via the mentioned options. I can not at the moment recall why though. Ordinary userland applications and ports are usually compiled to take advantage of those instructions if the CPU supports them. Regards! //Niclas -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Compiler Options
>From /usr/src/sys/conf/kern.mk:
# On the i386, do not align the stack to 16-byte boundaries. Otherwise GCC
# 2.95 adds code to the entry and exit point of every function to align the
# stack to 16-byte boundaries -- thus wasting approximately 12 bytes of
stack
# per function call. While the 16-byte alignment may benefit micro
benchmarks,
# it is probably an overall loss as it makes the code bigger (less efficient
# use of code cache tag lines) and uses more stack (less efficient use
of data
# cache tag lines). Explicitly prohibit the use of SSE and other SIMD
# operations inside the kernel itself. These operations are exclusively
# reserved for user applications.
#
.if ${MACHINE_ARCH} == "i386" && ${CC} != "icc"
CFLAGS+=-mno-align-long-strings -mpreferred-stack-boundary=2 \
-mno-mmx -mno-3dnow -mno-sse -mno-sse2
INLINE_LIMIT?= 8000
.endif
-Proto
Jason C. Wells wrote:
> I have set CPUTYPE=p3 in make.conf. When I compile my kernel I see
> -march=pentium3 as I expect. I also see -mno-mmx and -mno-sse are set
> which I do not expect given that -march=pentium3 is used. I presume
> that I want MMX and SSE since my processor supports it. What options do
> I set and where do I set them to get a kernel properly tuned for pentium3?
>
> Thanks,
> Jason C. Wells
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Michael Proto| SecureWorks
Unix Administrator |
PGP ID: 5D575BBE | [EMAIL PROTECTED]
***
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Compiler Options
I have set CPUTYPE=p3 in make.conf. When I compile my kernel I see -march=pentium3 as I expect. I also see -mno-mmx and -mno-sse are set which I do not expect given that -march=pentium3 is used. I presume that I want MMX and SSE since my processor supports it. What options do I set and where do I set them to get a kernel properly tuned for pentium3? Thanks, Jason C. Wells ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
At 05:00 PM 11/9/2006, Mike Tancsa wrote: At 10:51 AM 11/9/2006, Scott Long wrote: Mike Tancsa wrote: At 08:19 PM 11/8/2006, Jack Vogel wrote: BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. It certainly does make a difference performance wise. I did some quick testing with netperf and netrate. Back to back boxes, using an AMD x2 with bge nic and one intel box CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.27-MHz 686-class CPU) CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2144.01-MHz 686-class CPU) The intel is a DG965SS with integrated em nic, the AMD a Tyan with integrated bge. Both running SMP kernels with pf built in, no inet6. Intel box as sender. In this test its with the patch from yesterday. The first set with the patch as is, the second test with -DEM_FAST_INTR. Thanks for the tests. One thing to note is that Gleb reported a higher rate of dropped packets with INTR_FAST. He is the only one who has reported this, so I'd like to find out if there is something unique to his environment, or if there is a larger problem to be addressed. There are ways that we can change the driver to not drop any packets at all for Gleb, but they expose the system to risk if there is ever an accidental (or malicious) RX flood on the interface. With a high rate of packets, I am able to live lock the box. I setup the following Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. SMP kernel fastfwd pf ipfw FAST_INTR streams np (Mb) x x x 2 livelock x x xx 2 468 livelock x x 2 453 lost packets, box sluggish x xx 2 lost packets, box sluggish x 2 468 lost packets, box sluggish x x 2 468 livelock x x x 2 468 livelock 2 475 livelock x 2 livelock P 2 OK P x 2 OK P x 2 OK The P is for Uniproc, but with Polling enabled (also kern.polling.idle_poll=1) UP single stream 58Kpps, no polling in kernel [bsd6-32bit]# ./netblast 192.168.44.1 500 10 10 start: 1163184051.627479975 finish:1163184061.628200458 send calls:5869051 send errors: 0 approx send rate: 586905 approx error rate: 0 with polling [bsd6-32bit]# ./netblast 192.168.44.1 500 10 10 start: 1163184606.651001121 finish:1163184616.651288588 send calls:5866199 send errors: 1 approx send rate: 586619 approx error rate: 0 With polling and 2 streams at the same time (a lot of pps! and its still totally responsive!!) [r6-32bit]# ./netblast 192.168.88.218 500 10 10 start: 1163184712.103954688 finish:1163184722.104388542 send calls:4528941 send errors: 0 approx send rate: 452894 approx error rate: 0 [r6-32bit]# [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163184793.172036336 finish:1163184813.173028921 send calls:11550594 send errors: 0 approx send rate: 577529 approx error rate: 0 [bsd6-32bit]# polling, 2 streams at the same time [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163185058.477137404 finish:1163185078.478025226 send calls:11679831 send errors: 0 approx send rate: 583991 approx error rate: 0 [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163185167.969551943 finish:1163185187.970435295 send calls:11706825 send errors: 0 approx send rate: 585341 approx error rate: 0 [bsd6-32bit]# ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Cruel and unusual problems with Proliant ML350
The machine in question has a 2-core Xeon, 2GB RAM and a new ciss-compatible controller, for which I appologise for not remembering the exact model but it's "200-something" with three attached 7.2k RPM SATA drives (so it's probably SAS-compatible) in RAID5, and 128 MB cache with BBU. I'm trying to install FreeBSD 6.2-beta3, and though all hardware is correctly detected, there are some curious problems: - The least problem: drive access is incredibly slow, but since this is a brand new machine and BIOS complains that the BBU is not filled to capacity and the controller is doing some calibration, it doesn't seem serious for now. On one burst I managed to get ~~110 MB/s reads from dd on raw device which is enough. - The less serious problem: It looks like a whole bunch of built-in devices is routed to irq 29: bce, ciss, ohci and ehci. I notice last three are giant locked, which doesn't look good, especially since this should be a loaded web server. I'll get a chance to open it after weekend, but I want to hear advice - does someone have experience with resolving such conflicts on proliants? - The showstopper: Sysinstall completes (though slowly), but on reboot the loader doesn't go further than the "F1 prompt" :( This is very curious, since when booting from install CD the loader shows it recognizes the CD drive and drives A: and C:, so BIOS seems to be ok. If I understand the loader correctly, after the "F1 prompt" phase, the loader should transfer control to the boot block of the first slice? I'll get a chance to work on it some more after weekend (after BBU is charged, hopefully), but this last issue looks like there might be a bug in sysinstall so I'm complaining early. The problems listed appear both on i386 and amd64 install images. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
So far so good. I updated to the latest, including jfv's revision 1.65.2.21 from this AM. With the 6.1 ISO distribution, I would get watchdogs within seconds of starting a file transfer (except giant locked which worked fine). With RELENG_6 I've transfered 100's of GB via ftp and NFS over both ethernet ports and no problems yet. Thanks for all the hard work! Barry Gleb Smirnoff writes: > Hello Barry, > > On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: > B>I see you listed on the EM stability issues list. I have a Tyan > B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes > B> without EM watchdog resets unless I use giant locks. > B>Is there any way you'd like me to help you with testing the updated > B> drivers? > > Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new > kernel and report whether the problem is fixed or not. > > You see, I have added a o lot of people and two mailing lists to Cc. > Please do not remove them, when replying. Thanks! > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding an extra hard disk and adding space to /usr
on 10/11/2006 14:32 Oliver Fromme said the following: > Aaron Burke wrote: > > SNIP > > > >(FreeBSD 4.x) : cd /usr; tar clpf - . | (cd /mnt; tar xvf -) > > > >(FreeBSD 5.x+) : cd /usr; gtar clpf - . | (cd /mnt; gtar xvf -) > > > iirc tar(1) has changed in 5.3. why do you use gtar please? is new tar > > > missing something? > > Well, technically no, but it requires more typing. > > That's why I prefer to use cpio: > > cd /usr; find -dx . | cpio -dump /mnt > > which works on _any_ version of FreeBSD out of the box. $ pax rw /usr /mnt is even less typing and works on any system with POSIX-compliant utilities :-) Not to mention all other goodies that pax provides (I especially like -s option). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
aaccli on recent conrollers?
I have just built a new SunFire X4100 server with an Adaptec 2230SLP RAID card using FreeBSD 6.2-PRE kernel (from September 20). Everything is working extremely well except I cannot run the aaccli utility on this controller. When I try to open the controller, it gives this error: Command Error: current controller software.> On my other X4100 with the same RAID card but FreeBSD 6.0, aaccli works just fine. On my 6.2-PRE with a different aac(4) supported RAID card, it runs fine. There seems to be no difference in the card (other than they added a "R" to the part number to indicate it is compatible with new recycling environmental regulations). This is a HUGE problem since there is no way to probe the system to check on the health of the RAID subsystem disk drives, as aac(4) doesn't log anything to syslog on disk failure or recover, etc. Any help would be appreciated. All I *really* need is a program to tell me if the disk system is degraded (and which drive is bad) or optimal. I don't really need to reconfigure the array. The dmesg on the X4100 where aaccli works has this to say about the aac controller: aac0: mem 0xfe00-0xfe7f, 0xe000-0xefff irq 37 at device 1.0 on pci6 aac0: Enabling 64-bit address support aac0: New comm. interface enabled aac0: Adaptec Raid Controller 2.0.0-1 aacp0: on aac0 aacp1: on aac0 aacd0: on aac0 aacd0: 34699MB (71065344 sectors) aacd1: on aac0 aacd1: 208194MB (426381312 sectors) Trying to mount root from ufs:/dev/aacd0s1a uname -a: FreeBSD d01.m1e.net 6.0-RELEASE-p4 FreeBSD 6.0-RELEASE-p4 #0: Fri Jan 27 13:43:53 EST 2006 [EMAIL PROTECTED]:/n/lorax1/usr6/ obj.amd64/n/lorax1/usr6/src/sys/KCI64SMP amd64 On the new (non-working) system: aac0: mem 0xfe60-0xfe7f, 0xfe8ff000-0xfe8f irq 37 at device 1.0 on pci6 aac0: Enabling 64-bit address support aac0: New comm. interface enabled aac0: Adaptec Raid Controller 2.0.0-1 aacd0: on aac0 aacd0: 34589MB (70838272 sectors) aacd1: on aac0 aacd1: 207594MB (425152512 sectors) Trying to mount root from ufs:/dev/aacd0s1a uname -a: FreeBSD d02.m1e.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Wed Sep 20 23:21:10 EDT 2006 [EMAIL PROTECTED]:/ usr/obj/usr/src/sys/KCI64SMP amd64 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Debugging a dump - need alternative?
On Fri, 10 Nov 2006 10:33:44 -0500 Vivek Khera <[EMAIL PROTECTED]> wrote: > > On Nov 10, 2006, at 10:19 AM, Robert Marella wrote: > > > Thank you for your response. It seems unlikely that it is the power > > supply because I can buildworld on the same machine with an i386 > > install. The only difference is the i386 is on a SATA drive while > > the AMD64 is on an IDE drive. > > The funny thing about hardware failure is that the symptoms often > make no sense. > > Don't rule it out until you test the equipment. > I am planning to. Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Debugging a dump - need alternative?
On Nov 10, 2006, at 10:19 AM, Robert Marella wrote: Thank you for your response. It seems unlikely that it is the power supply because I can buildworld on the same machine with an i386 install. The only difference is the i386 is on a SATA drive while the AMD64 is on an IDE drive. The funny thing about hardware failure is that the symptoms often make no sense. Don't rule it out until you test the equipment.
Re: Debugging a dump - need alternative?
On Fri, 10 Nov 2006 11:48:40 +0200 Andrei Kolu <[EMAIL PROTECTED]> wrote: > On Friday 10 November 2006 03:45, Robert Marella wrote: > > Aloha All > > > > One of my computers has an Asus A8N-VM motherboard. I have been > > running i386 on it for nearly a year. I played around with AMD64 > > earlier stuck with the i386. > > > > Last week I set up a dual boot with i386 and AMD64. The i386 is on a > > SATA drive and I installed 6.2 Beta 3 on and IDE Drive. All went > > well and I was installing ports from source. When I tried to > > install K3B it crashed. > > > > I then cvsup'd the source (RELENG_6) and tried to update the > > system. It was compiling for a few minutes and dumped again. I set > > "dumpdev" and "dumdir" in rc.conf and proceded again. It crashed > > and the dump was saved. > > > > Here's my problem: Since this was the first time I was building the > > world, I cannot cd to /usr/obj/usr/src/sys/KERNCONF because it > > doesn't exist. > > > > I went to the i386 slice and did the upgrade (also RELENG_6) without > > any problem. This seems to tell me that memory is good (2 Gig) and > > I am not overheating. > > > > I mounted the partition for the IDE that has the crash and tried to > > read it from the i386 but it can't do it. > > > > Is there some other way for me to debug the dump? This is the only > > AMD64 system that I have. > > > > All help is appreciated. TIA > > > > Robert > > I had exactly the same problem with couple of AMD64 computers (random > crashes during buildworld) and believe it or not- troublemaker was > PSU (Power Supply Unit) Chieftech 410W if I remember correctly (it > works just fine with Intel counterparts). Andrei Thank you for your response. It seems unlikely that it is the power supply because I can buildworld on the same machine with an i386 install. The only difference is the i386 is on a SATA drive while the AMD64 is on an IDE drive. I will try another power supply just to make sure but I will not be able to do anything until Monday or Tuesday. I am heading out in an hour to relax and camp and hike at Volcanoes National Park. Thanks again for your reply and have a great weekend. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
Hello Barry, On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: B>I see you listed on the EM stability issues list. I have a Tyan B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes B> without EM watchdog resets unless I use giant locks. B>Is there any way you'd like me to help you with testing the updated B> drivers? Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new kernel and report whether the problem is fixed or not. You see, I have added a o lot of people and two mailing lists to Cc. Please do not remove them, when replying. Thanks! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb serial lockup
Ian Smith wrote:
> On Fri, 10 Nov 2006, Vince wrote:
>
> >I have a bit of a wierd problem, My laptop has no serial ports, as is
> > the norm these days, so i have a FTDI based usb serial connector which
> > is very handy and works well. However, what i have found is that freebsd
> > still detects a serial port anyway
> >
> > sio0: configured irq 4 not in bitmap of probed irqs 0
> > sio0: port may not be enabled
> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> > sio0: type 8250 or not responding
> > sio1: configured irq 3 not in bitmap of probed irqs 0
> > sio1: port may not be enabled
> >
> > and if i'm careless and type tip com1 ( or use minicom on /dev/{ttyd0,
> > cuad0} as root or as a user I hard lock my laptop, nothing responding
> > and i have to powercycle it. this is 100% reproducable.
>
> add to /boot/loader.conf (ditto for sio.1 wouldn't hurt):
>
> hint.sio.0.disabled=1
>
Yeah that would work. didnt even think to look there.
Doh.
cheers,
Vince
> Ian
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding an extra hard disk and adding space to /usr
Aaron Burke wrote: > SNIP > > >(FreeBSD 4.x) : cd /usr; tar clpf - . | (cd /mnt; tar xvf -) > > >(FreeBSD 5.x+) : cd /usr; gtar clpf - . | (cd /mnt; gtar xvf -) > > iirc tar(1) has changed in 5.3. why do you use gtar please? is new tar > > missing something? > Well, technically no, but it requires more typing. That's why I prefer to use cpio: cd /usr; find -dx . | cpio -dump /mnt which works on _any_ version of FreeBSD out of the box. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb serial lockup
On Fri, 10 Nov 2006, Vince wrote:
> I have a bit of a wierd problem, My laptop has no serial ports, as is
> the norm these days, so i have a FTDI based usb serial connector which
> is very handy and works well. However, what i have found is that freebsd
> still detects a serial port anyway
>
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> sio0: type 8250 or not responding
> sio1: configured irq 3 not in bitmap of probed irqs 0
> sio1: port may not be enabled
>
> and if i'm careless and type tip com1 ( or use minicom on /dev/{ttyd0,
> cuad0} as root or as a user I hard lock my laptop, nothing responding
> and i have to powercycle it. this is 100% reproducable.
add to /boot/loader.conf (ditto for sio.1 wouldn't hurt):
hint.sio.0.disabled=1
Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb serial lockup
At 07:17 AM 11/10/2006, Vince wrote: Hi All, I have a bit of a wierd problem, My laptop has no serial ports, as is the norm these days, so i have a FTDI based usb serial connector which is very handy and works well. However, what i have found is that freebsd still detects a serial port anyway sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled What happens if you disable the bogus port in /boot/device.hints ? ie. add hint.sio.0.disabled="1" ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
usb serial lockup
Hi All,
I have a bit of a wierd problem, My laptop has no serial ports, as is
the norm these days, so i have a FTDI based usb serial connector which
is very handy and works well. However, what i have found is that freebsd
still detects a serial port anyway
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
and if i'm careless and type tip com1 ( or use minicom on /dev/{ttyd0,
cuad0} as root or as a user I hard lock my laptop, nothing responding
and i have to powercycle it. this is 100% reproducable.
I'm pretty sure this isnt expected behaviour, and it has happened from
6.1 through 6-Stable to my latest update (possibly before but i havent
tested:)
6.2-PRERELEASE #12: Mon Nov 6 15:01:21 GMT 2006
any suggestions as to what i can do about it? (other than watch my
typing, if thats the only answer i can live with it though;)
Vince
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux-firefox
On Thu, 9 Nov 2006, Minette Pamela wrote: Ppass on Q1 .. what Vladimir said. > Now, maybe is somehow related to the errors I always get when I try > to download files or open files from the linux-firefox browser like : > "/tmp/, could not be saved, because you cannot change the > contents of the folder. Change the folder properties and try again, > or try saving in a different location". Hmm, any user should be able to write to /tmp safely as long as its sticky bit is set (default). Does 'ls -lad /tmp/' say something like? drwxrwxrwt 13 root wheel 1536 Nov 10 03:12 /tmp/ Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb to serial
On Fri, 10 Nov 2006, 11:09-, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Hans Petter Selasky writes: > >On Friday 10 November 2006 10:08, Maxim Konovalov wrote: > >> The second question: is it OK to commit uark(4) as is and then convert > >> it to the new model? > > > >I would prefer no. It is better to commit "uark(4)" to the USB p4 project, > >than HEAD, because then we don't have to worry about integrating the driver. > > If the driver works, then there should be no need to hold off on > committing it to -CURRENT. Having it in -CURRENT now allows it to > be MFC'd to RELENG_6 sooner. From a quick glance it looks fine to > me, so I'd say just go ahead and commit it Maxim. Yes, it works. I'd prefer to commit it first and then adopt for a new model too. Thank you both! -- Maxim Konovalov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb to serial
In message <[EMAIL PROTECTED]>, Hans Petter Selasky writes: >On Friday 10 November 2006 10:08, Maxim Konovalov wrote: >> The second question: is it OK to commit uark(4) as is and then convert >> it to the new model? > >I would prefer no. It is better to commit "uark(4)" to the USB p4 project, >than HEAD, because then we don't have to worry about integrating the driver. If the driver works, then there should be no need to hold off on committing it to -CURRENT. Having it in -CURRENT now allows it to be MFC'd to RELENG_6 sooner. From a quick glance it looks fine to me, so I'd say just go ahead and commit it Maxim. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb to serial
[...] > > The second question: is it OK to commit uark(4) as is and then convert > > it to the new model? > > I would prefer no. It is better to commit "uark(4)" to the USB p4 project, > than HEAD, because then we don't have to worry about integrating the driver. > > I looked at your uark.diff, and it shouldn't be too difficult to port it to > the new USB architecture. > > Have a look at "ufoma.c": > > http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ufoma.c > > >From what I can see you need to: > > Make a config thread, from where you do the configuration. You should not call > usbd_do_request() directly from the ucom callbacks! > > Add config for the USB BULK transfers needed. > > And a little more. Thanks for the tips! > Do you have hardware that you can test the UARK driver with? Alex does, I don't. -- Maxim Konovalov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb to serial
On Friday 10 November 2006 10:08, Maxim Konovalov wrote: > Hi Hans, > > On Fri, 10 Nov 2006, 08:38+0100, Hans Petter Selasky wrote: > > On Thursday 09 November 2006 18:29, Maxim Konovalov wrote: > > > [ iedowse CC'ed ] > > > > > > Hello, > > > > > > On Fri, 5 May 2006, 11:04-0400, David Coder wrote: > > > > thx for the suggestions, guys. with > > > > > > > > device uftdi > > > > device uplcom > > > > > > > > in the kernel config the adapter shows up as > > > > > > > > ugen0: ArkMicroChips USB-UART Controller, rev 1.10/0.01, addr 2 > > > > > > > > no specific com port shows up, however, so i must need something > > > > else. > > > > > > Alex Rodin have ported uark(4) driver from OpenBSD. I made code > > > cleanup and intergation in the tree. You can get&test patches for > > > HEAD and RELENG_6 there: > > > > > > http://maxim.int.ru/stuff/uark.diff > > > http://maxim.int.ru/stuff/uark.diff.6 > > > > > > Ian, could you please review the patches? > > > > Hi, do you think that you could also port the serial driver to the new > > USB stack, and send me a patch file? > > > > Please see: > > > > http://www.turbocat.net/~hselasky/usb4bsd > > > > Download the SVN version, and type "svn diff" to generate a patch when > > you are finished. Look at the other serial drivers in my SVN tree, how > > the USB/UCOM stuff is done. > > Are there any correlations with p4://depot/projects/usb? Yes, it is the same. > > The second question: is it OK to commit uark(4) as is and then convert > it to the new model? I would prefer no. It is better to commit "uark(4)" to the USB p4 project, than HEAD, because then we don't have to worry about integrating the driver. I looked at your uark.diff, and it shouldn't be too difficult to port it to the new USB architecture. Have a look at "ufoma.c": http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ufoma.c From what I can see you need to: Make a config thread, from where you do the configuration. You should not call usbd_do_request() directly from the ucom callbacks! Add config for the USB BULK transfers needed. And a little more. Do you have hardware that you can test the UARK driver with? --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux-firefox
Install flash plugin from the port. "cd /usr/ports/www/linux-flashplugin7 & make install". In firefox options change the default download directory to where you can write. HTH,-vlado On Thu, 9 Nov 2006, Minette Pamela wrote: hi, i got this problem with linux-firefox. I Installed it before in my KDE in FreeBSD with no problems and been able to use flash plugins. Then, I changed to Gnome recently and installed linux-firefox. Now, when I tried to install plugins by clicking on a site with a plugin requirement, I was successfully directed to "agreement" stuff but I would get an error of "No plugin installed". Now, maybe is somehow related to the errors I always get when I try to download files or open files from the linux-firefox browser like : "/tmp/, could not be saved, because you cannot change the contents of the folder. Change the folder properties and try again, or try saving in a different location". I would appreciate if you could help me with these 2 problems. Thanks... newbe Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR with today's RELENG_6
On Thu, 9 Nov 2006, Vlad Galu wrote: -- cut here -- lock order reversal: 1st 0x80501ba0 cdev (cdev) @ kern/kern_conf.c:61 2nd 0x858d20f8 sleep mtxpool (sleep mtxpool) @ kern/kern_prot.c:1877 isn't that http://sources.zabbadoz.net/freebsd/lor.html#187 ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: adding an extra hard disk and adding space to /usr
SNIP > >(FreeBSD 4.x) : cd /usr; tar clpf - . | (cd /mnt; tar xvf -) > >(FreeBSD 5.x+) : cd /usr; gtar clpf - . | (cd /mnt; gtar xvf -) > iirc tar(1) has changed in 5.3. why do you use gtar please? is new tar > missing something? Well, technically no, but it requires more typing. gtar supports the same flags that were present on FreeBSD up till 4.x (or as you say, perhaps as late as 5.3). However, the more typical tar now has a completly undesired effect. The main difference is how the 'l' flag is treated. excerpt from tar man page: BUGS POSIX and GNU violently disagree about the meaning of the -l option. Because of the potential for disaster if someone expects one behavior and gets the other, the -l option is deliberately broken in this implementa- tion. another excerpt from the tar man page. (FreeBSD 5.4-Release): -l If POSIXLY_CORRECT is specified in the environment, this is a synonym for the --check-links option. Otherwise, an error will be displayed. Users who desire behavior compatible with GNU tar should use the --one-file-system option instead. excerpt from gtar man page (FreeBSD 5.4-Release): -l --one-file-system Stay in local file system when creating an ar- chive (do not cross mount points). > cheers, > > martin SNIP -- Aaron Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Debugging a dump - need alternative?
On Friday 10 November 2006 03:45, Robert Marella wrote: > Aloha All > > One of my computers has an Asus A8N-VM motherboard. I have been running > i386 on it for nearly a year. I played around with AMD64 earlier stuck > with the i386. > > Last week I set up a dual boot with i386 and AMD64. The i386 is on a > SATA drive and I installed 6.2 Beta 3 on and IDE Drive. All went well > and I was installing ports from source. When I tried to install K3B it > crashed. > > I then cvsup'd the source (RELENG_6) and tried to update the system. It > was compiling for a few minutes and dumped again. I set "dumpdev" and > "dumdir" in rc.conf and proceded again. It crashed and the dump was > saved. > > Here's my problem: Since this was the first time I was building the > world, I cannot cd to /usr/obj/usr/src/sys/KERNCONF because it doesn't > exist. > > I went to the i386 slice and did the upgrade (also RELENG_6) without > any problem. This seems to tell me that memory is good (2 Gig) and I am > not overheating. > > I mounted the partition for the IDE that has the crash and tried to > read it from the i386 but it can't do it. > > Is there some other way for me to debug the dump? This is the only > AMD64 system that I have. > > All help is appreciated. TIA > > Robert I had exactly the same problem with couple of AMD64 computers (random crashes during buildworld) and believe it or not- troublemaker was PSU (Power Supply Unit) Chieftech 410W if I remember correctly (it works just fine with Intel counterparts). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux-firefox
On Thu, 9 Nov 2006 19:31:59 -0800 (PST) Minette Pamela wrote: > hi, i got this problem with linux-firefox. I Installed it before in my > KDE in FreeBSD with no problems and been able to use flash > plugins. Then, I changed to Gnome recently and installed > linux-firefox. Now, when I tried to install plugins by clicking on a > site with a plugin requirement, I was successfully directed to > "agreement" stuff but I would get an error of "No plugin installed". Can't say about this case. > Now, maybe is somehow related to the errors I always get when I try to > download files or open files from the linux-firefox browser like : > "/tmp/, could not be saved, because you cannot change the > contents of the folder. Change the folder properties and try again, or > try saving in a different location". I would appreciate if you could > help me with these 2 problems. Thanks... And for this one, can you show "ls -l /compat/linux" and "ls -ld /var/db/pkg/linux*"? WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb to serial
Hi Hans, On Fri, 10 Nov 2006, 08:38+0100, Hans Petter Selasky wrote: > On Thursday 09 November 2006 18:29, Maxim Konovalov wrote: > > [ iedowse CC'ed ] > > > > Hello, > > > > On Fri, 5 May 2006, 11:04-0400, David Coder wrote: > > > thx for the suggestions, guys. with > > > > > > device uftdi > > > device uplcom > > > > > > in the kernel config the adapter shows up as > > > > > > ugen0: ArkMicroChips USB-UART Controller, rev 1.10/0.01, addr 2 > > > > > > no specific com port shows up, however, so i must need something else. > > > > Alex Rodin have ported uark(4) driver from OpenBSD. I made code > > cleanup and intergation in the tree. You can get&test patches for > > HEAD and RELENG_6 there: > > > > http://maxim.int.ru/stuff/uark.diff > > http://maxim.int.ru/stuff/uark.diff.6 > > > > Ian, could you please review the patches? > > > > Hi, do you think that you could also port the serial driver to the new USB > stack, and send me a patch file? > > Please see: > > http://www.turbocat.net/~hselasky/usb4bsd > > Download the SVN version, and type "svn diff" to generate a patch when you are > finished. Look at the other serial drivers in my SVN tree, how the USB/UCOM > stuff is done. Are there any correlations with p4://depot/projects/usb? The second question: is it OK to commit uark(4) as is and then convert it to the new model? -- Maxim Konovalov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Remote Tape slow....
Hi, I recently replaced an old DDS-II Tape with a not so old AIT-Tape in one of my FBSD-Boxes. However, access via RMT is really slow :-( When I perform a local dump of the machines that hosts the drive I get 4 - 6MB/s throughput. I get roughly the same speed, when I move the Tape to one of the other machines and perform a local dump. However, when I set "RSH=/usr/bin/ssh" and then dump to [EMAIL PROTECTED]:/dev/sa0 (I didn't change any of the other dump-Parameters like Blocksize etc.) I get a speed of ~1MB/s. I tried this both with good old 3Com 3C905TX(100MBit) and DLink DGE-530T (1GBit). The Drive is atached to an Adaptec 2940UW, the "normal" Machine that Hosts that Drive is a PIII/733MHz Box with 512MB RAM. During the dump none of the machines really show up with Load; they are ~0.15/0.20. Is this the expected behaviour of RMT? I thought I could expect (nearly) the speed of a locally atached Drive. Or is there something to tune so I get better throughput? I already searched the Lists, Manual and G* but ddin't find a real hint :-( Would be great if I could speed this up... MTIA! Cheers, _ralf_ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
