Order of sd# allocation on isp fibre channel card
I have a HP DL380/G6 with NetBSD/amd64 6.1.4. 1 x QLogic QLE2562 8Gb dual port fibre channel card (HP Version) 1 x HP M6412A 12 drive enclosure 12 x HP 450GB fibre channel drives Strangely the sd# are allocated starting at the 5th (sd2) drive in the enclosure. They then continue sequentially until the 12th (sd9) drive and then wrap around and continue from drive 1 (sd10) - 4 (sd13). The target #'s are sequential as shown in the dmesg snippet below. Is there a logic behind how this is done? At first I thought maybe there was a MAC address on each drive and it was in sequential order but the luck of installing them perfectly in sequence doesn't make any sense. 1) Can I assume this will stay static? It has across many reboots so far. - I am about to add another M6412A enclosure on the 2nd port with another 12 drives. 2) Does anyone know the logic behind how the sd# drives are allocated for this controller? 3) I know I can map these directly to targets in the kernel config file but I am wondering if the odd allocation of target numbers starting at the 5th drive in the enclosure is a constant. dmesg below.. scsibus2 at isp0: 512 targets, 8 luns per target scsibus3 at isp1: 512 targets, 8 luns per target sd2 at scsibus2 target 0 lun 0: disk fixed sd2: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd3 at scsibus2 target 1 lun 0: disk fixed sd3: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd4 at scsibus2 target 2 lun 0: disk fixed sd4: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd5 at scsibus2 target 3 lun 0: disk fixed sd5: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd6 at scsibus2 target 4 lun 0: disk fixed sd6: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd7 at scsibus2 target 5 lun 0: disk fixed sd7: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd8 at scsibus2 target 6 lun 0: disk fixed sd8: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd9 at scsibus2 target 7 lun 0: disk fixed sd9: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd10 at scsibus2 target 9 lun 0: disk fixed sd10: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd11 at scsibus2 target 10 lun 0: disk fixed sd11: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd12 at scsibus2 target 11 lun 0: disk fixed sd12: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors sd13 at scsibus2 target 12 lun 0: disk fixed sd13: 419 GB, 153352 cyl, 8 head, 716 sec, 512 bytes/sect x 878906250 sectors Thank you Scott...
Re: tmux messes up my backspace character
Rhialto wrote: |> Can't you simply `bind-key' over that? | |I don't think so. bind-key looks to be for commands only, not a general |translation mechanism. I now see tmux has also has a terminal-overrides.. oops, but mind you, i still was registered to tmux-users@ once the thread you have been pointed to was current, so i'm sorry i didn't remember that. But i have e.g. `bind a eval copy "stuff \002"' in my .screenrc -- `stuff' is a very powerful tool, too. |> But i'm out of ideas if not; i switched back to screen(1) due to |> it's charset conversion capabilities (i'm still using ISO-8859-x |> on all BSD VMs),o | |Yes, so do I, and I noticed that if I happen to access my systems from |Linux, then tmux won't translate characters for use in utf8 terminals. So with screen i can stay in a single session, with tmux i couldn't: simply setting an UTF-8 flag on some window doesn't help to deal with different character sets. Though most is english, German Umlauts can well be transformed, even round-trip. I _really_ was surprised once i saw that this feature was missing, my guess is that administrators still live in a heterogeneous environment: all english. |> requires significantly less CPU time and after | |I am also surprised by the high cpu time usage of tmux. I wonder what it |is doing in all that time? The FAQ mentions something about automatic |window renaming or somesuch - I'm going to try turning that off and see |if that helps. Worse, for 1.6 to compile on Snow Leopard i even had to adjust its usage of `struct bsdinfo', if i recall correctly, so i even had to blame myself? Ok, sometimes i wish screen would always display a status line with all currently open windows or at least had an option to always display the current one so that there would be no need to ^A-w (windows) or ^A-W (windowlist), but having one more line is a great thing. |> And i guess your problem could be easily fixed with it's `term*' commands. | |I used screen before, and there the problem doesn't exist at all. It |took a while to discover it in tmux because many programs can use |whatever is set for the erase character, including bash. I noticed it in |mutt, where ^H scrolls back a single line in a mail message. | |I have also mailed to the tmux-users mailing list, and I have discovered |which code seems to be responsible for the translation: | |/* | * Check for backspace key using termios VERASE - the terminfo | * kbs entry is extremely unreliable, so cannot be safely | * used. termios should have a better idea. | */ |bspace = tty->tio.c_cc[VERASE]; |if (bspace != _POSIX_VDISABLE && key == bspace) |key = KEYC_BSPACE; | |in cvs/src/external/bsd/tmux/dist/tty-keys.c. Note that KEYC_BSPACE is |'\177' or ASCII DEL, not backspace. So i hope for you that tmux(1) gets fixed (you wrote "which shows to my mind a misunderstanding"), back in February the thread ended with "anyway try running stty verase ^? in tmux", at least from the developer side. Now that i know it but am back to screen, all i miss is `bind-key < set-window-option force-width 80' (and ditto `> 0'), which was very nice to have when reviewing code, but i can still use `wc -L'. --steffen
Recent video-related commits: summary wanted
There have been many video-related commits to the source tree recently, which I am doing my best to understand. Radeon, nouveau, drm, kms, and the like. It would be nice if someone would summarise what is happening and what difference it makes, and whether NetBSD 7 will benefit. A question I have for starters: do these changes bring native X up to date in -7, and if so would there be any compelling reason to choose modular X instead? -- Gerard Lally
Re: tmux messes up my backspace character
On Fri 15 Aug 2014 at 15:16:41 +0200, Steffen Nurpmeso wrote: > Can't you simply `bind-key' over that? I don't think so. bind-key looks to be for commands only, not a general translation mechanism. > But i'm out of ideas if not; i switched back to screen(1) due to > it's charset conversion capabilities (i'm still using ISO-8859-x > on all BSD VMs),o Yes, so do I, and I noticed that if I happen to access my systems from Linux, then tmux won't translate characters for use in utf8 terminals. > requires significantly less CPU time and after I am also surprised by the high cpu time usage of tmux. I wonder what it is doing in all that time? The FAQ mentions something about automatic window renaming or somesuch - I'm going to try turning that off and see if that helps. > And i guess your problem could be easily fixed with it's `term*' commands. I used screen before, and there the problem doesn't exist at all. It took a while to discover it in tmux because many programs can use whatever is set for the erase character, including bash. I noticed it in mutt, where ^H scrolls back a single line in a mail message. I have also mailed to the tmux-users mailing list, and I have discovered which code seems to be responsible for the translation: /* * Check for backspace key using termios VERASE - the terminfo * kbs entry is extremely unreliable, so cannot be safely * used. termios should have a better idea. */ bspace = tty->tio.c_cc[VERASE]; if (bspace != _POSIX_VDISABLE && key == bspace) key = KEYC_BSPACE; in cvs/src/external/bsd/tmux/dist/tty-keys.c. Note that KEYC_BSPACE is '\177' or ASCII DEL, not backspace. > --steffen -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpjgA7pgQ3hU.pgp Description: PGP signature
