"DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11

"DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11

[Darren Dupre]

I only use my Adaptec 2940-UW for doing weekly backups to my Quantum DLT4000
(external) tape drive. On the 2.4 kernels, I'd just modprobe aic7xx and it
would detect the tape drive, load the st module and I could do my usual tar
command to backup stuff to tape. On 2.6.0-test11, I modprobe aic7xxx and it
detects the drive but it says "scsi0:A:5:0: DV failed to configure device.
Please file a bug report against this driver." and the st module does not
get loaded.

Not sure what this means.. I didnt have this problem with 2.4.21.

However, I can modprobe st and use the tape drive just fine.

Here is the relevant bits out of my syslog:

Nov 29 12:18:37 dmdtech kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI
HBA DRIVER, Rev 6.2.35
Nov 29 12:18:37 dmdtech kernel:         <Adaptec 2940 Ultra SCSI adapter>
Nov 29 12:18:37 dmdtech kernel:         aic7880: Ultra Wide Channel A, SCSI
Id=7, 16/253 SCBs
Nov 29 12:18:37 dmdtech kernel:
Nov 29 12:19:01 dmdtech kernel: scsi0:A:5:0: DV failed to configure device.
Please file a bug report against this driver.
Nov 29 12:19:05 dmdtech kernel: (scsi0:A:5): 10.000MB/s transfers
(10.000MHz, offset 15)
Nov 29 12:19:05 dmdtech kernel:   Vendor: Quantum   Model: DLT4000
Rev: CC37
Nov 29 12:19:05 dmdtech kernel:   Type:   Sequential-Access
ANSI SCSI revision: 02
Nov 29 12:20:18 dmdtech kernel: st: Version 20030811, fixed bufsize 32768,
s/g segs 256 <- this is when I manually loaded the st module
Nov 29 12:20:18 dmdtech kernel: Attached scsi tape st0 at scsi0, channel 0,
id 5, lun 0
Nov 29 12:20:18 dmdtech kernel: st0: try direct i/o: yes, max page reachable
by HBA 1048575
Nov 29 12:20:23 dmdtech kernel: st0: Block limits 1 - 16777215 bytes.

Re: "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11

[Darren Dupre]

The backup just finished.. I unloaded the modules (doing "rmmod st aic7xxx"
exactly like that)

Now the kernel barfs this out at me (again, this is 2.6.0-test11)  right as
or after I unload the modules:

