laptop freezes when starting X
Hello, community After updating to r278893 my thinkpad e530 (Ivy bridge) freezes when starting X after few seconds. There is no any such issues with my previos kernel r278308. Both Xorg.0.log and messages doesn't have any new error records. Changing hw.x2apic_enable does not make any difference. ___ 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: URGENT: RNG broken for last 4 months
John-Mark Gurney j...@funkthat.com wrote: Oliver Pinter wrote this message on Tue, Feb 17, 2015 at 23:27 +0100: On Tue, Feb 17, 2015 at 11:19 PM, Fabian Keil freebsd-lis...@fabiankeil.de wrote: John-Mark Gurney j...@funkthat.com wrote: If you are running a current kernel r273872 or later, please upgrade your kernel to r278907 or later immediately and regenerate keys. I tried ... start_init: trying /sbin/init 118[20] Setting hostuuid: [...] 118[20] Setting hostid: [... [20] [20] [20] Fatal trap 12: page fault while in kernel mode [...] So, this should now be fixed w/: Committed revision 278927. Works for me. Thanks. Fabian pgp_5WOGke3Xn.pgp Description: OpenPGP digital signature
ufs/devfs lock order reversal on poweroff
Hi On r278909 (and probably earlier) I get the following when I run poweroff (retyped from a video of it I had to record, since it disappears very quickly): Syncing disks, vnodes remaining...4 1 0 0 done All buffers synced. lock order reversal: 1st 0xf80014d4d060 ufs (ufs) 0 /usr/src/sys/kern/vfs_mount.c:1229 2nd 0xf00014a695f0 devfs (devfs) 0 /usr/src/sys/kern/vfs_subr.c:2176 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame ... witness_checkorder() at witness_checkorder+... __lockmgr_args() at __lockmgr_args+... vop_stdlock() at vop_stdlock+0x3c/frame .. VOP_LOOCK1_AVP() _vm_lock() vget() devfs_allocv() devfs_root() dounmount() vfs_unmountall() kern_reboot() sys_reboot() amd64_syscall() Xfast_syscall() --- syscall (55, FreeBSD ELF64, sys_reboot), ript = 0x40fd1c, rsp = ..., rbp= ... Uptime: ... Thank you Damjan ___ 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: [Call for testers] DRM device-independent code update to Linux 3.8
On Wed, Feb 18, 2015 at 12:09 AM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: Hi Good job! Will do some testing! As for the i915 driver, what versions are supported? Up until and including HD4000 Gen7 Ivy bridge? -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Wed, Feb 18, 2015 at 8:45 AM, Jean-Sébastien Pédron dumbb...@freebsd.org wrote: Hi! An update to the DRM subsystem, not including the drivers, is ready for wider testing! The patch against HEAD is here: https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch I'm interested in success/failure reports for amd64, powerpc and powerpc64 users, for i915 and Radeon GPUs. I already know there is a build issue on i386, please wait for the next patch if you are in this case. The changes brought by this patch are explained in a blog post: http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/ This is working well for some Radeon users for more than a year. However, it only started to work with i915 a month ago, when the i915 refresh was committed. Try your day-to-day applications, try suspend/resume, try all output connectors, try OpenGL stuff, try backlight controls, everything :) Testing suspend/resume by closing/opening the LID works for me but I did get this: lock order reversal: 1st 0xfee1c728 ath0 (ath0) @ /usr/src/sys/dev/ath/if_ath.c:6654 2nd 0xfefc1838 ath0_node_lock (ath0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1824 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0115c71790 witness_checkorder() at witness_checkorder+0xe45/frame 0xfe0115c71820 __mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfe0115c71870 ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x52/frame 0xfe0115c718c0 node_free() at node_free+0x25/frame 0xfe0115c718e0 ieee80211_tx_complete() at ieee80211_tx_complete+0x2c/frame 0xfe0115c71900 ath_tx_draintxq() at ath_tx_draintxq+0x22/frame 0xfe0115c71930 ath_edma_tx_drain() at ath_edma_tx_drain+0x10d/frame 0xfe0115c71970 ath_stop_locked() at ath_stop_locked+0x148/frame 0xfe0115c719a0 ath_ioctl() at ath_ioctl+0x223/frame 0xfe0115c719e0 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfe0115c71a40 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfe0115c71a70 fork_exit() at fork_exit+0x84/frame 0xfe0115c71ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0115c71ab0 --- trap 0, rip = 0, rsp = 0xfe0115c71b70, rbp = 0 --- So something fails in the ath side, which I'm guesssing I should report to the wireless list? As for backlight I still have no control of that, unless I use intel_backlight or the patch proposed a while back which adds hw.dri.0.i915_backlight The latptop I just tested is an Acer S3-391 Ivy Bridge and I only have the single card (I have another with dual graphics that I'll test later) the hardware keys for backlight control in this one are Fn-Left/Right Arrow. Thank you! -- Jean-Sébastien Pédron -- ___ 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: ufs/devfs lock order reversal on poweroff
On Wed, Feb 18, 2015 at 9:53 AM, Damjan Jovanovic damjan@gmail.com wrote: Hi On r278909 (and probably earlier) I get the following when I run poweroff (retyped from a video of it I had to record, since it disappears very quickly): Hi Damjan, This is a known LOR. Thanks! ___ 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: [Call for testers] DRM device-independent code update to Linux 3.8
On Wednesday, February 18, 2015 12:45:36 AM Jean-Sébastien Pédron wrote: Hi! An update to the DRM subsystem, not including the drivers, is ready for wider testing! The patch against HEAD is here: https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch I'm interested in success/failure reports for amd64, powerpc and powerpc64 users, for i915 and Radeon GPUs. I already know there is a build issue on i386, please wait for the next patch if you are in this case. The changes brought by this patch are explained in a blog post: http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/ This is working well for some Radeon users for more than a year. However, it only started to work with i915 a month ago, when the i915 refresh was committed. Try your day-to-day applications, try suspend/resume, try all output connectors, try OpenGL stuff, try backlight controls, everything :) Thank you! The patch drastically fails to apply on recent HEAD. Thanks, Shawn signature.asc Description: This is a digitally signed message part.
Re: [Call for testers] DRM device-independent code update to Linux 3.8
On Wed, Feb 18, 2015 at 12:45:36AM +0100, Jean-Sébastien Pédron wrote: Hi! An update to the DRM subsystem, not including the drivers, is ready for wider testing! The patch against HEAD is here: https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch Have you looked into using a MTX_SPIN lock where Linux actually employs a DRM_SPINTYPE one? That should allow to use a filter instead of an ithread handler, solving a great number of problems with pre-loading of DRM drivers and allow them to be statically compiled into the kernel as - unlike ihtreads - filters work right from the moment they are set up during attach. In turn, that would make the lack of a VESA driver for vt(4) less painful and likely even forgivable, as resolutions higher than VGA could be used way earlier, etc. Marius ___ 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
Build failed in Jenkins: FreeBSD_HEAD #2408
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2408/changes Changes: [gjb] Fix a grammar nit. Sponsored by: The FreeBSD Foundation [markj] Remove unnecessary checks for a return value of NULL from M_WAITOK allocations. MFC after: 3 days [markj] Free the zlib stream after expanding a compressed CTF section. Note that this memory would only be leaked once, since CTF info for a kld file is cached after the first access. MFC after: 3 days [jmg] fix spelling, add comma and remove BUGS section.. it provided no useful information, and is not really bugs, but limitations for other reasons... [glebius] Use new struct mbufq instead of struct ifqueue to manage packet queues in IPv6 multicast code. Sponsored by: Netflix Sponsored by: Nginx, Inc. [glebius] Use new struct mbufq instead of struct ifqueue to manage packet queues in IPv4 multicast code. Sponsored by: Netflix Sponsored by: Nginx, Inc. [glebius] Provide a set of inline functions to manage simple mbuf(9) queues, based on queue(3)'s STAILQ. Utilize them in cxgb(4) and Xen, deleting home grown implementations. Sponsored by: Netflix Sponsored by: Nginx, Inc. -- [...truncated 76151 lines...] --- inet_ntop.So --- cc -fpic -DPIC -O2 -pipe -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/gdtoa -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/libc-vis -DINET6 -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/lib/libc -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../libmd -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/jemalloc/include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/tzcode/stdtime -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/stdtime -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ ws/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/inet/inet_ntop.c -o inet_ntop.So --- inet_pton.So --- cc -fpic -DPIC -O2 -pipe -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/gdtoa -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/libc-vis -DINET6 -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/lib/libc -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../libmd -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/jemalloc/include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/tzcode/stdtime -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/stdtime -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ ws/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/inet/inet_pton.c -o inet_pton.So --- nsap_addr.So --- cc -fpic -DPIC -O2 -pipe -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libc/../../contrib/gdtoa
Jenkins build is back to normal : FreeBSD_HEAD #2407
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2407/changes ___ 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: Xen HVM Panic, HEAD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/17/15 12:30, Sean Bruno wrote:
On 02/17/15 12:26, Konstantin Belousov wrote:
On Tue, Feb 17, 2015 at 12:00:04PM -0800, Sean Bruno wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512
On 02/17/15 00:56, Konstantin Belousov wrote:
On Mon, Feb 16, 2015 at 08:10:06PM -0800, Sean Bruno wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512
https://people.freebsd.org/~sbruno/Xen_APIC_panic.png
I suspect that there may be one or two more lines above
this that are relevant to this panic, but XENHVM kernel's
now panic booting on Xen server. The working kernel output
looks like this:
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final
208032) 20140512 XEN: Hypervisor version 4.2 detected.
CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
(2400.05-MHz K8-class CPU) Origin=GenuineIntel
Id=0x206c2 Family=0x6 Model=0x2c Stepping=2
Features=0x1783fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT
Features2=0x81ba2201SSE3,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,HV
AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD
Features2=0x1LAHF Hypervisor: Origin = XenVMMXenVMM
real memory = 1434451968 (1368 MB) avail memory =
1353293824 (1290 MB) Event timer LAPIC quality 400 ACPI
APIC Table: Xen HVM FreeBSD/SMP: Multiprocessor System
Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0
(BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 ioapic0: Changing
APIC ID to 1 MADT: Forcing active-low polarity and level
trigger for SCI
I am not sure why your machine uses native lapic instead of
xen lapic, and should it be other way, or not.
Regardless, show the line number for the ipi_startup+0x56.
Did you performed clean kernel build ?
I have rebuilt a kernel/world based on head at svn r276627. I
have delete /usr/obj completely and started from scratch.
Updated kernelpanic image at
https://people.freebsd.org/~sbruno/Xen_APIC_panic.png
/usr/src/sys/x86/include # kgdb /boot/kernel/kernel GNU gdb
6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are welcome to change it and/or distribute
copies of it under certain conditions. Type show copying to
see the conditions. There is absolutely no warranty for GDB.
Type show warranty for details. This GDB was configured as
amd64-marcel-freebsd... (kgdb) list *(ipi_startup+0x56)
0x80e088c6 is in ipi_startup (apicvar.h:383). 378 379
static inline int 380 lapic_ipi_wait(int delay) 381 { 382 383
return (apic_ops.ipi_wait(delay)); 384 } 385 386 static inline
int 387 lapic_set_lvt_mask(u_int apic_id, u_int lvt, u_char
masked)
Please disassemble your ipi_startup, also please do 'p
*apic_ops'.
(kgdb) disassemble ipi_startup
Dump of assembler code for function ipi_startup: 0x80df3900
ipi_startup+0: push %rbp 0x80df3901
ipi_startup+1: mov%rsp,%rbp 0x80df3904
ipi_startup+4: push %r14 0x80df3906
ipi_startup+6: push %rbx 0x80df3907
ipi_startup+7: mov%esi,%ebx 0x80df3909
ipi_startup+9: mov%edi,%r14d 0x80df390c
ipi_startup+12:mov$0xc500,%edi 0x80df3911
ipi_startup+17:mov%r14d,%esi 0x80df3914
ipi_startup+20:callq *0x815ac428 0x80df391b
ipi_startup+27:mov$0x14,%edi 0x80df3920
ipi_startup+32:callq *0x815ac438 0x80df3927
ipi_startup+39:mov$0x8500,%edi 0x80df392c
ipi_startup+44:mov%r14d,%esi 0x80df392f
ipi_startup+47:callq *0x815ac428 0x80df3936
ipi_startup+54:mov$0x2710,%edi 0x80df393b
ipi_startup+59:callq 0x80f39c10 DELAY
0x80df3940 ipi_startup+64:or $0x4600,%ebx
0x80df3946 ipi_startup+70:movslq %ebx,%rbx
0x80df3949 ipi_startup+73:mov%rbx,%rdi
0x80df394c ipi_startup+76:mov%r14d,%esi
0x80df394f ipi_startup+79:callq *0x815ac428
0x80df3956 ipi_startup+86:mov$0x14,%edi
0x80df395b ipi_startup+91:callq *0x815ac438
0x80df3962 ipi_startup+98:test %eax,%eax
0x80df3964 ipi_startup+100: je 0x80df399b
ipi_startup+155 0x80df3966 ipi_startup+102: mov
$0xc8,%edi 0x80df396b ipi_startup+107: callq
0x80f39c10 DELAY 0x80df3970 ipi_startup+112:
mov%rbx,%rdi 0x80df3973 ipi_startup+115: mov
%r14d,%esi 0x80df3976 ipi_startup+118: callq
*0x815ac428 0x80df397d ipi_startup+125: mov
$0x14,%edi 0x80df3982 ipi_startup+130: callq
*0x815ac438 0x80df3989 ipi_startup+137: test
%eax,%eax 0x80df398b ipi_startup+139: je
0x80df39a4
Re: r278857: buildkernel failure: pf_norm.c:1098:1: error: no previous prototype for function 'pf_refragment6'
Hi, I encountered this issue before. What I did is resync with the source tree again. N recompile world. It solved the issue. Maybe you can try that also ? Sent from my iPhone On 17 Feb 2015, at 1:54 am, O. Hartmann ohart...@zedat.fu-berlin.de wrote: awk -f /usr/src/sys/conf/kmod_syms.awk ng_ksocket.ko export_syms | xargs -J% objcopy % ng_ksocket.ko objcopy --strip-debug ng_ksocket.ko === netgraph/l2tp (all) --- ng_l2tp.o --- cc -O2 -pipe -O3 -O3 -pipe -march=native -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/THOR/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/sys/THOR -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/netgraph/l2tp/../../../netgraph/ng_l2tp.c --- all_subdir_pf --- /usr/src/sys/modules/pf/../../netpfil/pf/pf_norm.c:1098:1: error: no previous prototype for function 'pf_refragment6' [-Werror,-Wmissing-prototypes] pf_refragment6(struct ifnet *ifp, struct mbuf **m0, struct m_tag *mtag) ^ 1 error generated. *** [pf_norm.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/pf 1 error make[4]: stopped in /usr/src/sys/modules/pf *** [all_subdir_pf] Error code 2 ___ 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: default pager (csh)
On 19 Feb 2015, at 02:27, Davide Italiano dav...@freebsd.org wrote: On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall mcdou...@egr.msu.edu wrote: The PAGER was less for about half a year and reverted. Please see: https://svnweb.freebsd.org/base?view=revisionrevision=242643 ___ 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 OK, I think this ends the discussion =) Nope, not good enough. The way I see it we achieved nothing despite the fact that several bugs are on the table. Now that we all agree more(1) is the way to go, can we please fix colouring and the pager quit issue for man pages using sensible options in more(1)? Other's should speak up for their woes with the FreeBSD defaults too. The defaults are supposed to be the best we can do. Right now, we can actually do better. :) Cheers, Franco ___ 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: default pager (csh)
On Wed, Feb 18, 2015 at 10:46 PM, Franco Fichtner fra...@lastsummer.de wrote: On 19 Feb 2015, at 02:27, Davide Italiano dav...@freebsd.org wrote: On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall mcdou...@egr.msu.edu wrote: The PAGER was less for about half a year and reverted. Please see: https://svnweb.freebsd.org/base?view=revisionrevision=242643 ___ 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 OK, I think this ends the discussion =) Nope, not good enough. The way I see it we achieved nothing despite the fact that several bugs are on the table. Now that we all agree more(1) is the way to go, can we please fix colouring and the pager quit issue for man pages using sensible options in more(1)? Other's should speak up for their woes with the FreeBSD defaults too. The defaults are supposed to be the best we can do. Right now, we can actually do better. :) Cheers, Franco I want my bikeshed to be purple with yellow stars. I want my PAGER to be Jim Davis's most(1). Does a LOT more than more or less. (Does have the annoying te/ti thing, though.) Displays binary. Auto-decompresses compressed files. Allows moving my line or percentage. Whole raft of neat stuff. Usually the second port (after portmaster) I install on a system since my finger type most even when I want them to type more because the system does not have most installed. I don't expect anyone else to agree and don't expect it to ever be in the base, let alone the default. Still, it's a much better pager then less, whether it's called more or not. Started using it at least 25 years ago on VMS. -- 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
Re: [Call for testers] DRM device-independent code update to Linux 3.8
Dear Jean, thanks for your work! I built a recent git checkout of the kms38-branch on both a i5-3320M (w/ HD4000) and an AMD FirePro V4900. Works absolutely fine, the only minor issue is that there seemingly is a small performance regression w/ clover. However, I didn't yet have time to dig into this and make sure that indeed something is off. HTH Johannes On Wed, Feb 18, 2015 at 12:45 AM, Jean-Sébastien Pédron dumbb...@freebsd.org wrote: Hi! An update to the DRM subsystem, not including the drivers, is ready for wider testing! The patch against HEAD is here: https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch I'm interested in success/failure reports for amd64, powerpc and powerpc64 users, for i915 and Radeon GPUs. I already know there is a build issue on i386, please wait for the next patch if you are in this case. The changes brought by this patch are explained in a blog post: http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/ This is working well for some Radeon users for more than a year. However, it only started to work with i915 a month ago, when the i915 refresh was committed. Try your day-to-day applications, try suspend/resume, try all output connectors, try OpenGL stuff, try backlight controls, everything :) Thank you! -- Jean-Sébastien Pédron ___ 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: Xen HVM Panic, HEAD
Hi, Since this is the (at least) second round of x2apic support broke me changes, can we please either back them out or set it to default to '0' for now? Thanks, -adrian ___ 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: [Call for testers] DRM device-independent code update to Linux 3.8
2015-02-18 0:45 GMT+01:00 Jean-Sébastien Pédron dumbb...@freebsd.org: Hi! An update to the DRM subsystem, not including the drivers, is ready for wider testing! The patch against HEAD is here: https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch I'm interested in success/failure reports for amd64, powerpc and powerpc64 users, for i915 and Radeon GPUs. I already know there is a build issue on i386, please wait for the next patch if you are in this case. The changes brought by this patch are explained in a blog post: http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/ This is working well for some Radeon users for more than a year. However, it only started to work with i915 a month ago, when the i915 refresh was committed. Try your day-to-day applications, try suspend/resume, try all output connectors, try OpenGL stuff, try backlight controls, everything :) Thank you! -- Jean-Sébastien Pédron Just upgraded my laptop to r278960. Testing the patch I receive these errors: # patch -sC ~/downloads/drm-update-38.f.patch 1 out of 3 hunks failed while patching sys/dev/drm2/drm_agpsupport.c 1 out of 4 hunks failed while patching sys/dev/drm2/drm_auth.c 1 out of 26 hunks failed while patching sys/dev/drm2/drm_bufs.c 1 out of 17 hunks failed while patching sys/dev/drm2/drm_context.c 1 out of 39 hunks failed while patching sys/dev/drm2/drm_crtc.h 1 out of 5 hunks failed while patching sys/dev/drm2/drm_dma.c 1 out of 1 hunks failed while patching sys/dev/drm2/drm_drawable.c 1 out of 8 hunks failed while patching sys/dev/drm2/drm_drv.c 1 out of 5 hunks failed while patching sys/dev/drm2/drm_edid.h 1 out of 17 hunks failed while patching sys/dev/drm2/drm_edid_modes.h 1 out of 7 hunks failed while patching sys/dev/drm2/drm_fb_helper.h 1 out of 9 hunks failed while patching sys/dev/drm2/drm_fops.c 1 out of 3 hunks failed while patching sys/dev/drm2/drm_fourcc.h 1 out of 1 hunks failed while patching sys/dev/drm2/drm_internal.h 1 out of 4 hunks failed while patching sys/dev/drm2/drm_ioctl.c 1 out of 50 hunks failed while patching sys/dev/drm2/drm_irq.c 1 out of 3 hunks failed while patching sys/dev/drm2/drm_lock.c 1 out of 2 hunks failed while patching sys/dev/drm2/drm_memory.c 1 out of 10 hunks failed while patching sys/dev/drm2/drm_mm.h 1 out of 11 hunks failed while patching sys/dev/drm2/drm_mode.h 1 out of 1 hunks failed while patching sys/dev/drm2/drm_sman.c 1 out of 1 hunks failed while patching sys/dev/drm2/drm_sman.h 1 out of 4 hunks failed while patching sys/modules/drm2/radeonkms/Makefile Regards Maurizio ___ 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: laptop freezes when starting X
Hi! * would you mind filing a PR? https://bugs.freebsd.org/submit/ * are you able to test any other kernel versions between those two, just to narrow it down a bit further? Thanks! -a On 18 February 2015 at 02:41, Alexandr Krivulya shur...@shurik.kiev.ua wrote: Hello, community After updating to r278893 my thinkpad e530 (Ivy bridge) freezes when starting X after few seconds. There is no any such issues with my previos kernel r278308. Both Xorg.0.log and messages doesn't have any new error records. Changing hw.x2apic_enable does not make any difference. ___ 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
Build failed in Jenkins: FreeBSD_HEAD #2406
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2406/changes Changes: [jkim] Merge ACPICA 20141107 and 20150204. [grehan] Restore the ability to use clang as an external compiler. This was inadvertently removed when support for external GCC was added. Deprecate XFLAGS in favour of the newer XCFLAGS/XCXXFLAGS. Tested with:make universe, make CROSS_COMPILER_PREFIX=/usr/bin/ buildworld Reviewed by:imp, bapt [ken] Make sure that the flags for the XPT_DEV_ADVINFO CCB are initialized properly. If there is garbage in the flags field, it can sometimes include a set CDAI_FLAG_STORE flag, which may cause either an error or perhaps result in overwriting the field that was intended to be read. sys/cam/cam_ccb.h: Add a new flag to the XPT_DEV_ADVINFO CCB, CDAI_FLAG_NONE, that callers can use to set the flags field when no store is desired. sys/cam/scsi/scsi_enc_ses.c: In ses_setphyspath_callback(), explicitly set the XPT_DEV_ADVINFO flags to CDAI_FLAG_NONE when fetching the physical path information. Instead of ORing in the CDAI_FLAG_STORE flag when storing the physical path, set the flags field to CDAI_FLAG_STORE. sys/cam/scsi/scsi_sa.c: Set the XPT_DEV_ADVINFO flags field to CDAI_FLAG_NONE when fetching extended inquiry information. sys/cam/scsi/scsi_da.c: When storing extended READ CAPACITY information, set the XPT_DEV_ADVINFO flags field to CDAI_FLAG_STORE instead of ORing it into a field that isn't initialized. sys/dev/mpr/mpr_sas.c, sys/dev/mps/mps_sas.c: When fetching extended READ CAPACITY information, set the XPT_DEV_ADVINFO flags field to CDAI_FLAG_NONE instead of setting it to 0. sbin/camcontrol/camcontrol.c: When fetching a device ID, set the XPT_DEV_ADVINFO flags field to CDAI_FLAG_NONE instead of 0. sys/sys/param.h: Bump __FreeBSD_version to 1100061 for the new XPT_DEV_ADVINFO CCB flag, CDAI_FLAG_NONE. Sponsored by: Spectra Logic MFC after: 1 week -- [...truncated 119237 lines...] === usr.sbin/arp (depend) --- usr.bin.depend__D --- --- depend_subdir_chat --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -std=gnu99 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/chat/chat.c echo chat: https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libc.a .depend --- usr.sbin.depend__D --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -std=gnu99 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin/arp/arp.c --- usr.bin.depend__D --- --- depend_subdir_checknr --- === usr.bin/checknr (depend) --- usr.sbin.depend__D --- echo arp: https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libc.a .depend --- usr.bin.depend__D --- --- depend_subdir_chkey --- === usr.bin/chkey (depend) --- depend_subdir_checknr --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -std=gnu99 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/checknr/checknr.c --- depend_subdir_chkey --- --- .depend --- rm -f .depend --- depend_subdir_checknr --- echo checknr: https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libc.a .depend --- depend_subdir_chkey --- CC='cc ' mkdep -f .depend -a -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/chkey/../newkey -DYP -std=gnu99 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/chkey/chkey.c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/chkey/../newkey/generic.c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/chkey/../newkey/update.c --- usr.sbin.depend__D --- --- depend_subdir_asf --- === usr.sbin/asf (depend) --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -std=gnu99 https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin/asf/asf.c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin/asf/asf_kld.c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin/asf/asf_kvm.c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.sbin/asf/asf_prog.c --- usr.bin.depend__D --- echo chkey: https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libc.a https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/librpcsvc.a https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libmp.a .depend --- depend_subdir_chpass --- === usr.bin/chpass (depend) --- usr.sbin.depend__D --- --- depend_subdir_acpi --- echo acpidb: https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libc.a https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libpthread.a .depend === usr.sbin/acpi/acpidump (depend) --- depend_subdir_asf --- echo asf:
default pager (csh)
Hi, one of the first things I do when I install FreeBSD is to switch the default PAGER from more(1) to less(1). This is particularly convenient, e.g. while using git diff, to show something more readable. Just out of curiosity, is there a reason why more(1) is still the default, and/or is this just historical? -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: default pager (csh)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Great quote for the OP on the thread. I for one would be for switching it to ‘less -M’ then it would respect a users wish to use environment variables LESS and LESSPIPE but still carry the traditional behavior. On Feb 18, 2015, at 17:18, Davide Italiano dav...@freebsd.org wrote: Hi, one of the first things I do when I install FreeBSD is to switch the default PAGER from more(1) to less(1). This is particularly convenient, e.g. while using git diff, to show something more readable. Just out of curiosity, is there a reason why more(1) is still the default, and/or is this just historical? - -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org - -- Jason Hellenthal Mobile: +1 (616) 953-0176 jhellent...@dataix.net JJH48-ARIN -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJU5R6bAAoJEDLu+wRc4KcIB8YH+wdyVQNGRPqtzdiEKAR1dGJB jc4q+2+RMs1GpDNsFzjdFBgM30MiwinZ/USZJGzWLoA7lqIHZmpM1PzsvSdMQ0oR 5e9atR+tOVkDMp6P5xXyjj6HNEwRCUv+FmHAzajpJYHqEArpms3H+MUSz8ytgiu6 sJfxpGAY0woaK/sINDV01GfYYneoqqRZtvOioSNVp94+Wtd74o5+W367mGk9vpl6 XRCbj1c0agDhi9FWptH/BcnAFV0JMnhC0v8mtgnmgdD6AoO/lwsswjZysWOJ+ooZ vZmQqk1GzK486Mb2evjgcapZfgCZx6ObRhEXa6VYfjyOz3P19syqFrfMtL+x6hQ= =7Jy7 -END PGP SIGNATURE- ___ 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: default pager (csh)
On Feb 18, 2015, at 4:41 PM, Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/18/15 15:18, Davide Italiano wrote: Hi, one of the first things I do when I install FreeBSD is to switch the default PAGER from more(1) to less(1). This is particularly convenient, e.g. while using git diff, to show something more readable. Just out of curiosity, is there a reason why more(1) is still the default, and/or is this just historical? The _only_ reason that I can think of is that more(1) does not clear screen for certain terminals (done with 'ti' and 'te' sequences), while less(1) when running as less does. The less(1) behavior can be annoying to some people (sometimes even myself when using less to show contents of a file and ^Z to paste them), and unfortunately quite a few of them also happen to be the more vocal ones when it comes to a change. Being one of those people who strongly prefer using more, I vote against this change. Also, it is easier to scroll back in a terminal window using more. Every system I use, if it defaults the PAGER to less, I change it to more. Kim ___ 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: default pager (csh)
Kim Shrier k...@westryn.net wrote: On Feb 18, 2015, at 4:41 PM, Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/18/15 15:18, Davide Italiano wrote: Hi, one of the first things I do when I install FreeBSD is to switch the default PAGER from more(1) to less(1). This is particularly convenient, e.g. while using git diff, to show something more readable. Just out of curiosity, is there a reason why more(1) is still the default, and/or is this just historical? The _only_ reason that I can think of is that more(1) does not clear screen for certain terminals (done with 'ti' and 'te' sequences), while less(1) when running as less does. The less(1) behavior can be annoying to some people (sometimes even myself when using less to show contents of a file and ^Z to paste them), and unfortunately quite a few of them also happen to be the more vocal ones when it comes to a change. Being one of those people who strongly prefer using more, I vote against this change. Also, it is easier to scroll back in a terminal window using more. Every system I use, if it defaults the PAGER to less, I change it to more. I think the defaults of both programs on FreeBSD are suboptimal. I prefer more with MORE=-eF, which fixes the man page issue mentioned earlier. This is clearly a personal preference item; we won't get it right for everyone. However, anyone who can use git can definitely switch pagers. Trivia: the version of more on BSD systems actually is derived from less, not the original version of more. Mike ___ 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: default pager (csh)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/18/15 15:18, Davide Italiano wrote: Hi, one of the first things I do when I install FreeBSD is to switch the default PAGER from more(1) to less(1). This is particularly convenient, e.g. while using git diff, to show something more readable. Just out of curiosity, is there a reason why more(1) is still the default, and/or is this just historical? The _only_ reason that I can think of is that more(1) does not clear screen for certain terminals (done with 'ti' and 'te' sequences), while less(1) when running as less does. The less(1) behavior can be annoying to some people (sometimes even myself when using less to show contents of a file and ^Z to paste them), and unfortunately quite a few of them also happen to be the more vocal ones when it comes to a change. Other behavioral difference are trivial (or people care less to speak up). I use less(1) instead of more(1) on all systems I have, so if some brave soul wants to make the change I'd say just go for it! but that's my $0.02 only. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJU5SMrAAoJEJW2GBstM+nsd7AQAJNJnZtu3YabP0wzbwZuhQHu 7BvG/RLEqUe6ZmR10pcxe/vr6W+d7HpRuBcF09MSclpijTie+w/5AmaP7NNCCrHc +lAtUhGxGhloTmpkm3GhL94ai1AMoKSIwKgT2Onx76CWYXKfh2ycN4EDfAHUlenZ 4N+3NYua/20deTy0rji0HYMexN4/ZUApsiX9hLwj+mlVl/KVNLMh2OIoUpdbnfJi MU9h+/WPZGBJeU4VQU3YO77sPm23EIzirFajM4Fqk6AZJp8ueHp5U0Bz1l98fBFZ EUx2Bh4DLhn/+7AUlCiW3ByAwyaEzdjpeGwIT97hqHE+7r0Yuf69Sf1mdUcIbMNd TOMo3oKTsVWtYkzB8DZAvGw6y73sLxm6KRwGYWoU3SIhIacU7zer5FC755pPGw3V RqjBPu6nD8BCCXaBumiFtwrr88+vdDV6HfWRXfwSukT4sAYDAzjDEAhuY8kzDyWB vW9KG5IqPrTXPabdAKEj8qpfZBbspYUT0jOPrnto9/S5pnxkXmtmTn/gfVELjblj mLkJYPX9W25ziz3hI9t/wOp2Rl5GzBQdudIXpwD/06/L9h9X4CD38NdEQtJOOLyp M4twYFkiFJZp64XhuwMJ4BGIunj4OsbDfmvZEbJJfV8Z2mgA0QbRvfZG7UqVThd0 MTHLk0J7hIunFwIdICpI =whDB -END PGP SIGNATURE- ___ 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: default pager (csh)
The PAGER was less for about half a year and reverted. Please see: https://svnweb.freebsd.org/base?view=revisionrevision=242643 ___ 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: default pager (csh)
On 19 Feb 2015, at 00:41, Xin Li delp...@delphij.net wrote: Other behavioral difference are trivial (or people care less to speak up). more(1) with man(1) is suboptimal when skipping to the end it quits the pager and one can't scroll back. I use less(1) instead of more(1) on all systems I have, so if some brave soul wants to make the change I'd say just go for it! but that's my $0.02 only. DragonFly made the pager change a while back last year. I do carry these modifications for OPNsense as well. Cheers, Franco ___ 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: sa(4) driver changes available for test
I have updated the patches. I have removed the XPT_DEV_ADVINFO changes from the patches to head, since I committed those separately. I have (hopefully) fixed the build for the stable/10 patches by MFCing dependencies. (One of them mav did for me, thanks!) Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt The patches against FreeBSD/head as of SVN revision 278975: http://people.freebsd.org/~ken/sa_changes.20150218.1.txt And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt Thanks, Ken On Fri, Feb 13, 2015 at 17:32:32 -0700, Kenneth D. Merry wrote: I have a fairly large set of changes to the sa(4) driver and mt(1) driver that I'm planning to commit in the near future. A description of the changes is here and below in this message. If you have tape hardware and the inclination, I'd appreciate testing and feedback. Rough draft commit message: http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt The patches against FreeBSD/head as of SVN revision 278706: http://people.freebsd.org/~ken/sa_changes.20150213.3.txt And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt The intent is to get the tape infrastructure more up to date, so we can support LTFS and more modern tape drives: http://www.ibm.com/systems/storage/tape/ltfs/ I have ported IBM's LTFS Single Drive Edition to FreeBSD. The port depends on the patches linked above. It isn't fully cleaned up and ready for redistribution. If you're interested, though, let me know and I'll tell you when it is ready to go out. You need an IBM LTO-5, LTO-6, TS1140 or TS1150 tape drive. HP drives aren't supported by IBM's LTFS, and older drives don't have the necessary features to support LTFS. The commit message below outlines most of the changes. A few comments: 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. 2. The XML output is similar to what GEOM and CTL do. It would be nice to figure out how to put a standard schema on it so that standard tools could read it. I don't know how feasible that is, since I haven't time to dig into it. If anyone has suggestions on whether that is feasible or advisable, I'd appreciate feedback. 3. I have tested with a reasonable amount of tape hardware (see below for a list), but more testing and feedback would be good. 4. Standard 'mt status' output looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP 5. 'mt status -v' looks like this: # mt -f /dev/nsa3 status -v Drive: sa3: IBM ULTRIUM-HH6 E4J1 Serial Number: 101500520A - Mode Density Blocksize bpi Compression Current: 0x5a:LTO-6 variable 384607 enabled (0xff) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual:0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP - Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 1081344 bytes Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes Maximum block size supported by tape drive and media (max_blk): 8388608 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 1081344 bytes 6. Existing applications should work without changes. If not, please let me know. Hopefully they will move over time to the new interfaces. 7. There are lots of additional features that could be added later. Append-only support, encryption, more log pages, etc. 8. I have SCSI READ ATTRIBUTE changes for camcontrol(8) that will go in separately. These changes allow displaying the contents of the MAM (Medium Auxiliary Memory) chips on LTO, TS and other modern tape drives. These are good, and a future possible direction is adding attributes to the status XML from the sa(4) driver. Significant upgrades to sa(4) and mt(1). The primary focus of these changes is to modernize FreeBSD's tape infrastructure
Re: default pager (csh)
On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall mcdou...@egr.msu.edu wrote: The PAGER was less for about half a year and reverted. Please see: https://svnweb.freebsd.org/base?view=revisionrevision=242643 ___ 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 OK, I think this ends the discussion =) Thanks! -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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
