atacontrol reinit
Hi, How do I accomplish atacontrol reinit in 9.0 with ATA_CAM enabled? Plugged drives don't show up without a reboot and camcontrol reset or rescan does not help. Pete ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
pci enumeration order
Is there a way (loader variable, hints, etc.?) to change the order which different PCI card ports are enumerated on kernel start? Pete ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion
Matthias Buelow wrote: Petri Helenius wrote: Are you sure you aren't comparing filesystems with different mount options? Async comes to mind first. a) ext3 and xfs are logging filesystems, so the problem with asynchronous metadata updates possibly corrupting the filesystem on a crash doesn't arise. No, they have a different, though unrelated issues. I didn't notice which filesystem and which options were used for the benchmarks, that's why I was asking about it. b) asynchronous metadata updates wouldn't have any performance benefit on a dd if=/dev/zero of=tstfile. I was not aware that the tests were this simple. c) please cut down your quotes, and write your answers below or between the quoted text, instead of the outlook text-above-fullquote style. thanks. I usually do, however in this case it was intentional. Pete ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion
Are you sure you aren't comparing filesystems with different mount options? Async comes to mind first. Pete Nick Pavlica wrote: All, I would like to start addressing some of the feedback that I have been given. I started this discussion because I felt that it was important to share the information I discovered in my testing. I also want to reiterate my earlier statement that this is not an X vs. X discussion, but an attempt to better understand the results, and hopefully look at ways of improving the results I had with FreeBSD 5.x. I'm also looking forward to seeing the improvements to the 5.x branch as it matures. I want to make it very clear that this is NOT A Religious/Engineering War, please don't try to turn it into one. That said, lets move on to something more productive. I installed both operating systems using as many default options as possible and updated them with all of the latest patches. I was logged in via SSH from my workstation while running the tests. I didn't have X, running on any of the installations because it wasn't need. CPU and RAM utilization wasn't an issue during any of the tests, but the disk I/O performance was dramatically different. Please keep in mind that I ran these tests over and over to see if I had consistent results. I even did the same tests on other pieces of equipment not listed in my notes that yielded the same results time and time again. Some have confirmed that they have had similar results in there testing using other testing tools and methods. This makes me wounder why the gap is so large, and how it can be improved? I think that it would be beneficial to have others in this group do similar testing and post there results. This may help those that are working on the OS itself to find trouble areas, and ways to improve them. It may also help clarify many of the response questions because you will be able to completely control the testing environment. I look forward to seeing the testing results, and any good feedback that helps identify specific tuning options, or bugs that need to be addressed. Thanks! --Nick Pavlica --Laramie, WY ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error message
Alexander Leidinger wrote: On Mon, 29 Nov 2004 08:17:40 -0600 Mike Horwath [EMAIL PROTECTED] wrote: On Mon, Nov 29, 2004 at 06:12:20PM +0530, Akhthar Parvez. K wrote: Hi All, I am getting the following error message in /var/log/messages tail -f /var/log/messages Nov 29 07:24:31 speedy /kernel: pid 83876 (httpd), uid 65534: exited on signal 4 Nov 29 07:24:31 speedy /kernel: pid 84126 (httpd), uid 65534: exited on signal 4 [snipper] #define SIGILL 4 /* illegal instr. (not reset when caught) */ Anyhave has any idea why it's coming? I am not getting any error messsages in apache error logs. Only time I have seen this kind of thing is bad hardware. It may also be the case that the wrong CPUTYPE is/was specified in /etc/make.conf. Are you running old enough version of apache to be vulnerable to remote exploits but they're trying to feed you wrong shellcode? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
syslog -Wformat and %m
Is the warning message generated by -Wformat about syslog %m an issue with FreeBSD header files or gcc itself? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Max NFSD processes
Christian Hiris wrote: About a year ago i observed strong nfs performance decrease when using RLT8139A nics. Nfs transfers leaded into high system load, because of an excessive high packet retransmission rate. Switching over to 3Com nics solved my problem. The specific model and it's close relatives is only suitable for light use, like basic web surfing, small remote-monitoring applications, etc. The more recent realtek chips support more sane ways to access the hardware and wastly increased performance. You'll want RTL8139C+, RTL8169, etc. which use the re driver instead of the rl driver. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 20TB Storage System
Geoff Buckingham wrote: - This is a big problem (no pun intended), my smallest requirement is still 5TB... what would you recommend? The smallest file on the storage will be 500MB. If you files are all going this large I imagine you should look carefully at what you do with inodes, block and cluster sizes fsck problem should be gone with less inodes and less blocks since if I read the code correctly, memory is consumed according to used inodes and blocks so having like 2 inodes and 64k blocks should allow you to build 5-20T filesystem and actually fsck them. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 20TB Storage System
Poul-Henning Kamp wrote: I am not sure I would advocate 64k blocks yet. Good to know, I have stuck with 16k so far due to the fact that our database has pagesize of 16k and I found little benefit tuning that. (but it´s completely different application) I tend to stick with 32k block, 4k fragment myself. This is a problem which is in the cross-hairs for 6.x You have any insight into the fsck memory consumption? I remember getting myself saved quite a long time ago by reducing the number of inodes. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FW: 20TB Storage System
Poul-Henning Kamp wrote: 2) What is the maximum size of a filesystem that I can present to the host OS using vinum/ccd? Am I limited anywhere that I am not aware of? Good question, I'm not sure we currently know the exact barrier. Just make sure you run UFS2, which is the default on -CURRENT because UFS1 has a 1TB limit. 3) Could I put all 20TB on one system, or will I need two to sustain the IO required? Spreading it will give you more I/O bandwidth. Can you say why? Usually putting more spindles into one pile gives you more I/O, unless you have very evenly distributed sequential access in pattern you can predict in advance. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
syscall counter
Is there a counter which would show system calls per process? Like vm.stats.sys.v_syscall but instead of being systemwide, count separately for each process. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
raidframe
What would be the correct forum to post RAIDframe questions/problem reports to? Couldn't really locate maintainer address on the source tree... Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
David Schultz wrote: Most kernel memory is not pageable, so swap probably won't help you. Your `kmem_map too small' error message should report to you the size of the attempted allocation and the size of kmem_map. If the map really isn't full, I'm not sure why you would get this panic, unless you're somehow running into excessive fragmentation. Nov 3 21:44:52 giga /kernel: panic: kmem_malloc(7164): kmem_map too small: 183193600 total allocated Nov 3 22:10:30 giga /kernel: panic: kmem_malloc(7164): kmem_map too small: 175476736 total allocated This is what I'm seeing. Most of the kernel allocated memory was free at the time the panic occurred, but fragmented though. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
David Schultz wrote: Thus spake Petri Helenius [EMAIL PROTECTED]: I seem to get kmem_map too small panics when using large buffers with bpf. Is there a tunable I should be increasing? Yes, increase KVA_PAGES in your kernel config. I put in KVA_PAGES=1024 with following results on next boot: Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0600 fault virtual address = 0x1 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01efc88 stack pointer = 0x10:0xdf0ccbcc frame pointer = 0x10:0xdf0ccbf0 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 = 15 (swi1: net) trap number lastlog: Permission denied Removing the option and recompiling kernel from the same sources makes it work fine. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
Read LINT (or NOTES) carefully. You can't set KVA_PAGES to 1024, because then your kernel would take up the entire 4 GB virtual address space. Since the kernel must fit into 4 GB alongside every user process, that leaves you no room for programs. Try a more reasonable value like 512 (2 GB). Am I correct assuming that the default is 256? I´m not coming near this utilization when the system panics. With about 150M in use and KVA_PAGES undefined in config (default), both 4.7-STABLE and 5.0-CURRENT panic (1G installed memory). Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: panic: kmem_map too small
With about 150M in use and KVA_PAGES undefined in config (default), both 4.7-STABLE and 5.0-CURRENT panic (1G installed memory). Yes, the default is 256, IIRC. That corresponds to 1 GB of KVA, and you have only 1 GB of physical memory to back it. I take it this is a very busy machine. Short of getting more memory, you can decrease memory utilization by the network, e.g. by decreasing TCP window sizes, or you can limit memory usage by the network so you don't get panics. I forget the details here, so perhaps someone else can fill them in. The thing I´m concerned about that if with 150M kernel memory usage and 200M free and 300M inact memory the system panics, how much extra memory is needed to keep it running? And the swap is never touched. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
panic: kmem_map too small
I seem to get kmem_map too small panics when using large buffers with bpf. Is there a tunable I should be increasing? Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
