Re: [MFC REQUEST] Filename completion in sh(1)
-Brandon Oh, I see. The diff doesn't include the change(s) to histedit.h I would be very interested in a diff for FreeBSD 8.1 Sam Fourman Jr. http://www.fourmannetworks.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
devd and/or ACPI not reporting a heat problem
Howdy,
I thought my heat problems were over with this laptop thanks to all the
great suggestions I've received about powerd, no stepping, etc. (I also
propped up both the back and the front to make a nice big air pocket.)
I've always been pretty religious about blowing the dust off the fans
and heat sinks, but I guess it's been dustier than I thought lately
because I finally caught my laptop doing what it's been doing for the
last 2 weeks, which is (occasionally) powering down when it was
unattended; and the problem was heat.
Of course I've been running devd all along, and so I initially ruled out
the heat problem due to this entry in devd.conf:
# Notify all users before beginning emergency shutdown when we get
# a _CRT or _HOT thermal event and we're going to power down the system
# very soon.
notify 10 {
match system ACPI;
match subsystem Thermal;
match notify 0xcc;
action logger -p kern.emerg 'WARNING: system temperature too
high, shutting down soon!';
};
I'm not getting any of those notices in the logs, so I was looking other
places. (I do get other ACPI-related activity from devd, such as the
notice that it's going on and off AC power.)
So, 2-part question, how can I make sure that devd gets the message, and
how do I make sure that the notice comes _before_ the BIOS forces the
system to power off. I.e., I'd like to have some sort of devd notice
that comes in time to do a clean shutdown, or perhaps some other
mitigation strategy prior to the BIOS taking over.
Any
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message From: Ganbold ganb...@gmail.com To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu ganb...@mobicom.mn Sent: Tue, June 15, 2010 8:02:02 AM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless AK-san, PseudoCylon wrote: From: Ganbold ganb...@gmail.com To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org; Ganbold Tsagaankhuu ganb...@mobicom.mn Sent: Thu, June 10, 2010 10:53:30 AM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless It seems like it is running without any problem so far, no more adsl modem problem. I can see arp packets in wlan0 interface as well as in macbook. I will continue testing and let you know if there comes any problem. thanks again, Ganbold Hello, Glad to hear. It was an encryption problem. A client was dropping packets.. Please let me know if you find another bug. (Hope there won't be) Well, looks like I was too fast :( It seems like client is not receiving any arp packets when rspro doesn't first initiate ping (maybe arp request) to client. If I first ping to client from rspro, later on arp packets can be seen on client. When I ping from rspro to client, response is very different: # arp -a ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1200 seconds [ethernet] ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 824 seconds [ethernet] # ping 192.168.1.50 PING 192.168.1.50 (192.168.1.50): 56 data bytes 64 bytes from 192.168.1.50: icmp_seq=0 ttl=64 time=2.694 ms 64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=302.177 ms 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1.041 ms 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=5234.417 ms 64 bytes from 192.168.1.50: icmp_seq=5 ttl=64 time=4225.060 ms 64 bytes from 192.168.1.50: icmp_seq=6 ttl=64 time=3214.908 ms 64 bytes from 192.168.1.50: icmp_seq=7 ttl=64 time=2207.241 ms 64 bytes from 192.168.1.50: icmp_seq=8 ttl=64 time=1197.061 ms 64 bytes from 192.168.1.50: icmp_seq=9 ttl=64 time=186.833 ms ^C --- 192.168.1.50 ping statistics --- 11 packets transmitted, 9 packets received, 18.2% packet loss round-trip min/avg/max/stddev = 1.041/1841.270/5234.417/1870.962 ms # arp -a ? (192.168.1.43) at 8e:fd:59:d6:3a:50 on bridge0 permanent [bridge] ? (192.168.1.42) at 00:22:cf:03:e0:30 on wlan0 permanent [ethernet] ? (192.168.1.41) at 00:15:6d:c1:c7:77 on arge0 permanent [ethernet] ? (192.168.1.1) at 00:30:54:62:3d:24 on arge0 expires in 1183 seconds [ethernet] ? (192.168.1.7) at 00:1c:25:9d:36:1d on arge0 expires in 805 seconds [ethernet] ? (192.168.1.50) at 00:26:bb:17:f6:61 on arge0 expires in 1186 seconds [ethernet] # ping 192.168.1.50 PING 192.168.1.50 (192.168.1.50): 56 data bytes 64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=1590.035 ms 64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=580.201 ms 64 bytes from 192.168.1.50: icmp_seq=4 ttl=64 time=528.019 ms ^C --- 192.168.1.50 ping statistics --- 5 packets transmitted, 3 packets received, 40.0% packet loss round-trip min/avg/max/stddev = 528.019/899.418/1590.035/488.804 ms Well, the patch is working (sort of). Old driver wouldn't let you ping anywhere. Replies are taking awfully long. One of them took 5 sec. This could be a different issue. Can you try a few thing? (Unfortunately, everything is working on my side.) * Before ping from rspro, does ping from macbook to 192.168.1.42 (wlan0) work? No. I will check again and let you know. * If you give IP address to only bridge0, does it make any difference? I will let you know after testing. * Does it make any difference if use rspro without 192.168.1.7 (if possible)? 192.168.1.7 is just my freebsd laptop. Hello, More questions. Is freebsd laptop working fine with wlan, or is it connected to ethernet port? Does adsl modem still freeze? Normally, when you ping from macbook to modem, there will be arp pakets 'who-has modem tell macbook' and 'modem is-at xx:xx...' Do you see these at wlan0 on rspro? If rspro can ping patch should be working, but let's make sure it is. Please before starting hostapd, sysctl hw.usb.run.debug=1 (If the driver is not compiled with kernel, please apply a patch attached.) When hostapd is started, it will print out Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:cf:03:e0:30 and ssid 'bsd' run_key_set: cmdq_store=0 run_key_set_cb: associd=0, keyix=1, mode=3, type=group, tx=on, rx=off run_stop: All Tx cleared run_newstate: INIT - INIT run_newstate: INIT - SCAN ... omit some lines ... Please confirm there is run_key_set_cb: associd=0, mode=3, ... And, associd is '0' (This was the
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
PseudoCylon wrote: - Original Message Well, the patch is working (sort of). Old driver wouldn't let you ping anywhere. Replies are taking awfully long. One of them took 5 sec. This could be a different issue. Can you try a few thing? (Unfortunately, everything is working on my side.) * Before ping from rspro, does ping from macbook to 192.168.1.42 (wlan0) work? No. I will check again and let you know. * If you give IP address to only bridge0, does it make any difference? I will let you know after testing. * Does it make any difference if use rspro without 192.168.1.7 (if possible)? 192.168.1.7 is just my freebsd laptop. Hello, More questions. Is freebsd laptop working fine with wlan, or is it connected to ethernet port? Connected to ethernet port. Does adsl modem still freeze? Yes. Normally, when you ping from macbook to modem, there will be arp pakets 'who-has modem tell macbook' and 'modem is-at xx:xx...' Do you see these at wlan0 on rspro? I see it. ... 19:02:52.519830 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.50, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 c0a8 0132 0x0020: c0a8 0101 19:02:52.520118 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 00:30:54:62:3d:24 (oui Unknown), length 46 0x: 0026 bb17 f661 0030 5462 3d24 0806 0001 0x0010: 0800 0604 0002 0030 5462 3d24 c0a8 0101 0x0020: 0026 bb17 f661 c0a8 0132 0x0030: I will test the rest and let you know. Ganbold If rspro can ping patch should be working, but let's make sure it is. Please before starting hostapd, sysctl hw.usb.run.debug=1 (If the driver is not compiled with kernel, please apply a patch attached.) When hostapd is started, it will print out Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:cf:03:e0:30 and ssid 'bsd' run_key_set: cmdq_store=0 run_key_set_cb: associd=0, keyix=1, mode=3, type=group, tx=on, rx=off run_stop: All Tx cleared run_newstate: INIT - INIT run_newstate: INIT - SCAN ... omit some lines ... Please confirm there is run_key_set_cb: associd=0, mode=3, ... And, associd is '0' (This was the problem before. So, encryption with group key failed.) When macbook associates with AP, it will print run_newassoc: cmdq_store=2 run_newassoc: new assoc isnew=1 associd=c001 addr=00:26:bb:17:f6:61 run_newassoc: rate=0x82 ridx=0 ctl_ridx=0 ... omit some lines ... run_newassoc: rate=0x6c ridx=11 ctl_ridx=8 run_newassoc: rate=2, mgmt_ridx=0 run_key_set: cmdq_store=3 run_key_set_cb: associd=c001, keyix=0, mode=4, type=pairwise, tx=on, rx=on Please confirm there is run_key_set_cb: associd=c001, mode=4, ... And associd isn't '0'. If not, I need to fix the driver. If things go accordingly, please compare the mode. With your config, group key uses TKIP (mode 3) and pairwise key uses CCMP (mode 4). And very first arp who-has packet uses group key and other use pairwise key. Maybe, macbook doesn't like mixing the mode. So, please tcpdump -vvv -xxx -i wlan0 'arp' and check if any packet with address of all 'ff'. is sent/received alright. All 'ff 'means using group key. Others use pairwise key. All 'ff is easy to see in output of tcpdump. Or, you can chose one of them, CCMP or TKIP for 'wpa_pairwise=' and see if it makes any difference. Sorry for too many questions. It is working fine here, again. AK --patch Only needed if the driver is not compiled with the kernel-- diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c index e4fc8d2..65c1dab 100644 --- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c @@ -69,6 +69,7 @@ __FBSDID($FreeBSD: src/sys/dev/usb/wlan/if_run.c,v 1.11 2010/06/14 23:01:50 jki #include usbdevs.h #define USB_DEBUG_VAR run_debug +#define USB_DEBUG #include dev/usb/usb_debug.h #include if_runreg.h --end patch-- only one line to add -- I disagree with what you say, but will defend to the death your right to tell such LIES! ___ 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: [MFC REQUEST] Filename completion in sh(1)
On 06/16/2010 02:20, Sam Fourman Jr. wrote: -Brandon Oh, I see. The diff doesn't include the change(s) to histedit.h I would be very interested in a diff for FreeBSD 8.1 Sam Fourman Jr. http://www.fourmannetworks.com/ Just got home, So Ill be working on getting this put together over the next few minutes and replying to this thread with a go or no go depending on the outcome and posting the patch. Regards, -- jhell ___ 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: [MFC REQUEST] Filename completion in sh(1)
On 06/16/2010 07:53, jhell wrote: On 06/16/2010 07:29, jhell wrote: Just got home, So Ill be working on getting this put together over the next few minutes and replying to this thread with a go or no go depending on the outcome and posting the patch. Here it is: cd /usr/src patch /path/to/patchfile cd /usr/src/include make obj make depend make includes make make install cd /usr/src/lib/libedit make obj make depend make includes make make install cd /usr/src/bin/sh make obj make depend make includes make make install exec /bin/sh cd /[TAB][TAB] Report any inconsistencies to this thread please. Good Luck Regards, In case the patch did not make it, I have uploaded it here: http://bit.ly/a9i7x9 Regards, -- jhell ___ 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: [MFC REQUEST] Filename completion in sh(1)
I should probably also mention that it does not have username completion the the following form ~userna[TAB][TAB] But does complete ~/[TAB][TAB] from your own home directory. And if you spell out the username as ~username/[TAB][TAB] that will also work. So do not be surprised. -- jhell ___ 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 TEST [HOSTAP] run(4) ralink usb wireless
AK-san, PseudoCylon wrote: Hello, More questions. Is freebsd laptop working fine with wlan, or is it connected to ethernet port? Does adsl modem still freeze? Normally, when you ping from macbook to modem, there will be arp pakets 'who-has modem tell macbook' and 'modem is-at xx:xx...' Do you see these at wlan0 on rspro? If rspro can ping patch should be working, but let's make sure it is. Please before starting hostapd, sysctl hw.usb.run.debug=1 (If the driver is not compiled with kernel, please apply a patch attached.) When hostapd is started, it will print out Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:cf:03:e0:30 and ssid 'bsd' run_key_set: cmdq_store=0 run_key_set_cb: associd=0, keyix=1, mode=3, type=group, tx=on, rx=off run_stop: All Tx cleared run_newstate: INIT - INIT run_newstate: INIT - SCAN ... omit some lines ... Please confirm there is run_key_set_cb: associd=0, mode=3, ... And, associd is '0' (This was the problem before. So, encryption with group key failed.) It prints: ... run_key_set_cb: associd=0, keyix=1, mode=3, type=group, tx=on, rx=off ... When macbook associates with AP, it will print run_newassoc: cmdq_store=2 run_newassoc: new assoc isnew=1 associd=c001 addr=00:26:bb:17:f6:61 run_newassoc: rate=0x82 ridx=0 ctl_ridx=0 ... omit some lines ... run_newassoc: rate=0x6c ridx=11 ctl_ridx=8 run_newassoc: rate=2, mgmt_ridx=0 run_key_set: cmdq_store=3 run_key_set_cb: associd=c001, keyix=0, mode=4, type=pairwise, tx=on, rx=on Please confirm there is run_key_set_cb: associd=c001, mode=4, ... And associd isn't '0'. It prints: run_newassoc: cmdq_store=3 run_newassoc: new assoc isnew=1 associd=c001 addr=00:26:bb:17:f6:61 ... run_newassoc: rate=2, mgmt_ridx=0 wlan0: STA 00:26:bb:17:f6:61 IEEE 802.11: associated run_key_set: cmdq_store=5 run_key_set_cb: associd=c001, keyix=0, mode=4, type=pairwise, tx=on, rx=on wlan0: STA 00:26:bb:17:f6:61 RADIUS: starting accounting session 4C18B4C8- wlan0: STA 00:26:bb:17:f6:61 WPA: pairwise key handshake completed (RSN) If not, I need to fix the driver. If things go accordingly, please compare the mode. With your config, group key uses TKIP (mode 3) and pairwise key uses CCMP (mode 4). And very first arp who-has packet uses group key and other use pairwise key. Maybe, macbook doesn't like mixing the mode. So, please tcpdump -vvv -xxx -i wlan0 'arp' 19:34:27.188281 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.50 tell 0.0.0.0, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 0x0020: c0a8 0132 19:34:27.188326 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.50 tell 0.0.0.0, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 0x0020: c0a8 0132 19:34:27.586863 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.50 tell 0.0.0.0, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 0x0020: c0a8 0132 19:34:27.586903 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.50 tell 0.0.0.0, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 0x0020: c0a8 0132 19:34:27.989517 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.50 tell 192.168.1.50, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 c0a8 0132 0x0020: c0a8 0132 19:34:27.989561 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.50 tell 192.168.1.50, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 c0a8 0132 0x0020: c0a8 0132 19:34:28.389609 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.50 tell 192.168.1.50, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 c0a8 0132 0x0020: c0a8 0132 19:34:28.389638 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.50 tell 192.168.1.50, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 c0a8 0132 0x0020: c0a8 0132 19:34:28.389761 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.50, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 c0a8 0132 0x0020: c0a8 0101 19:34:28.389790 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.50, length 28 0x: 0026 bb17 f661 0806 0001 0x0010: 0800 0604 0001 0026 bb17 f661 c0a8 0132 0x0020:
how to set up UTF8 russian in -current?
My system is amd64 r209195. I was wondering if the user localisation section of the handbook is a bit out of date: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/using-localization.html The handbook suggests using cons25r, whereas the default console type in /etc/ttys is now xterm. And keeping cons25r together with relevant fonts, screenmap and keymap in /etc/rc.conf doesn't seem to work anymore. Also, the latest I can find on UTF8 in FreeBSD is this thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009349.html I tried to follow the advice given in this thread, namely I've rebuilt the kernel with TEKEN_UTF8 (it seems the other option mentioned, TEKEN_XTERM, is no longer valid), and set LC_CTYPE=ru_RU.UTF-8 in my shell. This didn't seem to have any effect. Please advise many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: how to set up UTF8 russian in -current?
* Anton Shterenlikht me...@bristol.ac.uk wrote:
My system is amd64 r209195.
I was wondering if the user localisation
section of the handbook is a bit out of date:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/using-localization.html
The handbook suggests using cons25r, whereas
the default console type in /etc/ttys is now xterm.
And keeping cons25r together with relevant fonts,
screenmap and keymap in /etc/rc.conf doesn't seem
to work anymore.
Also, the latest I can find on UTF8 in FreeBSD
is this thread:
http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009349.html
I tried to follow the advice given in this thread,
namely I've rebuilt the kernel with TEKEN_UTF8
(it seems the other option mentioned, TEKEN_XTERM, is no
longer valid), and set LC_CTYPE=ru_RU.UTF-8
in my shell. This didn't seem to have any effect.
Even though UTF-8 support for the console is closer than it used to be,
it's still not useful in practice, since syscons won't display it. I
guess if you want to get Russian working on HEAD, you should do the
following:
- Don't set TEKEN_* in your kernel configuration file.
- Just use the xterm terminal type in /etc/ttys.
- Set LC_CTYPE=ru_RU.{CP1251,CP866,ISO8859-5,KOI8-R}.
- Load a font for Syscons which uses the same character as the one you
chose above.
So this means 8-bit character sets is the best thing we can do right
now.
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpxUzRW1nIR9.pgp
Description: PGP signature
Re: [CFT] BSDL iconv in base system
On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan ga...@freebsd.org wrote: cc1: warnings being treated as errors /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h: In function '_citrus_BIG5_stdenc_cstomb': /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:138: warning: 'ret' may be used uninitialized in this function Eeh. I'm sorry, I'll look at it tomorrow. For now you can use WERROR= and CWARNFLAGS= to test, actually it was what I used that's why I couldn't catch this. I had the same problem with some code that was not mine so I just set it. I don't know why I'm having that, tohugh, I also have that with a clean unpatched src tree and I'm not using any CFLAGS tweak or such. If you haven't done make clean yet, you can resume the build with: make buildworld -DNO_CLEAN WERROR= CWARNFLAGS= thanks. that worked. :) -- Gabor Kovesdan FreeBSD Volunteer EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org -- Alexander Best ___ 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: [CFT] BSDL iconv in base system
On Tue, Jun 15, 2010 at 7:01 PM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On (15/06/2010 02:13), Gabor Kovesdan wrote: Hello Folks, during the last summer, Google generously founded my Summer of Code project, which was providing a BSD-licensed iconv implementation for FreeBSD. I'm proud to announce that the work has been completed and a patch is available to add it to the base system. The results of this work are: - The Citrus implementation has been ported from NetBSD. - Some utilities have been added. There is a conversion table generator, which can compare conversion tables to reference data generated by GNU libiconv. This helps ensuring conversion compatibility. - UTF-16 surrogate support and some endianness issues have been fixed. - The rather chaotic Makefiles to build metadata have been refactored and cleaned up, now it is easy to read and it is also easier to add support for new encodings. - A bunch of new encodings and encoding aliases have been added. - Support for 1-2, 1-3 and 1-4 mappings, which is needed for transliterating with flying accents as GNU does, like u. - Lots of warnings have been fixed, the major part of the code is now WARNS=6 clean. - New section 1 and section 5 manual pages have been added. - Some GNU-specific calls have been implemented: iconvlist(), iconvctl(), iconv_canonicalize(), iconv_open_into() - Support for GNU's //IGNORE suffix has been added. - The - argument for stdin is now recognized in iconv(1) as per POSIX. - The Big5 conversion module has been fixed. - The iconv.h header files is supposed to be compatible with the GNU version, i.e. sources should build with base iconv.h and GNU libiconv. I've just did a very quick test and it seems ports can safely link to GNU libiconv, there's no conflict. - Various cleanups and style(9) fixes. - A bachelor thesis written in Hungarian language: http://www.kovesdan.org/files/bsc_iconv.pdf The rather big patch (42,5M) is available here: http://www.kovesdan.org/patches/iconv_base_integrate.diff Any comments, suggestions or bugreports are very welcome. Awesome! Thanks for working on it. Are there any plans to resurrect/finish multibyte collation support GSoC'2008 project: http://wiki.freebsd.org/KonradJankowski/Collation Hi. The project is not dead. I've resumed actively working on it. Expect some patches/commits soon. -- Konrad ___ 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: devd and/or ACPI not reporting a heat problem
On Wednesday 16 June 2010 3:04:24 am Doug Barton wrote:
Howdy,
I thought my heat problems were over with this laptop thanks to all the
great suggestions I've received about powerd, no stepping, etc. (I also
propped up both the back and the front to make a nice big air pocket.)
I've always been pretty religious about blowing the dust off the fans
and heat sinks, but I guess it's been dustier than I thought lately
because I finally caught my laptop doing what it's been doing for the
last 2 weeks, which is (occasionally) powering down when it was
unattended; and the problem was heat.
Of course I've been running devd all along, and so I initially ruled out
the heat problem due to this entry in devd.conf:
# Notify all users before beginning emergency shutdown when we get
# a _CRT or _HOT thermal event and we're going to power down the system
# very soon.
notify 10 {
match system ACPI;
match subsystem Thermal;
match notify 0xcc;
action logger -p kern.emerg 'WARNING: system temperature too
high, shutting down soon!';
};
I'm not getting any of those notices in the logs, so I was looking other
places. (I do get other ACPI-related activity from devd, such as the
notice that it's going on and off AC power.)
So, 2-part question, how can I make sure that devd gets the message, and
how do I make sure that the notice comes _before_ the BIOS forces the
system to power off. I.e., I'd like to have some sort of devd notice
that comes in time to do a clean shutdown, or perhaps some other
mitigation strategy prior to the BIOS taking over.
Hmm, so the system just polls the temperature every 10 seconds
(sys/dev/acpica/acpi_thermal.c has the details) and if it sees a high
temperature twice in a row, it sends this event to devd. If it sees it a
third time it initiates a shutdown. It may be that the BIOS takes over before
those 20 seconds have passed. You can reduce the polling interval by changing
hw.acpi.thermal.polling_rate (it is in seconds it seems) to a lower value.
--
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: [CFT] BSDL iconv in base system
Anonymous swel...@gmail.com writes:
Gabor Kovesdan ga...@freebsd.org writes:
[...]
Any comments, suggestions or bugreports are very welcome.
Does it respect lib32?
$ iconv -f ascii
iconv: iconv_open(UTF-8, ascii): Invalid argument
/usr/lib/i18n/libiconv_std.so.4: unsupported file layoutzsh: exit 1
iconv -f ascii
$ file /usr/lib/i18n/libiconv_std.so.4
/usr/lib/i18n/libiconv_std.so.4: ELF 32-bit LSB shared object, Intel 80386,
version 1 (FreeBSD), dynamically linked, stripped
$ uname -vm
FreeBSD 9.0-CURRENT #0 r209191=1463b20-dirty: Tue Jun 15 04:59:40 UTC 2010
h...@raphael.local:/a/objdir/a/dirty_build/sys/PHOENIX amd64
BTW, I tried to crosscompile i386 and got error on installing
usr.bin/{mkesdb,mkcsmapper}.
$ make installworld TARGET=i386 DESTDIR=/b/bbb
...
=== usr.bin/mkcsmapper (install)
install -s -o root -g wheel -m 555 mkcsmapper /b/bbb/usr/bin
strip: /b/bbb/usr/bin/mkcsmapper: File format not recognized
install: wait: No such file or directory
*** Error code 70
___
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: [CFT] BSDL iconv in base system
On Wed, Jun 16, 2010 at 3:50 PM, Alexander Best alexbes...@uni-muenster.de wrote: On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan ga...@freebsd.org wrote: cc1: warnings being treated as errors /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h: In function '_citrus_BIG5_stdenc_cstomb': /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:138: warning: 'ret' may be used uninitialized in this function Eeh. I'm sorry, I'll look at it tomorrow. For now you can use WERROR= and CWARNFLAGS= to test, actually it was what I used that's why I couldn't catch this. I had the same problem with some code that was not mine so I just set it. I don't know why I'm having that, tohugh, I also have that with a clean unpatched src tree and I'm not using any CFLAGS tweak or such. If you haven't done make clean yet, you can resume the build with: make buildworld -DNO_CLEAN WERROR= CWARNFLAGS= thanks. that worked. :) ok. after installing world i get this when bootingt up: Starting powerd. Starting musicpd. path: invalid filesystem charset: ISO-8859-15 /usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout pid 1078 (mpd), uid 1001: exited on signal 6 Abort trap /etc/rc: WARNING: failed to start musicpd Starting mpdscribble. GLib: Cannot convert message: Conversion from character set 'UTF-8' to 'ASCII' is not supported /usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layoutoption parsing failed: Conversion from character set 'ASCII' to 'UTF-8' is not supported /etc/rc: WARNING: failed to start mpdscribble cheers. alex -- Gabor Kovesdan FreeBSD Volunteer EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org -- Alexander Best -- Alexander Best ___ 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 TEST [HOSTAP] run(4) ralink usb wireless
AK-san, PseudoCylon wrote: Hello, More questions. Is freebsd laptop working fine with wlan, or is it connected to ethernet port? Does adsl modem still freeze? Normally, when you ping from macbook to modem, there will be arp pakets 'who-has modem tell macbook' and 'modem is-at xx:xx...' Do you see these at wlan0 on rspro? If rspro can ping patch should be working, but let's make sure it is. Please before starting hostapd, sysctl hw.usb.run.debug=1 (If the driver is not compiled with kernel, please apply a patch attached.) When hostapd is started, it will print out Starting hostapd. Configuration file: /etc/hostapd.conf Using interface wlan0 with hwaddr 00:22:cf:03:e0:30 and ssid 'bsd' run_key_set: cmdq_store=0 run_key_set_cb: associd=0, keyix=1, mode=3, type=group, tx=on, rx=off run_stop: All Tx cleared run_newstate: INIT - INIT run_newstate: INIT - SCAN ... omit some lines ... Please confirm there is run_key_set_cb: associd=0, mode=3, ... And, associd is '0' (This was the problem before. So, encryption with group key failed.) When macbook associates with AP, it will print run_newassoc: cmdq_store=2 run_newassoc: new assoc isnew=1 associd=c001 addr=00:26:bb:17:f6:61 run_newassoc: rate=0x82 ridx=0 ctl_ridx=0 ... omit some lines ... run_newassoc: rate=0x6c ridx=11 ctl_ridx=8 run_newassoc: rate=2, mgmt_ridx=0 run_key_set: cmdq_store=3 run_key_set_cb: associd=c001, keyix=0, mode=4, type=pairwise, tx=on, rx=on Please confirm there is run_key_set_cb: associd=c001, mode=4, ... And associd isn't '0'. If not, I need to fix the driver. If things go accordingly, please compare the mode. With your config, group key uses TKIP (mode 3) and pairwise key uses CCMP (mode 4). And very first arp who-has packet uses group key and other use pairwise key. Maybe, macbook doesn't like mixing the mode. So, please tcpdump -vvv -xxx -i wlan0 'arp' and check if any packet with address of all 'ff'. is sent/received alright. All 'ff 'means using group key. Others use pairwise key. All 'ff is easy to see in output of tcpdump. Or, you can chose one of them, CCMP or TKIP for 'wpa_pairwise=' and see if it makes any difference. I tried both wpa_pairwise=CCMP and wpa_pairwise=TKIP, and it is same as before, modem hangs. Ganbold Sorry for too many questions. It is working fine here, again. AK --patch Only needed if the driver is not compiled with the kernel-- diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c index e4fc8d2..65c1dab 100644 --- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c @@ -69,6 +69,7 @@ __FBSDID($FreeBSD: src/sys/dev/usb/wlan/if_run.c,v 1.11 2010/06/14 23:01:50 jki #include usbdevs.h #define USB_DEBUG_VAR run_debug +#define USB_DEBUG #include dev/usb/usb_debug.h #include if_runreg.h --end patch-- only one line to add -- I never killed a man that didn't deserve it. -- Mickey Cohen ___ 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: [CFT] BSDL iconv in base system
Alexander Best alexbes...@uni-muenster.de writes: On Wed, Jun 16, 2010 at 3:50 PM, Alexander Best alexbes...@uni-muenster.de wrote: On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan ga...@freebsd.org wrote: cc1: warnings being treated as errors /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h: In function '_citrus_BIG5_stdenc_cstomb': /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:138: warning: 'ret' may be used uninitialized in this function Eeh. I'm sorry, I'll look at it tomorrow. For now you can use WERROR= and CWARNFLAGS= to test, actually it was what I used that's why I couldn't catch this. I had the same problem with some code that was not mine so I just set it. I don't know why I'm having that, tohugh, I also have that with a clean unpatched src tree and I'm not using any CFLAGS tweak or such. If you haven't done make clean yet, you can resume the build with: make buildworld -DNO_CLEAN WERROR= CWARNFLAGS= thanks. that worked. :) ok. after installing world i get this when bootingt up: Starting powerd. Starting musicpd. path: invalid filesystem charset: ISO-8859-15 /usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout pid 1078 (mpd), uid 1001: exited on signal 6 Abort trap /etc/rc: WARNING: failed to start musicpd Starting mpdscribble. GLib: Cannot convert message: Conversion from character set 'UTF-8' to 'ASCII' is not supported /usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layout/usr/lib/i18n/libiconv_std.so.4: unsupported file layoutoption parsing failed: Conversion from character set 'ASCII' to 'UTF-8' is not supported /etc/rc: WARNING: failed to start mpdscribble Can you try? $ cd /usr/src/lib/libiconv_modules $ make install ___ 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: how to set up UTF8 russian in -current?
On Wed, Jun 16, 2010 at 03:45:30PM +0200, Ed Schouten wrote:
* Anton Shterenlikht me...@bristol.ac.uk wrote:
My system is amd64 r209195.
I was wondering if the user localisation
section of the handbook is a bit out of date:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/using-localization.html
The handbook suggests using cons25r, whereas
the default console type in /etc/ttys is now xterm.
And keeping cons25r together with relevant fonts,
screenmap and keymap in /etc/rc.conf doesn't seem
to work anymore.
Also, the latest I can find on UTF8 in FreeBSD
is this thread:
http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009349.html
I tried to follow the advice given in this thread,
namely I've rebuilt the kernel with TEKEN_UTF8
(it seems the other option mentioned, TEKEN_XTERM, is no
longer valid), and set LC_CTYPE=ru_RU.UTF-8
in my shell. This didn't seem to have any effect.
Even though UTF-8 support for the console is closer than it used to be,
it's still not useful in practice, since syscons won't display it. I
guess if you want to get Russian working on HEAD, you should do the
following:
- Don't set TEKEN_* in your kernel configuration file.
- Just use the xterm terminal type in /etc/ttys.
- Set LC_CTYPE=ru_RU.{CP1251,CP866,ISO8859-5,KOI8-R}.
- Load a font for Syscons which uses the same character as the one you
chose above.
So this means 8-bit character sets is the best thing we can do right
now.
Yes, this works fine.
I guess TEKEN_* in the kernel broke it.
However, russian in xterm is still not working.
This is probably my misconfiguration..
many thanks for your help
anton
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
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
HEADSUP: Call for FreeBSD Status Reports - 2Q/2010
Dear all, I would like to remind you that the next round of status reports covering the second quarter of 2010 is due on July 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template to be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer ___ 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: devd and/or ACPI not reporting a heat problem
On 6/16/2010 5:05 AM, John Baldwin wrote: You can reduce the polling interval by changing hw.acpi.thermal.polling_rate (it is in seconds it seems) to a lower value. Thanks, I'll give that a try, although with the cleaning I gave it yesterday I'm hoping to avoid heat problems for a while. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] BSDL iconv in base system
Hi, On 2010-06-15, Gabor Kovesdan wrote: - The iconv.h header files is supposed to be compatible with the GNU version, i.e. sources should build with base iconv.h and GNU libiconv. I've just did a very quick test and it seems ports can safely link to GNU libiconv, there's no conflict. The rather big patch (42,5M) is available here: http://www.kovesdan.org/patches/iconv_base_integrate.diff iconv(3) prototype doesn't conform to POSIX.1-2008. Is it a well-considered decision? -- Jaakko ___ 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: [CFT] BSDL iconv in base system
iconv(3) prototype doesn't conform to POSIX.1-2008. Is it a well-considered decision? No, it was just like that in the Citrus version and I didn't notice the const qualifier. Fixed in my working copy, will be available soon with some minor modifications. Thanks for reporting this. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.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: [CFT] BSDL iconv in base system
On Wed, Jun 16, 2010 at 10:04:16PM +0300, Jaakko Heinonen wrote: On 2010-06-15, Gabor Kovesdan wrote: - The iconv.h header files is supposed to be compatible with the GNU version, i.e. sources should build with base iconv.h and GNU libiconv. I've just did a very quick test and it seems ports can safely link to GNU libiconv, there's no conflict. The rather big patch (42,5M) is available here: http://www.kovesdan.org/patches/iconv_base_integrate.diff iconv(3) prototype doesn't conform to POSIX.1-2008. Is it a well-considered decision? I think the difference from POSIX.1-2008 is pretty common and may therefore cause less compilation problems. NetBSD's Citrus iconv and GNU iconv have the extra 'const', and so does the default Solaris iconv (Solaris has a separate iconv for standards-conforming applications with the POSIX prototype.) -- Jilles Tjoelker ___ 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: [CFT] BSDL iconv in base system
Jaakko Heinonen j...@freebsd.org writes:
iconv(3) prototype doesn't conform to POSIX.1-2008. Is it a
well-considered decision?
Probably not, because it breaks the interface.
Imagine that inbuf were just a char *, not a char **. It would be
perfectly safe to change it to const char *, because you can always
assign a char * to a const char *.
However, inbuf is a char **, which is a pointer to a pointer to char.
Gabor changed it to const char **, which is a pointer to a pointer to
const char. Unfortunately, the two types are incompatible. If foo is a
char *, you can't pass foo as inbuf.
% cat /tmp/const.c EOF
#include stdio.h
void fs(char *s) { puts(++s); }
void gs(const char *s) { puts(++s); }
void fsp(char **sp) { puts(++*sp); }
void gsp(const char **sp) { puts(++*sp); }
int main() { char *s = xyzzy, **sp = s; fs(s); gs(s); fsp(sp); gsp(sp); }
EOF
% cc -Wall -Wextra -Werror -std=c99 -o/dev/null /tmp/const.c
cc1: warnings being treated as errors
/tmp/const.c: In function ‘main’:
/tmp/const.c:6: error: passing argument 1 of ‘gsp’ from incompatible pointer
type
/tmp/const.c:5: note: expected ‘const char **’ but argument is of type ‘char **’
This means you can't, say, read data from a file into a buffer and then
pass that buffer to iconv, because the buffer is not const (otherwise
you couldn't have read data into it). That seems like a pretty
fundamental flaw.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: how to set up UTF8 russian in -current?
On Wed, 2010-06-16 at 17:30 +0100, Anton Shterenlikht wrote:
On Wed, Jun 16, 2010 at 03:45:30PM +0200, Ed Schouten wrote:
* Anton Shterenlikht me...@bristol.ac.uk wrote:
My system is amd64 r209195.
I was wondering if the user localisation
section of the handbook is a bit out of date:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/using-localization.html
The handbook suggests using cons25r, whereas
the default console type in /etc/ttys is now xterm.
And keeping cons25r together with relevant fonts,
screenmap and keymap in /etc/rc.conf doesn't seem
to work anymore.
Also, the latest I can find on UTF8 in FreeBSD
is this thread:
http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009349.html
I tried to follow the advice given in this thread,
namely I've rebuilt the kernel with TEKEN_UTF8
(it seems the other option mentioned, TEKEN_XTERM, is no
longer valid), and set LC_CTYPE=ru_RU.UTF-8
in my shell. This didn't seem to have any effect.
Even though UTF-8 support for the console is closer than it used to be,
it's still not useful in practice, since syscons won't display it. I
guess if you want to get Russian working on HEAD, you should do the
following:
- Don't set TEKEN_* in your kernel configuration file.
- Just use the xterm terminal type in /etc/ttys.
- Set LC_CTYPE=ru_RU.{CP1251,CP866,ISO8859-5,KOI8-R}.
- Load a font for Syscons which uses the same character as the one you
chose above.
So this means 8-bit character sets is the best thing we can do right
now.
Yes, this works fine.
I guess TEKEN_* in the kernel broke it.
However, russian in xterm is still not working.
This is probably my misconfiguration..
Can you specifically point out things that do not work for you in the
xterm window? I am able to create files and directories with Cyrillic
names, use Cyrillic strings as the command parameters, etc. It has been
working for me for quite a long time, so I could not really remember
what, if anything, I had to do, but we can compare settings if you'd
like to. I do use Gnome, though, so some of its pixie dust could have
been spilled onto xterm.
I have attached small screenshot as an illustration -- if this is not
what you are talking about, please, accept my apology for the noise.
many thanks for your help
anton
--
Alexandre Kovalenko (Олександр Коваленко)
--
Ovi Store: Fresh apps and more
http://store.ovi.com/?cid=ovistore-fw-bac-na-acq-na-ovimail-g0-na-4
___
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: how to set up UTF8 russian in -current?
On 17.06.2010 5:57, Alexandre Sunny Kovalenko wrote: Can you specifically point out things that do not work for you in the xterm window? I am able to create files and directories with Cyrillic names, use Cyrillic strings as the command parameters, etc. It has been working for me for quite a long time, so I could not really remember what, if anything, I had to do, but we can compare settings if you'd like to. I do use Gnome, though, so some of its pixie dust could have been spilled onto xterm. I have attached small screenshot as an illustration -- if this is not what you are talking about, please, accept my apology for the noise. I think Anton said about console localization (not X Window). -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
SUJ problem
after unexpected reboot I have problem Mounting root filesystem rw failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Jun 17 12:35:49 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh : # f s c k - y ** /dev/label/rootFS USE JOURNAL?? yes ** SU+J Recovering /dev/label/rootFS ** Reading 33554432 byte journal from inode 10. RECOVER? yes ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. fsck: /dev/label/rootFS: Abort trap: 6 # fsck -y ** /dev/label/rootFS USE JOURNAL?? yes ** SU+J Recovering /dev/label/rootFS ** Reading 33554432 byte journal from inode 10. RECOVER? yes ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. fsck: /dev/label/rootFS: Abort trap: 6 # fsck -y \^H\^[[K \^H\^[[K / ** /dev/label/rootFS USE JOURNAL?? [yn] ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes 73183545484378114 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY 8589934638 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY 50775137189900 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY 361413938815959043 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY 482670965550 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY 289356344794376192 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY -1097558167694 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY 289356344784931840 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY -1097843379600 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY 361413938827687936 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY -281004955507613 BAD I=29393063 UNEXPECTED SOFT UPDATE INCONSISTENCY EXCESSIVE BAD BLKS I=29393063 CONTINUE? [yn] INCORRECT BLOCK COUNT I=29393063 (2153728 should be 263040) CORRECT? [yn] ** Phase 2 - Check Pathnames DUP/BAD I=29393063 OWNER=lissyara MODE=100644 SIZE=1102141440 MTIME=May 12 16:31 2010 FILE=/tmp/src.tar UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? [yn] ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=3085332 OWNER=root MODE=100555 SIZE=362096 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=3085355 OWNER=root MODE=100555 SIZE=137472 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=4922372 OWNER=root MODE=100555 SIZE=9168 MTIME=Jun 15 09:24 2010 CLEAR? [yn] UNREF FILE I=4922398 OWNER=root MODE=100555 SIZE=438280 MTIME=Jun 15 09:24 2010 CLEAR? [yn] UNREF FILE I=4922403 OWNER=root MODE=100555 SIZE=89184 MTIME=Jun 15 09:24 2010 CLEAR? [yn] UNREF FILE I=7561814 OWNER=root MODE=140666 SIZE=0 MTIME=Jun 15 14:45 2010 CLEAR? [yn] UNREF FILE I=13566043 OWNER=root MODE=100644 SIZE=69 MTIME=Jun 15 15:06 2010 CLEAR? [yn] UNREF FILE I=22138926 OWNER=root MODE=100444 SIZE=38016 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139000 OWNER=root MODE=100444 SIZE=20472 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139005 OWNER=root MODE=100444 SIZE=21088 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139052 OWNER=root MODE=100444 SIZE=40600 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139096 OWNER=root MODE=100444 SIZE=38872 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139109 OWNER=root MODE=100444 SIZE=5800 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139118 OWNER=root MODE=100444 SIZE=8160 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139120 OWNER=root MODE=100444 SIZE=9736 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139122 OWNER=root MODE=100444 SIZE=6872 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139124 OWNER=root MODE=100444 SIZE=7080 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139127 OWNER=root MODE=100444 SIZE=6840 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139131 OWNER=root MODE=100444 SIZE=5320 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139139 OWNER=root MODE=100444 SIZE=5352 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139142 OWNER=root MODE=100444 SIZE=5888 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139144 OWNER=root MODE=100444 SIZE=5624 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139151 OWNER=root MODE=100444 SIZE=13752 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139155 OWNER=root MODE=100444 SIZE=35840 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139174 OWNER=root MODE=100444 SIZE=4 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139214 OWNER=root MODE=100444 SIZE=63128 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139223 OWNER=root MODE=100444 SIZE=35712 MTIME=Jun 15 09:23 2010 CLEAR? [yn] UNREF FILE I=22139256 OWNER=root MODE=100444 SIZE=293128 MTIME=Jun 15 09:24 2010 CLEAR? [yn] UNREF FILE I=22139328 OWNER=root MODE=100555 SIZE=151784 MTIME=Jun 15 09:24 2010 CLEAR? [yn] UNREF FILE I=22139335 OWNER=root MODE=100444 SIZE=108320 MTIME=Jun 15 09:23
