On Friday 05 November 2010 20:06:12 John Baldwin wrote:
> On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote:
> > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote:
> > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky
> >
> > wrote:
> > > > On Friday 05 November 2010
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm just
wondering why the same c++ code is working on 8_STABLE and it's segfaultin
* Barbara , 20101106 10:57:
> Just to be clear, I'm not looking for a solution about the port here,
> I'm just wondering why the same c++ code is working on 8_STABLE and
> it's segfaulting on CURRENT, considering also that AFAIK the gcc
> version in both the base system
>* Barbara , 20101106 10:57:
>> Just to be clear, I'm not looking for a solution about the port here,
>> I'm just wondering why the same c++ code is working on 8_STABLE and
>> it's segfaulting on CURRENT, considering also that AFAIK the gcc
>> version
>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>>
>> I had a problem running the IcedTea java plugin on CURRENT i386, while it
>> works on 8_STABLE.
>> But maybe it's not a problem related to the port.
>> Just to be clear, I'm not looking for a solution about the port here, I'm
just
>> wonder
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu wrote:
> On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>>
>> I had a problem running the IcedTea java plugin on CURRENT i386, while it
>> works on 8_STABLE.
>> But maybe it's not a problem related to the port.
>> Just to be clear, I'm not looking for a
On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote:
>
>
>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>>>
>>> I had a problem running the IcedTea java plugin on CURRENT i386, while it
>>> works on 8_STABLE.
>>> But maybe it's not a problem related to the port.
>>> Just to be clear, I'm not lookin
On Sat, Nov 6, 2010 at 11:32 AM, Vlad Galu wrote:
> On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu wrote:
>> On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>>>
>>> I had a problem running the IcedTea java plugin on CURRENT i386, while it
>>> works on 8_STABLE.
>>> But maybe it's not a problem relat
On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>
> I had a problem running the IcedTea java plugin on CURRENT i386, while it
> works on 8_STABLE.
> But maybe it's not a problem related to the port.
> Just to be clear, I'm not looking for a solution about the port here, I'm just
> wondering why th
>On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote:
>>
>>
>>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm
On Sat, Nov 6, 2010 at 11:44 AM, Barbara wrote:
>
>>On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote:
>>>
>>>
On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>
> I had a problem running the IcedTea java plugin on CURRENT i386, while it
> works on 8_STABLE.
> But maybe it's not
On Sat, Nov 6, 2010 at 1:37 AM, Hans Petter Selasky wrote:
> On Friday 05 November 2010 20:06:12 John Baldwin wrote:
>> On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote:
>> > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote:
>> > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Pe
Hi,
On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote:
>
> I think you're misunderstanding the existing taskqueue(9) implementation.
>
> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change,
> nor can the set of running tasks. So the order of checks is
> irrelevant.
El día Friday, November 05, 2010 a las 01:13:15AM +0200, Alexander Motin
escribió:
> > # mixer -f /dev/mixer1
> > Mixer rec is currently set to 100:100
> > Mixer monitor is currently set to 100:100
> > Recording source: monitor
>
> That's strange. I would expect it working.
>
> > Would yo
On Fri, Nov 5, 2010 at 8:57 AM, Anonymous wrote:
> A few examples from ports tree
>
> devel/automake111: automake-1.11(1)
> devel/gettext: dcgettext(3), dcngettext(3), dgettext(3), dngettext(3)
> devel/nasm: rdf2com(1), rdf2ihx(1), rdf2ith(1), rdf2srec(1)
> textproc/gnugrep: egrep(1), fgrep(1)
1st 0x80990308 PFil read/write mutex (PFil hook read/write
mutex @ /usr/src/head/sys/net/pfil.c:77
2nd 0x80991528 tcp (tcp)
@ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702
KDB: stack backtrace:
db_trace_self_wrapper()
kdb_backtrace()
_witness_debugger()
witness_checkorde
Hi,
I got a similar panic on amd64. Looking into the source it hit
KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with
a printf to see what triggered the assertion and here is the output.
Combined with memcontrol output 'bogus' keyword it seems buggy BIOS
violated some kind of sp
Today I came back to my computer and realised I'd left ttyv0 in
history/scrollback mode, with scroll-lock enabled. To see what
would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to
see that it seemed to get partway through the process but it never
rebooted: the other ttys were kille
On 11/6/10, Bruce Cran wrote:
> Today I came back to my computer and realised I'd left ttyv0 in
> history/scrollback mode, with scroll-lock enabled. To see what
> would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to
> see that it seemed to get partway through the process but it ne
On 11/6/10, Jia-Shiun Li wrote:
> Hi,
>
> I got a similar panic on amd64. Looking into the source it hit
> KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with
> a printf to see what triggered the assertion and here is the output.
> Combined with memcontrol output 'bogus' keyword
Paul B Mahol wrote:
On 11/6/10, Jia-Shiun Li wrote:
Hi,
I got a similar panic on amd64. Looking into the source it hit
KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with
a printf to see what triggered the assertion and here is the output.
Combined with memcontrol output '
On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote:
> Hi,
>
> On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote:
>>
>> I think you're misunderstanding the existing taskqueue(9) implementation.
>>
>> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change,
>> nor can
On 6 November 2010 20:27, Bruce Cran wrote:
> 1st 0x80990308 PFil read/write mutex (PFil hook read/write
> mutex @ /usr/src/head/sys/net/pfil.c:77
> 2nd 0x80991528 tcp (tcp)
> @ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702
> KDB: stack backtrace:
> db_trace_self_wrappe
On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote:
> Hi,
>
> In the patch attached to this e-mail I included Matthew Fleming's patch
> aswell.
>
> 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles
> the words of the callout and USB API's terminology f
24 matches
Mail list logo
