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

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

[Toad]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

I got the following when trying to mount a particular DVD-R on Linux
2.6.0-test11, using an IDE DVD-RW drive, using SCSI emulation, with the
preempt kernel option enabled, and taskfile I/O:
(the middle bit was repeated several times):

ide-scsi: reset called for 133
bad: scheduling while atomic!
Call Trace:
 [<c0119acc>] schedule+0x55c/0x570
 [<c01259ce>] schedule_timeout+0x5e/0xb0
 [<c0125960>] process_timeout+0x0/0x10
 [<c02add47>] idescsi_reset+0xf7/0x110
 [<c02a7b82>] scsi_try_bus_device_reset+0x52/0x90
 [<c02a7c1d>] scsi_eh_bus_device_reset+0x5d/0xe0
 [<c02a8368>] scsi_eh_ready_devs+0x28/0x70
 [<c02a84ef>] scsi_unjam_host+0xbf/0xd0
 [<c02a85da>] scsi_error_handler+0xda/0x120
 [<c02a8500>] scsi_error_handler+0x0/0x120
 [<c0107329>] kernel_thread_helper+0x5/0xc

SCSI error: host 0 id 0 lun 0 return code = 6000000
Sense class 0, sense error 0, extended sense 0
mount: No medium found

I also suspect that it is refusing to read valid DVD-Rs, but it could
just be my drive. One of them successfully mounted and then complained
about attempt to access beyond end of device, and another 6 or so
refused to mount for the same reason.

If you require any further information, please ask me.

Software: Kernel 2.6.0-test11, configured as above, Debian sid current
(glibc2.3 IIRC), mount version 2.12, athlon XP 2800+, ATI's fglrx module
loaded, sound (emu10k1) as moule, AGP, and some networking and lm_sensors
stuff (all from stock kernel).
-- 
Matthew J Toseland - toad@amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Linus Torvalds]

On Mon, 15 Dec 2003, Toad wrote:
>
> I got the following when trying to mount a particular DVD-R on Linux
> 2.6.0-test11, using an IDE DVD-RW drive, using SCSI emulation, with the
> preempt kernel option enabled, and taskfile I/O:
> (the middle bit was repeated several times):

ide-scsi does

        spin_lock_irqsave(&ide_lock, flags);
        while (HWGROUP(drive)->handler) {
                HWGROUP(drive)->handler = NULL;
                schedule_timeout(1);
        }

which is obvious crap. Scheduling while holding a spinlock is not a good
idea.

You could try dropping the lock over the schedule and re-aquire it
afterwards, but the comment tries to say that it is required for avoiding
new requests.

This is why ide-scsi needs a maintainer, btw - somebody who cares about
it, and actually tries to resolve the current mess.

		Linus

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

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Mon, 15 Dec 2003, Toad wrote:
> 
>>I got the following when trying to mount a particular DVD-R on Linux
>>2.6.0-test11, using an IDE DVD-RW drive, using SCSI emulation, with the
>>preempt kernel option enabled, and taskfile I/O:
>>(the middle bit was repeated several times):
> 
> 
> ide-scsi does
> 
>         spin_lock_irqsave(&ide_lock, flags);
>         while (HWGROUP(drive)->handler) {
>                 HWGROUP(drive)->handler = NULL;
>                 schedule_timeout(1);
>         }
> 
> which is obvious crap. Scheduling while holding a spinlock is not a good
> idea.
> 
> You could try dropping the lock over the schedule and re-aquire it
> afterwards, but the comment tries to say that it is required for avoiding
> new requests.
> 
> This is why ide-scsi needs a maintainer, btw - somebody who cares about
> it, and actually tries to resolve the current mess.


Pardon me for asking a dumb and possibly impertinent question, but why 
keep it around at all?

In 2.6 it just seems like it's causing more problems than it's worth.  I 
mean, replacing ide-scsi with a simple 4-line driver would suffice...

int init_module(void)
{
	printk(KERN_INFO "fix your app to use SG_IO\n");
}

Since the major app, cdrecord, has already been fixed, that just leaves 
a few IMO minor apps out there that (a) should be using SG IO and (b) 
are depending on an unmaintained and perpetually broken driver anyway.

	Jeff


