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 togethe
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 writ
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 at
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 :
> > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote:
> > >
> > > > Hmm, the problem is we need to be able to write t
On Tue, Apr 7, 2009 at 9:21 AM, John Baldwin 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 :
>> > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote:
>> >
(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
ca
> 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
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 that
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 prob
-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 occure
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 r
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 m
13 matches
Mail list logo
