Questions and *little* bugs in new vt(9)
Hi there, I'm currently trying vt(9) on a CURRENT kernel (only the kernel not the base). I have very small bugs, not really serious. I'm currently using the radeon KMS driver. * When I switch from a tty to X I can see the mouse appearing but the tty is still displayed until I move the mouse. Or until I wait something like 3 seconds. It sounds like a small refresh trouble. * When I don't use the native resolution (i.e the radeon firmwares are not loaded) switching from a tty to another results sometimes in a black screen when only some colors are displayed. This does not seems to appear when the native resolution is set. And some questions: * Will you add support for dead keys? I have a UK keyboard and when I want to write french characters like à ô ê I usually press the ` character then a. Same for ^ then o and e. To accomplish this, I use the extd variant in Xorg. This let me to press the dead ` character before a. It would be great to add this support to the vt (or maybe it is already done but I was not able to modify .kdb files to support that). Thanks for your great work on vt(9) and I'm very happy to have full unicode support and a quick tty switch :-). PS: this is more a personal opinion, but I really prefer the syscons font rather than the vt(9)'s one. Regards, David. ___ 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
Fresh-install from -current snapshot: Boot loader too large
Hi, I installed FreeBSD-11.0-CURRENT-i386-20140428-r265054-disc1.iso to a VirtualBox i386 VM. I did the most straightforward install you can possibly do (hit enter repeatedly, except for hostname and password). On the first boot I get the following error message: Boot loader too large Note that FreeBSD-11.0-CURRENT-i386-20140423-r264794-disc1.iso does not has the problem. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: Fresh-install from -current snapshot: Boot loader too large
On Thu, May 08, 2014 at 10:24:01AM +0200 I heard the voice of Jeremie Le Hen, and lo! it spake thus: On the first boot I get the following error message: Boot loader too large As I recall, this comes from the freebsd-boot partition being too big, where too big is some unround number like 540k or something odd like that. Make sure that partition is 512k or something smaller. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: New and exciting panic, possibly re(4)
On 07.05.2014 23:24, Sean Bruno wrote: While screwing around with comcast, I can trivially get this panic out of my desktop machine, and am very confused. It seems to happen on link change up/down events. I'm running 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r265280M. I don't have any direct evidence that this is re(4), just a I'm sorry, that's my fault :) Commit r265279 has introduced panic on IPv4 address removal. That was fixed in r265288. hunch from some discussions in clusteradm@ This can happen when reconnecting my modem or simply issues a netif restart. Fatal trap 9: general protection fault while in kernel mode cpuid = 5; apic id = 15 instruction pointer = 0x20:0x80a4429e stack pointer = 0x28:0xfe046a7f5530 frame pointer = 0x28:0xfe046a7f55d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1306 (ifconfig) trap number = 9 panic: general protection fault cpuid = 5 KDB: stack backtrace: #0 0x80998510 at kdb_backtrace+0x60 #1 0x80959d05 at panic+0x155 #2 0x80d9f2ff at trap_fatal+0x38f #3 0x80d9ef5d at trap+0x74d #4 0x80d82282 at calltrap+0x8 #5 0x80aa0aa1 at in_ifadownkill+0xd1 #6 0x80a412f0 at rn_walktree+0x80 #7 0x80aa0942 at in_ifadown+0xc2 #8 0x80a95591 at in_difaddr_ioctl+0x3a1 #9 0x80a94763 at in_control+0x463 #10 0x80a3010c at ifioctl+0x145c #11 0x809b1a5d at kern_ioctl+0x3cd #12 0x809b163c at sys_ioctl+0x13c #13 0x80d9fd1b at amd64_syscall+0x3fb #14 0x80d8256b at Xfast_syscall+0xfb Uptime: 10m12s Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/modules/vboxguest.ko...done. Loaded symbols for /boot/modules/vboxguest.ko Reading symbols from /boot/modules/vboxvideo.ko...done. Loaded symbols for /boot/modules/vboxvideo.ko Reading symbols from /boot/kernel/drm.ko.symbols...done. Loaded symbols for /boot/kernel/drm.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols #0 doadump (textdump=value optimized out) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:219 #1 0x80959888 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0x80959d44 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:756 #3 0x80d9f2ff in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:882 #4 0x80d9ef5d in trap (frame=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:224 #5 0x80d82282 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #6 0x80a4429e in rt_expunge (rnh=0x7f000210, rt=0xf800148e10c8) at /usr/src/sys/net/route.c:930 #7 0x80aa0aa1 in in_ifadownkill (rn=0xf800148e10c8, xap=0xfe046a7f5660) at /usr/src/sys/netinet/in_rmx.c:414 #8 0x80a412f0 in rn_walktree (h=value optimized out, f=0x80aa09d0 in_ifadownkill, w=0xfe046a7f5660) at /usr/src/sys/net/radix.c:1097 #9 0x80aa0942 in in_ifadown (ifa=0xf8000d542300, delete=1) at /usr/src/sys/netinet/in_rmx.c:447 #10 0x80a95591 in in_difaddr_ioctl (data=value optimized out, ifp=0xf8000d249000, td=value optimized out) at /usr/src/sys/netinet/in.c:580 #11 0x80a94763 in in_control (so=value optimized out, cmd=value optimized out, data=0xf80126c642c0 lo0, ifp=0xf8000d249000, td=0xf80108ad6000) at /usr/src/sys/netinet/in.c:219 #12 0x80a3010c in ifioctl (so=0xf80014839700, cmd=2149607705, data=0xf80126c642c0 lo0, td=0xf80108ad6000) at /usr/src/sys/net/if.c:2638 #13 0x809b1a5d in kern_ioctl (td=0xf80108ad6000, fd=value optimized out, com=0) at file.h:323 #14 0x809b163c in sys_ioctl (td=0xf80108ad6000,
Re: Questions and *little* bugs in new vt(9)
On 8 May 2014 04:16, David Demelier demelier.da...@gmail.com wrote: Hi there, I'm currently trying vt(9) on a CURRENT kernel (only the kernel not the base). I have very small bugs, not really serious. I'm currently using the radeon KMS driver. * When I switch from a tty to X I can see the mouse appearing but the tty is still displayed until I move the mouse. Or until I wait something like 3 seconds. It sounds like a small refresh trouble. Interesting. On my stable/9 desktop with i915kms I can't reproduce this; after switching back to X the previous display is restored, and then a redraw happens, within a few hundred mS. I do see it on my laptop, which also has i915kms but newer software (recent CURRENT, and newer xorg packages). I'll see if I can gather more information at BSDCan next week. * When I don't use the native resolution (i.e the radeon firmwares are not loaded) switching from a tty to another results sometimes in a black screen when only some colors are displayed. This does not seems to appear when the native resolution is set. Can you describe the corruption in some more detail, or share a picture of it? I haven't observed something like this with stock vt, and the vt_vga driver. And some questions: * Will you add support for dead keys? I have a UK keyboard and when I want to write french characters like à ô ê I usually press the ` character then a. This isn't currently planned, but I'll keep it in mind if I look into future work on the keyboard input path. PS: this is more a personal opinion, but I really prefer the syscons font rather than the vt(9)'s one. I've been using vt for about six months and am now used to the default vt font -- the VGA ROM font looks odd to me now. However, I believe the primary motivation behind the font choice was the glyph coverage. I now have a vt-compatible version of the VGA ROM font, but it only has about half of the characters. vt default font: Count % RangeDescription - - --- 95 74% 007F Basic Latin 96 75% 0080 00FF Latin-1 Supplement 126 98% 0100 017F Latin Extended-A 15 7% 0180 024F Latin Extended-B 6 6% 0250 02AF IPA Extensions 10 12% 02B0 02FF Spacing Modifier Letters 7 6% 0300 036F Combining Diacritical Marks 74 51% 0370 03FF Greek 168 66% 0400 04FF Cyrillic 14 5% 1E00 1EFF Latin Extended Additional 38 34% 2000 206F General Punctuation 1 2% 2070 209F Superscripts and Subscripts 3 6% 20A0 20CF Currency Symbols 5 6% 2100 214F Letterlike Symbols 14 12% 2190 21FF Arrows 19 7% 2200 22FF Mathematical Operators 8 3% 2300 23FF Miscellaneous Technical 6 9% 2400 243F Control Pictures 101 79% 2500 257F Box Drawing 24 75% 2580 259F Block Elements 12 12% 25A0 25FF Geometric Shapes 11 4% 2600 26FF Miscellaneous Symbols 1 6% FFF0 Specials Converted cp437-8x16 font: Count % RangeDescription - - --- 98 77% 007F Basic Latin 55 43% 0080 00FF Latin-1 Supplement 1 0% 0180 024F Latin Extended-B 12 8% 0370 03FF Greek 2 2% 2000 206F General Punctuation 1 2% 2070 209F Superscripts and Subscripts 1 2% 20A0 20CF Currency Symbols 7 6% 2190 21FF Arrows 9 4% 2200 22FF Mathematical Operators 4 2% 2300 23FF Miscellaneous Technical 40 31% 2500 257F Box Drawing 8 25% 2580 259F Block Elements 9 9% 25A0 25FF Geometric Shapes 11 4% 2600 26FF Miscellaneous Symbols I expect to commit the converted font soon, and it'll be loadable at runtime. ___ 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: ports broken in current
On May 7, 2014, at 5:41 PM, Shane Ambler free...@shaneware.biz wrote: I have just updated my 11-CURRENT tinderbox machine and found an issue that breaks ports building. make: /usr/share/mk/bsd.port.mk line 15: Could not find bsd.own.mk Install again. This was fixed last night. You can fix it just by updating and running make install in share/mk. This is highlighted as tinderbox creates a clean build environment while the base system kept working with the old file being left behind - make delete-old doesn't remove bsd.own.mk from base but a clean system doesn't get it installed. In r265420 /head/share/mk/Makefile removed reference to bsd.own.mk and replaced it with src.opts.mk Yea that’s totally bogus. Which is why I fixed it. One too many automatic replacements that slipped through the cracks. bsd.port.mk was left unaltered still including bsd.own.mk which now doesn't get installed but is still in svn, breaking ports building. Yea, bsd.port.mk is good. The above breakage was bad... Should bsd.port.mk include src.opts.mk instead of bsd.own.mk or should bsd.own.mk be re-added to the install list? The proper fix is in the tree: re-add bsd.own.mk. This appears to carry on from the yesterdays build fails with src.opts.mk not being found. Please update. If the problems persist, please let me know. Also, be sure to remove /usr/share/mk/src.opts.mk, since if will cause you head-aches in the future if you don’t. Sorry for the bumps… Warner ___ 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
Bumps in the build...
Greetings, Please accept my apologies for the the bumps in the build in recent days. I knew my changes were large, and tried to test them as best I could before the commit. However, there are too many scenarios my testing didn’t hit (including some in hind sight that were obvious holes in my testing). Also obvious in hindsight: I should have sent a heads up when the stuff hit the tree so people would be more cautious. At this point, as far as I know, it has all been fixed. If you see anything weird in the next week or so, please drop me a line. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bumps in the build...
On Thu, May 08, 2014 at 09:12:31AM -0700, Warner Losh wrote: Greetings, Please accept my apologies for the the bumps in the build in recent days. I knew my changes were large, and tried to test them as best I could before the commit. However, there are too many scenarios my testing didn’t hit (including some in hind sight that were obvious holes in my testing). Also obvious in hindsight: I should have sent a heads up when the stuff hit the tree so people would be more cautious. At this point, as far as I know, it has all been fixed. If you see anything weird in the next week or so, please drop me a line. FWIW, r265628 builds fine. Thank you (again) for your quick fix. Glen pgpjSYYSVlAYo.pgp Description: PGP signature
Re: ale(4) cannot negotiate as GigE
On Tue, Mar 05, 2013 at 09:14:11AM +, Alexey Dokuchaev wrote: On Tue, Mar 05, 2013 at 05:57:03PM +0900, YongHyeon PYUN wrote: Hmm, Does the switch support EEE feature? If yes, would you try disabling it? I do not think it [1] does; plus I cannot do much about this switch, as I'm pretty far away from it right now. [1] http://netgear.com/home/products/switches-and-access-points/unmanaged-switches/GS608.aspx (got it about 4 years ago) I just had a chance to plug the Ethernet cable directly into my laptop's bge(4) port, and it immediately negotiated at 1000baseT; but with the switch, it can only feel fine with 10baseT/UTP (after some 1000baseT-no carrier flip flopping). So it looks like it fails to talk to the switch. Given that this switch of mine in a simple (dumb) piece of equipment, any ideas how to help ale(4) to negotiate with it at full speed? ./danfe ___ 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: /usr/src: svn status: svn: E200030: sqlite[S1]: near 1: syntax error
O. Hartmann ohart...@zedat.fu-berlin.de writes: I get this weird error in /usr/src with the port devel/subversion: root@thor: [ports] svn st svn: E200030: sqlite[S1]: near 1: syntax error Using /bin/svn everything is clear. What happened here? OS is FreeBSD 11.0-CURRENT #0 r265433: Tue May 6 13:37:15 CEST 2014 amd64 Did you try svn cleanup? I'm not sure what /bin/svn is, but I suspect it's relatively lightweight (not keeping the backing database), in which case it's not relevant. ___ 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: /usr/src: svn status: svn: E200030: sqlite[S1]: near 1: syntax error
Am Thu, 08 May 2014 16:38:41 -0400 Lowell Gilbert freebsd-current-lo...@be-well.ilk.org schrieb: O. Hartmann ohart...@zedat.fu-berlin.de writes: I get this weird error in /usr/src with the port devel/subversion: root@thor: [ports] svn st svn: E200030: sqlite[S1]: near 1: syntax error Using /bin/svn everything is clear. What happened here? OS is FreeBSD 11.0-CURRENT #0 r265433: Tue May 6 13:37:15 CEST 2014 amd64 Did you try svn cleanup? I'm not sure what /bin/svn is, but I suspect it's relatively lightweight (not keeping the backing database), in which case it's not relevant. Something seemed to have gone wrong during the last update cycle of world. /bin/svn is the svn that comes in 11 CURRENT as contribution. That svn worked well on bot /usr/src and /usr/ports, but the port's version didn't. After make delete-old in /usr/src and a complete buildworld/installworld the problem went away. Thanks. Oliver signature.asc Description: PGP signature
WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
Hi, After the bsd.opts.mk / src.opts.mk split WITHOUT_NIS in src.conf doesn't work. src.conf is included in src.opts.mk after bsd.own.mk which includes bsd.opts.mk. Should bsd.opts.mk options overrides now be set in make.conf instead of src.conf? Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN. Thanks, Guy ___ 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: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On May 8, 2014, at 3:26 PM, Guy Yur guy...@gmail.com wrote:
Hi,
After the bsd.opts.mk / src.opts.mk split
WITHOUT_NIS in src.conf doesn't work.
It should still work… At least that’s the intention...
src.conf is included in src.opts.mk after bsd.own.mk
which includes bsd.opts.mk.
Yea, that’s a problem… It should be included after.
Should bsd.opts.mk options overrides now be set in
make.conf instead of src.conf?
That’s a good workaround until I get that fix tested and committed. Or you
could include src.conf in make.conf at the end. Either will have the same
effect.
Here’s the fix I’m testing, if you’d like to test that instead...
diff -r d69444b828c1 share/mk/src.opts.mk
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -30,17 +30,15 @@
.if !target(__src.opts.mk__)
__src.opts.mk__:
-# Compat -- needed still?
-.include bsd.own.mk
-
-# Allow user to configure things, but in the future this will move
-# elsehwere...
-
+# Allow user to configure things that only effect src tree builds.
SRCCONF?= /etc/src.conf
.if exists(${SRCCONF}) || ${SRCCONF} != /etc/src.conf
.include ${SRCCONF}
.endif
+# Must be included after src.conf
+.include bsd.own.mk
+
#
# Define MK_* variables (which are either yes or no) for users
# to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
Yea, sorry about missing this subtle issue in the split. There was another
report of something similar that I hadn’t tracked down, but your report pointed
me to where I needed to go.
Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 02:54, Warner Losh wrote:
On May 8, 2014, at 3:26 PM, Guy Yur guy...@gmail.com wrote:
Hi,
After the bsd.opts.mk / src.opts.mk split
WITHOUT_NIS in src.conf doesn't work.
It should still work… At least that’s the intention...
src.conf is included in src.opts.mk after bsd.own.mk
which includes bsd.opts.mk.
Yea, that’s a problem… It should be included after.
Should bsd.opts.mk options overrides now be set in
make.conf instead of src.conf?
That’s a good workaround until I get that fix tested and committed. Or you
could include src.conf in make.conf at the end. Either will have the same
effect.
Here’s the fix I’m testing, if you’d like to test that instead...
diff -r d69444b828c1 share/mk/src.opts.mk
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -30,17 +30,15 @@
.if !target(__src.opts.mk__)
__src.opts.mk__:
-# Compat -- needed still?
-.include bsd.own.mk
-
-# Allow user to configure things, but in the future this will move
-# elsehwere...
-
+# Allow user to configure things that only effect src tree builds.
SRCCONF?=/etc/src.conf
.if exists(${SRCCONF}) || ${SRCCONF} != /etc/src.conf
.include ${SRCCONF}
.endif
+# Must be included after src.conf
+.include bsd.own.mk
+
#
# Define MK_* variables (which are either yes or no) for users
# to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
Yea, sorry about missing this subtle issue in the split. There was another
report of something similar that I hadn’t tracked down, but your report
pointed me to where I needed to go.
Warner
Finally! Trying it now...
I was about to take deep look into it because that bothered me so much.
___
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: [rfc] bind per-cpu timeout threads to each CPU
Hi, I'd like to revisit this now. I'd like to commit this stuff as-is and then take some time to revisit the catch-all softclock from cpu0 swi. It's more complicated than it needs to be as it just assumes timeout_cpu == cpuid of cpu 0. So there's no easy way to slide in a new catch-all softclock. Once that's done I'd like to then experiment with turning on the pcpu tcp timer stuff and gluing that into the RSS CPU ID / netisr ID stuff. Thanks, -a On 20 February 2014 13:48, Adrian Chadd adr...@freebsd.org wrote: On 20 February 2014 11:17, John Baldwin j...@freebsd.org wrote: (A further variant of this would be to divorce cpu0's swi from the catch-all softclock and let the catch-all softclock float, but bind all the per-cpu swis) I like this idea. If something (eg per-CPU TCP timers, if it's turned on) makes a very specific decision about the CPU then it should be fixed. Otherwise a lot of the underlying assumptions for things like RSS just aren't guaranteed to hold. It could also perhaps extend to some abstract pool of CPUs later, if we wanted to do things like one flowing swi per socket or whatnot when we start booting on 1024 core boxes... -a ___ 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: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 02:54, Warner Losh wrote:
On May 8, 2014, at 3:26 PM, Guy Yur guy...@gmail.com wrote:
Hi,
After the bsd.opts.mk / src.opts.mk split
WITHOUT_NIS in src.conf doesn't work.
It should still work… At least that’s the intention...
src.conf is included in src.opts.mk after bsd.own.mk
which includes bsd.opts.mk.
Yea, that’s a problem… It should be included after.
Should bsd.opts.mk options overrides now be set in
make.conf instead of src.conf?
That’s a good workaround until I get that fix tested and committed. Or you
could include src.conf in make.conf at the end. Either will have the same
effect.
Here’s the fix I’m testing, if you’d like to test that instead...
diff -r d69444b828c1 share/mk/src.opts.mk
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -30,17 +30,15 @@
.if !target(__src.opts.mk__)
__src.opts.mk__:
-# Compat -- needed still?
-.include bsd.own.mk
-
-# Allow user to configure things, but in the future this will move
-# elsehwere...
-
+# Allow user to configure things that only effect src tree builds.
SRCCONF?=/etc/src.conf
.if exists(${SRCCONF}) || ${SRCCONF} != /etc/src.conf
.include ${SRCCONF}
.endif
+# Must be included after src.conf
+.include bsd.own.mk
+
#
# Define MK_* variables (which are either yes or no) for users
# to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
Yea, sorry about missing this subtle issue in the split. There was another
report of something similar that I hadn’t tracked down, but your report
pointed me to where I needed to go.
Warner
Sorry, that didn't exactly help. I don't fully get what went so wrong there?
Now I got this during install:
---
=== gnu/lib/libregex/doc (install)
install-info: not found
*** Error code 127
---
It was total WTF error but just in case I tried putting .include
../src.conf back, and it worked!
I use __MAKE_CONF, and inside that file I have SRCCONF.
9.2, BTW... unsure if it matters here?
___
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: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On May 8, 2014, at 10:12 PM, Sulev-Madis Silber (ketas) madis...@hot.ee wrote:
On 2014-05-09 02:54, Warner Losh wrote:
On May 8, 2014, at 3:26 PM, Guy Yur guy...@gmail.com wrote:
Hi,
After the bsd.opts.mk / src.opts.mk split
WITHOUT_NIS in src.conf doesn't work.
It should still work… At least that’s the intention...
src.conf is included in src.opts.mk after bsd.own.mk
which includes bsd.opts.mk.
Yea, that’s a problem… It should be included after.
Should bsd.opts.mk options overrides now be set in
make.conf instead of src.conf?
That’s a good workaround until I get that fix tested and committed. Or you
could include src.conf in make.conf at the end. Either will have the same
effect.
Here’s the fix I’m testing, if you’d like to test that instead...
diff -r d69444b828c1 share/mk/src.opts.mk
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -30,17 +30,15 @@
.if !target(__src.opts.mk__)
__src.opts.mk__:
-# Compat -- needed still?
-.include bsd.own.mk
-
-# Allow user to configure things, but in the future this will move
-# elsehwere...
-
+# Allow user to configure things that only effect src tree builds.
SRCCONF?=/etc/src.conf
.if exists(${SRCCONF}) || ${SRCCONF} != /etc/src.conf
.include ${SRCCONF}
.endif
+# Must be included after src.conf
+.include bsd.own.mk
+
#
# Define MK_* variables (which are either yes or no) for users
# to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
Yea, sorry about missing this subtle issue in the split. There was another
report of something similar that I hadn’t tracked down, but your report
pointed me to where I needed to go.
Warner
Sorry, that didn't exactly help. I don't fully get what went so wrong there?
Now I got this during install:
---
=== gnu/lib/libregex/doc (install)
install-info: not found
*** Error code 127
---
It was total WTF error but just in case I tried putting .include
../src.conf back, and it worked!
I use __MAKE_CONF, and inside that file I have SRCCONF.
To be clear, you define SRCCONF in /etc/make.conf (or the file defined by
__MAKE_CONF). The file defined by SRCCONF has WITHOUT_NIS=t defined, but that’s
not effective, even with my change. However, if you add an include to the file
defined by __MAKE_CONF, then it is effective… Is that what you are telling me?
9.2, BTW... unsure if it matters here?
I’m doing my testing on 10-stable… I’ll have to try on my 9.x system… But it
is a lot slower than my 10.x system...
Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: ale(4) cannot negotiate as GigE
On Thu, May 08, 2014 at 05:23:32PM +, Alexey Dokuchaev wrote:
On Tue, Mar 05, 2013 at 09:14:11AM +, Alexey Dokuchaev wrote:
On Tue, Mar 05, 2013 at 05:57:03PM +0900, YongHyeon PYUN wrote:
Hmm, Does the switch support EEE feature? If yes, would you try
disabling it?
I do not think it [1] does; plus I cannot do much about this switch, as I'm
pretty far away from it right now.
[1]
http://netgear.com/home/products/switches-and-access-points/unmanaged-switches/GS608.aspx
(got it about 4 years ago)
I just had a chance to plug the Ethernet cable directly into my laptop's
bge(4) port, and it immediately negotiated at 1000baseT; but with the switch,
it can only feel fine with 10baseT/UTP (after some 1000baseT-no carrier flip
flopping). So it looks like it fails to talk to the switch. Given that this
switch of mine in a simple (dumb) piece of equipment, any ideas how to help
ale(4) to negotiate with it at full speed?
Because there is no publicly available data sheet for Atheros F1
PHY I'm not sure what could be done in this case. The only thing
I can think of at this moment is announcement of next page in auto
negotiation. atphy(4) does not directly manipulate master/slave,
single port/multi port configuration and this configuration may
need next page if other link partner also announces next page
capability.
Try attached patch and let me know whether this makes any
difference for you. You may have to cold boot the box because
stock driver used to clear next page bit in auto-negotiation.
./danfe
Index: sys/dev/mii/atphy.c
===
--- sys/dev/mii/atphy.c (revision 265477)
+++ sys/dev/mii/atphy.c (working copy)
@@ -338,7 +338,9 @@ atphy_setmedia(struct mii_softc *sc, int media)
{
uint16_t anar;
- anar = BMSR_MEDIA_TO_ANAR(sc-mii_capabilities) | ANAR_CSMA;
+ anar = PHY_READ(sc, MII_ANAR);
+ anar = ANAR_NP;
+ anar |= BMSR_MEDIA_TO_ANAR(sc-mii_capabilities) | ANAR_CSMA;
if ((IFM_SUBTYPE(media) == IFM_AUTO || (media IFM_FDX) != 0)
((media IFM_FLOW) != 0 ||
(sc-mii_flags MIIF_FORCEPAUSE) != 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
