Re: What is a good choice of sata-ii raid controller for freebsd?
hi! I am the original poster of this thread. I have read many interesting reply during these two days. However, as i said in the original message due to certification issues i am pretty limited to INTEL controllers and i have not seen a single relevant reply about them. This is interesting. Nobody uses Intel controllers on FreeBSD or they just suck that much? -- Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fetch hangs on AMD64 RELENG_6
On Wed, Jul 05, 2006 at 04:56:09PM -0400, Charles Swiger wrote: On Jul 5, 2006, at 4:22 PM, Justin T. Gibbs wrote: Hmm. Seems we close the window unexpectedly and the remote side doesn't retransmit when we open it. Yes, interesting that. :-) Normally the stack only sets the window size to 0 in the event of severe congestion, it's used to tell the other side to stop sending traffic for an interval, although the other side should retry with zero-data-length ACK-only packets after a delay, or once your side sends a packet opening the window. FreeBSD's acks stop once the window is fully open... aren't the acks supposed to retried longer? If not, shouldn't fetch eventually see a socket close event instead of hanging forever? RFC-793 says: The sending TCP must be prepared to accept from the user and send at least one octet of new data even if the send window is zero. The sending TCP must regularly retransmit to the receiving TCP even when the window is zero. Two minutes is recommended for the retransmission interval when the window is zero. This retransmission is essential to guarantee that when either TCP has a zero window the re-opening of the window will be reliably reported to the other. When the receiving TCP has a zero window and a segment arrives it must still send an acknowledgment showing its next expected sequence number and current window (zero). The fact that you aren't seeing any ACK's back from this remote server suggests that perhaps a stateful firewall is involved which is getting confused and/or dropping the state entry once it sees the zero-window-size packet from your machine. There may be something wrong on the FreeBSD side as well, of course-- the fact that it grows the window by sending nearly twenty or more ACK packets in the span of about one millisecond without waiting for any ACKs from the other side is pretty wacky in it's own right. Hi, has there been any solution to this problem. I'm seeing this with RELENG_6_2 on an Intel Core2Duo system whilst fetching certain source files for ports, e.g. elinks. Fetch just hangs after the first few kbytes in sbwait state. -- Sascha ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still have BCE driver issues (dell pe 1950) and NFS
Hi, This is still an issue, we are experiencing hangs and loss of connectivity on 6.2-release Dell pe1950 machines without debug.mpsafenet=0. They last about a minute then the machines come alive again. Needless to say this is impossible to tolerate in a production environment. Kind regards, Fredrik Widlund Fredrik Widlund wrote: Hi, Will a fix/this fix be part of the 6.2 Release? We will be relying heavily on fbsd6.2 and pe1950 and are worried about the BCE stability? Kind regards, Fredrik Widlund Scott Long wrote: Olivier Mueller wrote: Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is defined to 0. Then recompile. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is a good choice of sata-ii raid controller for freebsd?
Artem Kuchin wrote: hi! I am the original poster of this thread. I have read many interesting reply during these two days. However, as i said in the original message due to certification issues i am pretty limited to INTEL controllers and i have not seen a single relevant reply about them. This is interesting. Nobody uses Intel controllers on FreeBSD or they just suck that much? If you have enough SATA ports and no need for fancy RAID levels, then my advice is to use gmirror. Hardware RAID1 buys you nothing in perfomance and reliability for a prolonged headache with drivers, bios insanity and monitoring+control tools. -- ./lxnt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: What is a good choice of sata-ii raid controller for freebsd?
Hardware RAID1 buys you nothing in perfomance and reliability for a prolonged headache with drivers, bios insanity and monitoring+control tools. Intel does seem to have a few hardware-based RAID controllers here: http://www.intel.com/products/server/raid/ I don't see any driver or support for them in FreeBSD though. Jaime Bozza Qlinks Media Group ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
BTX halted with MegaRaid SCSI 320-2 on 6.2R help
6.2R cd boot failed with follow error,and the MegaRAID fw version is FW_1L33 thanks with any info BTX loader 1.00 BTX version 1.01 Console: internal video/keyboard BIOS CD is cd0 BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/3668928kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root at [EMAIL PROTECTED], Fri Jan 12 06:40:38 UTC 2007) int=000d err= efl=00030086 eip=c3d4 eax=8058 ebx=2000 ecx=0007 edx=fffa esi=f69b edi=00040170 epb=03d8 esp=0358 cs=f000 ds=0040 es=5d18fs=9fc0 gs=f000 ss=9e17 cs:eip=ec 50 e4 61 58 50 e4 61-58 ee 5a c3 01 00 e4 c3 12 00 00 41 d0 0c 02 08-80 00 03 00 79 00 79 00 00 ss:esp=77 01 03 2c a1 00 08 2c-fa 02 00 e0 00 00 c0 9f 00 00 4e 80 f3 ee 00 f0-03 24 00 e0 06 02 00 80 BTX halted This message was sent using IMP, the Internet Messaging Program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is a good choice of sata-ii raid controller for freebsd?
Jaime Bozza wrote: Hardware RAID1 buys you nothing in perfomance and reliability for a prolonged headache with drivers, bios insanity and monitoring+control tools. Intel does seem to have a few hardware-based RAID controllers here: http://www.intel.com/products/server/raid/ I don't see any driver or support for them in FreeBSD though. Those are rebranded LSI Megaraid units, amr(4). They have mostly-unusable GUI bios (you actually have to have a mouse plugged in to do anything with it), no up-to-date FreeBSD control utility, though some reverse-engineering work resulted in a simple monitoring utility. They work ok (SCSI ones at least), but configuration and maintenance leave much to be desired. -- ./lxnt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is a good choice of sata-ii raid controller for freebsd?
- Original Message - From: Artem Kuchin [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Friday, February 09, 2007 5:15 PM Subject: Re: What is a good choice of sata-ii raid controller for freebsd? Alexander Sabourenkov wrote: Artem Kuchin wrote: hi! I am the original poster of this thread. I have read many interesting reply during these two days. However, as i said in the original message due to certification issues i am pretty limited to INTEL controllers and i have not seen a single relevant reply about them. This is interesting. Nobody uses Intel controllers on FreeBSD or they just suck that much? If you have enough SATA ports and no need for fancy RAID levels, then my advice is to use gmirror. Hardware RAID1 buys you nothing in perfomance and reliability for a prolonged headache with drivers, bios insanity and monitoring+control tools. Hm... two points here. I, somehow, do not really believe that software raid (gmirror for example) is as reliable as hardware. I, deeply inside, believe that i might screw things very badly under some heavy load and bad timing conditions. Can't explain it. it is religious i guess, but i can be very wrong about this. However, two perfomance point: Under gmirror OS must issue two commands to write to disks and some commands to check/set mark that mirrored data is intact. Under hardware RAID OS issue sonly one command to write and no checking command, since raid controller handles this async. So, software OS raid must be slower than controller based raid anyway. Am i right here? Any benchmark data on this? As for reliability of gmirror. I just need to know how it works to see for myself that if power turned off in some racing condition gmirror will know that disk are out of sync. If it is done than gmirror must check sync of disks every read, and that mean two command for reading too, which must slow down things. Is it true? -- Artem I set up 3 RedHat Enterprise servers in a cluster for a customer 2-3 years ago. Dual P4-XEON 3.4GHz with 16G of ram each. Really lovely servers. Intel server motherboards with 2 x15k RPM SCSI drives as a mirror for the OS and fibrechannel external storage for Oracle 10i. The SCSI RAID on the motherboard was horrifically slow. I'm talking around 5MB/s hardware raid for 15k RPM SCSI drives. Turns out it was a known bug on the Intel motherboards with no workaround or fix so I set the boxes up with Linux software raid. The performance was excellent and they are still running perfectly today. I think the SCSI controller was Symbios or something like that. Ever since then I have not trusted Intel and RAID in the same sentence. I was really upset that they were not interested in fixing the issue. I even emailed Intel to ask them about it and they said there was not much likelihood of a fix. Call me biased but that's just what my experience has taught me. Btw the Areca cards have Intel RISC CPU's on them and they are lightning fast. -Clay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX halted with MegaRaid SCSI 320-2 on 6.2R help
Hi, This isn't the answer, but I'm attempting to provide triage for jhb who will probably look at it. This is a GPF, but it's not being caused by an attempt to enter protected mode, so it isn't the most-often reported BTX issue. [EMAIL PROTECTED] wrote: 6.2R cd boot failed with follow error,and the MegaRAID fw version is FW_1L33 thanks with any info BTX loader 1.00 BTX version 1.01 Console: internal video/keyboard BIOS CD is cd0 BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/3668928kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root at [EMAIL PROTECTED], Fri Jan 12 06:40:38 UTC 2007) int=000d err= efl=00030086 eip=c3d4 eax=8058 ebx=2000 ecx=0007 edx=fffa esi=f69b edi=00040170 epb=03d8 esp=0358 cs=f000 ds=0040 es=5d18fs=9fc0 gs=f000 ss=9e17 cs:eip=ec 50 e4 61 58 50 e4 61-58 ee 5a c3 01 00 e4 c3 12 00 00 41 d0 0c 02 08-80 00 03 00 79 00 79 00 00 ss:esp=77 01 03 2c a1 00 08 2c-fa 02 00 e0 00 00 c0 9f 00 00 4e 80 f3 ee 00 f0-03 24 00 e0 06 02 00 80 BTX halted It looks like BIOS code at f000:c3d4 is trying to read a word from I/O port 0xfffa, and this is causing a GPF when it tries to write to what looks like the BIOS data area at 0040:0058; cursor position for video page 4. 0: ec in (%dx),%al 1: 50 push %eax 2: e4 61 in $0x61,%al 4: 58 pop%eax 5: 50 push %eax 6: e4 61 in $0x61,%al 8: 58 pop%eax 9: ee out%al,(%dx) a: 5a pop%edx b: c3 ret c: 01 00 add%eax,(%eax) e: e4 c3 in $0xc3,%al 10: 12 00 adc(%eax),%al 12: 00 41 d0add%al,0xffd0(%ecx) 15: 0c 02 or $0x2,%al 17: 08 80 00 03 00 79 or %al,0x79000300(%eax) 1d: 00 79 00add%bh,0x0(%ecx) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX halted with MegaRaid SCSI 320-2 on 6.2R help
Bruce M. Simpson wrote: Hi, This isn't the answer, but I'm attempting to provide triage for jhb who will probably look at it. This is a GPF, but it's not being caused by an attempt to enter protected mode, so it isn't the most-often reported BTX issue. [EMAIL PROTECTED] wrote: 6.2R cd boot failed with follow error,and the MegaRAID fw version is FW_1L33 thanks with any info BTX loader 1.00 BTX version 1.01 Console: internal video/keyboard BIOS CD is cd0 BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/3668928kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root at [EMAIL PROTECTED], Fri Jan 12 06:40:38 UTC 2007) int=000d err= efl=00030086 eip=c3d4 eax=8058 ebx=2000 ecx=0007 edx=fffa esi=f69b edi=00040170 epb=03d8 esp=0358 cs=f000 ds=0040 es=5d18fs=9fc0 gs=f000 ss=9e17 cs:eip=ec 50 e4 61 58 50 e4 61-58 ee 5a c3 01 00 e4 c3 12 00 00 41 d0 0c 02 08-80 00 03 00 79 00 79 00 00 ss:esp=77 01 03 2c a1 00 08 2c-fa 02 00 e0 00 00 c0 9f 00 00 4e 80 f3 ee 00 f0-03 24 00 e0 06 02 00 80 BTX halted It looks like BIOS code at f000:c3d4 is trying to read a word from I/O port 0xfffa, and this is causing a GPF when it tries to write to what looks like the BIOS data area at 0040:0058; cursor position for video page 4. 0: ec in (%dx),%al 1: 50 push %eax 2: e4 61 in $0x61,%al 4: 58 pop%eax 5: 50 push %eax 6: e4 61 in $0x61,%al 8: 58 pop%eax ^^^ The stack operations sound mad to me :-) I think these is probably not what we expect... 9: ee out%al,(%dx) a: 5a pop%edx b: c3 ret c: 01 00 add%eax,(%eax) e: e4 c3 in $0xc3,%al 10: 12 00 adc(%eax),%al 12: 00 41 d0add%al,0xffd0(%ecx) 15: 0c 02 or $0x2,%al 17: 08 80 00 03 00 79 or %al,0x79000300(%eax) 1d: 00 79 00add%bh,0x0(%ecx) Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: What is a good choice of sata-ii raid controller for freebsd?
On Friday 09 February 2007 09:15, Artem Kuchin wrote: Alexander Sabourenkov wrote: Artem Kuchin wrote: hi! I am the original poster of this thread. I have read many interesting reply during these two days. However, as i said in the original message due to certification issues i am pretty limited to INTEL controllers and i have not seen a single relevant reply about them. This is interesting. Nobody uses Intel controllers on FreeBSD or they just suck that much? If you have enough SATA ports and no need for fancy RAID levels, then my advice is to use gmirror. Hardware RAID1 buys you nothing in perfomance and reliability for a prolonged headache with drivers, bios insanity and monitoring+control tools. Hm... two points here. I, somehow, do not really believe that software raid (gmirror for example) is as reliable as hardware. I, deeply inside, believe that i might screw things very badly under some heavy load and bad timing conditions. Can't explain it. it is religious i guess, but i can be very wrong about this. However, two perfomance point: Under gmirror OS must issue two commands to write to disks and some commands to check/set mark that mirrored data is intact. Under hardware RAID OS issue sonly one command to write and no checking command, since raid controller handles this async. So, software OS raid must be slower than controller based raid anyway. Am i right here? Any benchmark data on this? As for reliability of gmirror. I just need to know how it works to see for myself that if power turned off in some racing condition gmirror will know that disk are out of sync. If it is done than gmirror must check sync of disks every read, and that mean two command for reading too, which must slow down things. Is it true? -- Artem What hardware RAID buys you over gmirror is that you can boot from it. If a drive in the mirror fails the device name available to the OS is still the same. The FreeBSD loader does not do gmirror, it boots off the raw device, and then gmirror is loaded. If the drive you are booting off of fails you have to have the BIOS set to boot from the other drive in the mirror, and then you run into 'what is the root device set to in loader.conf' issues. From a raw speed perspective on an unloaded CPU a 3.0ghz processor is probably just as fast or faster than the embedded processor on a RAID card running at a few hundred mhz. Sure, once you start talking about CPUs at full load there are advantages to off-loading stuff to a dedicated processor. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.2 amd64 hang, continued
I will not claim to have any kernel locking foo, however it seems odd to me that this machine has lots of processes waiting on allproc but show alllocks doesn't show any process having the allproc lock. Is this correct? db show alllocks Process 89731 (perform_ca) thread 0xff0128c9fbe0 (100232) exclusive sx proctree r = 0 (0x8070dde0) locked @ kern/kern_exit.c:602 Process 85077 (ph_ thread 0xff012e83bbe0 (100182) exclusive sleep mutex process lock r = 0 (0xff01205c1418) locked @kern/subr_trap.c:88 Process 85077 (ph) thread 0xff01142e (100133) exclusive sleep mutex so_rcv r = 0 (0xff0126948338) locked @ kern/uipc_socket.c:2037 exclusive sleep mutex so_snd r = 0 (0xff0126948408) locked @ kern/uipc_socket.c:2036 Process 837 (sendmail) thread 0xff012efa3260 (100035) exclusive sx sysctl lock r = 0 (0x8070e580) locked @ kern/kern_sysctl.c:1375 db show sleepchain 843 thread 100055 (pid 843, sendmail) blocked on sx sysctl lock XLOCK thread 100035 (pid 837, sendmail) blocked on lk allproc EXCL (count 0) db where 89792 Tracing pid 89792 tid 100199 td 0xff01251a24c0 sched_switch() at sched_switch+0x13a mi_switch() at mi_switch+0x1d2 critical_exit() at critical_exit+0xb0 spinlock_exit() at spinlock_exit+0x17 turnstile_unpend() at turnstile_unpend+0x249 vmspace_exit() at vmspace_exit+0x9a exit1() at exit1+0x38f sys_exit() at sys_exit+0xe syscall() at syscall+0x4d1 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (1, FreeBSD ELF64, sys_exit), rip = 0x48b46c, rsp = 0x7fffeae8, rbp = 0x5fa000 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Desired behaviour of ifconfig -alias
I recently ran into a bug in the jail startup scripts that caused this command to be executed: ifconfig bce0 -alias It turns out that this command eliminated the primary IP for the device. man ifconfig defines the behavior of -alias to be: -alias Remove the network address specified. This would be used if you incorrectly specified an alias, or it was no longer needed. If you have incorrectly set an NS address having the side effect of specifying the host portion, removing all NS addresses will allow you to respecify the host portion. I can't help but wonder if it would be better behavior to throw an error when no argument is supplied. The only discussion I found of this in a quick search of the archives was a post in 2004 which noted that the fxp driver actually deletes all IP addresses, but there was no significant follow-up. Should ifconfig throw an error if no address is supplied? -Kevin Way ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pppd crashes, was: kde-freebsd
Peter Jeremy wrote: On 2007-Feb-08 17:16:23 -0500, John Walthall [EMAIL PROTECTED] wrote: functionally obsolete. User PPP provides better service, and several tangible design benefits. User PPP is very easy to use, Kernel PPP is not. Actually, kernel PPP has one significant (at least theoretical) advantage over user ppp: Network data is not pushed through the kernel/userland interface an additional two times. This is irrelevant for low-speed modem interfaces but could be significant for PPPoE on high-speed broadband. Keep in mind that a firewall host is likely to be a slow box - either a pensioned-off desktop or a mini-ITX style system. FreeBSD is NOT Linux, and SHOULD NOT attempt to model it. FreeBSD is BSD UNIX! Isn't that the WHOLE POINT (pardon my shouting) for our existence? I'm not sure I see where Linux comes into this. Looking back into history, it seems that both ppp(4) and ppp(8) arrived fairly close together. It appears that ppp(4) was a port of the portable ppp-2.2 code - the same code as used in SunOS AFAIR. Yes, indeed. I admit I had not thought of that. I was writing from MY personal perspective, With my nice modern machine and my privileged state of not having broadband access (wink, wink). This is a rant, er editorial; I am writing as it seems to *me*. Conceded: this is not true for *everyone*. As to where Linux comes in. It appears to me that PPP is the more normal way on FreeBSD, whereas, in my own experience Linux, (or at least, the distributions I formerly used) prefer PPPD. Therefore when KDE wrote KPPP, (and they originally wrote it more-or-less for Linux.) They used PPPD. There is nothing theoretically invalid about PPPD. It's just not quite how we do things *most of the time*. Over time FreeBSD and Linux drifted apart on this design issue, and it became something of a characteristic of BSD, perhaps that is why Kernel PPP became less well maintained I should *not* have said Did a clumsy job. I probably should have said, Did a less than perfect job. I guess it's kind of like trying to make a bread recipe with rice flour instead of wheat flour. I retract this phrase. Regarding the various comments by Michael Nottebrock, Firstly: The bug you mentioned I have not experienced. I never had problems when killing the X-server. I cannot comment on that. I do not often kill my X-Server; perhaps I just didn't do it frequently enough. If you believe that this speech is a rant, you are somewhat correct. I am rather cross and it does show. However I differ with your estimation that it is undignified. Oh, Please! With all due respect you take things entirely too seriously. I am obviously being over-the-sarcastic. If you feel that you should not dignify this rant by replying to it, but, then don't! No buts! If you really think it is a rant. Ignore it! That's the mature thing to do! As for your opinion that I should close the bug. I will not. An unwise design decision has caused this problem. Because of known problems with PPPD, KPPP should provide at least the option of using user land PPP. You may of course differ from this view. However, unless a large outcry arises, I will not close the bug. I think that it is, in-fact a bug. Bugs are sometimes a bit subjective. The KPPP Developers can always ignore me. -- Unless instructed to do otherwise, Please address mail to [EMAIL PROTECTED] and not to this address. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Desired behaviour of ifconfig -alias
On Fri, Feb 09, 2007 at 04:06:56PM -0500, Kevin Way wrote: I recently ran into a bug in the jail startup scripts that caused this command to be executed: ifconfig bce0 -alias It turns out that this command eliminated the primary IP for the device. man ifconfig defines the behavior of -alias to be: -alias Remove the network address specified. This would be used if you incorrectly specified an alias, or it was no longer needed. If you have incorrectly set an NS address having the side effect of specifying the host portion, removing all NS addresses will allow you to respecify the host portion. I can't help but wonder if it would be better behavior to throw an error when no argument is supplied. The only discussion I found of this in a quick search of the archives was a post in 2004 which noted that the fxp driver actually deletes all IP addresses, but there was no significant follow-up. Should ifconfig throw an error if no address is supplied? My vote is for either 1) an error, or 2) delete all of the aliases associated with that interface. If I had a preference, I'd choose #1. I'd argue that -alias doing what you described (removing the non-aliased IP bound to the iface) when no inet/inet6 arguments are suppied is indeed a bug. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Desired behaviour of ifconfig -alias
On Fri, Feb 09, 2007 at 01:49:08PM -0800, Jeremy Chadwick wrote: On Fri, Feb 09, 2007 at 04:06:56PM -0500, Kevin Way wrote: I recently ran into a bug in the jail startup scripts that caused this command to be executed: ifconfig bce0 -alias It turns out that this command eliminated the primary IP for the device. man ifconfig defines the behavior of -alias to be: -alias Remove the network address specified. This would be used if you incorrectly specified an alias, or it was no longer needed. If you have incorrectly set an NS address having the side effect of specifying the host portion, removing all NS addresses will allow you to respecify the host portion. I can't help but wonder if it would be better behavior to throw an error when no argument is supplied. The only discussion I found of this in a quick search of the archives was a post in 2004 which noted that the fxp driver actually deletes all IP addresses, but there was no significant follow-up. Should ifconfig throw an error if no address is supplied? My vote is for either 1) an error, or 2) delete all of the aliases associated with that interface. If I had a preference, I'd choose #1. I'd argue that -alias doing what you described (removing the non-aliased IP bound to the iface) when no inet/inet6 arguments are suppied is indeed a bug. It's way to late to make this change. This is known behavior and has been for ages. If there's a bug it's in the documentation. -- Brooks pgpJSwTuBuQil.pgp Description: PGP signature
Re: dd as an imaging solution.
Sean Bryant wrote this message on Fri, Feb 09, 2007 at 14:07 -0500: John-Mark Gurney wrote: Antony Mawer wrote this message on Tue, Feb 06, 2007 at 17:04 +1100: On 6/02/2007 1:47 PM, Sean Bryant wrote: Dominic Marks wrote: Check out G4U (NetBSD based) The only problem I can see here is that multiple parallel reads will have serious performance impacts, thus greatly increasing the cloning of the disk. The solution with dd, tee and netcat would just daisy chain the copy across the network which would be way faster. Now all you need is G4U to operate in a multicast manner like Symantec Ghost Corporate Edition, and your transfer speed wouldn't reduce with each additional client (eg. 100mbps for 1 client, 50mbps each for 2 clients, 33.3mbps each for 3 clients, ...) Add FEC to the multicast, and you can constantly stream the data, and not have to worry about dropped segments as much... Can you explain this? FEC stands for Forward Error Correction... Check out: http://info.iet.unipi.it/~luigi/fec.html for some work that Luigi has done wrt FEC. I've even embedded his FEC library in the kernel w/o too much difficulty... Wikipedia also has an article on it... So the idea is that you multicast out the data broken up into x packets.. In addition to x packets, you also transmit y parity packets... As long as the end system receives any combination of x and y packets where the total unique packet count is x, you are able to reconstruct the data... You choose y based upon your expected packet drop rate.. This has the advantage that when you are transmitting the data, and a machine fails to receive a packet, you don't have to a) retrainsmit the packet, or b) wait till the same data packet comes along... Because you can replace the missed data packet w/ one of the parity packets to reconstruct the data... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
Bruce A. Mah wrote: I've convinced myself that this problem needs to be tested in isolation (i.e. you have complete control over both ends of the tunnel) because incoming packets over the tunnel cause the host route to get added automatically if it wasn't there already. After reading the code and discussing this with a couple folks, I've managed to convince myself that 1.48.2.14 and 1.48.2.15 (and their analogues on HEAD) need to go away. I've committed diffs that back these out, and they solve the problem for me in my testing (which I've done with two VMs in isolation). The applicable revisions for nd6.c are 1.74 (HEAD) and 1.48.2.18 (RELENG_6). Updating up to (or beyond) these revisions should clear up the problem. Confirmed. I've updated the machine on which I originally had this problem to -STABLE as of today, and the problem has disappeared. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Desired behaviour of ifconfig -alias
On Friday 09 February 2007 20:29, Brooks Davis wrote: On Fri, Feb 09, 2007 at 01:49:08PM -0800, Jeremy Chadwick wrote: On Fri, Feb 09, 2007 at 04:06:56PM -0500, Kevin Way wrote: I recently ran into a bug in the jail startup scripts that caused this command to be executed: ifconfig bce0 -alias It turns out that this command eliminated the primary IP for the device. It's way to late to make this change. This is known behavior and has been for ages. If there's a bug it's in the documentation. wellwell, we also were apes for ages but does not mean that we stay behaving like them and if some still does so it is also never to late to change that ;) ifconfig nic -alias is obviously a wired and confusing behaviour and should firstable do what it says, remove an alias and not the first IP address even if it can be seen as an alias too. Logic would exist when ifconfig nic -alias removes all aliases (or perhaps first of them) but not one by one starting with the first ip. Then when there is no other alias left it should better ask if removing the Ip address is really desired since it is essential to have one. rmuser and other utilities also ask such kind of questions for less reason. then already beeing here there is more, ifconfig nic alias does not return anything at all and ifconfig nic -alias on a nic w/o ip returns can't assign requested address ... -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is a good choice of sata-ii raid controller for freebsd?
Josh Paetzel wrote: What hardware RAID buys you over gmirror is that you can boot from it. [snip] From a raw speed perspective on an unloaded CPU a 3.0ghz processor is probably just as fast or faster than the embedded processor on a RAID card running at a few hundred mhz. Sure, once you start talking about CPUs at full load there are advantages to off-loading stuff to a dedicated processor. What hardware RAID buys me over gmirror is that SATA2 NCQ actually works on recent hardware RAID cards, and doesn't on gmirror -- at least according to the ata(4) manpage on 6.2-RELEASE. Depending on your specific application, that could have a performance impact, no? -- Mike Andrews * [EMAIL PROTECTED] * http://www.bit0.com It's not news, it's Fark.com. Carpe cavy! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pppd crashes, was: kde-freebsd
On Friday, 9. February 2007 22:48, John Walthall wrote: Because of known problems with PPPD, KPPP should provide at least the option of using user land PPP. You may of course differ from this view. However, unless a large outcry arises, I will not close the bug. I think that it is, in-fact a bug. Bugs are sometimes a bit subjective. The KPPP Developers can always ignore me. No, bugs are not 'a bit subjective'. With just a little actual analysis and straight thinking it is very easy to determine what is a bug and where the bug is. The fact that KPPP does not support ppp(8) is not a bug, it is a missing feature. If you want to request a feature, you open a wish, not a bug, you word it nicely and preferably attach some code that implements that feature, because this is how community-driven open source development works. Did it ever cross your mind that the KPPP developer(s) might not even use FreeBSD? The fact that machines panic or freeze when KPPP is used is not a bug in KPPP either, because KPPP is nothing but a front-end to the software that causes the problem. By principle, a kernel panic or freeze is never an application's fault, because the kernel should never panic and never freeze, no matter what an application does. Therefore, the bug report needs to go into FreeBSD's bugtracker (someone else already filed one, see my previous mails for the URL), not KDE's. All that your bug report accomplishes is broadcasting your bad and uninformed attitude to an even bigger audience. It is in your own and the FreeBSD community's best interest to backtrack before anyone gets to form a negative opinion on both. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp7bVJV0CANM.pgp Description: PGP signature
Re: Desired behaviour of ifconfig -alias
Brooks Davis wrote: On Fri, Feb 09, 2007 at 01:49:08PM -0800, Jeremy Chadwick wrote: On Fri, Feb 09, 2007 at 04:06:56PM -0500, Kevin Way wrote: I recently ran into a bug in the jail startup scripts that caused this command to be executed: ifconfig bce0 -alias It turns out that this command eliminated the primary IP for the device. It's way to late to make this change. This is known behavior and has been for ages. If there's a bug it's in the documentation. -- Brooks I'm as much of a change-hating curmudgeon as the next guy, but if anybody is relying on ifconfig iface -alias 's undefined behavior, then they deserve the pain that will come with a fix. As it stands the behavior appears to vary between drivers (archive search shows that on fxp it blows away all IPs, while on bce it blows away the primary IP, leaving all aliases intact.) Am I missing a reason that this could ever be desirable? If it was consistent, I could see an argument for documentation. But as it stands, the only thing to document would be that the behavior varies between drivers, and a fix has been declined on the basis of momentum. At a minimum can this get normalized in -HEAD? --Kevin Way ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Desired behaviour of ifconfig -alias
On Fri, Feb 09, 2007 at 09:13:22PM -0500, Kevin Way wrote: I'm as much of a change-hating curmudgeon as the next guy, but if anybody is relying on ifconfig iface -alias 's undefined behavior, then they deserve the pain that will come with a fix. As it stands the behavior appears to vary between drivers (archive search shows that on fxp it blows away all IPs, while on bce it blows away the primary IP, leaving all aliases intact.) Upon looking at the code, I can see exactly where this (read: -alias without any arguments) can be addressed, and it's not in the NIC drivers. Tracing through src/sbin/ifconfig/ifconfig.c in RELENG_6: main() iterates through argv, calling cmd_lookup() on each argument passed. cmd_lookup() does a strcmp() comparison against the argument passed and what's in each struct entry pointed to by pointer cmds. cmds is populated via the constructor ifconfig_ctor(), taking its data from a struct table called basic_cmds. Entries in basic_cmds use macros named DEF_CMD(), DEF_CMD_ARG(), and DEF_CMD_ARG2(), which define the number of arguments required. Thus, it seems to me that either the struct of basic_cmds needs to be changed to address things differently (argv parsers are fun!), or one could simply move -alias to require inet or inet6 (or whatever other things you might want to match on). It seems to me that this oversight was addressed when adding 802.1 support to ifconfig -- thus creating ifieee80211.c, which has pre-requisite counts and things for some of the arguments. Thus, what I'm saying is this: the change should be doable, and the argument for keeping this brokenness fails miserably (sorry Brooks, I don't want you to feel like I'm raining on your parade, but your argument doesn't jive with me.) Am I missing a reason that this could ever be desirable? If it was consistent, I could see an argument for documentation. But as it stands, the only thing to document would be that the behavior varies between drivers, and a fix has been declined on the basis of momentum. I can't see why this would be desirable either. I don't want ifconfig to go the route of Linux's ipfwadm -- ipchains -- iptables (anyone familiar with that migration should understand my comparison), but we're talking about an oversight of the syntax parser here. Additionally, if each driver (fxp vs. bge vs. nve) all behave differently on -alias, that's also odd. I bet that one can be explained, though. At a minimum can this get normalized in -HEAD? I would like to see this addressed in -HEAD and backported to RELENG_6, because this isn't an ifconfig syntax change, it's addressing a decent oversight in what expected arguments are for certain commands. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Desired behaviour of ifconfig -alias
On Fri, 9 Feb 2007, Jeremy Chadwick wrote: On Fri, Feb 09, 2007 at 09:13:22PM -0500, Kevin Way wrote: I'm as much of a change-hating curmudgeon as the next guy, but if anybody is relying on ifconfig iface -alias 's undefined behavior, then they deserve the pain that will come with a fix. As it stands the behavior appears to vary between drivers (archive search shows that on fxp it blows away all IPs, while on bce it blows away the primary IP, leaving all aliases intact.) Upon looking at the code, I can see exactly where this (read: -alias without any arguments) can be addressed, and it's not in the NIC drivers. Tracing through src/sbin/ifconfig/ifconfig.c in RELENG_6: main() iterates through argv, calling cmd_lookup() on each argument passed. cmd_lookup() does a strcmp() comparison against the argument passed and what's in each struct entry pointed to by pointer cmds. cmds is populated via the constructor ifconfig_ctor(), taking its data from a struct table called basic_cmds. Entries in basic_cmds use macros named DEF_CMD(), DEF_CMD_ARG(), and DEF_CMD_ARG2(), which define the number of arguments required. Thus, it seems to me that either the struct of basic_cmds needs to be changed to address things differently (argv parsers are fun!), or one could simply move -alias to require inet or inet6 (or whatever other things you might want to match on). This is way out of my league, but: -alias Remove the network address specified. This would be used if you incorrectly specified an alias, or it was no longer needed. If you have incorrectly set an NS address having the side effect of specifying the host portion, removing all NS addresses will allow you to respecify the host portion. Does not 'remove the network address specified' imply that this should fail if a) there is no network address specified or b) the address that is specified is not an existing alias address for the interface? Secondly, pardon my ignorance, but what does 'NS' refer to here? That string / term occurs nowhere else in ifconfig(8). Perhaps I'm missing a valid (and used) usage of -alias with no address? [..] Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pppd crashes, was: kde-freebsd] Question about KPPP on FreeBSD
On Thu, 8 Feb 2007, Michael Nottebrock wrote: On Thursday, 8. February 2007 08:38, Ian Smith wrote: On Wed, 7 Feb 2007, Michael Nottebrock wrote: On Wednesday, 7. February 2007 18:45, Joe Vender wrote: On Wednesday 07 February 2007 01:59, Michael Nottebrock wrote: ... There is https://bugs.kde.org/show_bug.cgi?id=55785 on record, your description sounds more like you're getting a kernel panic in the background though (KPPP is a frontend for pppd and the in-kernel ppp driver). If I want to use KPPP in FreeBSD, do I need to first manually edit any config files for pppd, and if so, please elaborate, or does creating the settings in the Configure sections of KPPP take care of everything needed? I found this bug report which sounds just like the problem I'm having with FreeBSD and KPPP. http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/98154 I agree, that sounds similar. I've changed the CC to stable@, since that is a better place for pppd/kernel ppp related issues. Is there any intention to address it? I call on the community (especially those with modems) to take it on. To that end, I've left your motivational speech below intact for everyone's benefit. Perhaps we should rather be calling upon the KDE developer community to provide such a frontend interface to configure and invoke FreeBSD's ppp, for those who find a little manual configuration, as you describe below, beyond them? You mean the FreeBSD-using KDE developer community, which is neither very big nor very prolific. I am convinced that remaining compatible with common Linux solutions will always be the better strategy as far as the desktop is concerned. Well perhaps there's a pppd hacker who shares your conviction out there somewhere? As Kris emphasised, pppd's fallen into disrepair because nobody cares for it, whereas I've watched ongoing quality work on and support of ppp over the last 9 years by very cluey FreeBSD developers. I made my own choice back then, and have long omitted ppp from kernels as a waste of space, and have very rarely even seen pppd mentioned. KPPP doesn't fail here, but finding no ppp interface, has nothing to do. Since once trying (and failing) to debug or even comprehend a spaghetti of scripts and configs behind a dialout-only linux pppd setup some years ago, compared to the much more straightforward ppp with mgetty setup for both dialout and some dialin modem lines I'd built pretty much from the FreeBSD Handbook even at 2.2.6 with nary a problem, regressing for sake of 'compatibility' with a linux-based sub-application seems silly. I agree with you about this not being a KPPP bug (though searching KDE bugs for 'kppp' provides no shortage of hits!) and appreciate that KDE people have no interest in catering for user ppp, since it's not linux, despite or perhaps because of its obvious superiority to FreeBSD people. Maybe at least the KPPP 'documentation', such as it is, could at least mention that it doesn't support FreeBSD's ppp over tun devices, to avoid the expectation that it should work that gave rise to this thread. And yes, if pppd is broken and won't be fixed, it should disappear. Over and out, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pppd crashes, was: kde-freebsd
Hi, On Fri, 09 Feb 2007 17:24:11 +0100 Eric Masson [EMAIL PROTECTED] said: emss Right, and an up to date pppd in base would be imho really nice to have. emss Kernel pppoe as in Net/Open would be an alternative to net/mpd. emss (No, I'm not volunteering to port NetBSD's kernel ppp to FreeBSD as my emss C kernel programming skills are way under required level) In my experience, this is not an issue that just porting pppd from NetBSD or OpenBSD, or importing latest pppd solves the problem. It seems locking problem to me, and setting debug.mpsafenet to 0 should be a workaround. Of course, it's great someone upgrading our pppd to recent one. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pppd crashes, was: kde-freebsd] Question about KPPP on FreeBSD
On Saturday, 10. February 2007 07:34, Ian Smith wrote: Since once trying (and failing) to debug or even comprehend a spaghetti of scripts and configs behind a dialout-only linux pppd setup some years ago, compared to the much more straightforward ppp with mgetty setup for both dialout and some dialin modem lines I'd built pretty much from the FreeBSD Handbook even at 2.2.6 with nary a problem, regressing for sake of 'compatibility' with a linux-based sub-application seems silly. Well, kppp makes configuring dialout easy. Or attempts to, at least. :) I agree with you about this not being a KPPP bug (though searching KDE bugs for 'kppp' provides no shortage of hits!) and appreciate that KDE people have no interest in catering for user ppp, since it's not linux, despite or perhaps because of its obvious superiority to FreeBSD people. Maybe at least the KPPP 'documentation', such as it is, could at least mention that it doesn't support FreeBSD's ppp over tun devices, to avoid the expectation that it should work that gave rise to this thread. It kinda does. It says right in the about dialog and in the very first line of its online help: A dialer and front end for pppd. And yes, if pppd is broken and won't be fixed, it should disappear. And when that happens, so will kppp (it won't build once the if_ppp.h header is gone). Which of course would solve the problem in a way. In any case: I dragged this issue onto -stable precisely to attract attention to the problem and hopefully motivate someone to get down and write some code, whether for pppd or kppp, I really don't care much. Cheers, -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpyYiQbYxsIy.pgp Description: PGP signature
