Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
On 2 July 2014 17:09, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
On 2 July 2014 14:51, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
Hi,
Is it just me or is there something wrong with vidcontrol(1) in
base/head, amd64, sc console, r268165?
Should be fixed in r268175.
Looks good, thanks.
Thanks for the report, and sorry for the trouble.
No trouble at all, I follow base/head (and stable/{8,9,10}) on various
VMs at home only to know what's ahead. ;-)
Since neither kbdcontrol(1) nor I mind using the old syscons keymap
file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
after searching for them in /usr/share/vt/keymaps?
E.g.:
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -804,7 +804,7 @@
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
- prefix[2] = vt_keymap_path;
+ prefix[1] = vt_keymap_path;
cp = getenv(KEYMAP_PATH);
if (cp != NULL)
asprintf((prefix[0]), %s/, cp);
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote:
On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
On 2 July 2014 17:09, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
On 2 July 2014 14:51, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
Hi,
Is it just me or is there something wrong with vidcontrol(1) in
base/head, amd64, sc console, r268165?
Should be fixed in r268175.
Looks good, thanks.
Thanks for the report, and sorry for the trouble.
No trouble at all, I follow base/head (and stable/{8,9,10}) on various
VMs at home only to know what's ahead. ;-)
Since neither kbdcontrol(1) nor I mind using the old syscons keymap
file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
after searching for them in /usr/share/vt/keymaps?
E.g.:
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -804,7 +804,7 @@
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
- prefix[2] = vt_keymap_path;
+ prefix[1] = vt_keymap_path;
cp = getenv(KEYMAP_PATH);
if (cp != NULL)
asprintf((prefix[0]), %s/, cp);
Or maybe this patch is even better, as it leaves one instance of blank
in the array when KEYMAP_PATH is set in the environment, at prefix[1],
and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
set in the environment.
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -800,7 +800,7 @@
char*name, *cp;
charblank[] = , keymap_path[] = KEYMAP_PATH;
charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = .kbd;
- char*prefix[] = {blank, blank, keymap_path, NULL};
+ char*prefix[] = {blank, blank, blank, keymap_path, NULL};
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
For now I could just stick to using an absolute pathname for keymap=
in /etc/rc.conf.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2014-07-03 08:02:27 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-03 08:02:27 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-03 08:02:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-07-03 08:02:27 - cleaning the object tree TB --- 2014-07-03 08:03:30 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-03 08:03:48 - At svn revision 268201 TB --- 2014-07-03 08:03:49 - building world TB --- 2014-07-03 08:03:49 - CROSS_BUILD_TESTING=YES TB --- 2014-07-03 08:03:49 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-03 08:03:49 - MAKESYSPATH=/src/share/mk TB --- 2014-07-03 08:03:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-03 08:03:49 - SRCCONF=/dev/null TB --- 2014-07-03 08:03:49 - TARGET=ia64 TB --- 2014-07-03 08:03:49 - TARGET_ARCH=ia64 TB --- 2014-07-03 08:03:49 - TZ=UTC TB --- 2014-07-03 08:03:49 - __MAKE_CONF=/dev/null TB --- 2014-07-03 08:03:49 - cd /src TB --- 2014-07-03 08:03:49 - /usr/bin/make -B buildworld Building an up-to-date bmake(1) [...] cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstFindFrom.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstFirst.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstForEach.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstForEachFrom.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstInit.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstInsert.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstIsAtEnd.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024
Re: FreeBSD iscsi target
On Thu, Jul 3, 2014 at 12:06 AM, Kevin Oberman rkober...@gmail.com wrote: On Wed, Jul 2, 2014 at 1:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Wed, Jul 02, 2014 at 12:51:59PM -0700, Kevin Oberman wrote: On Wed, Jul 2, 2014 at 4:26 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: Does freebsd iscsi target supports: 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) 3. Multiple connections per session No; see above. I think this is help for 40G links. I assume that you are looking at transfer of large amounts of data over 40G links. Assuming that tis is the case, yes, multiple connections per session Yes, this case. As I know, single transfer over 40G link limited by 10G. ??? No, not at all. Getting 40G performance over TCP is not easy, but there is no 10G limitation. As I know (may be wrong) 40G is bundled 4x10G link. For prevent packet reordering (when run over diferrent link) all packets from one sessoin must be routed to same link. Same issuse for Etherchannel. No, 40G Ethernet is single channel from the interface perspective.. What my be confusing you is that they may use lanes which, for 40G, are 10.3125G. But, unlike the case with Etherchannel, these lanes are hidden from the MAC. The interface deals with a single stream and parcels it out over the 10G (or 25G) lanes. All 100G optical links use multiple lanes (4x25G or 10x10G), but 40G my use either a single 40G lane for distances of up to 2km or 4x10G for longer runs. Since, in most cases, 40G is used within a data center or to connect to wave gear for DWDM transmission over very long distances, most runs are under 2km, so a single 40G lane may be used. When 4 lanes are used, a ribbon cable is required to assure that all optical or copper paths are exactly the same length. Since the PMD is designed to know about and use these lanes for a single channel, the issue of packet re-ordering is not present and the protocol layers above the physical are unaware of how many lanes are used. Wikipedia has a fairly good discussion under the unfortunate title of 100 Gigabit Ethernet https://en.wikipedia.org/wiki/100_Gigabit_Ethernet. Regardless of the title, the article covers both 40 and 100 Gigabit specifications as both were specified on the same standard, 802.3ba. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf --Nikolay ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd and utf-8 directory names
Kevin Lo wrote, On 07/03/2014 05:33: On Wed, Jul 02, 2014 at 12:27:07AM +0200, d...@gmx.com wrote: But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540 Well, I'm going to close that PR. :-) First, [...] Let me know if that works for you, thanks. Yes, that did work. When I'll have more time and resources, I'll try to find out why/what didn't work at the time of the IRC conversation. It is possible that Windows was using something like UTF-16, but I tested only UTF-8 -- though the apparent unavailability of any UTF-16 locale on my system indicates that base FreeBSD installations are not able to properly mount commonly-used FAT32 partitions (think about flash drives). Another next step is to find out whether a regular user can set a locale environment variable and then create a file that system utilities -- which have one pre-set locale -- (think about disk space usage quota enforcers) won't handle well. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: freebsd and utf-8 directory names
thanks, I will do that. I started to setup my locale again, and found that earlier I should have made a mistake because the new setup (almost) perfectly works: I set up login class for me following the handbook as hungarian (LANG=hu_HU.UTF-8, and charset=UTF-8; set keyboard layout to hungarian with setxkbmap hu, and used the hungarian locale in fstab to mount the fat32 partition.). there are two characters in the Hungarian alphabet which are not in the ISO-Latin1 code set (o with double accent and u with double accent, both lower and upper case) which are displayed as space in filenames, but now libreoffice is able to open the files. All other hungarian characters appeared as normal. I will do the test you suggested but it can take 1-2 days, I do not have time for it right now. rgds András Krasznai -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Kevin Lo Sent: Thursday, July 03, 2014 5:33 AM To: d...@gmx.com Cc: freebsd-current@freebsd.org; David Chisnall Subject: Re: freebsd and utf-8 directory names On Wed, Jul 02, 2014 at 12:27:07AM +0200, d...@gmx.com wrote: David Chisnall wrote, On 07/01/2014 19:06: Please note that forums.freebsd.org is not a bug tracker. I tried searching the bug tracker for bugs with FAT and filename or FAT and utf-8/utf8/character in their names and could not find any reference to this issue. If you actually want to see bugs fixed, rather than just complain about them, please file them here: https://bugs.freebsd.org/bugzilla/enter_bug.cgi Make sure that you provide all of the steps required to reproduce them. I neglected to submit a bug report because: (1) there were already at least 3 bug reports related to (FAT32 and) character sets or encodings, some of them even had patches; (2) the reports were very old, indicating that the FreeBSD developers don't care about FAT32; (3) at least one report was seemingly related, and I didn't want to create a(nother) possible duplicate. But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540 Well, I'm going to close that PR. :-) First, set LANG environment variable to hu_HU.UTF-8 in your case: # setenv LANG hu_HU.UTF-8 Second, mount the FAT32 partition in Hungarian locale: # mount_msdosfs -L hu_HU.UTF-8 /dev/da0s1 /mnt Third, untar your attachement file: # tar xvf /mnt/files.zip x 1’.txt x 2–.txt # stat 1’.txt 128 244744 -rwxr-xr-x 1 root wheel 4294967295 0 Jan 1 08:00:00 1980 Aug 1 16:57:52 2011 Aug 1 16:57:52 2011 Jul 3 11:28:24 2014 16384 0 0x800 1’.txt # stat 2–.txt 128 244746 -rwxr-xr-x 1 root wheel 4294967295 0 Jan 1 08:00:00 1980 Aug 1 16:55:20 2011 Aug 1 16:55:20 2011 Jul 3 11:28:24 2014 16384 0 0x800 2–.txt Let me know if that works for you, thanks. Kevin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD iscsi target
On Thu, Jul 03, 2014 at 09:31:45AM +0100, Nikolay Denev wrote: On Thu, Jul 3, 2014 at 12:06 AM, Kevin Oberman rkober...@gmail.com wrote: On Wed, Jul 2, 2014 at 1:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Wed, Jul 02, 2014 at 12:51:59PM -0700, Kevin Oberman wrote: On Wed, Jul 2, 2014 at 4:26 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: Does freebsd iscsi target supports: 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) 3. Multiple connections per session No; see above. I think this is help for 40G links. I assume that you are looking at transfer of large amounts of data over 40G links. Assuming that tis is the case, yes, multiple connections per session Yes, this case. As I know, single transfer over 40G link limited by 10G. ??? No, not at all. Getting 40G performance over TCP is not easy, but there is no 10G limitation. As I know (may be wrong) 40G is bundled 4x10G link. For prevent packet reordering (when run over diferrent link) all packets from one sessoin must be routed to same link. Same issuse for Etherchannel. No, 40G Ethernet is single channel from the interface perspective.. What my be confusing you is that they may use lanes which, for 40G, are 10.3125G. But, unlike the case with Etherchannel, these lanes are hidden from the MAC. The interface deals with a single stream and parcels it out over the 10G (or 25G) lanes. All 100G optical links use multiple lanes (4x25G or 10x10G), but 40G my use either a single 40G lane for distances of up to 2km or 4x10G for longer runs. Since, in most cases, 40G is used within a data center or to connect to wave gear for DWDM transmission over very long distances, most runs are under 2km, so a single 40G lane may be used. When 4 lanes are used, a ribbon cable is required to assure that all optical or copper paths are exactly the same length. Since the PMD is designed to know about and use these lanes for a single channel, the issue of packet re-ordering is not present and the protocol layers above the physical are unaware of how many lanes are used. Wikipedia has a fairly good discussion under the unfortunate title of 100 Gigabit Ethernet https://en.wikipedia.org/wiki/100_Gigabit_Ethernet. Regardless of the title, the article covers both 40 and 100 Gigabit specifications as both were specified on the same standard, 802.3ba. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD iscsi target
On Thu, Jul 3, 2014 at 10:13 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Jul 03, 2014 at 09:31:45AM +0100, Nikolay Denev wrote: On Thu, Jul 3, 2014 at 12:06 AM, Kevin Oberman rkober...@gmail.com wrote: On Wed, Jul 2, 2014 at 1:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Wed, Jul 02, 2014 at 12:51:59PM -0700, Kevin Oberman wrote: On Wed, Jul 2, 2014 at 4:26 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: Does freebsd iscsi target supports: 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) 3. Multiple connections per session No; see above. I think this is help for 40G links. I assume that you are looking at transfer of large amounts of data over 40G links. Assuming that tis is the case, yes, multiple connections per session Yes, this case. As I know, single transfer over 40G link limited by 10G. ??? No, not at all. Getting 40G performance over TCP is not easy, but there is no 10G limitation. As I know (may be wrong) 40G is bundled 4x10G link. For prevent packet reordering (when run over diferrent link) all packets from one sessoin must be routed to same link. Same issuse for Etherchannel. No, 40G Ethernet is single channel from the interface perspective.. What my be confusing you is that they may use lanes which, for 40G, are 10.3125G. But, unlike the case with Etherchannel, these lanes are hidden from the MAC. The interface deals with a single stream and parcels it out over the 10G (or 25G) lanes. All 100G optical links use multiple lanes (4x25G or 10x10G), but 40G my use either a single 40G lane for distances of up to 2km or 4x10G for longer runs. Since, in most cases, 40G is used within a data center or to connect to wave gear for DWDM transmission over very long distances, most runs are under 2km, so a single 40G lane may be used. When 4 lanes are used, a ribbon cable is required to assure that all optical or copper paths are exactly the same length. Since the PMD is designed to know about and use these lanes for a single channel, the issue of packet re-ordering is not present and the protocol layers above the physical are unaware of how many lanes are used. Wikipedia has a fairly good discussion under the unfortunate title of 100 Gigabit Ethernet https://en.wikipedia.org/wiki/100_Gigabit_Ethernet. Regardless of the title, the article covers both 40 and 100 Gigabit specifications as both were specified on the same standard, 802.3ba. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Interesting, however this seems like implementation specific detail, and not limitation of native 40Gbit ethernet. Still, it's something that one must be aware of (esp when dealing with Cisco gear :) ) I wonder why they are not doing something like this : http://blog.ipspace.net/2011/04/brocade-vcs-fabric-has-almost-perfect.html --Nikolay ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 08:31:45 +0200 (CEST)
Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote:
On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote:
On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
On 2 July 2014 17:09, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
On 2 July 2014 14:51, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
Hi,
Is it just me or is there something wrong with vidcontrol(1) in
base/head, amd64, sc console, r268165?
Should be fixed in r268175.
Looks good, thanks.
Thanks for the report, and sorry for the trouble.
No trouble at all, I follow base/head (and stable/{8,9,10}) on various
VMs at home only to know what's ahead. ;-)
Since neither kbdcontrol(1) nor I mind using the old syscons keymap
file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
after searching for them in /usr/share/vt/keymaps?
E.g.:
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -804,7 +804,7 @@
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
- prefix[2] = vt_keymap_path;
+ prefix[1] = vt_keymap_path;
cp = getenv(KEYMAP_PATH);
if (cp != NULL)
asprintf((prefix[0]), %s/, cp);
Or maybe this patch is even better, as it leaves one instance of blank
in the array when KEYMAP_PATH is set in the environment, at prefix[1],
and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
set in the environment.
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -800,7 +800,7 @@
char*name, *cp;
charblank[] = , keymap_path[] = KEYMAP_PATH;
charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = .kbd;
- char*prefix[] = {blank, blank, keymap_path, NULL};
+ char*prefix[] = {blank, blank, blank, keymap_path, NULL};
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
For now I could just stick to using an absolute pathname for keymap=
in /etc/rc.conf.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Hi Trond,
It is not so good idea to fallback to syscons keymaps, because vt(4)
works with Unicode only char codes. So fallback will make input with
non-English characters - unreadable.
Instead of that fallback you can convert keymaps you can verify by
follow instructions in [1], then please check it and send it to list,
so me or someone else will commit it.
Thank you for reports!
1.
http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html
WBW
--
Aleksandr Rybalko r...@ddteam.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD iscsi target
On Thu, Jul 03, 2014 at 10:35:55AM +0100, Nikolay Denev wrote: I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Interesting, however this seems like implementation specific detail, and not limitation of native 40Gbit ethernet. I see some perfomance tests on solaris and 40G link. In this test perfomance limited about 10Gbit per flow. May be I found links to this test. May be some NIC's implementation specific detail also limited performance per flow. Still, it's something that one must be aware of (esp when dealing with Cisco gear :) ) I wonder why they are not doing something like this : http://blog.ipspace.net/2011/04/brocade-vcs-fabric-has-almost-perfect.html --Nikolay ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
getenv(TZ) crashes triggered by tzset_basic()
Using HEAD, www/gatling reproducible crashes for me after receiving a single request if TZ isn't set: (gdb) where #0 strncmp (s1=optimized out, s2=optimized out, n=optimized out) at /usr/src/lib/libc/string/strncmp.c:46 #1 0x0008011a9ffe in strncmpeq (nameValue=0x7fffeb5e LC_PAPER=de_DE.UTF-8, name=0x8011be49e TZ, nameLen=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:144 #2 __findenv_environ (name=optimized out, nameLen=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:195 #3 getenv (name=0x8011be49e TZ) at /usr/src/lib/libc/stdlib/getenv.c:441 #4 0x000801189f49 in tzset_basic (rdlocked=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 #5 0x00080118a13e in localtime (timep=0x801c12030) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1467 #6 0x0040d38d in http_dirlisting (h=0x801c07140, D=0x801c0e080, path=0x7fffbb50 /, arg=0x0) at http.c:214 #7 0x0040ff9d in http_openfile (h=0x801c07140, filename=0x801c0c085 /, ss=0x7fffc108, sockfd=9, nobody=1) at http.c:1485 #8 0x00413922 in httpresponse (h=0x801c07140, s=9, headerlen=76) at http.c:1940 #9 0x0040657d in handle_read_misc (i=9, h=0x801c07140, ftptimeout_secs=600, nextftp=...) at gatling.c:1051 #10 0x00404d54 in main (argc=3, argv=0x7fffe840, envp=0x7fffe860) at gatling.c:2247 This is not a recent regression, I first noticed it a couple of months ago but haven't had time to look into it yet. If was reminded of this because a program I'm working on (Privoxy) recently crashed thusly: (gdb) where #0 0x00080128ef40 in strncmp (s1=optimized out, s2=optimized out, n=optimized out) at /usr/src/lib/libc/string/strncmp.c:46 #1 0x00080128bb92 in getenv (name=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:424 #2 0x00080126bb39 in tzset_basic (rdlocked=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1281 #3 0x00080126bb1b in tzset_basic (rdlocked=-14721152) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 #4 0x00080122c0a0 in _fmt (format=0x22313031734e6863 Address 0x22313031734e6863 out of bounds, t=0x8012a009e, pt=0x2 Address 0x2 out of bounds, ptlim=0xf5 Address 0xf5 out of bounds, warnp=0x8014cc418 tzname+8, loc=0x80126bb1b tzset_basic+27) at /usr/src/lib/libc/stdtime/strftime.c:137 #5 0x00080122d6fb in _conv (n=optimized out, format=optimized out, pt=optimized out, n=optimized out, format=optimized out, pt=optimized out, ptlim=optimized out) at /usr/src/lib/libc/stdtime/strftime.c:597 #6 _yconv (a=optimized out, b=optimized out, convert_top=optimized out, convert_yy=optimized out, pt=optimized out, ptlim=optimized out, a=optimized out, b=optimized out, convert_top=optimized out, convert_yy=optimized out, pt=optimized out, ptlim=optimized out) at /usr/src/lib/libc/stdtime/strftime.c:649 #7 0x00428747 in get_log_timestamp (buffer=0x7f1f5f80 2014-06-30 17:03:45.115, buffer_size=30) at errlog.c:482 [...] (gdb) f 3 #3 0x00080126bb1b in tzset_basic (rdlocked=-14721152) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 1274name = getenv(TZ); I haven't been able to reproduce the Privoxy crash yet, but in case of gatling the problem is reproducible and valgrind doesn't complain about any previous memory corruption: fk@r500 ~/test/privoxy/test $valgrind gatling -p 81 ==6563== Memcheck, a memory error detector ==6563== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==6563== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==6563== Command: gatling -p 81 ==6563== starting_up 0 :: 81 start_ftp 0 :: 2121 accept 7 10.0.0.1 48596 1 http ==6563== Invalid read of size 1 ==6563==at 0x1039C74: strncmp (mc_replace_strmem.c:596) ==6563==by 0x1BA1FFD: getenv (getenv.c:144) ==6563==by 0x1B81F48: ??? (localtime.c:1274) ==6563==by 0x1B8213D: localtime (localtime.c:1467) ==6563==by 0x40D38C: http_dirlisting (http.c:214) ==6563==by 0x40FF9C: http_openfile (http.c:1485) ==6563==by 0x413921: httpresponse (http.c:1940) ==6563==by 0x40657C: handle_read_misc (gatling.c:1051) ==6563==by 0x404D53: main (gatling.c:2247) ==6563== Address 0xff000b7a is not stack'd, malloc'd or (recently) free'd ==6563== ==6563== ==6563== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==6563== Access not within mapped region at address 0xFF000B7A ==6563==at 0x1039C74: strncmp (mc_replace_strmem.c:596) ==6563==by 0x1BA1FFD: getenv (getenv.c:144) ==6563==by 0x1B81F48: ??? (localtime.c:1274) ==6563==by 0x1B8213D: localtime (localtime.c:1467) ==6563==by 0x40D38C: http_dirlisting (http.c:214) ==6563==by 0x40FF9C: http_openfile (http.c:1485) ==6563==by 0x413921: httpresponse (http.c:1940) ==6563==by 0x40657C: handle_read_misc (gatling.c:1051) ==6563==by 0x404D53: main (gatling.c:2247) ==6563== If you
Re: getenv(TZ) crashes triggered by tzset_basic()
On Thu, 3 Jul 2014 14:01+0200, Fabian Keil wrote: Using HEAD, www/gatling reproducible crashes for me after receiving a single request if TZ isn't set: (gdb) where #0 strncmp (s1=optimized out, s2=optimized out, n=optimized out) at /usr/src/lib/libc/string/strncmp.c:46 #1 0x0008011a9ffe in strncmpeq (nameValue=0x7fffeb5e LC_PAPER=de_DE.UTF-8, name=0x8011be49e TZ, nameLen=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:144 #2 __findenv_environ (name=optimized out, nameLen=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:195 #3 getenv (name=0x8011be49e TZ) at /usr/src/lib/libc/stdlib/getenv.c:441 #4 0x000801189f49 in tzset_basic (rdlocked=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 #5 0x00080118a13e in localtime (timep=0x801c12030) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1467 #6 0x0040d38d in http_dirlisting (h=0x801c07140, D=0x801c0e080, path=0x7fffbb50 /, arg=0x0) at http.c:214 #7 0x0040ff9d in http_openfile (h=0x801c07140, filename=0x801c0c085 /, ss=0x7fffc108, sockfd=9, nobody=1) at http.c:1485 #8 0x00413922 in httpresponse (h=0x801c07140, s=9, headerlen=76) at http.c:1940 #9 0x0040657d in handle_read_misc (i=9, h=0x801c07140, ftptimeout_secs=600, nextftp=...) at gatling.c:1051 #10 0x00404d54 in main (argc=3, argv=0x7fffe840, envp=0x7fffe860) at gatling.c:2247 This is not a recent regression, I first noticed it a couple of months ago but haven't had time to look into it yet. If was reminded of this because a program I'm working on (Privoxy) recently crashed thusly: (gdb) where #0 0x00080128ef40 in strncmp (s1=optimized out, s2=optimized out, n=optimized out) at /usr/src/lib/libc/string/strncmp.c:46 #1 0x00080128bb92 in getenv (name=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:424 #2 0x00080126bb39 in tzset_basic (rdlocked=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1281 #3 0x00080126bb1b in tzset_basic (rdlocked=-14721152) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 #4 0x00080122c0a0 in _fmt (format=0x22313031734e6863 Address 0x22313031734e6863 out of bounds, t=0x8012a009e, pt=0x2 Address 0x2 out of bounds, ptlim=0xf5 Address 0xf5 out of bounds, warnp=0x8014cc418 tzname+8, loc=0x80126bb1b tzset_basic+27) at /usr/src/lib/libc/stdtime/strftime.c:137 #5 0x00080122d6fb in _conv (n=optimized out, format=optimized out, pt=optimized out, n=optimized out, format=optimized out, pt=optimized out, ptlim=optimized out) at /usr/src/lib/libc/stdtime/strftime.c:597 #6 _yconv (a=optimized out, b=optimized out, convert_top=optimized out, convert_yy=optimized out, pt=optimized out, ptlim=optimized out, a=optimized out, b=optimized out, convert_top=optimized out, convert_yy=optimized out, pt=optimized out, ptlim=optimized out) at /usr/src/lib/libc/stdtime/strftime.c:649 #7 0x00428747 in get_log_timestamp (buffer=0x7f1f5f80 2014-06-30 17:03:45.115, buffer_size=30) at errlog.c:482 [...] (gdb) f 3 #3 0x00080126bb1b in tzset_basic (rdlocked=-14721152) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 1274 name = getenv(TZ); Does the code test at all for the possibility of getenv(3) returning a NULL pointer? I haven't been able to reproduce the Privoxy crash yet, but in case of gatling the problem is reproducible and valgrind doesn't complain about any previous memory corruption: fk@r500 ~/test/privoxy/test $valgrind gatling -p 81 ==6563== Memcheck, a memory error detector ==6563== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==6563== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==6563== Command: gatling -p 81 ==6563== starting_up 0 :: 81 start_ftp 0 :: 2121 accept 7 10.0.0.1 48596 1 http ==6563== Invalid read of size 1 ==6563==at 0x1039C74: strncmp (mc_replace_strmem.c:596) ==6563==by 0x1BA1FFD: getenv (getenv.c:144) ==6563==by 0x1B81F48: ??? (localtime.c:1274) ==6563==by 0x1B8213D: localtime (localtime.c:1467) ==6563==by 0x40D38C: http_dirlisting (http.c:214) ==6563==by 0x40FF9C: http_openfile (http.c:1485) ==6563==by 0x413921: httpresponse (http.c:1940) ==6563==by 0x40657C: handle_read_misc (gatling.c:1051) ==6563==by 0x404D53: main (gatling.c:2247) ==6563== Address 0xff000b7a is not stack'd, malloc'd or (recently) free'd ==6563== ==6563== ==6563== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==6563== Access not within mapped region at address 0xFF000B7A ==6563==at 0x1039C74: strncmp (mc_replace_strmem.c:596) ==6563==by 0x1BA1FFD: getenv (getenv.c:144) ==6563==by 0x1B81F48: ??? (localtime.c:1274) ==6563==by 0x1B8213D: localtime (localtime.c:1467) ==6563==by 0x40D38C: http_dirlisting
Re: getenv(TZ) crashes triggered by tzset_basic()
Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote: On Thu, 3 Jul 2014 14:01+0200, Fabian Keil wrote: Using HEAD, www/gatling reproducible crashes for me after receiving a single request if TZ isn't set: (gdb) where #0 strncmp (s1=optimized out, s2=optimized out, n=optimized out) at /usr/src/lib/libc/string/strncmp.c:46 #1 0x0008011a9ffe in strncmpeq (nameValue=0x7fffeb5e LC_PAPER=de_DE.UTF-8, name=0x8011be49e TZ, nameLen=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:144 #2 __findenv_environ (name=optimized out, nameLen=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:195 #3 getenv (name=0x8011be49e TZ) at /usr/src/lib/libc/stdlib/getenv.c:441 #4 0x000801189f49 in tzset_basic (rdlocked=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 #5 0x00080118a13e in localtime (timep=0x801c12030) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1467 #6 0x0040d38d in http_dirlisting (h=0x801c07140, D=0x801c0e080, path=0x7fffbb50 /, arg=0x0) at http.c:214 #7 0x0040ff9d in http_openfile (h=0x801c07140, filename=0x801c0c085 /, ss=0x7fffc108, sockfd=9, nobody=1) at http.c:1485 #8 0x00413922 in httpresponse (h=0x801c07140, s=9, headerlen=76) at http.c:1940 #9 0x0040657d in handle_read_misc (i=9, h=0x801c07140, ftptimeout_secs=600, nextftp=...) at gatling.c:1051 #10 0x00404d54 in main (argc=3, argv=0x7fffe840, envp=0x7fffe860) at gatling.c:2247 This is not a recent regression, I first noticed it a couple of months ago but haven't had time to look into it yet. If was reminded of this because a program I'm working on (Privoxy) recently crashed thusly: (gdb) where #0 0x00080128ef40 in strncmp (s1=optimized out, s2=optimized out, n=optimized out) at /usr/src/lib/libc/string/strncmp.c:46 #1 0x00080128bb92 in getenv (name=optimized out) at /usr/src/lib/libc/stdlib/getenv.c:424 #2 0x00080126bb39 in tzset_basic (rdlocked=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1281 #3 0x00080126bb1b in tzset_basic (rdlocked=-14721152) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 #4 0x00080122c0a0 in _fmt (format=0x22313031734e6863 Address 0x22313031734e6863 out of bounds, t=0x8012a009e, pt=0x2 Address 0x2 out of bounds, ptlim=0xf5 Address 0xf5 out of bounds, warnp=0x8014cc418 tzname+8, loc=0x80126bb1b tzset_basic+27) at /usr/src/lib/libc/stdtime/strftime.c:137 #5 0x00080122d6fb in _conv (n=optimized out, format=optimized out, pt=optimized out, n=optimized out, format=optimized out, pt=optimized out, ptlim=optimized out) at /usr/src/lib/libc/stdtime/strftime.c:597 #6 _yconv (a=optimized out, b=optimized out, convert_top=optimized out, convert_yy=optimized out, pt=optimized out, ptlim=optimized out, a=optimized out, b=optimized out, convert_top=optimized out, convert_yy=optimized out, pt=optimized out, ptlim=optimized out) at /usr/src/lib/libc/stdtime/strftime.c:649 #7 0x00428747 in get_log_timestamp (buffer=0x7f1f5f80 2014-06-30 17:03:45.115, buffer_size=30) at errlog.c:482 [...] (gdb) f 3 #3 0x00080126bb1b in tzset_basic (rdlocked=-14721152) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1274 1274name = getenv(TZ); Does the code test at all for the possibility of getenv(3) returning a NULL pointer? It does: http://svnweb.freebsd.org/base/head/contrib/tzcode/stdtime/localtime.c?view=markup#l1270 Assuming the back traces aren't corrupted, the crashes occur before getenv() returns, though. Fabian signature.asc Description: PGP signature
RE: freebsd and utf-8 directory names
Hi, Kevin, I made the experiment and there was no fault, the result contains the stat outputs. I used login-class (according to the handbook) to set the environment, and added the -L hu_HU.UTF-8 option to the appropriate line in fstab rgds András From: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] On Behalf Of Kevin Lo [ke...@freebsd.org] Sent: Thursday, July 03, 2014 5:33 AM To: d...@gmx.com Cc: freebsd-current@freebsd.org; David Chisnall Subject: Re: freebsd and utf-8 directory names On Wed, Jul 02, 2014 at 12:27:07AM +0200, d...@gmx.com wrote: David Chisnall wrote, On 07/01/2014 19:06: Please note that forums.freebsd.org is not a bug tracker. I tried searching the bug tracker for bugs with FAT and filename or FAT and utf-8/utf8/character in their names and could not find any reference to this issue. If you actually want to see bugs fixed, rather than just complain about them, please file them here: https://bugs.freebsd.org/bugzilla/enter_bug.cgi Make sure that you provide all of the steps required to reproduce them. I neglected to submit a bug report because: (1) there were already at least 3 bug reports related to (FAT32 and) character sets or encodings, some of them even had patches; (2) the reports were very old, indicating that the FreeBSD developers don't care about FAT32; (3) at least one report was seemingly related, and I didn't want to create a(nother) possible duplicate. But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540 Well, I'm going to close that PR. :-) First, set LANG environment variable to hu_HU.UTF-8 in your case: # setenv LANG hu_HU.UTF-8 Second, mount the FAT32 partition in Hungarian locale: # mount_msdosfs -L hu_HU.UTF-8 /dev/da0s1 /mnt Third, untar your attachement file: # tar xvf /mnt/files.zip x 1’.txt x 2–.txt # stat 1’.txt 128 244744 -rwxr-xr-x 1 root wheel 4294967295 0 Jan 1 08:00:00 1980 Aug 1 16:57:52 2011 Aug 1 16:57:52 2011 Jul 3 11:28:24 2014 16384 0 0x800 1’.txt # stat 2–.txt 128 244746 -rwxr-xr-x 1 root wheel 4294967295 0 Jan 1 08:00:00 1980 Aug 1 16:55:20 2011 Aug 1 16:55:20 2011 Jul 3 11:28:24 2014 16384 0 0x800 2–.txt Let me know if that works for you, thanks. Kevin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org result Description: result ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 12:48+0300, Aleksandr Rybalko wrote:
On Thu, 3 Jul 2014 08:31:45 +0200 (CEST)
Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote:
On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote:
On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
On 2 July 2014 17:09, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
On 2 July 2014 14:51, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
Hi,
Is it just me or is there something wrong with vidcontrol(1) in
base/head, amd64, sc console, r268165?
Should be fixed in r268175.
Looks good, thanks.
Thanks for the report, and sorry for the trouble.
No trouble at all, I follow base/head (and stable/{8,9,10}) on various
VMs at home only to know what's ahead. ;-)
Since neither kbdcontrol(1) nor I mind using the old syscons keymap
file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
after searching for them in /usr/share/vt/keymaps?
E.g.:
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -804,7 +804,7 @@
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
- prefix[2] = vt_keymap_path;
+ prefix[1] = vt_keymap_path;
cp = getenv(KEYMAP_PATH);
if (cp != NULL)
asprintf((prefix[0]), %s/, cp);
Or maybe this patch is even better, as it leaves one instance of blank
in the array when KEYMAP_PATH is set in the environment, at prefix[1],
and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
set in the environment.
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -800,7 +800,7 @@
char*name, *cp;
charblank[] = , keymap_path[] = KEYMAP_PATH;
charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = .kbd;
- char*prefix[] = {blank, blank, keymap_path, NULL};
+ char*prefix[] = {blank, blank, blank, keymap_path, NULL};
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
For now I could just stick to using an absolute pathname for keymap=
in /etc/rc.conf.
Hi Trond,
It is not so good idea to fallback to syscons keymaps, because vt(4)
works with Unicode only char codes. So fallback will make input with
non-English characters - unreadable.
Instead of that fallback you can convert keymaps you can verify by
follow instructions in [1], then please check it and send it to list,
so me or someone else will commit it.
Thank you for reports!
1.
http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html
I tried to follow the instructions, but I honestly don't see any
difference.
I downloaded uakbd2ukbd.pl.gz, decompressed the file, installed
converters/p5-Text-Iconv, copied /usr/share/syscons/norwegian.iso.kbd
to cwd, and ran:
./uakbd2ukbd.pl norwegian.iso.kbd ISO-8859-1 norwegian.utf8.kbd
Running diff -u norwegian.* shows absolutely no difference.
Is it pilot error on my part?
I have attached both files.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++# $FreeBSD: head/share/syscons/keymaps/norwegian.iso.kbd 117271 2003-07-06
03:09:40Z ache $
# alt
# scan cntrl altalt cntrl lock
# code base shift cntrl shift altshift cntrl shift state
# --
000 nopnopnopnopnopnopnopnop O
001 escescescescescescdebug esc O
002 '1''!'nopnop'1''!'nopnop O
003 '2'''nulnul'@''@'nulnul O
004 '3''#'nopnop158'#'nopnop O
005 '4'164nopnop'$'164nopnop O
006 '5''%'nopnop'5''%'
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 17:50+0200, Trond Endrestøl wrote:
On Thu, 3 Jul 2014 12:48+0300, Aleksandr Rybalko wrote:
On Thu, 3 Jul 2014 08:31:45 +0200 (CEST)
Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote:
On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote:
On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
On 2 July 2014 17:09, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
On 2 July 2014 14:51, Trond Endrestøl
trond.endres...@fagskolen.gjovik.no wrote:
Hi,
Is it just me or is there something wrong with vidcontrol(1) in
base/head, amd64, sc console, r268165?
Should be fixed in r268175.
Looks good, thanks.
Thanks for the report, and sorry for the trouble.
No trouble at all, I follow base/head (and stable/{8,9,10}) on various
VMs at home only to know what's ahead. ;-)
Since neither kbdcontrol(1) nor I mind using the old syscons keymap
file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
after searching for them in /usr/share/vt/keymaps?
E.g.:
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -804,7 +804,7 @@
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
- prefix[2] = vt_keymap_path;
+ prefix[1] = vt_keymap_path;
cp = getenv(KEYMAP_PATH);
if (cp != NULL)
asprintf((prefix[0]), %s/, cp);
Or maybe this patch is even better, as it leaves one instance of blank
in the array when KEYMAP_PATH is set in the environment, at prefix[1],
and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
set in the environment.
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
--- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
+++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
@@ -800,7 +800,7 @@
char*name, *cp;
charblank[] = , keymap_path[] = KEYMAP_PATH;
charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = .kbd;
- char*prefix[] = {blank, blank, keymap_path, NULL};
+ char*prefix[] = {blank, blank, blank, keymap_path, NULL};
char*postfix[] = {blank, dotkbd, NULL};
if (is_vt4())
For now I could just stick to using an absolute pathname for keymap=
in /etc/rc.conf.
Hi Trond,
It is not so good idea to fallback to syscons keymaps, because vt(4)
works with Unicode only char codes. So fallback will make input with
non-English characters - unreadable.
Instead of that fallback you can convert keymaps you can verify by
follow instructions in [1], then please check it and send it to list,
so me or someone else will commit it.
Thank you for reports!
1.
http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html
I tried to follow the instructions, but I honestly don't see any
difference.
I downloaded uakbd2ukbd.pl.gz, decompressed the file, installed
converters/p5-Text-Iconv, copied /usr/share/syscons/norwegian.iso.kbd
to cwd, and ran:
./uakbd2ukbd.pl norwegian.iso.kbd ISO-8859-1 norwegian.utf8.kbd
Running diff -u norwegian.* shows absolutely no difference.
Is it pilot error on my part?
Yes, perhaps it was pilot error.
Running:
./uakbd2ukbd.pl norwegian.iso.kbd ISO-8859-15 norwegian.utf8-15.kbd
produced differences when compared to norwegian.iso.kbd.
The keyboard checked out on all three occasions, with the original
norwegian.iso.kbd, with the norwegian.utf8.kbd, and with the
norwegian.utf8-15.kbd.
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++# $FreeBSD: head/share/syscons/keymaps/norwegian.iso.kbd 117271 2003-07-06
03:09:40Z ache $
# alt
# scan cntrl altalt cntrl lock
# code base shift cntrl shift altshift cntrl shift state
# --
Re: FreeBSD iscsi target
Which NIC? -a On 3 July 2014 03:29, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Jul 03, 2014 at 10:35:55AM +0100, Nikolay Denev wrote: I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Interesting, however this seems like implementation specific detail, and not limitation of native 40Gbit ethernet. I see some perfomance tests on solaris and 40G link. In this test perfomance limited about 10Gbit per flow. May be I found links to this test. May be some NIC's implementation specific detail also limited performance per flow. Still, it's something that one must be aware of (esp when dealing with Cisco gear :) ) I wonder why they are not doing something like this : http://blog.ipspace.net/2011/04/brocade-vcs-fabric-has-almost-perfect.html --Nikolay ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD iscsi target
On Thu, Jul 03, 2014 at 10:28:19AM -0700, Adrian Chadd wrote: Which NIC? I am can't find again this forum posts (last time I find -- year ago). May be this http://hardforum.com/showthread.php?t=1662769 In this case -- Mellanox QDR ConnectX2 Infiniband. On 3 July 2014 03:29, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Jul 03, 2014 at 10:35:55AM +0100, Nikolay Denev wrote: I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Interesting, however this seems like implementation specific detail, and not limitation of native 40Gbit ethernet. I see some perfomance tests on solaris and 40G link. In this test perfomance limited about 10Gbit per flow. May be I found links to this test. May be some NIC's implementation specific detail also limited performance per flow. Still, it's something that one must be aware of (esp when dealing with Cisco gear :) ) I wonder why they are not doing something like this : http://blog.ipspace.net/2011/04/brocade-vcs-fabric-has-almost-perfect.html --Nikolay ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On 3 July 2014 11:50, Trond Endrestøl trond.endres...@fagskolen.gjovik.no wrote: 1. http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html I tried to follow the instructions, but I honestly don't see any difference. I downloaded uakbd2ukbd.pl.gz, decompressed the file, installed converters/p5-Text-Iconv, copied /usr/share/syscons/norwegian.iso.kbd to cwd, and ran: ./uakbd2ukbd.pl norwegian.iso.kbd ISO-8859-1 norwegian.utf8.kbd Running diff -u norwegian.* shows absolutely no difference. Actually, I believe that's to be expected. The ISO-8859-1 code points and the first 256 Unicode code points are the same. You should be able to confirm by checking that you can produce the currency symbol, diaeresis, broken bar, and currency symbol. (If they don't get mangled by email: ¤ ¨ ¦ ¸ ) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2014-07-03 22:16:31 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-03 22:16:31 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-03 22:16:31 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-07-03 22:16:31 - cleaning the object tree TB --- 2014-07-03 22:16:31 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-03 22:17:00 - At svn revision 268215 TB --- 2014-07-03 22:17:01 - building world TB --- 2014-07-03 22:17:01 - CROSS_BUILD_TESTING=YES TB --- 2014-07-03 22:17:01 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-03 22:17:01 - MAKESYSPATH=/src/share/mk TB --- 2014-07-03 22:17:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-03 22:17:01 - SRCCONF=/dev/null TB --- 2014-07-03 22:17:01 - TARGET=ia64 TB --- 2014-07-03 22:17:01 - TARGET_ARCH=ia64 TB --- 2014-07-03 22:17:01 - TZ=UTC TB --- 2014-07-03 22:17:01 - __MAKE_CONF=/dev/null TB --- 2014-07-03 22:17:01 - cd /src TB --- 2014-07-03 22:17:01 - /usr/bin/make -B buildworld Building an up-to-date bmake(1) [...] cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstFindFrom.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstFirst.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstForEach.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstForEachFrom.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstInit.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstInsert.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -D_PATH_DEFSYSPATH=\.../share/mk:/usr/share/mk\ -I. -I/src/contrib/bmake -DMAKE_NATIVE -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign-c /src/contrib/bmake/lst.lib/lstIsAtEnd.c cc -O2 -pipe -DNO_PWD_OVERRIDE -I/src/usr.bin/bmake -DBMAKE_PATH_MAX=1024 -DUSE_META -DMAKE_NATIVE -DHAVE_CONFIG_H -DHAVE_CONFIG_H -DBMAKE_PATH_MAX=1024
Re: FreeBSD iscsi target
On Tue, Jul 1, 2014 at 2:12 AM, Edward Tomasz Napierała tr...@freebsd.org wrote: In 10-STABLE there is a way to control access based on initiator name and IP address. Edward, Out of curiousity, what kinds of interop testing do you do when you implement the iSCSI code in FreeBSD? I work on FreeNAS at iXsystems, and we have found that iSCSI is a complex protocol, and there are interop issues, especially with VMWare ESX. Luckily I see that Alexander Motin has been working with you to commit fixes to the iSCSI code, which help. I've rolled an experimental FreeNAS image based on FreeBSD 10 at svn revision r268201 if you want to give it a try: http://download.freenas.org/nightlies/10.0.0/ALPHA/20140703/ -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
EDEADLK from fcntl(F_SETFL) ?
Hi! I've seen sqlite3 crap out due to disk IO error. It looks like the F_SETFL path is returning EDEADLK when it shouldn't be - only the wait version of this should be. The kernel code looks to be: lf_setlock() - lf_add_outgoing() - lf_add_edge() - graph_add_edge() - EDEADLK .. and lf_setlock() will return an error from lf_add_outgoing() without checking if it's (a) EDEADLK, and (b) whether we're going to sleep or not. So, sqlite3 trips up on this. I'm sure other things do. What should the correct thing be? It looks like EWOULDBLOCK is the correct value to return for F_SETFL failing, not EDEADLK. What do those-who-know-POSIX-standards-better-than-I think? Thanks! -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: EDEADLK from fcntl(F_SETFL) ?
Hi, I'm currently testing this out. It seems to be working out alright. adrian@test3:~/work/freebsd % svn diff stable/10/src/sys/kern/ Index: stable/10/src/sys/kern/kern_lockf.c === --- stable/10/src/sys/kern/kern_lockf.c (revision 267627) +++ stable/10/src/sys/kern/kern_lockf.c (working copy) @@ -1425,6 +1425,14 @@ if (lockf_debug 1) lf_print(lf_setlock: deadlock, lock); #endif + + /* +* If the lock isn't waiting, return EAGAIN +* rather than EDEADLK. +*/ + if (((lock-lf_flags F_WAIT) == 0) + (error == EDEADLK)) + error = EAGAIN; lf_free_lock(lock); goto out; } On 3 July 2014 17:45, Adrian Chadd adrian.ch...@gmail.com wrote: Hi! I've seen sqlite3 crap out due to disk IO error. It looks like the F_SETFL path is returning EDEADLK when it shouldn't be - only the wait version of this should be. The kernel code looks to be: lf_setlock() - lf_add_outgoing() - lf_add_edge() - graph_add_edge() - EDEADLK .. and lf_setlock() will return an error from lf_add_outgoing() without checking if it's (a) EDEADLK, and (b) whether we're going to sleep or not. So, sqlite3 trips up on this. I'm sure other things do. What should the correct thing be? It looks like EWOULDBLOCK is the correct value to return for F_SETFL failing, not EDEADLK. What do those-who-know-POSIX-standards-better-than-I think? Thanks! -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD iscsi target
On Thu, Jul 3, 2014 at 2:13 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Jul 03, 2014 at 09:31:45AM +0100, Nikolay Denev wrote: On Thu, Jul 3, 2014 at 12:06 AM, Kevin Oberman rkober...@gmail.com wrote: On Wed, Jul 2, 2014 at 1:36 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Wed, Jul 02, 2014 at 12:51:59PM -0700, Kevin Oberman wrote: On Wed, Jul 2, 2014 at 4:26 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: Does freebsd iscsi target supports: 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) 3. Multiple connections per session No; see above. I think this is help for 40G links. I assume that you are looking at transfer of large amounts of data over 40G links. Assuming that tis is the case, yes, multiple connections per session Yes, this case. As I know, single transfer over 40G link limited by 10G. ??? No, not at all. Getting 40G performance over TCP is not easy, but there is no 10G limitation. As I know (may be wrong) 40G is bundled 4x10G link. For prevent packet reordering (when run over diferrent link) all packets from one sessoin must be routed to same link. Same issuse for Etherchannel. No, 40G Ethernet is single channel from the interface perspective.. What my be confusing you is that they may use lanes which, for 40G, are 10.3125G. But, unlike the case with Etherchannel, these lanes are hidden from the MAC. The interface deals with a single stream and parcels it out over the 10G (or 25G) lanes. All 100G optical links use multiple lanes (4x25G or 10x10G), but 40G my use either a single 40G lane for distances of up to 2km or 4x10G for longer runs. Since, in most cases, 40G is used within a data center or to connect to wave gear for DWDM transmission over very long distances, most runs are under 2km, so a single 40G lane may be used. When 4 lanes are used, a ribbon cable is required to assure that all optical or copper paths are exactly the same length. Since the PMD is designed to know about and use these lanes for a single channel, the issue of packet re-ordering is not present and the protocol layers above the physical are unaware of how many lanes are used. Wikipedia has a fairly good discussion under the unfortunate title of 100 Gigabit Ethernet https://en.wikipedia.org/wiki/100_Gigabit_Ethernet. Regardless of the title, the article covers both 40 and 100 Gigabit specifications as both were specified on the same standard, 802.3ba. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I found this white paper useful in understanding how this works : http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf In real world Reality is quite different than it actually is. http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html See Packet Path Theory of Operation. Ingress Mode. Yep. It is really crappy LAGG (fixed three-tupple hash... yuck!) and is really nothing but 4 10G Ethernet ports using a 40G PHY in yhe 4x10G form. Note that they don't make any claim of 802.3ba compliance. It only states that 40 Gigabit Ethernet is now part of the IEEE 802.3ba standard. So it is, but this device almost certainly predates the completion of the standard to get a product for which there was great demand. It's a data center product and for typical cases of large numbers of small flow, it should do the trick. Probably does not interoperate with true 80-2.3ba hardware, either. My boss at the time I retired last November was on the committee that wrote 802.3ba. He would be a good authority on whether the standard has any vague wording that would allow this, but he retired 5 month after I did and I have no contact information for him. But I'm pretty sure that there is no way that this is legitimate 40G Ethernet. -- R. Kevin Oberman, Network Engineer, Retired E-mail:
