Re: what is stuck here?!
On Tue, 23 Aug 2005, Fafa Hafiz Krantz wrote: hello! how come *nothing* happens when i rm -rf directory/? it just won't move ... top from another terminal tells me: 55272 root 1160 14396K 13768K RUN 0:27 36.13% 35.40% rm what? the directory/ only contains a .maildir/, a .muttrc and an empty directory it's not an immutable flag that has been set, chflags -R nouchg directory/ stands equally still to rm -rf It's probably busy calculating the list of directory entries to remove. If you have /proc mounted try: truss -p 55272 to see what it is doing. If you don't, and you have KTRACE in your kernel, you can try: ktrace -i -d -p 55272 kdump -l to monitor the process. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
OT: Supermicro IPMI 2.0 boards
I wasn't able to find anything about this on Google unfortunately. Hoping that if this thread can determine the problem, others will be able to find it. We ordered a whole batch of servers which have the IPMI 2.0 board (I am pretty sure). When they first come online they seem to have the MAC 00:30:48:12:34:56 . Then at some point they take on the real NICs MAC address. The problem is that some of them aren't, and the IPMI 2.0 boards do not seem to be supported/working under FreeBSD yet. The older versions of the board did work previously, using the 'freeipmi' port. On these servers the tools just hang indefinitely. The situation is getting more serious as it may be causing spanning tree problems. We're getting warnings from our switches every 15 seconds about 00:30:48:12:34:56 being swapped from port to port and switch to switch. While on the servers themselves, I'm seeing a steady stream of: 13:37:37.023915 arp who-has 192.168.1.113 tell 192.168.1.113 13:37:37.119740 arp who-has 192.168.1.113 tell 192.168.1.113 13:37:37.213317 arp who-has 192.168.1.113 tell 192.168.1.113 13:37:37.271162 arp who-has 192.168.1.113 tell 192.168.1.113 13:37:37.522533 arp who-has 192.168.1.113 tell 192.168.1.113 13:37:37.720931 arp who-has 192.168.1.113 tell 192.168.1.113 If I bring up that IP on one of the servers, dmesg fills up with entries about other servers claiming the IP for their own. Most of the entries have the real MAC address, and some of them have the 12:34:56 entry: arp: 00:30:48:83:0b:4a is using my IP address 192.168.1.113! arp: 00:30:48:83:0c:38 is using my IP address 192.168.1.113! arp: 00:30:48:83:0b:e2 is using my IP address 192.168.1.113! arp: 00:30:48:12:34:56 is using my IP address 192.168.1.113! arp: 00:30:48:83:aa:84 is using my IP address 192.168.1.113! arp: 00:30:48:83:0c:04 is using my IP address 192.168.1.113! arp: 00:30:48:83:0c:06 is using my IP address 192.168.1.113! FWIW, we don't use the 192.168.1 block anywhere on our network, so none of us know why it picked that particular IP address. I realize this is totally off-topic but I'm hoping others have been using these servers and may know a solution to the problem. If this message is totally inappropriate please feel free to reply off-list. In that case I'd collect the replies and post the solution somewhere (giving credit obviously). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OT: Supermicro IPMI 2.0 boards
On Mon, 22 Aug 2005, Danial Thom wrote: A more important question is: why did you order a whole bunch of servers without testing one first? A curious approach to computing. DT We weren't made aware that the newer servers were coming with a later rev board, and a customer came along asking for 30 some servers to be ordered yesterday. The servers themselves work OK otherwise, for the most part. FWIW, this particular IPMI problem would not have appeared at all if we only ordered one server, since multiple servers are trying to grab the same IP/using the same MAC. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable server
On Tue, 16 Aug 2005, Nikolas Britton wrote: 4.x compared to 5.x will always be more stable 5.x compared to 6.x will always be more stable 6.x compared to 7.x will al Do you see a trend? 4.x works now but what about in another year, two years, or three? I expect it should work just fine in 3 years -- when we purchase hardware we expect it to last at least that long, and there's rarely a truly compelling reason to replace the OS on a server. Try running the last version of 3.x on today's hardware and software, 4.x is already having problems with hardware support. Unfortunately, yeah. 3ware's auto-carving feature (available in 5.4-S) would not work on 4.x as an example. There may be other things, but 4.11 works on relatively standard hardware you can purchase today. FreeBSD 6 already has a -STABLE and it's first release is just around the corner, It would be unwise to deploy 4.x unless specifically needed If you need to build the next Mars rover or a persons life depends on the system working then use 4.x, If your deploying a new web server or what not you want 5.x, possibly even 6.x if you can wait another month or two. It depends. I am really concerned about security updates being backported. While I feel I'm probably capable of handling it myself, if I had to, by reviewing patches submitted for later versions, I feel more confident in the patch when it has been peer-reviewed. The fact is that FreeBSD's 4.11 release is scheduled to have patches long past 5.4, and I have to take that into account when making recommendations to our clients. I don't want to have to tell a customer: Install this OS, but in a year, you'll want to install a different OS, and then deal with incompatibilities with the software you've purchased for your sites. The way I see it, every major release of FreeBSD takes some time to reach stability -- the classic be wary of x.0 versions rule applies here as with almost all software. Stable versions for web servers have been (in my experience): FreeBSD 2.2.(something, I don't remember, 5?), 3.2, 4.5. 5's appears to be 5.4, which so far seems to be pretty great, but was only just recently released May 9th and is set to EOL in about 10 months. Anyways, to the OP, it all depends on how long you want this particular solution to be deployed. I'd keep an eye on the security page (of course). There may be a company/set of hackers out there that would be able to backport fixes to FreeBSD 5.4 after it expires, in case you're not able to deploy the most recent version on that date. I do stand by my recommendation of 4.11, because it is the pinnacle before some architectural changes, and if it's anything like 4.5 or 3.2 it should give you years of quality. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to know the file system type [programming]
On Wed, 17 Aug 2005, Jorge Mario G. Mazo wrote: hi there I've been looking for a way to check the fs type I need to do something like this if NTFS do this if msdis do that if ufs2 do that if ext2 do this other stuff thanks in advance I'd check out the fdisk code. For example: $ fdisk /dev/ad0 | grep sysid sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) Figure out how it determines the sysid, and then you can use that in your code. You'd still need a function to determine what disks are physically present. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable server
On Tue, 16 Aug 2005, Carstea Catalin wrote: what version of freebsd do u recomand for a stable server? 4.11 is solid, hasn't shown any problems here. 5.4 is the best of the 5.x series but we (I mean at my company, not speaking as a FreeBSD rep) haven't put it through as much stress as we have 4.11 . ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable server
On Tue, 16 Aug 2005, dpk wrote: On Tue, 16 Aug 2005, Carstea Catalin wrote: what version of freebsd do u recomand for a stable server? 4.11 is solid, hasn't shown any problems here. 5.4 is the best of the 5.x series but we (I mean at my company, not speaking as a FreeBSD rep) haven't put it through as much stress as we have 4.11 . I forgot to mention the other reason I recommend 4.11 first: http://www.freebsd.org/security/index.html 4.11-R is scheduled to receive security updates 8 months longer than 5.4-R, which may be relevant if you want to stick with a specific version for a while. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failed installation of FreeBSD 5.4
On Fri, 12 Aug 2005, Greg Barniskis wrote: It can be argued (and has been, a lot) whether the hardware problems that some folks clearly do have are the fault of the hardware or of the new FreeBSD architecture. Myself, I think it's probably a little of each. Even though the hardware in question often works fine with other operating systems, that's not in my view conclusive evidence that the new FreeBSD code is bad. Make up your own mind, by all means, but jumping to conclusions is rarely going to help you actually resolve a problem. I believe it's a little bit of each as well -- however, there have always been hardware problems, and sometimes they just need to be hammered at with software until they work. There are some issues with modern hardware that some (including myself) should have come up during testing (crashes w/ PAE, kernel dumps don't, 2GB filesystem/drive problems, sysinstall bugs). I suspect that part of the problem is that this hardware may not be immediately available to the FreeBSD developers, so they might be flying blind. I've been trying to collect information as I see the issues, and opening PRs, but if you go over the PR list you'll see some open issues for years. I'm not sure if the issues will be handled, or if they have been and the tickets just haven't been closed. Unfortunately I'm not currently in a position to offer hardware loans to developers so they can work out the kinks. I'm hoping that will change (especially for large RAID support) but it's not directly in my hands. With the solid FreeBSD 4.x relegated to legacy status, we've been forced to use FreeBSD 5.x on some servers at customers requests, with very mixed success. 5.4 seems relatively OK, so far, but earlier releases have some random crash issues on hardware that has appeared stable in the past. When the latest legacy 4.x release version has a EOL that is further off than the latest best 5.x release, and with developers moving on to 6.0 and 7.0, it's hard to stay motivated, as a user, to continue to submit bugs for older releases (older as in not even a year old). I can and will continue to submit bugs as I see them, but as I'm working with production systems, I can't just upgrade the entire OS to the latest version, if that's the answer, which it often is. This may sound bitchy, but at the time of this email there are 4920 non-closed PRs for FreeBSD. It'd be great if these could be handled before or at the same time as developers move on to the bigger, better code. I know the answer here is that it's an open system, and if I think it should be done, I should do it -- unfortunately I do not have the skill set necessary to fix these bugs. If there is a way I could help out, I would. The FreeBSD Foundation activity list doesn't include fixing old bugs -- http://www.freebsdfoundation.org/activities.shtml . Their goal appears to be adding features, which is understandable; it's way sexier than bug fixing, in any case. Is there another organization I could donate money to (and perhaps even time, if possible), that would be working towards making FreeBSD a stable platform on modern hardware? I realize this email may turn people against me and my bug reports (if I'm even important enough to remember, heh!) for being so bitchy. It's been on my mind for a while, mainly because I still feel FreeBSD provides the best platform for web services (at least the type I work with). I'd just prefer that open PRs take priority over new features. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie Q: No login prompt on startup
On Thu, 11 Aug 2005, Eric Lance wrote: Hello all, I just finished installing FreeBSD 5.4 on my PC. When i boot it normally all of the startup scripts finish, no errors are displayed but afterwards a login prompt fails to appear. If i boot in single user mode I get my '#' prompt right off the bat and can edit files. What is going on? Does my machine think I have a terminal connected to the serial port? What config file do i need to edit? I used standard install method from CD. I'm running an Nforce2 chipset and my HDD is SATA, but FreeBSD seems to be dealing with these just fine. Thank you, Eric I'd check /etc/ttys and make sure you have this line: ttyv0 /usr/libexec/getty Pc cons25 on secure exactly as above. At the very least, with 'on' and 'secure' in the line. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Newbie Q: No login prompt on startup
On Fri, 12 Aug 2005, Hexren wrote: The next time that happens try ^C. If the startup process hangs in bringing up a daemon you cann kill that like any other foreground running process. Maybe that was what hit you at least it sound a lot like that to me. Hexren Also, try ^T. ^T should tell you what program is running, and, on occasion, might give you additional information. Try it next time you're waiting for the automatic fsck to finish, for an example. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wizard mode docs
On Thu, 11 Aug 2005, Randy Schultz wrote: Hey all, Is there any documentation on wizard mode? I'm just wondering what the scan function does. Looking at the source, I would guess that it counts how many 512 byte blocks there are on a device. It prints B: at the beginning and G: at the end of the device, I believe. It appears to be capable of handling multiple beginnings and ends, but I'm not sure how that works (would a read of the full disk device, at the end of a slice, not read a full 512 bytes? I don't know.) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help on bash script?
On Fri, 12 Aug 2005, Xu Qiang wrote: Hi, all: I don't know if this is the right list to ask this question. But since I didn't find a bash script mail list and you guys are always so helpful, then... Here are an excerpt of a bash script: --- #!/bin/bash # saveLogs.sh - Bourne Again Shell script ... find / -type f -name core -print | while read COREFILE ; do NCOREFILES=$[ $NCOREFILES + 1 ] # a bit strange - xq echo $NCOREFILES # xq ... --- ... 1. The way of incrementing the variable NCOREFILES. Why does it use the formula of NCOREFILES=$[ $NCOREFILES + 1 ], and not the direct way of NCOREFILES=$NCOREFILES+1? If that was done, NCOREFILES would end up looking like: +1+1+1+1+1+1+1 as bash does not automatically differentiate between numeric and string variables. What the funky looking construct does is convince bash to treat it as a numeric/arithmetic expression. 2. What confused me most is the value of the variable NCOREFILES ($NCOREFILES). Say there is just 1 core file, then because the initial value of NCOREFILES is 0, it will be incremented to 1. Yes, this is the value in the do-while loop. But outside the loop and if-block, the value of NCOREFILES is reverted back to 0 - its initial value. It is a local variable, so any modification to it should be valid as long as we are still in the scope of the function, right? I am really lossed at this phenomenon. As soon as you used the pipe, to the while, you entered a sub-shell. There's no way (that I'm aware of anyways) to get the sub-shell's variables sent back up to the parent. You could do something along the lines of: for cf in `find -X -type f -name core -print` do # do stuff with $cf NCOREFILES=$[ $NCOREFILES + 1 ] done (the -X helps prevent problems when faced with spaces embedded in the path) By the way, on FreeBSD systems, the default core filename format is %N.core (see man core) where %N is the name of the program that dumped. You'd need to expand your find with -name \*.core . If you wanted to get really fancy, you could parse sysctl kern.corefile to find out the current filename format and use that in your find, but most people leave that sysctl at its default, so it probably wouldn't be necessary. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Help on bash script?
On Fri, 12 Aug 2005, Xu Qiang wrote: This is my test script: - #!/bin/bash var=0 var=$[3] vari=0 ++vari echo $var echo $vari - The result is: ./test.sh: ++vari: command not found 3 0 So the manual of bash is incorrect? Regards, Xu Qiang It will work with either 'let' or within an 'arithmetic expansion': $[++var] let ++var By the way, there is another syntax, from the man page, that seems to operate identically: $((++var)) and $((var+1)) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fdisk maximum partition size
On Wed, 10 Aug 2005, Valerio daelli wrote: Hi all does anyone know any maximum limit to the slice size in freebsd? We would like to create a filesystem of 2.2T. Is there any limit in fdisk and bsdlabel? Thanks a lot fdisk does not support 2TB partitions -- at least, I've been unable to get it to work, just gives me zeros. From the advice I've read, what you'd be best off doing is skipping fdisk and labeling and just run newfs against the drive itself. IE: newfs /dev/da0 Of course, this means you will not be able to boot off of the large device. That's the price we pay for being on the cutting edge. There are still several utilities that do not yet handle large partitions -- the project page is available here: http://www.freebsd.org/projects/bigdisk/ Another option for you is available if you're using the 3Ware cards: you can enable auto-carving in its BIOS, to split the device into 2TB chunks. FreeBSD 5.4-RELEASE can only read the first of these chunks, but if you update to 5.4-STABLE, with its new twa driver, you can access the other chunks. (* There may be a better term than chunks, but slices and partitions are already used interchangably (and non-interchangably), so I'm going with chunks.) This works out pretty well in practice except for having to divide files between mount points by hand. If you run into any panics or bugs about this please open PRs. There only seems to be a few of us FreeBSD users with multi-terabyte partitions and there are still some bugs to be worked out. You may not be able to get a kernel dump (I wasn't, even with 5.4-R and 1TB partitions (had to put the server into production before I could report this bug unfortunately)) but you could still get a backtrace for the developers to use. ___ 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.4-RELEASE-p5 panic
On Tue, 2 Aug 2005, dpk wrote: (Another panic I would get would follow roughly the same path except it would die while trying to unlock a vnode lock that the thread didn't own. I'll try to get this information some time, too.) Here's the backtrace from that panic: #0 kdb_enter (msg=0x12 Address 0x12 out of bounds) at ../../../kern/subr_kdb.c:266 #1 0xc033ea1f in panic (fmt=0xc04c99ff lockmgr: thread %p, not %s %p unlocking) at ../../../kern/kern_shutdown.c:550 #2 0xc0333181 in lockmgr (lkp=0xc61f5e14, flags=6, interlkp=0x100, td=0x0) at ../../../kern/kern_lock.c:419 #3 0xc038b08b in vop_stdunlock (ap=0x12) at ../../../kern/vfs_default.c:295 #4 0xc038af3b in vop_defaultop (ap=0x0) at ../../../kern/vfs_default.c:157 #5 0xc03010bb in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118 #6 0xc0301648 in spec_write (ap=0xeb858a94) at vnode_if.h:1044 #7 0xc03010bb in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118 #8 0xc0452ecd in vnode_pager_generic_putpages (vp=0xc61f5d68, m=0xeb858bf0, bytecount=4096, flags=0, rtvals=0xeb858b70) at vnode_if.h:432 #9 0xc038b7e2 in vop_stdputpages (ap=0x12) at ../../../kern/vfs_default.c:650 #10 0xc038af3b in vop_defaultop (ap=0x0) at ../../../kern/vfs_default.c:157 #11 0xc03010bb in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118 #12 0xc0452c6a in vnode_pager_putpages (object=0xc085e7bc, m=0x12, count=18, sync=0, rtvals=0x12) at vnode_if.h:1357 #13 0xc044a603 in vm_pageout_flush (mc=0xeb858bf0, count=1, flags=0) at vm_pager.h:147 #14 0xc044a52d in vm_pageout_clean (m=0x0) at ../../../vm/vm_pageout.c:347 #15 0xc044b3df in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:996 #16 0xc044c162 in vm_pageout () at ../../../vm/vm_pageout.c:1487 #17 0xc032911d in fork_exit (callout=0xc044be50 vm_pageout, arg=0x0, frame=0xeb858d48) at ../../../kern/kern_fork.c:791 #18 0xc0474fcc in fork_trampoline () at ../../../i386/i386/exception.s:209 Again, vm_pageout_clean is being called with a NULL argument, and eventually the spec_vnoperate function is called with a NULL (the other panic, ufs_vnoperate was called with a NULL). These couple of panics are relatively easy to reproduce on demand. Interestingly (I think), vm_pageout_flush's m argument was the same with each panic: 0xeb858bf0 . That is decimal 3,951,397,872 . When you boot these servers without PAE enabled, the real memory is 3,757,965,312. I think this indicates that the page vnode_pager_generic_putpages is dealing with is within the PAE range (I don't know exactly how to describe that). This could be a total long shot, but I think it's unlikely that both panics would have something like that in common without it being a bug of some sort. If there's somewhere else I should be sending these please let me know. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4-RELEASE-p5 panic
After much struggling (documented elsewhere) I have a backtrace showing
one of a handful of panics I am getting on a FreeBSD 5.4-RELEASE-p5
system. The server has 4GB RAM, and is running with PAE and SMP enabled.
If this is not the appropriate list for this, I can send it elsewhere,
please let me know.
(gdb) bt
#0 kdb_enter (msg=0x12 Address 0x12 out of bounds) at
../../../kern/subr_kdb.c:266
#1 0xc033ea1f in panic (fmt=0xc04d782d ffs_write: dir write) at
../../../kern/kern_shutdown.c:550
#2 0xc04292de in ffs_write (ap=0xeb858a94) at ../../../ufs/ffs/ffs_vnops.c:614
#3 0xc0452e71 in vnode_pager_generic_putpages (vp=0xc6237630, m=0xeb858bf0,
bytecount=4096,
flags=0, rtvals=0xeb858b70) at vnode_if.h:432
#4 0xc038b7e2 in vop_stdputpages (ap=0x12) at ../../../kern/vfs_default.c:650
#5 0xc038af3b in vop_defaultop (ap=0x0) at ../../../kern/vfs_default.c:157
#6 0xc0435ebf in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2821
#7 0xc0452c0e in vnode_pager_putpages (object=0xc6901a50, m=0x12, count=18,
sync=0, rtvals=0x12)
at vnode_if.h:1357
#8 0xc044a5db in vm_pageout_flush (mc=0xeb858bf0, count=1, flags=0) at
vm_pager.h:147
#9 0xc044a505 in vm_pageout_clean (m=0x0) at ../../../vm/vm_pageout.c:347
#10 0xc044b386 in vm_pageout_scan (pass=1) at ../../../vm/vm_pageout.c:985
#11 0xc044c106 in vm_pageout () at ../../../vm/vm_pageout.c:1476
#12 0xc032911d in fork_exit (callout=0xc044bdf4 vm_pageout, arg=0x0,
frame=0xeb858d48)
at ../../../kern/kern_fork.c:791
#13 0xc0474f6c in fork_trampoline () at ../../../i386/i386/exception.s:209
(Another panic I would get would follow roughly the same path except it
would die while trying to unlock a vnode lock that the thread didn't own.
I'll try to get this information some time, too.)
This might all trace back to vm_pageout_clean() being called with as NULL
argument. Looking at vm_pageout_clean, it looks as though that should
never happen -- at least, there's nothing there that checks if it is NULL
before it goes on to treat it as a pointer to a struct:
static int
vm_pageout_clean(m)
vm_page_t m;
{
vm_object_t object;
vm_page_t mc[2*vm_pageout_page_count];
int pageout_count;
int ib, is, page_base;
vm_pindex_t pindex = m-pindex;
mtx_assert(vm_page_queue_mtx, MA_OWNED);
VM_OBJECT_LOCK_ASSERT(m-object, MA_OWNED);
In frame #10, vm_pageout_scan:
#10 0xc044b386 in vm_pageout_scan (pass=1) at ../../../vm/vm_pageout.c:985
985 if (vm_pageout_clean(m) != 0) {
(gdb) p m
$65 = 0xc0da66f8
(gdb) p *m
$78 = {pageq = {tqe_next = 0xeb858cb0, tqe_prev = 0xc231c840},
listq = {tqe_next = 0x0, tqe_prev = 0xc6901a88}, left = 0x0,
right = 0x0, object = 0xc6901a50, pindex = 1, phys_addr = 296792064,
md = {pv_list_count = 0, pv_list = {tqh_first = 0x0,
tqh_last = 0xc0da6728}},queue = 33, flags = 4, pc = 11,
wire_count = 0, hold_count = 0, act_count = 0 '\0', busy = 1 '\001',
valid = 255 '', dirty = 255 '', cow = 0}
So it seems as though m is getting lost. What follows that seems to be
undefined behavior. (I have slightly modified the above. valid had a 'y'
shaped upper-8-bit symbol between the quotes, and formatted it to fit in
80 columns).
I'll admit I'm quite green when it comes to debugging kernels, especially
5.x kernels. It gets really tricky when some functions trace back to .h
files, and not all of the variables seem available to the debugger. The
servers appear to work fine without PAE enabled, if that's of interest.
This gdb session is still active and I hope to keep it active in case
there are other commands you'd like me to run that might help shed some
light on the situation.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4-RELEASE-p5 panics
I'm getting some panics on a few FreeBSD 5.4 boxes, and I'm trying to figure out a way to get them to drop to some sort of debugger, or to dump core. It used to be that you'd just add: options DDB options DDB_UNATTENDED and build a kernel with -g, set 'dumpon', and then when it paniced it would write it out to disk. For 5.4, I understand you also need options KDB, and you need to replace DDB_UNATTENDED with KDB_UNATTENDED. I've done all of that, but the panic did not trigger a core dump, and did not leave me at a prompt (the latter probably because of KDB_UNATTENDED?). The panic message, in the present case, in case someone's seen this particular problem before: Fatal trap 12: page fault while in kernel mode. cpuid = 01; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc035c7cf stack pointer = 0x10:0xeb858c74 frame pointer = 0x10:0xeb858c88 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL equal 0 current process = 8 (pagedaemon) Would this sort of panic prevent a dump from occuring? BTW: I have checked the handbook and haven't found the answer (it doesn't seem to mention KDB at all). Unfortunately the kernel buffer appears insufficient to store all the output from boot -v, so I'm booting it with no flags. I've included the output of dmesg. Following that is the kernel's config. sysctl -a output is available at http://dpk.net/5.4-sysctl.txt (35KB) Copyright (c) 1992-2005 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 5.4-RELEASE-p5 #2: Sun Jul 31 20:58:46 PDT 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/STD-PAE MPTable: INTELLINDENHURST Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 4831838208 (4608 MB) avail memory = 4194848768 (4000 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic2: Assuming intbase of 48 ioapic3: Assuming intbase of 72 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard ioapic3 Version 2.0 irqs 72-95 on motherboard npx0: math processor on motherboard npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: PCI bus on pcib1 pcib2: PCI-PCI bridge at device 0.0 on pci1 pci3: PCI bus on pcib2 pcib3: MPTable PCI-PCI bridge at device 0.2 on pci1 pci2: PCI bus on pcib3 3ware device driver for 9000 series storage controllers, version: 2.50.02.012 twa0: 3ware 9000 series Storage Controller port 0xa800-0xa8ff mem 0xfb80-0xfbff,0xfc8ffc00-0xfc8ffcff irq 72 at device 1.0 on pci2 twa0: 4 ports, Firmware FE9X 2.04.00.005, BIOS BE9X 2.03.01.047 pcib4: PCI-PCI bridge irq 16 at device 3.0 on pci0 pci4: PCI bus on pcib4 pcib5: MPTable PCI-PCI bridge at device 28.0 on pci0 pci5: PCI bus on pcib5 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xbc00-0xbc3f mem 0xfc9e-0xfc9f irq 26 at device 1.0 on pci5 em0: Ethernet address: 00:30:48:83:0a:f8 em0: Speed:N/A Duplex:N/A em1: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xb800-0xb83f mem 0xfc9a-0xfc9b irq 27 at device 2.0 on pci5 em1: Ethernet address: 00:30:48:83:0a:f9 em1: Speed:N/A Duplex:N/A pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: base peripheral at device 29.4 (no driver attached) pci0: base peripheral, interrupt controller at device 29.5 (no driver attached) pci0: serial bus, USB at device 29.7 (no driver attached) pcib6: MPTable PCI-PCI bridge at device 30.0 on pci0 pci6: PCI bus on pcib6 pci6: display, VGA at device 2.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel 6300ESB UDMA100 controller port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) orm0: ISA Option ROMs at iomem 0xca800-0xcb7ff,0xc9800-0xca7ff,0xc8000-0xc97ff,0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0
Syncing disks, buffers remaining - value increases?
Sorry for all the questions to the list, we're having a number of issues deploying FreeBSD 5.4 and we're trying to get an understanding of what we're seeing. When I reboot these servers (using reboot on the command line), it will go through the usual routine I'm familiar with from FreeBSD 4.x, but when it goes to the syncing disks phase, sometimes it will do something like this: Syncing disks, buffers remaining ... 1 1 1 1 1 2 1 1 1 3 1 1 1 1 Eventually it gives up on 1 or so buffers. When the server comes back up, it gives warnings that the partitions were all improperly dismounted. Is it normal for the number of buffers remaining to actually increase while shutting down? I'm looking at the kernel source and the loop that performs these syncs appears pretty small. Could something else still be running on the server that is trying to write to disk, even while in the shutdown phase? I guess it would only be able to run interrupt threads, judging by the comments, while it releases Giant. It may be a coincidence, but on a few occasions, the background fsck may have still been running when the reboot was issued. I've assumed that since fsck now runs in the background that it must be able to gracefully handle reboots. FreeBSD 5.4-RELEASE-p5, Dual proc Xeons (varying speed), varying memory, PAE+SMP kernels, 3ware RAID cards (varying capacity, RAID levels). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large filesystem woes
The resolution to this problem turned out to be enabling the 3Ware 9500S auto carving option. This splits all partitions into 2TB chunks, which are then presented to the OS as separate LUNs. FreeBSD 5.4-RELEASE's driver for the 3Ware card does not support multiple LUNs, but the new driver (Common Layer) in 5.4-STABLE does. So if you're running in to this same problem, here's a quick run down of what you need to do: 1) Enable auto-carving in either the 3ware BIOS or in the 3dm web control panel. 2) Delete and then re-create any RAID that is larger than 2TB, that you want accessable from the OS. If you have sufficient drives available, you can migrate the data to a new RAID, instead of deleting. 3) Install 5.4-RELEASE. sysinstall will show you a single 2TB device. Feel free to use that device however you wish -- you can fill it to its boundaries. 4) cvsup to 5.4-STABLE, make buildworld buildkernel installkernel, reboot. 5) You'll now see da1 and perhaps da2 and beyond, in dmesg or camcontrol devlist. If you should ever have to reboot into the 5.4-RELEASE GENERIC kernel, the da1..n partitions will be unavailable. da0, however, will operate normally. As such it is safe to use as a boot device. (For sanity's sake it is probably best to create a much smaller slice or partition for system files, but that's your decision). ___ 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.4+SMP, severe network degredation
By the way, I also compared GENERIC performance against GENERIC w/ options SMP added, and had the same results. On Wed, 27 Jul 2005, dpk wrote: We just received several SuperMicro servers, 3.0Ghz Xeon x 2, 4GB RAM. They're using the em driver and the ports are set to 1000Mbit (we also tried 100Mbit/full duplex on the card and on the switch). They're running FreeBSD 5.4. I ran a steady ping on a couple of them while they were running GENERIC, and then rebooted them with a kernel built with the PAE kernel included with the installation, with option SMP added. The PAE-SMP-GENERIC kernel was built after cvsup'ing with tag=RELENG_5_4 and the uname reports 5.4-RELEASE-p5. Here are the ping results: GENERIC: 117 packets transmitted, 117 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.451/0.554/0.856/0.059 ms PAE-SMP-GENERIC: 102 packets transmitted, 102 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.569/4.262/7.944/2.065 ms Fetching a 637MB ISO from a local server, also on 100/FDX: GENERIC: /dev/null 100% of 637 MB 10 MBps 00m00s real0m58.071s user0m1.954s sys 0m6.278s PAE-SMP-GENERIC: /dev/null 100% of 637 MB 5764 kBps 00m00s real1m53.324s user0m1.478s sys 0m5.624s Running GENERIC, systat shows about 7000 interrupts/second, and around 600 interrupts/second using PAE-SMP-GENERIC, while fetch was running. I've checked the errata and hardware notes, as well as gnats, and was not able to find anything that explains or matches this behavior. We've run SMP servers for years, using 4.5-4.11, but we've never seen the network performance cut in half (or pings go up 10x). Removing option SMP makes the problem go away, but at a very significant performance cost obviously. Could it be something from -p5? Is this explained/examined in a PR I've missed, and if so can I add some information? ___ 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.4+SMP, severe network degredation
Woah. Well, I guess I didn't try *everything*. Removing device acpi from the kernel config leaves me witih a PAE+SMP kernel that works fine. I can fetch files at wire speed and everything. So, I guess this issue is closed. acpi was the ultimate culprit. On Thu, 28 Jul 2005, dpk wrote: By the way, I also compared GENERIC performance against GENERIC w/ options SMP added, and had the same results. On Wed, 27 Jul 2005, dpk wrote: We just received several SuperMicro servers, 3.0Ghz Xeon x 2, 4GB RAM. They're using the em driver and the ports are set to 1000Mbit (we also tried 100Mbit/full duplex on the card and on the switch). They're running FreeBSD 5.4. I ran a steady ping on a couple of them while they were running GENERIC, and then rebooted them with a kernel built with the PAE kernel included with the installation, with option SMP added. The PAE-SMP-GENERIC kernel was built after cvsup'ing with tag=RELENG_5_4 and the uname reports 5.4-RELEASE-p5. Here are the ping results: GENERIC: 117 packets transmitted, 117 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.451/0.554/0.856/0.059 ms PAE-SMP-GENERIC: 102 packets transmitted, 102 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.569/4.262/7.944/2.065 ms Fetching a 637MB ISO from a local server, also on 100/FDX: GENERIC: /dev/null 100% of 637 MB 10 MBps 00m00s real0m58.071s user0m1.954s sys 0m6.278s PAE-SMP-GENERIC: /dev/null 100% of 637 MB 5764 kBps 00m00s real1m53.324s user0m1.478s sys 0m5.624s Running GENERIC, systat shows about 7000 interrupts/second, and around 600 interrupts/second using PAE-SMP-GENERIC, while fetch was running. I've checked the errata and hardware notes, as well as gnats, and was not able to find anything that explains or matches this behavior. We've run SMP servers for years, using 4.5-4.11, but we've never seen the network performance cut in half (or pings go up 10x). Removing option SMP makes the problem go away, but at a very significant performance cost obviously. Could it be something from -p5? Is this explained/examined in a PR I've missed, and if so can I add some information? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large filesystem woes
On Thu, 21 Jul 2005, Giorgos Keramidas wrote: Are you trying to start from scratch, or just making changes to the existing table? If it's the second, then try the -u option: # fdisk -u /dev/da0 This should give you a chance to interactively change the partition table of the disk. If this fails too, please show us the exact command line you used and the exact error messages. - Giorgos Unfortunately I can't run fdisk -u, if that command will wipe out the partition table, since / is also on the array, just in a smaller partition. I found this page: http://www.freebsd.org/projects/bigdisk/ It was last updated in January. Has there been more progress on this front? I wonder if this is all a known problem, and I just overlooked it because of my understanding that UFS2 is supposed to handle large partitions. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large filesystem woes
On Fri, 29 Jul 2005, Giorgos Keramidas wrote: It won't wipe away the table. It will just let you edit the existing table interactively, through a series of questions like: - Do you want to edit partition 1? - Do you want to edit partition 2? - Do you want to edit partition 3? - Do you want to edit partition 4? - Do you want to change the active partition? - Do you want to save your changes to the disk? # df -k Filesystem 1K-blocksUsedAvail Capacity Mounted on /dev/da0s1a 35082074 1147642 31127868 4%/ devfs 1 10 100%/dev procfs 4 40 100%/proc # fdisk -u fdisk: cannot open disk /dev/da0: No such file or directory # ls -ald /dev/da0* crw-r- 1 root operator4, 12 Jul 28 15:56 /dev/da0 crw-r- 1 root operator4, 13 Jul 28 15:56 /dev/da0s1 crw-r- 1 root operator4, 18 Jul 28 08:56 /dev/da0s1a crw-r- 1 root operator4, 19 Jul 28 15:56 /dev/da0s1b crw-r- 1 root operator4, 20 Jul 28 15:56 /dev/da0s1c truss indicates that fdisk may be getting the error from somewhere else: stat(/dev/da0,0xbfbfeb30) = 0 (0x0) open(/dev/da0,0x2,00) ERR#1 'Operation not permitted' open(/dev/da0,0x0,027757765630)= 6 (0x6) open(/dev/da0s1,0x2,01001210100) ERR#1 'Operation not permitted' open(/dev/da0s2,0x2,01001210100) ERR#2 'No such file or directory' open(/dev/da0s3,0x2,01001210100) ERR#2 'No such file or directory' open(/dev/da0s4,0x2,01001210100) ERR#2 'No such file or directory' Because it is using devfs, I'm not able to create these missing slices in /dev. Most unfortunately, it appears it uses devfs in single user mode as well, so I can't test the theory. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large filesystem woes
On Thu, 28 Jul 2005, dpk wrote: truss indicates that fdisk may be getting the error from somewhere else: stat(/dev/da0,0xbfbfeb30) = 0 (0x0) open(/dev/da0,0x2,00) ERR#1 'Operation not permitted' open(/dev/da0,0x0,027757765630)= 6 (0x6) open(/dev/da0s1,0x2,01001210100) ERR#1 'Operation not permitted' open(/dev/da0s2,0x2,01001210100) ERR#2 'No such file or directory' open(/dev/da0s3,0x2,01001210100) ERR#2 'No such file or directory' open(/dev/da0s4,0x2,01001210100) ERR#2 'No such file or directory' Because it is using devfs, I'm not able to create these missing slices in /dev. Most unfortunately, it appears it uses devfs in single user mode as well, so I can't test the theory. Under a chrooted shell, I created the s1-4 /dev entries. fdisk -u now reports 'Device not configured', which supports the theory that fdisk is just using whatever error it last sees and gives up. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large filesystem woes
On Fri, 29 Jul 2005, Giorgos Keramidas wrote:
Hmmm, in multiuser mode, your root filesystem is mounted as read-write
and it resides in da0, so GEOM will forbid opening the disk device in
read-write mode for editing the partition table.
In single user mode, devfs is still used, but your root filesystem
should be mounted read-only (unless you manually mount it as
read-write), so fdisk -u should work.
I've remounted the disk readonly, and was still seeing the same errors.
I've looked at the fdisk source and compared it to the truss output.
... /* rwmode is O_RDWR due to -u */
fd = open(disk, rwmode);
... /* errno is EPERM here, from truss */
if (fd == -1 errno == ENXIO)
return -2;
if (fd == -1 errno == EPERM rwmode == O_RDWR) {
... /* this is successful: */
fd = open(disk, O_RDONLY);
... /* the following opens get device not configured, or no such file or
directory under normal operation, from truss */
for (p = 1; p 5; p++) {
asprintf(s, %ss%d, disk, p);
fdw = open(s, O_RDONLY);
free(s);
if (fdw == -1)
continue;
break;
}
... /* ah ha! open_disk is returning -4 because the last slice had some
error */
if (fdw == -1)
return -4;
This change was introduced with version 1.67 of the fdisk.c file.
Commenting out if (fdw == -1) return -4; allows fdisk -u to function. Here
are the results, not changing anything:
# ./fdisk -u
*** Working on device /dev/da0 ***
parameters extracted from in-core disklabel are:
cylinders=534921 heads=255 sectors/track=63 (16065 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=534921 heads=255 sectors/track=63 (16065 blks/cyl)
Do you want to change our idea of what BIOS thinks ? [n]
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 75489372 (36860 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 254/ sector 63
Do you want to change it? [n]
The data for partition 2 is:
UNUSED
Do you want to change it? [n]
The data for partition 3 is:
UNUSED
Do you want to change it? [n]
The data for partition 4 is:
UNUSED
Do you want to change it? [n]
Partition 1 is marked active
Do you want to change the active partition? [n]
Here are the results of ./fdisk -u when trying to add the second
partition:
# ./fdisk -u
*** Working on device /dev/da0 ***
parameters extracted from in-core disklabel are:
cylinders=534921 heads=255 sectors/track=63 (16065 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=534921 heads=255 sectors/track=63 (16065 blks/cyl)
Do you want to change our idea of what BIOS thinks ? [n] n
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 75489372 (36860 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 254/ sector 63
Do you want to change it? [n] n
The data for partition 2 is:
UNUSED
Do you want to change it? [n] y
Supply a decimal value for sysid (165=FreeBSD) [0] 165
Supply a decimal value for start [0]
Supply a decimal value for size [0]
fdisk: ERROR: size of partition is zero
fdisk: ERROR: failed to adjust; setting sysid to 0
Explicitly specify beg/end address ? [n] y
Supply a decimal value for beginning cylinder [0] 1024
Supply a decimal value for beginning head [0]
Supply a decimal value for beginning sector [0]
Supply a decimal value for ending cylinder [0] 534921
Supply a decimal value for ending head [0] 254
Supply a decimal value for ending sector [0] 63
sysid 0 (),(unused)
start 0, size 0 (0 Meg), flag 0
beg: cyl 0/ head 0/ sector 0;
end: cyl 393/ head 254/ sector 63
Writing it fails, but I didn't really expect it to succeed with the above
values. There's some overflowing going on.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4+SMP, severe network degredation
We just received several SuperMicro servers, 3.0Ghz Xeon x 2, 4GB RAM. They're using the em driver and the ports are set to 1000Mbit (we also tried 100Mbit/full duplex on the card and on the switch). They're running FreeBSD 5.4. I ran a steady ping on a couple of them while they were running GENERIC, and then rebooted them with a kernel built with the PAE kernel included with the installation, with option SMP added. The PAE-SMP-GENERIC kernel was built after cvsup'ing with tag=RELENG_5_4 and the uname reports 5.4-RELEASE-p5. Here are the ping results: GENERIC: 117 packets transmitted, 117 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.451/0.554/0.856/0.059 ms PAE-SMP-GENERIC: 102 packets transmitted, 102 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.569/4.262/7.944/2.065 ms Fetching a 637MB ISO from a local server, also on 100/FDX: GENERIC: /dev/null 100% of 637 MB 10 MBps 00m00s real0m58.071s user0m1.954s sys 0m6.278s PAE-SMP-GENERIC: /dev/null 100% of 637 MB 5764 kBps 00m00s real1m53.324s user0m1.478s sys 0m5.624s Running GENERIC, systat shows about 7000 interrupts/second, and around 600 interrupts/second using PAE-SMP-GENERIC, while fetch was running. I've checked the errata and hardware notes, as well as gnats, and was not able to find anything that explains or matches this behavior. We've run SMP servers for years, using 4.5-4.11, but we've never seen the network performance cut in half (or pings go up 10x). Removing option SMP makes the problem go away, but at a very significant performance cost obviously. Could it be something from -p5? Is this explained/examined in a PR I've missed, and if so can I add some information? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Large filesystem woes
On Wed, 20 Jul 2005, Lowell Gilbert wrote: dpk [EMAIL PROTECTED] writes: Has anyone here had any luck whatsoever getting FreeBSD 5.4-RELEASE to use 4TB of space from a 4TB RAID array? It is apparent that there is a 1TB/slice limit, and sysinstall doesn't seem to be able to handle creating more than 2 slices. Since you're using slices, I would try working with fdisk directly... fdisk gives a No such file or directory error when you run fdisk -i /dev/da0, but fdisk /dev/da0 shows the partition table. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Large filesystem woes
Has anyone here had any luck whatsoever getting FreeBSD 5.4-RELEASE to use 4TB of space from a 4TB RAID array? It is apparent that there is a 1TB/slice limit, and sysinstall doesn't seem to be able to handle creating more than 2 slices. I read somewhere that people recommend using gpt to manage large filesystems. Unfortunately, this tool is not to be found on the fixit floppy or the mfsroot during installation. If the server is up, gpt complains about Operation not permitted because the disk is in use. I managed to get gpt on a floppy -- along with a hand written cp/mkdir all-in-one binary because, when you use the Fixit option it does not chroot you to the fixit floppy, meaning you'll need /libexec/ld-elf.so.1 and /lib/libc.so.5, because for some reason critical system utilities are built dynamically now but I am straying from the topic -- and ran gpt migrate as recommended in its man page. Now gpt no longer recognizes the the disk at all. gpt show fails entirely. gpt -vvv show lists some entries, but the sizes are all very wrong, as if they were truncated. Anyone know the specific tricks involved in getting all 4TB used, even if it has to be in 4 different slices, or am I stuck with using just 2TB? We're gonna have to go with Linux on this particular server since we need it up today but we'll be getting another one soon and I can try things there. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Server throwing NMI ISA 20, EISA ff messages
We have various servers, with various versions of FreeBSD throwing these NMI messages: NMI ISA 3c, EISA ff NMI ISA 2c, EISA ff NMI ISA 20, EISA ff There's no information about this anywhere that I can see, but at least two other people have had the problem according to Google searches. If tripwire is running while one of these messages appears, sometimes it shows false alarms about files, indicating either memory or drive controller problems, maybe? At first we thought it might just be dodgy hardware. We were only getting the first two errors on some of our older 2U white box machines. However, this morning, we just got the third error (just prior to a complete freeze) on a modern Dell 1750, 1GB RAM, 2.8Ghz. The kernel source reveals nothing of use about what these errors could be. Does anyone have a chart of what the numbers next to ISA mean, or have any ideas where I should turn for answers? Thanks! I'm off-list, so please Cc: me on any replies. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory leak on 5.1-RELEASE?
leak in 5.1, since I've seen running 5.1 just fine on a PE2650 with 2 GB RAM. You shouldn't rely on top too much acually. Vmstat is a better program when looking at memory. Cheers, Jorn - Original Message - From: dpk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 31, 2004 1:10 AM Subject: Memory leak on 5.1-RELEASE? (I'm not a member of the list; please Cc me on any replies.) We're running Apache 1.3.28 on a 5.1-RELEASE machine. It's a Dell PE 2650 w/ 2GB RAM. The site contains a lot of large files (multi-megabyte) - otherwise there's nothing unusual running. The Active memory use, according to top, seems rather high: last pid: 21487; load averages: 0.19, 0.33, 0.32up 2+16:45:20 15:52:21 76 processes: 1 running, 75 sleeping CPU states: 0.5% user, 0.0% nice, 4.0% system, 1.4% interrupt, 94.2% idle Mem: 1413M Active, 187M Inact, 299M Wired, 93M Cache, 112M Buf, 2632K Free Swap: 1024M Total, 21M Used, 1003M Free, 2% Inuse We can't seem to get the Active number down much, even after stopping Apache it still stays around 1100M. There's no shared memory in use, and nothing in vmstat -m seems to indicate where the missing memory is. top, sorting by size, does not indicate anything unusual either. sysctl vm.vmtotal says: vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) === Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 76) Virtual Memory: (Total: 8172K, Active 636472K) Real Memory:(Total: 2051312K Active 389176K) Shared Virtual Memory: (Total: 16436K Active: 11760K) Shared Real Memory: (Total: 6004K Active: 4436K) Free Memory Pages: 79228K whereas on other servers, the Real Memory Active number seems to match the one found in top, on this one it is about 1GB lower. A similar machine running Apache on 5.1-R, generally serving smaller files, has the same problem in a smaller scale (about 640M even when Apache is stopped). Are there any other data that I should send to help diagnose this problem, or any programs I can run to try and track this stray memory use down? - dpk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Memory leak on 5.1-RELEASE?
(I'm not a member of the list; please Cc me on any replies.) We're running Apache 1.3.28 on a 5.1-RELEASE machine. It's a Dell PE 2650 w/ 2GB RAM. The site contains a lot of large files (multi-megabyte) - otherwise there's nothing unusual running. The Active memory use, according to top, seems rather high: last pid: 21487; load averages: 0.19, 0.33, 0.32up 2+16:45:20 15:52:21 76 processes: 1 running, 75 sleeping CPU states: 0.5% user, 0.0% nice, 4.0% system, 1.4% interrupt, 94.2% idle Mem: 1413M Active, 187M Inact, 299M Wired, 93M Cache, 112M Buf, 2632K Free Swap: 1024M Total, 21M Used, 1003M Free, 2% Inuse We can't seem to get the Active number down much, even after stopping Apache it still stays around 1100M. There's no shared memory in use, and nothing in vmstat -m seems to indicate where the missing memory is. top, sorting by size, does not indicate anything unusual either. sysctl vm.vmtotal says: vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) === Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 76) Virtual Memory: (Total: 8172K, Active 636472K) Real Memory:(Total: 2051312K Active 389176K) Shared Virtual Memory: (Total: 16436K Active: 11760K) Shared Real Memory: (Total: 6004K Active: 4436K) Free Memory Pages: 79228K whereas on other servers, the Real Memory Active number seems to match the one found in top, on this one it is about 1GB lower. A similar machine running Apache on 5.1-R, generally serving smaller files, has the same problem in a smaller scale (about 640M even when Apache is stopped). Are there any other data that I should send to help diagnose this problem, or any programs I can run to try and track this stray memory use down? - dpk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
