laptop freezes when starting X

[Alexandr Krivulya]

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

[Fabian Keil]

John-Mark Gurney  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
> >  wrote:
> > > John-Mark Gurney  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

Re: [Call for testers] DRM device-independent code update to Linux 3.8

[Ranjan1018 .]

2015-02-18 0:45 GMT+01:00 Jean-Sébastien Pédron :

> 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

[Adrian Chadd]

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  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"

ufs/devfs "lock order reversal" on poweroff

[Damjan Jovanovic]

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: ufs/devfs "lock order reversal" on poweroff

[NGie Cooper]

On Wed, Feb 18, 2015 at 9:53 AM, Damjan Jovanovic  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

[Miguel Clara]

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: [Call for testers] DRM device-independent code update to Linux 3.8

[Shawn Webb]

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

[Marius Strobl]

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 #2406

[jenkins-admin]

See 

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   

echo chat: 

  >> .depend
--- usr.sbin.depend__D ---
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a -std=gnu99   

--- usr.bin.depend__D ---
--- depend_subdir_checknr ---
===> usr.bin/checknr (depend)
--- usr.sbin.depend__D ---
echo arp: 

  >> .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   

--- depend_subdir_chkey ---
--- .depend ---
rm -f .depend
--- depend_subdir_checknr ---
echo checknr: 

  >> .depend
--- depend_subdir_chkey ---
CC='cc  ' mkdep -f .depend -a
-I 
-DYP -std=gnu99   
 

 

--- usr.sbin.depend__D ---
--- depend_subdir_asf ---
===> usr.sbin/asf (depend)
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a -std=gnu99   
 
 
 

--- usr.bin.depend__D ---
echo chkey: 

 

 

 >> .depend
--- depend_subdir_chpass ---
===> usr.bin/chpass (depend)
--- usr.sbin.depend__D ---
--- depend_subdir_acpi ---
echo acpidb: 

 

 >> .depend
===> usr.sbin/acpi/acpidump (depend)
--- depend_subdir_asf ---
echo asf: 

default pager (csh)

[Davide Italiano]

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)

[Xin Li]

-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 https://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)

[Franco Fichtner]

> On 19 Feb 2015, at 00:41, Xin Li  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

[Kenneth D. Merry]

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:  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:  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 

Re: default pager (csh)

[Jason Hellenthal]

-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  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)

[Kim Shrier]

> On Feb 18, 2015, at 4:41 PM, Xin Li  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)

[Mike Karels]

Kim Shrier  wrote:
> > On Feb 18, 2015, at 4:41 PM, Xin Li  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)

[Adam McDougall]

The PAGER was less for about half a year and reverted.  Please see:

https://svnweb.freebsd.org/base?view=revision&revision=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)

[Davide Italiano]

On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall  wrote:
> The PAGER was less for about half a year and reverted.  Please see:
>
> https://svnweb.freebsd.org/base?view=revision&revision=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"

Jenkins build is back to normal : FreeBSD_HEAD #2407

[jenkins-admin]

See 

___
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

[Sean Bruno]

