i can reliably produce a situation where an io on a disk attached
to mpii(4) never completes. this implements timeouts on scsi io so
we can recover from this situation.
ok?
Index: mpii.c
===
RCS file: /cvs/src/sys/dev/pci/mpii.c,v
re
hi guys,
this makes mpii properly detach devices, which helps a lot if they
have commands in flight. to relevant changes are:
- call the activate(DVACT_DEACTIVATE) function against all the luns
on the target that is going away.
- issue the target reset BEFORE detaching the children devices.
this
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
This offer is reserved to adults.
By clicking on any of the links in this mail, you certify that you are
over 18.
I will test this patch with my Linksys rum(4) AP tonight and report back
to you.
-luis
On 12/22/10 18:36, Jacob Meuser wrote:
no feedback yet. anyone care to comment on this?
On Thu, Dec 16, 2010 at 12:28:56AM +, Jacob Meuser wrote:
the following diff tries to make sure that no other pr
> What do you mean exactly by "OpenBSD is consuming"? Are you referring to
> the kernel or userland arc4random?
> > Probably you think these are ridiculous questions.
> HMM PERHAPS I'LL GO LOOK AT THE SOURCE CODE AND FIND OUT FOR MYSELF.
> Back.
Haven't you done this already? So you don't know wh
> How much did you get?
> Is it safe for the boot process to generate keys now?
If you can only read.
On Thu, Dec 23, 2010 at 07:02:47AM +, Jordan Hargrave wrote:
>
> Bad AML. Looks like it is trying to do an AML Load of a memory block, and
> that is failing.
> Usually that's because the checksum is incorrect. Look at dsdt.c:aml_load()
> and put printf's at both goto fails', to see what is
On Thu, Dec 23, 2010 at 01:30:15PM +0100, Thomas Pfaff wrote:
> On Thu, 23 Dec 2010 00:36:26 +
> Jacob Meuser wrote:
>
> > no feedback yet. anyone care to comment on this?
> >
> > > this diff covers rum(4), run(4), ural(4) and urtw(4). without the
> > > diff, I can get the kernel to crash
[IMAGE]
[IMAGE]
Buenos dmas, en esta oportunidad queremos compartir con usted siete
nuevas estrategias para maximizar la visibilidad de su empresa
minimizando su inversisn , lo cual le puede ser de gran utilidad.
A continuacisn podra observar los 7 puntos de los que vamos a hablar en
nuestro siti
On Thu, Dec 23, 2010 at 04:12:43PM +0100, Claudio Jeker wrote:
> dhcpd has own logging functions so use those instead of the syslog_r()
> calls. With this -d will actually work as expected. Appart from that add
> additional warning messages if the sendmsg() call fails.
>
> OK?
ok. Tested with dhc
dhcpd has own logging functions so use those instead of the syslog_r()
calls. With this -d will actually work as expected. Appart from that add
additional warning messages if the sendmsg() call fails.
OK?
--
:wq Claudio
Index: sync.c
==
On 23 December 2010 22:24, Marsh Ray wrote:
> It's a really good question: how do you prove that something is
> unpredictable?
>
> In the US, it is the agency NIST.
You can't.
So can we give this BS a rest?
On Thu, 23 Dec 2010 00:36:26 +
Jacob Meuser wrote:
> no feedback yet. anyone care to comment on this?
>
> > this diff covers rum(4), run(4), ural(4) and urtw(4). without the
> > diff, I can get the kernel to crash by starting a scan with
> > the deice, then ejecting it while the scan is ru
On Thu, Dec 23, 2010 at 11:39:59AM +0100, Kurt Knochner wrote:
> 2010/12/22 Marsh Ray :
> > In any case, generic statistical tests might detect really horrible
> > brokenness but they're are not the thing to certify CSRNGs with.
>
> Really? So, how do you certify the IMPLEMENTATION (bold, not shou
On 12/23/2010 04:39 AM, Kurt Knochner wrote:
2010/12/22 Marsh Ray:
In any case, generic statistical tests might detect really
horrible brokenness but they're are not the thing to certify CSRNGs
with.
Really? So, how do you certify the IMPLEMENTATION (bold, not
shouting) of a CSRNG, (not the t
2010/12/22 Marsh Ray :
> Well if that's your goal, I think you probably need to patch the kernel to
> DMA the stuff into video RAM and offload the processing of it there. :-) Or
> something else, be creative. Try to write a backdoor
good ideas, I will consider them ;-)
> In any case, generic stat
2010/12/23 Clint Pachl :
> The last time I installed FreeBSD about 5 years ago, it asked me to pound on
> the keyboard for like 60 seconds during installation (or at first boot,
> can't remember) in order to build up some "randomness". I wonder what kind
> of entropy that provided?
run it through
On 12/22/2010 02:34 PM, Theo de Raadt wrote:
Which is why I'm wondering what exactly, this 'multi-consumer' design
feature is all about. Is it simply that more userland stuff is pinging
the kernel at unpredictable times resulting in more timestamps feeding
into the central entropy pool? It seems
On Thu, Dec 23, 2010 at 10:43:49AM +0100, olli hauer wrote:
> On 2010-12-23 09:44, Clint Pachl wrote:
> > Salvador Fandiqo wrote:
> >> On 12/23/2010 06:39 AM, Marsh Ray wrote:
> >>> On 12/22/2010 03:49 PM, Clint Pachl wrote:
> Salvador Fandiqo wrote:
> >
> > Could a random seed be pat
On 2010-12-23 09:44, Clint Pachl wrote:
> Salvador Fandiqo wrote:
>> On 12/23/2010 06:39 AM, Marsh Ray wrote:
>>> On 12/22/2010 03:49 PM, Clint Pachl wrote:
Salvador Fandiqo wrote:
>
> Could a random seed be patched into the kernel image at installation
> time?
> Admittedly thi
Salvador Fandiqo wrote:
On 12/23/2010 06:39 AM, Marsh Ray wrote:
On 12/22/2010 03:49 PM, Clint Pachl wrote:
Salvador Fandiqo wrote:
Could a random seed be patched into the kernel image at installation
time?
Admittedly this is not entropy, this is a just secret key and anyone
with access to th
On 12/23/2010 06:39 AM, Marsh Ray wrote:
On 12/22/2010 03:49 PM, Clint Pachl wrote:
Salvador Fandiqo wrote:
Could a random seed be patched into the kernel image at installation
time?
Admittedly this is not entropy, this is a just secret key and anyone
with access to the machine would be able t
22 matches
Mail list logo
