Re: Switch from legacy ata(4) to CAM-based ATA
On 21.04.2011 13:26, Alexander Motin wrote: Marius Strobl wrote: On Wed, Apr 20, 2011 at 12:57:47PM +0300, Alexander Motin wrote: With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch Could you please add descriptions of the controllers supported by ahci(4), mvs(4) and siis(4) to the kernel configuration files and preserve alphabetical ordering, i.e. list ata(4) after ahci(4)? OK. Here is the new patch: http://people.freebsd.org/~mav/ata_switch2.patch Patch committed. Welcome to the new world! :) -- Alexander Motin ___ 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: panic: g_eli_key_hold: sc_ekeys_total=1
Fabian Keil wrote:
> With sources from today my system panics at boot time
> after attaching the swap device:
>
> GEOM_ELI: Device ada0s1b.eli created.
> GEOM_ELI: Encryption: AES-XTS 256
> GEOM_ELI: Crypto: software
> panic: g_eli_key_hold: sc_ekeys_total=1
> cpuid = 0
> KDB: enter: panic
> Uptime: 2m16s
> Physical memory: 1974 MB
> Dumping 213 MB: 198 182 166 150 134 118 102 86 70 54 38 22 6
>
> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
> /boot/kernel/zfs.ko.symbols...done.
> done.
> [...]
> Loaded symbols for /boot/kernel/acpi_ibm.ko
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250
> 250 if (textdump_pending)
> (kgdb) where
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:250
> #1 0x805354f7 in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:418
> #2 0x80534f91 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:591
> #3 0x811acab2 in g_eli_key_hold (sc=0xfe0005c33400, offset=0,
> blocksize=Variable "blocksize" is not available.
> ) at
> /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_key_cache.c:266
> #4 0x811acdbc in g_eli_crypto_run (wr=0xfe0005cc3a80,
> bp=0xfe0005b9f0e8) at
> /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_privacy.c:317
> #5 0x811a5301 in g_eli_worker (arg=Variable "arg" is not available.
> ) at /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli.c:519
> #6 0x80509845 in fork_exit (callout=0x811a4f20
> , arg=0xfe0005cc3a80, frame=0xff80e68d5c50) at
> /usr/src/sys/kern/kern_fork.c:920
> #7 0x807bd67e in fork_trampoline () at
> /usr/src/sys/amd64/amd64/exception.S:603
> [...]
> (kgdb) f 3
> #3 0x811acab2 in g_eli_key_hold (sc=0xfe0005c33400, offset=0,
> blocksize=Variable "blocksize" is not available.
> ) at
> /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_key_cache.c:266
> 266 KASSERT(sc->sc_ekeys_total > 1, ("%s: sc_ekeys_total=%ju",
> __func__,
> (kgdb) p *sc
> $1 = {sc_geom = 0xfe00028a1000, sc_crypto = 2,
> sc_mkey = "[scrubbed]", sc_ekey = '\0' , sc_ekeys_queue =
> {tqh_first = 0xfe0005c2b380, tqh_last = 0xfe0005c2b3d0},
> sc_ekeys_tree = {rbh_root = 0xfe0005c2b380}, sc_ekeys_lock =
> {lock_object = {lo_name = 0x811adf38 "geli:ekeys", lo_flags =
> 16973824, lo_data = 0, lo_witness = 0x0},
> mtx_lock = 4}, sc_ekeys_total = 1, sc_ekeys_allocated = 1, sc_ealgo = 22,
> sc_ekeylen = 256,
> sc_akey = "[scrubbed]", sc_aalgo = 0, sc_akeylen = 0, sc_alen = 0,
> sc_akeyctx = {state = {0, 0, 0, 0, 0, 0, 0,
> 0}, bitcount = 0, buffer = '\0' },
> sc_ivkey = "[scrubbed]", sc_ivctx = {state = {0, 0, 0, 0, 0, 0, 0, 0},
> bitcount = 0, buffer = '\0' }, sc_nkey = -1, sc_flags =
> 13, sc_inflight = 1, sc_mediasize = 2147483648, sc_sectorsize = 4096,
> sc_bytes_per_sector = 0,
> sc_data_per_sector = 0, sc_queue = {queue = {tqh_first = 0x0, tqh_last =
> 0xfe0005c336a8}, last_offset = 2147479552, insert_point = 0x0},
> sc_queue_mtx = {lock_object = {
> lo_name = 0x811adf2d "geli:queue", lo_flags = 16973824, lo_data
> = 0, lo_witness = 0x0}, mtx_lock = 4}, sc_workers = {lh_first =
> 0xfe0005cc3a40}}
>
> Before the panic, the geli provider (AES-CBC 128) for the ZFS pool
> is attached without issues. Attaching geli providers located on
> USB disks doesn't seem to cause issues either, and I haven't
> been able to reproduce the panic by manually running:
>
> /sbin/geli onetime -l 256 /dev/ada0s1b
> swapon /dev/ada0s1b.eli
Which of course isn't the sector size normally
used for the swap device.
The panic can be reproduced with:
/sbin/geli onetime -l 256 -s 4096 /dev/ada0s1b
Fabian
signature.asc
Description: PGP signature
Re: xterm termcape :ti@:te@:
On Sun, Apr 24, 2011 at 02:57:11PM +0900, Randy Bush wrote: > i know i a perverted, but i really prefer not to have ca_mode. i.e. > prior to 9, i had this little patch > > *** termcap.FCS Tue Jun 17 15:10:46 2003 > --- termcap Tue Jun 17 15:14:15 2003 > *** > *** 299,305 > adm3|3|lsi adm3:\ > :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: > xterm|xterm-color|X11 terminal emulator:\ > ! :ti@:te@:tc=xterm-xfree86: > # > # DESCRIPTION: > # This file describes capabilities of various terminals, as needed by > --- 299,305 > adm3|3|lsi adm3:\ > :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: > xterm|xterm-color|X11 terminal emulator:\ > ! :tc=xterm-xfree86: > # > # DESCRIPTION: > # This file describes capabilities of various terminals, as needed by > > which no longer works. > > what is the simplest way to accomplish this? thanks. With xterm? (that's a resource setting, also available as a menu entry) Or something else that you're using that termcap entry for? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpjSHqHUUyrj.pgp Description: PGP signature
Re: xterm termcape :ti@:te@:
> With xterm? yep > (that's a resource setting, also available as a menu entry) the menu "Enable Alternate Screen Switching" seems to do nothing toggled either way. could you whack me with the resource name? randy ___ 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: panic: g_eli_key_hold: sc_ekeys_total=1
On Sun, Apr 24, 2011 at 11:12:03AM +0200, Fabian Keil wrote: > The panic can be reproduced with: > /sbin/geli onetime -l 256 -s 4096 /dev/ada0s1b That's why I asked for ada0s1b size. It should be fixed in HEAD (r220984). -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpAuN5zvAX8k.pgp Description: PGP signature
"No such file or directory" in daily setuid checks
Hi, I'm running a fairly recent -CURRENT on a new storage machine: kaos % uname -a FreeBSD kaos 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Apr 16 06:39:04 EDT 2011 root@kaos:/usr/obj/usr/src/sys/GENERIC amd64 I'm using ZFS v28 with dedup (thank you, pjd!) on an NFS-exported dataset, to which I backup another machine using rsnapshot: kaos % zpool list NAMESIZE ALLOC FREECAP DEDUP HEALTH ALTROOT zroot 2.70T 28.9G 2.67T 1% 11.80x ONLINE - kaos % zfs get dedup zroot/usr/backup NAME PROPERTY VALUE SOURCE zroot/usr/backup dedup sha256,verify local kaos % showmount -e Exports list on localhost: /usr/backup192.168.1.0 I've been seeing the following in my daily periodic emails: Checking setuid files and devices: find: /usr/backup/hourly.14/orion: No such file or directory find: /usr/backup/hourly.14: No such file or directory find: /usr/backup/hourly.15/orion: No such file or directory find: /usr/backup/hourly.15: No such file or directory [...] Files/directories do exist, however: kaos % ll /usr/backup/hourly.14/orion/usr/ total 4 drwxr-xr-x 5 root wheel 5 Apr 23 17:01 home drwxr-xr-x 4 root wheel 5 Apr 23 17:01 local kaos % ls /usr/backup/hourly.14/orion/usr/home/gjb/ | wc -l 82 The UID for my primary logon has changed between these two machines, so I do expect to see output from the weekly 340.noid check, but I'm not sure what to make of the 'No such file or directory' output in the daily emails. If it matters, the machine that is backing up to the NFS dataset is running 8-STABLE: orion % uname -a FreeBSD orion 8.2-STABLE FreeBSD 8.2-STABLE #9 r219355: Sun Mar 6 19:31:45 EST 2011 root@orion:/usr/obj/usr/src/sys/ORION amd64 I'm not sure if this is ZFS or NFS related, and I'm not entirely sure where to begin looking. Any ideas? Regards, -- Glen Barber ___ 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: xterm termcape :ti@:te@:
On Sun, Apr 24, 2011 at 07:30:12PM +0900, Randy Bush wrote: > > With xterm? > > yep What does the included termcap for xterm-xfree86 look like? Just to refresh my memory, I'm looking at the code, and see that titeInhibit applies to each of the controls that would switch between normal/alternate screens. But the older (47) code would clear the screen, unlike the "newer" (1049) code. > > (that's a resource setting, also available as a menu entry) > > the menu "Enable Alternate Screen Switching" seems to do nothing toggled > either way. odd - even if you were using an application that uses the terminfo entry rather than the modified termcap, that should prevent the screen-switching. > could you whack me with the resource name? That's titeInhibit What does "xterm -v" say? (I'm not aware that anyone has patched xterm to disable the feature; I revised it more than ten years ago, though it's been ignored by all of the "xterm emulators"...). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpQth2edyY6z.pgp Description: PGP signature
Re: xterm termcape :ti@:te@:
> What does the included termcap for xterm-xfree86 look like? xterm-new|modern xterm:\ :@7=\EOF:@8=\EOM:F1=\E[23~:F2=\E[24~:K2=\EOE:Km=\E[M:\ :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:\ :k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:kI=\E[2~:\ :kN=\E[6~:kP=\E[5~:kd=\EOB:kh=\EOH:kl=\EOD:kr=\EOC:ku=\EOA:\ :tc=xterm-basic: xterm-basic|modern xterm common:\ :am:bs:km:mi:ms:ut:xn:AX:\ :Co#8:co#80:kn#12:li#24:pa#64:\ :AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:\ :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=\E(B:al=\E[L:\ :as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\ :cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:\ :ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:\ :kD=\E[3~:kb=^H:ke=\E[?1l\E>:ks=\E[?1h\E=:le=^H:md=\E[1m:\ :me=\E[m:ml=\El:mr=\E[7m:mu=\Em:nd=\E[C:op=\E[39;49m:\ :rc=\E8:rs=\E[!p\E[?3;4l\E[4l\E>:sc=\E7:se=\E[27m:sf=^J:\ :so=\E[7m:sr=\EM:st=\EH:\ :ue=\E[24m:up=\E[A:us=\E[4m:ve=\E[?12l\E[?25h:vi=\E[?25l:vs=\E[?12;25h: xterm-xfree86|xterm terminal emulator (XFree86):\ :tc=xterm-new: > odd - even if you were using an application that uses the terminfo > entry rather than the modified termcap, that should prevent the > screen-switching. i test with less > What does "xterm -v" say? no xterm on the remote sys. the local sys is macosx snow leopard, and % xterm -v XTerm(251) note that my ti@:te@: hack works when the remote sys is 7-stable or releng_8. it's just 9-current randy ___ 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: panic: g_eli_key_hold: sc_ekeys_total=1
Fabian Keil wrote: > Fabian Keil wrote: > > > With sources from today my system panics at boot time > > after attaching the swap device: > > > > GEOM_ELI: Device ada0s1b.eli created. > > GEOM_ELI: Encryption: AES-XTS 256 > > GEOM_ELI: Crypto: software > > panic: g_eli_key_hold: sc_ekeys_total=1 > > cpuid = 0 > > KDB: enter: panic > > Uptime: 2m16s > > Physical memory: 1974 MB > > Dumping 213 MB: 198 182 166 150 134 118 102 86 70 54 38 22 6 > > Before the panic, the geli provider (AES-CBC 128) for the ZFS pool > > is attached without issues. Attaching geli providers located on > > USB disks doesn't seem to cause issues either, and I haven't > > been able to reproduce the panic by manually running: > > > > /sbin/geli onetime -l 256 /dev/ada0s1b > > swapon /dev/ada0s1b.eli > > Which of course isn't the sector size normally > used for the swap device. > > The panic can be reproduced with: > /sbin/geli onetime -l 256 -s 4096 /dev/ada0s1b Somehow http://lists.freebsd.org/pipermail/freebsd-current/2011-April/024199.html and http://lists.freebsd.org/pipermail/freebsd-current/2011-April/024210.html haven't reached me. fk@r500 ~ $diskinfo -v /dev/ada0s1b /dev/ada0s1b 512 # sectorsize 2147483648 # mediasize in bytes (2.0G) 4194304 # mediasize in sectors 0 # stripesize 1073782272 # stripeoffset 4161# Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. 090509FB2F32LLEY6D8A# Disk ident. It is indeed fixed in r220984. Thanks, Pawel. Fabian signature.asc Description: PGP signature
Re: xterm termcape :ti@:te@:
On Sun, Apr 24, 2011 at 10:23:43PM +0900, Randy Bush wrote: > > What does the included termcap for xterm-xfree86 look like? > > xterm-new|modern xterm:\ ... looks ok - no hidden "ti" or "te" capabilities lurking in that. > > odd - even if you were using an application that uses the terminfo > > entry rather than the modified termcap, that should prevent the > > screen-switching. > > i test with less normally I test with ded (using ncurses and terminfo). But "less" behaves consistently (referring to the testing mentioned below). > > What does "xterm -v" say? > > no xterm on the remote sys. the local sys is macosx snow leopard, and > > % xterm -v > XTerm(251) Actually, I "have" that in my current configuration, but don't use it (their insistence on using the option/command buttons in the "emulate three-button mouse" rather than shift is cumbersome). So (except for testing), I use my compiled #269 (with the toolbar). However... the menu-entry seems to work for me here, testing with the bundled #251. > note that my ti@:te@: hack works when the remote sys is 7-stable or > releng_8. it's just 9-current I don't have 9-current (8.1 is here, as a VM). But I'm puzzled: if you were reporting the reverse case (expecting alternate screen-switching to occur), it would be good to collect a typescript from "script" and verify if the control sequences were sent. But this doesn't offer that possibility since it's doing a function that the menu entry itself should prevent. While it's possible to have conflicting resource-settings, the menu entry isn't affected by that (discarding another possibility). If I saw something like this first-hand, I'd compile a copy of xterm to compare (and look at its debugging trace). My local compiles on Mac OS X are only x86_64 so far - -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp20sbr4w8dk.pgp Description: PGP signature
Re: Heads Up: default NFS server changing to the new one
On 04/24/11 02:00, Rick Macklem wrote: There will soon be a commit to head that will change the default NFS server to the new one that was called the experimental NFS server (but no longer experimental). After this commit, you must use "-o" on both mountd and nfsd to force the system to use the old/regular server but, please, try the new server and let me know of problems before you switch back to the old one. Hopefully this will not cause you grief, rick ___ 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" If one would like to build NFS into the kernel, should those people use the "old" options (options NFSCLIENT|options NFSSERVER)? Oliver ___ 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: xterm termcape :ti@:te@:
Randy Bush wrote: > i know i a perverted, but i really prefer not to have ca_mode. i.e. > prior to 9, i had this little patch Are you trying to stop the irritating linux-like screen swapping? I couldn't make termcap play nicely. In the end I put the following in wy .Xresources: XTerm*titeInhibit: true urxvt*secondaryScreen: false Ian -- Ian Freislich ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Apr 23, 2011, at 10:36 AM, sth...@nethelp.no wrote: >> In other words, "ada" isn't the problem here, it's that we all still think >> in terms of the 1980's when systems didn't autoconfigure and device names >> were important hints to system functionality. That time has thankfully >> passed, and it's time for us to catch up. > > If this is important for disk type devices, why not also for network > type devices? Why don't we all use ethX like Linux does? I'd really like to see that as well, but there were strong disagreements when I floated the idea 4 years ago. > Personally I *like* knowing something about the underlying type of > device and technology - but I can definitely see both sides of the > argument here. > Indeed, there's nothing wrong with preserving access to the system details for the use of administration, troubleshooting, and even mere geeky knowledge. This isn't about taking power away from the superusers, it's about making the system smart enough to handle common situations reliably. I'm sure that there some among us who pine for the good old days of manually configuring and linking a kernel, but it's hard to argue that an auto-configured kernel isn't pretty darn convenient most of the time. What I'm proposing is just the next step in that process. Scott___ 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: Heads Up: default NFS server changing to the new one
> On 04/24/11 02:00, Rick Macklem wrote: > > There will soon be a commit to head that will change the > > default NFS server to the new one that was called the > > experimental NFS server (but no longer experimental). After > > this commit, you must use "-o" on both mountd and nfsd to > > force the system to use the old/regular server but, please, > > try the new server and let me know of problems before you > > switch back to the old one. > > > > Hopefully this will not cause you grief, rick > > ___ > > 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" > > If one would like to build NFS into the kernel, should those people > use > the "old" options (options NFSCLIENT|options NFSSERVER)? > If you are going with the default/new server, the option is NFSD. I haven't yet switched over the client (it still needs some commits related to diskless root, etc), but the option for it is NFSCL. (When it gets time to switch the client, I plan on posting to see if others think the default kernel configs should change. Personally, I'd wait until both have been switched and the dust settles to the point where it seems there is no need to switch back.) rick ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Sun, Apr 24, 2011 at 1:54 PM, Scott Long wrote: > Indeed, there's nothing wrong with preserving access to the system details > for the use of administration, troubleshooting, and even mere geeky > knowledge. This isn't about taking power away from the superusers, it's > about making the system smart enough to handle common situations reliably. > I'm sure that there some among us who pine for the good old days of manually > configuring and linking a kernel, but it's hard to argue that an > auto-configured kernel isn't pretty darn convenient most of the time. What > I'm proposing is just the next step in that process. > For me, your proposal would make life more difficult as it is on Linux. I've had to do more deployment/autoconfig setups recently and FreeBSD's method of device naming makes it much easier for me to deal with. I like the fact I easily know what disk is attached to what controller and what NIC driver is in use. The NIC specific naming is more useful than disk controller, but both have their places for me. It makes tweaking/troubleshooting quicker in some situations. In fact, I would like even more of it it, eg /dev/usbda0. What a disk is called is already different(for me) than what is in fstab since some(maybe many?) people are already using some of the abstraction methods currently available. If a sys-admin makes an effort, a consistent fstab is pretty easily achieved but it's better done by pre-deployment planning rather than after. If one of the new installer proposals handled this automatically, even better. My point is that device names are still an important hint to functionality particularly for auto-deployment/configure settings where specific hardware isn't always known ahead of time. -- Adam Vande More ___ 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: xterm termcape :ti@:te@:
>> i know i a perverted, but i really prefer not to have ca_mode. i.e. >> prior to 9, i had this little patch > Are you trying to stop the irritating linux-like screen swapping? don't know linux, but i want to exit more et alia and have my screen restored. sounds like i am the opposite of you. > I couldn't make termcap play nicely. i could up to 9-current. termcap changed bigtime in 9. but something else changed too. it's as if tite has been excised from the code. > In the end I put the following in wy .Xresources: > XTerm*titeInhibit: true > urxvt*secondaryScreen: false no workie (with settings flipped) randy ___ 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: xterm termcape :ti@:te@:
Randy Bush writes: > i know i a perverted, but i really prefer not to have ca_mode. i.e. Not to? But the patch makes the opposite effect. > prior to 9, i had this little patch > > *** termcap.FCS Tue Jun 17 15:10:46 2003 > --- termcap Tue Jun 17 15:14:15 2003 > *** > *** 299,305 > adm3|3|lsi adm3:\ > :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: > xterm|xterm-color|X11 terminal emulator:\ > ! :ti@:te@:tc=xterm-xfree86: > # > # DESCRIPTION: > # This file describes capabilities of various terminals, as needed by > --- 299,305 > adm3|3|lsi adm3:\ > :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: > xterm|xterm-color|X11 terminal emulator:\ > ! :tc=xterm-xfree86: > # > # DESCRIPTION: > # This file describes capabilities of various terminals, as needed by > > which no longer works. Use FreeBSD-specific `xterm-clear' termcap record, e.g. $ xterm -xrm 'XTerm.termName: xterm-clear' # or add to ~/.Xdefaults or alter xterm alias to point to it so that ca_mode works even if you ssh to Linux box that doesn't have the record. %% Index: share/termcap/termcap.src === --- share/termcap/termcap.src (revision 220998) +++ share/termcap/termcap.src (working copy) @@ -3011,7 +3011,7 @@ # is widely used for a variety of incompatible terminal emulations including # color_xterm and rxvt. xterm|X11 terminal emulator:\ - :tc=xterm-new: + :tc=xterm-clear: # :tc=xterm-r6: # dtterm termcap entry - Obtained from Xinside's CDE with permission # from Thomas Roell %% ___ 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: xterm termcape :ti@:te@:
>> i know i a perverted, but i really prefer not to have ca_mode. i.e. > Not to? But the patch makes the opposite effect. sorry. my bad. > Use FreeBSD-specific `xterm-clear' termcap record, e.g. > > $ xterm -xrm 'XTerm.termName: xterm-clear' # or add to ~/.Xdefaults > > or alter xterm alias to point to it so that ca_mode works even if you > ssh to Linux box that doesn't have the record. > > %% > Index: share/termcap/termcap.src > === > --- share/termcap/termcap.src (revision 220998) > +++ share/termcap/termcap.src (working copy) > @@ -3011,7 +3011,7 @@ > # is widely used for a variety of incompatible terminal emulations including > # color_xterm and rxvt. > xterm|X11 terminal emulator:\ > - :tc=xterm-new: > + :tc=xterm-clear: > #:tc=xterm-r6: > # dtterm termcap entry - Obtained from Xinside's CDE with permission > # from Thomas Roell > %% not working on 9. ___ 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: xterm termcape :ti@:te@:
On Sun, Apr 24, 2011 at 06:26:34PM -0400, Thomas Dickey wrote: > On Mon, Apr 25, 2011 at 01:04:56AM +0400, Pan Tsu wrote: > > Randy Bush writes: > > > > > i know i a perverted, but i really prefer not to have ca_mode. i.e. > > > > Not to? But the patch makes the opposite effect. > > hmm - I've seen this sort of question often enough that I read it offhand > as did someone last August - that Randy wants to cancel the alternate > screen mode: > > http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019100.html > > (I don't know what ca_mode might be, either) Googling further finds that referenced in a comment pointing to the termcap manual, which refers to the terminfo names "enter_ca_mode" and "exit_ca_mode". In that context, "ca" refers to cursor-addressing, which is only related to titeInhibit since the strings happen to be where xterm's alternate-screen controls are usually put. bye -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpNQ95vrkm1S.pgp Description: PGP signature
Re: xterm termcape :ti@:te@:
On Mon, Apr 25, 2011 at 01:04:56AM +0400, Pan Tsu wrote: > Randy Bush writes: > > > i know i a perverted, but i really prefer not to have ca_mode. i.e. > > Not to? But the patch makes the opposite effect. hmm - I've seen this sort of question often enough that I read it offhand as did someone last August - that Randy wants to cancel the alternate screen mode: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019100.html (I don't know what ca_mode might be, either) But given your comment, and looking again at the patch, I notice that the chunk without the cancels has the later timestamp: > > prior to 9, i had this little patch > > > > *** termcap.FCS Tue Jun 17 15:10:46 2003 > > --- termcap Tue Jun 17 15:14:15 2003 > > *** > > *** 299,305 > > adm3|3|lsi adm3:\ > > :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: > > xterm|xterm-color|X11 terminal emulator:\ > > ! :ti@:te@:tc=xterm-xfree86: > > # > > # DESCRIPTION: > > # This file describes capabilities of various terminals, as needed by > > --- 299,305 > > adm3|3|lsi adm3:\ > > :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: > > xterm|xterm-color|X11 terminal emulator:\ > > ! :tc=xterm-xfree86: > > # > > # DESCRIPTION: > > # This file describes capabilities of various terminals, as needed by > > > > which no longer works. Perhaps he wants to _have_ the alternate screen, which as I noted is not present in the "xterm-xfree86" entry. Then that would make the desired line :ti=\E[?1049h:te=\E[?1049l:tc=xterm-xfree86: or :ti=\E[?1049h:te=\E[?1049l:tc=xterm-new: Setting the titeInhibit resource cancels those 1049's, but unsetting it doesn't add them. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpHgm1uGlaui.pgp Description: PGP signature
Re: xterm termcape :ti@:te@:
Thomas Dickey writes: [...] > Setting the titeInhibit resource cancels those 1049's, but unsetting > it doesn't add them. xterm-basic in /head doesn't define ti/te capabilities anymore per r200503. So, there is no more need to hide them via `@', e.g. `:ti@:te@:' in `xterm'. $ getcap -c ti -f /etc/termcap xterm-basic || tset -S xterm-basic | sed 'y/:/\n/' | fgrep ti It was probably too minor of an issue to be mentioned in UPDATING. ___ 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: xterm termcape :ti@:te@:
no help from the following: *** termcap~Fri Mar 18 14:34:01 2011 --- termcap Sun Apr 24 23:33:52 2011 *** *** 3131,3136 --- 3131,3137 # # Customization begins here. xterm-xfree86|xterm terminal emulator (XFree86):\ + :te=\E[?1049l:ti=\E[?1049h:\ :tc=xterm-new: # # This is the only entry which you should have to customize, since "xterm" ___ 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: xterm termcape :ti@:te@:
On Mon, Apr 25, 2011 at 08:37:05AM +0900, Randy Bush wrote: > no help from the following: > > *** termcap~Fri Mar 18 14:34:01 2011 > --- termcap Sun Apr 24 23:33:52 2011 > *** > *** 3131,3136 > --- 3131,3137 > # > # Customization begins here. > xterm-xfree86|xterm terminal emulator (XFree86):\ > + :te=\E[?1049l:ti=\E[?1049h:\ > :tc=xterm-new: At this point, I'd check if less is using that entry (ktrace or truss should be able to show the open's on the termcap database, for instance). Also, I seem to recall some discussion about less' -X (--no-init) option. It's possible that someone's patched "less" for FreeBSD to make that -X option more or less permanent. That would be consistent with omitting ti/te from the termcap. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpZTyjlnTPvI.pgp Description: PGP signature
Re: Switch from legacy ata(4) to CAM-based ATA
Hi, On Sun, Apr 24, 2011 at 5:04 AM, Alexander Motin wrote: > Patch committed. Welcome to the new world! :) > What transition plan do you provide ? Drop in single-user-mode and fix /etc/fstab ? Forbid anybody without ATA_CAM in their 8.x config to be able to switch between 8 and 9 ? Thanks, - Arnaud ___ 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: Switch from legacy ata(4) to CAM-based ATA
Hi, On Thu, Apr 21, 2011 at 3:51 AM, Bjoern A. Zeeb wrote: > [...] > > I agree that we need to catch up with something but we should have done so a > year ago. > > a) we MUST HAVE a transition scheme if we cam-base ATA by default. Something > that converts things automatically to whatever? That's not been done in more > than one year. It's not acceptable to update, reboot and not find the root > file system no matter what. We all agreed on that back then. I do not > really care how it's done. > I have been testing cam based ata for a while now on the machines I can cope > with as a developer and even then I screwed the transition partly two times > in the last months. How's a normal user to do that flawlessly? > For the record, it would seem that Alexander did not provide any follow-up to this message, but still decided to go forward. I would be interested to have his answer to your question. Thanks, - Arnaud > b) FYI: labels and stacked geoms do not work well together as you can never > detach providers cleanly then, which basically means you are at risk of data > loss with every reboot. I was told multiple times that this is not fixable. > If it is labels seem to be a great why to go. For now I have to compile them > out/disable them unfortunately so they are not an option, and they'll be less > so if the new installer also offers gmirror, geli, ... installs. > > Give me a solution that works out of the box and I'll happily agree that we > switch. > FWIW, so do I. > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. > > ___ > 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"
