Date: Tue, 4 Jan 2000 09:13:25 +0100 (CET) From: Soren Schmidt <sos@freebsd.dk> To: green@FreeBSD.org (Brian Fundakowski Feldman) Cc: current@FreeBSD.org Subject: Re: ATA atapi-all.c problems/fixes/cleanups Message-ID: <200001040813.JAA84062@freebsd.dk> In-Reply-To: <Pine.BSF.4.10.10001040243220.951-100000@green.dyndns.org> from Brian Fundakowski Feldman at "Jan 4, 2000 02:52:07 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001040813.JAA84062>