---------- Forwarded message ----------
Date: Wed, 30 Aug 2000 00:26:13 +0100 (GMT)
From: Damon LoCascio <dlocasci@seaforn.dircon.co.uk>
To: Douglas Gilbert <dougg@torque.net>
Subject: Re: Silent breakage of cdrecord under 2.4?
On Tue, 29 Aug 2000, Douglas Gilbert wrote:
> Damon,
> Sounds worrying. I have done a fair amount of testing
> with sg in lk 2.4 and haven't seen a problem like this.
> My adapters are also from advansys (but singles, not
> quads). Could you send me a sample of the corruption
> (100 byte one would be fine). Are you using SMP?
>
> A loop through character device, sitting between cdrecord
> and sg would be useful in such situations.
>
> Doug Gilbert
>
I have just put together a table of what works and what doesn't
under 2.4-test5. All I know for sure is that cdrecord 1.6 compiled against
2.2.16 and running under 2.2.16 works flawlessly. Attached is the results.
As you can see I compiled against both the 2.2.16 trees and
2.4.0-test5 ones. Though I only ran it under 2.4. I suspect it would
prolly work better under 2.2.16 but then again that is what I am noticing
:) cdrecord is doing strange things in the later kernels? I'm not using
SMP though, which in theory might make things easier to track???
How do I go about seting up a loop through device before the sg driver
just out of interest?
Don't know if this is any good. It's never very much corruption just a few
bytes here and there? Or in this case a chunk of them
-- cmp /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3 /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3 differ: char 3754969, line 13388-- cmp -l /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3
3754969 372 251 3754970 263 23 3754971 16 234 3754972 144 65 3754973 254 203 3754974 301 22 3754975 101 77 3754976 31 2
--
cmp /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 differ: char 746761, line 3054
--
cmp -l /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 746761 375 242 746762 67 70 746763 72 343 746764 1 5 746765 264 60 746766 242 274 746767 50 231 746768 10 150
--
Hmmmm I'm beginnning to see a pattern now..? 8 bytes????
Q. Is though.. why just these 3 files with the latest version of cdrecord?
Arrrrg this is gonna drive me nuts?!
;)
Will this enlighten us all I wonder?
Cheers,
-- ===
"If you can keep your head when all about you are losing theirs... you're missing something IMPORTANT!" Rob. (prolly teefed tho')
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:28 EST