kern/187443: Impossible clean shutdown
>Number: 187443 >Category: kern >Synopsis: Impossible clean shutdown >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 11 11:10:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Bykov Vladislav >Release:FreeBSD 9.2-RELEASE amd64 >Organization: >Environment: Current system: FreeBSD hellgate 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013 r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Tested systems: 9.2-RELEASE, 10, 11-CURRENT Machine: HP envy 4-1055er >Description: Broken ACPI support that causes in impossibility of clean shutdown (S5). When entering ACPI S5 state everything goes okay, but the last part: turning off the power. Mar 11 14:44:09 hellgate kernel: usbus2: Controller shutdown complete Mar 11 14:44:09 hellgate kernel: ACPI Error: No handler for Region [RCM0] (0xfe0002b15900) [SystemCMOS] (20110527/evregion-421) Mar 11 14:44:09 hellgate kernel: ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) Mar 11 14:44:09 hellgate kernel: ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] (Node 0xfe0002af5800), AE_NOT_EXIST (20110527/psparse-560) Mar 11 14:44:09 hellgate kernel: ACPI Error: Method parse/execution failed [\_PTS] (Node 0xfe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) Mar 11 14:44:09 hellgate kernel: acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST Mar 11 14:44:09 hellgate kernel: Rebooting... >How-To-Repeat: Entering in ACPI S5 state. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/187451: Some vlans in bride + carp result hung server
>Number: 187451
>Category: kern
>Synopsis: Some vlans in bride + carp result hung server
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Mar 11 15:20:02 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Yuriy Tsilyk
>Release:RELEASE 10.0
>Organization:
Lantrace
>Environment:
FreeBSD olimp.lantrace.net 10.0-RELEASE FreeBSD 10.0-RELEASE #10 r262714: Tue
Mar 4 14:31:52 EET 2014
r...@olimp.lantrace.net:/usr/obj/usr/src/sys/olimpkernel amd64
>Description:
On two servers (different hardware) created vlans 217-227 on Ethernet
interfaces.
Servers connect via switch.
Vlans added in bridge.
On the bridge created carp option.
Client PC connected to servers in vlan 217.
Carp works fine.
When client generate some traffic (something like ping) to Server the system
hung without any log messages.
>How-To-Repeat:
In server 1 setings /etc/rc.conf:
cloned_interfaces="vlan217 \
vlan218 \
vlan219 \
vlan220 \
vlan221 \
vlan222 \
vlan223 \
vlan224 \
vlan225 \
vlan226 \
vlan227 \
vlan500 \
bridge0"
internal_if="em0"
ifconfig_vlan217="vlan 217 vlandev ${internal_if}"
ifconfig_vlan218="vlan 218 vlandev ${internal_if}"
ifconfig_vlan219="vlan 219 vlandev ${internal_if}"
ifconfig_vlan220="vlan 220 vlandev ${internal_if}"
ifconfig_vlan221="vlan 221 vlandev ${internal_if}"
ifconfig_vlan222="vlan 222 vlandev ${internal_if}"
ifconfig_vlan223="vlan 223 vlandev ${internal_if}"
ifconfig_vlan224="vlan 224 vlandev ${internal_if}"
ifconfig_vlan225="vlan 225 vlandev ${internal_if}"
ifconfig_vlan226="vlan 226 vlandev ${internal_if}"
ifconfig_vlan227="vlan 227 vlandev ${internal_if}"
ifconfig_bridge0="inet 10.100.15.250 netmask 255.255.240.0 \
addm vlan217 \
addm vlan218 \
addm vlan219 \
addm vlan220 \
addm vlan221 \
addm vlan222 \
addm vlan223 \
addm vlan224 \
addm vlan225 \
addm vlan226 \
addm vlan227 "
ifconfig_bridge0_alias0="inet vhid 202 pass password advbase 4 advskew 90
10.100.15.254/32 add"
In server 2 setings /etc/rc.conf:
cloned_interfaces="vlan217 \
vlan218 \
vlan219 \
vlan220 \
vlan221 \
vlan222 \
vlan223 \
vlan224 \
vlan225 \
vlan226 \
vlan227 \
vlan500 \
bridge0"
internal_if="igb1"
ifconfig_vlan217="vlan 217 vlandev ${internal_if}"
ifconfig_vlan218="vlan 218 vlandev ${internal_if}"
ifconfig_vlan219="vlan 219 vlandev ${internal_if}"
ifconfig_vlan220="vlan 220 vlandev ${internal_if}"
ifconfig_vlan221="vlan 221 vlandev ${internal_if}"
ifconfig_vlan222="vlan 222 vlandev ${internal_if}"
ifconfig_vlan223="vlan 223 vlandev ${internal_if}"
ifconfig_vlan224="vlan 224 vlandev ${internal_if}"
ifconfig_vlan225="vlan 225 vlandev ${internal_if}"
ifconfig_vlan226="vlan 226 vlandev ${internal_if}"
ifconfig_vlan227="vlan 227 vlandev ${internal_if}"
ifconfig_bridge0="inet 10.100.15.251 netmask 255.255.240.0 \
addm vlan217 \
addm vlan218 \
addm vlan219 \
addm vlan220 \
addm vlan221 \
addm vlan222 \
addm vlan223 \
addm vlan224 \
addm vlan225 \
addm vlan226 \
addm vlan227 "
ifconfig_bridge0_alias0="inet vhid 202 pass password advbase 2 advskew 50
10.100.15.254/32 add"
In client PC setings:
IP: 10.100.0.100
Netmask: 255.255.240.0
Generate some traffic several minutes:
ping 10.100.15.254
>Fix:
do not know
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/183666: Compiled-in bxe(4) breaks kgzip(1) kernel
Synopsis: Compiled-in bxe(4) breaks kgzip(1) kernel State-Changed-From-To: open->analyzed State-Changed-By: edavis State-Changed-When: Tue Mar 11 18:33:31 UTC 2014 State-Changed-Why: The bxe driver has been re-written and committed. This new driver contains support for many new devices thereby adding a couple more very large firmware blob arrays embedded in the driver. bxe need to be modified to support the firmware(9) interface. http://www.freebsd.org/cgi/query-pr.cgi?pr=183666 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/183666: Compiled-in bxe(4) breaks kgzip(1) kernel
Synopsis: Compiled-in bxe(4) breaks kgzip(1) kernel Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: edavis Responsible-Changed-When: Tue Mar 11 18:38:38 UTC 2014 Responsible-Changed-Why: changed responsible to -net http://www.freebsd.org/cgi/query-pr.cgi?pr=183666 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
RE: kern/185876: ipfw not matching incoming packets decapsulating ipsec. example l2tp/ipsec
Hey, First off all, thanks for the patch, should we wait for FreeBSD 10.1, use 10.0/stable or patch it our selves? Or is this going to be issued as Errata patch for FreeBSD 10.0-Release? (which I think it should be) Kind Regards, Robert Sevat > Subject: Re: kern/185876: ipfw not matching incoming packets decapsulating > ipsec. example l2tp/ipsec > From: nico...@deffayet.com > To: gamana...@gmail.com > Date: Fri, 28 Feb 2014 23:36:44 +0100 > CC: an...@freebsd.org; melif...@freebsd.org; a.v.volob...@gmail.com; > freebsd-bugs@freebsd.org; bug-follo...@freebsd.org > > The following patch seem to be the only working workaround for IPsec > transport mode and tunnel mode. Please note the use of M_PROTO7 instead > of M_PROTO5 as that is not used in netinet & netinet6. M_PROTO5 is used > for another purpose and so using it may create a conflict like M_PROTO3. > > --- > Index: netinet/ip_var.h > === > --- netinet/ip_var.h(revision 262470) > +++ netinet/ip_var.h(working copy) > @@ -167,7 +167,7 @@ > */ > #defineM_FASTFWD_OURS M_PROTO1/* changed dst to > local */ > #defineM_IP_NEXTHOPM_PROTO2/* explicit ip > nexthop */ > -#defineM_SKIP_FIREWALL M_PROTO3/* skip firewall > processing, > +#defineM_SKIP_FIREWALL M_PROTO7/* skip firewall > processing, >keep in sync with IP6 > */ > #defineM_IP_FRAG M_PROTO4/* fragment > reassembly */ > > Index: netinet6/ip6_var.h > === > --- netinet6/ip6_var.h (revision 262470) > +++ netinet6/ip6_var.h (working copy) > @@ -297,7 +297,7 @@ > * IPv6 protocol layer specific mbuf flags. > */ > #defineM_IP6_NEXTHOP M_PROTO2/* explicit ip > nexthop */ > -#defineM_SKIP_FIREWALL M_PROTO3/* skip firewall > processing, > +#defineM_SKIP_FIREWALL M_PROTO7/* skip firewall > processing, >keep in sync with > IPv4 */ > > #ifdef __NO_STRICT_ALIGNMENT > --- > > > -- > Nicolas DEFFAYET > > ___ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org" ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/185876: ipfw not matching incoming packets decapsulating ipsec. example l2tp/ipsec
Glebius is working on a patch. I hope it will be commited soon to stable. On Tue, Mar 11, 2014 at 7:57 PM, Robert Sevat wrote: > Hey, > > First off all, thanks for the patch, should we wait for FreeBSD 10.1, use > 10.0/stable or patch it our selves? > > Or is this going to be issued as Errata patch for FreeBSD 10.0-Release? > (which I think it should be) > > Kind Regards, > Robert Sevat > > > > Subject: Re: kern/185876: ipfw not matching incoming packets > decapsulating ipsec. example l2tp/ipsec > > From: nico...@deffayet.com > > To: gamana...@gmail.com > > Date: Fri, 28 Feb 2014 23:36:44 +0100 > > CC: an...@freebsd.org; melif...@freebsd.org; a.v.volob...@gmail.com; > freebsd-bugs@freebsd.org; bug-follo...@freebsd.org > > > > > The following patch seem to be the only working workaround for IPsec > > transport mode and tunnel mode. Please note the use of M_PROTO7 instead > > of M_PROTO5 as that is not used in netinet & netinet6. M_PROTO5 is used > > for another purpose and so using it may create a conflict like M_PROTO3. > > > > --- > > Index: netinet/ip_var.h > > === > > --- netinet/ip_var.h (revision 262470) > > +++ netinet/ip_var.h (working copy) > > @@ -167,7 +167,7 @@ > > */ > > #define M_FASTFWD_OURS M_PROTO1 /* changed dst to > > local */ > > #define M_IP_NEXTHOP M_PROTO2 /* explicit ip > > nexthop */ > > -#define M_SKIP_FIREWALL M_PROTO3 /* skip firewall > > processing, > > +#define M_SKIP_FIREWALL M_PROTO7 /* skip firewall > > processing, > > keep in sync with IP6 > > */ > > #define M_IP_FRAG M_PROTO4 /* fragment > > reassembly */ > > > > Index: netinet6/ip6_var.h > > === > > --- netinet6/ip6_var.h (revision 262470) > > +++ netinet6/ip6_var.h (working copy) > > @@ -297,7 +297,7 @@ > > * IPv6 protocol layer specific mbuf flags. > > */ > > #define M_IP6_NEXTHOP M_PROTO2 /* explicit ip > > nexthop */ > > -#define M_SKIP_FIREWALL M_PROTO3 /* skip firewall > > processing, > > +#define M_SKIP_FIREWALL M_PROTO7 /* skip firewall > > processing, > > keep in sync with > > IPv4 */ > > > > #ifdef __NO_STRICT_ALIGNMENT > > --- > > > > > > -- > > Nicolas DEFFAYET > > > > ___ > > freebsd-bugs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > > To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org" > ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
conf/187457: ifconfig IP range assignment too restrictive
>Number: 187457 >Category: conf >Synopsis: ifconfig IP range assignment too restrictive >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Mar 11 22:10:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Adam McDougall >Release:FreeBSD 10.0-STABLE >Organization: >Environment: FreeBSD build10 10.0-STABLE FreeBSD 10.0-STABLE #0 r262298: Fri Feb 21 18:28:26 EST 2014 root@build10:/usr/obj/usr/src/sys/BUILD10 amd64 >Description: Recently I came up with the need to assign almost every IP in a /24 subnet to an interface. I wanted to avoid 250+ lines in /etc/rc.conf so I read the rc.conf manpage and discovered the wonderful range feature where I thought I could use: ifconfig_lagg0_alias0="inet 10.0.30.2-254/24" I found out it only creates addresses up to around .34 and prints "Range specification is too large", all as an anti foot-shooting protection due to _IPEXPANDMAX=31 in /etc/network.subr. Could the code be changed to allow for example a whole /24 to be created with a single range? Looking at SVN, this appears to apply to 9 as well. Workaround: define a bunch of smaller ranges: ifconfig_lagg0_aliases="inet 10.0.30.2-31/24 inet 10.0.30.32-63/32 \ inet etc etc" >How-To-Repeat: Try to set a large range in /etc/rc.conf and reboot. ifconfig_interfacename0="up" ifconfig_interfacename0_alias0="inet 10.0.30.2-254/24" >Fix: Raise _IPEXPANDMAX=31 in network.subr? Untested but seems logical since the only apparent purpose is to prevent accidental misconfiguration. It is easy to see if the range is defined too large then it might make a poor choice regarding broadcast IPs, oversized netmasks or something. I didn't check exactly how many IPs it assigned, it should be near 32. I was in a rush and had to settle for a workaround that evening. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/187458: sysrc silently and unexpectedly bootstraps pkg
>Number: 187458 >Category: bin >Synopsis: sysrc silently and unexpectedly bootstraps pkg >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 11 22:40:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Adam McDougall >Release:10.0-STABLE >Organization: >Environment: FreeBSD build10 10.0-STABLE FreeBSD 10.0-STABLE #0 r262298: Fri Feb 21 18:28:26 EST 2014 root@build10:/usr/obj/usr/src/sys/BUILD10 amd64 >Description: Recently I began setting up some fresh FreeBSD installs and I used sysrc to enable some services in /etc/rc.conf that I would use later on. From a fresh install, I have no ports or packages installed. A few steps later I ran 'pkg bootstrap' and it told me pkg was already installed. Huh? The first time I thought I was crazy, the second time I tracked it down. When sysrc runs, it runs some subroutines from /usr/share/bsdconfig/common.subr which runs "ASSUME_ALWAYS_YES=1 pkg -vv" which will bootstrap pkg silently if it can, because it is not installed and it was told to assume yes. In my environment, the end result is not problematic but it is confusing and very unexpected, especially the brief delay during the first execution while it bootstraps. >How-To-Repeat: on a system without pkg installed but with sysrc, run: script output.log sh -x `which sysrc` test=yes In output.log you'll see sysrc call /usr/share/bsdconfig/common.subr which runs "ASSUME_ALWAYS_YES=1 pkg -vv" which will bootstrap pkg silently. to check status, but if pkg is not already bootstrapped, it will silently attempt to and continue on after a short delay if it succeeds. >Fix: No specific fix suggestion. If there is a way to check if pkg is actually installed and not just the /usr/sbin/pkg stub, maybe the full "ASSUME_ALWAYS_YES=1 pkg -vv" execution could be avoided. Checking for /usr/local/sbin/pkg may be insufficient if some has it in a custom path. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/186793: fsck_ffs/ufs segmentation violation in SU J mode on SIGINT before check cycle
The following reply was made to PR bin/186793; it has been noted by GNATS. From: Oleg Ginzburg To: bug-follo...@freebsd.org, olev...@olevole.ru, Petr Lampa , mckus...@freebsd.org Cc: Subject: Re: bin/186793: fsck_ffs/ufs segmentation violation in SU J mode on SIGINT before check cycle Date: Wed, 12 Mar 2014 05:43:47 +0400 Please close this PR due to r263062 / PR187221 solve this issue. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/187461: sysrc mishandles variable names containing a dot
>Number: 187461 >Category: bin >Synopsis: sysrc mishandles variable names containing a dot >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 11 23:10:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Adam McDougall >Release:FreeBSD 10.0-STABLE >Organization: >Environment: FreeBSD build10 10.0-STABLE FreeBSD 10.0-STABLE #0 r262298: Fri Feb 21 18:28:26 EST 2014 root@build10:/usr/obj/usr/src/sys/BUILD10 amd64 >Description: Recently I was trying to convert some "echo a.b.c=1 > /etc/sysctl.conf" type statements to use sysrc instead. It appears if the variable contains one or more dots, sysrc will write the desired value, fail to read it, and it will always create a new entry if executed again. This is inconvenient for editing values in /etc/sysctl.conf using the -f parameter because such entries almost always have a dot in the variable. sysrc -f /etc/sysctl.conf Symptoms are present on FreeBSD 9 too. >How-To-Repeat: root@build10:~ # grep a.b /etc/rc.conf root@build10:~ # sysrc a.b=yes a.b: -> root@build10:~ # grep a.b /etc/rc.conf a.b="yes" root@build10:~ # sysrc a.b=yes a.b: -> root@build10:~ # grep a.b /etc/rc.conf a.b="yes" a.b="yes" >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/187461: sysrc mishandles variable names containing a dot
Synopsis: sysrc mishandles variable names containing a dot Responsible-Changed-From-To: freebsd-bugs->dteske Responsible-Changed-By: eadler Responsible-Changed-When: Wed Mar 12 00:36:24 UTC 2014 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=187461 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/187458: sysrc silently and unexpectedly bootstraps pkg
Synopsis: sysrc silently and unexpectedly bootstraps pkg Responsible-Changed-From-To: freebsd-bugs->dteske Responsible-Changed-By: eadler Responsible-Changed-When: Tue Mar 11 23:07:09 UTC 2014 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=187458 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/187470: [patch] Apple Wireless Keyboard (JIS)
>Number: 187470 >Category: bin >Synopsis: [patch] Apple Wireless Keyboard (JIS) >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Mar 12 02:30:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Yuichiro NAITO >Release:FreeBSD 10.0-Release >Organization: >Environment: FreeBSD pluto.local 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r262241: Tue Feb 25 13:52:12 JST 2014 root@pluto.local:/usr/obj/usr/src/sys/SLIM amd64 >Description: I'm using Apple Wireless Keyboard (JIS) for FreeBSD 10.0-R on amd64 machine. This keyboard has "Kana" and "Eisu" keys that turns on/off input method. I made a patch to handle these keys by bthidd (bluetooth hid daemon). Usually "Zenkaku-Hankaku" key is used to toggle input method. But Apple designed "Kana" key enables input method, and "Eisu" key disables input method, and lost "Zenkaku-Hankaku" key. This patch enables to send these key events to Xorg kbd driver. >How-To-Repeat: Using Apple Wireless Keyboard (JIS) on FreeBSD 10.0-R box. >Fix: Apply this patch. Patch attached with submission follows: diff --git usr.sbin/bluetooth/bthidd/kbd.c usr.sbin/bluetooth/bthidd/kbd.c index 3e944f0..0b66b64 100644 --- usr.sbin/bluetooth/bthidd/kbd.c +++ usr.sbin/bluetooth/bthidd/kbd.c @@ -225,8 +225,8 @@ static int32_t constx[] = /* Keyboard Int'l 7 8D */ -1, /* Unassigned */ /* Keyboard Int'l 8 8E */ -1, /* Unassigned */ /* Keyboard Int'l 9 8F */ -1, /* Unassigned */ -/* Keyboard Lang 1 90 */ NOBREAK|0xF2, /* None */ -/* Keyboard Lang 2 91 */ NOBREAK|0xF1, /* None */ +/* Keyboard Lang 1 90 */ 0x71, /* eisu */ +/* Keyboard Lang 2 91 */ 0x72, /* kana */ /* Keyboard Lang 3 92 */ 0x78, /* F8 */ /* Keyboard Lang 4 93 */ 0x77, /* F7 */ /* Keyboard Lang 5 94 */ 0x76, /* F6 */ >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