P.S. Yes, libata will probably (not definite) use the SCSI layer to 
drive ATAPI devices... but that's a long way off, and will not be using 
the ide-scsi code.  ide-scsi is basically a glue driver specifically for 
drivers/ide.

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

[Toad]

[-- Attachment #1: Type: text/plain, Size: 2408 bytes --]

On Mon, Dec 15, 2003 at 10:54:11AM -0500, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >
> >On Mon, 15 Dec 2003, Toad wrote:
> >
> >>I got the following when trying to mount a particular DVD-R on Linux
> >>2.6.0-test11, using an IDE DVD-RW drive, using SCSI emulation, with the
> >>preempt kernel option enabled, and taskfile I/O:
> >>(the middle bit was repeated several times):
> >
> >
> >ide-scsi does
> >
> >        spin_lock_irqsave(&ide_lock, flags);
> >        while (HWGROUP(drive)->handler) {
> >                HWGROUP(drive)->handler = NULL;
> >                schedule_timeout(1);
> >        }
> >
> >which is obvious crap. Scheduling while holding a spinlock is not a good
> >idea.
> >
> >You could try dropping the lock over the schedule and re-aquire it
> >afterwards, but the comment tries to say that it is required for avoiding
> >new requests.
> >
> >This is why ide-scsi needs a maintainer, btw - somebody who cares about
> >it, and actually tries to resolve the current mess.
> 
> 
> Pardon me for asking a dumb and possibly impertinent question, but why 
> keep it around at all?
> 
> In 2.6 it just seems like it's causing more problems than it's worth.  I 
> mean, replacing ide-scsi with a simple 4-line driver would suffice...
> 
> int init_module(void)
> {
> 	printk(KERN_INFO "fix your app to use SG_IO\n");
> }
> 
> Since the major app, cdrecord, has already been fixed, that just leaves 
> a few IMO minor apps out there that (a) should be using SG IO and (b) 
> are depending on an unmaintained and perpetually broken driver anyway.

I've been completely unable to get cdrtools to compile... The version in
debian is 2.0a19, which works with IDE-SCSI, and doesn't work without
it. The RPM from the oss-dvd extension site doesn't work either without
IDE-SCSI. Nor does dvd+rwtools. Anyone attempting to write DVDs will
have real problems if IDE-SCSI is removed, judging by this experience.
> 
> 	Jeff
> 
> 
> P.S. Yes, libata will probably (not definite) use the SCSI layer to 
> drive ATAPI devices... but that's a long way off, and will not be using 
> the ide-scsi code.  ide-scsi is basically a glue driver specifically for 
> drivers/ide.
> 

-- 
Matthew J Toseland - toad@amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[David T Hollis]

On Mon, 2003-12-15 at 12:49, Toad wrote:

> I've been completely unable to get cdrtools to compile... The version in
> debian is 2.0a19, which works with IDE-SCSI, and doesn't work without
> it. The RPM from the oss-dvd extension site doesn't work either without
> IDE-SCSI. Nor does dvd+rwtools. Anyone attempting to write DVDs will
> have real problems if IDE-SCSI is removed, judging by this experience.

I've been running 2.5/2.6 kernels since June and I've been able to use
cdrecord (2.x) from RedHat Rawhide/Fedora Core to burn CDs and DVDs
without ide-scsi the entire time.  I currently have
cdrecord-2.01-0.a19.3 installed (probably from Fedora devel) and it
works like a champ.

So long ide-scsi!

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

[grundig]

El Mon, 15 Dec 2003 17:49:08 +0000 Toad <toad@amphibian.dyndns.org> escribió:

> I've been completely unable to get cdrtools to compile... The version in
> debian is 2.0a19, which works with IDE-SCSI, and doesn't work without

I've been burning cds with cdrecord in debian (sid) for months without
ide-scsi.


> > P.S. Yes, libata will probably (not definite) use the SCSI layer to 
> > drive ATAPI devices... but that's a long way off, and will not be using 
> > the ide-scsi code.  ide-scsi is basically a glue driver specifically for 
> > drivers/ide.

IIRC, some devices (ie: some tape devices) need ide-scsi too. They should be
ported instead of fixing ide-scsi?

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

[Jeff Garzik]

Toad wrote:
> I've been completely unable to get cdrtools to compile... The version in
> debian is 2.0a19, which works with IDE-SCSI, and doesn't work without
> it. The RPM from the oss-dvd extension site doesn't work either without
> IDE-SCSI. Nor does dvd+rwtools. Anyone attempting to write DVDs will
> have real problems if IDE-SCSI is removed, judging by this experience.

Well, it sounds like we are having real problems _with_ IDE-SCSI, too ;-)

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

