Re: RFC: please put back spare fields in struct ifnet (removed in svn 270870)
Luigi, On Tue, Sep 09, 2014 at 07:59:42PM +0200, Luigi Rizzo wrote: L My point is preserving support for out of tree modules, L and spares (or spare accessors, or the ABI you mention below; L something that gets you quickly a vendor specific pointer L from an opaque ifnet) were useful for that. L L I think the removal of spares should have happened together L with the commit of the new mechanism. If it is ready now, L let's move with it and be done with this discussion. L L If not, I would like to bring back the pspares L with a big note summarizing this discussion, L and remove then when the new mechanism is ready. L If i read correctly your comment below about L the properly named placeholder you seem to be ok with that ? It would be absolutely okay if you commit right now a properly named placeholder for your new subsystem, that you work on right now. With the proper name no one will unintentionally hijack it. Would this be a satisfiable solution for you? The suggested ABI mechanism is still under discussion and development. -- Totus tuus, Glebius. ___ 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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On 09.09.2014 21:53, Patrick Kelsey wrote: I don't think it is worth the trouble, as given the larger pattern of libc routines requiring multiple capsicum rights, it seems one will in general have to have libc implementation knowledge when using it in concert with capsicum. For example, consider the limitfd() routine in kdump.c, which provides rights for the TIOCGETA ioctl to be used on stdout so the eventual call to isatty() via printf() will work as intended. I think the above kdump example is a good one for the subtle issues that can arise when using capsicum with libc. That call to isatty() is via a widely-used internal libc routine __smakebuf(). __smakebuf() also calls __swhatbuf(), which in turn calls _fstat(), all to make sure that output to a tty is line buffered by default. It would appear that programs that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT could be disabling the normally default line buffering when stdout is a tty. kdump goes the distance, but dhclient does not (restricting stdout to CAP_WRITE only). In any event, the patch attached to my first message is seeming like the way to go. Well, then commit it (if capsicum team agrees). -- http://ache.vniz.net/ ___ 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: ipv6 network aliases not set after upgrade to 9.3
On 04.09.2014 18:16, Kurt Lidl wrote: Greetings all: I have a host that recently was upgraded from FreeBSD 9.1 to FreeBSD 9.3. After the upgrade, the IPv6 aliases that I was setting on vlan'd interfaces, no longer get set: The section of my /etc/rc.conf, which worked under 9.1: # inside network (gigabit connected) ifconfig_bce1=up vlans_bce1=16 17 ifconfig_bce1_16=192.168.16.4/24 ifconfig_bce1_16_ipv6=inet6 accept_rtadv ifconfig_bce1_16_alias0=inet6 2001:470:e254:0010::4 prefixlen 64 alias ifconfig_bce1_17=192.168.17.4/24 ifconfig_bce1_17_ipv6=inet6 accept_rtadv ifconfig_bce1_17_alias0=inet6 2001:470:e254:0011::4 prefixlen 64 alias When I use the same configuration file under 9.3, I get the vlan'd interfaces created, and they get an auto-assigned IPv6 interface, but the aliases do not get assigned. If I manually run: ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias Then the aliased addresses get assigned. Did the syntax for specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1? I did not see anything calling out this change in either the 9.2 or 9.3 release notes. Hi, I can confirm this, please, fill a bug report. -- WBR, Andrey V. Elsukov ___ 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: service doen't get started at boottime, but can start manually
Am Sun, 7 Sep 2014 11:16:37 -0500
Scot Hetzel swhet...@gmail.com schrieb:
On Sun, Sep 7, 2014 at 10:44 AM, Scot Hetzel swhet...@gmail.com wrote:
I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a
few minor changes.
This script (untested) should do what the scripts/refdb.in and
scripts/refdbctl.in were doing:
#!/bin/sh
#
# $FreeBSD$
#
# PROVIDE: refdbd
# REQUIRE: LOGIN
# KEYWORD: shutdown
. /etc/rc.subr
name=refdbd
rcvar=refdbd_enable
command=%%PREFIX%%/bin/${name}
pidfile=/var/run/${name}.pid
required_files=/etc/${name}.conf
I missed required_files in my editing of the original script.
If refdbd does have a configuration file, changes this to point to the
correct file, otherwise this can be removed.
extra_commands=reload
load_rc_config $name
run_rc_command $1
Place the above in textproc/refdb/files/refdb.in, then add:
USE_RC_SUBR= refdbd
in textproc/refdb/Makefile.
It seems to me, that when a port installs a script appended with *.sh in
etc/rc.d/, the
script gets executed anyway - regardless wether the service is enabled
in /etc/rc.conf[.local] or not. This is especially the case for the original
port
textproc/refdb.
The reason why especially one particular machine rejected the startup of the
service was:
I changed the script's name from refdb.sh to refdb and with the lack of the
correct
syntax and definitions inside it, the system (11.0 CURRENT) did not start the
service
while the other systems running refdb used the oldstyle refdb.sh script.
Just for the conclusion of the obscure (at least for me) behaviour.
Thanks for your time,
Oliver
signature.asc
Description: PGP signature
Re: UEFI display frozen on Retina MacBook Pro
On Sep 8, 2014, at 06:21, Anders Bolt Evensen andersb...@icloud.com wrote: To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI shell like rEFIt on either your hard drive or a HFS formatted memory stick: I think this is just a problem with our EFI implementation, though. We should be able to switch to text mode like rEFIt does. -- Rui Paulo ___ 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
panic: resource_list_alloc: resource entry is busy
On my CURRENT as of 6 Sep (r271197): What I did was that: - kldload i915 - startx During X server start I get the following: #10 0x808c2947 in resource_list_alloc (rl=value optimized out, bus=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in bus_alloc_resource (dev=0xf800026d8800, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 #14 0x808c4420 in bus_alloc_resource (dev=0xf800026d7300, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #15 0x81e94f73 in drm_attach (kdev=0xf800026d7300, idlist=value optimized out) at bus.h:416 #16 0x808c202f in device_attach (dev=0xf800026d7300) at device_if.h:180 #17 0x808c34c9 in bus_generic_driver_added (dev=value optimized out, driver=value optimized out) at /usr/src/sys/kern/subr_bus.c:2792 #18 0x808c022a in devclass_driver_added (dc=0xf80002504a80, driver=0x81e714c0) at bus_if.h:204 #19 0x808c018c in devclass_add_driver (dc=0xf80002504a80, driver=0x81e714c0, pass=value optimized out, dcp=value optimized out) at /usr/src/sys/kern/subr_bus.c:1136 #20 0x80873a12 in module_register_init (arg=0x81e714a8) at /usr/src/sys/kern/kern_module.c:123 #21 0x80866f24 in linker_load_module (kldname=value optimized out, modname=0xf80002407400 i915kms, parent=0x0, verinfo=0x0, lfpp=0xfe0096d05a80) at /usr/src/sys/kern/kern_linker.c:224 #22 0x80868a18 in kern_kldload (td=value optimized out, file=value optimized out, fileid=0xfe0096d05ac4) at /usr/src/sys/kern/kern_linker.c:1029 #23 0x80868b5b in sys_kldload (td=0xf80008911490, uap=value optimized out) at /usr/src/sys/kern/kern_linker.c:1055 X -version: X.Org X Server 1.12.4 Release Date: 2012-08-27 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 11.0-CURRENT amd64 Current Operating System: FreeBSD radziecki.saper.info 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r271197M: Sat Sep 6 19:19:12 CEST 2014 r...@radziecki.saper.info:/usr/obj/usr/src/sys/VAIO amd64 Build Date: 04 September 2014 01:06:53AM Devices: vgapci0@pci0:0:2:0: class=0x03 card=0x81e6104d chip=0x27a28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x81e6104d chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller' class = display (this laptop also has a possbility to switch to NVidia card on boot, not tested yet with this kernel). Kernel: # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for the raster text mode # vt is the new video console driver device vt device vt_vga device vt_efifb device agp # support several AGP chipsets Loader: kern.vty=vt By the way, how do I get a nicer FB console during boot (not just after starting X)? I have difficulty getting back to the console text printed when it was vga (in 640x480x16 mode) - no more output shown on the hires console (I've had tail -f somelog) running on the text console 0 when starting X from another window. //Marcin ___ 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: UEFI display frozen on Retina MacBook Pro
On 09/10/2014 02:08, Rui Paulo wrote: On Sep 8, 2014, at 06:21, Anders Bolt Evensen andersb...@icloud.com wrote: To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI shell like rEFIt on either your hard drive or a HFS formatted memory stick: I think this is just a problem with our EFI implementation, though. We should be able to switch to text mode like rEFIt does. -- Rui Paulo ___ 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 Please see http://www.mail-archive.com/freebsd-current@freebsd.org/msg155044.html for a patch. ___ 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: ipv6 network aliases not set after upgrade to 9.3
On 9/10/14, 6:10 AM, Andrey V. Elsukov wrote:
On 04.09.2014 18:16, Kurt Lidl wrote:
Greetings all:
I have a host that recently was upgraded from FreeBSD 9.1
to FreeBSD 9.3. After the upgrade, the IPv6 aliases that
I was setting on vlan'd interfaces, no longer get set:
The section of my /etc/rc.conf, which worked under 9.1:
# inside network (gigabit connected)
ifconfig_bce1=up
vlans_bce1=16 17
ifconfig_bce1_16=192.168.16.4/24
ifconfig_bce1_16_ipv6=inet6 accept_rtadv
ifconfig_bce1_16_alias0=inet6 2001:470:e254:0010::4 prefixlen 64 alias
ifconfig_bce1_17=192.168.17.4/24
ifconfig_bce1_17_ipv6=inet6 accept_rtadv
ifconfig_bce1_17_alias0=inet6 2001:470:e254:0011::4 prefixlen 64 alias
When I use the same configuration file under 9.3, I get the
vlan'd interfaces created, and they get an auto-assigned
IPv6 interface, but the aliases do not get assigned.
If I manually run:
ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias
ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias
Then the aliased addresses get assigned. Did the syntax for
specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1?
I did not see anything calling out this change in either the 9.2 or 9.3
release notes.
Hi,
I can confirm this, please, fill a bug report.
This bug has already been fixed in stable/9, apparently:
r269028 | dteske | 2014-07-23 18:10:34 -0400 (Wed, 23 Jul 2014) | 7 lines
MFC r267812 (hrs): Fix ifname normalization. ifconfig_IF_alias{es,N} did not
work if ifname has any of [.-/+].
PR: conf/191961
Spotted by: jhay
MFC after: 3 days
Personally, given that this a regression of prior behavior,
I'd love to see it go into a patch release of 9.3. Since its
not a security concern, I think this is unlikely to happen.
I have tested the patch in that revision (kindly send to me by
Hiroki Sato), and it resolves the issue I was seeing.
-Kurt
___
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: ipv6 network aliases not set after upgrade to 9.3
On 2014-09-10 10:05, Kurt Lidl wrote:
On 9/10/14, 6:10 AM, Andrey V. Elsukov wrote:
On 04.09.2014 18:16, Kurt Lidl wrote:
Greetings all:
I have a host that recently was upgraded from FreeBSD 9.1
to FreeBSD 9.3. After the upgrade, the IPv6 aliases that
I was setting on vlan'd interfaces, no longer get set:
The section of my /etc/rc.conf, which worked under 9.1:
# inside network (gigabit connected)
ifconfig_bce1=up
vlans_bce1=16 17
ifconfig_bce1_16=192.168.16.4/24
ifconfig_bce1_16_ipv6=inet6 accept_rtadv
ifconfig_bce1_16_alias0=inet6 2001:470:e254:0010::4 prefixlen 64 alias
ifconfig_bce1_17=192.168.17.4/24
ifconfig_bce1_17_ipv6=inet6 accept_rtadv
ifconfig_bce1_17_alias0=inet6 2001:470:e254:0011::4 prefixlen 64 alias
When I use the same configuration file under 9.3, I get the
vlan'd interfaces created, and they get an auto-assigned
IPv6 interface, but the aliases do not get assigned.
If I manually run:
ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias
ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias
Then the aliased addresses get assigned. Did the syntax for
specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1?
I did not see anything calling out this change in either the 9.2 or 9.3
release notes.
Hi,
I can confirm this, please, fill a bug report.
This bug has already been fixed in stable/9, apparently:
r269028 | dteske | 2014-07-23 18:10:34 -0400 (Wed, 23 Jul 2014) | 7 lines
MFC r267812 (hrs): Fix ifname normalization. ifconfig_IF_alias{es,N} did
not
work if ifname has any of [.-/+].
PR: conf/191961
Spotted by: jhay
MFC after: 3 days
Personally, given that this a regression of prior behavior,
I'd love to see it go into a patch release of 9.3. Since its
not a security concern, I think this is unlikely to happen.
I have tested the patch in that revision (kindly send to me by
Hiroki Sato), and it resolves the issue I was seeing.
-Kurt
___
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
I think at least an Errata notice is called for. So users will more
easily be able to find out what the problem is, and stand a reasonable
chance of being aware of the issue before they upgrade, so they can
either include the patch, or rename their interfaces.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: UEFI display frozen on Retina MacBook Pro
Would you or someone else please file a PR with that patch? That way it doesn't get lost. https://bugs.freebsd.org/submit/ Thanks! -a On 10 September 2014 06:34, Adam McDougall mcdou...@egr.msu.edu wrote: On 09/10/2014 02:08, Rui Paulo wrote: On Sep 8, 2014, at 06:21, Anders Bolt Evensen andersb...@icloud.com wrote: To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI shell like rEFIt on either your hard drive or a HFS formatted memory stick: I think this is just a problem with our EFI implementation, though. We should be able to switch to text mode like rEFIt does. -- Rui Paulo ___ 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 Please see http://www.mail-archive.com/freebsd-current@freebsd.org/msg155044.html for a patch. ___ 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
Re: UEFI display frozen on Retina MacBook Pro
On Wednesday, September 10, 2014 08:03:47 AM Adrian Chadd wrote: Would you or someone else please file a PR with that patch? That way it doesn't get lost. https://bugs.freebsd.org/submit/ Thanks! Please assign it to emaste@ as he had volunteered to commit the patch previously. Also, Ed, regarding the earlier thread about this, I think instead of hacking up the EFI headers, we should use the stock headers and adjust our code to use whatever naming contentions (CamelCase, etc.) those use. This is what we do with ACPICA for example. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_alloc: resource entry is busy
On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote: On my CURRENT as of 6 Sep (r271197): What I did was that: - kldload i915 - startx During X server start I get the following: #10 0x808c2947 in resource_list_alloc (rl=value optimized out, bus=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in bus_alloc_resource (dev=0xf800026d8800, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 Can you load the core dump in kgdb and run 'f 13' and 'p *rid'? -- John Baldwin ___ 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: UEFI display frozen on Retina MacBook Pro
On 09/10/2014 11:09, John Baldwin wrote: On Wednesday, September 10, 2014 08:03:47 AM Adrian Chadd wrote: Would you or someone else please file a PR with that patch? That way it doesn't get lost. https://bugs.freebsd.org/submit/ Thanks! Please assign it to emaste@ as he had volunteered to commit the patch previously. Also, Ed, regarding the earlier thread about this, I think instead of hacking up the EFI headers, we should use the stock headers and adjust our code to use whatever naming contentions (CamelCase, etc.) those use. This is what we do with ACPICA for example. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193524 ___ 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
Need help fixing tests in CURRENT
Hi, Based on feedback from Garrett, it looks like there were some problems in kyua, causing test failures. I patched my local copy of the kyua port: https://github.com/rodrigc/kyua-port/ and re-ran the tests: cd /usr/tests kyua test kyua report kyua report-html kyua report-junit https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedBuild/testReport/ There are still 7 test failures which I don't understand. Can someone help fix these? -- Craig ___ 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
UEFI boot failure: BIOS smap did not include a basemem segment!
Hello! I tried the following FreeBSD snapshot on my Clevo W860CU with UEFI enabled: FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img The boot fails early with the following error: panic: BIOS smap did not include a basemem segment! The full picture of the panic is here: https://people.freebsd.org/~dumbbell/uefi/FreeBSD-Clevo-W860CU-UEFI-no-basemem-segment.jpg Here's a video of a verbose boot (the quality is really low, I can try to redo it if this one doesn't help): http://www.dumbbell.fr/~dumbbell/FreeBSD-Clevo-W860CU-UEFI-no-basemem-segment.mov When I tried UEFI a couple years ago (with Windows 7), it could boot. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
