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
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 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
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 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
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
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
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
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
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)
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
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.
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
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 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 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: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 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: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 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
>* 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
* 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
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
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
24 matches
Mail list logo
