linux/drivers/ide/ide-cd.c

1819 lines
46 KiB

ide: fix regression caused by ide_device_{get,put}() addition (take 2) On Monday 28 July 2008, Benjamin Herrenschmidt wrote: [...] > Vector: 300 (Data Access) at [c58b7b80] > pc: c014f264: elv_may_queue+0x10/0x44 > lr: c0152750: get_request+0x2c/0x2c0 > sp: c58b7c30 > msr: 1032 > dar: c > dsisr: 40000000 > current = 0xc58aaae0 > pid = 854, comm = media-bay > enter ? for help > mon> t > [c58b7c40] c0152750 get_request+0x2c/0x2c0 > [c58b7c70] c0152a08 get_request_wait+0x24/0xec > [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 > [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc > [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 > [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c > [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 > [c58b7e50] c022395c ide_cd_release+0x80/0x84 > [c58b7e70] c0163650 kref_put+0x54/0x6c > [c58b7e80] c0223884 ide_cd_put+0x40/0x5c > [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c > [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 > [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 > [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 > [c58b7f00] c01e7424 device_del+0x104/0x198 > [c58b7f20] c01e74d0 device_unregister+0x18/0x30 > [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 > [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 > [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 > [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc > [c58b7fd0] c00485c0 kthread+0x48/0x84 > [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 The guilty commit turned out to be 08da591e14cf87247ec09b17c350235157a92fc3 ("ide: add ide_device_{get,put}() helpers"). ide_device_put() is called before kref_put() in ide_cd_put() so IDE device is already gone by the time ide_cd_release() is reached. Fix it by calling ide_device_get() before kref_get() and ide_device_put() after kref_put() in all affected device drivers. v2: Brown paper bag time. In v1 cd->drive was referenced after dropping last reference on cd object (which could result in OOPS in ide_device_put() as reported/debugged by Mariusz Kozlowski). Fix it by caching cd->drive in the local variable (fix other device drivers too). Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Borislav Petkov <petkovbb@gmail.com> Tested-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2008-08-05 18:16:59 +02:00
ide: fix regression caused by ide_device_{get,put}() addition (take 2) On Monday 28 July 2008, Benjamin Herrenschmidt wrote: [...] > Vector: 300 (Data Access) at [c58b7b80] > pc: c014f264: elv_may_queue+0x10/0x44 > lr: c0152750: get_request+0x2c/0x2c0 > sp: c58b7c30 > msr: 1032 > dar: c > dsisr: 40000000 > current = 0xc58aaae0 > pid = 854, comm = media-bay > enter ? for help > mon> t > [c58b7c40] c0152750 get_request+0x2c/0x2c0 > [c58b7c70] c0152a08 get_request_wait+0x24/0xec > [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 > [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc > [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 > [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c > [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 > [c58b7e50] c022395c ide_cd_release+0x80/0x84 > [c58b7e70] c0163650 kref_put+0x54/0x6c > [c58b7e80] c0223884 ide_cd_put+0x40/0x5c > [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c > [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 > [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 > [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 > [c58b7f00] c01e7424 device_del+0x104/0x198 > [c58b7f20] c01e74d0 device_unregister+0x18/0x30 > [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 > [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 > [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 > [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc > [c58b7fd0] c00485c0 kthread+0x48/0x84 > [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 The guilty commit turned out to be 08da591e14cf87247ec09b17c350235157a92fc3 ("ide: add ide_device_{get,put}() helpers"). ide_device_put() is called before kref_put() in ide_cd_put() so IDE device is already gone by the time ide_cd_release() is reached. Fix it by calling ide_device_get() before kref_get() and ide_device_put() after kref_put() in all affected device drivers. v2: Brown paper bag time. In v1 cd->drive was referenced after dropping last reference on cd object (which could result in OOPS in ide_device_put() as reported/debugged by Mariusz Kozlowski). Fix it by caching cd->drive in the local variable (fix other device drivers too). Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Borislav Petkov <petkovbb@gmail.com> Tested-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2008-08-05 18:16:59 +02:00
ide: fix regression caused by ide_device_{get,put}() addition (take 2) On Monday 28 July 2008, Benjamin Herrenschmidt wrote: [...] > Vector: 300 (Data Access) at [c58b7b80] > pc: c014f264: elv_may_queue+0x10/0x44 > lr: c0152750: get_request+0x2c/0x2c0 > sp: c58b7c30 > msr: 1032 > dar: c > dsisr: 40000000 > current = 0xc58aaae0 > pid = 854, comm = media-bay > enter ? for help > mon> t > [c58b7c40] c0152750 get_request+0x2c/0x2c0 > [c58b7c70] c0152a08 get_request_wait+0x24/0xec > [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 > [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc > [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 > [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c > [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 > [c58b7e50] c022395c ide_cd_release+0x80/0x84 > [c58b7e70] c0163650 kref_put+0x54/0x6c > [c58b7e80] c0223884 ide_cd_put+0x40/0x5c > [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c > [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 > [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 > [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 > [c58b7f00] c01e7424 device_del+0x104/0x198 > [c58b7f20] c01e74d0 device_unregister+0x18/0x30 > [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 > [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 > [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 > [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc > [c58b7fd0] c00485c0 kthread+0x48/0x84 > [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 The guilty commit turned out to be 08da591e14cf87247ec09b17c350235157a92fc3 ("ide: add ide_device_{get,put}() helpers"). ide_device_put() is called before kref_put() in ide_cd_put() so IDE device is already gone by the time ide_cd_release() is reached. Fix it by calling ide_device_get() before kref_get() and ide_device_put() after kref_put() in all affected device drivers. v2: Brown paper bag time. In v1 cd->drive was referenced after dropping last reference on cd object (which could result in OOPS in ide_device_put() as reported/debugged by Mariusz Kozlowski). Fix it by caching cd->drive in the local variable (fix other device drivers too). Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Borislav Petkov <petkovbb@gmail.com> Tested-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2008-08-05 18:16:59 +02:00
ide: fix regression caused by ide_device_{get,put}() addition (take 2) On Monday 28 July 2008, Benjamin Herrenschmidt wrote: [...] > Vector: 300 (Data Access) at [c58b7b80] > pc: c014f264: elv_may_queue+0x10/0x44 > lr: c0152750: get_request+0x2c/0x2c0 > sp: c58b7c30 > msr: 1032 > dar: c > dsisr: 40000000 > current = 0xc58aaae0 > pid = 854, comm = media-bay > enter ? for help > mon> t > [c58b7c40] c0152750 get_request+0x2c/0x2c0 > [c58b7c70] c0152a08 get_request_wait+0x24/0xec > [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 > [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc > [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 > [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c > [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 > [c58b7e50] c022395c ide_cd_release+0x80/0x84 > [c58b7e70] c0163650 kref_put+0x54/0x6c > [c58b7e80] c0223884 ide_cd_put+0x40/0x5c > [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c > [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 > [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 > [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 > [c58b7f00] c01e7424 device_del+0x104/0x198 > [c58b7f20] c01e74d0 device_unregister+0x18/0x30 > [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 > [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 > [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 > [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc > [c58b7fd0] c00485c0 kthread+0x48/0x84 > [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 The guilty commit turned out to be 08da591e14cf87247ec09b17c350235157a92fc3 ("ide: add ide_device_{get,put}() helpers"). ide_device_put() is called before kref_put() in ide_cd_put() so IDE device is already gone by the time ide_cd_release() is reached. Fix it by calling ide_device_get() before kref_get() and ide_device_put() after kref_put() in all affected device drivers. v2: Brown paper bag time. In v1 cd->drive was referenced after dropping last reference on cd object (which could result in OOPS in ide_device_put() as reported/debugged by Mariusz Kozlowski). Fix it by caching cd->drive in the local variable (fix other device drivers too). Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Borislav Petkov <petkovbb@gmail.com> Tested-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2008-08-05 18:16:59 +02:00
ide: fix regression caused by ide_device_{get,put}() addition (take 2) On Monday 28 July 2008, Benjamin Herrenschmidt wrote: [...] > Vector: 300 (Data Access) at [c58b7b80] > pc: c014f264: elv_may_queue+0x10/0x44 > lr: c0152750: get_request+0x2c/0x2c0 > sp: c58b7c30 > msr: 1032 > dar: c > dsisr: 40000000 > current = 0xc58aaae0 > pid = 854, comm = media-bay > enter ? for help > mon> t > [c58b7c40] c0152750 get_request+0x2c/0x2c0 > [c58b7c70] c0152a08 get_request_wait+0x24/0xec > [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 > [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc > [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 > [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c > [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 > [c58b7e50] c022395c ide_cd_release+0x80/0x84 > [c58b7e70] c0163650 kref_put+0x54/0x6c > [c58b7e80] c0223884 ide_cd_put+0x40/0x5c > [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c > [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 > [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 > [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 > [c58b7f00] c01e7424 device_del+0x104/0x198 > [c58b7f20] c01e74d0 device_unregister+0x18/0x30 > [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 > [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 > [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 > [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc > [c58b7fd0] c00485c0 kthread+0x48/0x84 > [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 The guilty commit turned out to be 08da591e14cf87247ec09b17c350235157a92fc3 ("ide: add ide_device_{get,put}() helpers"). ide_device_put() is called before kref_put() in ide_cd_put() so IDE device is already gone by the time ide_cd_release() is reached. Fix it by calling ide_device_get() before kref_get() and ide_device_put() after kref_put() in all affected device drivers. v2: Brown paper bag time. In v1 cd->drive was referenced after dropping last reference on cd object (which could result in OOPS in ide_device_put() as reported/debugged by Mariusz Kozlowski). Fix it by caching cd->drive in the local variable (fix other device drivers too). Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Borislav Petkov <petkovbb@gmail.com> Tested-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2008-08-05 18:16:59 +02:00
[PATCH] IDE CD end-of media error fix This is a patch from Alan that fixes a real ide-cd.c regression causing bogus "Media Check" failures for perfectly valid Fedora install ISOs, on certain CD-ROM drives. This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the end of media problem. It may not be sufficient for some controllers (promise notably) and it does not touch the locking so the error path locking is as horked as in mainstream. From: Ingo Molnar <mingo@elte.hu> I have ported the patch to 2.6.17-rc4 and tested it by provoking end-of-media IO errors with an unaligned ISO image. Unlike the vanilla kernel, the patched kernel interpreted the error condition correctly with 512 byte granularity: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 Buffer I/O error on device hdc, logical block 163261 Buffer I/O error on device hdc, logical block 163262 the unpatched kernel produces an incorrect error dump: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306088 Buffer I/O error on device hdc, logical block 163261 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306096 Buffer I/O error on device hdc, logical block 163262 I do not have the right type of CD-ROM drive to reproduce the end-of-media data corruption bug myself, but this same patch in RHEL solved it. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 05:47:44 -07:00
[PATCH] IDE CD end-of media error fix This is a patch from Alan that fixes a real ide-cd.c regression causing bogus "Media Check" failures for perfectly valid Fedora install ISOs, on certain CD-ROM drives. This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the end of media problem. It may not be sufficient for some controllers (promise notably) and it does not touch the locking so the error path locking is as horked as in mainstream. From: Ingo Molnar <mingo@elte.hu> I have ported the patch to 2.6.17-rc4 and tested it by provoking end-of-media IO errors with an unaligned ISO image. Unlike the vanilla kernel, the patched kernel interpreted the error condition correctly with 512 byte granularity: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 Buffer I/O error on device hdc, logical block 163261 Buffer I/O error on device hdc, logical block 163262 the unpatched kernel produces an incorrect error dump: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306088 Buffer I/O error on device hdc, logical block 163261 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306096 Buffer I/O error on device hdc, logical block 163262 I do not have the right type of CD-ROM drive to reproduce the end-of-media data corruption bug myself, but this same patch in RHEL solved it. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 05:47:44 -07:00
[PATCH] IDE CD end-of media error fix This is a patch from Alan that fixes a real ide-cd.c regression causing bogus "Media Check" failures for perfectly valid Fedora install ISOs, on certain CD-ROM drives. This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the end of media problem. It may not be sufficient for some controllers (promise notably) and it does not touch the locking so the error path locking is as horked as in mainstream. From: Ingo Molnar <mingo@elte.hu> I have ported the patch to 2.6.17-rc4 and tested it by provoking end-of-media IO errors with an unaligned ISO image. Unlike the vanilla kernel, the patched kernel interpreted the error condition correctly with 512 byte granularity: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 Buffer I/O error on device hdc, logical block 163261 Buffer I/O error on device hdc, logical block 163262 the unpatched kernel produces an incorrect error dump: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306088 Buffer I/O error on device hdc, logical block 163261 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306096 Buffer I/O error on device hdc, logical block 163262 I do not have the right type of CD-ROM drive to reproduce the end-of-media data corruption bug myself, but this same patch in RHEL solved it. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 05:47:44 -07:00
[PATCH] IDE CD end-of media error fix This is a patch from Alan that fixes a real ide-cd.c regression causing bogus "Media Check" failures for perfectly valid Fedora install ISOs, on certain CD-ROM drives. This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the end of media problem. It may not be sufficient for some controllers (promise notably) and it does not touch the locking so the error path locking is as horked as in mainstream. From: Ingo Molnar <mingo@elte.hu> I have ported the patch to 2.6.17-rc4 and tested it by provoking end-of-media IO errors with an unaligned ISO image. Unlike the vanilla kernel, the patched kernel interpreted the error condition correctly with 512 byte granularity: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 Buffer I/O error on device hdc, logical block 163261 Buffer I/O error on device hdc, logical block 163262 the unpatched kernel produces an incorrect error dump: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306088 Buffer I/O error on device hdc, logical block 163261 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306096 Buffer I/O error on device hdc, logical block 163262 I do not have the right type of CD-ROM drive to reproduce the end-of-media data corruption bug myself, but this same patch in RHEL solved it. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 05:47:44 -07:00
[PATCH] IDE CD end-of media error fix This is a patch from Alan that fixes a real ide-cd.c regression causing bogus "Media Check" failures for perfectly valid Fedora install ISOs, on certain CD-ROM drives. This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the end of media problem. It may not be sufficient for some controllers (promise notably) and it does not touch the locking so the error path locking is as horked as in mainstream. From: Ingo Molnar <mingo@elte.hu> I have ported the patch to 2.6.17-rc4 and tested it by provoking end-of-media IO errors with an unaligned ISO image. Unlike the vanilla kernel, the patched kernel interpreted the error condition correctly with 512 byte granularity: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 Buffer I/O error on device hdc, logical block 163261 Buffer I/O error on device hdc, logical block 163262 the unpatched kernel produces an incorrect error dump: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306088 Buffer I/O error on device hdc, logical block 163261 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306096 Buffer I/O error on device hdc, logical block 163262 I do not have the right type of CD-ROM drive to reproduce the end-of-media data corruption bug myself, but this same patch in RHEL solved it. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 05:47:44 -07:00
[PATCH] IDE CD end-of media error fix This is a patch from Alan that fixes a real ide-cd.c regression causing bogus "Media Check" failures for perfectly valid Fedora install ISOs, on certain CD-ROM drives. This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the end of media problem. It may not be sufficient for some controllers (promise notably) and it does not touch the locking so the error path locking is as horked as in mainstream. From: Ingo Molnar <mingo@elte.hu> I have ported the patch to 2.6.17-rc4 and tested it by provoking end-of-media IO errors with an unaligned ISO image. Unlike the vanilla kernel, the patched kernel interpreted the error condition correctly with 512 byte granularity: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 Buffer I/O error on device hdc, logical block 163261 Buffer I/O error on device hdc, logical block 163262 the unpatched kernel produces an incorrect error dump: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306088 Buffer I/O error on device hdc, logical block 163261 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306096 Buffer I/O error on device hdc, logical block 163262 I do not have the right type of CD-ROM drive to reproduce the end-of-media data corruption bug myself, but this same patch in RHEL solved it. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 05:47:44 -07:00
ide-cd,atapi: use bio for internal commands Impact: unify request data buffer handling rq->data is used mostly to pass kernel buffer through request queue without using bio. There are only a couple of places which still do this in kernel and converting to bio isn't difficult. This patch converts ide-cd and atapi to use bio instead of rq->data for request sense and internal pc commands. With previous change to unify sense request handling, this is relatively easily achieved by adding blk_rq_map_kern() during sense_rq prep and PC issue. If blk_rq_map_kern() fails for sense, the error is deferred till sense issue and aborts the failed command which triggered the sense. Note that this is a slim possibility as sense prep is done on each command issue, so for the above condition to actually trigger, all preps since the last sense issue till the issue of the request which would require a sense should fail. * do_request functions might sleep now. This should be okay as ide request_fn - do_ide_request() - is invoked only from make_request and plug work. Make sure this is the case by adding might_sleep() to do_ide_request(). * Functions which access the read sense data before the sense request is complete now should access bio_data(sense_rq->bio) as the sense buffer might have been copied during blk_rq_map_kern(). * ide-tape updated to map sg. * cdrom_do_block_pc() now doesn't have to deal with REQ_TYPE_ATA_PC special case. Simplified. * tp_ops->output/input_data path dropped from ide_pc_intr(). Signed-off-by: Tejun Heo <tj@kernel.org>
2009-04-19 07:00:42 +09:00
ide-cd,atapi: use bio for internal commands Impact: unify request data buffer handling rq->data is used mostly to pass kernel buffer through request queue without using bio. There are only a couple of places which still do this in kernel and converting to bio isn't difficult. This patch converts ide-cd and atapi to use bio instead of rq->data for request sense and internal pc commands. With previous change to unify sense request handling, this is relatively easily achieved by adding blk_rq_map_kern() during sense_rq prep and PC issue. If blk_rq_map_kern() fails for sense, the error is deferred till sense issue and aborts the failed command which triggered the sense. Note that this is a slim possibility as sense prep is done on each command issue, so for the above condition to actually trigger, all preps since the last sense issue till the issue of the request which would require a sense should fail. * do_request functions might sleep now. This should be okay as ide request_fn - do_ide_request() - is invoked only from make_request and plug work. Make sure this is the case by adding might_sleep() to do_ide_request(). * Functions which access the read sense data before the sense request is complete now should access bio_data(sense_rq->bio) as the sense buffer might have been copied during blk_rq_map_kern(). * ide-tape updated to map sg. * cdrom_do_block_pc() now doesn't have to deal with REQ_TYPE_ATA_PC special case. Simplified. * tp_ops->output/input_data path dropped from ide_pc_intr(). Signed-off-by: Tejun Heo <tj@kernel.org>
2009-04-19 07:00:42 +09:00
ide-cd,atapi: use bio for internal commands Impact: unify request data buffer handling rq->data is used mostly to pass kernel buffer through request queue without using bio. There are only a couple of places which still do this in kernel and converting to bio isn't difficult. This patch converts ide-cd and atapi to use bio instead of rq->data for request sense and internal pc commands. With previous change to unify sense request handling, this is relatively easily achieved by adding blk_rq_map_kern() during sense_rq prep and PC issue. If blk_rq_map_kern() fails for sense, the error is deferred till sense issue and aborts the failed command which triggered the sense. Note that this is a slim possibility as sense prep is done on each command issue, so for the above condition to actually trigger, all preps since the last sense issue till the issue of the request which would require a sense should fail. * do_request functions might sleep now. This should be okay as ide request_fn - do_ide_request() - is invoked only from make_request and plug work. Make sure this is the case by adding might_sleep() to do_ide_request(). * Functions which access the read sense data before the sense request is complete now should access bio_data(sense_rq->bio) as the sense buffer might have been copied during blk_rq_map_kern(). * ide-tape updated to map sg. * cdrom_do_block_pc() now doesn't have to deal with REQ_TYPE_ATA_PC special case. Simplified. * tp_ops->output/input_data path dropped from ide_pc_intr(). Signed-off-by: Tejun Heo <tj@kernel.org>
2009-04-19 07:00:42 +09:00
ide-cd,atapi: use bio for internal commands Impact: unify request data buffer handling rq->data is used mostly to pass kernel buffer through request queue without using bio. There are only a couple of places which still do this in kernel and converting to bio isn't difficult. This patch converts ide-cd and atapi to use bio instead of rq->data for request sense and internal pc commands. With previous change to unify sense request handling, this is relatively easily achieved by adding blk_rq_map_kern() during sense_rq prep and PC issue. If blk_rq_map_kern() fails for sense, the error is deferred till sense issue and aborts the failed command which triggered the sense. Note that this is a slim possibility as sense prep is done on each command issue, so for the above condition to actually trigger, all preps since the last sense issue till the issue of the request which would require a sense should fail. * do_request functions might sleep now. This should be okay as ide request_fn - do_ide_request() - is invoked only from make_request and plug work. Make sure this is the case by adding might_sleep() to do_ide_request(). * Functions which access the read sense data before the sense request is complete now should access bio_data(sense_rq->bio) as the sense buffer might have been copied during blk_rq_map_kern(). * ide-tape updated to map sg. * cdrom_do_block_pc() now doesn't have to deal with REQ_TYPE_ATA_PC special case. Simplified. * tp_ops->output/input_data path dropped from ide_pc_intr(). Signed-off-by: Tejun Heo <tj@kernel.org>
2009-04-19 07:00:42 +09:00
ide-cd,atapi: use bio for internal commands Impact: unify request data buffer handling rq->data is used mostly to pass kernel buffer through request queue without using bio. There are only a couple of places which still do this in kernel and converting to bio isn't difficult. This patch converts ide-cd and atapi to use bio instead of rq->data for request sense and internal pc commands. With previous change to unify sense request handling, this is relatively easily achieved by adding blk_rq_map_kern() during sense_rq prep and PC issue. If blk_rq_map_kern() fails for sense, the error is deferred till sense issue and aborts the failed command which triggered the sense. Note that this is a slim possibility as sense prep is done on each command issue, so for the above condition to actually trigger, all preps since the last sense issue till the issue of the request which would require a sense should fail. * do_request functions might sleep now. This should be okay as ide request_fn - do_ide_request() - is invoked only from make_request and plug work. Make sure this is the case by adding might_sleep() to do_ide_request(). * Functions which access the read sense data before the sense request is complete now should access bio_data(sense_rq->bio) as the sense buffer might have been copied during blk_rq_map_kern(). * ide-tape updated to map sg. * cdrom_do_block_pc() now doesn't have to deal with REQ_TYPE_ATA_PC special case. Simplified. * tp_ops->output/input_data path dropped from ide_pc_intr(). Signed-off-by: Tejun Heo <tj@kernel.org>
2009-04-19 07:00:42 +09:00
block: add rq->resid_len rq->data_len served two purposes - the length of data buffer on issue and the residual count on completion. This duality creates some headaches. First of all, block layer and low level drivers can't really determine what rq->data_len contains while a request is executing. It could be the total request length or it coulde be anything else one of the lower layers is using to keep track of residual count. This complicates things because blk_rq_bytes() and thus [__]blk_end_request_all() relies on rq->data_len for PC commands. Drivers which want to report residual count should first cache the total request length, update rq->data_len and then complete the request with the cached data length. Secondly, it makes requests default to reporting full residual count, ie. reporting that no data transfer occurred. The residual count is an exception not the norm; however, the driver should clear rq->data_len to zero to signify the normal cases while leaving it alone means no data transfer occurred at all. This reverse default behavior complicates code unnecessarily and renders block PC on some drivers (ide-tape/floppy) unuseable. This patch adds rq->resid_len which is used only for residual count. While at it, remove now unnecessasry blk_rq_bytes() caching in ide_pc_intr() as rq->data_len is not changed anymore. Boaz : spotted missing conversion in osd Sergei : spotted too early conversion to blk_rq_bytes() in ide-tape [ Impact: cleanup residual count handling, report 0 resid by default ] Signed-off-by: Tejun Heo <tj@kernel.org> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Cc: Borislav Petkov <petkovbb@googlemail.com> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Mike Miller <mike.miller@hp.com> Cc: Eric Moore <Eric.Moore@lsi.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Doug Gilbert <dgilbert@interlog.com> Cc: Mike Miller <mike.miller@hp.com> Cc: Eric Moore <Eric.Moore@lsi.com> Cc: Darrick J. Wong <djwong@us.ibm.com> Cc: Pete Zaitcev <zaitcev@redhat.com> Cc: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 22:24:37 +09:00
block: set rq->resid_len to blk_rq_bytes() on issue In commit c3a4d78c580de4edc9ef0f7c59812fb02ceb037f, while introducing rq->resid_len, the default value of residue count was changed from full count to zero. The conversion was done under the assumption that when a request fails residue count wasn't defined. However, Boaz and James pointed out that this wasn't true and the residue count should be preserved for failed requests too. This patchset restores the original behavior by setting rq->resid_len to blk_rq_bytes(rq) on request start and restoring explicit clearing in affected drivers. While at it, take advantage of the fact that rq->resid_len is set to full count where applicable. * ide-cd: rq->resid_len cleared on pc success * mptsas: req->resid_len cleared on success * sas_expander: rsp/req->resid_len cleared on success * mpt2sas_transport: req->resid_len cleared on success * ide-cd, ide-tape, mptsas, sas_host_smp, mpt2sas_transport, ub: take advantage of initial full count to simplify code Boaz Harrosh spotted bug in resid_len initialization. Fixed as suggested. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Borislav Petkov <petkovbb@googlemail.com> Cc: Boaz Harrosh <bharrosh@panasas.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Pete Zaitcev <zaitcev@redhat.com> Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Eric Moore <Eric.Moore@lsi.com> Cc: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-19 18:33:05 +09:00
block: set rq->resid_len to blk_rq_bytes() on issue In commit c3a4d78c580de4edc9ef0f7c59812fb02ceb037f, while introducing rq->resid_len, the default value of residue count was changed from full count to zero. The conversion was done under the assumption that when a request fails residue count wasn't defined. However, Boaz and James pointed out that this wasn't true and the residue count should be preserved for failed requests too. This patchset restores the original behavior by setting rq->resid_len to blk_rq_bytes(rq) on request start and restoring explicit clearing in affected drivers. While at it, take advantage of the fact that rq->resid_len is set to full count where applicable. * ide-cd: rq->resid_len cleared on pc success * mptsas: req->resid_len cleared on success * sas_expander: rsp/req->resid_len cleared on success * mpt2sas_transport: req->resid_len cleared on success * ide-cd, ide-tape, mptsas, sas_host_smp, mpt2sas_transport, ub: take advantage of initial full count to simplify code Boaz Harrosh spotted bug in resid_len initialization. Fixed as suggested. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Borislav Petkov <petkovbb@googlemail.com> Cc: Boaz Harrosh <bharrosh@panasas.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Pete Zaitcev <zaitcev@redhat.com> Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Eric Moore <Eric.Moore@lsi.com> Cc: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-19 18:33:05 +09:00
block: add rq->resid_len rq->data_len served two purposes - the length of data buffer on issue and the residual count on completion. This duality creates some headaches. First of all, block layer and low level drivers can't really determine what rq->data_len contains while a request is executing. It could be the total request length or it coulde be anything else one of the lower layers is using to keep track of residual count. This complicates things because blk_rq_bytes() and thus [__]blk_end_request_all() relies on rq->data_len for PC commands. Drivers which want to report residual count should first cache the total request length, update rq->data_len and then complete the request with the cached data length. Secondly, it makes requests default to reporting full residual count, ie. reporting that no data transfer occurred. The residual count is an exception not the norm; however, the driver should clear rq->data_len to zero to signify the normal cases while leaving it alone means no data transfer occurred at all. This reverse default behavior complicates code unnecessarily and renders block PC on some drivers (ide-tape/floppy) unuseable. This patch adds rq->resid_len which is used only for residual count. While at it, remove now unnecessasry blk_rq_bytes() caching in ide_pc_intr() as rq->data_len is not changed anymore. Boaz : spotted missing conversion in osd Sergei : spotted too early conversion to blk_rq_bytes() in ide-tape [ Impact: cleanup residual count handling, report 0 resid by default ] Signed-off-by: Tejun Heo <tj@kernel.org> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Cc: Borislav Petkov <petkovbb@googlemail.com> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: Mike Miller <mike.miller@hp.com> Cc: Eric Moore <Eric.Moore@lsi.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Doug Gilbert <dgilbert@interlog.com> Cc: Mike Miller <mike.miller@hp.com> Cc: Eric Moore <Eric.Moore@lsi.com> Cc: Darrick J. Wong <djwong@us.ibm.com> Cc: Pete Zaitcev <zaitcev@redhat.com> Cc: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 22:24:37 +09:00
ide-cd,atapi: use bio for internal commands Impact: unify request data buffer handling rq->data is used mostly to pass kernel buffer through request queue without using bio. There are only a couple of places which still do this in kernel and converting to bio isn't difficult. This patch converts ide-cd and atapi to use bio instead of rq->data for request sense and internal pc commands. With previous change to unify sense request handling, this is relatively easily achieved by adding blk_rq_map_kern() during sense_rq prep and PC issue. If blk_rq_map_kern() fails for sense, the error is deferred till sense issue and aborts the failed command which triggered the sense. Note that this is a slim possibility as sense prep is done on each command issue, so for the above condition to actually trigger, all preps since the last sense issue till the issue of the request which would require a sense should fail. * do_request functions might sleep now. This should be okay as ide request_fn - do_ide_request() - is invoked only from make_request and plug work. Make sure this is the case by adding might_sleep() to do_ide_request(). * Functions which access the read sense data before the sense request is complete now should access bio_data(sense_rq->bio) as the sense buffer might have been copied during blk_rq_map_kern(). * ide-tape updated to map sg. * cdrom_do_block_pc() now doesn't have to deal with REQ_TYPE_ATA_PC special case. Simplified. * tp_ops->output/input_data path dropped from ide_pc_intr(). Signed-off-by: Tejun Heo <tj@kernel.org>
2009-04-19 07:00:42 +09:00
ide-cd,atapi: use bio for internal commands Impact: unify request data buffer handling rq->data is used mostly to pass kernel buffer through request queue without using bio. There are only a couple of places which still do this in kernel and converting to bio isn't difficult. This patch converts ide-cd and atapi to use bio instead of rq->data for request sense and internal pc commands. With previous change to unify sense request handling, this is relatively easily achieved by adding blk_rq_map_kern() during sense_rq prep and PC issue. If blk_rq_map_kern() fails for sense, the error is deferred till sense issue and aborts the failed command which triggered the sense. Note that this is a slim possibility as sense prep is done on each command issue, so for the above condition to actually trigger, all preps since the last sense issue till the issue of the request which would require a sense should fail. * do_request functions might sleep now. This should be okay as ide request_fn - do_ide_request() - is invoked only from make_request and plug work. Make sure this is the case by adding might_sleep() to do_ide_request(). * Functions which access the read sense data before the sense request is complete now should access bio_data(sense_rq->bio) as the sense buffer might have been copied during blk_rq_map_kern(). * ide-tape updated to map sg. * cdrom_do_block_pc() now doesn't have to deal with REQ_TYPE_ATA_PC special case. Simplified. * tp_ops->output/input_data path dropped from ide_pc_intr(). Signed-off-by: Tejun Heo <tj@kernel.org>
2009-04-19 07:00:42 +09:00
[PATCH] IDE CD end-of media error fix This is a patch from Alan that fixes a real ide-cd.c regression causing bogus "Media Check" failures for perfectly valid Fedora install ISOs, on certain CD-ROM drives. This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the end of media problem. It may not be sufficient for some controllers (promise notably) and it does not touch the locking so the error path locking is as horked as in mainstream. From: Ingo Molnar <mingo@elte.hu> I have ported the patch to 2.6.17-rc4 and tested it by provoking end-of-media IO errors with an unaligned ISO image. Unlike the vanilla kernel, the patched kernel interpreted the error condition correctly with 512 byte granularity: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 Buffer I/O error on device hdc, logical block 163261 Buffer I/O error on device hdc, logical block 163262 the unpatched kernel produces an incorrect error dump: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306088 Buffer I/O error on device hdc, logical block 163261 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306096 Buffer I/O error on device hdc, logical block 163262 I do not have the right type of CD-ROM drive to reproduce the end-of-media data corruption bug myself, but this same patch in RHEL solved it. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 05:47:44 -07:00
[PATCH] IDE CD end-of media error fix This is a patch from Alan that fixes a real ide-cd.c regression causing bogus "Media Check" failures for perfectly valid Fedora install ISOs, on certain CD-ROM drives. This is a forward port to 2.6.16 (from RHEL) of the minimal changes for the end of media problem. It may not be sufficient for some controllers (promise notably) and it does not touch the locking so the error path locking is as horked as in mainstream. From: Ingo Molnar <mingo@elte.hu> I have ported the patch to 2.6.17-rc4 and tested it by provoking end-of-media IO errors with an unaligned ISO image. Unlike the vanilla kernel, the patched kernel interpreted the error condition correctly with 512 byte granularity: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown ATAPI device hdc: Error: Illegal request -- (Sense key=0x05) Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 fb 78 00 00 06 00 00 00 00 00 00 00 " end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 Buffer I/O error on device hdc, logical block 163261 Buffer I/O error on device hdc, logical block 163262 the unpatched kernel produces an incorrect error dump: hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306080 Buffer I/O error on device hdc, logical block 163260 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306088 Buffer I/O error on device hdc, logical block 163261 hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } ide: failed opcode was: unknown end_request: I/O error, dev hdc, sector 1306096 Buffer I/O error on device hdc, logical block 163262 I do not have the right type of CD-ROM drive to reproduce the end-of-media data corruption bug myself, but this same patch in RHEL solved it. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Jens Axboe <axboe@suse.de> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 05:47:44 -07:00
[PATCH] ide: MODALIAS support for autoloading of ide-cd, ide-disk, ... IDE: MODALIAS support for autoloading of ide-cd, ide-disk, ... Add MODULE_ALIAS to IDE midlayer modules: ide-disk, ide-cd, ide-floppy and ide-tape, to autoload these modules depending on the probed media type of the IDE device. It is used by udev and replaces the former agent shell script of the hotplug package, which was required to lookup the media type in the proc filesystem. Using proc was racy, cause the media file is created after the hotplug event is sent out. The module autoloading does not take any effect, until something like the following udev rule is configured: SUBSYSTEM=="ide", ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}" The module ide-scsi will not be autoloaded, cause it requires manual configuration. It can't be, and never was supported for automatic setup in the hotplug package. Adding a MODULE_ALIAS to ide-scsi for all supported media types, would just lead to a default blacklist entry anyway. $ modinfo ide-disk filename: /lib/modules/2.6.15-rc4-g1b0997f5/kernel/drivers/ide/ide-disk.ko description: ATA DISK Driver alias: ide:*m-disk* license: GPL ... $ modprobe -vn ide:m-disk insmod /lib/modules/2.6.15-rc4-g1b0997f5/kernel/drivers/ide/ide-disk.ko $ cat /sys/bus/ide/devices/0.0/modalias ide:m-disk It also adds attributes to the IDE device: $ tree /sys/bus/ide/devices/0.0/ /sys/bus/ide/devices/0.0/ |-- bus -> ../../../../../../../bus/ide |-- drivename |-- media |-- modalias |-- power | |-- state | `-- wakeup `-- uevent $ cat /sys/bus/ide/devices/0.0/{modalias,drivename,media} ide:m-disk hda disk Signed-off-by: Kay Sievers <kay.sievers@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-12-12 18:03:44 +01:00