Recommended amount of swap
What is the state of the art for the recommended amount of swap in FreeBSD? Both "normal" systems with 512 MB - 8 GB of RAM, and large database systems with around 128 - 256 GB. Thanks in advance, -- Sean Hamilton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NUMA support; tweaking TCP for GPRS
On Fri, Dec 18, 2009 at 12:47:11PM +1100, Lawrence Stewart wrote: > Sean Hamilton wrote: > > [...] > > Second, I am using a FreeBSD server to talk to equipment > > which has a GPRS internet connection. This is fairly high > > latency (approximately one second RTT) and is prone to > > bursts of packet loss, or bursts of extremely high latency > > -- perhaps up to a minute. These intervals cause many > > retransmissions, which I presume is a good strategy over the > > internet, but not so good for GPRS. > > > > For my application, latency is mostly irrelevant. However, > > data over GPRS is very expensive, so I would like to reduce > > as much as possible the number of TCP retransmissions made > > on the FreeBSD side, possibly at the expense of latency. > > > > So, I am looking for suggestions on how to achieve this, via > > sysctl, setsockopt, etc. There seems to be a lot of > > literature regarding TCP tuning, but usually the focus is on > > improving performance, not reducing network traffic. The > > "rexmit_min" and "rexmit_sop" sysctls mentioned in tcp(4) > > seem interesting, but it's not clear to me exactly how they > > might be adjusted for this purpose. > > Just back from 6 months of travel and a bit busy right now catching up > on things, but ping me in a week or two about the TCP issue and I can > provide some insights. At this point, the issue is mostly resolved -- we were seeing a huge number of TCP retransmissions, but this was due to braindead and undocumented behaviour on the GPRS device side, not FreeBSD's fault at all. Specifically, the TCP stack on the device (eCos-based, but possibly using the TCP stack in the GSM chipset -- not sure) was setting some of its parameters based on the requested GPRS service class. For instance, if the GPRS service class indicated a desired average RTT of 0.5s, then it would just retransmit every 0.5s, or something like that -- the exact behaviour is undocumented, but clearly laughably broken. Anyway, I am still really interested in what you might have to say about this. I have already increased the minimum retransmission interval to a few seconds, with some success. -- Sean Hamilton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
NUMA support; tweaking TCP for GPRS
Greetings -hackers, I have two unrelated questions. First, what is the status of NUMA support in FreeBSD? Is there a performance penalty on Nehalem-class systems, compared with Linux, which advertises NUMA awareness? Google seems to turn up very little on this subject. Second, I am using a FreeBSD server to talk to equipment which has a GPRS internet connection. This is fairly high latency (approximately one second RTT) and is prone to bursts of packet loss, or bursts of extremely high latency -- perhaps up to a minute. These intervals cause many retransmissions, which I presume is a good strategy over the internet, but not so good for GPRS. For my application, latency is mostly irrelevant. However, data over GPRS is very expensive, so I would like to reduce as much as possible the number of TCP retransmissions made on the FreeBSD side, possibly at the expense of latency. So, I am looking for suggestions on how to achieve this, via sysctl, setsockopt, etc. There seems to be a lot of literature regarding TCP tuning, but usually the focus is on improving performance, not reducing network traffic. The "rexmit_min" and "rexmit_sop" sysctls mentioned in tcp(4) seem interesting, but it's not clear to me exactly how they might be adjusted for this purpose. Thanks in advance, -- Sean Hamilton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
bfe hardlocks
I've found my 5.2-RELEASE system hardlocking when I put some decent load on
its bfe interface. It'll do 80% load for hours before it freezes, but if I
do a ping -f it locks up within seconds. I had no problems using this
interface with the Windows driver provided by Broadcom.
bfe0: mem 0xeb80-0xeb801fff irq 12 at
device 9.0 on pci0
bfe0: Ethernet address: 00:e0:18:ab:3b:b5
[EMAIL PROTECTED]:9:0: class=0x02 card=0x80a81043 chip=0x440114e4 rev=0x01
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM440x 10/100 Integrated Ethernet Controller'
class= network
subclass = ethernet
bfe0: flags=8843 mtu 1500
inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255
ether 00:e0:18:ab:3b:b5
media: Ethernet autoselect (100baseTX )
status: active
--
Sean Hamilton <[EMAIL PROTECTED]>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VT8237 serial-ATA support, Promise ATA stalls, GEOM noise
"Søren Schmidt" <[EMAIL PROTECTED]> wrote: | Hmm, those hangs are just time spent waiting for drives (that in this | case are not there, but it can be difficult to tell). Could we have a tunable timeout, or some means of disabling the device altogether? My BIOS gives no such option. I've noticed if I put a device on the parallel interface this controller offers, the timeout problem goes away, so that is my solution for now. -- Sean Hamilton <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VT8237 serial-ATA support, Promise ATA stalls, GEOM noise
"Søren Schmidt" <[EMAIL PROTECTED]> wrote: | These are not "hangs" these are "pauses" and happens because the | kernel thinks there are devices on these channels (are there ? no | dmesg provided) and waits for the 31secs the spec calls for. Now, | I have one of those exact Promise controllers and there it works | butifully, so your setup has to be special or wrong in some way | since you see the delays (again no dmesg or anything provided so | I cant tell) There are no drives on the SATA interfaces, but there were at one point and I don't remember if it stalled or not. However I do remember them being very slow if I read them both in parallel (16 MB/sec each according to dd and systat) but very fast if I read only one (60 MB/sec) despite the system load being very low. In 5.1 I could only get 16 MB/sec even if I only read from a single drive. I can probably get my hands on more drives if this needs to be reproduced. I attempted a verbose dmesg but the buffer filled up with ata5-master: stat=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata5-master: stat=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata5-master: stat=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata5-master: stat=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 [...] ata5: reset tp2 mask=00 stat0=a0 stat1=00 devices=0x0 ata5: at 0xec80 on atapci0 ata5: [MPSAFE] A non-verbose dmesg: Preloaded elf kernel "/boot/kernel/kernel" at 0xc0682000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0682244. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2500+ (1833.13-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc040 real memory = 268419072 (255 MB) avail memory = 255393792 (243 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2080 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 7 INTA is routed to irq 10 pcib0: slot 8 INTA is routed to irq 10 pcib0: slot 9 INTA is routed to irq 12 pcib0: slot 10 INTA is routed to irq 11 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci0: at device 7.0 (no driver attached) atapci0: port 0xb800-0xb87f,0xd000-0xd00f,0xd400-0xd43f mem 0xec00-0xec01,0xec80-0xec800fff irq 10 at device 8.0 on pci0 atapci0: [MPSAFE] ata2: at 0xec80 on atapci0 ata2: [MPSAFE] ata3: at 0xec80 on atapci0 ata3: [MPSAFE] [stall here] ata4: at 0xec80 on atapci0 ata4: [MPSAFE] [stall here] ata5: at 0xec80 on atapci0 ata5: [MPSAFE] bfe0: mem 0xeb80-0xeb801fff irq 12 at device 9.0 on pci0 bfe0: Ethernet address: 00:e0:18:ab:3b:b5 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at device 10.0 (no driver attached) pci0: at device 11.0 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 atapci1: port 0xa000-0xa00f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci1 ata1: [MPSAFE] orm0: at iomem 0xc-0xc7fff on isa0 Timecounter "TSC" frequency 1833134268 Hz quality 800 Timecounters tick every 10.000 msec GEOM: create disk ad0 dp=0xc29c7760 ad0: 76319MB [155061/16/63] at ata0-master UDMA100 GEOM: create disk ad1 dp=0xc29c7560 ad1: 76319MB [155061/16/63] at ata0-slave UDMA100 acd0: CDRW at ata1-slave PIO4 GEOM: create disk ar0 dp=0xc296c5e0 ar0: 152638MB [19458/255/63] status: READY subdisks: disk0 READY on ad0 at ata0-master disk1 READY on ad1 at ata0-slave Mounting root from ufs:/dev/ar0a -- Sean Hamilton <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VT8237 serial-ATA support, Promise ATA stalls, GEOM noise
"Soren Schmidt" <[EMAIL PROTECTED]> wrote: | It seems Sean Hamilton wrote: | | I have two Asus boards (A7V8X and A7V) which have in common a | | Promise ATA controller. Both of these boards hang up for about a | | minute during the boot of 5.1-RELEASE, and emit messages about ad* | | devices being reset -- I cannot paste them verbatim as they seem | | to have been omitted from my dmesg. In the case of the A7V8X, the | | controller is unused and disabled in the BIOS. Has this been | | rectified for 5.2? | | Should not happen on -current. Upgraded to 5.2-RELEASE and it is still happening. The problem seems to be the Promise controller, not the bridge IDE. The board is an Asus A7V8X, controller "PDC20376". The hang comes before it prints "ata4: at 0xec80" as well as ata5. I can provide a root shell or serial console to Soren if this hardware is not already available. -- Sean Hamilton <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Passthrough block device
Does FreeBSD support a device that will allow for the passing of all reads and writes on it to a userland application? I wish to handle swapping myself, preferably without any kernel hacking. What would happen if the kernel decided to swap out such a process? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mmap(2) questions, reads not caching
I have some code resembling: FILE * f = fopen (filename, "rb"); mmap (NULL, st.st_size, PROT_READ, MAP_PRIVATE, fileno (f), 0); I've found that reads are not brought into disk cache. Successive reads on the same file once again read from disk. If I cat the file to /dev/null, then the mmap(2) does indeed read the data from cache. What's going on here? Also, the man page states that the mapped region may be longer than the specified size. Does this have any implications for the size which is passed to munmap(2)? If I pass the same size to munmap(2), then will there still be leftover, or will the entire region be unmapped? And, should I be passing MAP_PRIVATE or MAP_SHARED to read-only mmaps? Does it make any difference at all? Running 5.1-RELEASE. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
VT8237 serial-ATA support, Promise ATA stalls, GEOM noise
I'm looking to replace an aging fileserver with an Asus A7V600 board. Presently it appears FreeBSD does not support the serial ATA interface on the south bridge. As this appears to be the first Via serial ATA controller, am I safe in assuming this will not be supported for some time? I have two Asus boards (A7V8X and A7V) which have in common a Promise ATA controller. Both of these boards hang up for about a minute during the boot of 5.1-RELEASE, and emit messages about ad* devices being reset -- I cannot paste them verbatim as they seem to have been omitted from my dmesg. In the case of the A7V8X, the controller is unused and disabled in the BIOS. Has this been rectified for 5.2? When using atacontrol's software RAID functionality, GEOM laments "Opened disk ad6 -> 1" at boot. This seems like benign noise, perhaps it should be removed -- it appears to be a forgotten debug message, /sys/geom/geom_disk.c 1.72, line 115. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mmap(2) questions, reads not caching
I have some code resembling: FILE * f = fopen (filename, "rb"); mmap (NULL, st.st_size, PROT_READ, MAP_PRIVATE, fileno (f), 0); I've found that reads are not brought into disk cache. Successive reads on the same file once again read from disk. If I cat the file to /dev/null, then the mmap(2) does indeed read the data from cache. What's going on here? Also, the man page states that the mapped region may be longer than the specified size. Does this have any implications for the size which is passed to munmap(2)? If I pass the same size to munmap(2), then will there still be leftover, or will the entire region be unmapped? And, should I be passing MAP_PRIVATE or MAP_SHARED to read-only mmaps? Does it make any difference at all? Running 5.1-RELEASE. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Tuning HZ for semi-realtime applications
Greetings, I have an application which has some task it must execute at some interval (approximately 1000 times per second.) This application calls select(2) in a loop, and uses its timeout parameter to try to keep the timing consistent. At the end of a cycle, it sends out a large amount of network traffic. During the select loop, it expects to receive replies to all this traffic. Should I set HZ to 1000 (the frequency of my application) or should I set it to a much higher value? The CPU is running at around 2 GHz, and I set it as high as 50,000 with no problems. However, the granularity of my timeout appears to be restricted to 1/1000th of a second. I would like to use poll(2) instead of select, but it appears to take its timeout parameter in milliseconds, which aren't precise enough to keep my timing reasonable, especially if I ever need to increase my frequency. Another option would be calling poll/select with no timeout, in a loop. However, this seems like a waste of CPU time. Also, as I am doing large amounts of network traffic, which NIC (preferably gigabit) should I be using, to cause the least interference with my timing? I do not require realtime performance. I am just looking to have this run as smoothly as possible. sh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apache2's perchild MPM not working under 5.0-RELEASE
"Jeremy C. Reed" <[EMAIL PROTECTED]> wrote: | The apache2 port build and installed with WITH_MPM=perchild does | not work for me [...] As far as I can tell, perchild MPM is dead. Which sucks, as it was by far Apache 2.0's coolest feature. If you view the CVS log, it has not seen any real work in a year. sh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Quota consistency/races
Greetings, What measures are in place to ensure disk quota consistency? For instance, if a part of the filesystem changes while running quotacheck, I imagine that does not get accounted for. Wouldn't somebody have trouble enabling quotas on a busy filesystem? The quota file would always lag behind the actual filesystem, and one cannot mount read-only because quotacheck must write the quota file. sh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wait()/alarm() race condition
Dan Nelson wrote: | In the last episode (Mar 30), Sean Hamilton said: || I'm concerned about this order of events: || || - alarm() || - wait() returns successfully || - if (alarmed...) [false] || - SIGALRM is delivered, alarmed = true || - loop || - wait() waits indefinitely | | A cleaner solution would be to use ualarm(6,1000) or setitimer() | to do this (replacing the alarm(60) call outside the handler). This looks like the way to go. "cleaner" is certainly relative here, but it's quite likely this hack never comes up in the lifetime of the program. I've inserted a printf just in case. (slight grin) This is my first time dealing with signals... they seem to lack the elegance most of Unix offers. Perhaps that's just my inexperience speaking. sh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wait()/alarm() race condition
Dan Nelson wrote: | Just make sure your signal handler has the SA_RESTART flag unset | (either via siginterrupt() if the handler was installed with signal(), | or directly if the signal was installed with sigaction() ), and the | signal will interrupt the wait() call. Er, I think you've missed my problem. Or I'm not getting your solution. I'm concerned about this order of events: - alarm() - wait() returns successfully - if (alarmed...) [false] - SIGALRM is delivered, alarmed = true - loop - wait() waits indefinitely This is incredibly unlikely to ever happen, but it's irritating me somewhat that the code isn't airtight. Bad design. Surely there is some atomic means of setting a timeout on a system call. sh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
wait()/alarm() race condition
[asked in comp.unix.programmer without much luck]
Greetings,
I have a loop which calls wait(), and I want another function to be called
as close to once per minute as possible. Pseudo code:
int alarmed = 0;
void handle_sigalrm (int sig)
{
alarmed = 1;
}
while (1)
{
alarmed = 0;
alarm (60);
while (1)
{
wait (...);
if (alarmed || wait was interrupted)
{
break;
}
}
/* minutely code */
}
My concern is there is a small possibility that the alarm signal is
delivered after the if() but before the wait. So it is possible that this
wait takes several minutes or longer.
Moving the "if (alarmed)" above the wait() makes no difference, of course.
Is there a better way of doing something like this? Ideally wait() has a
timeout parameter, but, no such luck.
sh
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
first parameter to select
Greetings, What is the first parameter to select(2) for? Microsoft's select ignores it, and it does not appear to have any valid use since it only allows constraints on values which are assigned by the system. Purely historic? sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IP addresses of bridge interfaces
Greetings, I recently upgraded a FreeBSD 4.6.2 bridge to 5.0, and am having troubles with how it handles IP addresses. router | | t1 | [fxp0] FreeBSD bridge [fxp1] | switch | hosts The problem is that if the external interface is assigned an address, then hosts on the same block can't access it. Likewise if the internal interface is given an address, *only* hosts on the same block can access it! I have verified that in both cases the bridge has its default route correctly set. I won't be too suprised if this is due to screwey ISP routing, but I don't recall this ever being a problem with 4.6.2. Any tips? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: C coding editor
Wes Peters wrote: | On Saturday 01 March 2003 03:12 pm, Giorgos Keramidas wrote: || The font of the program text isn't really important, as long as || nesting isn't horribly broken by someone who typed the wrong number || of spaces instead of just hitting tab. | | But the font of the program text *is* important if you are considering | readability. We use variable-width fonts for books and printed matter | because they are easier to read than monospaced fonts. Er, no. Things like serifs, variable width lettering, and kerning do make English more readable, but much like they do little good for Japanese, they are inconvenient for code, which is mostly symbols. I suppose Pascal would be alright in variable width, but certainly not C. I tried using variable with for C a while back, and the main problem I had was not with spacing, but my severely defective ocular receptors were unable to distingush between a lot of the symbols. IIRC, I went back to monospace after trying to find the syntax error on a line which wound up ending with a colon. sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ACPI throttle doesn't cool CPU
Greetings, After setting hw.acpi.cpu.performance_speed to 1, a dmesg of acpi_cpu0: set speed to 6.2% and a dog slow system, I am still finding my CPU pumping out heat. It's an AMD 1333 with an A7V board. Is this typical behaviour? If so, I'll just underclock the CPU in the bios. I was hoping to be able to run it at full speed during builds. All this ACPI stuff seems interesting, is it well documented anywhere? The man page wasn't of much use. thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Random disk cache expiry
- Original Message - From: "Tim Kientzle" <[EMAIL PROTECTED]> | Cycling through large data sets is not really that uncommon. | I do something like the following pretty regularly: | find /usr/src -type f | xargs grep function_name | | Even scanning through a large dataset once can really hurt | competing applications on the same machine by flushing | their data from the cache for no gain. I think this | is where randomized expiration might really win, by reducing the | penalty for disk-cache-friendly applications who are competing | with disk-cache-unfriendly applications. In my case I have a webserver serving up a few dozen files of about 10 MB each. While yes it is true that I could purchase more memory, and I could purchase more drives and stripe them, I am more interested in the fact that this server is constantly grinding away because it has found a weakness in the caching algorithm. After further thought, I propose something much simpler: when the kernel is hinted that access will be sequential, it should stop caching when there is little cache space available, instead of throwing away old blocks, or be much more hesitant to throw away old blocks. Consider that in almost all cases where access is sequential, as reading continues, the chances of the read being aborted increase: ie, users downloading files, directory tree traversal, etc. Since the likelihood of the first byte reading the first byte is very high, and the next one less high, and the next less yet, etc, it seems to make sense to tune the caching algorithm to accomodate this. While discussing disks, I have a minor complaint: at least on IDE systems, when doing something like an untar, the entire system is painfully unresponsive, even though CPU load is low. I presume this is because when an executable is run, it needs to sit and wait for the disk. Wouldn't it make sense to give very high disk priority to executables? Isn't that worth the extra seeks? sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Random disk cache expiry
Greetings, I have a situation where I am reading large quantities of data from disk sequentially. The problem is that as the data is read, the oldest cached blocks are thrown away in favor of new ones. When I start re-reading data from the beginning, it has to read the entire file from disk again. Is there some sort of sysctl which could be changed to induce a more random expiry of cached disk blocks? Wouldn't it seem logical to have something like this in place at all times? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kldload random.ko panic
Greetings, Running 5.0-RELEASE, # kldload random induces a panic, presumably unless it is not compiled into the kernel. sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel panic with ATA RAID
From: "Brian F. Feldman" <[EMAIL PROTECTED]>
| The program plus output given when you recompile/run gdb -k with a
debugging kernel
| would be really useful here.
I can't try it again (the system has gone off to production) but here is the
perl script:
---
#!/usr/bin/perl
system ('atacontrol', 'create', 'stripe', '1', 'ad2', 'ad3');
open (DD, 'dd if=/dev/ar0 of=/dev/null count=32k 2>&1 |');
system ('atacontrol', 'delete', '0');
---
panicked my system every time.
sh
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Kernel panic with ATA RAID
Seems my toying with atacontrol caused a reproducable panic. I have a perl script which causes the panic right away every time, I'll mail that to anybody @freebsd.org that wants it. (Or is such paranoia unnecessary?) I believe everything else needed is here. sh --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x88 fault code = supervisor write, page not present instruction pointer = 0x8:0xc014e4fd stack pointer = 0x10:0xcfce6d4c frame pointer = 0x10:0xcfce6d60 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 = 112 (dd) interrupt mask = none trap number = 12 panic: page fault --- --- (kgdb) where #0 0xc01447b6 in dumpsys () #1 0xc0144587 in boot () #2 0xc01449ac in poweroff_wait () #3 0xc01dddb2 in trap_fatal () #4 0xc01dda85 in trap_pfault () #5 0xc01dd66f in trap () #6 0xc014e4fd in dsclose () #7 0xc014de75 in diskclose () #8 0xc01782e8 in spec_close () #9 0xc01abc3a in ufsspec_close () #10 0xc01ac201 in ufs_vnoperatespec () #11 0xc0175f5c in vn_close () #12 0xc0176887 in vn_closefile () #13 0xc013ac9f in fdrop () #14 0xc013abe7 in closef () #15 0xc013a7f4 in fdfree () #16 0xc013d4b1 in exit1 () #17 0xc0146432 in sigexit () #18 0xc01461ac in postsig () #19 0xc01de114 in syscall2 () #20 0xc01d2465 in Xint0x80_syscall () #21 0x8055585 in ?? () #22 0x8048f00 in ?? () #23 0x8048135 in ?? () --- --- machine i386 cpu I686_CPU ident SOAP maxusers0 options INET options FFS options FFS_ROOT options SOFTUPDATES options UFS_DIRHASH options COMPAT_43 options ICMP_BANDLIM device apm device isa device pci device ata device atadisk device atapicd options ATA_STATIC_ID device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device vga0at isa? device sc0 at isa? flags 0x100 device npx0at nexus? port IO_NPX irq 13 device miibus device rl pseudo-device loop pseudo-device ether pseudo-device pty pseudo-device bpf device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 --- --- Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-RELEASE #2: Wed Jan 1 06:52:01 PST 2003 [snip] Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (451.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383f9ff real memory = 335544320 (327680K bytes) avail memory = 323653632 (316068K bytes) Preloaded elf kernel "kernel" at 0xc0279000. Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fdf00 apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 irq 10 chip1: port 0x5000-0x500f at device 7.3 on pci0 rl0: port 0xe400-0xe4ff mem 0xe800-0xe8ff irq 10 at device 17.0 on pci0 rl0: Ethernet address: [snip] miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto orm0: at iomem 0xc-0xc on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold ad0: 9732MB [19774/16/63] at ata0-master UDMA33 ad2: 76319MB [155061/16/63] at ata1-master UDMA33 ad3: 76319MB [155061/16/63] at ata1-slave UDMA33 Mounting root from ufs:/dev/ad0s1a --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATA RAID performance (numerous fs related questions)
From: "Soeren Schmidt" <[EMAIL PROTECTED]> | Uhm, what kind of disks, stripesize etc are you using, without that info | noone can tell you why... Two Seagate 80GB 7200RPM drives each on their own ATA66 channel. They're not very fast, but they are quiet. Quick tests with dd show about 20 MB/s reads off them with a blocksize of 64KB. I then created a stripe with atacontrol create stripe 128 ad4 ad6 and performed the same dd on ar0, I get about 17 MB/s (on a K7 500.) The performance isn't very relevant in this case. I was just curious. Is there any reason to use span instead of stripe? I am booting off a different disk, and as I understand, if either drive craps out, there's not much hope of recovery for me anyways. Also, which newfs settings would be wise for me? I will only be storing files of exactly 10,000,000 bytes, they will be deleted and recreated often. They will be written slowly and sequentially, at around 40 KB/s (always one at a time.) They will be read as fast as possible several times thereafter, then deleted. The application I am using does not ftruncate before writing, and I am not in a position to change the code. I'm trying -m 0 -o space, though I've heard this is unwise. Can I prevent newfs from writing out superblock backups? Is async faster than softupdates? Is there any reason to use async and softupdates simultaneously, or are they mutually exclusive? (tries, but fails to think of more lingering questions) thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ATA RAID performance
Greetings, I have tried using both atacontrol and ccdconfig to create stripes and mirrors of various sizes, and have found that in all cases, read performance *decreased*. Is this typical? I have a Promise controller in another computer running Windows which sees a considerable performance increase while striping, but in the FreeBSD machine, no controller is present. thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Bootable FreeBSD CD
Greetings, How does the kernel on the FreeBSD install CD know which device to mount as root? I'm assuming it hasn't got a ROOTDEVNAME config option, since that would make it fairly specific to certain hardware. Mine always tries to mount fd0. thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
burncd raw mode
Greetings, I have a 2352-byte block mode1 CD image, and wish to burn this with burncd. I know I can use bin2iso or bchunk to decode it, but I'd rather keep the block metadata intact from the file itself instead of having the burner/driver(?) reconstruct it. I assembled a small stack of coasters by trying a few combinations of -d, 'raw', etc, to no avail. The best I got was from raw, a track which needed to be read with 2352 byte blocks, so it wasn't being interpreted as metadata. I presume if I were to dd this entire disc into a file, I would have a verbatim copy of my original, albeit less fault tolerant. Can this be done with burncd? How does the drive/driver know to interpret the remaining 304 bytes as metadata? Is it possible to extract the full 2352 byte blocks from a track which is advertised as only 2048, ie a typical data track? There are a few Windows apps for doing exactly this. thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HD data recovery
From: "Stephen Hilton" <[EMAIL PROTECTED]> | Am up and running now on the spare HD, and can work on my "big | mistake" at my lesiure, thanks in advance. My first partition: start 63, size 40130307 (19594 Meg), flag 80 (active) And an hd of block 63: ### fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c be 1a 7c bf |.1.|..|.| 0010 1a 06 b9 e6 01 f3 a4 e9 00 8a 31 f6 bb be 07 b1 |..1.| 0020 04 38 2f 74 08 7f 78 85 f6 75 74 89 de 80 c3 10 |.8/t..x..ut.| 0030 e2 ef 85 f6 75 02 cd 18 80 fa 80 72 0b 8a 36 75 |u..r..6u| 0040 04 80 c6 80 38 f2 72 02 8a 14 89 e7 8a 74 01 8b |8.r..t..| 0050 4c 02 bb 00 7c 80 fe ff 75 32 83 f9 ff 75 2d 51 |L...|...u2...u-Q| 0060 53 bb aa 55 b4 41 cd 13 72 20 81 fb 55 aa 75 1a |S..U.A..r ..U.u.| 0070 f6 c1 01 74 15 5b 66 6a 00 66 ff 74 08 06 53 6a |...t.[fj.f.t..Sj| 0080 01 6a 10 89 e6 b8 00 42 eb 05 5b 59 b8 01 02 cd |.j.B..[Y| 0090 13 89 fc 72 0f 81 bf fe 01 55 aa 75 0c ff e3 be |...r.U.u| 00a0 bc 06 eb 11 be d4 06 eb 0c be f3 06 eb 07 bb 07 || 00b0 00 b4 0e cd 10 ac 84 c0 75 f4 eb fe 49 6e 76 61 |u...Inva| 00c0 6c 69 64 20 70 61 72 74 69 74 69 6f 6e 20 74 61 |lid partition ta| 00d0 62 6c 65 00 45 72 72 6f 72 20 6c 6f 61 64 69 6e |ble.Error loadin| 00e0 67 20 6f 70 65 72 61 74 69 6e 67 20 73 79 73 74 |g operating syst| 00f0 65 6d 00 4d 69 73 73 69 6e 67 20 6f 70 65 72 61 |em.Missing opera| 0100 74 69 6e 67 20 73 79 73 74 65 6d 00 00 00 00 00 |ting system.| 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01 || 01c0 01 00 a5 fe ff ff 3f 00 00 00 03 57 64 02 00 00 |..?Wd...| 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200 ### Perhaps you can determine which of your blocks around the 4GB range contains "Missing operating system", then reconstruct enough of the partition table enough from that to recover your original boot block. # dd if=/dev/ad0 bs=1m skip=4000 | hd | grep 'em\.Missing opera' should uncover a line such as the one above, 00f0 65 6d 00 4d 69 73 73 69 6e 67 20 6f 70 65 72 61 |em.Missing opera| Add skip * bs (0xFA00 in my example) to the address specified and AND it with 0xFE00, that should be the first block of your partition. Run it to the end of the drive, and from there, you should be able to mount that partition and rewrite your real MBR. sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
umount -f safety
Greetings, In short, how safe is umount -f? I've been given the task of creating a CD jukebox with Samba. I've got a few dozen ISO images, and a directory with a number of subdirectories named after all the clients. Then, in samba, I have a share with a path of /store/images/%m, so each client receives a unique view of that share. To change CDs, I am executing, for example: # unmount old cd umount -f /store/mount/someclient vnconfig -u vn4 # and mount new one vnconfig vn4 /store/images/blah.iso mount -t cd9660 /dev/vn4 /store/mount/someclient This works great, but I seem to recall reading that umount -f might cause panics, and since this server is also a network gateway, I'd prefer that not occur. I need to umount -f because the samba server keeps its working directory in there, presumably it chroots. The alternative would be to kill off the samba server serving that one client, then quickly remount and hope the client doesn't reconnect, but of course that's a big hack. The server is running 4.7-RELEASE. I've only recently implemented this, so it has not seen heavy load, nor has it panicked. thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
libpcap packet direction
Greetings, Is it possible to get libpcap or bpf to tell me the direction of a packet going across an interface? They only seem to be able to match source and destination addresses, which isn't very useful for my application. thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CD audio interpolation
Greetings, If I read /dev/acd0t1, will the CD-ROM interpolate over scratches and stuff? Is there any way of identifying them? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
READ_BIG - ILLEGAL REQUEST at very end of CD
Greetings, I'm creating ISO images of CDs as advised by the handbook, like so: # dd if=/dev/acd0c of=blah.iso bs=2k At the very end of many CDs, dd states "acd0: Input/output error" and the kernel says: acd0: READ_BIG - ILLEGAL REQUEST asc=0x64 ascq=0x00 error=0x04 The .iso seems okay (I can make it into a vnode and mount it without trouble.) I can mount the CD and recursively cat every file, so I don't think it's bad media. Is this just an alignment issue, then? READ_BIG expecting 16 blocks or somesuch? Harmless? Is the tail end of my .iso getting thrown away? thanks, sh atapci0: port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: port 0x8800-0x883f,0x9000-0x9003,0x9400-0x9407,0x9800-0x9803,0xa000-0xa007 mem 0xe480-0xe481 irq 11 at device 17.0 on pci0 ata2: at 0xa000 on atapci1 ata3: at 0x9400 on atapci1 ad4: 38172MB [77557/16/63] at ata2-master UDMA100 acd0: CD-RW at ata0-master UDMA33 # atacontrol mode 0 Master = UDMA33 /* 40 pin cable. UDMA33 cdrom. */ Slave = ??? # atacontrol mode 1 Master = ??? Slave = ??? # atacontrol mode 2 Master = UDMA100 Slave = ??? # atacontrol mode 3 Master = ??? Slave = ??? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Direct video access
Greetings, I have been doing graphics programming in Windows for a few years, and am interested in broadening my horizons. I'm interested in attempting to get FreeBSD to switch video modes and gain access to video memory, perhaps to attempt a simple OpenGL-like implementation or the like, entirely foregoing xfree86 and mesa. Which card would I be best off using? I currently have an nvidia geforce256, but understand nvidia is fairly hush-hush about how their hardware works. I know nvidia is about to release an xfree86 module, but I'm not too interested in using xf86. I hear ATI is somewhat more open about the technical details of their cards. For this card, where should I look to get details of the interface? I really know nothing about talking directly to hardware, but am eager to learn. I am assuming all cards have a standard set of commands to do things like set video modes and possibly even things like hardware accelerated lines and such, but I imagine things like matrix multiplications and transformations, blitting, etc, are all proprietary. I know DOS uses a set of interrupts to change video modes, and a static address for the framebuffer, but I'm assuming this isn't the case with FreeBSD. If it *is* a static address, would I then have to be running in kernel mode to access such an address? Is this the inappropriate list for questions like this? freebsd-multimedia looks more like userland type stuff... thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
microuptime() and nanouptime() library?
Greetings, I just tried to use nanouptime, then microuptime, but was disappointed to find that a quick grep of /usr/lib revealed no libraries containing these symbols. Are they only available to the kernel. If so, how can I get a reasonable timer figure from user space? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP monitoring
Also, forgot to mention, I will need to look inside TCP streams, and know which user owns them, and which packets pertain to which TCP stream, which is why I was thinking a module would be more suitable. If I did this in user space, I'd have to reconstruct the streams myself (but as I understand, that isn't amazingly difficult.) sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IP monitoring
Greetings, I'm interested in developing a fairly proprietary IP monitoring solution (I want to look for specific trends in specific packets.) Will there be considerable gains from writing some sort of kernel module, vs. a userspace solution? I've never hacked the kernel or written any sort of kernel module before, but I'm eager to do so. What is the most low level API for this sort of thing, to avoid API overhead, if I should do it in user space? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: arplookup: host is not on local network
From: "Doug White" <[EMAIL PROTECTED]> > You should check that your network configuration is correct first, then > use tcpdump to locate the offender and report them to your provider. They > can ask the owner of said machine politely to install the patches or set > /proc flags to disable that behavior. You can, of course, comment out the Which /proc flags? Indeed it is a linux box, the firewall, which I have access to. My coworker, the administrator of this box, has simply turned a blind eye to this, on the grounds that it's not actually causing problems, just noise... but if it's a simple tweak, I'm sure he could be bribed with caffeine or somesuch. > printfs, or hide it behind log_arp_wrong_iface which is controlled by the > sysctl net.link.ether.inet.log_arp_wrong_iface. The file you want to > modify in that case is src/sys/netinet/if_ether.c. Thanks, looks like that sysctl is what I've been looking for. Though you seem to indicate I would have to modify the kernel to achieve this, it seems to be that way already -- perhaps a recent thing? Regardless, I find it somewhat surprising my googling didn't point me in this direction. sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
arplookup: host is not on local network
Greetings, I have a FreeBSD box being colocated. Every few seconds, I get the following message: /kernel: arplookup 216.187.x.x failed: host is not on local network As I understand, this 216.187.x.x machine is acting as a "proxy arp". I think it's supposed to be completely transparent, but evidently my box is noticing. I am on a 64.69.x.x address. I have tried explicitly setting host routes, with no results. I have tried setting a permanent arp entry for that IP address, but then I get: /kernel: arp: 00:d0:b7:bb:86:ec attempts to modify permanent entry for 216.187.x.x on xl0 even though this is the hardware address I've set for the explicit arp. This has polluted my server logs beyond my tolerance, and I am about to cave and just comment these out of the kernel. Any suggestions on how to rectify this? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Linux binary compatibility requires SYSVSEM
Greetings, "kldload linux" dies unless optionsSYSVSEM is in the kernel. Is there some way around this? (I have no other use for it, and try to be minimalist...) Also, are there other approaches to Linux binary compatibility? Is there some type of wrapper, which will load and execute the code, without all the compatibility/library mishmash? I'm trying to run a quake3 server, which I don't believe does anything not in the standard C library. thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Beep after shutdown
From: "Takanori Watanabe" <[EMAIL PROTECTED]> > >Anybody clueful want to point me in the right direction? > > Following patch is Chiharu Shibata's patch for old 4-stable. > The article on the patch is published in > FreeBSD press(http://www.ux.mycom.co.jp/). > > http://plaza17.mbn.or.jp/~chi/myprog/FreeBSD/scbeep.diff Unfortunately, no luck here. One of the devices I pull from the kernel is sc, which this depends on. sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Beep after shutdown
Greetings, The fact that FreeBSD does not beep after it finishes shutting down has costed me dozens of hours of reformatting inconsistent filesystems, and probably all sorts of little bits of data loss which I'm just unaware of. I've tried to hack this into the kernel myself, without much luck. The best I got it to do was start beeping but never end, since the timer related stuff had already been killed off. This wound up being more irritating than useful. Anybody clueful want to point me in the right direction? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