-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=0x1783fbff
>
>
>>>
>
>
> 
Features2=0x81ba2201
> AMD Features=0x28100800 AMD 
> Features2=0x1 Hypervisor: Origin = "XenVMMXenVMM"
> real memory  = 1434451968 (1368 MB) avail memory =
> 1353293824 (1290 MB) Event timer "LAPIC" quality 400 ACPI
> APIC Table:  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
> : push   %rbp 0x80df3901
> : mov%rsp,%rbp 0x80df3904
> : push   %r14 0x80df3906
> : push   %rbx 0x80df3907
> : mov%esi,%ebx 0x80df3909
> : mov%edi,%r14d 0x80df390c
> :mov$0xc500,%edi 0x80df3911
> :mov%r14d,%esi 0x80df3914
> :callq  *0x815ac428 0x80df391b
> :mov$0x14,%edi 0x80df3920
> :callq  *0x815ac438 0x80df3927
> :mov$0x8500,%edi 0x80df392c
> :mov%r14d,%esi 0x80df392f
> :callq  *0x815ac428 0x80df3936
> :mov$0x2710,%edi 0x80df393b
> :callq  0x80f39c10  
> 0x80df3940 :or $0x4600,%ebx 
> 0x80df3946 :movslq %ebx,%rbx 
> 0x80df3949 :mov%rbx,%rdi 
> 0x80df394c :mov%r14d,%esi 
> 0x80df394f :callq  *0x815ac428 
> 0x80df3956 :mov$0x14,%edi 
> 0x80df395b :callq  *0x815ac438 
> 0x80df3962 :test   %eax,%eax 
> 0x80df3964 :   je 0x80df399b 
>  0x80df3966 :   mov
> $0xc8,%edi 0x80df396b :   callq
> 0x80f39c10  0x80df3970 :
> mov%rbx,%rdi 0x80df3973 :   mov
> %r14d,%esi 0x80df3976 :   callq
> *0x815ac428 0x80df397d :   mov
> $0x14,%edi 0x80df3982 :   callq
> *0x815ac438 0x80df3989 :   test
> %eax,%eax 0x80df398b :   je
> 0x80df39a4  0x80df398d
> :   mov$0xc8,%edi 0x80df3992
> :   pop%rbx 0x80df3993
> :   pop%r14 0x80df3995
> :   pop%rbp 0x80df3996
> :   jmpq   0x80f39c10  
> 0x80df399b :   mov
> $0x810cb5c4,%rdi 0x80df39a2 :
> jmp0x80df39ab  0x80df39a4
> :   mov$0x810cb5f3,%rdi 
> 0xf

Re: Xen HVM Panic, HEAD

[Adrian Chadd]

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"

Build failed in Jenkins: FreeBSD_HEAD #2408

[jenkins-admin]

See 

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   
-I 
-I 
-I -DNLS  
-D__DBINTERFACE_PRIVATE 
-I
 
-I
 -DINET6 
-I
 -I 
-D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I 
-I
 
-I
 -I  
-I -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I -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 
 -o 
inet_ntop.So
--- inet_pton.So ---
cc  -fpic -DPIC  -O2 -pipe   
-I 
-I 
-I -DNLS  
-D__DBINTERFACE_PRIVATE 
-I
 
-I
 -DINET6 
-I
 -I 
-D_ACL_PRIVATE -DPOSIX_MISTAKE 
-I 
-I
 
-I
 -I  
-I -DBROKEN_DES -DPORTMAP -DDES_BUILTIN 
-I -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 
 -o 
inet_pton.So
--- nsap_addr.So ---
cc  -fpic -DPIC  -O2 -pipe   
-I 
-I 
-I -DNLS  
-D__DBINTERFACE_PRIVATE 
-I
 
-I

Re: default pager (csh)

[Franco Fichtner]

> On 19 Feb 2015, at 02:27, Davide Italiano  wrote:
> 
> On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall  wrote:
>> The PAGER was less for about half a year and reverted.  Please see:
>> 
>> https://svnweb.freebsd.org/base?view=revision&revision=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: r278857: buildkernel failure: pf_norm.c:1098:1: error: no previous prototype for function 'pf_refragment6'

[Ccs189]

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  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: [Call for testers] DRM device-independent code update to Linux 3.8

[Johannes Dieterich]

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
 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: default pager (csh)

[Kevin Oberman]

On Wed, Feb 18, 2015 at 10:46 PM, Franco Fichtner 
wrote:

>
> > On 19 Feb 2015, at 02:27, Davide Italiano  wrote:
> >
> > On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall 
> wrote:
> >> The PAGER was less for about half a year and reverted.  Please see:
> >>
> >> https://svnweb.freebsd.org/base?view=revision&revision=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"