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 hsela...@c2i.net
wrote:
On Friday 05 November
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
* Barbara barbara.xxx1...@libero.it, 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 systems
* Barbara barbara.xxx1...@libero.it, 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 systems
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it 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
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it 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
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it 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.
On Sat, Nov 6, 2010 at 11:32 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it 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
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it 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.
On Sat, Nov 6, 2010 at 11:44 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while
On Sat, Nov 6, 2010 at 1:37 AM, Hans Petter Selasky hsela...@c2i.net 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,
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.
I
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 you be so kind
On Fri, Nov 5, 2010 at 8:57 AM, Anonymous swel...@gmail.com 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:
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()
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
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
On 11/6/10, Bruce Cran br...@cran.org.uk 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
On 11/6/10, Jia-Shiun Li jiash...@gmail.com 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
Paul B Mahol wrote:
On 11/6/10, Jia-Shiun Li jiash...@gmail.com 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
On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky hsela...@c2i.net 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
On 6 November 2010 20:27, Bruce Cran br...@cran.org.uk 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:
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 for
24 matches
Mail list logo
