* Re: linux kernel panic when ejecting ieee1394 ipod
[not found] <200512072358.15398.adq_dvb@lidskialf.net>
@ 2005-12-08 1:17 ` Stefan Richter
2005-12-08 1:57 ` Andrew de Quincey
[not found] ` <200512080119.48740.adq@lidskialf.net>
2 siblings, 0 replies; 21+ messages in thread
From: Stefan Richter @ 2005-12-08 1:17 UTC (permalink / raw)
To: Andrew de Quincey; +Cc: linux1394-devel, linux-scsi
Andrew de Quincey wrote to linux1394-devel:
> Reposting to the -devel list since there was no response on -user.
I would have responded eventually... :-)
> Hi, I'm using linux kernel 2.6.14 with an generation 1 ipod connected via
> ieee1394/sbp2.
>
> I can mount/unmount it and use it fine. It even works with HAL now.
>
> The problem comes when I want to remove it. If I do:
>
> eject /dev/sdb
>
> The kernel panics with the following error:
> Kernel panic - not syncing: PCI-DMA: high address but no IOMMU
I think there was another report about "eject" of a FireWire iPod
crashing the kernel but I cannot find it in any archive anymore and do
not remember which kernel version and machine architecture was affected.
The eject command does work for me with a few different SBP-2 devices,
but I do not have an iPod. But more importantly, I have currently only
i386 with 512 MB RAM to test. The "high address but no IOMMU" panic
message is specific to x86_64.
I had only a superficial look at it so far and did not spot anything
obvious. (That's because I do not know anything about Linux' memory
management.) My only idea at the moment is to Cc this to linux-scsi
since sd_mod does work for you but the one thing you do via the sg
driver does not.
> I'm using an nforce 4 motherboard (Asus A8N-SLI Deluxe). The ipod is attached
> to the ieee1394 port on a creative labs Audigy2 sound card (uses OHCI-1394).
>
> I do _not_ have "Enable Phys DMA support for SBP2 (Debug)" enabled if thats
> any help.
--
Stefan Richter
-=====-=-=-= ==-- -=---
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
[not found] <200512072358.15398.adq_dvb@lidskialf.net>
2005-12-08 1:17 ` linux kernel panic when ejecting ieee1394 ipod Stefan Richter
@ 2005-12-08 1:57 ` Andrew de Quincey
[not found] ` <200512080119.48740.adq@lidskialf.net>
2 siblings, 0 replies; 21+ messages in thread
From: Andrew de Quincey @ 2005-12-08 1:57 UTC (permalink / raw)
To: linux1394-devel; +Cc: Stefan Richter, linux-scsi
(resent to include other lists)
On Wednesday 07 December 2005 23:58, Andrew de Quincey wrote:
> Reposting to the -devel list since there was no response on -user.
>
> Hi, I'm using linux kernel 2.6.14 with an generation 1 ipod connected via
> ieee1394/sbp2.
>
> I can mount/unmount it and use it fine. It even works with HAL now.
>
> The problem comes when I want to remove it. If I do:
>
> eject /dev/sdb
>
> The kernel panics with the following error:
> Kernel panic - not syncing: PCI-DMA: high address but no IOMMU
>
> I'm using an nforce 4 motherboard (Asus A8N-SLI Deluxe). The ipod is
> attached to the ieee1394 port on a creative labs Audigy2 sound card (uses
> OHCI-1394).
More info (I'm on an AMD64 in 64 bit mode BTW):
eject sends a CDROMEJECT ioctl first of all. It is this IOCTL that kills my
system. If I hack/tell it to just use a "SCSI eject", it works and actually
makes my ipod show that tick thing showing it is safe to remove it.
Tracing through the kernel for the CDROMEJECT shows:
drivers/scsi/sd.c/sd_ioctl()
-- calls scsi_cmd_ioctl()
drivers/block/scsi_ioctl.c/scsi_cmd_ioctl()
-- emulates the CDROMEJECT ioctl as a START_STOP unit SCSI packet command
... then that passes through the blockdev/scsi layers until:
drivers/ieee1394/sbp2.c/sbp2scsi_queuecommand()
-- this function actually works fine - it must be either in the callback
handler when the command completes (?) or sometime afterwards.
The last SCSI command received by sbp2 before the crash is:
1b 00 00 02 00
Which is definitely what scsi_cmd_ioctl() is setting up.
CDROMEJECT works on other scsi devices - e.g. my USB storage pendrive appears
as a SCSI drive, and can be "safely removed" by simply calling a CDROMEJECT
ioctl.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
[not found] ` <200512080119.48740.adq@lidskialf.net>
@ 2005-12-08 1:59 ` Andrew de Quincey
2005-12-08 2:09 ` Andrew de Quincey
0 siblings, 1 reply; 21+ messages in thread
From: Andrew de Quincey @ 2005-12-08 1:59 UTC (permalink / raw)
To: linux1394-devel; +Cc: Stefan Richter, linux-scsi
On Thursday 08 December 2005 01:19, Andrew de Quincey wrote:
> On Wednesday 07 December 2005 23:58, Andrew de Quincey wrote:
> > Reposting to the -devel list since there was no response on -user.
> >
> > Hi, I'm using linux kernel 2.6.14 with an generation 1 ipod connected via
> > ieee1394/sbp2.
> >
> > I can mount/unmount it and use it fine. It even works with HAL now.
> >
> > The problem comes when I want to remove it. If I do:
> >
> > eject /dev/sdb
> >
> > The kernel panics with the following error:
> > Kernel panic - not syncing: PCI-DMA: high address but no IOMMU
> >
> > I'm using an nforce 4 motherboard (Asus A8N-SLI Deluxe). The ipod is
> > attached to the ieee1394 port on a creative labs Audigy2 sound card (uses
> > OHCI-1394).
>
> More info (I'm on an AMD64 in 64 bit mode BTW):
>
> eject sends a CDROMEJECT ioctl first of all. It is this IOCTL that kills my
> system. If I hack/tell it to just use a "SCSI eject", it works and actually
> makes my ipod show that tick thing showing it is safe to remove it.
Yet more info:
eject -s sends the following SCSI packet command to the sbp/ipod device:
1b 00 00 00 02 00 with a direction of DMA_NONE
eject -r results in the same via the CDROMEJECT translator in
scsi_cmd_ioctl(), but with a direction of DMA_TO_DEVICE. Thats what crashes
it - looks like its trying to set up a DMA transfer for 0 bytes or something.
I just added a really horrible hack to the start of sbp2_send_command() to
check, as follows:
if (*cmd == 0x1b) {
SCpnt->sc_data_direction = 3;
}
Now, eject -r works perfectly. Though thats obviously not a good way to fix
it :)
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-08 1:59 ` Andrew de Quincey
@ 2005-12-08 2:09 ` Andrew de Quincey
2005-12-08 2:44 ` Stefan Richter
0 siblings, 1 reply; 21+ messages in thread
From: Andrew de Quincey @ 2005-12-08 2:09 UTC (permalink / raw)
To: linux1394-devel; +Cc: Stefan Richter, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]
On Thursday 08 December 2005 01:59, Andrew de Quincey wrote:
> On Thursday 08 December 2005 01:19, Andrew de Quincey wrote:
> > On Wednesday 07 December 2005 23:58, Andrew de Quincey wrote:
> > > Reposting to the -devel list since there was no response on -user.
> > >
> > > Hi, I'm using linux kernel 2.6.14 with an generation 1 ipod connected
> > > via ieee1394/sbp2.
> > >
> > > I can mount/unmount it and use it fine. It even works with HAL now.
> > >
> > > The problem comes when I want to remove it. If I do:
> > >
> > > eject /dev/sdb
> > >
> > > The kernel panics with the following error:
> > > Kernel panic - not syncing: PCI-DMA: high address but no IOMMU
> > >
> > > I'm using an nforce 4 motherboard (Asus A8N-SLI Deluxe). The ipod is
> > > attached to the ieee1394 port on a creative labs Audigy2 sound card
> > > (uses OHCI-1394).
> >
> > More info (I'm on an AMD64 in 64 bit mode BTW):
> >
> > eject sends a CDROMEJECT ioctl first of all. It is this IOCTL that kills
> > my system. If I hack/tell it to just use a "SCSI eject", it works and
> > actually makes my ipod show that tick thing showing it is safe to remove
> > it.
>
> Yet more info:
>
> eject -s sends the following SCSI packet command to the sbp/ipod device:
>
> 1b 00 00 00 02 00 with a direction of DMA_NONE
>
> eject -r results in the same via the CDROMEJECT translator in
> scsi_cmd_ioctl(), but with a direction of DMA_TO_DEVICE. Thats what crashes
> it - looks like its trying to set up a DMA transfer for 0 bytes or
> something. I just added a really horrible hack to the start of
> sbp2_send_command() to check, as follows:
>
> if (*cmd == 0x1b) {
> SCpnt->sc_data_direction = 3;
> }
>
> Now, eject -r works perfectly. Though thats obviously not a good way to fix
> it :)
Possible "proper" patch attached - no idea if its a good way to do this.
Basically if it gets a command with a scsi_request_bufflen of zero bytes, it
forces dma_dir to DMA_NONE.
The ipod works perfectly with this now.
[-- Attachment #2: possible-sbp2-eject-fix-1.patch --]
[-- Type: text/x-diff, Size: 552 bytes --]
--- linux-2.6.14/drivers/ieee1394/sbp2.c 2005-12-08 02:05:27.000000000 +0000
+++ linux/drivers/ieee1394/sbp2.c 2005-12-08 02:06:18.000000000 +0000
@@ -1760,6 +1760,10 @@
command_orb->misc |= ORB_SET_SPEED(scsi_id->speed_code);
command_orb->misc |= ORB_SET_NOTIFY(1); /* Notify us when complete */
+ /* check for duff DMA transfer direction with a zero length buffer */
+ if (scsi_request_bufflen == 0)
+ dma_dir = DMA_NONE;
+
/*
* Get the direction of the transfer. If the direction is unknown, then use our
* goofy table as a back-up.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-08 2:09 ` Andrew de Quincey
@ 2005-12-08 2:44 ` Stefan Richter
2005-12-08 3:19 ` Andrew de Quincey
2005-12-08 17:34 ` Patrick Mansfield
0 siblings, 2 replies; 21+ messages in thread
From: Stefan Richter @ 2005-12-08 2:44 UTC (permalink / raw)
To: Andrew de Quincey; +Cc: linux1394-devel, linux-scsi
Andrew de Quincey wrote:
> On Thursday 08 December 2005 01:59, Andrew de Quincey wrote:
>>eject -s sends the following SCSI packet command to the sbp/ipod device:
>>
>>1b 00 00 00 02 00 with a direction of DMA_NONE
>>
>>eject -r results in the same via the CDROMEJECT translator in
>>scsi_cmd_ioctl(), but with a direction of DMA_TO_DEVICE. Thats what crashes
>>it - looks like its trying to set up a DMA transfer for 0 bytes or
>>something. I just added a really horrible hack to the start of
>>sbp2_send_command() to check, as follows:
>>
>> if (*cmd == 0x1b) {
>> SCpnt->sc_data_direction = 3;
>> }
>>
>>Now, eject -r works perfectly. Though thats obviously not a good way to fix
>>it :)
That was a long time ago when sbp2 had to take care of data direction. I
think we don't want to go back there. :-)
> Possible "proper" patch attached - no idea if its a good way to do this.
> Basically if it gets a command with a scsi_request_bufflen of zero bytes, it
> forces dma_dir to DMA_NONE.
>
> The ipod works perfectly with this now.
...
[in sbp2_create_command_orb]
> + /* check for duff DMA transfer direction with a zero length buffer */
> + if (scsi_request_bufflen == 0)
> + dma_dir = DMA_NONE;
What if you replace WRITE by READ in
drivers/scsi/scsi_ioctl.c::scsi_cmd_ioctl()::case CDROMEJECT ?
And BTW, can/should this latter case block be converted to use
scsi_execute() or scsi_execute_req()?
--
Stefan Richter
-=====-=-=-= ==-- -=---
http://arcgraph.de/sr/
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-08 2:44 ` Stefan Richter
@ 2005-12-08 3:19 ` Andrew de Quincey
2005-12-08 7:52 ` Stefan Richter
2005-12-08 17:34 ` Patrick Mansfield
1 sibling, 1 reply; 21+ messages in thread
From: Andrew de Quincey @ 2005-12-08 3:19 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux1394-devel, linux-scsi
> [in sbp2_create_command_orb]
>
> > + /* check for duff DMA transfer direction with a zero length buffer */
> > + if (scsi_request_bufflen == 0)
> > + dma_dir = DMA_NONE;
>
> What if you replace WRITE by READ in
> drivers/scsi/scsi_ioctl.c::scsi_cmd_ioctl()::case CDROMEJECT ?
Yup, using READ there fixes it too (and I did remember to remove my other
patch before testing :)
USB storage devices still work with the CDROMEJECT ioctl and this change as
well.
> And BTW, can/should this latter case block be converted to use
> scsi_execute() or scsi_execute_req()?
Can't comment - don't know enough about the linux SCSI subsystem.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-08 3:19 ` Andrew de Quincey
@ 2005-12-08 7:52 ` Stefan Richter
2005-12-08 19:27 ` Stefan Richter
0 siblings, 1 reply; 21+ messages in thread
From: Stefan Richter @ 2005-12-08 7:52 UTC (permalink / raw)
To: Andrew de Quincey; +Cc: linux1394-devel, linux-scsi
Andrew de Quincey wrote:
>>What if you replace WRITE by READ in
>>drivers/scsi/scsi_ioctl.c::scsi_cmd_ioctl()::case CDROMEJECT ?
>
> Yup, using READ there fixes it too (and I did remember to remove my other
> patch before testing :)
>
> USB storage devices still work with the CDROMEJECT ioctl and this change as
> well.
I'll check if they have a safeguard which sbp2 should have too.
Thanks a lot.
--
Stefan Richter
-=====-=-=-= ==-- -=---
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-08 2:44 ` Stefan Richter
2005-12-08 3:19 ` Andrew de Quincey
@ 2005-12-08 17:34 ` Patrick Mansfield
2005-12-08 19:25 ` Stefan Richter
2005-12-09 13:37 ` Jens Axboe
1 sibling, 2 replies; 21+ messages in thread
From: Patrick Mansfield @ 2005-12-08 17:34 UTC (permalink / raw)
To: Stefan Richter; +Cc: Andrew de Quincey, linux1394-devel, linux-scsi
On Thu, Dec 08, 2005 at 03:44:42AM +0100, Stefan Richter wrote:
> What if you replace WRITE by READ in
> drivers/scsi/scsi_ioctl.c::scsi_cmd_ioctl()::case CDROMEJECT ?
You must mean block/scsi_ioctl.c? i.e.:
diff -uprN -X /home/patman/dontdiff linux-2.6.15-rc5-git1/block/scsi_ioctl.c mod- linux-2.6.15-rc5-git1/block/scsi_ioctl.c
--- /home/linux/views/linux-2.6.15-rc5-git1/block/scsi_ioctl.c 2005-12-03 22:51:54.000000000 -0800
+++ linux-2.6.15-rc5-git1/block/scsi_ioctl.c 2005-12-08 09:31:52.000000000 -0800
@@ -566,7 +566,7 @@ int scsi_cmd_ioctl(struct file *file, st
case CDROMCLOSETRAY:
close = 1;
case CDROMEJECT:
- rq = blk_get_request(q, WRITE, __GFP_WAIT);
+ rq = blk_get_request(q, READ, __GFP_WAIT);
rq->flags |= REQ_BLOCK_PC;
rq->data = NULL;
rq->data_len = 0;
> And BTW, can/should this latter case block be converted to use
> scsi_execute() or scsi_execute_req()?
And then scsi_cmd_ioctl() already uses blk layer REQ_BLOCK_PC.
-- Patrick Mansfield
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-08 17:34 ` Patrick Mansfield
@ 2005-12-08 19:25 ` Stefan Richter
2005-12-09 13:37 ` Jens Axboe
1 sibling, 0 replies; 21+ messages in thread
From: Stefan Richter @ 2005-12-08 19:25 UTC (permalink / raw)
To: Patrick Mansfield
Cc: Andrew de Quincey, linux1394-devel, linux-scsi, Bryan Olmstead
Patrick Mansfield wrote:
> On Thu, Dec 08, 2005 at 03:44:42AM +0100, Stefan Richter wrote:
>>What if you replace WRITE by READ in
>>drivers/scsi/scsi_ioctl.c::scsi_cmd_ioctl()::case CDROMEJECT ?
(unless blk_get_request() knows another flag which comes closer to
DMA_NONE than READ)
> You must mean block/scsi_ioctl.c? i.e.:
Yes, actually. %-)
> diff -uprN -X /home/patman/dontdiff linux-2.6.15-rc5-git1/block/scsi_ioctl.c mod- linux-2.6.15-rc5-git1/block/scsi_ioctl.c
> --- /home/linux/views/linux-2.6.15-rc5-git1/block/scsi_ioctl.c 2005-12-03 22:51:54.000000000 -0800
> +++ linux-2.6.15-rc5-git1/block/scsi_ioctl.c 2005-12-08 09:31:52.000000000 -0800
> @@ -566,7 +566,7 @@ int scsi_cmd_ioctl(struct file *file, st
> case CDROMCLOSETRAY:
> close = 1;
> case CDROMEJECT:
> - rq = blk_get_request(q, WRITE, __GFP_WAIT);
> + rq = blk_get_request(q, READ, __GFP_WAIT);
> rq->flags |= REQ_BLOCK_PC;
> rq->data = NULL;
> rq->data_len = 0;
This should also go to -stable.
BTW, a kernel oops after "eject /mnt/ipod" under 2.6.12 (though no
panic) was also reported by Bryan Olmstead on July 16 2005.
http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
From the multiple problems reported there, everything except the eject
issue has been fixed in the meantime.
--
Stefan Richter
-=====-=-=-= ==-- -=---
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-08 7:52 ` Stefan Richter
@ 2005-12-08 19:27 ` Stefan Richter
0 siblings, 0 replies; 21+ messages in thread
From: Stefan Richter @ 2005-12-08 19:27 UTC (permalink / raw)
To: Andrew de Quincey; +Cc: linux1394-devel, linux-scsi
I wrote:
> Andrew de Quincey wrote:
>> USB storage devices still work with the CDROMEJECT ioctl and this
>> change as well.
>
> I'll check if they have a safeguard which sbp2 should have too.
I browsed a bit through usb/storage/ but did not spot an obvious sanity
check of this kind. AFAIU, slightly differently arranged case
discriminations let usb-storage avoid this pitfall.
Your patch to sbp2_create_command_orb() is basically the right thing to
do --- not as an actual fix of the bogus transfer direction passed to
sbp2 but rather as a protection against catastrophic failure. I'd like
to integrate your check in marginally different form though. Patch
follows shortly.
Thanks again.
--
Stefan Richter
-=====-=-=-= ==-- -=---
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-08 17:34 ` Patrick Mansfield
2005-12-08 19:25 ` Stefan Richter
@ 2005-12-09 13:37 ` Jens Axboe
2005-12-09 13:42 ` Jens Axboe
1 sibling, 1 reply; 21+ messages in thread
From: Jens Axboe @ 2005-12-09 13:37 UTC (permalink / raw)
To: Patrick Mansfield
Cc: Stefan Richter, Andrew de Quincey, linux1394-devel, linux-scsi
On Thu, Dec 08 2005, Patrick Mansfield wrote:
> On Thu, Dec 08, 2005 at 03:44:42AM +0100, Stefan Richter wrote:
>
> > What if you replace WRITE by READ in
> > drivers/scsi/scsi_ioctl.c::scsi_cmd_ioctl()::case CDROMEJECT ?
>
> You must mean block/scsi_ioctl.c? i.e.:
>
> diff -uprN -X /home/patman/dontdiff linux-2.6.15-rc5-git1/block/scsi_ioctl.c mod- linux-2.6.15-rc5-git1/block/scsi_ioctl.c
> --- /home/linux/views/linux-2.6.15-rc5-git1/block/scsi_ioctl.c 2005-12-03 22:51:54.000000000 -0800
> +++ linux-2.6.15-rc5-git1/block/scsi_ioctl.c 2005-12-08 09:31:52.000000000 -0800
> @@ -566,7 +566,7 @@ int scsi_cmd_ioctl(struct file *file, st
> case CDROMCLOSETRAY:
> close = 1;
> case CDROMEJECT:
> - rq = blk_get_request(q, WRITE, __GFP_WAIT);
> + rq = blk_get_request(q, READ, __GFP_WAIT);
> rq->flags |= REQ_BLOCK_PC;
> rq->data = NULL;
> rq->data_len = 0;
This should not make a difference, the direction flag must be ignored
for !rq->data_len. Similarly you could translate the request with the
change above into DMA_FROM_DEVICE which is clearly false as well. So it
must be a bug somewhere that somebody only looks at the direction flag.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-09 13:37 ` Jens Axboe
@ 2005-12-09 13:42 ` Jens Axboe
2005-12-09 18:39 ` Stefan Richter
0 siblings, 1 reply; 21+ messages in thread
From: Jens Axboe @ 2005-12-09 13:42 UTC (permalink / raw)
To: Patrick Mansfield
Cc: Stefan Richter, Andrew de Quincey, linux1394-devel, linux-scsi,
James Bottomley
On Fri, Dec 09 2005, Jens Axboe wrote:
> On Thu, Dec 08 2005, Patrick Mansfield wrote:
> > On Thu, Dec 08, 2005 at 03:44:42AM +0100, Stefan Richter wrote:
> >
> > > What if you replace WRITE by READ in
> > > drivers/scsi/scsi_ioctl.c::scsi_cmd_ioctl()::case CDROMEJECT ?
> >
> > You must mean block/scsi_ioctl.c? i.e.:
> >
> > diff -uprN -X /home/patman/dontdiff linux-2.6.15-rc5-git1/block/scsi_ioctl.c mod- linux-2.6.15-rc5-git1/block/scsi_ioctl.c
> > --- /home/linux/views/linux-2.6.15-rc5-git1/block/scsi_ioctl.c 2005-12-03 22:51:54.000000000 -0800
> > +++ linux-2.6.15-rc5-git1/block/scsi_ioctl.c 2005-12-08 09:31:52.000000000 -0800
> > @@ -566,7 +566,7 @@ int scsi_cmd_ioctl(struct file *file, st
> > case CDROMCLOSETRAY:
> > close = 1;
> > case CDROMEJECT:
> > - rq = blk_get_request(q, WRITE, __GFP_WAIT);
> > + rq = blk_get_request(q, READ, __GFP_WAIT);
> > rq->flags |= REQ_BLOCK_PC;
> > rq->data = NULL;
> > rq->data_len = 0;
>
> This should not make a difference, the direction flag must be ignored
> for !rq->data_len. Similarly you could translate the request with the
> change above into DMA_FROM_DEVICE which is clearly false as well. So it
> must be a bug somewhere that somebody only looks at the direction flag.
This looks like the real bug.
---
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 4afef5c..0978887 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1215,12 +1215,12 @@ static int scsi_prep_fn(struct request_q
} else {
memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
cmd->cmd_len = req->cmd_len;
- if (rq_data_dir(req) == WRITE)
+ if (!req->data_len)
+ cmd->sc_data_direction = DMA_NONE;
+ else if (rq_data_dir(req) == WRITE)
cmd->sc_data_direction = DMA_TO_DEVICE;
- else if (req->data_len)
- cmd->sc_data_direction = DMA_FROM_DEVICE;
else
- cmd->sc_data_direction = DMA_NONE;
+ cmd->sc_data_direction = DMA_FROM_DEVICE;
cmd->transfersize = req->data_len;
cmd->allowed = 3;
--
Jens Axboe
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-09 13:42 ` Jens Axboe
@ 2005-12-09 18:39 ` Stefan Richter
2005-12-09 19:35 ` Stefan Richter
0 siblings, 1 reply; 21+ messages in thread
From: Stefan Richter @ 2005-12-09 18:39 UTC (permalink / raw)
To: Jens Axboe
Cc: Patrick Mansfield, Andrew de Quincey, linux1394-devel,
linux-scsi, James Bottomley
Jens Axboe wrote:
> This looks like the real bug.
>
> ---
>
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 4afef5c..0978887 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1215,12 +1215,12 @@ static int scsi_prep_fn(struct request_q
> } else {
> memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
> cmd->cmd_len = req->cmd_len;
> - if (rq_data_dir(req) == WRITE)
> + if (!req->data_len)
> + cmd->sc_data_direction = DMA_NONE;
> + else if (rq_data_dir(req) == WRITE)
> cmd->sc_data_direction = DMA_TO_DEVICE;
> - else if (req->data_len)
> - cmd->sc_data_direction = DMA_FROM_DEVICE;
> else
> - cmd->sc_data_direction = DMA_NONE;
> + cmd->sc_data_direction = DMA_FROM_DEVICE;
>
> cmd->transfersize = req->data_len;
> cmd->allowed = 3;
>
>
And then there are also sd_init_command(), sr_init_command(),
st_init_command() in s[drt].c. sr_init_command() looks OK to me, the
other two feature the same flaw like scsi_prep_fn().
Or is there any reason why they should set DMA_TO_DEVICE while
rq->data_len == 0?
Furthermore, is there any other code path which may set
cmd->sc_data_direction, aside from s[drt]_init_command() and
scsi_prep_fn()? I was just browsing the code to find out myself but am
not 100% sure.
--
Stefan Richter
-=====-=-=-= ==-- -=--=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-09 18:39 ` Stefan Richter
@ 2005-12-09 19:35 ` Stefan Richter
2005-12-09 22:45 ` James Bottomley
2005-12-10 8:48 ` Jens Axboe
0 siblings, 2 replies; 21+ messages in thread
From: Stefan Richter @ 2005-12-09 19:35 UTC (permalink / raw)
To: linux-scsi; +Cc: patmans, adq_dvb, linux1394-devel, James.Bottomley, axboe
scsi: dont allow DMA_TO_DEVICE with zero data length
When preparing a request in scsi_lib or in a SCSI high-level driver,
always set a transfer direction of DMA_NONE if data length is zero,
even for alleged write requests. (Extended patch derived from Jens
Axboe's version.)
Write requests with request buffer length == 0 lead to kernel panic
or oops if channeled through sbp2:
http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/scsi/scsi_lib.c | 8 ++++----
drivers/scsi/sd.c | 8 ++++----
drivers/scsi/st.c | 8 ++++----
3 files changed, 12 insertions(+), 12 deletions(-)
diff -uprN -X linux/Documentation/dontdiff linux/drivers/scsi.orig/scsi_lib.c linux/drivers/scsi/scsi_lib.c
--- linux/drivers/scsi.orig/scsi_lib.c 2005-11-24 23:10:21.000000000 +0100
+++ linux/drivers/scsi/scsi_lib.c 2005-12-09 20:11:59.000000000 +0100
@@ -1266,12 +1266,12 @@ static int scsi_prep_fn(struct request_q
} else {
memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
cmd->cmd_len = req->cmd_len;
- if (rq_data_dir(req) == WRITE)
+ if (!req->data_len)
+ cmd->sc_data_direction = DMA_NONE;
+ else if (rq_data_dir(req) == WRITE)
cmd->sc_data_direction = DMA_TO_DEVICE;
- else if (req->data_len)
- cmd->sc_data_direction = DMA_FROM_DEVICE;
else
- cmd->sc_data_direction = DMA_NONE;
+ cmd->sc_data_direction = DMA_FROM_DEVICE;
cmd->transfersize = req->data_len;
cmd->allowed = 3;
diff -uprN -X linux/Documentation/dontdiff linux/drivers/scsi.orig/sd.c linux/drivers/scsi/sd.c
--- linux/drivers/scsi.orig/sd.c 2005-11-24 23:10:21.000000000 +0100
+++ linux/drivers/scsi/sd.c 2005-12-09 20:13:12.000000000 +0100
@@ -236,12 +236,12 @@ static int sd_init_command(struct scsi_c
memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
SCpnt->cmd_len = rq->cmd_len;
- if (rq_data_dir(rq) == WRITE)
+ if (!rq->data_len)
+ SCpnt->sc_data_direction = DMA_NONE;
+ else if (rq_data_dir(rq) == WRITE)
SCpnt->sc_data_direction = DMA_TO_DEVICE;
- else if (rq->data_len)
- SCpnt->sc_data_direction = DMA_FROM_DEVICE;
else
- SCpnt->sc_data_direction = DMA_NONE;
+ SCpnt->sc_data_direction = DMA_FROM_DEVICE;
this_count = rq->data_len;
if (rq->timeout)
diff -uprN -X linux/Documentation/dontdiff linux/drivers/scsi.orig/st.c linux/drivers/scsi/st.c
--- linux/drivers/scsi.orig/st.c 2005-11-24 23:10:21.000000000 +0100
+++ linux/drivers/scsi/st.c 2005-12-09 20:14:29.000000000 +0100
@@ -4208,12 +4208,12 @@ static int st_init_command(struct scsi_c
memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
SCpnt->cmd_len = rq->cmd_len;
- if (rq_data_dir(rq) == WRITE)
+ if (!rq->data_len)
+ SCpnt->sc_data_direction = DMA_NONE;
+ else if (rq_data_dir(rq) == WRITE)
SCpnt->sc_data_direction = DMA_TO_DEVICE;
- else if (rq->data_len)
- SCpnt->sc_data_direction = DMA_FROM_DEVICE;
else
- SCpnt->sc_data_direction = DMA_NONE;
+ SCpnt->sc_data_direction = DMA_FROM_DEVICE;
SCpnt->timeout_per_command = rq->timeout;
SCpnt->transfersize = rq->data_len;
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-09 19:35 ` Stefan Richter
@ 2005-12-09 22:45 ` James Bottomley
2005-12-10 18:20 ` Christoph Hellwig
2005-12-13 20:44 ` Stefan Richter
2005-12-10 8:48 ` Jens Axboe
1 sibling, 2 replies; 21+ messages in thread
From: James Bottomley @ 2005-12-09 22:45 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux-scsi, patmans, adq_dvb, linux1394-devel, axboe
On Fri, 2005-12-09 at 20:35 +0100, Stefan Richter wrote:
> When preparing a request in scsi_lib or in a SCSI high-level driver,
> always set a transfer direction of DMA_NONE if data length is zero,
> even for alleged write requests. (Extended patch derived from Jens
> Axboe's version.)
>
> Write requests with request buffer length == 0 lead to kernel panic
> or oops if channeled through sbp2:
> http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
> http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The problem is that I already picked up Jens' patch in rc fixes, so this
no-longer applies. However, given that the fix needed to be in four
separate places, which looks rather bad, I propose the following
consolidation instead.
James
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1078,6 +1078,26 @@ static void scsi_generic_done(struct scs
scsi_io_completion(cmd, cmd->result == 0 ? cmd->bufflen : 0, 0);
}
+void scsi_setup_blk_pc_cmnd(struct scsi_cmnd *cmd, int retries)
+{
+ struct request *req = cmd->request;
+
+ BUG_ON(sizeof(req->cmd) > sizeof(cmd->cmnd));
+ memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
+ cmd->cmd_len = req->cmd_len;
+ if (!req->data_len)
+ cmd->sc_data_direction = DMA_NONE;
+ else if (rq_data_dir(req) == WRITE)
+ cmd->sc_data_direction = DMA_TO_DEVICE;
+ else
+ cmd->sc_data_direction = DMA_FROM_DEVICE;
+
+ cmd->transfersize = req->data_len;
+ cmd->allowed = retries;
+ cmd->timeout_per_command = req->timeout;
+}
+EXPORT_SYMBOL(scsi_setup_blk_pc_cmnd);
+
static int scsi_prep_fn(struct request_queue *q, struct request *req)
{
struct scsi_device *sdev = q->queuedata;
@@ -1213,18 +1233,7 @@ static int scsi_prep_fn(struct request_q
goto kill;
}
} else {
- memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
- cmd->cmd_len = req->cmd_len;
- if (!req->data_len)
- cmd->sc_data_direction = DMA_NONE;
- else if (rq_data_dir(req) == WRITE)
- cmd->sc_data_direction = DMA_TO_DEVICE;
- else
- cmd->sc_data_direction = DMA_FROM_DEVICE;
-
- cmd->transfersize = req->data_len;
- cmd->allowed = 3;
- cmd->timeout_per_command = req->timeout;
+ scsi_setup_blk_pc_cmnd(cmd, 3);
cmd->done = scsi_generic_done;
}
}
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -245,24 +245,10 @@ static int sd_init_command(struct scsi_c
* SG_IO from block layer already setup, just copy cdb basically
*/
if (blk_pc_request(rq)) {
- if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
- return 0;
-
- memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
- SCpnt->cmd_len = rq->cmd_len;
- if (rq_data_dir(rq) == WRITE)
- SCpnt->sc_data_direction = DMA_TO_DEVICE;
- else if (rq->data_len)
- SCpnt->sc_data_direction = DMA_FROM_DEVICE;
- else
- SCpnt->sc_data_direction = DMA_NONE;
-
- this_count = rq->data_len;
+ scsi_setup_blk_pc_cmnd(SCpnt, SD_PASSTHROUGH_RETRIES);
if (rq->timeout)
timeout = rq->timeout;
- SCpnt->transfersize = rq->data_len;
- SCpnt->allowed = SD_PASSTHROUGH_RETRIES;
goto queue;
}
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -320,25 +320,11 @@ static int sr_init_command(struct scsi_c
* these are already setup, just copy cdb basically
*/
if (SCpnt->request->flags & REQ_BLOCK_PC) {
- struct request *rq = SCpnt->request;
+ scsi_setup_blk_pc_cmnd(SCpnt, MAX_RETRIES);
- if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
- return 0;
-
- memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
- SCpnt->cmd_len = rq->cmd_len;
- if (!rq->data_len)
- SCpnt->sc_data_direction = DMA_NONE;
- else if (rq_data_dir(rq) == WRITE)
- SCpnt->sc_data_direction = DMA_TO_DEVICE;
- else
- SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-
- this_count = rq->data_len;
- if (rq->timeout)
- timeout = rq->timeout;
+ if (SCpnt->timeout_per_command)
+ timeout = SCpnt->timeout_per_command;
- SCpnt->transfersize = rq->data_len;
goto queue;
}
diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -4194,27 +4194,10 @@ static void st_intr(struct scsi_cmnd *SC
*/
static int st_init_command(struct scsi_cmnd *SCpnt)
{
- struct request *rq;
-
if (!(SCpnt->request->flags & REQ_BLOCK_PC))
return 0;
- rq = SCpnt->request;
- if (sizeof(rq->cmd) > sizeof(SCpnt->cmnd))
- return 0;
-
- memcpy(SCpnt->cmnd, rq->cmd, sizeof(SCpnt->cmnd));
- SCpnt->cmd_len = rq->cmd_len;
-
- if (rq_data_dir(rq) == WRITE)
- SCpnt->sc_data_direction = DMA_TO_DEVICE;
- else if (rq->data_len)
- SCpnt->sc_data_direction = DMA_FROM_DEVICE;
- else
- SCpnt->sc_data_direction = DMA_NONE;
-
- SCpnt->timeout_per_command = rq->timeout;
- SCpnt->transfersize = rq->data_len;
+ scsi_setup_blk_pc_cmnd(SCpnt, 0);
SCpnt->done = st_intr;
return 1;
}
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-09 19:35 ` Stefan Richter
2005-12-09 22:45 ` James Bottomley
@ 2005-12-10 8:48 ` Jens Axboe
2005-12-10 9:28 ` Christoph Hellwig
1 sibling, 1 reply; 21+ messages in thread
From: Jens Axboe @ 2005-12-10 8:48 UTC (permalink / raw)
To: Stefan Richter
Cc: linux-scsi, patmans, adq_dvb, linux1394-devel, James.Bottomley
On Fri, Dec 09 2005, Stefan Richter wrote:
> scsi: dont allow DMA_TO_DEVICE with zero data length
>
> When preparing a request in scsi_lib or in a SCSI high-level driver,
> always set a transfer direction of DMA_NONE if data length is zero,
> even for alleged write requests. (Extended patch derived from Jens
> Axboe's version.)
>
> Write requests with request buffer length == 0 lead to kernel panic
> or oops if channeled through sbp2:
> http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
> http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
My quick grep just showed the one, I'd encourage you to turn this into a
static inline function instead of duplicating the same code again 3 (or
more) times.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-10 8:48 ` Jens Axboe
@ 2005-12-10 9:28 ` Christoph Hellwig
2005-12-10 10:55 ` Stefan Richter
0 siblings, 1 reply; 21+ messages in thread
From: Christoph Hellwig @ 2005-12-10 9:28 UTC (permalink / raw)
To: Jens Axboe
Cc: Stefan Richter, linux-scsi, patmans, adq_dvb, linux1394-devel,
James.Bottomley
On Sat, Dec 10, 2005 at 09:48:33AM +0100, Jens Axboe wrote:
> On Fri, Dec 09 2005, Stefan Richter wrote:
> > scsi: dont allow DMA_TO_DEVICE with zero data length
> >
> > When preparing a request in scsi_lib or in a SCSI high-level driver,
> > always set a transfer direction of DMA_NONE if data length is zero,
> > even for alleged write requests. (Extended patch derived from Jens
> > Axboe's version.)
> >
> > Write requests with request buffer length == 0 lead to kernel panic
> > or oops if channeled through sbp2:
> > http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
> > http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
> >
> > Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
>
> My quick grep just showed the one, I'd encourage you to turn this into a
> static inline function instead of duplicating the same code again 3 (or
> more) times.
Actually Mike has code pending to remove all copies but the scsi_lib.c
one.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-10 9:28 ` Christoph Hellwig
@ 2005-12-10 10:55 ` Stefan Richter
0 siblings, 0 replies; 21+ messages in thread
From: Stefan Richter @ 2005-12-10 10:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-scsi, patmans, adq_dvb, linux1394-devel,
James.Bottomley
Christoph Hellwig wrote:
> On Sat, Dec 10, 2005 at 09:48:33AM +0100, Jens Axboe wrote:
>>On Fri, Dec 09 2005, Stefan Richter wrote:
>>>scsi: dont allow DMA_TO_DEVICE with zero data length
>>>
>>>When preparing a request in scsi_lib or in a SCSI high-level driver,
>>>always set a transfer direction of DMA_NONE if data length is zero,
>>>even for alleged write requests. (Extended patch derived from Jens
>>>Axboe's version.)
...
>>My quick grep just showed the one, I'd encourage you to turn this into a
>>static inline function instead of duplicating the same code again 3 (or
>>more) times.
>
> Actually Mike has code pending to remove all copies but the scsi_lib.c
> one.
I was about to prepare a subsequent patch which collapses 4 x 9 lines of
common code of scsi_prep_fn and s[drt]_init_command. I guess Mike's work
goes _much_ further than that, so I'd like to leave it to him. :-)
--
Stefan Richter
-=====-=-=-= ==-- -=-=-
http://arcgraph.de/sr/
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-09 22:45 ` James Bottomley
@ 2005-12-10 18:20 ` Christoph Hellwig
2005-12-13 20:44 ` Stefan Richter
1 sibling, 0 replies; 21+ messages in thread
From: Christoph Hellwig @ 2005-12-10 18:20 UTC (permalink / raw)
To: James Bottomley
Cc: Stefan Richter, linux-scsi, patmans, adq_dvb, linux1394-devel, axboe
On Fri, Dec 09, 2005 at 05:45:22PM -0500, James Bottomley wrote:
> On Fri, 2005-12-09 at 20:35 +0100, Stefan Richter wrote:
> > When preparing a request in scsi_lib or in a SCSI high-level driver,
> > always set a transfer direction of DMA_NONE if data length is zero,
> > even for alleged write requests. (Extended patch derived from Jens
> > Axboe's version.)
> >
> > Write requests with request buffer length == 0 lead to kernel panic
> > or oops if channeled through sbp2:
> > http://marc.theaimsgroup.com/?l=linux1394-devel&m=113399994920181
> > http://marc.theaimsgroup.com/?l=linux1394-user&m=112152701817435
> >
> > Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
>
> The problem is that I already picked up Jens' patch in rc fixes, so this
> no-longer applies. However, given that the fix needed to be in four
> separate places, which looks rather bad, I propose the following
> consolidation instead.
Please make the export _GPL so people see it's internal and can go away
real soon. Hopefull for 2.6.16 already when Mike's patch series is merged.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-09 22:45 ` James Bottomley
2005-12-10 18:20 ` Christoph Hellwig
@ 2005-12-13 20:44 ` Stefan Richter
2005-12-13 20:54 ` Jens Axboe
1 sibling, 1 reply; 21+ messages in thread
From: Stefan Richter @ 2005-12-13 20:44 UTC (permalink / raw)
To: James Bottomley
Cc: Jody McIntyre, linux-scsi, patmans, adq_dvb, linux1394-devel, axboe
James Bottomley wrote:
> On Fri, 2005-12-09 at 20:35 +0100, Stefan Richter wrote:
>>When preparing a request in scsi_lib or in a SCSI high-level driver,
>>always set a transfer direction of DMA_NONE if data length is zero,
>>even for alleged write requests. (Extended patch derived from Jens
>>Axboe's version.)
[...]
> The problem is that I already picked up Jens' patch in rc fixes, so this
> no-longer applies. However, given that the fix needed to be in four
> separate places, which looks rather bad, I propose the following
> consolidation instead.
Jens' patch alone does not fix the kernel panic AFAICS. "eject /dev/sdX"
goes through sd_init_command. James, could you put your patch into
scsi-rc-fixes too? And what about -stable?
[BTW, some revisions of iPods require to either "eject" them or to
unload sbp2 or to disassociate them from sbp2 via an arcane echo to
ieee1394's sysfs interface before they can be unplugged. Else their
firmware needs to be reset. This is why "eject" is the recommended
procedure to disconnect an iPod.]
Thanks,
--
Stefan Richter
-=====-=-=-= ==-- -==-=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux kernel panic when ejecting ieee1394 ipod
2005-12-13 20:44 ` Stefan Richter
@ 2005-12-13 20:54 ` Jens Axboe
0 siblings, 0 replies; 21+ messages in thread
From: Jens Axboe @ 2005-12-13 20:54 UTC (permalink / raw)
To: Stefan Richter
Cc: James Bottomley, Jody McIntyre, linux-scsi, patmans, adq_dvb,
linux1394-devel
On Tue, Dec 13 2005, Stefan Richter wrote:
> James Bottomley wrote:
> >On Fri, 2005-12-09 at 20:35 +0100, Stefan Richter wrote:
> >>When preparing a request in scsi_lib or in a SCSI high-level driver,
> >>always set a transfer direction of DMA_NONE if data length is zero,
> >>even for alleged write requests. (Extended patch derived from Jens
> >>Axboe's version.)
> [...]
> >The problem is that I already picked up Jens' patch in rc fixes, so this
> >no-longer applies. However, given that the fix needed to be in four
> >separate places, which looks rather bad, I propose the following
> >consolidation instead.
>
> Jens' patch alone does not fix the kernel panic AFAICS. "eject /dev/sdX"
> goes through sd_init_command. James, could you put your patch into
> scsi-rc-fixes too? And what about -stable?
I trust James already included his own updated version, which is
basically fixing that bug but abstracting the rq_to_scsi_dir() stuff
into a helper instead. That should fix it for all cases.
--
Jens Axboe
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2005-12-13 20:54 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200512072358.15398.adq_dvb@lidskialf.net>
2005-12-08 1:17 ` linux kernel panic when ejecting ieee1394 ipod Stefan Richter
2005-12-08 1:57 ` Andrew de Quincey
[not found] ` <200512080119.48740.adq@lidskialf.net>
2005-12-08 1:59 ` Andrew de Quincey
2005-12-08 2:09 ` Andrew de Quincey
2005-12-08 2:44 ` Stefan Richter
2005-12-08 3:19 ` Andrew de Quincey
2005-12-08 7:52 ` Stefan Richter
2005-12-08 19:27 ` Stefan Richter
2005-12-08 17:34 ` Patrick Mansfield
2005-12-08 19:25 ` Stefan Richter
2005-12-09 13:37 ` Jens Axboe
2005-12-09 13:42 ` Jens Axboe
2005-12-09 18:39 ` Stefan Richter
2005-12-09 19:35 ` Stefan Richter
2005-12-09 22:45 ` James Bottomley
2005-12-10 18:20 ` Christoph Hellwig
2005-12-13 20:44 ` Stefan Richter
2005-12-13 20:54 ` Jens Axboe
2005-12-10 8:48 ` Jens Axboe
2005-12-10 9:28 ` Christoph Hellwig
2005-12-10 10:55 ` Stefan Richter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.