Shaowei Wang (wsw) wrote:
try -L zh_CN.euc .
zh_CN.euc doesn't exist, I tried zh_CN.eucCN instead. Didn't work.
I tried all zh_CN* and zh_TW* ones from /usr/share/locale/ -- none of
them worked.
Nut the garbage displayed by 'ls' changes depending on the one used.
Windows file system use a
On Tue, Apr 7, 2009 at 2:00 PM, Yuri y...@rawbw.com wrote:
Shaowei Wang (wsw) wrote:
try -L zh_CN.euc .
zh_CN.euc doesn't exist, I tried zh_CN.eucCN instead. Didn't work.
I tried all zh_CN* and zh_TW* ones from /usr/share/locale/ -- none of them
worked.
Nut the garbage displayed by 'ls'
I've been thinking about this some more. So, clearly, sw watchdog is different
from all the hw watchdogs (that I know about) in that it tries to take a
debugging
action as opposed to a straightforward recovery action. As such it currently
doesn't make much sense to mix sw and hw watchdogs
Gabriele, Robert,
Am 02.04.2009 um 19:26 schrieb Robert Watson:
In the BeOS model, or my reinterpretation based on something I read
a long time ago and then presumably had dreams about, the split is a
bit different: the file system maintains indexes of extended
attributes, which are
On Tue, 7 Apr 2009, Stephan Lichtenauer wrote:
Am 02.04.2009 um 19:26 schrieb Robert Watson:
In the BeOS model, or my reinterpretation based on something I read a long
time ago and then presumably had dreams about, the split is a bit
different: the file system maintains indexes of extended
On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote:
John Baldwin wrote:
On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote:
2009/4/6 John Baldwin j...@freebsd.org:
On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote:
Hmm, the problem is we need to be able to write to
On Tue, Apr 7, 2009 at 9:21 AM, John Baldwin j...@freebsd.org wrote:
On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote:
John Baldwin wrote:
On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote:
2009/4/6 John Baldwin j...@freebsd.org:
On Sunday 05 April 2009 12:23:39 pm Sergey
(Let's see if I've figured yet another workaround for the web
interface= ).
The address space used by the card I think is actually 0x80 bytes= ,
in the I/O port space. The card has it located at the port 0xEC00.
Yester= day I've had all the values and addresses written to this
I have registered and pointed to my name server the following domains:
istudentunion.com (.net and .org)
They resolve locally but do not resolve remotely it has been 24 hrs
so some propagation should of occured... I tested resolving remotely
with hardcoding the nameserver to be me and
I have registered and pointed to my name server the following domains:
istudentunion.com (.net and .org)
They resolve locally but do not resolve remotely it has been 24 hrs
so some propagation should of occured... I tested resolving remotely
with hardcoding the nameserver to be me and
Aryeh M. Friedman wrote:
Already did (went a step farther had my machine at home -CURRENT use
the one at work [the one with the probldem] as it's /etc/resolv.conf
and as a forwarder in my named.conf and both worked fine)
Forgot to mention that different ISP's so it is not a port blocking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aryeh M. Friedman wrote:
I have registered and pointed to my name server the following domains:
istudentunion.com (.net and .org)
They resolve locally but do not resolve remotely it has been 24 hrs
so some propagation should of occured...
Already did (went a step farther had my machine at home -CURRENT use the
one at work [the one with the probldem] as it's /etc/resolv.conf and as
a forwarder in my named.conf and both worked fine)
Xin LI wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aryeh M. Friedman wrote:
I have
It appears that the KLD build process is missing a ctfmerge at the end, and
this results in KLDs with incomplete CTF information.
Here is a patch that fixes this. I verified it on amd64 with various KLDs.
Before:
# ctfdump /boot/kernel/if_cxgb.ko | wc -l
2269
# ctfdump /boot/kernel/zfs.ko | wc
John Baldwin wrote:
On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote:
Anyway, as far as I can tell, it's only the base register of
the simulated DEC21140 device that has this issue, so it's
quite possible that the bug is in that device's simulator.
I've attached a modified
15 matches
Mail list logo
