From owner-freebsd-current Tue Jan 4 0:13:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 6351415080; Tue, 4 Jan 2000 00:13:26 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id JAA84062; Tue, 4 Jan 2000 09:13:25 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200001040813.JAA84062@freebsd.dk> Subject: Re: ATA atapi-all.c problems/fixes/cleanups In-Reply-To: from Brian Fundakowski Feldman at "Jan 4, 2000 02:52:07 am" To: green@FreeBSD.org (Brian Fundakowski Feldman) Date: Tue, 4 Jan 2000 09:13:25 +0100 (CET) Cc: current@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Brian Fundakowski Feldman wrote: > On Tue, 4 Jan 2000, Soren Schmidt wrote: > > > Either the patch is very short, or you forgot to include it :) > > *LOL* I can't believe I did that :) It'll be on this one!! Yup, this time there is a patch :) > > The ATA_16BIT_ONLY thing is to only do 16bit wide inb/outb instructions > > as old ISA HW don't allow 32bit wide access. This option is now deprecated > > as it is switched on automagically for ISA cards. > > Is all data a multiple of 4 bytes, though? Not really, ie there is nothing that says so. However ALL requests should be of length N*blocksize where N can be from 1 to 254. Blocksize is depending on the format used but normally 2048 or 2352 bytes... > > You _should_ _always_ have dd (or whatever you use) pad the output to the > > given blocksize, or you will run into problems. > > IMHO, it should be better to use a larger multiple of block size (2352) > to not perform so many operations in userland (since the kernel does a > great job of doing writes in the right size in order). Then, it would > be pessimal to use "conv=osync" because you'd lose more room from the > media. But anyway, the padding should work properly, no matter what :) The problem here is that you will then do a lot of unneeded padding as the driver will attempt to pad to the blocksize used which is not wanted. You HAVE to use the right blocksize especially for audio, or you will get "silent" ie zero padded blocks on disk, and thats not what you want is it ? > Thanks for the prompt reply! Now I'll remember that patch... Your'e welcome... What should be done is that we need a new util instead of wormcontrol and dd to do burning. I dont see me having time anytime soon, too much to do (DVD + DVD-RAM support, more chipsets etc etc), so I'm on my way to add an ioctl interface that cdrecord can use.... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message