[Martin Schlemmer]

[-- Attachment #1.1: Type: text/plain, Size: 539 bytes --]

On Mon, 2003-12-15 at 19:49, Toad wrote:

> I've been completely unable to get cdrtools to compile... The version in
> debian is 2.0a19, which works with IDE-SCSI, and doesn't work without
> it. The RPM from the oss-dvd extension site doesn't work either without
> IDE-SCSI. Nor does dvd+rwtools. Anyone attempting to write DVDs will
> have real problems if IDE-SCSI is removed, judging by this experience.

You might try this patch to get the latest 2.01 beta compiled against
2.6 headers.


Cheers,

-- 
Martin Schlemmer

[-- Attachment #1.2: cdrtools-2.01-kernel25-support.patch --]
[-- Type: text/x-patch, Size: 616 bytes --]

--- cdrtools-2.01/libscg/scsi-linux-sg.c.orig	2003-02-05 21:01:31.000000000 +0200
+++ cdrtools-2.01/libscg/scsi-linux-sg.c	2003-02-05 21:16:33.000000000 +0200
@@ -66,6 +66,11 @@
 #if LINUX_VERSION_CODE >= 0x01031a /* <linux/scsi.h> introduced in 1.3.26 */
 #if LINUX_VERSION_CODE >= 0x020000 /* <scsi/scsi.h> introduced somewhere. */
 /* Need to fine tune the ifdef so we get the transition point right. */
+#if LINUX_VERSION_CODE >= 0x020500 /* 2.5.x breaks things again */
+#define __KERNEL__
+#include <asm/types.h>
+#undef __KERNEL__
+#endif
 #include <scsi/scsi.h>
 #else
 #include <linux/scsi.h>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Linus Torvalds]

On Mon, 15 Dec 2003, Jeff Garzik wrote:
>
> Pardon me for asking a dumb and possibly impertinent question, but why
> keep it around at all?

Hey, I've tried to kill it off, but people keep on wanting it. Either
because they are lazy and can't upgrade the tools to write CD's with the
regular ide-cd interfaces, or because they have IDE tapes and want to use
st.c to drive them.

ide-cd.c obviously does _not_ handle tapes. We could make the generic IDE
layer open them and let people do SCSI commands on them (and that probably
wouldn't be too hard), but somebody needs to _care_.

Right now ide-scsi (and the alternatives, like doing SCSI commands onto
any ATAPI device just using the regular IDE layer) are mostly hampered by
people complaining about them but not actually _doing_ anything.

I'll try something that rips out the reset handling altogether from
ide-scsi, let's see how that works (should be easy enough to test with a
black marker and an old CD-ROM).

		Linus

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

[bill davidsen]

In article <Pine.LNX.4.58.0312151019160.1488@home.osdl.org>,
Linus Torvalds  <torvalds@osdl.org> wrote:
| 
| 
| On Mon, 15 Dec 2003, Jeff Garzik wrote:
| >
| > Pardon me for asking a dumb and possibly impertinent question, but why
| > keep it around at all?
| 
| Hey, I've tried to kill it off, but people keep on wanting it. Either
| because they are lazy and can't upgrade the tools to write CD's with the
| regular ide-cd interfaces, or because they have IDE tapes and want to use
| st.c to drive them.

And MO drives. There was something funky with LS-120 and ZIP drives that
ide-scsi did right and ide-floppy didn't, but I haven't tried it since
about 2.5.4x, and at that time ide-scsi worked, other than logging some
status messages.

There is some MS backup software which wants SCSI tapes to run. I don't
know if that's under wine or vmware, it's on my list of things to check
and report, but down the list. One more reason for ide-scsi, though.
| 
| ide-cd.c obviously does _not_ handle tapes. We could make the generic IDE
| layer open them and let people do SCSI commands on them (and that probably
| wouldn't be too hard), but somebody needs to _care_.

I think there are a fair number of people who care, they just don't
happen to have the combination of skills, hardware, and time to go play.
Don't take it out, let people grouse and eventually fixes will come,
if only from vendors.
| 
| Right now ide-scsi (and the alternatives, like doing SCSI commands onto
| any ATAPI device just using the regular IDE layer) are mostly hampered by
| people complaining about them but not actually _doing_ anything.

1 - testing and reporting problems IS doing something.
2 - you supplied a patch which did fix some of the problems.
3 - I got another tape drive so I could test on non-production hardware
    and it died, haven't tried the replacement because we have had
    blizzards two bleeping weekends in a row. And this weekend is
    Christmas prep weekend, so don't expect nice test results this year.
4 - We now have three rescued kittens in the house, they are LOTS more
    fun to play with than ide-scsi ;-)
| 
| I'll try something that rips out the reset handling altogether from
| ide-scsi, let's see how that works (should be easy enough to test with a
| black marker and an old CD-ROM).

And hopefully the person who reported MO problems will test, because I
believe that was one of his major problems.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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

[Toad]

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

I recompiled the kernel with IDE-SCSI, preemption, taskfile, and a few
other things disabled. With the result that it worked. But of course I
can't _write_ DVDs without IDE-SCSI (short of obtaining a SCSI
writer)... I will now reenable features one by one to be sure it's an
IDE-SCSI problem. But it looks like IDE-SCSI has major problems reading
DVDs, mostly looking like this:

