Re: 'bad: scheduling while atomic!', preempt kernel, 2.6.1-test11, reading an apparently duff DVD-R

[Jens Axboe <axboe@suse.de>]

On Mon, Dec 15 2003, Linus Torvalds wrote:
> 
> 
> On Mon, 15 Dec 2003, Toad wrote:
> >
> > ide-scsi: reset called for 133
> 
> Ok, I can't trigger an IDE reset even with a bad CDROM, so I'm kind of out
> of luck on testing this. Can you try out the following silly patch, and
> report what it says?
> 
> The old ide-scsi reset function is just terminally broken, there's no way
> it can work. This patch _might_ make it work, but is more likely to just
> print out what it's trying to do.

abort doesn't work well either, and ide-scsi needs to be ported to do
proper new error handling. It's internal buffering stinks. In short, it
really needs to be almost rewritten if it is serve some useful purpose.
If it wasn't for the principle of it, it really should not be a big job.

> -	printk (KERN_ERR "ide-scsi: reset called for %lu\n", cmd->serial_number);
> -	/* first null the handler for the drive and let any process
> -	 * doing IO (on another CPU) run to (partial) completion
> -	 * the lock prevents processing new requests */
> -	spin_lock_irqsave(&ide_lock, flags);
> -	while (HWGROUP(drive)->handler) {
> -		HWGROUP(drive)->handler = NULL;
> -		schedule_timeout(1);
> -	}

It's incredible how anything like that ever got merged, looks like it
was introduced with scsi_sleep() change.

> -	/* now nuke the drive queue */
> -	while ((req = elv_next_request(drive->queue))) {
> -		blkdev_dequeue_request(req);
> -		end_that_request_last(req);

Broken, will introduced infinite stalls.

> -	}
> -	/* FIXME - this will probably leak memory */
> -	HWGROUP(drive)->rq = NULL;
> -	if (drive_to_idescsi(drive))
> -		drive_to_idescsi(drive)->pc = NULL;
> -	spin_unlock_irqrestore(&ide_lock, flags);
> -	/* finally, reset the drive (and its partner on the bus...) */
> -	ide_do_reset (drive);

-- 
Jens Axboe