Jenkins build became unstable: FreeBSD_HEAD-tests2 #733
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/733/ ___ 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: Pluggable frame buffer devices
On 02/20/15 02:15, Shawn Webb wrote:
On Thursday, February 19, 2015 07:04:50 PM Shawn Webb wrote:
On Sunday, February 15, 2015 11:14:47 PM Hans Petter Selasky wrote:
Hi,
I've added support for USB display link adapters to FreeBSD-11-current,
but the kernel panics once vt_fb_attach(info) is called from
fbd_register(struct fb_info* info) when the USB device is plugged or
udl.ko is loaded. Is this a known issue?
REF: https://svnweb.freebsd.org/base/head/sys/dev/usb/video/udl.c
--HPS
I just bought a DisplayLink adapter that's compatible. Compiling a new
kernel with device udl brings this error:
Hi,
You need to also build the sys/modules/videomode and install and kldload.
Does your device need a power supply?
Can you plug the device through an external USB HUB after boot?
Also you need some VT patches, before it will attach to VT which I can
send you. See attachment.
Beware the unplugging the device is not supported. It will crash / panic
which needs to be resolved.
--HPS
diff --git a/sys/dev/fb/fbd.c b/sys/dev/fb/fbd.c
index f9b4d8e..11cb30e 100644
--- a/sys/dev/fb/fbd.c
+++ b/sys/dev/fb/fbd.c
@@ -51,6 +51,9 @@ __FBSDID($FreeBSD$);
#include dev/vt/vt.h
#include dev/vt/hw/fb/vt_fb.h
+#include vm/vm.h
+#include vm/pmap.h
+
#include fb_if.h
LIST_HEAD(fb_list_head_t, fb_list_entry) fb_list_head =
@@ -167,14 +170,21 @@ fb_mmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, int nprot,
info = dev-si_drv1;
- if ((info-fb_flags FB_FLAG_NOMMAP) || info-fb_pbase == 0)
+ if (info-fb_flags FB_FLAG_NOMMAP)
return (ENODEV);
-
- if (offset info-fb_size) {
+ if (offset = info-fb_size)
+ return (EINVAL);
+ if (info-fb_pbase == 0) {
+ /*
+ * If there is no physical address
+ * assume there is a virtual address
+ * which is mappable:
+ */
+ *paddr = vtophys((uint8_t *)info-fb_vbase + offset);
+ } else {
*paddr = info-fb_pbase + offset;
- return (0);
}
- return (EINVAL);
+ return (0);
}
static int
@@ -354,5 +364,6 @@ devclass_t fbd_devclass;
DRIVER_MODULE(fbd, fb, fbd_driver, fbd_devclass, 0, 0);
DRIVER_MODULE(fbd, drmn, fbd_driver, fbd_devclass, 0, 0);
+DRIVER_MODULE(fbd, udl, fbd_driver, fbd_devclass, 0, 0);
MODULE_VERSION(fbd, 1);
diff --git a/sys/dev/vt/hw/fb/vt_fb.c b/sys/dev/vt/hw/fb/vt_fb.c
index 5a0fe4f..bd1b881 100644
--- a/sys/dev/vt/hw/fb/vt_fb.c
+++ b/sys/dev/vt/hw/fb/vt_fb.c
@@ -37,10 +37,14 @@ __FBSDID($FreeBSD$);
#include sys/malloc.h
#include sys/queue.h
#include sys/fbio.h
+
#include dev/vt/vt.h
#include dev/vt/hw/fb/vt_fb.h
#include dev/vt/colors/vt_termcolors.h
+#include vm/vm.h
+#include vm/pmap.h
+
static struct vt_driver vt_fb_driver = {
.vd_name = fb,
.vd_init = vt_fb_init,
@@ -135,7 +139,7 @@ vt_fb_mmap(struct vt_device *vd, vm_ooffset_t offset, vm_paddr_t *paddr,
return (ENODEV);
if (offset = 0 offset info-fb_size) {
- *paddr = info-fb_pbase + offset;
+ *paddr = vtophys(info-fb_vbase + offset);
#ifdef VM_MEMATTR_WRITE_COMBINING
*memattr = VM_MEMATTR_WRITE_COMBINING;
#endif
@@ -423,7 +427,7 @@ vt_fb_init(struct vt_device *vd)
if (info-fb_size == 0)
return (CN_DEAD);
- if (info-fb_pbase == 0)
+ if (info-fb_pbase == 0 info-fb_vbase == 0)
info-fb_flags |= FB_FLAG_NOMMAP;
if (info-fb_cmsize = 0) {
___
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)
Jeffrey Bouquet jbt...@iherebuywisely.com wrote: PAGER='cat' alias man='env PAGER=lookat man $1' No need to alias 'man', just set env MANPAGER. From man man: (so good they named it twice etc.!) -P pager Use specified pager. Defaults to 'less -s' if color support is enabled, or 'more -s'. Overrides the MANPAGER environment variable, which in turn overrides the PAGER environment variable. cheers, Jamie ___ 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 18 Feb 2015, at 20:45, Shawn Webb latt...@gmail.com wrote: 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 The patch failed to apply on HEAD here as well. Using the newest sources (fetched about 10 minutes ago). Anders ___ 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 18/02/15 00:45, 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! Hey! I saw that you had updated your patchfile to drm-update-38.h.patch, and decided to download that to see if I had better success with that one instead of f.patch (which you link to in this thread). To avoid unnecessary conflicts, I decided to remove local sources and redownload the newest sources from FreeBSD's svn repository. When I then applied the patch, it seemed to be more successful, but on 22 occations the patch still fails (the following list contains all the fails; the entire output can be seen here: https://www.dropbox.com/s/07kpkc9xh3zgno4/patchres.txt?dl=0 (patchres.txt)): Hunk #2 failed at 29. 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_agpsupport.c.rej Hunk #2 failed at 31. 1 out of 4 hunks failed--saving rejects to sys/dev/drm2/drm_auth.c.rej Hunk #2 failed at 31. 1 out of 26 hunks failed--saving rejects to sys/dev/drm2/drm_bufs.c.rej Hunk #2 failed at 31. 1 out of 17 hunks failed--saving rejects to sys/dev/drm2/drm_context.c.rej Hunk #1 failed at 21. 1 out of 39 hunks failed--saving rejects to sys/dev/drm2/drm_crtc.h.rej Hunk #2 failed at 31. 1 out of 5 hunks failed--saving rejects to sys/dev/drm2/drm_dma.c.rej Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_drawable.c.rej Hunk #2 failed at 44. 1 out of 8 hunks failed--saving rejects to sys/dev/drm2/drm_drv.c.rej Hunk #1 failed at 19. 1 out of 5 hunks failed--saving rejects to sys/dev/drm2/drm_edid.h.rej Hunk #1 failed at 21. 1 out of 17 hunks failed--saving rejects to sys/dev/drm2/drm_edid_modes.h.rej Hunk #1 failed at 26. 1 out of 7 hunks failed--saving rejects to sys/dev/drm2/drm_fb_helper.h.rej Hunk #2 failed at 32. 1 out of 9 hunks failed--saving rejects to sys/dev/drm2/drm_fops.c.rej Hunk #1 failed at 19. 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_fourcc.h.rej Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_internal.h.rej Hunk #2 failed at 31. 1 out of 4 hunks failed--saving rejects to sys/dev/drm2/drm_ioctl.c.rej Hunk #2 failed at 27. 1 out of 50 hunks failed--saving rejects to sys/dev/drm2/drm_irq.c.rej Hunk #2 failed at 31. 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_lock.c.rej Hunk #2 failed at 31. 1 out of 2 hunks failed--saving rejects to sys/dev/drm2/drm_memory.c.rej Hunk #1 failed at 25. 1 out of 10 hunks failed--saving rejects to sys/dev/drm2/drm_mm.h.rej Hunk #1 failed at 22. 1 out of 11 hunks failed--saving rejects to sys/dev/drm2/drm_mode.h.rej Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_sman.c.rej Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_sman.h.rej ___ 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: i386 port no longer bootable on non-SSE CPUs
On Fri, Feb 20, 2015 at 03:09:49PM -0600, Andrew Wilcox wrote: Hello, The i386 port, both 10-STABLE and 11-CURRENT, will not boot on systems without SSE support. This is caused by r273995, as using `svn merge -c -273995` (and hacking-and-sloshing through the few compiler errors afterwards) makes it once again bootable. This crash happens very early on in boot, before even mi_startup (as the author line is never even printed): http://i.imgur.com/SAty1mT.jpg This breaks support for all i486, Pentium, Pentium Pro, and Pentium II-based CPUs and computers. These are not only found in older computers that are useful as routers and file servers, but there are some new SoCs still using these chips: Intel Galileo board http://www.frys.com/product/8080584 Pentium core, no MMX/SSE whatsoever. Released late 2014. AMD Elan SC520, Geode series http://www.eurotech.com/en/products/CPU-1421 http://www.amd.com/en-us/products/embedded/processors/lx While the Elan is no longer manufactured, it still remains popular. The new Geode LX series of processors only implement MMX (so are roughly equivalent to a Pentium Pro in terms of instruction set). Backing out r273995 allows boot to proceed normally, as shown here: http://imgur.com/a/WWsa5 I attempted to revert locore.S to see if it was related to the stack setup changes found in that commit and it made no difference; the panic was the same. I would be willing to test any patches/diffs on any or all of the systems I have, but unfortunately I'm in a bit over my head trying to figure out which part of this commit is causing it. I just booted HEAD on the qemu configured to emulate Pentium II, i.e. MMX but no SSE/SSE2. So I think what you describe is based on the generalization from single fact. Double fault usually means that the stack overflown. The values for the %eip and %esp on the screen look fishy. My advise is to add debugging printfs to see how far execution went before double fault occur. From the dmesg, your machine fails somewhere in init386(). Try to add some printfs() there, probably around npxinit(true) call for the start. Also, providing us with the verbose dmesg for successfull boot could be useful. ___ 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
Resolver needs bind to src IP option
I looked through these pages and did not see an option to bind the resolver query from a specific IP address (as in the case where you have multiple interfaces and/or alias addresses and wish to pick one instead of the default route). resolver(3) gethostbyname(3) resolver(5) [resolv.conf] You could steer them with NAT filter, or bind a local unbound/named to a src IP and point the resolver at that. But those seem heavier weight solutions than doing it in the resolver natively (whether in resolv.conf or in library calls by applications [where in the apps case, resolv.conf would decide whether application call or resolv.conf takes precedence]). Thoughts? ___ 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
[patch] sys/boot/fdt/fdt_loader_cmd.c
--- sys/boot/fdt/fdt_loader_cmd.c.orig 2015-02-04 10:06:18.0 +0200
+++ sys/boot/fdt/fdt_loader_cmd.c 2015-02-20 23:50:26.0 +0200
@@ -1299,13 +1299,12 @@ fdt_merge_strings(int argc, char *argv[]
sz += argc - start;
buf = (char *)malloc(sizeof(char) * sz);
- bzero(buf, sizeof(char) * sz);
-
if (buf == NULL) {
sprintf(command_errbuf, could not allocate space
for string);
return (1);
}
+ bzero(buf, sizeof(char) * sz);
idx = 0;
for (i = start, idx = 0; i argc; i++) {
___
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
i386 port no longer bootable on non-SSE CPUs
Hello, The i386 port, both 10-STABLE and 11-CURRENT, will not boot on systems without SSE support. This is caused by r273995, as using `svn merge -c -273995` (and hacking-and-sloshing through the few compiler errors afterwards) makes it once again bootable. This crash happens very early on in boot, before even mi_startup (as the author line is never even printed): http://i.imgur.com/SAty1mT.jpg This breaks support for all i486, Pentium, Pentium Pro, and Pentium II-based CPUs and computers. These are not only found in older computers that are useful as routers and file servers, but there are some new SoCs still using these chips: Intel Galileo board http://www.frys.com/product/8080584 Pentium core, no MMX/SSE whatsoever. Released late 2014. AMD Elan SC520, Geode series http://www.eurotech.com/en/products/CPU-1421 http://www.amd.com/en-us/products/embedded/processors/lx While the Elan is no longer manufactured, it still remains popular. The new Geode LX series of processors only implement MMX (so are roughly equivalent to a Pentium Pro in terms of instruction set). Backing out r273995 allows boot to proceed normally, as shown here: http://imgur.com/a/WWsa5 I attempted to revert locore.S to see if it was related to the stack setup changes found in that commit and it made no difference; the panic was the same. I would be willing to test any patches/diffs on any or all of the systems I have, but unfortunately I'm in a bit over my head trying to figure out which part of this commit is causing it. Best, Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox ___ 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 became unstable: FreeBSD_HEAD-tests2 #737
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/737/ ___ 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/20/15 18:05, Warren Block wrote: It doesn't do that on csh. Or maybe I figured out how to prevent it long ago and forgot, but all I use is this: setenv PAGER less -RS You probably did what I used to do. Modify the termcaps/terminfo to eliminate this behavior. See Exorcising the Evil Alternate Screen. In the past, FreeBSD disabled this by default. It was changed several years ago, but you can change it back as per the aboved referenced article. I'm pretty sure I have not done that, it would show up in mergemaster. As far as I can remember, less(1) has never done that clear-the-screen thing on FreeBSD, which is why it is so jarring on Linux. Not all terminals will clear screen... 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.2 (FreeBSD) iQIbBAEBCgAGBQJU5+32AAoJEJW2GBstM+nsZFQP+IoALzoaMRYF+jB9L1kwY+QN h3mnx6BCjv24nMfnv/wLDvWXQ5N1DY0Di9/RP0YSFxgWetpxQGIf0fDOE2jYAbSW +xPBMnYfkKWmzenF5W9NxMPi4o6ul/+LIkp1PxGpxHqjktkSFu3lnoeZaI0JB+6U 3XgpyLMsCfKPP1s5jOyn7TcIKQkby69ANUHWN+7Vfcrg7wy7h0cLmEuCfqOjMg0O CczASshTkCH3JjdwENmT5hwxIKRRqLeqKLvGSyphcZ8FiOl8TKfY+Rnd7wxc9/Cf /PU4cJFVIYw4v60hknD+Dj3hdgwJYA5pfJY2+8faC5V0qKpsDCnl43xDzKXojJjE QX74k7fS47bwcAzTZMLD55X95mos6k7pkDdSE+FoEyWld+yCKxxnSGEXE+728xX2 zdpj1OlJLhyijcZXPNYbDmUVbGzjBnWSTcRF73+upeGDtG3Q1cKaCD7ZBx+Eyqq8 r0ILRrINPzW58XzK0i33obT4SqyBKnadCRuSADpKEaEZgjQeDEGhlQ83SBIt2xBr rqofewSf3jPoN/o03vNaVMRfOT36NT65DOoCjIf0TuEpKbRhfYXb5LVAmt13Bhpv Uc29/3uOi0r2A1h+2URZ0M5LBJo2NiaNgGRE+TTw4y/+mUwhbMvdOVuRwvYwGatb 2lI/u9fCHmNkyPWf5J8= =+90O -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
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #738
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/738/ ___ 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 Fri, 20 Feb 2015 15:49:44 +0100 Anders Bolt-Evensen andersb...@icloud.com wrote: I saw that you had updated your patchfile to drm-update-38.h.patch, and ... applied the patch, it seemed to be more successful, but on 22 occations the patch still fails (the following list contains all the fails; the entire output can be seen here: Hunk #2 failed at 29. 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_agpsupport.c.rej Hunk #2 failed at 31. 1 out of 4 hunks failed--saving rejects to sys/dev/drm2/drm_auth.c.rej Hunk #2 failed at 31. 1 out of 26 hunks failed--saving rejects to sys/dev/drm2/drm_bufs.c.rej Hunk #2 failed at 31. 1 out of 17 hunks failed--saving rejects to sys/dev/drm2/drm_context.c.rej Hunk #1 failed at 21. 1 out of 39 hunks failed--saving rejects to sys/dev/drm2/drm_crtc.h.rej Hunk #2 failed at 31. 1 out of 5 hunks failed--saving rejects to sys/dev/drm2/drm_dma.c.rej Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_drawable.c.rej Hunk #2 failed at 44. 1 out of 8 hunks failed--saving rejects to sys/dev/drm2/drm_drv.c.rej Hunk #1 failed at 19. 1 out of 5 hunks failed--saving rejects to sys/dev/drm2/drm_edid.h.rej Hunk #1 failed at 21. 1 out of 17 hunks failed--saving rejects to sys/dev/drm2/drm_edid_modes.h.rej Hunk #1 failed at 26. 1 out of 7 hunks failed--saving rejects to sys/dev/drm2/drm_fb_helper.h.rej Hunk #2 failed at 32. 1 out of 9 hunks failed--saving rejects to sys/dev/drm2/drm_fops.c.rej Hunk #1 failed at 19. 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_fourcc.h.rej Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_internal.h.rej Hunk #2 failed at 31. 1 out of 4 hunks failed--saving rejects to sys/dev/drm2/drm_ioctl.c.rej Hunk #2 failed at 27. 1 out of 50 hunks failed--saving rejects to sys/dev/drm2/drm_irq.c.rej Hunk #2 failed at 31. 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_lock.c.rej Hunk #2 failed at 31. 1 out of 2 hunks failed--saving rejects to sys/dev/drm2/drm_memory.c.rej Hunk #1 failed at 25. 1 out of 10 hunks failed--saving rejects to sys/dev/drm2/drm_mm.h.rej Hunk #1 failed at 22. 1 out of 11 hunks failed--saving rejects to sys/dev/drm2/drm_mode.h.rej Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_sman.c.rej Hunk #1 failed at 0. 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_sman.h.rej ___ Same errors here. Applying patch to r279092 from svn master. Did you diff against the github source and is there perhaps some divergence between that and the svn master? I worked through the rejects and applied them manually. But, booting does not go well: Feb 20 21:58:22 xx kernel: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_irq.c:1036 Feb 20 21:58:22 xx kernel: cpuid = 0 Feb 20 21:58:22 xx kernel: KDB: stack backtrace: Feb 20 21:58:22 xx kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00b2966600 Feb 20 21:58:22 xx kernel: vpanic() at vpanic+0x189/frame 0xfe00b2966680 Feb 20 21:58:22 xx kernel: kassert_panic() at kassert_panic+0x132/frame 0xfe00b29666f0 Feb 20 21:58:22 xx kernel: __mtx_lock_flags() at __mtx_lock_flags+0x14a/frame 0xfe00b2966740 Feb 20 21:58:22 xx kernel: drm_vblank_post_modeset() at drm_vblank_post_modeset+0x3f/frame 0xfe00b2966770 Feb 20 21:58:22 xx kernel: atombios_crtc_dpms() at atombios_crtc_dpms+0x208/frame 0xfe00b29667b0 Feb 20 21:58:22 xx kernel: atombios_crtc_commit() at atombios_crtc_commit+0x14/frame 0xfe00b29667e0 Feb 20 21:58:22 xx kernel: drm_crtc_helper_set_mode() at drm_crtc_helper_set_mode+0x480/frame 0xfe00b2966a30 Feb 20 21:58:22 xx kernel: drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x9c1/frame 0xfe00b2966b00 Feb 20 21:58:22 xx kernel: vt_restore_fbdev_mode() at vt_restore_fbdev_mode+0x4e/frame 0xfe00b2966b20 Feb 20 21:58:22 xx kernel: taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfe00b2966b80 Feb 20 21:58:22 xx kernel: taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfe00b2966bb0 Feb 20 21:58:22 xx kernel: fork_exit() at fork_exit+0x84/frame 0xfe00b2966bf0 Feb 20 21:58:22 xx kernel: fork_trampoline() at fork_trampoline+0xe/frame 0xfe00b2966bf0 Feb 20 21:58:22 xx kernel: --- trap 0, rip = 0, rsp = 0xfe00b2966cb0, rbp = 0 --- Feb 20 21:58:22 xx kernel: Uptime: 37s Feb 20 21:58:22 xx kernel: Dumping 236 out of 2915 MB:..7%..14%..21%..34%..41%..55%..61%..75%..82%..95% Feb 20 21:58:22 xx kernel: Dump complete Feb 20 21:58:22 xx kernel: Automatic reboot in 15 seconds - press a key on the console to abort Feb 20 21:58:22 xx kernel: Rebooting... I can also see earlier that the cp still did not init... same old CAFEDEAD in r100_cp_init. Chip is ATI Radeon RS690 X1270 IGP. -jr
Re: default pager (csh)
On Thu, 19 Feb 2015, Kevin Oberman wrote: On Thu, Feb 19, 2015 at 5:10 PM, Warren Block wbl...@wonkity.com wrote: On Thu, 19 Feb 2015, Julian Elischer wrote: On 2/18/15 3:41 PM, Xin Li wrote: 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. I find that behaviour infuriating I page down to a place to get some text on the screen to use as a reference, then exit to run a command with that information, and *bam* the info I wanted to use has gone away. It doesn't do that on csh. Or maybe I figured out how to prevent it long ago and forgot, but all I use is this: setenv PAGER less -RS You probably did what I used to do. Modify the termcaps/terminfo to eliminate this behavior. See Exorcising the Evil Alternate Screen. In the past, FreeBSD disabled this by default. It was changed several years ago, but you can change it back as per the aboved referenced article. I'm pretty sure I have not done that, it would show up in mergemaster. As far as I can remember, less(1) has never done that clear-the-screen thing on FreeBSD, which is why it is so jarring on Linux. ___ 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
SVN r279031 breaks net-snmp
It seems that net-snmp wants struct ifaddr and now fails on -CURRENT with: libtool: compile: cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -O2 -pipe -march=core2 -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -fno-strict-aliasing -std=c99 -Ufreebsd11 -Dfreebsd11=freebsd11 -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/usr/local/lib/perl5/5.18/mach/CORE -c mibII/ipv6.c -fPIC -DPIC -o mibII/.libs/ipv6.o mibII/ipv6.c:806:20: warning: returning 'char *' from a function with result type 'u_char *' (aka 'unsigned char *') converts between pointers to integer types with different sign [-Wpointer-sign] return p; ^ mibII/ipv6.c:848:29: error: variable has incomplete type 'struct ifaddr' struct ifaddr ifaddr; ^ /usr/include/net/if_var.h:89:24: note: forward declaration of 'struct ifaddr' TAILQ_HEAD(ifaddrhead, ifaddr); /* instantiation is preserved in the list */ ^ /usr/include/sys/queue.h:493:9: note: expanded from macro 'TAILQ_HEAD' struct type *tqh_first; /* first element */ \ ^ 1 warning and 1 error generated. *** Error code 1 Stop. make[4]: stopped in /usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3/agent/mibgroup *** Error code 1 signature.asc Description: OpenPGP digital signature
Jenkins build is back to stable : FreeBSD_HEAD-tests2 #734
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/734/ ___ 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