Dec 15 13:15:20 amphibian kernel: attempt to access beyond end of device
Dec 15 13:15:20 amphibian kernel: sr0: rw=0, want=2830152, limit=1329420
Dec 15 13:15:20 amphibian kernel: Buffer I/O error on device sr0,
logical block +707537

Either it gets such errors when mounting, or after mounting - almost
always when mounting.

Is there any way to record DVDs without using IDE-SCSI?

On Mon, Dec 15, 2003 at 01:58:02PM +0000, toad wrote:
> I got the following when trying to mount a particular DVD-R on Linux
> 2.6.0-test11, using an IDE DVD-RW drive, using SCSI emulation, with the
> preempt kernel option enabled, and taskfile I/O:
> (the middle bit was repeated several times):
> 
> ide-scsi: reset called for 133
> bad: scheduling while atomic!
> Call Trace:
>  [<c0119acc>] schedule+0x55c/0x570
>  [<c01259ce>] schedule_timeout+0x5e/0xb0
>  [<c0125960>] process_timeout+0x0/0x10
>  [<c02add47>] idescsi_reset+0xf7/0x110
>  [<c02a7b82>] scsi_try_bus_device_reset+0x52/0x90
>  [<c02a7c1d>] scsi_eh_bus_device_reset+0x5d/0xe0
>  [<c02a8368>] scsi_eh_ready_devs+0x28/0x70
>  [<c02a84ef>] scsi_unjam_host+0xbf/0xd0
>  [<c02a85da>] scsi_error_handler+0xda/0x120
>  [<c02a8500>] scsi_error_handler+0x0/0x120
>  [<c0107329>] kernel_thread_helper+0x5/0xc
> 
> SCSI error: host 0 id 0 lun 0 return code = 6000000
> Sense class 0, sense error 0, extended sense 0
> mount: No medium found
> 
> I also suspect that it is refusing to read valid DVD-Rs, but it could
> just be my drive. One of them successfully mounted and then complained
> about attempt to access beyond end of device, and another 6 or so
> refused to mount for the same reason.
> 
> If you require any further information, please ask me.
> 
> Software: Kernel 2.6.0-test11, configured as above, Debian sid current
> (glibc2.3 IIRC), mount version 2.12, athlon XP 2800+, ATI's fglrx module
> loaded, sound (emu10k1) as moule, AGP, and some networking and lm_sensors
> stuff (all from stock kernel).
> -- 
> Matthew J Toseland - toad@amphibian.dyndns.org
> Freenet Project Official Codemonkey - http://freenetproject.org/
> ICTHUS - Nothing is impossible. Our Boss says so.



