* "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11
@ 2003-11-29 18:31 Darren Dupre
2003-11-29 18:53 ` Darren Dupre
2003-11-29 21:38 ` Adam Kropelin
0 siblings, 2 replies; 4+ messages in thread
From: Darren Dupre @ 2003-11-29 18:31 UTC (permalink / raw)
To: linux-kernel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11
2003-11-29 18:31 "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11 Darren Dupre
@ 2003-11-29 18:53 ` Darren Dupre
2003-11-29 21:38 ` Adam Kropelin
1 sibling, 0 replies; 4+ messages in thread
From: Darren Dupre @ 2003-11-29 18:53 UTC (permalink / raw)
To: linux-kernel
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].
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11
2003-11-29 18:31 "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11 Darren Dupre
2003-11-29 18:53 ` Darren Dupre
@ 2003-11-29 21:38 ` Adam Kropelin
2003-11-29 20:20 ` Darren Dupre
1 sibling, 1 reply; 4+ messages in thread
From: Adam Kropelin @ 2003-11-29 21:38 UTC (permalink / raw)
To: Darren Dupre; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11
2003-11-29 21:38 ` Adam Kropelin
@ 2003-11-29 20:20 ` Darren Dupre
0 siblings, 0 replies; 4+ messages in thread
From: Darren Dupre @ 2003-11-29 20:20 UTC (permalink / raw)
To: Adam Kropelin; +Cc: linux-kernel
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
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-11-29 20:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-29 18:31 "DV failed to configure device" for Quantum DLT4000 tape drive on Adaptec 2940UW, 2.6.0-test11 Darren Dupre
2003-11-29 18:53 ` Darren Dupre
2003-11-29 21:38 ` Adam Kropelin
2003-11-29 20:20 ` Darren Dupre
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).