From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4 Description of problem: In FC4 (not in FC3, it works fine) the ide code is patched when compared to the stock kernel version in a way that zaps rq->errors in such a way, that idescsi_check_condition is never called from idescsi_end_request. I believe this is caused by the following change: --- kernel/linux-2.6.11/drivers/ide/ide-io.c 2005-03-02 02:38:19.000000000 -0500 +++ rpmbuild/BUILD/kernel-2.6.11-fc4/linux-2.6.11/drivers/ide/ide-io.c 2005-06-12 13:37:11.145605890 -0400 @@ -417,11 +434,8 @@ spin_lock_irqsave(&ide_lock, flags); blkdev_dequeue_request(rq); - - if (blk_barrier_preflush(rq) || blk_barrier_postflush(rq)) - ide_complete_barrier(drive, rq, err); - HWGROUP(drive)->rq = NULL; + rq->errors = err; end_that_request_last(rq); spin_unlock_irqrestore(&ide_lock, flags); } Attached to this bug report is a patch to ide-scsi that works around the above change, and makes it work for me again. Version-Release number of selected component (if applicable): kernel-smp-2.6.11-1.1369_FC4 How reproducible: Always Steps to Reproduce: 1.have an internal IDE tape drive without tape present 2.use ide-scsi + st (or osst) drivers and _not_ ide-tape 3.run 'mt -f /dev/nst0 status' (or 'mt -f /dev/nosst0 status') Actual Results: with DI-30 and osst, mt hangs for 30 minutes Expected Results: mt should return (virtually) immediately and print: [root@test26 ~]# mt -f /dev/nosst0 status OnStream SC-, DI-, DP-, or USB tape drive: File number=-1, block number=-1. Tape block size 0 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (50000): DR_OPEN IM_REP_EN Additional info:
Created attachment 115639 [details] patch to drivers/scsi/ide-scsi.c that works around change to drivers/ide/ide-io.c patch copies rq->errors to a local variable in idescsi_end_request() which is used later so it doesn't matter that ide_end_drive_cmd() changes rq->errors
[This comment has been added as a mass update for all FC4 kernel bugs. If you have migrated this bug from an FC3 bug today, ignore this comment.] Please retest your problem with todays 2.6.12-1.1398_FC4 update. If your problem involved being unable to boot, or some hardware not being detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE* installing any kernel updates. If in doubt, you can recreate this file using.. mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak mv /etc/modprobe.conf /etc/modprobe.conf.bak kudzu Thank you.
Unfortunately, kernel 1398 does not help. Here is what I get: [root@test26 ~]# uname -a Linux test26.riede.org 2.6.12-1.1398_FC4smp #1 SMP Fri Jul 15 01:30:13 EDT 2005 i686 i686 i386 GNU/Linux [root@test26 ~]# date ; mt -f /dev/nosst0 status ; date ; mt -f /dev/nosst1 status ; date Sun Jul 17 12:20:53 EDT 2005 OnStream SC-, DI-, DP-, or USB tape drive: File number=-1, block number=-1. Tape block size 0 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (50000): DR_OPEN IM_REP_EN Sun Jul 17 12:20:53 EDT 2005 OnStream SC-, DI-, DP-, or USB tape drive: File number=-1, block number=-1. Tape block size 512 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (1010000): ONLINE IM_REP_EN Sun Jul 17 12:46:10 EDT 2005 [root@test26 ~]# tail /var/log/messages Jul 17 12:11:34 test26 syslogd 1.4.1: restart. Jul 17 12:20:53 test26 kernel: osst0:I: Device did not become Ready in open Jul 17 12:46:10 test26 kernel: osst1:E: Failed to find valid ADRL header, new media? In the above, as before, osst0 is the SCSI drive and functions correctly, and osst1 is the equivalent ATAPI model and misbehaves. The log output implies that ide-scsi still doesn't "see" the NOT_READY due to medium not present and makes osst believe there is a tape in the drive which it then tries to read with a long timeout, and fails, inevitably. If there's any other experiment you want me to do, just ask. Regards, Willem Riede.
This bug followed the kernel port to 1372_FC3 and 1373_FC3. The ide-scsi patch which Willem Riede submitted seems to correct it. The error generated by osst is "osst0:W: Found logical frame 20 instead of 0 after fast open". Writing to the device appears to work for a few minutes, then the application (mt and bacula in my case) hangs in a perpetual devicewait state. Regards Gordon Larsen
Merged to CVS, will be in next update.
Looks like this bug has leaked back into the 2.6.13-1.1526_FC4 kernel. Re-applying Willem's patch to ide-scsi.c and recompiling corrects the issue once again. Regards, Gordon Larsen
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
Fix is in 2.6.15 git tree not 2.6.14
it was backported to current update.
I've tested kernel 1637_FC4 with my DI-30 ATAPI tape drive, using ide-scsi and osst, as well as with my Connor ATAPI tape drive using ide-scsi and st, and all is working just fine. Thanks!
I concur, my DI-30 ATAPI drive using ide-scsi and osst works fine with this release. Regards, Gord