-- 
Matthew J Toseland - toad@amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Linus Torvalds]

On Mon, 15 Dec 2003, Toad wrote:
>
> I recompiled the kernel with IDE-SCSI, preemption, taskfile, and a few
> other things disabled. With the result that it worked. But of course I
> can't _write_ DVDs without IDE-SCSI (short of obtaining a SCSI
> writer)...

Well, that "of course" shouldn't be there - it should work, using the
standard cdrecord.

You don't even need to recompile a cdrecord if you have a reasonably
recent distibution. Just use

	cdrecord dev=/dev/hdc

and it should "just work".

There's been at least one report that trying to write a DVD with packet
writing (ie by just mounting it read-write and writing to it) doesn't
work. That one seems to be due to the generic cdrom.c code getting the
size of the disk wrong. There was a patch floating around for testing, but
I never got any feedback on that apart from the original success story.

But if you have a DVD-R, then that shouldn't even be an issue, methinks.

			Linus

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

[Linus Torvalds]

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.

		Linus

----
--- 1.34/drivers/scsi/ide-scsi.c	Tue Dec  2 19:03:55 2003
+++ edited/drivers/scsi/ide-scsi.c	Mon Dec 15 10:17:52 2003
@@ -882,35 +882,26 @@
 	return FAILED;
 }

-static int idescsi_reset (Scsi_Cmnd *cmd)
+static int idescsi_device_reset(Scsi_Cmnd *cmd)
+{
+	printk("IDE device reset requested\n");
+	return FAILED;
+}
+
+static int idescsi_bus_reset(Scsi_Cmnd *cmd)
 {
-	unsigned long flags;
-	struct request *req;
 	idescsi_scsi_t *idescsi = scsihost_to_idescsi(cmd->device->host);
 	ide_drive_t *drive = idescsi->drive;

-	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);
-	}
-	/* now nuke the drive queue */
-	while ((req = elv_next_request(drive->queue))) {
-		blkdev_dequeue_request(req);
-		end_that_request_last(req);
-	}
-	/* 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);
+	printk("IDE bus reset requested\n");
+	ide_do_reset(drive);
 	return SUCCESS;
+}
+
+static int idescsi_host_reset(Scsi_Cmnd *cmd)
+{
+	printk("IDE host reset requested\n");
+	return FAILED;
 }

 static int idescsi_bios(struct scsi_device *sdev, struct block_device *bdev,
@@ -935,7 +926,9 @@
 	.ioctl			= idescsi_ioctl,
 	.queuecommand		= idescsi_queue,
 	.eh_abort_handler	= idescsi_abort,
-	.eh_device_reset_handler = idescsi_reset,
+	.eh_device_reset_handler = idescsi_device_reset,
+	.eh_bus_reset_handler	= idescsi_bus_reset,
+	.eh_host_reset_handler	= idescsi_host_reset,
 	.bios_param		= idescsi_bios,
 	.can_queue		= 40,
 	.this_id		= -1,

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

[Jens Axboe]

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

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

[Linus Torvalds]

On Mon, 15 Dec 2003, Jens Axboe wrote:
> >
> > 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.

Yeah. But at least it doesn't look like it would lock up the machine by
just being horribly wrong (like the reset code would). After all, all it
does is to wait for the requests to finish.

So I'm hoping that with just the reset routine basically removed, the
thing might limp along. But since I can't test it (and am not that
horribly motivated by it), I'll just see if somebody reports any success
at all with that patch.

		Linus

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

[Jens Axboe]

On Mon, Dec 15 2003, Linus Torvalds wrote:
> 
> 
> On Mon, 15 Dec 2003, Jens Axboe wrote:
> > >
> > > 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.
> 
> Yeah. But at least it doesn't look like it would lock up the machine by
> just being horribly wrong (like the reset code would). After all, all it
> does is to wait for the requests to finish.
> 
> So I'm hoping that with just the reset routine basically removed, the
> thing might limp along. But since I can't test it (and am not that
> horribly motivated by it), I'll just see if somebody reports any success
> at all with that patch.

So you're advocating a bandaid :)

However, if that patch makes ide-scsi limp along (it probably does),
then it will never get fixed for real. I suspect you don't care about
that, neither do I.

-- 
Jens Axboe