Nov 29 12:47:49 dmdtech kernel: st: Unloaded.
Nov 29 12:47:49 dmdtech kernel: bad: scheduling while atomic!
Nov 29 12:47:49 dmdtech kernel: Call Trace:
Nov 29 12:47:49 dmdtech kernel:  [<c0119963>] schedule+0x563/0x570
Nov 29 12:47:49 dmdtech kernel:  [<c0118b9e>] try_to_wake_up+0x9e/0x160
Nov 29 12:47:49 dmdtech kernel:  [<c0108076>] __down+0x96/0x110
Nov 29 12:47:49 dmdtech kernel:  [<c01199d0>] default_wake_function+0x0/0x20
Nov 29 12:47:49 dmdtech kernel:  [<c01082ac>] __down_failed+0x8/0xc
Nov 29 12:47:49 dmdtech kernel:  [<e0904480>]
.text.lock.aic7xxx_osm+0x19/0x99 [aic7xxx]
Nov 29 12:47:49 dmdtech kernel:  [<e09061e8>] ahc_linux_exit+0x28/0x82
[aic7xxx]
Nov 29 12:47:49 dmdtech kernel:  [<c0131e9c>] sys_delete_module+0x14c/0x1b0
Nov 29 12:47:49 dmdtech kernel:  [<c0144fca>] do_munmap+0x14a/0x190
Nov 29 12:47:49 dmdtech kernel:  [<c010935b>] syscall_call+0x7/0xb
Nov 29 12:47:49 dmdtech kernel:
Nov 29 12:47:49 dmdtech kernel: bad: scheduling while atomic!
Nov 29 12:47:49 dmdtech kernel: Call Trace:
Nov 29 12:47:49 dmdtech kernel:  [<c0119963>] schedule+0x563/0x570
Nov 29 12:47:49 dmdtech kernel:  [<c0134a24>]
__remove_from_page_cache+0x24/0x70
Nov 29 12:47:49 dmdtech kernel:  [<c013da18>] __pagevec_release+0x28/0x40
Nov 29 12:47:49 dmdtech kernel:  [<c013e004>]
truncate_inode_pages+0xf4/0x2c0
Nov 29 12:47:49 dmdtech kernel:  [<c015e003>] cached_lookup+0x23/0x90
Nov 29 12:47:49 dmdtech kernel:  [<c015f062>] __lookup_hash+0x72/0xe0
Nov 29 12:47:49 dmdtech kernel:  [<c016a59e>]
generic_delete_inode+0xfe/0x110
Nov 29 12:47:49 dmdtech kernel:  [<c016a782>] iput+0x62/0x80
Nov 29 12:47:49 dmdtech kernel:  [<c016767f>] dput+0xff/0x220
Nov 29 12:47:49 dmdtech kernel:  [<c018233d>]
sysfs_hash_and_remove+0x4d/0x7d
Nov 29 12:47:49 dmdtech kernel:  [<c01e8f25>] class_device_dev_unlink+0x25/0
x30
Nov 29 12:47:49 dmdtech kernel:  [<c01e9315>] class_device_del+0x75/0xb0
Nov 29 12:47:49 dmdtech kernel:  [<c01e9363>]
class_device_unregister+0x13/0x30
Nov 29 12:47:49 dmdtech kernel:  [<c0210055>] scsi_remove_device+0x45/0x80
Nov 29 12:47:49 dmdtech kernel:  [<c020f5ca>] scsi_forget_host+0x4a/0x90
Nov 29 12:47:49 dmdtech kernel:  [<c0209a4b>] scsi_remove_host+0x2b/0x60
Nov 29 12:47:49 dmdtech kernel:  [<e08ff211>] ahc_platform_free+0x141/0x160
[aic7xxx]
Nov 29 12:47:49 dmdtech kernel:  [<e08f160f>] ahc_free+0xbf/0x130 [aic7xxx]
Nov 29 12:47:49 dmdtech kernel:  [<e09051ea>]
ahc_linux_pci_dev_remove+0x6a/0xa0 [aic7xxx]
Nov 29 12:47:49 dmdtech kernel:  [<c01aa28b>] pci_device_remove+0x3b/0x40
Nov 29 12:47:49 dmdtech kernel:  [<c01e8614>]
device_release_driver+0x64/0x70
Nov 29 12:47:49 dmdtech kernel:  [<c01e8640>] driver_detach+0x20/0x30
Nov 29 12:47:49 dmdtech kernel:  [<c01e886d>] bus_remove_driver+0x3d/0x80
Nov 29 12:47:49 dmdtech kernel:  [<c01e8cc3>] driver_unregister+0x13/0x28
Nov 29 12:47:49 dmdtech kernel:  [<c01aa422>]
pci_unregister_driver+0x12/0x20
Nov 29 12:47:49 dmdtech kernel:  [<e090540f>] ahc_linux_pci_exit+0xf/0x20
[aic7xxx]
Nov 29 12:47:50 dmdtech kernel:  [<e090620e>] ahc_linux_exit+0x4e/0x82
[aic7xxx]
Nov 29 12:47:50 dmdtech kernel:  [<c0131e9c>] sys_delete_module+0x14c/0x1b0
Nov 29 12:47:50 dmdtech kernel:  [<c0144fca>] do_munmap+0x14a/0x190
Nov 29 12:47:50 dmdtech kernel:  [<c010935b>] syscall_call+0x7/0xb
Nov 29 12:47:50 dmdtech kernel:
Nov 29 12:47:50 dmdtech kernel: bad: scheduling while atomic!
Nov 29 12:47:50 dmdtech kernel: Call Trace:
Nov 29 12:47:50 dmdtech kernel:  [<c0119963>] schedule+0x563/0x570
Nov 29 12:47:50 dmdtech kernel:  [<c0119caf>] wait_for_completion+0x8f/0xe0
Nov 29 12:47:50 dmdtech kernel:  [<c01199d0>] default_wake_function+0x0/0x20
Nov 29 12:47:50 dmdtech kernel:  [<c01199d0>] default_wake_function+0x0/0x20
Nov 29 12:47:50 dmdtech kernel:  [<c0209c21>]
scsi_host_dev_release+0x81/0x90
Nov 29 12:47:50 dmdtech kernel:  [<c01e7320>] device_release+0x20/0x80
Nov 29 12:47:50 dmdtech kernel:  [<c01a478a>] kobject_del+0x5a/0x70
Nov 29 12:47:50 dmdtech kernel:  [<c01a448a>] unlink+0x7a/0x80
Nov 29 12:47:50 dmdtech kernel:  [<c01a48a0>] kobject_cleanup+0x80/0x90
Nov 29 12:47:50 dmdtech kernel:  [<e08ff225>] ahc_platform_free+0x155/0x160
[aic7xxx]
Nov 29 12:47:50 dmdtech kernel:  [<e08f160f>] ahc_free+0xbf/0x130 [aic7xxx]
Nov 29 12:47:50 dmdtech kernel:  [<e09051ea>]
ahc_linux_pci_dev_remove+0x6a/0xa0 [aic7xxx]
Nov 29 12:47:50 dmdtech kernel:  [<c01aa28b>] pci_device_remove+0x3b/0x40
Nov 29 12:47:50 dmdtech kernel:  [<c01e8614>]
device_release_driver+0x64/0x70
Nov 29 12:47:50 dmdtech kernel:  [<c01e8640>] driver_detach+0x20/0x30
Nov 29 12:47:50 dmdtech kernel:  [<c01e886d>] bus_remove_driver+0x3d/0x80
Nov 29 12:47:50 dmdtech kernel:  [<c01e8cc3>] driver_unregister+0x13/0x28
Nov 29 12:47:50 dmdtech kernel:  [<c01aa422>]
pci_unregister_driver+0x12/0x20
Nov 29 12:47:50 dmdtech kernel:  [<e090540f>] ahc_linux_pci_exit+0xf/0x20
[aic7xxx]
Nov 29 12:47:50 dmdtech kernel:  [<e090620e>] ahc_linux_exit+0x4e/0x82
[aic7xxx]
Nov 29 12:47:50 dmdtech kernel:  [<c0131e9c>] sys_delete_module+0x14c/0x1b0
Nov 29 12:47:50 dmdtech kernel:  [<c0144fca>] do_munmap+0x14a/0x190
Nov 29 12:47:50 dmdtech kernel:  [<c010935b>] syscall_call+0x7/0xb
Nov 29 12:47:50 dmdtech kernel:

