Re: Marvel Yukon using the sk driver
Hi, what I can tell. I had a terrible problem with this card (PCI-E version) exactly one week ago. Both drivers msk from the system and myk from the vendor show similar behavior. On high loads, like 2-3 users from Samba domain pulling their profiles at the same time, the card just chokes. No ping, and "buffer overflow message". I mean I had to bring the interface down and up again. Absolutely disgusting. No tweak helps. I mean, we tested it over the weekend and it was fine, till folks come there on Monday and start massively using the server. We downgraded the hardware and put good old 3Com509 PCI or whatever works with xl driver. Robert Slawson said the following on 20.08.2007 10:13: Greetings, I have a marvel yukon pci gigabit ethernet card. For some reason, after a period of time it will not transmit unless I make it transmit by pinging via the console. It is very annoying as I cannot ssh into the machine until I "wake up" the card by telling it to ping something. I am using 6.2 stable and just yesterday rebuilt the kernel and world hoping this would fix the problem. But nothing seems to help. I think the card needs to use the msk driver , which is installed, but the card keeps using the sk driver. Is there a way to have freebsd re identify the card correctly and use the proper driver? Thanks in advance, Bob ___ 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: Marvel Yukon using the sk driver
I agree, the second card we have there is Intel with fxp driver. One correction. The message said: "no buffer space available", when you ping something through that card. Clayton Milos said the following on 20.08.2007 16:05: Hi, what I can tell. I had a terrible problem with this card (PCI-E version) exactly one week ago. Both drivers msk from the system and myk from the vendor show similar behavior. On high loads, like 2-3 users from Samba domain pulling their profiles at the same time, the card just chokes. No ping, and "buffer overflow message". I mean I had to bring the interface down and up again. Absolutely disgusting. No tweak helps. I mean, we tested it over the weekend and it was fine, till folks come there on Monday and start massively using the server. We downgraded the hardware and put good old 3Com509 PCI or whatever works with xl driver. Robert Slawson said the following on 20.08.2007 10:13: Greetings, I have a marvel yukon pci gigabit ethernet card. For some reason, after a period of time it will not transmit unless I make it transmit by pinging via the console. It is very annoying as I cannot ssh into the machine until I "wake up" the card by telling it to ping something. I am using 6.2 stable and just yesterday rebuilt the kernel and world hoping this would fix the problem. But nothing seems to help. I think the card needs to use the msk driver , which is installed, but the card keeps using the sk driver. Is there a way to have freebsd re identify the card correctly and use the proper driver? Thanks in advance, Bob From my experience it always pays to use good hardware. I use 3com/Broadcom or Intel NIC's. Nothing else. Ever! They get much better throughput with less CPU overhead. And the real advantage is they have good suport in UNIX systems. I know Jack Vogel did his best and sorted out the issues with mine and many other people's Intel gigabit (em based) cards when there were issues. My em card is flying along happily now like it should be. The last server I bought had dual onboard Broadcom NIC's and I've had not issues throwing 500Mbit/s through them. Haven't had a chance to really push them to the limits yet. I know I'm not really helping you directly here but my advice would be to throw an Intel gigabit desktop adapter in there and your problems will disappear. They're only $20-$30 nowadays and it's going to take your headache away. -Clay ___ 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: GELI versus GBDE?
Definitely GELI. GBDE will become obsolete very soon as some other things like vinum and such. It was there just as a test of concept as I understand. Many those different disk subsystems are incompatible in fact, the case of GBDE and Vinum is mentioned as an example in the handbook. Read more about GEOM, as this system will unite all possible disk techniqies. Also, GELI takes advantage of crypto-hardware, but I believe that one gets a benefit out of it only if the main CPU is very slow. Michael C Voorhis said the following on 14.04.2007 18:07: The Handbook contains descriptions of GELI and GBDE for encrypting disk partitions; will both of these techniques remain available into the future? The fact that there are two implies (to me) that one may be on the way out, in preference of the other. In src/sys/geom/eli (RELENG_6) the oldest GELI sources are younger than the youngest GBDE stuff in src/sys/geom/bde. Is GBDE falling by the wayside in favor of GELI? Thanks for any information, Mike. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GELI versus GBDE?
Oh, and of course! GELI allow selection of the algorithm, key length and such. GBDE uses AES-128 only. I migrated to GELI in December, 2006. After the problem I had was resolved: http://www.freebsd.org/cgi/query-pr.cgi?pr=104669 Honestly, I also had a problem with GELI data authentication support, but I don't really need it. Google and search the PR database to see what other folks had to say. Michael C Voorhis said the following on 14.04.2007 18:07: The Handbook contains descriptions of GELI and GBDE for encrypting disk partitions; will both of these techniques remain available into the future? The fact that there are two implies (to me) that one may be on the way out, in preference of the other. In src/sys/geom/eli (RELENG_6) the oldest GELI sources are younger than the youngest GBDE stuff in src/sys/geom/bde. Is GBDE falling by the wayside in favor of GELI? Thanks for any information, Mike. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GELI versus GBDE?
Anyway, the other reasons that GBDE suck are: 1) Lots of annoying ENOMEM messages, since the memory allocation calls gbde makes are somewhat specific as I understand. One can ignore those messages. 2) GELI provides a onetime key feature, which makes it incredibly convenient for swap and /tmp encryption. 3) The secret key in GELI can be split between the keyfile and the passphrase. The only inconvenience I had with GELI is that if one wants to read a passphrase in a script once and then open a bunch of volumes, than one has to use "expect" to feed the passphrase to geli. It requires the terminal input and won't accept the stdin. GBDE does not have such issue. P.S. One can actually have both in kernel. Christian Brueffer said the following on 16.04.2007 11:21: On Sun, Apr 15, 2007 at 08:56:07AM -0500, Nikolay Mirin wrote: Definitely GELI. GBDE will become obsolete very soon as some other things like vinum and such. It was there just as a test of concept as I understand. Many those different disk subsystems are incompatible in fact, the case of GBDE and Vinum is mentioned as an example in the handbook. Read more about GEOM, as this system will unite all possible disk techniqies. Also, GELI takes advantage of crypto-hardware, but I believe that one gets a benefit out of it only if the main CPU is very slow. There are currently no plans to remove GBDE. The problems with Vinum you mention stemmed from the fact, that the original Vinum was not GEOM aware, thus, GELI couldn't have been used with it as well. gvinum has been in existance for some time now and it's fully compatible to both GBDE and GELI. - Christian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't mount encrypted drive
1) Are sure you have not just mistyped you password? 2) Does the file /etc/gbde/ad0s2c still exist? 3) Does the device /dev/ad0s2c still exist? 4) Did you include gbde in you new kernel config or do you have the up-to-date kernel gbde module compiled. What does it respond when if you run gbde attach /dev/ad0s2c -l /etc/gbde/ad0s2c and type you password. Napoleon Dynamite said the following on 31.03.2006 18:34: I noticed this morning I couldn't mount my encrypted hard drive. I have a backup of it, just in case. I cvsuped src and rebooted after a make world, and this is the error I get when mounting my hard drive via a script: mountprivate Enter passphrase: /dev/ad0s2c.bde (No such file or directory)Can't stat /dev/ad0s2c.bde Can't stat /dev/ad0s2c.bde: No such file or directory Can't stat /dev/ad0s2c.bde: No such file or directory /dev/ad0s2c.bde: CAN'T CHECK FILE SYSTEM. /dev/ad0s2c.bde: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. This is the script I use to mount it, and it has worked for months until this morning: cat /usr/local/sbin/mountprivate gbde attach /dev/ad0s2c -l /etc/gbde/ad0s2c&& fsck -p -t ffs /dev/ad0s2c.bde&& mount /dev/ad0s2c.bde /private Uname is: FreeBSD thanatos.org 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Fri Mar 31 15:52:10 PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL i386 TIA, Eric Buchanan ___ 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: Can't mount encrypted drive
Well, then the only idea I have from my own experience, that either key file /etc/gbde/ad0s2c, or the whole disk partition are corrupted. If you have a backup of /etc/gbde/ad0s2c, I'd try it. Also checking disk surface may not hurt. Did the problem emerge after the upgrade or just from like nowhere? It seems to me, that you may not have gbde support activated in you kernel. I'd double check on that too. I am using gbde intensively, but all partitions I have are located on physically mirrored or RAID-5 disks. I never had such problems for almost then a year of production servers up and running. I mean like one beautiful morning it won't attach for any reason. But once the filesystem was badly corrupted, but I dumped it and then rebuilt from the scratch. Lots of inodes were lost, but they were not critical and most of missing files were in the latest backup anyway. Napoleon Dynamite said the following on 31.03.2006 20:21: El Vie 31 Mar 2006 05:56 PM, Nikolay Mirin escribió: 1) Are sure you have not just mistyped you password? 2) Does the file /etc/gbde/ad0s2c still exist? 3) Does the device /dev/ad0s2c still exist? 4) Did you include gbde in you new kernel config or do you have the up-to-date kernel gbde module compiled. 1) I am sure I typed it right, and I tried about 100 times. I have it memorized and haven't changed it recently 2) it is still there 3) yes it exists 4) it is in my new kernel configuration What does it respond when if you run gbde attach /dev/ad0s2c -l /etc/gbde/ad0s2c and type you password. After I type this, I get a blank line, and this is the output of it and ls /dev: gbde attach /dev/ad0s2c -l /etc/gbde/ad0s2c Enter passphrase: thanatos# ls /dev acd0 ad5s3a agpgartdspW0.0netstderr ttyv7 acpi ad5s3c apmdspW0.1net1 stdin ttyv8 ad0ad5s4 atadspr0.1net2 stdout ttyv9 ad0s1 ad5s4c atkbd0 fd net3 sysmouse ttyva ad0s1a ad5s4e audio0.0 fd0net4 ttyd0 ttyvb ad0s1b ad5s4f audio0.1 fido networkttyd0.init ttyvc ad0s1c ad6bpf0 geom.ctl nfs4 ttyd0.lock ttyvd ad0s2 ad6s1 consoleio nfslockttyp0 ttyve ad0s2c ad6s1a consolectl kbd0 null ttyp1 ttyvf ad0s4 ad6s1b ctty klog pcittyp2 ums0 ad5ad6s1c cuad0 kmem pf ttyv0 urandom ad5s1 ad6s1d cuad0.init logppi0 ttyv1 usb ad5s1a ad6s2 cuad0.lock lpt0 ptyp0 ttyv2 usb0 ad5s1b ad6s3 devctl lpt0.ctl ptyp1 ttyv3 xpt0 ad5s1c ad6s4 devstatmdctl ptyp2 ttyv4 zero ad5s2 ad6s4c dsp0.0 memrandom ttyv5 ad5s3 ad6s4d dsp0.1 mixer0 sndstatttyv6 I have had the encrypted partition for about five months with no problems until today. Thank you for your help. Eric Buchanan ___ 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]"
