Hi,
I was playing around in the arch code of OpenBSD/i386 lately, and again
and again found that sys/user.h was not safe against multiple inclusions
from the same source file. Is that for a reason? One of my header files
needs to include sys/user.h, which creates a huge mess.
The following patch
CURSO TALLER
Aprenda a Otorgar Creditos Sanos, Prevenga y Recupere su Cartera Vencida
Experto instructor: Lic. Juan Manuel Lopez Vitela )
Duracion: (1 dia) 10 hrs.
Inversion: $4,200 pesos mas IVA / 420 dlls.
Objetivo: Capacitar
> Date: Mon, 20 Dec 2010 18:36:54 +
> From: Miod Vallat
>
> I just noticed this morning that msleep() will not behave correctly on
> some platforms, when passed a mutex associated to the IPL_NONE level
> (i.e. plain mutex, without an associated spl semantic).
>
> msleep() needs to run at spl
I am working on this bug and it is a side effect of wrapping VOP_*
calls. krw meanwhile commited a fix for the bug that exposed the panic
and should make your test case happy. The underlying bug needs more
work though but I am working on it.
On Mon, Dec 20, 2010 at 06:59:00PM +0100, Andreas Bart
I just noticed this morning that msleep() will not behave correctly on
some platforms, when passed a mutex associated to the IPL_NONE level
(i.e. plain mutex, without an associated spl semantic).
msleep() needs to run at splsched(), and fiddles with the mutex fields
to make sure mtx_leave() will n
On 12/20/10 18:26, Kenneth R Westerback wrote:
...
Can you provide the details on the exact panic you saw? Just to make sure
when an issue is reproduced we know we are working on the same problem.
Debugger
panic
sr_crypto_finish_io
sr_crypto_intr
sdstrategy
spec_strategy
VOP_STRATEGY
sr_startw
On Mon, Dec 20, 2010 at 5:46 PM, Mark Kettenis
wrote:
>> Date: Mon, 20 Dec 2010 17:29:36 +0100
>> From: Mike Belopuhov
>>
>> On Mon, Dec 20, 2010 at 5:11 PM, Mark Kettenis
wrote:
>> >> Date: Mon, 20 Dec 2010 16:12:24 +0100
>> >> From: Claudio Jeker
>> >>
>> >> With the change in rev. 1.99 of su
On Sun, Dec 19, 2010 at 02:17:46PM +0100, Andreas Bartelt wrote:
> Hello,
>
> I've noticed that the size of softraid(4) disks is one sector too large.
>
> In the following description, the native disk is sd4c (which is of type
> RAID), and the corresponding virtual softraid(4) disk will be sd5.
On Mon, Dec 20, 2010 at 04:44:36PM +0100, Claudio Jeker wrote:
> ip6s_exthdrtoolong is not used at all so why bother keeping it around?
> I guess this was a pre-m_pulldown() counter but is now unused.
>
> --
> :wq Claudio
>
> Index: sys/netinet6/ip6_var.h
> ==
> Date: Mon, 20 Dec 2010 17:29:36 +0100
> From: Mike Belopuhov
>
> On Mon, Dec 20, 2010 at 5:11 PM, Mark Kettenis
> wrote:
> >> Date: Mon, 20 Dec 2010 16:12:24 +0100
> >> From: Claudio Jeker
> >>
> >> With the change in rev. 1.99 of subr_pool() changing the limit
> >> will no longer set the hi
On Mon, Dec 20, 2010 at 5:11 PM, Mark Kettenis
wrote:
>> Date: Mon, 20 Dec 2010 16:12:24 +0100
>> From: Claudio Jeker
>>
>> With the change in rev. 1.99 of subr_pool() changing the limit
>> will no longer set the high watermark as well.
>> This causes i386 to stop forwading packets on very busy s
Još niste pronašli novogodišnje poklone?
Najnoviji hit proizvodi koje ste D
ekali!
Odaverite prave stvari za najdraE>e bez D
ekanja u redovima i probijanja
kroz guE>vu.
Naš Deda Mraz donosi poklone na kuDnu adresu!
Kliknite i poruD
ite HIT 2010. odmah!
Saznajte prvi koji su najbolji novog
On 12/20/10 17:11, Mark Kettenis wrote:
Date: Mon, 20 Dec 2010 16:12:24 +0100
From: Claudio Jeker
With the change in rev. 1.99 of subr_pool() changing the limit
will no longer set the high watermark as well.
This causes i386 to stop forwading packets on very busy systems because
the pool thread
> Date: Mon, 20 Dec 2010 16:12:24 +0100
> From: Claudio Jeker
>
> With the change in rev. 1.99 of subr_pool() changing the limit
> will no longer set the high watermark as well.
> This causes i386 to stop forwading packets on very busy systems because
> the pool thread is not fast enough to repl
ip6s_exthdrtoolong is not used at all so why bother keeping it around?
I guess this was a pre-m_pulldown() counter but is now unused.
--
:wq Claudio
Index: sys/netinet6/ip6_var.h
===
RCS file: /cvs/src/sys/netinet6/ip6_var.h,v
retri
With the change in rev. 1.99 of subr_pool() changing the limit
will no longer set the high watermark as well.
This causes i386 to stop forwading packets on very busy systems because
the pool thread is not fast enough to replenish the pool. So reintroduce
the pool_sethiwat() in this particular case
On Mon, Dec 20, 2010 at 08:06:33AM -0500, Kenneth R Westerback wrote:
> On Mon, Dec 20, 2010 at 06:24:17PM +1000, David Gwynne wrote:
> > On Mon, Dec 20, 2010 at 04:26:59PM +1000, David Gwynne wrote:
> > > im pretty sure scsi reports the last addressable sector, as opposed to the
> > > total number
On Thu, Nov 25, 2010 at 07:13:04PM +0100, Henning Brauer wrote:
> * Claudio Jeker [2010-11-25 17:04]:
> > I doubt that there is a measurable performance difference on
> > i386/amd64.
>
> yeah, well, "doubt". pls run a quick test.
>
Well this was not "quick" but I finally finsihed the testing.
Nikon P100 USD479 Nikon D3000 Kit 18-55 USD
690 Nikon D5000 Kit
18-55 USD943,50 Nikon
D3100 Kit 18-55 USD980 Nikon S203 USD
On Mon, Dec 20, 2010 at 11:50:21AM +0100, Andreas Bartelt wrote:
> On 12/19/10 22:28, Kenneth R Westerback wrote:
> ...
> >You should NEVER use 'c' partition. Amoung other things, it is
> >always set by the kernel to encompass the whole disk, everytime the
> >disklabel is read. If you restore to a
On Mon, Dec 20, 2010 at 06:24:17PM +1000, David Gwynne wrote:
> On Mon, Dec 20, 2010 at 04:26:59PM +1000, David Gwynne wrote:
> > im pretty sure scsi reports the last addressable sector, as opposed to the
> > total number of sectors. will have a diff shortly.
>
> compiles. can someone test?
Prett
On 12/19/10 22:28, Kenneth R Westerback wrote:
...
You should NEVER use 'c' partition. Amoung other things, it is
always set by the kernel to encompass the whole disk, everytime the
disklabel is read. If you restore to a different sized disk interesting
things might happen. I thought we also alwa
On Mon, Dec 20, 2010 at 04:26:59PM +1000, David Gwynne wrote:
> im pretty sure scsi reports the last addressable sector, as opposed to the
> total number of sectors. will have a diff shortly.
compiles. can someone test?
Index: softraid.c
===
23 matches
Mail list logo
