[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-security
Subject:    Re: signal handling in urandom can cause lockup
From:       Bruce Evans <bde () zeta ! org ! au>
Date:       1999-01-28 2:22:06
[Download RAW message or body]

>	This is very interesting.  For some time (I use FreeBSD on my
>desktop as well as for 50 odd servers) my desktop machine has been
>exhibiting a freeze that seems to coinside with intense swapping or
>writing to the disk.  This 'freeze' survived the upgrade from 2.2.7 to
>3.0.

>	Now... my take on the situation had been that IDE is just
>evil.  I have burned out 3 drives (of different brands) in as many
>months (they ranged from 1 month to 1 year old).  I have on order a 9G
>SCSI drive to become the main system and swap drive under the
>assumption that scsi drives are going to be more dependable and will
>not freeze the system.

I have no problems with IDE, and this problem has very little to do with
IDE.  It is a general problem with devices that can transfer large amounts
of data without blocking (not just with slow devices like I said before,
except faster devices tend to limit the denial of service to a second
or two).  E.g., a modern IDE drive can transfer at a rate of 12-15MB/sec.
The default interface is 16-bit PIO mode 1-4 (where the BIOS decides the
mode number).  At best, this transfers data at 8.3MB/sec and takes 100%
of the CPU to do so.  Don't connect a modern IDE drive to this interface.

>	However, it does strike me as bogus that this kind of blocking
>happens.  Maybe this type of patch should be applied to devices in
>general.

It already applies to everything that calls uiomove(), including many
cases involving filesystem i/o.  It doesn't apply to paging or certain
optimised filesystem i/o.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

[prev in list] [next in list] [prev in thread] [next in thread]