From owner-freebsd-current Mon May 18 10:06:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14537 for freebsd-current-outgoing; Mon, 18 May 1998 10:06:00 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA14512 for ; Mon, 18 May 1998 10:05:44 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA07351; Mon, 18 May 1998 17:21:46 +0200 From: Luigi Rizzo Message-Id: <199805181521.RAA07351@labinfo.iet.unipi.it> Subject: Re: ATAPI CDDA Extraction under FreeBSD To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 18 May 1998 17:21:45 +0200 (MET DST) Cc: regnauld@deepo.prosa.dk, current@FreeBSD.ORG In-Reply-To: <199805181655.JAA04143@rah.star-gate.com> from "Amancio Hasty" at May 18, 98 09:55:22 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Perhaps, it would be an interesting exercise to use dma to read audio > tracks on a IDE cdrom. i first want to see proper timeout handling on the IDE bus (and i don't see anyone else going to implement it, so ...) This said, there was probably someone who backported the IDE-DMA stuff to 2.2.X, but i also saw some comments on its little gain in performance, and maybe some stability problems ?, that did not encourage me to test them. > I don't think that for instance in a scsi subsystem that any one process > can hug a scsi drive for starters once the process is not running other > process will be able to issue disk requests. the problem i see is that a request can produce a lot of data back. Theoretically it could happen that process P makes a request then blocks, data start come in on the bus, thus blocking other processes from doing requests, process P wakes up because its data have come back (and maybe more are still coming), it issues another request finding the bus free, and so on. Unless of course something is preventing this form of synchronization between process and peripherals. I think we all have experienced this kind of problem when a big program coredumps and monopolizes requests to the FS layer. Things like this (capture effect) are also reported in the literature on ethernet. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message