Hi!
There is a problem with the AM53C974 Scsi-driver (Revision 0.5,
kernel 2.4.x) and the DawiControl DC-2974.
The driver finds an AM53C97 based Scsi-Board but it can't initialise it and
so hangs the computer. Here what's written in /var/log/messages while trying
to modprobe AM53C97:
Mar 17 14:12:55 orion kernel: PCI: Found IRQ 15 for device 00:0a.0
Mar 17 14:12:55 orion kernel: PCI: Sharing IRQ 15 with 00:07.5
Mar 17 14:12:55 orion kernel: scsi1 : AM53/79C974 PCscsi driver rev. 0.5;
host I/O address: 0xc000; irq: 15
Mar 17 14:12:55 orion kernel:
Mar 17 14:12:55 orion kernel: DC390: Suc. op/ Serv. req: pActiveDCB = 0!
Mar 17 14:12:59 orion /usr/sbin/gpm[258]: Error in protocol
Mar 17 14:12:59 orion last message repeated 12 times
Mar 17 14:13:01 orion kernel: scsi : aborting command due to timeout : pid
123, scsi1, channel 0, id 0, lun 0 Inquiry 00 0
Mar 17 14:13:03 orion kernel: SCSI host 1 abort (pid 123) timed out -
resetting
Mar 17 14:13:03 orion kernel: SCSI bus is being reset for host 1 channel 0.
Mar 17 14:13:03 orion kernel: AM53C974_reset called
Mar 17 14:13:03 orion kernel: AM53C974 register dump:
Mar 17 14:13:03 orion kernel: IO base: 0xc000; CTCREG: 0x120000; CMDREG:
0x45; STATREG: 0x00; ISREG: 0xc0
Mar 17 14:13:03 orion kernel: CFIREG: 0x00; CNTLREG1-4: 0x57; 0x40; 0x18;
0x44
Mar 17 14:13:03 orion kernel: DMACMD: 0x80; DMASTC: 0x0800; DMASPA:
0x14f5c000
Mar 17 14:13:03 orion kernel: DMAWBC: 0x0000; DMAWAC: 0x14f5c800; DMASTATUS:
0x00
Mar 17 14:13:03 orion kernel:
---------------------------------------------------------
Mar 17 14:13:03 orion kernel: DC390: Suc. op/ Serv. req: pActiveDCB = 0!
Mar 17 14:13:11 orion kernel: SCSI host 1 abort (pid 125) timed out -
resetting
Mar 17 14:13:11 orion kernel: SCSI bus is being reset for host 1 channel 0.
Mar 17 14:13:11 orion kernel: AM53C974_reset called
Mar 17 14:13:11 orion kernel: AM53C974 register dump:
Mar 17 14:13:11 orion kernel: IO base: 0xc000; CTCREG: 0x120000; CMDREG:
0x45; STATREG: 0x00; ISREG: 0xc0
Mar 17 14:13:11 orion kernel: CFIREG: 0x00; CNTLREG1-4: 0x57; 0x40; 0x18;
0x44
Mar 17 14:13:11 orion kernel: DMACMD: 0x80; DMASTC: 0x0800; DMASPA:
0x14f5c000
Mar 17 14:13:11 orion kernel: DMAWBC: 0x0000; DMAWAC: 0x14f5c800; DMASTATUS:
0x00
Mar 17 14:13:11 orion kernel:
---------------------------------------------------------
Mar 17 14:13:11 orion kernel: DC390: Suc. op/ Serv. req: pActiveDCB = 0!
This repeats every 8 Seconds and can only be stoped by rebooting, because
modprobe enters D state. But even a proper reboot is not possible,
it hangs while 'Shutting down NFS', the disks aren't cleanly unmounted.
And there is another thing: I've only got 1 Scsi-Board, but the AM53C97 is
the second driver trying to use it. The first is the tmscsim which works
well. But the AM53C974 doesn't care if the board is already in use.
This is how the drivers try to find a board:
tcscsim: PCI_FIND_DEVICE (PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD53C974)
AM53C97: pci_find_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_SCSI, pdev)
That's what 'lspci -vvv' says about the DC-2974:
00:0a.0 SCSI storage controller: Advanced Micro Devices [AMD] 53c974
[PCscsi] (rev 10)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping+ SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 70 (1000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 15
Region 0: I/O ports at c000 [size=128]
Expansion ROM at <unassigned> [disabled] [size=64K]
'cat /proc/scsi/scsi':
Attached devices:
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: PLEXTOR Model: CD-ROM PX-40TS Rev: 1.10
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 00
Vendor: FUJITSU Model: MCE3064SS Rev: 0030
Type: Optical Device ANSI SCSI revision: 02
'cat /proc/scsi/tmscsim/0':
Tekram DC390/AM53C974 PCI SCSI Host Adapter, Driver Version 2.0f 2000-12-20
SCSI Host Nr 0, AM53C974 Adapter Nr 0
IOPortBase 0xc000, IRQ 15
MaxID 7, MaxLUN 1, AdapterID 7, SelTimeout 250 ms, DelayReset 1 s
TagMaxNum 16, Status 0x00, ACBFlag 0x00, GlitchEater 24 ns
Statistics: Cmnds 13, Cmnds not sent directly 0, Out of SRB conds 0
Lost arbitrations 0, Sel. connected 0, Connected: No
Nr of attached devices: 2, Nr of DCBs: 2
Map of attached LUNs: 00 00 01 01 00 00 00 00
Idx ID LUN Prty Sync DsCn SndS TagQ NegoPeriod SyncSpeed SyncOffs MaxCmd
00 02 00 Yes Yes Yes Yes No 100 ns 10.0 M 15 01
01 03 00 Yes No Yes Yes No (100 ns) 01
Commands in Queues: Query: 0:
And the problem occurs with every distribution, it is not possible to boot
any CD which uses autoprobing for modules.
CU
Marion Steiner
On Sun, 17 Mar 2002, Marion Steiner wrote:
> There is a problem with the AM53C974 Scsi-driver (Revision 0.5,
> kernel 2.4.x) and the DawiControl DC-2974.
>
> Mar 17 14:13:01 orion kernel: scsi : aborting command due to timeout : pid
> 123, scsi1, channel 0, id 0, lun 0 Inquiry 00 0
> Mar 17 14:13:03 orion kernel: SCSI host 1 abort (pid 123) timed out -
> resetting
> Mar 17 14:13:03 orion kernel: SCSI bus is being reset for host 1 channel 0.
Command timeouts rather look like bus termination problem, plug loose or
something like that. Does the problem still occur with all cables
unplugged from the DC-2974? Does the problem occur with the DC-2974 in
a different computer?
Hi Marion,
On Sun, Mar 17, 2002 at 03:39:58PM +0100, Marion Steiner wrote:
> There is a problem with the AM53C974 Scsi-driver (Revision 0.5,
> kernel 2.4.x) and the DawiControl DC-2974.
>
> The driver finds an AM53C97 based Scsi-Board but it can't initialise it and
> so hangs the computer. Here what's written in /var/log/messages while trying
> to modprobe AM53C97:
Can you try the attached patch please? Patch is against 2.4.18.
It makes the AM53C974 driver register its IO-space and will make detection
fail, if there are no adapters found with available IO-space.
The tmscsim driver (which I maintain) does already register its IO space
correctly, so this patch should make sure that not both of them try to drive
the same piece of hardware.
Please report back, whether it works, so I can ask Marcelo to include it.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
Hi,
On Mon, Mar 18, 2002 at 12:30:38PM +0100, Kurt Garloff wrote:
> Can you try the attached patch please? Patch is against 2.4.18.
Grmpff! Second try.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
In linux.dev.kernel, Kurt Garloff wrote:
>On Sun, Mar 17, 2002 at 11:58:38PM +0100, Matthias Andree wrote:
>> [...]
>> Command timeouts rather look like bus termination problem, plug loose or
>> something like that. Does the problem still occur with all cables
>> unplugged from the DC-2974?
I've testet another case: first load the AM53C974, it works! So there
should be no loose plug or something like that.
>> Does the problem occur with the DC-2974 in
>> a different computer?
I've foud only one message in a Mandrake forum, where someone
complained about trouble with the AM53C974 and asked if there couldn't
be loaded another driver. But if it's really the same problem, I don't
know.
>As far as I could see there were TWO driver loaded trying to drive the same
>piece of hardware at the same time. You can really expect trouble if this
>happens and you can't take any conclusions about hardware problems.
>
>The problem is of course with the drivers: They should not allow to be
>loaded both for the same device.
>IMHO, The AM53C974 driver should register the ioports and fail
>initialization if it can't grab them, so the conflict would be solved. I'll
>investigate what the most proper solution to avoid such things is and come
>up with a patch.
This is told when loading AM53C974 first:
Mar 18 12:00:40 orion kernel: PCI: Found IRQ 15 for device 00:0a.0
Mar 18 12:00:40 orion kernel: PCI: Sharing IRQ 15 with 00:07.5
Mar 18 12:00:40 orion kernel: scsi0 : AM53/79C974 PCscsi driver rev.
0.5; host I/O address: 0xc000; irq: 15
Mar 18 12:00:40 orion kernel:
Mar 18 12:00:40 orion kernel: Vendor: PLEXTOR Model: CD-ROM PX-40TS
Rev: 1.10
Mar 18 12:00:40 orion kernel: Type: CD-ROM
ANSI SCSI revision: 02
Mar 18 12:00:40 orion kernel: Vendor: FUJITSU Model: MCE3064SS
Rev: 0030
Mar 18 12:00:40 orion kernel: Type: Optical Device
ANSI SCSI revision: 02
After loading the AM53C974 as first driver, I tried to load the tmscsim
again. I run into the same problem as vise versa:
Mar 18 12:02:13 orion kernel: PCI: Found IRQ 15 for device 00:0a.0
Mar 18 12:02:13 orion kernel: PCI: Sharing IRQ 15 with 00:07.5
Mar 18 12:02:13 orion kernel: DC390_init: No EEPROM found! Trying
default settings ...
Mar 18 12:02:13 orion kernel: DC390: Used defaults: AdaptID=7,
SpeedIdx=0 (10.0 MHz), DevMode=0x1f, AdaptMode=0x0f, TaggedCmnds=3
Mar 18 12:02:13 orion kernel: DC390: 1 adapters found
Mar 18 12:02:13 orion kernel: scsi0 : Tekram DC390/AM53C974 V2.0f
2000-12-20
Mar 18 12:02:19 orion kernel: scsi : aborting command due to timeout :
pid 20, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff
Mar 18 12:02:19 orion kernel: DC390: Abort command (pid 20, Device
00-00)
Mar 18 12:02:19 orion kernel: DC390: SRB: Xferred 00000000, Remain
00000000, State 00000040, Phase 05
Mar 18 12:02:19 orion kernel: DC390: AdpaterStatus: 00, SRB Status 00
Mar 18 12:02:19 orion kernel: DC390: Status of last IRQ
(DMA/SC/Int/IRQ): 00000000
Mar 18 12:02:19 orion kernel: DC390: Register dump: SCSI block:
Mar 18 12:02:19 orion kernel: DC390: XferCnt Cmd Stat IntS IRQS FFIS
Ctl1 Ctl2 Ctl3 Ctl4
Mar 18 12:02:19 orion kernel: DC390: 0000c0 01 00 c0 00 00
17 48 08 84
Mar 18 12:02:19 orion kernel: DC390: Register dump: DMA engine:
Mar 18 12:02:19 orion kernel: DC390: Cmd STrCnt SBusA WrkBC
WrkAC Stat SBusCtrl
Mar 18 12:02:19 orion kernel: DC390: 00 00000100 11569dc0 000000bc
11569e04 00 03080000
Mar 18 12:02:19 orion kernel: DC390: Register dump: PCI Status: 0200
Mar 18 12:02:19 orion kernel: DC390: In case of driver trouble read
linux/drivers/scsi/README.tmscsim
Mar 18 12:02:19 orion kernel: DC390: Abort current command (pid 20, SRB
d7980148)
Mar 18 12:02:19 orion kernel: DC390: Aborted pid 20 with status 3
Mar 18 12:02:25 orion kernel: scsi : aborting command due to timeout :
pid 20, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff
Mar 18 12:02:25 orion kernel: DC390: Abort command (pid 20, Device
00-00)
Mar 18 12:02:25 orion kernel: DC390: SRB: Xferred 00000000, Remain
00000000, State 00000040, Phase 05
Mar 18 12:02:25 orion kernel: DC390: AdpaterStatus: 00, SRB Status 00
Mar 18 12:02:25 orion kernel: DC390: Status of last IRQ
(DMA/SC/Int/IRQ): 00000000
Mar 18 12:02:25 orion kernel: DC390: Register dump: SCSI block:
Mar 18 12:02:25 orion kernel: DC390: XferCnt Cmd Stat IntS IRQS FFIS
Ctl1 Ctl2 Ctl3 Ctl4
Mar 18 12:02:25 orion kernel: DC390: 0000c0 01 00 c0 00 00
17 48 08 84
Mar 18 12:02:25 orion kernel: DC390: Register dump: DMA engine:
Mar 18 12:02:25 orion kernel: DC390: Cmd STrCnt SBusA WrkBC
WrkAC Stat SBusCtrl
Mar 18 12:02:25 orion kernel: DC390: 00 00000100 11569dc0 000000bc
11569e04 00 03080000
Mar 18 12:02:25 orion kernel: DC390: Register dump: PCI Status: 0200
Mar 18 12:02:25 orion kernel: DC390: In case of driver trouble read
linux/drivers/scsi/README.tmscsim
Mar 18 12:02:25 orion kernel: DC390: Abort current command (pid 20, SRB
d7980148)
Mar 18 12:02:25 orion kernel: DC390: Aborted pid 20 with status 3
Mar 18 12:02:25 orion kernel: SCSI host 0 abort (pid 20) timed out -
resetting
Mar 18 12:02:25 orion kernel: SCSI bus is being reset for host 0
channel 0.
Mar 18 12:02:25 orion kernel: DC390: RESET ... done
Mar 18 12:02:35 orion kernel: scsi : aborting command due to timeout :
pid 21, scsi0, channel 0, id 1, lun 0 Inquiry 00 00 00 ff
Mar 18 12:02:35 orion kernel: DC390: Abort command (pid 21, Device
01-00)
Mar 18 12:02:35 orion kernel: DC390: SRB: Xferred 00000000, Remain
00000000, State 00000040, Phase 05
Mar 18 12:02:35 orion kernel: DC390: AdpaterStatus: 00, SRB Status 00
Mar 18 12:02:35 orion kernel: DC390: Status of last IRQ
(DMA/SC/Int/IRQ): 00000000
Mar 18 12:02:35 orion kernel: DC390: Register dump: SCSI block:
Mar 18 12:02:35 orion kernel: DC390: XferCnt Cmd Stat IntS IRQS FFIS
Ctl1 Ctl2 Ctl3 Ctl4
Mar 18 12:02:35 orion kernel: DC390: 0000c0 01 00 c0 00 00
17 48 08 84
Mar 18 12:02:35 orion kernel: DC390: Register dump: DMA engine:
Mar 18 12:02:35 orion kernel: DC390: Cmd STrCnt SBusA WrkBC
WrkAC Stat SBusCtrl
Mar 18 12:02:35 orion kernel: DC390: 00 00000100 11569dc0 000000bc
11569e04 00 03080000
Mar 18 12:02:35 orion kernel: DC390: Register dump: PCI Status: 0200
Mar 18 12:02:35 orion kernel: DC390: In case of driver trouble read
linux/drivers/scsi/README.tmscsim
Mar 18 12:02:35 orion kernel: DC390: Abort current command (pid 21, SRB
d7980148)
Mar 18 12:02:35 orion kernel: DC390: Aborted pid 21 with status 3
Mar 18 12:02:41 orion kernel: scsi : aborting command due to timeout :
pid 21, scsi0, channel 0, id 1, lun 0 Inquiry 00 00 00 ff
Mar 18 12:02:41 orion kernel: DC390: Abort command (pid 21, Device
01-00)
Mar 18 12:02:41 orion kernel: DC390: SRB: Xferred 00000000, Remain
00000000, State 00000040, Phase 05
Mar 18 12:02:41 orion kernel: DC390: AdpaterStatus: 00, SRB Status 00
Mar 18 12:02:41 orion kernel: DC390: Status of last IRQ
(DMA/SC/Int/IRQ): 00000000
Mar 18 12:02:41 orion kernel: DC390: Register dump: SCSI block:
Mar 18 12:02:41 orion kernel: DC390: XferCnt Cmd Stat IntS IRQS FFIS
Ctl1 Ctl2 Ctl3 Ctl4
Mar 18 12:02:41 orion kernel: DC390: 0000c0 01 00 c0 00 00
17 48 08 84
Mar 18 12:02:41 orion kernel: DC390: Register dump: DMA engine:
Mar 18 12:02:41 orion kernel: DC390: Cmd STrCnt SBusA WrkBC
WrkAC Stat SBusCtrl
Mar 18 12:02:41 orion kernel: DC390: 00 00000100 11569dc0 000000bc
11569e04 00 03080000
Mar 18 12:02:41 orion kernel: DC390: Register dump: PCI Status: 0200
Mar 18 12:02:41 orion kernel: DC390: In case of driver trouble read
linux/drivers/scsi/README.tmscsim
Mar 18 12:02:41 orion kernel: DC390: Abort current command (pid 21, SRB
d7980148)
Mar 18 12:02:41 orion kernel: DC390: Aborted pid 21 with status 3
Mar 18 12:02:41 orion kernel: SCSI host 0 abort (pid 21) timed out -
resetting
Mar 18 12:02:41 orion kernel: SCSI bus is being reset for host 0
channel 0.
Mar 18 12:02:41 orion kernel: DC390: RESET ... done
But at this point there is a real crash (magic keys still works, but
no chance for only tryig to reboot).
So maybe the tmscsim has the same problem? Or one of the drivers
doesn't care to mark the device as being already served nor to look
if its busy?
CU
Marion Steiner
>
>On Mon, Mar 18, 2002 at 12:30:38PM +0100, Kurt Garloff wrote:
>> Can you try the attached patch please? Patch is against 2.4.18.
>
OK, after testing I can say:
After loading AM53C974 I can not load tmscsim any more!
But that's the only improvement so far.
After loading tmscsim I can still load AM53C974, /var/log/messages
looks same as before:
Mar 18 15:11:03 orion kernel: PCI: Found IRQ 15 for device 00:0a.0
Mar 18 15:11:03 orion kernel: PCI: Sharing IRQ 15 with 00:07.5
Mar 18 15:11:03 orion kernel: scsi0 : AM53/79C974 PCscsi driver rev.
0.5; host I/O address: 0xc000; irq: 15
Mar 18 15:11:03 orion kernel:
Mar 18 15:11:03 orion kernel: DC390: Suc. op/ Serv. req: pActiveDCB =
0!
Mar 18 15:11:09 orion kernel: scsi : aborting command due to timeout :
pid 41, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 0
Mar 18 15:11:12 orion kernel: SCSI host 0 abort (pid 41) timed out -
resetting
Mar 18 15:11:12 orion kernel: SCSI bus is being reset for host 0
channel 0.
Mar 18 15:11:12 orion kernel: AM53C974_reset called
Mar 18 15:11:12 orion kernel: AM53C974 register dump:
Mar 18 15:11:12 orion kernel: IO base: 0xc000; CTCREG: 0x120000;
CMDREG: 0x45; STATREG: 0x00; ISREG: 0xc0
Mar 18 15:11:12 orion kernel: CFIREG: 0x00; CNTLREG1-4: 0x57; 0x40;
0x18; 0x44
Mar 18 15:11:12 orion kernel: DMACMD: 0x80; DMASTC: 0x0100; DMASPA:
0x1549ddc0
Mar 18 15:11:12 orion kernel: DMAWBC: 0x00bc; DMAWAC: 0x1549de04;
DMASTATUS: 0x00
Mar 18 15:11:12 orion kernel:
---------------------------------------------------------
Mar 18 15:11:12 orion kernel: DC390: Suc. op/ Serv. req: pActiveDCB =
0!
Mar 18 15:11:20 orion kernel: SCSI host 0 abort (pid 43) timed out -
resetting
Mar 18 15:11:20 orion kernel: SCSI bus is being reset for host 0
channel 0.
Mar 18 15:11:20 orion kernel: AM53C974_reset called
Mar 18 15:11:20 orion kernel: AM53C974 register dump:
Mar 18 15:11:20 orion kernel: IO base: 0xc000; CTCREG: 0x120000;
CMDREG: 0x45; STATREG: 0x00; ISREG: 0xc0
Mar 18 15:11:20 orion kernel: CFIREG: 0x00; CNTLREG1-4: 0x57; 0x40;
0x18; 0x44
Mar 18 15:11:20 orion kernel: DMACMD: 0x80; DMASTC: 0x0100; DMASPA:
0x1549ddc0
Mar 18 15:11:20 orion kernel: DMAWBC: 0x00bc; DMAWAC: 0x1549de04;
DMASTATUS: 0x00
Mar 18 15:11:20 orion kernel:
---------------------------------------------------------
Mar 18 15:11:20 orion kernel: DC390: Suc. op/ Serv. req: pActiveDCB =
0!
[Still repeating until reboot]
Reboot now succeeds cleanly, but maybe it was my fault it fail before
while hanging in AM53C974. It sometimes seems to need some keys pressed
to go on. (?!)
But there is another thing now happening:
After unloading any of the two drivers modprobing the AM53C974 fail
in the first try, even after waiting some time. Second try suceeds:
orion:~ # rmmod AM53C974
orion:~ # modprobe AM53C974
/lib/modules/2.4.18/kernel/drivers/scsi/AM53C974.o: init_module: No
such device
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters
/lib/modules/2.4.18/kernel/drivers/scsi/AM53C974.o: insmod
/lib/modules/2.4.18/kernel/drivers/scsi/AM53C974.o failed
/lib/modules/2.4.18/kernel/drivers/scsi/AM53C974.o: insmod AM53C974
failed
orion:~ # modprobe AM53C974
orion:~ #
Modprobing tmscsim succeeds on first try.
CU
Marion Steiner
In linux.dev.kernel, Kurt Garloff wrote:
>Can you try the attached patch please? Patch is against 2.4.18.
>
>It makes the AM53C974 driver register its IO-space and will make detection
>fail, if there are no adapters found with available IO-space.
>
>The tmscsim driver (which I maintain) does already register its IO space
>correctly, so this patch should make sure that not both of them try to drive
>the same piece of hardware.
>
>Please report back, whether it works, so I can ask Marcelo to include it.
OK, I found a littler bug in it, that's why on my first try it didn't
work. There was a "!" missing in the if statement whether the region is
free. So the driver failed if the region was free and succeeded if it was
busy.
But now it seems to work well, so including it in the kernel would be
great.
CU
Marion Steiner
Here the corrected patch:
--- linux-2.4.18.ipt_fixes2.ix86/drivers/scsi/AM53C974.c.orig Sun Sep 30 21:26:07 2001
+++ linux-2.4.18.ipt_fixes2.ix86/drivers/scsi/AM53C974.c Mon Mar 18 11:59:31 2002
@@ -732,6 +732,12 @@
hostdata->disconnecting = 0;
hostdata->dma_busy = 0;
+ if (!request_region (instance->io_port, 128, "AM53C974")) {
+ printk ("AM53C974 (scsi%d): Could not get IO region %04lx. Detaching ...\n",
+ instance->host_no, instance->io_port);
+ scsi_unregister(instance);
+ return 0;
+ }
/* Set up an interrupt handler if we aren't already sharing an IRQ
with another board */
for (search = first_host;
search && (((the_template != NULL) && (search->hostt !=
the_template)) ||
@@ -2441,6 +2447,7 @@
static int AM53C974_release(struct Scsi_Host *shp)
{
free_irq(shp->irq, shp);
+ release_region(shp->io_port, 128);
scsi_unregister(shp);
return 0;
}
Hi Marion,
On Wed, Mar 20, 2002 at 03:01:12PM +0100, Marion Steiner wrote:
> In linux.dev.kernel, Kurt Garloff wrote:
> >Can you try the attached patch please? Patch is against 2.4.18.
> >
[...]
> >Please report back, whether it works, so I can ask Marcelo to include it.
>
> OK, I found a littler bug in it, that's why on my first try it didn't
> work. There was a "!" missing in the if statement whether the region is
> free. So the driver failed if the region was free and succeeded if it was
> busy.
>
> But now it seems to work well, so including it in the kernel would be
> great.
Right you are! I was confused because I had fixed the aic7xxx driver just
before where the statement reads request_region(...) == 0.
Sorry about that.
I'll submit the corrected patch to Marcelo.
Thanks for testing and for spotting the typo!
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
On Sun, Mar 17, 2002 at 11:58:38PM +0100, Matthias Andree wrote:
> On Sun, 17 Mar 2002, Marion Steiner wrote:
>
> > There is a problem with the AM53C974 Scsi-driver (Revision 0.5,
> > kernel 2.4.x) and the DawiControl DC-2974.
> >
> > Mar 17 14:13:01 orion kernel: scsi : aborting command due to timeout : pid
> > 123, scsi1, channel 0, id 0, lun 0 Inquiry 00 0
> > Mar 17 14:13:03 orion kernel: SCSI host 1 abort (pid 123) timed out -
> > resetting
> > Mar 17 14:13:03 orion kernel: SCSI bus is being reset for host 1 channel 0.
>
> Command timeouts rather look like bus termination problem, plug loose or
> something like that. Does the problem still occur with all cables
> unplugged from the DC-2974? Does the problem occur with the DC-2974 in
> a different computer?
As far as I could see there were TWO driver loaded trying to drive the same
piece of hardware at the same time. You can really expect trouble if this
happens and you can't take any conclusions about hardware problems.
The problem is of course with the drivers: They should not allow to be
loaded both for the same device.
IMHO, The AM53C974 driver should register the ioports and fail
initialization if it can't grab them, so the conflict would be solved. I'll
investigate what the most proper solution to avoid such things is and come
up with a patch.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security