Adjusting partition size with disklabel
Hi, long story short, I have a partition on a RAID5 array which after an accident where I had to rebuild the array became smaller than it originally was. Here's the original size: amrd1: 1430505MB (2929674240 sectors) RAID 5 (degraded) and the new size after the rebuild: amrd1: 1430400MB (2929459200 sectors) RAID 5 (optimal) Is it possible to use 'bsdlabel -e' to shrink the partition down to a size which will fit the new size of the array? with regards, -- Morten A. Middelthon Which is worse: ignorance or apathy? Who knows? Who cares? pgpLqo4p87Rwb.pgp Description: PGP signature
Re: Weird problem upgrading 5.4 to 6.1
On 6/29/06, Francisco Reyes [EMAIL PROTECTED] wrote: Sergey Shyman writes: Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0. Is that a RAID you are booting from? No, ordinary IDE drive Booting with old kernel works fine. Also BIOS see IDE drive. Single IDE drive? Single IDE drive stay as primary master ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird problem upgrading 5.4 to 6.1
On 6/30/06, Tony Maher [EMAIL PROTECTED] wrote: Sergey Shyman wrote: I have FreeBSD 5.4 box with Intel865 chipset. The 5.4 works fine nearly a year. But strange troubles happens when I've tried to upgrade to 6.1 (via make buildworld make kernel). The loader show me following messages and then hangs when I try to boot new kernel: Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0. Some one else reported similar problem which were traced to having non standard compiler flags in make.conf. In particular -funroll-loops is bad for loader. Yes, I've read about this and try to recompile with -O -pipe and even without make.conf totally -- no luck :( -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
Michel Talon wrote: I guess I'm still just a bit stunned that a bug this obvious not only found it's way into the STABLE branch, but is still there. Maybe it's not as obvious as I think, or not many folks are using it? All I know for sure here is that if I had upgraded to 6.1 my network would have been crippled. Strange, since i upgraded to FreeBSD-6.1 and the NFS server to Fedora Core 5, my machine, NFS client is happy, and lockd works. It is first time since years i have no problem. It certainly did not work with FreeBSD-5 and i still have a machine with FreeBSD-6.0 which does not work properly (frequently loses the NFS mount, but it gets remounted some times later by amd). Anyways i have exactly 0 problem with the 6.1 machine. I could extend that to say that everything works very well on that machine, nothing is slow, including disk access. This has not always been the case. Stability wise, i have not seen any panic, hang or whatever since i have compiled a kernel adapted to my hardware. I got a panic with the generic kernel soon after installation, but now machine is totally stable. Based on prior reading about this problem, I'd venture to guess that the file locking between FC5 and FreeBSD simply isn't. See, between just 2 machines sharing files without rpc.lockd running you won't see a problem. Both the client and the server must not only be running rpc.lockd, but they must be able to actually talk to each other. For a simple 2 machine setup, you don't really need much in the way of locking control, as you don't have to deal with multiple requests for the same resource. This is why folks just running the -L flag on their mount command also aren't having any problems. To actually see the problem isn't too hard to set up. Just have rpc.lockd, rpc.statd, and rpcbind enabled on both the client and the server. Then just starting trying to transfer a stack of files from one to the other. I found this to be true even trying to go from a 5.4 server to my 6.1 laptop here. There was quite a thread on this back in March of this year, along with a few PR's that are still opened up. I'm personally just coming head long into all of this. Later on, -- Michael Collette IT Manager TestEquity Inc [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
the one thing that sticks out to me about this report is that they upgraded teh NFS server to FC5 ... what was the server running before? if FreeBSD, could the problem be an interaction problem between the NFS server and client, vs just the client side? Previously the server used Fedora Core 3. I think like you that it is an interaction between client and server. For example we have a client machine running Debian Unstable which had NFS problems interacting FC3 server and still has with FC5 server. But i don't have any more with Fbsd-6.1. As to the problem of the machine freezing when the server freezes i have always seen that, both under Linux and FreeBSD, nothing new. The freeze seems to me less severe now, that is i have been able to log in root with the server down. The load on the server is rather big, we are talking around 100 machines having their home directories on the server. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
I only started to see the lockd problems when upgrading the server side to FreeBSD 6.x and later. I had various FreeBSD clients, between 4.x and 7-current and the lockd problem only showed up when upgrading the server from 5.x to 6.x. As far as i remember FreeBSD-4 did not have a true lockd, only a fake one, so it was always working no problem. I have used all versions of FreeBSD-5 up to 6.0 and 6.1 on my client with a Linux server, and i can say that 6.1 is the first one which works OK for me. I don't have any experience with FreeBSD server, except the occasional nfs mounting after a make world. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
Based on prior reading about this problem, I'd venture to guess that the file locking between FC5 and FreeBSD simply isn't. See, between just 2 machines sharing files without rpc.lockd running you won't see a problem. Both the client and the server must not only be running rpc.lockd, but they must be able to actually talk to each other. I definitely disagree with that. I have written a little program just to check locking on files on the NFS share, and i can assure you it works. Before FC5 the same program did not work, in fact hanged. You could not kill the program, without unmounting the NFS share. After the upgrade FC3 - FC5 the lockd works and if i try setting a second lock on the same file it will fail. I am using this daily with mutt, no problem. But it is not only lockd which now works, it is more generally NFS. On a 6.0 machine i regularly get things like: Jun 22 17:30:10 asmodee kernel: for server ada:/ada1 Jun 22 17:30:10 asmodee kernel: nfs send error 1 for server ada:/ada1 Jun 22 17:30:10 asmodee last message repeated 797 times Jun 22 17:30:15 asmodee kernel: for server ada:/ada Jun 22 17:30:15 asmodee kernel: nfs send error 1 for server ada:/ada Jun 22 17:30:15 asmodee last message repeated 817 times Jun 22 17:30:20 asmodee kernel: nfs send error 35 for server ada:/ada and the home directories are inaccessible for a couple of minutes. I have never seen that once on the 6.1 machine. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
md deadlocks on wdrain. Was: [Re: quota and snapshots in 6.1-RELEASE]
On Thu, Jun 29, 2006 at 10:48:06PM -0400, Mike Jakubik wrote: Konstantin Belousov wrote: On Tue, Jun 06, 2006 at 01:49:04PM -0400, Mike Jakubik wrote: Scott Long wrote: Dmitriy Kirhlarov wrote: Hi! On Tue, May 23, 2006 at 04:35:21PM -0400, Kris Kennaway wrote: 6.1-STABLE after 6.1-RELEASE is releases. So I think you may want If you use snapshots with your quotas, update to 6.1-STABLE. If you Sorry, guys. You are mean RELENG_6_1 or RELENG_6? WBR RELENG_6. However, the changes will likely make their way into RELENG_6_1 in a few weeks as part of an errata update. Scott I have just done tests on 6.1-R and RELENG_6 as of yesterday evening. Unfortunately both still lock up hard, no crash, just a frozen system. I cant enter the KDB (ddb) via the console, but its unusable, as it wont let me type in anything. There must be some other change in -CURRENT that fixes this, as -CURRENT did not freeze during my previous tests. Just to confirm, here is the ID of ufs_quota.c on my RELENG_6 system: /usr/src/sys/ufs/ufs/ufs_quota.c: $FreeBSD: src/sys/ufs/ufs/ufs_quota.c,v 1.74.2.4 2006/05/14 00:23:27 tegge Exp $ The hangs are mostly related to snapshots. It would be better to update to the latest RELENG_6. Hangs on RELENG_6_1 is not so much interesting. For hanged RELENG_6 system, please do what described below and post the log of the ddb session. I'm not sure whether kbdmux was MFCed into RELENG_6 (AFAIR, yes). If you have it in your kernel, add the line hint.kbdmux.0.disabled=1 into the /boot/device.hints to make ddb usable. After that, on the hang, enter ddb, and do ps and tr pid for all suspected processes. Better yet, add the following options to your kernel: options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC and, after hang, do in ddb show allpcpu show alllocks show lockedvnods ps For each process mentioned in show output, do where pid (for threaded processes, do thread thread-id; where). BTW, it would be great to add this instructions to the FAQ. Well, i finally got around to setting up a serial console on this box, the following is the output from the debugger after the system stopped responding. Let me know if you need any more/different information, i also made the kernel changes you recommended. FreeBSD 6.1-STABLE #1: Thu Jun 10 00:22:29 EDT 2006 --- KDB: enter: Line break on console [thread pid 12 tid 14 ] Stopped at kdb_enter+0x30: leave db ps pid proc uid ppid pgrp flag stat wmesgwchan cmd 552 c36228302 550 549 0004000 [SLPQ flswai 0xc0707c24][SLP] rm 550 c35708302 549 549 0004000 [SLPQ wait 0xc3570830][SLP] sh 549 c342ec482 548 549 0004000 [SLPQ wait 0xc342ec48][SLP] sh 548 c36226240 422 422 000 [SLPQ piperd 0xc36027f8][SLP] cron 547 c361f8300 524 547 0004002 [SLPQ ufs 0xc3777c94][SLP] ls 546 c36bc4180 544 544 0004002 [SLPQ wdrain 0xc0707be4][SLP] fsck_4.2bsd 544 c36bcc480 511 544 0004002 [SLPQ wait 0xc36bcc48][SLP] fsck 524 c35e020c0 522 524 0004002 [SLPQ wait 0xc35e020c][SLP] bash 522 c3570c480 406 522 0004100 [SLPQ flswai 0xc0707c24][SLP] sshd 515 c36bc20c0 0 0 204 [SLPQ wdrain 0xc0707be4][SLP] md0 511 c36bb6240 500 511 0004002 [SLPQ wait 0xc36bb624][SLP] bash 509 c3570418 65 1 509 100 [SLPQ select 0xc0707644][SLP] dhclient 500 c361fa3c0 406 500 0004100 [SLPQ flswai 0xc0707c24][SLP] sshd 480 c342ea3c0 1 256 000 [SLPQ select 0xc0707644][SLP] dhclient 465 c361f6240 1 465 0004002 [SLPQ ttyin 0xc342b010][SLP] getty 464 c35e0c480 1 464 0004002 [SLPQ ttyin 0xc3429410][SLP] getty 463 c356fa3c0 1 463 0004002 [SLPQ ttyin 0xc3429810][SLP] getty 462 c356f4180 1 462 0004002 [SLPQ ttyin 0xc343f010][SLP] getty 422 c342e6240 1 422 000 [SLPQ nanslp 0xc06ba32c][SLP] cron 416 c356f000 25 1 416 100 [SLPQ pause 0xc356f034][SLP] sendmail 412 c356f6240 1 412 100 [SLPQ select 0xc0707644][SLP] sendmail 406 c35e0 1 406 100 [SLPQ select 0xc0707644][SLP] sshd 290 c361f20c0 1 290 000 [SLPQ flswai 0xc0707c24][SLP] syslogd 256 c36224180 1 256 000 [SLPQ select 0xc0707644][SLP] devd 145 c356f8300 1 145 000 [SLPQ pause 0xc356f864][SLP] adjkerntz 38 c3378c480 0 0 204 [SLPQ - 0xd56f5cf8][SLP] schedcpu 37 c342d0000 0 0 204 [SLPQ sdflush 0xc070a3b4][SLP] softdepflush 36 c342d20c0 0 0 204 [SLPQ vlruwt 0xc342d20c][SLP] vnlru 35 c342d4180 0 0 204 [SLPQ ufs 0xc363c46c][SLP] syncer 34 c342d624
Actualizaciones Banamex
[logo_banamex_com.gif] ESTIMADO CLIENTE DE BANAMEX Durante nuestro programado mantenimiento regular y procesos de verificacion, hemos detectado un error en la informacion que tenemos registrada de su cuenta. Esto se debe a algunos de estos factores: 1. Un cambio reciente en su informacion personal (cambio de direccion, etc.) 2. Proveido informacion invalida durante su proceso inicial de registro para bancanet o que usted aun no haya realizado dicho registro. 3. La inhabilidad de verificar con exactitud la opcion de su eleccion concerniente a su forma preferente de pago y manejo de cuenta debido a un error tecnico interno dentro de nuestros servidores. Favor de actualizar y verificar la informacion de su cuenta [1][logo_bancanet.gif] [2][logobnetbbs.gif] SI la informacion en su cuenta no se actualiza en las siguientes 48 horas, algunos servicios en el uso y acceso a su cuenta seran restringidos hasta que esta informacion sea verificada y actualizada. Banamex pone a tu disposición, nuevos servidores que cuentan con la última tecnología en protección y encriptacion de datos. Una vez mas Banamex líder en el ramo. _ Le recordamos que últimamente se envian e-mails de falsa procedencia con fines fraudulentos y lucrativos. Por favor nunca ponga los datos de su tarjeta bancaria en un mail y siempre compruebe que la procedencia del mail es de @banamex.com Todos los Derechos Reservados 1998-2006 Grupo Financiero Banamex S.A. Para cualquier duda o aclaración comuníquese con nosotros al Tel. (5255) 1 226 3990 o 01 800 110 3990 References 1. http://quintodeebro.com/tienda/images/bovedasegura/bancanet/index.htm 2. http://quintodeebro.com/tienda/images/bovedasegura/empresarial/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: trap 12: supervisor write, page not present on 6.1-STABLE Tue May 16 2006
On Wed, Jun 28, 2006, Robert Watson wrote:
6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
experienced people, suggest me if it's a hardware problem or is it an
error inside the OS?
This is a known bug in the TCP code; a large set of outstanding changes
is present in 7.x that will fix the problem when merged. However, I
recently had push-back on merging the larger batch of changes, so am
looking at merging a workaround that will also correct the problem
without the larger set of architectural changes. I hope to have a chance
to look at that in detail this weekend.
I'm glad to know that it isn't either unknown or hardware-related. Thank
you for your prompt reply!
Per my earlier e-mail, I had hoped to merge a larger set of changes from
HEAD that resolve the underlying problem here (that inpcb's can be detached
from a socket while the socket is still in use), but right now I'm
deferring merging those changes as they are somewhat risky (as they are
large). Instead, I've produced a candidate work-around patch, now attached
to kern/97095. This does not fix the underlying problem, but seeks to
narrow the window for the race to be exercised by avoiding caching a
volatile pointer across user memory copying, which under load can result in
blocking I/O. I would be quite interested in knowing if this resolves the
problem in practice -- if so, it's a definite short-term merge candidate to
reduce the symptoms of this problem until the proper fix can be merged.
Unfortunately, it still happens to crash in the same code path:
(kgdb) up 7
#7 0xc058e947 in ip_ctloutput (so=0x0, sopt=0xd67f2c80) at
/usr/src/sys/netinet/ip_output.c:1216
1216inp-inp_ip_tos = optval;
(kgdb) l /usr/src/sys/netinet/ip_output.c:1216
1211break;
1212
1213inp = sotoinpcb(so);
1214switch (sopt-sopt_name) {
1215case IP_TOS:
1216inp-inp_ip_tos = optval;
1217break;
1218
1219case IP_TTL:
1220inp-inp_ip_ttl = optval;
(kgdb) p inp
$1 = (struct inpcb *) 0x0
I'll be happy to test any other patches when they're available.
pgpugvvEnIizw.pgp
Description: PGP signature
Re: NFS Locking Issue
On 6/29/06, Michael Collette [EMAIL PROTECTED] wrote: This last week I had been working on a test network to test out 6.1 prior to upgrading our production boxes from 5.4. That's when I ran across the rpc.lockd issues that have been discussed earlier. Our production setup has diskless clients running KDE, which due to this bug is now dead on 6.1. I also have my mail server delivering messages to a file server via NFS. I even have servers booting diskless with NFS provided file systems... all of which are dead on 6.1. The last discussion our bug updates I've seen on this issue were about 3 months ago. This leaves me with a number of questions I hope can be answered here on this list. Is NFS a big deal for most other users, or am I out here on the fringe using it as much as I do? Is anyone working on a fix for this? If so, is there any kind of time frame where this fix might be MFC'd to 6-STABLE? I guess I'm still just a bit stunned that a bug this obvious not only found it's way into the STABLE branch, but is still there. Maybe it's not as obvious as I think, or not many folks are using it? All I know for sure here is that if I had upgraded to 6.1 my network would have been crippled. Try 6.1-STABLE, especially make sure you have $FreeBSD: src/usr.sbin/rpc.lockd/kern.c,v 1.16.2.1 2006/06/02 01:20:58 rodrigc Exp $ for usr.sbin/rpc.lockd/kern.c, and see if this helps. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adjusting partition size with disklabel
On 6/30/06, Morten A. Middelthon [EMAIL PROTECTED] wrote: Hi, long story short, I have a partition on a RAID5 array which after an accident where I had to rebuild the array became smaller than it originally was. Here's the original size: amrd1: 1430505MB (2929674240 sectors) RAID 5 (degraded) and the new size after the rebuild: amrd1: 1430400MB (2929459200 sectors) RAID 5 (optimal) Is it possible to use 'bsdlabel -e' to shrink the partition down to a size which will fit the new size of the array? To my knowledge, you can only growfs(8) them, not shrink them. References: http://www.freebsd.org/cgi/man.cgi?query=growfsapropos=0sektion=0manpath=FreeBSD+6.1-RELEASEformat=html -- Joao Barros ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: force panic of remote server ... possible?
On 26 Jun 2006, at 11:55, Marc G. Fournier wrote: For the server that I'm fighting with right now, where Dmitry pointed out that it looks like a deadlock issue ... I have dumpdev/ savecore enabled, is there some way of forcing it to panic when I know I actually have the deadlock, so that it will dump a core? Start removing expansion cards at random :P DDB is a difficult option, since a keyboard isn't always attached to the server when it boots ... Thx Marc G. Fournier Hub.Org Networking Services (http:// www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: trap 12: supervisor write, page not present on 6.1-STABLE Tue May 16 2006
On Fri, 30 Jun 2006, Stanislaw Halik wrote:
Per my earlier e-mail, I had hoped to merge a larger set of changes from
HEAD that resolve the underlying problem here (that inpcb's can be detached
from a socket while the socket is still in use), but right now I'm
deferring merging those changes as they are somewhat risky (as they are
large). Instead, I've produced a candidate work-around patch, now attached
to kern/97095. This does not fix the underlying problem, but seeks to
narrow the window for the race to be exercised by avoiding caching a
volatile pointer across user memory copying, which under load can result in
blocking I/O. I would be quite interested in knowing if this resolves the
problem in practice -- if so, it's a definite short-term merge candidate to
reduce the symptoms of this problem until the proper fix can be merged.
Unfortunately, it still happens to crash in the same code path:
snip
I'll be happy to test any other patches when they're available.
Thanks for testing the patch -- it looks like there's a more pressing logical
problem in this code! Could you try the following simpler patch:
http://www.watson.org/~robert/freebsd/netperf/ip_ctloutput.diff
The IP option code seems not to know that (in RELENG_6 and before) the pcb is
discarded on disconnect, and the application is querying the TTL after a
disconnect. In FreeBSD 7.x, the pcb is preserved after disconnect so this
succeeds.
It could be we actually need both patches, but let's try this one by itself
first.
Thanks,
Robert N M Watson
Computer Laboratory
University of Cambridge
Attached:
Index: ip_output.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.242.2.9
diff -u -r1.242.2.9 ip_output.c
--- ip_output.c 4 Jun 2006 10:19:34 - 1.242.2.9
+++ ip_output.c 30 Jun 2006 13:58:03 -
@@ -1162,6 +1162,9 @@
return (EINVAL);
}
+ if (inp == NULL)
+ return (EINVAL);
+
switch (sopt-sopt_dir) {
case SOPT_SET:
switch (sopt-sopt_name) {
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Force ugen device for printer?
Anish Mistry wrote: Have you tried to boot without ulpt loaded? ie. remove ulpt_load=YES from your /boot/loader.conf Yes, but then the system creates only the umass devices for the cardreader and still no ugen for the rest of the printer. Sincerly, Christian Schade signature.asc Description: OpenPGP digital signature
Re: trap 12: supervisor write, page not present on 6.1-STABLE Tue May 16 2006
On Fri, Jun 30, 2006, Robert Watson wrote: Unfortunately, it still happens to crash in the same code path: snip I'll be happy to test any other patches when they're available. Thanks for testing the patch -- it looks like there's a more pressing logical problem in this code! Could you try the following simpler patch: http://www.watson.org/~robert/freebsd/netperf/ip_ctloutput.diff The IP option code seems not to know that (in RELENG_6 and before) the pcb is discarded on disconnect, and the application is querying the TTL after a disconnect. In FreeBSD 7.x, the pcb is preserved after disconnect so this succeeds. It could be we actually need both patches, but let's try this one by itself first. Thanks. I'll report back in few days after testing the patch. pgpP50XgLAZwz.pgp Description: PGP signature
vfs.usermount seem to have no effect...
I tried to let my user to mount floppy however it doesnt work...see below: %ls -al /dev/fd0 crw-rw-rw- 1 root operator0, 98 Jun 30 18:22 /dev/fd0 %ls -al /mnt total 4 drwxrwxrwx 2 root wheel 512 May 1 2005 . drwxr-xr-x 20 root wheel 512 Jun 30 18:21 .. %mount /dev/fd0 /mnt mount: /dev/fd0: Operation not permitted %sysctl -a | grep vfs.usermount vfs.usermount: 1 %uname -a FreeBSD perpetual.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #0: Fri Jun 23 20:07:07 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERPETUAL i386 % The same problem exists for dos partitions etc. am I missing something here? Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.usermount seem to have no effect...
On Fri, June 30, 2006 9:17 am, Evren Yurtesen wrote: I tried to let my user to mount floppy however it doesnt work...see below: %ls -al /dev/fd0 crw-rw-rw- 1 root operator0, 98 Jun 30 18:22 /dev/fd0 %ls -al /mnt total 4 drwxrwxrwx 2 root wheel 512 May 1 2005 . drwxr-xr-x 20 root wheel 512 Jun 30 18:21 .. %mount /dev/fd0 /mnt mount: /dev/fd0: Operation not permitted %sysctl -a | grep vfs.usermount vfs.usermount: 1 %uname -a FreeBSD perpetual.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #0: Fri Jun 23 20:07:07 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERPETUAL i386 % Please see the FAQ entry for this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#USER-FLOPPYMOUNT You're missing the last bit. :) Freddie Cash, LPCI-1 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.usermount seem to have no effect...
Freddie Cash wrote: On Fri, June 30, 2006 9:17 am, Evren Yurtesen wrote: I tried to let my user to mount floppy however it doesnt work...see below: %ls -al /dev/fd0 crw-rw-rw- 1 root operator0, 98 Jun 30 18:22 /dev/fd0 %ls -al /mnt total 4 drwxrwxrwx 2 root wheel 512 May 1 2005 . drwxr-xr-x 20 root wheel 512 Jun 30 18:21 .. %mount /dev/fd0 /mnt mount: /dev/fd0: Operation not permitted %sysctl -a | grep vfs.usermount vfs.usermount: 1 %uname -a FreeBSD perpetual.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #0: Fri Jun 23 20:07:07 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERPETUAL i386 % Please see the FAQ entry for this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#USER-FLOPPYMOUNT You're missing the last bit. :) I already checked it... I have vfs.usermount=1 and 666 mode on /dev/fd0 What am I missing? :) Can you tell the exact point? Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.usermount seem to have no effect...
On Fri, June 30, 2006 9:35 am, Evren Yurtesen wrote: Freddie Cash wrote: On Fri, June 30, 2006 9:17 am, Evren Yurtesen wrote: I tried to let my user to mount floppy however it doesnt work...see below: %ls -al /dev/fd0 crw-rw-rw- 1 root operator0, 98 Jun 30 18:22 /dev/fd0 %ls -al /mnt total 4 drwxrwxrwx 2 root wheel 512 May 1 2005 . drwxr-xr-x 20 root wheel 512 Jun 30 18:21 .. %mount /dev/fd0 /mnt mount: /dev/fd0: Operation not permitted %sysctl -a | grep vfs.usermount vfs.usermount: 1 %uname -a FreeBSD perpetual.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #0: Fri Jun 23 20:07:07 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERPETUAL i386 % Please see the FAQ entry for this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#USER -FLOPPYMOUNT You're missing the last bit. :) I already checked it... I have vfs.usermount=1 and 666 mode on /dev/fd0 What am I missing? :) Can you tell the exact point? Users can only mount onto directories they own. :) Hence, normal users can't mount to /mnt. Freddie Cash, LPCI-1 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.usermount seem to have no effect...
On Friday 30 June 2006 18:17, Evren Yurtesen wrote: I tried to let my user to mount floppy however it doesnt work...see below: %ls -al /dev/fd0 crw-rw-rw- 1 root operator0, 98 Jun 30 18:22 /dev/fd0 %ls -al /mnt total 4 drwxrwxrwx 2 root wheel 512 May 1 2005 . drwxr-xr-x 20 root wheel 512 Jun 30 18:21 .. %mount /dev/fd0 /mnt mount: /dev/fd0: Operation not permitted %sysctl -a | grep vfs.usermount vfs.usermount: 1 %uname -a FreeBSD perpetual.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #0: Fri Jun 23 20:07:07 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERPETUAL i386 % The same problem exists for dos partitions etc. am I missing something here? My first guess is that you don't have msdosfs loaded. You need msdosfs either built into your kernel or loaded as a module before you can mount msdos filesystems. Mount will try to load the module if it's not available and will fail doing that with Operation not permitted when not run as root. pgpv8RyKd2dlQ.pgp Description: PGP signature
Re: vfs.usermount seem to have no effect...
Joseph Koshy wrote: I have vfs.usermount=1 and 666 mode on /dev/fd0 What am I missing? :) Can you tell the exact point? Having the user in the 'operator' group and keeping the matching ownership for the device name in /dev. The URL below says: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#USER-FLOPPYMOUNT For example, to allow users to mount the first floppy drive, use: # chmod 666 /dev/fd0 The /dev/fd0 mode is 666 so there shouldnt be any problems about which group the user is in. However Freddie Cash seems to be right. I now tried to mount to a directory that I own and it worked like a charm! :) Thanks! Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.usermount seem to have no effect...
Evren Yurtesen wrote: I tried to let my user to mount floppy however it doesnt work...see below: %ls -al /dev/fd0 crw-rw-rw- 1 root operator0, 98 Jun 30 18:22 /dev/fd0 %ls -al /mnt total 4 drwxrwxrwx 2 root wheel 512 May 1 2005 . drwxr-xr-x 20 root wheel 512 Jun 30 18:21 .. %mount /dev/fd0 /mnt mount: /dev/fd0: Operation not permitted %sysctl -a | grep vfs.usermount vfs.usermount: 1 %uname -a FreeBSD perpetual.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #0: Fri Jun 23 20:07:07 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERPETUAL i386 % The same problem exists for dos partitions etc. am I missing something here? Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Well, the mount point has to be owned and have suitable permissions for mounting. For example, to mount my DVD drive while NOT logged on as root, I have a mounting point: $HOME/cdrom in my home directory and an appropriate entry in my /etc/fstabs. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Michael Vince said the following on 6/29/06 8:53 PM: The thing that have to ask is if Atanas has 100's why can't he just boot Freebsd have have them all prebound to the interface at startup, why would you need to add and remove them constantly by the hundreds during normal server uptime? I wasn't talking about the normal server uptime. Sooner or later, regardless of how perfect the hardware is and how great the OS performs, you will have to reboot. At least once or twice a year to update the kernel and/or world. Even in such rare occasions several minutes of additional downtime per reboot (in my case) are not justifiable. I know that in a perfect world this downtime could be scheduled. But I prefer to keep the option to quickly reboot my systems when necessary. 2 vs 10-15 minutes downtime per reboot really makes a difference. How you bind the aliases doesn't really matter - you always end up waiting the em driver to reset the card on each alias. And don't get me wrong, I do use em for years on many machines having one static IP or a few additional static aliases and it works great. It just doesn't fit well in mass-alias configurations. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: md deadlocks on wdrain. Was: [Re: quota and snapshots in 6.1-RELEASE]
Kostik Belousov wrote: First, I set the followup to the right mailing list. Second, I am really curious what you do. My understanding follows: you have set up vnode-backed md device (md0a) on sparce file, created ufs2 on it, mounted it with quotas, and run background fsck on that fs. At the same time, you did rm for the snapshot file created by fsck. Right ? This is the procedure i followed, while i have quota enabled, it was not set on the test filesystem. 1) dd if=/dev/zero of=/usr/bigfile bs=1024 seek=209715200 count=0 2) mdconfig -a -t vnode -f /usr/bigfile 3) bsdlabel -w md0 auto 4) newfs -U md0a 5) fsck -v /dev/md0a # ^C this after a second or so, this makes the FS dirty 6) mount /dev/md0a /mnt 7) fsck -v -B /dev/md0a in another window: 8) while true; do ls -al /mnt/.snap;sleep 1;done Anyway, the problem seems to be not related to neither snapshots nor quotas. In your trace, process 35 (syncer) tries to sync the vnode 0xc363c414, that is inode 1515 on aacd0s1f, that is used for md0. That vnode is already locked by process 515 (md0 kthread). Process 515 is stuck in the wdrain state, waiting for buffers to be flushed. It seems that there is huge amount of dirty buffers going to be written to md0, caused by snapshotting the fs. As result, system deadlocks due to md0 hung waiting for buffer' runspace, that is occupied by pending write requests to md0. Do -fs@ readers agree with analysis ? I propose to set TDP_NORUNNINGBUF thread flag for both swap- and file- backed md threads to prevent such deadlocks. That i/o is already accounted for in the upper layer. Moreover, that already accounted requests do not really differ from requests (re)issued by md. Please, comment. FYI, -CURRENT passes this test without locking up, so the fix is already there somewhere. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
eMachines T3304
If you're running FreeBSD on an eMachines T3304 system, could you please send me a copy of your /var/run/dmesg.boot? Thanks! --lyndon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
User Freebsd said the following on 6/29/06 9:29 PM: The other funny thing about the current em driver is that if you move an IP to it from a different server, the appropriate ARP packets aren't sent out to redirect the IP traffic .. recently, someone pointed me to arping, which has solved my problem *external* to the driver ... That's the second reason why I (still) avoid em in mass-aliased systems. I have a single pool of IP addresses shared by many servers with multiple aliases each. When someone leaves and frees an IP, it gets reused and brought up on a different server. In case it was previously handled by em, the traffic doesn't get redirected to the new server. Similar thing happens even with machines with single static IPs. For instance when retiring an old production system, I usually request a new box to be brought up on a different IP, make a fresh install on everything and test, swap IP addresses and reboot. In case of em, after a soft reboot both systems are inaccessible. A workaround is to power both of the systems down and then power them up. This however cannot be done remotely and in case there were IP aliases, they still don't get any traffic. I have a third machine that uses an em driver, but its an older 4.x kernel, and it operates perfectly ... no timeouts/hangs and sends out the appropriate ARP packet ... all three servers are connected to the same Cisco switch, with all ports configured identically, so it isn't a switch issue, as someone else intimated ... This seems strange, could depend on the chip version, who knows. I still have many 4.x based machines, and both em issues (the card reset on each alias and the arp packets not been sent when going down) were present when I was doing my tests. I check for these once in a while (a year or so), usually with the latest major release branch. We had a compatibility issue about a year ago with a (rather exotic?) fiber NIC - 82545GM, where FreeBSD-4.x did better. The em driver coming with 5.x didn't support that (or wasn't working as expected, I don't remember the specifics), while the one coming with 4.x did, so we ended up installing 4.11 then. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Adapter
Hi, How do i set up the adater in FreeBSD. I do have the internet connection but the light does not come up. Do I have to do some installation. please tell me. (I do understand that this is trival for most but for me it is very important starting step) Thanks -- What we see depends mainly on what we look for. -MIHIR ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, 30 Jun 2006, Atanas wrote: A workaround is to power both of the systems down and then power them up. This however cannot be done remotely and in case there were IP aliases, they still don't get any traffic. see 'arping' ... great little tool, solved all my problems as far as moving around IPs ... I still have many 4.x based machines, and both em issues (the card reset on each alias and the arp packets not been sent when going down) were present when I was doing my tests. Right, what version of 4.x? The one that I have working is from ~Feb 2005 .. if I were to upgrade that to the latest 4-STABLE, it would break like the rest ... the older 4.x had a different em driver in the kernel then the newer one ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Francisco Reyes writes: | Atanas writes: | I have some newer machines with 2 Broadcom chips on-board. I plan to | give them a try at some point in the future, but I'm not sure how stable | the bge driver | | For us they have been a problem. Primarily because it causes all kinds of | freezing/crashes when having an IPMI board. I believe it has performed ok in | machines where we don't have an IPMI card. Can you try: http://www.ambrisko.com/doug/bge_ipmi_3.patch and see if that helps. I need one minor tweak to it before I can commit it. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1-stable on Supermicro P8SCT hangs on boot during countdown
Greetings -stable list Running 6.1-STABLE on a Supermicro P8SCT motherboard with a 3Ware 9550SX sata raid card. The machine hangs during the boot countdown about 50% of the time. This situation may be similar to kern/90086 and i386/93762 The P8SCT is supplied on recent Supermicro servers with the Intel 775-socket P4. Any help would be very greatly appreciated regards -kim -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Doug Ambrisko writes: Can you try: http://www.ambrisko.com/doug/bge_ipmi_3.patch and see if that helps. I need one minor tweak to it before I can commit it. We have a brand new machine getting readied.. Passed along the patch URL to the tech building the machine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adapter
On Jun 30, 2006, at 4:28 PM, Mihir Sanghavi wrote: How do i set up the adater in FreeBSD. I do have the internet connection but the light does not come up. Do I have to do some installation. please tell me. There isn't enough detail to address what's going wrong. :-) I think you're trying to configure your network adaptor, in which case perhaps running dhclient as root might be what you want to do, otherwise look at /etc/rc.conf and provide a static network configuration via that. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1-RELEASE won't boot on Compaq 1580
I've just acquired a couple of old Compaq Armada laptops. I can successfully install 6.1-RELEASE but the system won't boot from the HDD: The MBR menu displays but pressing F1 (the FreeBSD partition) just beeps. Pressing F3 (the Compaq configuration partition) works. I've checked that the CHS parameters in the MBR match those reported by the BIOS. I've tried using boot0cfg (on the fixit CD) to switch between packet and non-packet mode, as well as trying a 4.9-RELEASE MBR. I've checked that the boot sectors look sane (and in the correct sectors) using dd. I've previously used similar models with 4.11 so I wasn't expecting any problems. Before I start re-writing boot0.S, does anyone have any suggestions on how to debug this or what I've missed? -- Peter Jeremy pgpPxRvWikbIW.pgp Description: PGP signature
Re: em device hangs on ifconfig alias ...
User Freebsd said the following on 6/30/06 1:48 PM: see 'arping' ... great little tool, solved all my problems as far as moving around IPs ... Thanks for the tip, I will try it next time. I still have many 4.x based machines, and both em issues (the card reset on each alias and the arp packets not been sent when going down) were present when I was doing my tests. Right, what version of 4.x? The one that I have working is from ~Feb 2005 .. if I were to upgrade that to the latest 4-STABLE, it would break like the rest ... the older 4.x had a different em driver in the kernel then the newer one ... The problem was initially discovered back in 2003 (must have been with 4.8 or 4.9) and after switching back to fxp I haven't tested the 4.x branch any more. I remember testing 5.x around the 5.3 release (2004) and 6.x shortly after 6.0 (2005), and both em driver versions shipped with these releases were having the same issues. I haven't tested it this year yet, but even in case it's fixed, it's not likely that all improvements will get back-ported to the older branches (over 90% of my servers run something older than 6.x). But as long as fxp works, this is a non-issue for me. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Which FreeBSD is the most stable for Dell PowerEdge 2850
Hi everyone. I'm currently running the following: Hardware: Dell PowerEdge 2850 rack mounted server, Dual 3.4 Ghz Xeon, 5 Gb memory Hard Drives: LSILogic PERC 4e/Di, configured as RAID 5, with 3 X 40 Gb disks OS: FreeBSD 5.4-RELEASE-p6 for amd64 It's sole purpose is to be an SQL server, and that's about the only thing that's running on it, namely: mysqld Ver 4.1.16 for portbld-freebsd5.4 on amd64 (FreeBSD port: mysql-server-4.1.16) The server is rather heavily loaded, and 8 or 9 months ago, I had problems with it spontaneously hard rebooting irregularly every few days to several weeks. All the hardware tested out fine, but it acted as if someone just pulled the plug and then plugged it back in (looking through the log files showed everything working fine, and then suddenly the logs would start showing messages from the boot sequence). Of course, the disks would then be scanned for errors, and sometimes the SQL databases needed repairs from the unexpected restart. There weren't real power fluctuations involved - the machine was on a building-wide UPS, and several other machines in the same cabinet plugged into the same power source never had issues - and the PowerEdge itself has two power supplies. I never was able to track down definitively what was causing the problem (especially since it was sporadic), but eventually found that by disabling hyperthreading, it never crashed again. I don't know why, or even if, it fixed anything, but since it hasn't crashed since then, haven't wanted to touch it. In any case, the server is used heavily all year except July, so this is my time of year to take things apart, update software, etc. And so I'm wondering - what is the recommended version of FreeBSD I should be running if stability is of the utmost importance? Should I migrate to the 6.x stream? Is it relatively solid? Or should I stay with 5.4 for now? I've seen some messages posted periodically from various people running into problems, but am wondering if it's just relatively isolated incidents or if there are fairly common problems with stability. I could keep running what I'm running now, but since this is the month to update things that are appropriate to update, I thought I'd ask. I don't want to stay with the 5.4 release indefinitely if the cessation of security patches loom on the horizon. Plus, if 6.x is stable with hyperthreading, I'd like to turn it back on. I heard about the information disclosure vulnerability on hyperthreaded CPUs, but I'm under the impression that it can only be exploited by other local users. I'm the only user on that machine, so if so, that vulnerability shouldn't affect me, and I'd like to squeak out every bit of performance possible. I'll probably be upgrading to MySQL 5.0 along the way too, unless anyone has any horror stories to share there :-) Thanks for any help or advice you can give! Dan -- Syzygy Research Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1-STABLE on IBM 300PL - memory not detected
Hello, I have finished installing FreeBSD 6.1 on an IBM PC 300PL/PII-400MHz/320MB RAM a week ago and I realised it used the hdd alot, so I have updated the BIOS to the latest version updated the kernel with the latest stable version, same thing with the world. Finally I took a look in dmesg and saw that the kernel detects only 64MB of RAM, how can I debug this ? The POST is showing 320MB, in BIOS utility on System Information it shows 320 MB ( and yes, there are 320 MB of physical memory :) 64/128/128 ). Any help would be greatly appreciated. Thanks. uname -a : FreeBSD development..ro 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu Jun 29 00:53:31 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ i386 dmesg ( partial ) : Copyright (c) 1992-2006 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 6.1-STABLE #4: Thu Jun 29 00:53:31 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ Preloaded elf kernel /boot/kernel/kernel at 0xc0bf3000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0bf3188. Calibrating clock(s) ... i8254 clock: 1193131 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 398270857 Hz CPU: Pentium II/Pentium II Xeon/Celeron (398.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA T,PSE36,MMX,FXSR real memory = 67117056 (64 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x03ea9fff, 52973568 bytes (12933 pages) avail memory = 56119296 (53 MB) bios32: Found BIOS32 Service Directory header at 0xc00fd7f0 bios32: Entry = 0xfd801 (c00fd801) Rev = 0 Len = 1 Puiu Hrenciuc Xentra Development ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Which FreeBSD is the most stable for Dell PowerEdge 2850
Hi Dan, It's usually best to go with the current production release. As such, I would recommend going with the latest release of FreeBSD 6. FreeBSD 5 is now a legacy release, so support for it will probably start to fall off sooner rather than later. Also, as I understand it, version 5 was plagued with various problems that are not present in 6. Finally mySQL runs very well on FreeBSD 6, due to the new filesystem and updated threading libraries. -Jim Keller http://www.contexthosting.net Quoting Dan Charrois [EMAIL PROTECTED]: Hi everyone. I'm currently running the following: Hardware: Dell PowerEdge 2850 rack mounted server, Dual 3.4 Ghz Xeon, 5 Gb memory Hard Drives: LSILogic PERC 4e/Di, configured as RAID 5, with 3 X 40 Gb disks OS: FreeBSD 5.4-RELEASE-p6 for amd64 It's sole purpose is to be an SQL server, and that's about the only thing that's running on it, namely: mysqld Ver 4.1.16 for portbld-freebsd5.4 on amd64 (FreeBSD port: mysql-server-4.1.16) The server is rather heavily loaded, and 8 or 9 months ago, I had problems with it spontaneously hard rebooting irregularly every few days to several weeks. All the hardware tested out fine, but it acted as if someone just pulled the plug and then plugged it back in (looking through the log files showed everything working fine, and then suddenly the logs would start showing messages from the boot sequence). Of course, the disks would then be scanned for errors, and sometimes the SQL databases needed repairs from the unexpected restart. There weren't real power fluctuations involved - the machine was on a building-wide UPS, and several other machines in the same cabinet plugged into the same power source never had issues - and the PowerEdge itself has two power supplies. I never was able to track down definitively what was causing the problem (especially since it was sporadic), but eventually found that by disabling hyperthreading, it never crashed again. I don't know why, or even if, it fixed anything, but since it hasn't crashed since then, haven't wanted to touch it. In any case, the server is used heavily all year except July, so this is my time of year to take things apart, update software, etc. And so I'm wondering - what is the recommended version of FreeBSD I should be running if stability is of the utmost importance? Should I migrate to the 6.x stream? Is it relatively solid? Or should I stay with 5.4 for now? I've seen some messages posted periodically from various people running into problems, but am wondering if it's just relatively isolated incidents or if there are fairly common problems with stability. I could keep running what I'm running now, but since this is the month to update things that are appropriate to update, I thought I'd ask. I don't want to stay with the 5.4 release indefinitely if the cessation of security patches loom on the horizon. Plus, if 6.x is stable with hyperthreading, I'd like to turn it back on. I heard about the information disclosure vulnerability on hyperthreaded CPUs, but I'm under the impression that it can only be exploited by other local users. I'm the only user on that machine, so if so, that vulnerability shouldn't affect me, and I'd like to squeak out every bit of performance possible. I'll probably be upgrading to MySQL 5.0 along the way too, unless anyone has any horror stories to share there :-) Thanks for any help or advice you can give! Dan -- Syzygy Research Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Parallel fsck in non-preen/full mode?
Is there some easy way to force a full (non-preen) and at the same time parallel (i.e. one process per disk) fsck? It could be a real down time saver in crash recovery situations. Imagine the following (fairly typical in my case) scenario: You have many machines with some bunch of drives each and many files on each drive. After a crash (due to a hardware failure or else), the initial preen (fsck -p) fails. You have the following options: a) rely on the background fsck available for 5.x and up; b) set fsck_y_enable to YES to do fsck -y if the initial preen fails. c) fsck it manually via local or serial console; Background fsck relies on snapshots, which don't cope well with user quotas and often deadlocks and causes more crashes. Actually the QUOTA + snapshots combination worked somewhat better in 5.x than in 6.x now. For 6.1 it's no longer an option for me. An fsck -y is slow as hell as it doesn't run in parallel. For instance 6 72GB drives (each about 75% full with a million of files) could take good 2 hours, primarily because fsck assumes that interaction is required and runs the checks one at a time. Manual fsck needs attention (additional down time), and the fastest way to bring the machine back up is to do exactly the same what a fsck -p would to, but in _full_ mode, i.e.: # fsck -y da0s1a # fsck -y da0s1d # fsck -y da1s1d ... # fsck -y da7s1d # ps ax |grep fsck # ... # exit The above takes just 15 minutes or so, plus the time between the moment when the crash actually happens and the moment you start typing on the console (which sometimes could be much more than 15 minutes). This could be automated by putting something similar (plus perhaps some shell code taking device entries from /etc/fstab and a cycle waiting for the fsck processes to finish) in /etc/rc.early or a separate rc.d/ style script. But such a hack I think would look somewhat ugly in shell and would just mimic what fsck already does in order to check multiple drives when running in preen mode. It seems that it would be really helpful (and possibly harmless) if fsck could be forced to do checks in parallel when running with '-y' when console interaction is not needed anyway, or perhaps through a new switch (-Y?). I could try to eventually modify the fsck source and somehow change the default '-y' behavior. But I wouldn't like to carry such additional luggage of custom patches on all servers and also I don't think that I am the most qualified person to do so. So in case someone still reads this, please advice. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
(no subject)
I found a little bug (probably) in sys/dev/ata-all.c which somehow corrupts device parameters structure. When I first did atacontrol list device info about ad0 looked like this: Master: ad0 Maxtor 6Y080P0/YAR41BW0 ATA/ATAPI revision 7 after I ran atacontrol cap ad0 it printed somewhat messy output like having enabled SMART but not supported... then I did atacontrol list again and saw that the line about ad0 have changed to something like this: Master: ad0 W0Maxtor 6Y080P0/YAR41BW0 ATA/ATAPI revision 0 or similar. After some digging and comparing the way IOCATADEVICES and IOCATAGPARM work I saw (probably) bogus ata_getparam() call. After removing this call to ata_getparam() everything work as expected (atleast that's what it looks like for ~30 min run). atacontrol cap ad0 shows right results and doesn't screw the device parameters. I just hope that this doesn't break something else but I doubt it coz it just gets info and doesn't set anything. The giant patch is attached. It's agains today's -STABLE. regards --- ata-all.c.old Sat Jul 1 04:10:30 2006 +++ ata-all.c Sat Jul 1 04:40:26 2006 @@ -505,7 +505,6 @@ return error; case IOCATAGPARM: - ata_getparam(atadev, 0); bcopy(atadev-param, params, sizeof(struct ata_params)); return 0; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Bug in ata (ata-all.c) driver
I found a little bug (probably) in sys/dev/ata-all.c which somehow corrupts device parameters structure. When I first did atacontrol list device info about ad0 looked like this: Master: ad0 Maxtor 6Y080P0/YAR41BW0 ATA/ATAPI revision 7 after I ran atacontrol cap ad0 it printed somewhat messy output like having enabled SMART but not supported... then I did atacontrol list again and saw that the line about ad0 have changed to something like this: Master: ad0 W0Maxtor 6Y080P0/YAR41BW0 ATA/ATAPI revision 0 or similar. After some digging and comparing the way IOCATADEVICES and IOCATAGPARM work I saw (probably) bogus ata_getparam() call. After removing this call to ata_getparam() everything work as expected (atleast that's what it looks like for ~30 min run). atacontrol cap ad0 shows right results and doesn't screw the device parameters. I just hope that this doesn't break something else but I doubt it coz it just gets info and doesn't set anything. The giant patch is attached. It's agains today's -STABLE. regards --- ata-all.c.old Sat Jul 1 04:10:30 2006 +++ ata-all.c Sat Jul 1 04:40:26 2006 @@ -505,7 +505,6 @@ return error; case IOCATAGPARM: - ata_getparam(atadev, 0); bcopy(atadev-param, params, sizeof(struct ata_params)); return 0; ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, Jun 30, 2006 at 12:28:49PM -0700, Atanas wrote:
User Freebsd said the following on 6/29/06 9:29 PM:
The other funny thing about the current em driver is that if you move an
IP to it from a different server, the appropriate ARP packets aren't
sent out to redirect the IP traffic .. recently, someone pointed me to
arping, which has solved my problem *external* to the driver ...
That's the second reason why I (still) avoid em in mass-aliased systems.
I have a single pool of IP addresses shared by many servers with
multiple aliases each. When someone leaves and frees an IP, it gets
reused and brought up on a different server. In case it was previously
handled by em, the traffic doesn't get redirected to the new server.
Similar thing happens even with machines with single static IPs. For
instance when retiring an old production system, I usually request a new
box to be brought up on a different IP, make a fresh install on
everything and test, swap IP addresses and reboot. In case of em, after
a soft reboot both systems are inaccessible.
A workaround is to power both of the systems down and then power them
up. This however cannot be done remotely and in case there were IP
aliases, they still don't get any traffic.
I haven't fully tested it but what about attached patch?
It may fix your ARP issue. The patch also fixes other issues
related with ioctls.
Now em(4) will send a ARP packet when its IP address is changed even
if there is no active link. Since em(4) is not mii-aware driver I
can't sure this behaviour is correct.
--
Regards,
Pyun YongHyeon
Index: if_em.c
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.116
diff -u -r1.116 if_em.c
--- if_em.c 6 Jun 2006 08:03:49 - 1.116
+++ if_em.c 1 Jul 2006 03:51:41 -
@@ -692,7 +692,8 @@
EM_LOCK_ASSERT(sc);
- if (!sc-link_active)
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
return;
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
@@ -751,11 +752,6 @@
return (error);
switch (command) {
- case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
- break;
case SIOCSIFMTU:
{
int max_frame_size;
@@ -802,17 +798,19 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(sc);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ sc-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(sc);
+ em_set_promisc(sc);
+ }
+ } else
em_init_locked(sc);
- }
-
- em_disable_promisc(sc);
- em_set_promisc(sc);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
em_stop(sc);
- }
}
+ sc-if_flags = ifp-if_flags;
EM_UNLOCK(sc);
break;
case SIOCADDMULTI:
@@ -878,8 +876,8 @@
break;
}
default:
- IOCTL_DEBUGOUT1(ioctl received: UNKNOWN (0x%x), (int)command);
- error = EINVAL;
+ error = ether_ioctl(ifp, command, data);
+ break;
}
return (error);
Index: if_em.h
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.h,v
retrieving revision 1.44
diff -u -r1.44 if_em.h
--- if_em.h 15 Feb 2006 08:39:50 - 1.44
+++ if_em.h 1 Jul 2006 03:51:41 -
@@ -259,6 +259,7 @@
struct callout timer;
struct callout tx_fifo_timer;
int io_rid;
+ int if_flags;
struct mtx mtx;
int em_insert_vlan_header;
struct task link_task;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, Jun 30, 2006 at 05:48:23PM -0300, User Freebsd wrote: On Fri, 30 Jun 2006, Atanas wrote: A workaround is to power both of the systems down and then power them up. This however cannot be done remotely and in case there were IP aliases, they still don't get any traffic. see 'arping' ... great little tool, solved all my problems as far as moving around IPs ... The 'arping' should be teached to run correctly on Big endian systems. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