if it helps, here is the entry for the SCSI card from /proc/pci:

 Bus  0, device  12, function  0:
    SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC (rev 0).
      IRQ 16.
      Master Capable.  Latency=64.  Min Gnt=8.Max Lat=8.
      I/O at 0xdc00 [0xdcff].
      Non-prefetchable 32 bit memory at 0xdbfef000 [0xdbfeffff].

Re: "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11

[Darren Dupre]

Hmm. That does reflect exactly what happened in my situation. I turned on
the tape drive, inserted a tape, and while it was busy rewinding, I inserted
the aic7xxx module.

I just tried inserting the module again, this time with no tape in the drive
as I turned it on and it initializes just fine and loads the st module. It
works fine doing everything else AFAIK.

But it still complains when I unload the modules..

Adam Kropelin <akropel1@rochester.rr.com>
>
> I've seen this same issue with my Quantum DLT4000 & 2940UW as well. It
> seems to have to do with there being a tape in the drive when the
> aic7xxx driver initializes. It looks to me like the DLT4000 does not
> respond to the DV configuration attempt when it is in the middle of
> rewinding a tape. If the rewind takes long enough, aic7xxx times out the
> configuration and gives the message you saw.
>
> I run a completely static kernel so in my case the problem happens when
> I reboot the machine with a tape still in the drive and the tape is
> positioned near the end. When the 2940UW BIOS initializes it triggers
> the DLT4000 to start rewinding the tape and if the tape is positioned
> far enough along it can still be rewinding when the kernel boots and
> aic7xxx tries to perform the DV configuration.
>
> --Adam
>
>

Re: "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11

[Adam Kropelin]

On Sat, Nov 29, 2003 at 12:31:14PM -0600, Darren Dupre wrote:
> I only use my Adaptec 2940-UW for doing weekly backups to my Quantum DLT4000
> (external) tape drive. On the 2.4 kernels, I'd just modprobe aic7xx and it
> would detect the tape drive, load the st module and I could do my usual tar
> command to backup stuff to tape. On 2.6.0-test11, I modprobe aic7xxx and it
> detects the drive but it says "scsi0:A:5:0: DV failed to configure device.
> Please file a bug report against this driver." and the st module does not
> get loaded.
> 
> Not sure what this means.. I didnt have this problem with 2.4.21.
> 
> However, I can modprobe st and use the tape drive just fine.

I've seen this same issue with my Quantum DLT4000 & 2940UW as well. It
seems to have to do with there being a tape in the drive when the
aic7xxx driver initializes. It looks to me like the DLT4000 does not
respond to the DV configuration attempt when it is in the middle of
rewinding a tape. If the rewind takes long enough, aic7xxx times out the
configuration and gives the message you saw. 

I run a completely static kernel so in my case the problem happens when
I reboot the machine with a tape still in the drive and the tape is
positioned near the end. When the 2940UW BIOS initializes it triggers
the DLT4000 to start rewinding the tape and if the tape is positioned
far enough along it can still be rewinding when the kernel boots and 
aic7xxx tries to perform the DV configuration.

--Adam