After installing 2.4.4 with the 0.02j patch, I ran into the following
difficulties:
---------------------- cdrwtool output ----------------------------------
slacker:/home/rsmith/tmp/src/udf-cvs/udf/tools# ./cdrwtool -d /dev/sr0 -q
using device /dev/sr0
768KB internal buffer
setting write speed to 12x
Settings for /dev/sr0:
Fixed packets, size 32
Mode-2 disc
I'm going to do a quick setup of /dev/sr0. The disc is going to be blanked
and formatted with one big track. All data on the device will be lost!!
Press CTRL-C to cancel now.
Initiating quick disc blank
Disc capacity is 275008 blocks (550016KB/537MB)
Formatting track
---------------------- cdrwtool output ----------------------------------
There was one more line of output, something like:
---------------------- cdrwtool output ----------------------------------
7200 (EST)
---------------------- cdrwtool output ----------------------------------
But it scrolled off the screen before I could write it down, and I can't
remember the precise message.
At this point a lot of error messages appeared in the log file:
--------------------- /var/log/syslog -----------------------------------
Apr 29 13:22:59 slacker kernel: hdc: empty DMA table?
Apr 29 13:23:04 slacker kernel: scsi : aborting command due to timeout : pid 0,
scsi0, channel 0, id 1, lun 0 0x2a 00 00 00 00 00 00 00 20 00
Apr 29 13:23:09 slacker kernel: hdc: irq timeout: status=0xd0 { Busy }
Apr 29 13:23:09 slacker kernel: hdc: DMA disabled
Apr 29 13:23:09 slacker kernel: hdc: ATAPI reset complete
Apr 29 13:23:09 slacker kernel: hdc: irq timeout: status=0xd0 { Busy }
Apr 29 13:23:09 slacker kernel: scsi : aborting command due to timeout : pid 0,
scsi0, channel 0, id 1, lun 0 0x2a 00 00 00 00 00 00 00 20 00
Apr 29 13:23:09 slacker kernel: SCSI host 0 abort (pid 0) timed out - resetting
Apr 29 13:23:09 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:10 slacker kernel: scsi : aborting command due to timeout : pid 0,
scsi0, channel 0, id 1, lun 0 0x2a 00 00 00 00 00 00 00 20 00
Apr 29 13:23:10 slacker kernel: SCSI host 0 abort (pid 0) timed out - resetting
Apr 29 13:23:10 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:10 slacker kernel: scsi : aborting command due to timeout : pid 0,
scsi0, channel 0, id 1, lun 0 0x2a 00 00 00 00 00 00 00 20 00
Apr 29 13:23:10 slacker kernel: SCSI host 0 abort (pid 0) timed out - resetting
Apr 29 13:23:10 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:12 slacker kernel: hdc: ATAPI reset complete
Apr 29 13:23:12 slacker kernel: hdc: irq timeout: status=0xd0 { Busy }
Apr 29 13:23:12 slacker kernel: hdc: status timeout: status=0xd0 { Busy }
Apr 29 13:23:12 slacker kernel: hdc: drive not ready for command
Apr 29 13:23:15 slacker kernel: hdc: ATAPI reset complete
Apr 29 13:23:17 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:17 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:18 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:18 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:20 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:20 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:22 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:22 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:23 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:23 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:24 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:24 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:25 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:25 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:26 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:26 slacker kernel: SCSI bus is being reset for host 0 channel 0.
Apr 29 13:23:27 slacker kernel: scsi0 : channel 0 target 1 lun 0 request sense f
ailed, performing reset.
Apr 29 13:23:27 slacker kernel: SCSI bus is being reset for host 0 channel 0.
--------------------- /var/log/syslog -----------------------------------
At this point, the box seemed to have hung completely; all disk activity
ceased, it didn't respond to keyboard input anymore, and I did a hard
reset.
I've tried several times, but always with the same result. It always hangs
at the end of the disk blanking c.q. beginning of the writing of the
filesystem.
My writer is a Philips CDD 3610, and I'm using scsi emulation. The CDRW
disc I was using had been used before, but I used cdrecord to do a complete
blank beforehand.
I might add that pktsetup worked without errors, but mounting the disk
failed of course, because it couldn't find a valid superblock.
Some drive info:
-------------------------- /proc data ------------------------------------
slacker:/home/rsmith# cat /proc/ide/hdc/model
PHILIPS CDD3610 CD-R/RW
slacker:/home/rsmith# cat /proc/ide/hdc/settings
name value min max mode
---- ----- --- --- ----
bios_cyl 0 0 1023 rw
bios_head 0 0 255 rw
bios_sect 0 0 63 rw
current_speed 33 0 69 rw
ide_scsi 0 0 1 rw
init_speed 33 0 69 rw
io_32bit 0 0 3 rw
keepsettings 0 0 1 rw
log 0 0 1 rw
nice1 1 0 1 rw
number 2 0 3 rw
pio_mode write-only 0 255 w
slow 0 0 1 rw
transform 1 0 3 rw
unmaskirq 0 0 1 rw
using_dma 1 0 1 rw
slacker:/home/rsmith# cat /proc/ide/hdc/identify
8580 0000 0000 0000 0000 0000 0000 0000
0000 0000 3456 4f32 3239 3834 3831 3734
3332 3330 3032 3130 0000 1e78 0000 563a
3030 332e 3031 5048 494c 4950 5320 4344
4433 3631 3020 4344 2d52 2f52 5720 2020
2020 2020 2020 2020 2020 2020 2020 0000
0000 0b00 0000 0200 0200 0002 0000 0000
0000 0000 0000 0000 0000 0000 0007 0203
0001 007f 007f 00d0 007f 0000 0000 0000
On Mon, Apr 30 2001, rsmith@xs4all.nl wrote:
After installing 2.4.4 with the 0.02j patch, I ran into the following difficulties:
Apr 29 13:22:59 slacker kernel: hdc: empty DMA table?
ide-scsi bug. I'd suggest _not_ using ide-scsi with packet writing for now, it seems to buggy in many cases. Pure ide-cd is better then. Does that work for you?
My writer is a Philips CDD 3610, and I'm using scsi emulation. The CDRW disc I was using had been used before, but I used cdrecord to do a complete blank beforehand.
That's not necessary, cdrwtool -q will take a disc in just about any state and make it sane. -- Jens Axboe
On Mon, 30 Apr 2001, Jens Axboe wrote:
ide-scsi bug. I'd suggest _not_ using ide-scsi with packet writing for now, it seems to buggy in many cases. Pure ide-cd is better then. Does that work for you?
I tried with hdd=ide-cd and it didn't work at all, freezing the system. With ide-scsi I was able to copy several big files without problems. One problem: Copying a dir with one big files (300M) took awful long! Somehow it looks like the pktwriter get stuck, the lights on the cdwriter only blinks occasionally, slowly slowly adding bytes to the file. Well, it was working, no crash, nothing, just the copy just came to a halt more or less. I could interrupt the cp process and it finished without problems. So, to my mind this is a real success, no crashes at all. Congratulations. Best wishes Norbert -- ciao norb +-------------------------------------------------------------------+ | Norbert Preining http://www.logic.at/people/preining | | University of Technology Vienna, Austria preining@logic.at | | DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key | +-------------------------------------------------------------------+
On Wed, 2 May 2001, Norbert Preining wrote:
One problem: Copying a dir with one big files (300M) took awful long! Somehow it looks like the pktwriter get stuck, the lights on the cdwriter only blinks occasionally, slowly slowly adding bytes to the file. Well, it was working, no crash, nothing, just the copy just came to a halt more or less.
I have the same problem with a SCSI CDRW. One other problem: Copying one big file after about 200MB the writing stopped completely. "cat /proc/driver/pktcdvd" showed that there were still commands in the queue, but the number of written sectors did not increase and the number of commands in the queue was constant. I waited some minutes and tried "sync" which hung. Then I found out that I could stimulate the writing by doing "cat /pktcd/<file which was being written>" in parallel. After that the "sync" command finished. At another time I tried copying a big file again, again after some time the writing stopped but this time a could not stimulate the writing and the system hung completely (after doing "cat ..."). There were no error messages at all in the logs. Best regards, Andreas
On Wed, May 02 2001, Andreas Nowack wrote:
One problem: Copying a dir with one big files (300M) took awful long! Somehow it looks like the pktwriter get stuck, the lights on the cdwriter only blinks occasionally, slowly slowly adding bytes to the file. Well, it was working, no crash, nothing, just the copy just came to a halt more or less.
I have the same problem with a SCSI CDRW.
One other problem: Copying one big file after about 200MB the writing stopped completely. "cat /proc/driver/pktcdvd" showed that there were still commands in the queue, but the number of written sectors did not increase and the number of commands in the queue was constant. I waited some minutes and tried "sync" which hung. Then I found out that I could stimulate the writing by doing "cat /pktcd/<file which was being written>" in parallel. After that the "sync" command finished.
The write queue was probably plugged at this point, so running the command in parallel provoked an unplug which then drained the queue.
At another time I tried copying a big file again, again after some time the writing stopped but this time a could not stimulate the writing and the system hung completely (after doing "cat ...").
And here the same situation, but this time the queue was unplugged but not empty. So no new fs activity would cause it to unplug. For both of you, try re-adding the generic_unplug_device(q) to kcdrwd efter the set_task_state(). AFAICS, that should fix the problem outlined above.
There were no error messages at all in the logs.
Good, just makes the case above stronger :-) We definitely don't want to unplug every time, I'll add some code to make this happen correctly no matter the circumstance. -- Jens Axboe
participants (4)
-
Andreas Nowack -
Jens Axboe -
Norbert Preining -
rsmith＠xs4all.nl