February 2002 - Packet Writing - openSUSE Mailing Lists

Teac CD-W524E Problems (slowness and corruption)
by Ironhide 03 Feb '02

03 Feb '02

I (very recently) purchased a Teac CD-W524E drive. Unfortunately, it does not seem to be very compatible with pktcdvd. To be specific, it is EXTREMELY slow (ls on a relatively small directory once took five minutes; writing 150 megabytes to the disc and umounting it took over an hour!) and the discs seem to be highly prone to spontaneous corruption (for instance, an attempt at an ls of a file that should be there results in "permission denied" errors). IDE and SCSI emulation modes produced no difference in results that I could detect. Following is an excerpt from the log from a typical write. Notice the five minute delay towards the end. I didn't include the whole log excerpt because the operation generated about 8 megabytes of logging info. :) I did notice the log comments were very different than those left by the Sony CRX175A, which I managed to get to operate successfully. If anyone could help me with this, I'd appreciate it. I'd like Mount Rainier support on a drive, and Teac supposedly has it, but if I can't get it to work on Linux I'll have to take it back in about ten days to get my money back. Any help you can give me would be greatly appreciated. If it matters, I am running kernel 2.4.17. Jan 13 19:49:48 darkstar kernel: unlocked last 699772 Jan 13 19:49:48 darkstar kernel: __pkt_inject_request: list_empty == 1, size=4, cmd=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174912, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174913, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174914, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174915, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174916, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174917, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174918, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=37077102, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174920, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174921, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174922, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174923, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174924, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174925, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174926, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174927, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174928, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174929, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174930, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174931, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174932, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174933, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174934, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174935, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174936, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174937, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174938, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174939, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174940, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174941, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174942, uptodate=1 Jan 13 19:49:48 darkstar kernel: end_io_write: bh=174943, uptodate=1 Jan 13 19:49:48 darkstar kernel: pkt_rq_end_io: rq=ce5ecf00, cmd=1, q=00000000 Jan 13 19:49:48 darkstar kernel: handle_queue Jan 13 19:49:48 darkstar kernel: pkt_request: cmd=1, rq=ce5eb200, rq->sector=700020, rq->nr_sectors=4 Jan 13 19:49:48 darkstar kernel: wake up wait queue Jan 13 19:49:48 darkstar kernel: handle_queue Jan 13 19:49:48 darkstar kernel: do_request: bh=37077101, nr_sectors=4, size=128, cmd=1 Jan 13 19:49:48 darkstar kernel: pkt_gather_data: cmd=1 Jan 13 19:49:48 darkstar kernel: need 124 sectors for 0b:01 Jan 13 19:49:48 darkstar kernel: from 699904 to 700032 <5>(700020 - 700024) Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699904, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699908, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699912, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699916, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699920, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699924, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699928, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699932, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699936, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699940, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699944, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699948, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699952, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699956, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699960, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699964, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699968, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699972, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699976, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699980, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699984, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699988, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699992, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=699996, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=700000, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=700004, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=700008, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=700012, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=700016, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=700024, size=2048 Jan 13 19:49:48 darkstar kernel: get_buffer: sector=700028, size=2048 Jan 13 19:56:27 darkstar kernel: unlocked last 700028 Jan 13 19:56:27 darkstar kernel: __pkt_inject_request: list_empty == 1, size=4, cmd=1 __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

4 7

can't use a udf cd
by David Cougle 02 Feb '02

02 Feb '02

I have latest kernel, and latest udf tools. I format the cd, but get errors on mount, even though pktsetup was used, and it says it cannot mount it(in order to write to it) because of bad file system or bad blocks or something. -- http://www.mp3.com/lunarbard ICQ #3795561, Yahoo IM lunarbard1979 David Cougle on AOL(Instant Messenger) Microsoft Messenger davidcougle 1 John 4:11

1 0

DVD-RW
by Keith Bennett 01 Feb '02

01 Feb '02

Hi, I've recently aquired a Pioneer DVR-A03 DVD-RW drive. I would like to get this working with packet writing but according to the patch, it doesn't work for DVD-RW. Could someone let me know what is required to make it work and if the packet-writing patch is the best starting point. I have no kernel progamming experience (except for modifying a few patches to work with new kernels, etc.) but I have a reasonable knowledge of C and am willing to learn. Keith. -- =============================================================================== Dr Keith Bennett tel: +44 (0)1334 463735 School of Mathematics and Statistics, fax: +44 (0)1334 463748 University of St. Andrews, email: keith(a)mcs.st-and.ac.uk St. Andrews, Fife KY16 9SS SCOTLAND http://www-solar.mcs.st-and.ac.uk/~keith ===============================================================================

2 2

New cdrwtool (trying to format too many blocks)
by Ben Fennema 01 Feb '02

01 Feb '02

If your seeing the new cdrwtool fail and the value for blocks is more than it used to be, could you send me the output of cdrwtool -i. The new code bases the number of blocks on the lead_out, which looks like it can lie as bad as the track_size.. joy =) Ben

2 1